당신의 에이전트 평가 스위트(eval suite)는 한 번에 한 턴씩 점수를 매깁니다. 프롬프트(Prompt)를 입력하고, 출력(output)을 내보내고, 점수를 매긴 뒤 다음으로 넘어갑니다. 그러한 모델은 완성형 엔드포인트(completion endpoint)에는 적합할 수 있습니다. 하지만 대화를 유지해야 하는 모든 작업에는 조용히 잘못된 방식이며, 이것이 바로 당신의 "94% 통과율"이 6번째 턴에서 분노하며 이탈하는 사용자들과 공존하는 이유입니다.

대화형 에이전트(conversational agent)의 실패 단위는 턴(turn)이 아닙니다. 그것은 바로 **세션(session)**입니다.

턴 단위의 사각지대

고객 지원 에이전트를 가정해 봅시다. 턴 1: 사용자가 환불에 대해 묻습니다. 에이전트는 올바르게 답변하고 모든 평가를 통과합니다. 턴 4: 사용자가 부분(partial) 환불을 의미한다고 명확히 합니다. 에이전트는 그것에 대해서도 올바르게 답변합니다. 턴 6: 에이전트는 3턴 전에 "부분"이라는 제약 조건을 조용히 놓쳐버린 채, 다시 원래의 환불 금액을 인용합니다.

모든 개별 턴은 고립된 평가를 통과합니다. 각 출력은 근거가 확실하고, 형식이 잘 갖춰져 있으며, 주제에 부합합니다. 실패는 오직 턴들 _사이(across)_에만 존재합니다. 제약 조건의 누락, 턴 4와의 모순, 지켜지지 않은 약속 같은 것들 말입니다. 턴 단위의 채점은 구조적으로 이를 인지하지 못하는데, 왜냐하면 버그는 개별 출력 중 하나에 있는 것이 아니라 출력들 사이의 관계에 있기 때문입니다.

이것은 이례적인 예외 사례가 아닙니다. 제약 조건의 감쇠(Constraint decay), 자기 모순(self-contradiction), 그리고 잊혀진 약속들은 멀티 턴(multi-turn) 에이전트에서 나타나는 지배적인 실패 유형입니다. 그리고 이는 대부분의 팀이 실제로 운영하는 평가 아키텍처(eval architecture)에서는 보이지 않습니다.

계층 구조에서 세션 수준의 신호가 존재하는 위치

제가 쓴 글을 읽어보셨다면, 저는 평가 증거를 비용 축이 아닌 독립성(independence) 축에 따라 분류한다는 것을 알고 계실 것입니다. 에이전트가 조작할 수 없는 증거부터 에이전트와 동일한 기질(substrate)을 공유하는 의견에 이르기까지 다음과 같이 분류합니다:

• Tier 1: 에이전트가 속일 수 없는 외부 관찰 가능한 증거. 유효한 JSON, 존재하는 파일, 통과된 테스트, 타임아웃 내 완료, 비어 있지 않음.
• Tier 2: 에이전트가 작성하지 않은 기준점(baseline) 대비 통계적 신호. 임베딩 유사도(Embedding similarity), 반복성, diff가 실제로 무언가를 변경했는지 여부.
• Tier 3: 모델 기반 판사(model-as-judge). 동일 기질(shared-substrate)의 의견. 이는 신호(signal)일 뿐, 결론(verdict)은 아닙니다.

팀들이 멀티 턴(multi-turn) 상황에서 범하는 실수는 세션 평가(session evaluation)가 본질적으로 Tier 3 문제라고 가정하는 것입니다. 즉, "전체 대화가 일관적이었는지 판사(judge)에게 물어보면 된다"라고 생각하는 것이죠. 하지만 그렇지 않습니다. 마지막 메시지가 아닌 궤적(trajectory)을 살펴보면, 세션 실패의 상당 부분은 Tier 1 및 Tier 2에 해당합니다.

• 6번째 턴의 양이 에이전트가 4번째 턴에서 스스로 약속한 값과 **모순(contradict)**되었는가? 이는 구조화된 추출(structured extractions)에 대한 결정론적 차이(deterministic diff)이며, Tier 1입니다. 판사가 필요 없습니다.
• 사용자가 설정한 제약 조건("부분적인", "EUR 단위로", "금요일 전까지")이 최종 출력까지 **유지(survive)**되었는가? 해결된 슬롯(resolved slots)에 대한 집합 멤버십 확인(Set-membership check)이며, Tier 1/2입니다.
• 에이전트가 진전하는 대신 이전 답변을 그대로 **반복(repeat)**했는가? 턴 간의 반복 및 임베딩 유사도(embedding-similarity) 확인이며, Tier 2입니다.
• 모든 사용자 질문에 대응하는 답변이 있었는가, 아니면 하나가 **누락(dropped)**되었는가? 개수 및 커버리지 확인이며, Tier 1입니다.

이러한 검사들은 **궤적(trajectory)**을 따라 결정론적으로 수행되며, 비용이 거의 $0에 가깝고 게이트(gate) 역할을 할 만큼 충분히 빠릅니다. 그리고 Tier 1+2가 궤적에 대해 실행될 수 있는 이유는 정확히 이들이 에이전트와 동일한 기질(substrate)을 공유하지 않기 때문입니다. Tier 3는 불가능합니다. 한 모델이 다른 모델의 멀티 턴 추론을 판단하는 것은 순환 논리(circular)입니다. 판사와 피판단자가 동일한 실패 사전 확률(failure priors)을 공유하므로, 독립적인 정답(ground truth)이 존재하지 않기 때문입니다. 판사는 진정으로 주관적인 세션의 끝부분("상황이 악화되는 동안 어조가 적절했는가?")을 위해 오프라인에서 명확하게 의견으로 라벨링하여 남겨두어야 합니다.

캡처하지 않은 궤적은 확인할 수 없습니다

여기에 운영상의 함정이 있습니다. 위의 모든 Tier 1/2 세션 검사에는 트레이스(trace), 즉 해결된 입력값, 약속된 값, 각 단계에서의 도구 출력값(tool outputs)이 필요합니다. 에이전트가 작성한 요약본이 아니라, 실제 시퀀스(sequence)가 필요합니다.

이것이 바로 두 부분이 하나의 워크플로우 (workflow)로 함께 제공되어야 하는 이유입니다. AgentLens는 트레이스 (trace)를 캡처합니다. 즉, 모든 모델 및 도구 단계, 해결된 입력값 (resolved inputs), 가공되지 않은 출력값 (raw outputs), 그리고 턴 (turn)마다 실제로 발생한 일에 대해 에이전트가 작성할 수 없는 위조 불가능한 기록을 남깁니다. agent-eval은 위에서 언급한 티어 (tier) 교리에 따라 해당 트레이스를 바탕으로 점수를 매기고 게이트 (gate) 역할을 수행합니다. 평가는 실행되는 트레이스만큼만 신뢰할 수 있으며, 트레이스는 무언가가 그것을 평가할 때만 유용합니다. 평가 없는 트레이스는 디버깅 로그 (debugging log)에 불과하며, 트레이스 없는 평가는 추측하는 판사와 같습니다.

다음은 모델 호출이 전혀 필요 없는, 확정된 값에 대한 모순 탐지(contradiction detection)를 수행하는 티어 1 (Tier 1) 세션 게이트 (session gate) 예시입니다:

import { z } from "zod";

const RefundCommitment = z.object({
...

어떤 판사(judge)도 그것을 점수 매기지 못했습니다. 그것은 에이전트가 작성할 수 없는 트레이스 데이터 (trace data)에 대한 차이(diff)이며, 6개의 통과된 턴별 평가 (per-turn evals)가 그냥 지나쳐 버린 정확한 6번째 턴의 버그를 잡아냅니다.

80%를 출시하라

다회차 대화의 일관성 (multi-turn coherence) 문제를 해결하기 위해 똑똑한 판사 (judge)를 투입하려는 것이 본능적인 반응입니다. 이를 저항하십시오. 대부분의 세션 실패, 제약 조건 누락, 모순, 반복된 답변, 답변되지 않은 질문 등은 궤적 (trajectory)에 대해 티어 1+2 단계에서 결정론적 (deterministically)으로 포착되며, 비용은 약 0달러에 가깝고, 잘못된 턴이 실행되기 전에 차단할 수 있을 만큼 충분히 빠릅니다. 그것이 바로 80%입니다.

모델을 판사로 사용하는 것은 주관적인 나머지 20% 영역, 즉 톤 (tone), 공감 (empathy), 에스컬레이션 (escalation)이 적절히 처리되었다고 '느껴지는지' 여부 등을 위해 남겨두십시오. 이는 오프라인에서, 사용량에 따라 비용이 발생하며, 증거가 아닌 의견 (opinion)으로 라벨링되어야 합니다.

문장이 아니라 세션을 채점하십시오. AgentLens로 궤적 (trajectory)을 캡처하고, agent-eval로 게이트 (gate)를 설정하십시오. 그리고 6번째 턴에서 무너져 버린 대화를 수많은 통과된 턴별 체크 (per-turn checks) 결과가 인증하게 두지 마십시오.