멀티턴 LLM 평가: 5가지 메트릭, 3가지 프레임워크, 1가지 워크플로우
멀티턴 LLM 평가는 턴-8 건망증 버그를 잡을 수 있는 유일한 방법이다: 사용자가 턴 3에서 주문 번호를 제시했는데, 봇이 다시 묻는 것이다. 각 턴은 독립적으로 통과했지만, 전체 대화는 실패했다. DeepEval 4.0과 RAGAS 0.4가 정확히 이를 위해 전용 대화형 평가 API를 출시했으며, Techsy의 자체 파이프라인에서 두 번의 평가 사건을 겪은 후, 시작해야 할 5가지 메트릭, 3가지 프레임워크, 1가지 워크플로우를 소개한다.
핵심 요점
- 멀티턴 평가는 고립된 입력-출력 쌍이 아닌 전체 대화를 점수화한다.
- 단일턴 벤치마크에서 상위권인 모델도 대화 턴이 진행됨에 따라 성능이 현저히 저하된다.
- 네 가지 메트릭부터 시작하자: 완결성, 지식 보존, 역할 준수, 턴 관련성.
- DeepEval, RAGAS, Langfuse는 멀티턴 평가를 각각 다르게 해결한다; 아래 프레임워크 표를 비교해 보자.
단일턴 점수가 당신을 속이는 이유는?
단일턴 평가는 한 번에 하나의 입력-출력 쌍을 점수화하므로, 턴에 걸쳐서만 나타나는 실패(건망증, 모순, 표류)를 볼 수 없다. 모델은 강력한 벤치마크 점수를 게시할 수 있으면서도 실제 대화의 흐름을 잃을 수 있다. Laban 외는 "LLMs Get Lost In Multi-Turn Conversation"에서 이를 문서화했으며, 353개 인용: 단일턴 결과가 건강해 보여도 멀티턴 설정에서는 성능이 저하된다.
핵심 문제는 비결정성이다: n번째 응답은 모든 n-1개의 이전 턴에 의존하므로, 동일한 프롬프트도 이력에 따라 다르게 작동한다. 고립된 쌍의 데이터셋은 이 의존성을 절대 검증하지 않는다. arXiv 서베이 "Evaluating LLM-based Agents for Multi-Turn Conversations"는 약 250개 자료의 PRISMA 리뷰로서, 평가 대상(문맥 관리, 계획, 일관성)과 평가 방법(메트릭, LLM 판사, 인간 검토)으로 분야를 나눈다. 단일턴 스위트에는 두 축이 모두 없다.
이것이 단일턴 스택을 쓸모없게 만드는 건 아니다. BLEU, ROUGE, G-Eval 같은 단일턴 메트릭을 실행한다면, 잘 측정하는 것에만 사용하자: 형식 규정 준수, 독성, 고정 프롬프트에 대한 사실 기억. 단지 사용자가 접하는 대화의 건강 상태 점검으로 읽는 것을 멈추자.
우리의 해석을 한 줄로:
단일턴 평가는 답변을 측정하고, 멀티턴 평가는 대화를 측정하며, 턴 1을 만점한 모델도 턴 5에는 길을 잃을 수 있다.
멀티턴 LLM 평가란 무엇인가? 두 가지 평가 모드
멀티턴 LLM 평가는 고립된 프롬프트-응답 쌍 대신 전체 대화 또는 그 안의 윈도우를 점수화하는 관행이다. 모델이 문맥을 유지했고, 역할을 지켰으며, 턴에 걸쳐 사용자의 문제를 해결했는지를 묻는다. 두 가지 모드가 이 일을 한다: 대화 수준 점수화와 슬라이딩 윈도우 턴 수준 점수화이며, 대부분의 팀은 둘 다 실행한다.
대화 수준 점수화는 판사에게 전체 기록을 제공하고 한 가지 질문을 던진다: 이 대화는 성공했는가? 전체 스레드만이 사용자가 환불을 받지 못했다는 것을 보여주므로, 조기 종료와 미해결 루프를 잡아낸다. 약점은 세분성이다: 12턴 스레드에서 "실패"는 어디서 문제가 발생했는지 말하지 않는다.
슬라이딩 윈도우 턴 수준 점수화는 N턴의 윈도우를 기록 전체에 이동하고, 윈도우당 하나의 판정을 제시한다. 10턴 대화에서 크기가 3인 윈도우는 채팅의 영역에 연결된 8개의 판정을 산출하므로, "실패"는 좌표와 함께 온다: 문제는 턴 6부터 8에서 발생했다. 이 포스트 맨 위의 다이어그램은 한 스레드에서 두 가지 모드를 보여준다: 대화 판정을 위한 괄호, 윈도우별 판정을 위한 슬라이딩 프레임.
대화 수준 점수화를 게이트로, 윈도우형 점수화를 그것이 작동할 때 실패를 지역화하는 데 사용하자. DeepEval의 멀티턴 평가 가이드는 작업의 단위를 입력-출력 쌍이 아닌 시나리오로 정의한다(ConversationalGolden 타입): 질문이 아닌 상황을 테스트하고 있다.
예시(합성; 실제 실행이 아닌 메커니즘을 보여줌): 8턴 반품 요청 채팅에서 크기가 3인 슬라이딩 윈도우.
대화 수준 판정: 실패. 6개 윈도우 중 5개가 통과했지만, 스레드는 지식 보존에서 깨졌으며, 이는 정확히 단일턴 스위트가 절대 드러내지 않는 실패다.
어떤 멀티턴 메트릭이 중요한가? 중요한 5가지
먼저 네 가지 메트릭을 실행하자: 대화 완결성, 지식 보존, 역할 준수, 턴 관련성. 다섯 번째로 커스텀 기준(DeepEval의 G-Eval, RAGAS의 AspectCritic)을 추가하되, 제품이 놓칠 수 없는 것을 대상으로 하자. 처음 네 가지는 프로젝트 간에 전달되지만; 다섯 번째가 실패 모드가 사는 곳이다.
- 대화 완결성. 사용자의 목표가 해결되었나, 아니면 봇이 조기에 승리를 선언했나? 조기 종료 감지기.
- 지식 보존. 모델이 스레드에서 이전에 명시된 사실을 기억하는가? 턴-8 건망증 버그는 지식 보존 실패다.
- 역할 준수. 어시스턴트가 페르소나 내에 머무르고 범위 밖의 요청을 거부하는가? 규정 준수 경계에서 중요하다.
- 턴 관련성. 각 응답이 이전 턴을 고려했을 때 주제에 맞는가? 표류와 루프를 잡아낸다.
- 커스텀 기준. 도메인을 위한 하나의 평문 규칙: "가격 목록과 다른 가격을 절대 인용하지 말 것." DeepEval은 ConversationalGEval로 구현하고; RAGAS는 AspectCritic으로 구현한다.
DeepEval 메트릭 가이드는 각각을 실행 가능한 클래스로 정의하지만, 개념은 프레임워크 중립적이다: 판사를 직접 만들어도 표는 성립한다.
커스텀 기준은 문장처럼 읽힌다:
실제 DeepEval 코드와 동일한 규칙:
DeepEval vs RAGAS vs Langfuse: 어떤 프레임워크가 맞는가?
세 가지 모두 멀티턴 대화를 평가하지만, 평가 단위가 다르다: DeepEval은 오프라인으로 시나리오를 시뮬레이션하고, RAGAS는 이미 있는 대화의 측면을 점수화하며, Langfuse는 실제 프로덕션 추적을 평가한다. 기능 개수로 선택하지 말고 대화가 어디서 오는지로 선택하자.
프레임워크 중립적 로직이 먼저이므로, 아래 벤더 코드는 이식 가능하다:
DeepEval: 시나리오와 배터리 포함 시뮬레이터
DeepEval은 일급 대화 시뮬레이터를 가진 유일한 것이다: 시나리오와 페르소나를 설명하면, 사용자를 봇에 맞춘다. 멀티턴 가이드는 시나리오-페어가 아닌 패턴의 정규 참조다. Confident AI는 호스팅 대시보드를 판매한다; 우리의 Confident AI 리뷰는 유료 계층이 추가하는 것을 다룬다.
RAGAS: 오류 분석 주도, 측면별
RAGAS는 이미 있는 대화에서 시작하여 측면별로 점수를 매긴다. 멀티턴 방법은 수동 오류 분석과 쌍을 이룬다: 실패한 채팅을 읽고, 실패 모드마다 AspectCritic을 작성하고, 점수를 매긴다.
Langfuse: 실제 추적에 대한 N+1 평가
Langfuse는 반대 경로를 취한다: 추적기가 먼저다. N+1 요리책은 각 턴의 추적과 전체 대화를 평가하며, 시뮬레이션이 아닌 프로덕션 트래픽에서 평가한다. 아직 관찰성 계층을 선택 중이라면, 우리의 Langfuse vs LangSmith 비교가 이 결정을 다룬다.
우리의 판정, 타협 없음: 새로운 챗봇 프로젝트에는 DeepEval로 시작하자. 시뮬레이터는 프로덕션 트래픽이 있기 전에 회귀를 제어할 수 있게 해주며, 이때가 테스트가 가장 필요할 때다. 실제 스레드가 존재하면 Langfuse를 추가하자; 팀이 실패한 대화를 읽고 발견한 것을 체계화하는 것을 선호할 때 RAGAS를 선택하자.
오류 분석에서 자동화로 어떻게 이동하나?
순서대로 진행한다. 실제 대화 20-30개를 읽고, 실패 모드에 손으로 레이블을 붙이고, 명백한 것들에 대해 이진 통과/실패 검사를 작성하고, 그것들을 자동화하고, 그 후에만 주관적 잔여물에 대해 LLM 판정 메트릭을 추가한다. Hamel Husain은 정확히 이 순서를 주장한다: 수동 오류 분석과 이진 결정이 먼저인데, 설명할 수 있는 검사가 설명할 수 없는 점수를 이기기 때문이다.
판사 전 이진: 우리를 구한 순서
이는 우리가 실행한 챗봇 벤치마크가 아니다; 이는 모든 프롬프트 및 도구 변경에서 평가 게이트 회귀 검사를 실행하는 자체 콘텐츠 파이프라인 내에서 동일한 패턴에 대한 우리의 해석이다. 두 가지 사건이 우리에게 순서를 증명했다.
...