애플리케이션별 평가 접근법

애플리케이션별 평가 접근법

LLM 애플리케이션을 평가한다고 해서 똑같은 방법을 쓰진 않아요. 어떤 종류의 애플리케이션이냐에 따라 초점이 달라지거든요. 여기서는 인기 있는 몇 가지 LLM 애플리케이션 유형(에이전트·RAG·요약·분류)을 어떻게 평가하는지 정리해 볼게요.

출처: Application-specific evaluation approaches - 공식문서

에이전트 평가

LLM 기반 자율 에이전트는 세 가지 요소를 결합해요: ① 도구 호출(Tool calling), ② 메모리(Memory), ③ 계획(Planning). 에이전트는 도구 호출로 주어진 프롬프트에 응답할 때 (1) 호출할 도구와 (2) 필요한 입력 인자를 생성하고, 계획(흔히 프롬프팅)과 메모리(흔히 단기 메시지 기록)를 사용해 응답을 만들어요.

LangGraph로 만든 도구 호출 에이전트 구조를 살펴보면 이해가 쉬워요. assistant node는 입력을 보고 도구를 호출할지 판단하는 LLM이고, tool condition은 assistant node가 도구를 선택했는지 확인해 선택했다면 tool node로 라우팅해요. tool node는 도구를 실행하고 그 출력을 tool 메시지로 assistant node에 돌려줘요. 이 루프는 assistant node가 도구를 선택하는 한 계속되고, 도구가 선택되지 않으면 에이전트가 바로 LLM 응답을 반환해요.

이런 구조에서 사용자가 관심 갖는 에이전트 평가는 세 가지 유형으로 정리돼요.

• Final Response — 에이전트의 최종 응답을 평가
• Single step — 개별 에이전트 단계를 단독으로 평가(예: 적절한 도구를 선택했는지)
• Trajectory — 에이전트가 최종 답에 도달하기 위해 예상된 경로(예: 도구 호출 흐름)를 밟았는지 평가

일반적인 사용 사례는 이 중 여러 개 또는 전부를 함께 쓰기도 해요. 서로 배타적이지 않다는 점을 기억해 두면 좋아요.

에이전트의 최종 응답 평가

에이전트가 태스크에서 전반적으로 잘 수행했는지를 평가하는 방식이에요. 기본적으로 에이전트를 블랙박스로 보고 작업을 제대로 끝냈는지만 판정해요.

• 입력: 사용자 입력과 선택적으로 도구 목록. 도구가 에이전트에 하드코딩돼 있다면 넘길 필요 없고, 더 범용적인 에이전트라면 실행 시점에 도구를 넘겨줘야 해요.
• 출력: 에이전트의 최종 응답.
• 평가자: 태스크에 따라 달라요. RAG와 유사하게, 많은 에이전트가 복잡한 일련의 단계를 거친 뒤 최종 텍스트 응답을 내놓으므로 LLM-as-judge가 텍스트 응답만으로 작업 성공 여부를 판단하기에 효과적이에요.

다만 몇 가지 단점이 있어요. 실행 시간이 꽤 걸리고, 에이전트 내부에서 일어난 일은 평가하지 않아 실패 시 디버깅이 어려우며, 적절한 평가 지표를 정의하기 어려운 경우도 있어요.

에이전트의 단일 단계 평가

에이전트는 일반적으로 여러 액션을 수행해요. 종단 간 평가도 유용하지만, 개별 액션을 평가하는 것도 가치가 있어요. 보통 에이전트의 한 단계, 즉 "무엇을 할지 결정하는 LLM 호출"을 평가하는 방식이에요.

• 입력: 평가 대상에 따라 단계의 입력. 단순히 원시 사용자 입력(프롬프트나 도구 세트)일 수도, 이전에 완료한 단계를 포함할 수도 있어요.
• 출력: 그 단계의 출력, 보통 LLM 응답. LLM 응답에는 에이전트가 다음에 취해야 할 액션을 나타내는 도구 호출이 포함되는 경우가 많아요.
• 평가자: 올바른 도구 호출이 선택됐는지에 대한 이진 점수와, 도구 입력이 올바른지에 대한 휴리스틱. 참조 도구는 단순히 문자열로 지정할 수 있어요.

이 방식의 장점은 개별 액션을 평가해 애플리케이션이 어디서 실패하는지 좁힐 수 있고, LLM 호출 한 번만 거치므로 상대적으로 빠르다는 점이에요. 평가도 참조 도구와 선택된 도구를 비교하는 단순한 휴리스틱으로 이뤄지는 경우가 많고요. 단점은 전체 에이전트가 아니라 특정 단계만 잡는다는 것과, 에이전트 입력에 과거 이력을 포함하려면 데이터셋 생성이 까다로울 수 있다는 점이에요. 궤적 초반 단계(입력 프롬프트만 포함하는 경우)는 데이터셋 생성이 쉽지만, 후반 단계(수많은 이전 액션·응답 포함)는 어려울 수 있어요.

에이전트의 궤적 평가

에이전트가 수행한 모든 단계를 평가하는 방식이에요.

• 입력: 전체 에이전트에 대한 입력(사용자 입력과 선택적으로 도구 목록).
• 출력: 도구 호출 목록. 예상된 도구 호출 시퀀스를 정확히 지정한 "정확(exact)" 궤적이거나, 순서와 무관하게 예상되는 도구 호출 집합일 수 있어요.
• 평가자: 취해진 단계에 대한 어떤 함수. "정확" 궤적은 시퀀스에서 각 도구 이름이 정확히 일치하는지 확인하는 단일 이진 점수를 쓸 수 있어요. 단순하지만 몇 가지 단점이 있는데, 올바른 경로가 여러 개일 수 있고, 궤적이 한 단계 빗나간 것과 완전히 틀린 것을 구분하지 못해요.

이 단점을 보완하려면 "잘못된" 단계의 수에 초점을 맞춘 평가 지표로 근접한 궤적과 크게 벗어난 궤적을 구분하거나, 예상된 도구가 순서와 무관하게 전부 호출됐는지를 보는 지표를 쓸 수 있어요.

다만 이런 접근들은 전부 도구의 입력은 평가하지 않고 선택된 도구에만 집중해요. 입력까지 고려하려면 에이전트의 전체 궤적을 참조 궤적과 함께 메시지 집합(모든 LLM 응답과 도구 호출)으로 LLM-as-judge에 넘기는 방법이 있어요. 이렇게 하면 에이전트의 완전한 동작을 평가할 수 있지만 참조를 구성하기 가장 어렵고, 이런 작업엔 LangGraph 같은 프레임워크가 도움을 줘요. 평가 지표를 떠올리기도 꽤 까다로운 편이에요.

RAG 애플리케이션 평가

Retrieval-augmented generation (RAG)은 사용자 입력에 대해 문서를 검색해 모델에 넘겨서 외부 지식을 활용해 응답하게 하는 기법이에요. 단계별 워크스루는 Evaluate a RAG application을 참고해요.

데이터셋 선택 — 각 example에 참조 답이 있는지부터 결정해요. 참조 답이 있으면 정답(gound truth)으로 써서 답변 정확도를 점수화하고, 없으면 문서 관련성·답변 충실성·유용성을 확인하는 참조 없는(Reference-free) 프롬프트를 써요.

평가자 선택 — LLM-as-judge가 RAG에 잘 맞아요. 텍스트 간 사실적 정확성과 일관성을 점수화할 수 있기 때문이에요. 두 종류가 있어요.

• 참조 기반(Reference-based) — 생성된 답이나 검색된 문서를 참조 답이나 참조 검색 결과와 비교
• 참조 없는(Reference-free) — 참조 답이 필요 없는 자체 일관성(self-consistency) 검사 실행

평가 모드 선택 — 세 가지가 있어요.

• 오프라인(Offline) — 프롬프트가 참조 답을 필요로 할 때, 가장 흔히 답변 정확도에 사용
• 온라인(Online) — 실서비스 트래픽을 점수화할 수 있도록 참조 없는 프롬프트에 사용
• 쌍 비교(Pairwise) — 형식·스타일 같은 기준으로 서로 다른 RAG 체인의 답을 비교. 정확도 확인은 자체 일관성이나 참조 답을 사용

RAG 평가 요약 — 평가자별로 참조 출력 필요 여부와 LLM-as-judge 사용 여부가 달라요.

요약 평가

요약은 자유 형식 글쓰기의 한 유형이에요. 평가 목표는 보통 일련의 기준에 비추어 작성물(요약문)을 검토하는 것이에요.

요약할 텍스트의 Developer curated examples가 평가에 흔히 쓰여요(요약 데이터셋 예시). 프로덕션(요약) 앱의 user logs는 아래 Reference-free 평가 프롬프트 중 아무거나로 온라인 평가에 쓸 수 있죠.

LLM-as-judge는 요약(그리고 다른 종류의 글쓰기) 평가에 주로 쓰여요. 주어진 기준을 따라 요약문을 등급 매기는 Reference-free 프롬프트를 사용해요. 특정 Reference 요약을 제공하는 경우는 드물어요. 요약은 창의적 태스크라 정답이 여러 개일 수 있기 때문이에요. Reference-free 프롬프트 덕분에 Online·Offline 평가가 모두 가능하고, Pairwise 평가는 서로 다른 요약 체인(다른 요약 프롬프트나 LLM)을 비교하는 강력한 방법이에요.

분류·태깅 평가

분류·태깅은 주어진 입력에 라벨을 붙이는 작업이에요(독성 감지, 감성 분석 등). 분류·태깅 평가는 보통 다음 구성 요소를 사용하는데, 하나씩 살펴볼게요.

핵심 고려사항은 reference 라벨이 있는 데이터셋을 갖는지 여부예요. 라벨이 없으면 기준(criteria, 예: 독성)을 사용해 입력(텍스트, 사용자 질문 등)에 라벨을 붙이는 평가자를 정의하고 싶은 경우가 많아요. 반면 ground truth 클래스 라벨이 제공되면, 평가 목표는 정확도·재현율(precision, recall) 같은 지표로 분류·태깅 체인을 ground truth 클래스 라벨에 비추어 점수화하는 데 초점을 맞춰요.

ground truth 참조 라벨이 있으면 커스텀 휴리스틱 평가자를 정의해 ground truth 라벨과 체인 출력을 비교하는 것이 흔해요. 하지만 LLM 등장 이후로는 ground truth 참조 없이 지정된 기준에 따라 입력의 분류·태깅을 수행하도록 LLM-as-judge를 쓰는 경우가 점점 늘고 있어요.

Reference-free 프롬프트로 LLM-as-judge를 쓰면 Online·Offline 평가가 모두 가능해요. 특히 사용자가 애플리케이션 입력을 태깅·분류(예: 독성 등)하고 싶을 때 Online 평가에 잘 맞아요.

더 알아보기

• LangSmith 평가 (Evaluation) 개요
• LLM-as-judge 평가
• RAG 애플리케이션 평가 튜토리얼
• Assertions로 수용 기준 자동화하기