당신의 에이전트는 올바른 도구를 선택했습니다. 사용자가 환불을 요청했을 때 refund_order로 라우팅했습니다. 당신의 평가(eval) 스위트는 초록색(통과)으로 표시되었습니다. 하지만 그 직후, 인자 추출(argument extraction) 과정에서 실수가 발생하여 ID를 0으로 기본 설정하는 바람에 주문 번호 #0에 대해 4,200달러의 환불을 실행했습니다.

이것은 아무도 측정하지 않는 실패 모드입니다: 올바른 도구, 잘못된 인자 (right tool, wrong arguments). 대부분의 평가(eval) 설정은 에이전트가 올바른 동작을 _선택했는지_를 확인하며, 인자를 검증하는 작업은 번거로워 보이기 때문에 그냥 통과시켜 버립니다. 바로 그 간극에서 실제 돈이 새어나갑니다.

도구 선택은 쉬운 20%에 불과하다

올바른 도구로 라우팅하는 것은 분류(classification) 문제이며, 현대의 모델들은 이를 잘 수행합니다. 어렵고 위험한 부분은 바로 인자 (arguments) 입니다. 즉, 에이전트가 복잡한 문맥(context)으로부터 합성해낸 해결된 ID, 금액, 필터 및 경로들입니다. 이것들은 에이전트가 작성한 구조화된 주장(structured claims)이며, 지루하면서도 비용이 많이 드는 방식으로 실패합니다:

• 잘못된 품목(line item)에서 추출된 환불 금액.

• 존재하지 않지만 그럴싸해 보이는 디렉토리에서 환각(hallucination)된 파일 경로.

• 시간대(timezone) 차이로 인해 잘못 설정된 날짜 필터가

• Tier 1 — 에이전트가 위조할 수 없는 증거. 인자가 유효한 JSON으로 파싱되고, 도구의 스키마(schema)를 충족하며, 참조된 order_id가 실제로 존재하고, 금액이 주문 총액 범위 내에 있으며, 경로가 해결(resolve)되는지 확인합니다. 결정론적(Deterministic)이며, 비용은 거의 $0에 가깝고, 핫 패스(hot path)에서 실행되며, 실행 전 호출을 차단할 수 있습니다.

• Tier 2 — 에이전트가 작성하지 않은 기준(baseline)에 대한 통계적 신호. 추출된 금액이 해당 가맹점의 상식적인 분포 내에 있는지, 인자 세트가 이전 턴(turn)으로부터 실제로 변경되었는지, 해결된 엔티티(entity)의 임베딩(embedding)이 사용자 요청에 명시된 엔티티와 유사한지 확인합니다.

• Tier 3 — 판사로서의 모델 (model-as-judge). "대화 내용을 고려할 때, 이 환불이 정당해 보이는가?"라는 질문을 던집니다. 이는 하나의 신호(signal)일 뿐 결코 판결(verdict)이 아니며, 오프라인에서만 수행됩니다. 비용이 발생하고 느리며 비결정론적(non-deterministic)이므로, 결제 경로(payment path)에 비즈니스 로직이 묶여서는 안 됩니다.

실수는 Tier 3에게 Tier 1의 역할을 맡기는 것입니다. order_id: 0이 맞는지 평가하는 판사 모델은 순환 논리(circular reasoning)에 빠집니다. 판사 모델은 인자를 생성한 에이전트와 동일한 기질(substrate)을 공유하며, 귀하의 데이터베이스에 대한 독립적인 정답(ground truth)을 가지고 있지 않기 때문입니다. 주문 0이 존재하는지 여부는 의견의 문제가 아닙니다. 데이터베이스에 쿼리(query)하십시오.

도구가 실행되기 전에 인자를 검증(Gate)하라

도구 호출(tool calls)을 위한 Tier 1은 모델이 제안한 호출과 실제 실행 사이에 위치하는 검증 계층(validation layer)입니다. 제안된 환불에 대한 예시는 다음과 같습니다:

import { z } from "zod";

const RefundArgs = z.object({
...

여기에서의 모든 확인 작업은 의견이 아닌 증거(proof) 또는 통계(statistics)입니다. 스키마, 존재 여부, 범위, 분포를 확인합니다. 에이전트는 order_not_found를 말로 설득하여 통과할 수 없습니다. 왜냐하면 이 검증은 에이전트가 작성할 수 없는 소스를 참조하기 때문입니다. 이것이 독립성 축(independence axis)의 핵심입니다. 검증 게이트(gate)는 에이전트가 판단 근거로 삼는 증거를 스스로 작성할 수 없을 때에만 가치가 있습니다.

이것이 여러분이 가장 먼저 출시하게 될 80%의 영역입니다. 잘못된 인자 (Malformed args), 환각된 ID (hallucinated IDs), 빈 결과 집합 (empty result sets), 범위를 벗어난 금액 (out-of-bounds amounts) — 실제로 새벽 2시에 당신을 깨우는 실패 사례들은 모두 실행 전, Tier 1+2 단계에서 결정론적 (deterministically)으로 포착됩니다. 주관적인 나머지 ~20% ("환불이 사회적으로 _옳은 결정_이었는가?")만이 명확하게 라벨링된 의견으로서 판사 (judge)에게 전달되는 유일한 부분입니다.

볼 수 없는 것은 검증할 수 없다

이 모든 것은 여러분이 확정된 (resolved) 인자를 가지고 있다는 것을 전제로 합니다. 즉, 모델의 출력이 파싱(parsing), 기본값 설정(defaulting), 강제 변환(coercing)된 후 도구가 실제로 전달받은 값 말입니다. 대부분의 로깅 (logging)은 사용자 프롬프트와 최종 응답만을 캡처하며, 그 사이의 과정은 아무것도 기록하지 않습니다. 주문 0에 대해 환불이 실행될 때, 여러분의 로그는 성공적인 경로 (happy path)만을 보여줍니다.

이 지점이 워크플로우의 두 절반이 맞물리는 곳입니다. AgentLens는 트레이스 (trace)를 캡처합니다: 모든 모델 단계와 도구 단계, 도구가 실제로 본 확정된 (resolved) 입력값, 그리고 에이전트가 작성하지 않은, 발생한 일을 그대로 기록한 가공되지 않은 원시 출력값 (raw outputs)까지 말입니다. agent-eval은 위의 티어 교리 (tier doctrine)를 사용하여 해당 트레이스를 바탕으로 점수를 매기고 검증 게이트 (gate)를 작동시킵니다. AgentLens는 Tier 1+2에 검증할 수 있는 실질적인 대상을 제공하며, agent-eval은 이를 호출을 차단할 수 있는 빨간색/초록색 결정으로 전환합니다.

트레이스가 없다면, 여러분의 평가 (evals)는 에이전트가 스스로에 대해 말하는 '이야기'를 채점하는 것에 불과합니다. 트레이스가 있다면, 여러분은 에이전트가 실제로 전달한 인자를 채점하게 되며, 주문 0에 대한 $4,200 환불이 승인되기 _전_에 이를 차단할 수 있습니다.

핵심 요약

에이전트가 올바른 도구를 선택했다고 해서 축하하는 것을 멈추십시오. 도구 선택은 분류 (classification)의 문제이지만, 인자 합성 (argument synthesis)은 리스크가 존재하는 지점입니다. 실행 전, 핫 패스 (hot path)에서 스키마 (schema), 존재 여부, 범위와 같이 의견이 아닌 증거로서 인자를 검증하십시오. 판사 (judge)는 진정으로 주관적인 나머지 부분(tail)을 위해서만 남겨두십시오. 그리고 확정된 (resolved) 입력을 트레이스하십시오. 기록되지 않은 것은 검증할 수 없기 때문입니다.