본문으로 건너뛰기

AI 에이전트 평가하기

고급
What you'll learn
  • 에이전트 평가가 프롬프트 평가와 왜 다른지 이해하기 — 최종 답변뿐 아니라 궤적이 중요하다
  • 20–100개의 실제 사례로 명확한 통과 기준을 갖춘 골든 세트 구축하기
  • 네 가지 계층 점수화: 도구 호출 정확성, 궤적 품질, 작업 성공, 프로덕션 드리프트
  • LLM-as-judge를 안전하게 사용하기: 루브릭 우선, 사람과의 보정, 판정 스팟체크
  • CI에서 실행되어 나쁜 변경이 사용자에게 도달하기 전에 실패시키는 평가 배포하기

에이전트 평가는 "프롬프트가 올바른 단어를 반환했는가?"보다 더 어려운 질문에 답합니다. 루프 안에서 실행되는 모델이 올바른 도구를 올바른 순서로, 올바른 인자와 함께 선택하여, 올바른 결과에 도달했는가 — 그리고 예산과 안전 한계 내에 머물렀는가?

이 단계를 건너뛰면 시스템 프롬프트를 조정할 때마다 조용히 퇴보하는 "도움이 되는" 에이전트를 배포하게 될 것입니다.

에이전트가 자체 평가가 필요한 이유​

단일 프롬프트 평가는 하나의 입력 → 하나의 출력을 점수화합니다. 에이전트는 궤적을 생성합니다: 여러 턴에 걸친 추론 체인, 도구 호출, 중간 관찰, 그리고 수정. 이를 어렵게 만드는 두 가지 실패 모드가 있습니다:

  • 올바른 답, 잘못된 경로. 낭비적인 루프, 안전하지 않은 조치, 또는 운 좋은 추측 후에 에이전트가 올바른 출력에 우연히 도달합니다. 최종 답변만 보는 평가는 이를 통과로 표시하지만, 프로덕션에서는 그렇지 않습니다.
  • 잘못된 답, 그럴듯한 경로. 모든 단계가 개별적으로는 합리적으로 보이지만, 에이전트가 도구를 잘못 사용했거나, 제약을 무시했거나, 중간 사실을 환각했습니다. 응답만이 아니라 추적을 봐야 합니다.

네 가지 평가 계층​

값비싼 채점기를 기다리지 않고 나쁜 변경이 빠르게 실패하도록 가장 저렴한 것부터 계층화하세요.

Guided walkthrough1 of 4
  1. 예상되는 각 단계에 대해 도구 이름이 일치하는지, 필수 매개변수가 존재하는지, 타입이 유효한지 확인합니다. 순수 코드, 밀리초, 모델 불필요. 다른 어떤 것이 실행되기 전에 'write_file을 호출했어야 하는데 search를 호출한' 경우를 잡아냅니다.

가치를 예측하는 지표​

모든 지표가 대시보드에 속하는 것은 아닙니다. 2026년에 배포 결정을 이끄는 다섯 가지는 다음과 같습니다:

지표측정 대상중요한 이유
작업 성공률에이전트가 올바르게 완료한 골든 세트 사례의 %헤드라인. 나머지는 모두 진단용.
성공 작업당 비용$ / 통과 사례 (입력 + 출력 토큰, 도구 비용)10배 비용으로 성공하는 것은 퇴보.
지연 시간 (p50 / p95)작업당 실제 시간, 꼬리 포함p95는 실제 사용자가 느끼는 것 — 평균은 거짓말.
도구 호출 정확도이름 + 인자가 올바른 예상 도구 호출의 %궤적 품질 예측; 계산 비용 저렴.
개입률프로덕션에서 사람의 인수가 필요한 작업의 %자율성 숫자. 상승 = 신뢰 하락.

함께 추적하세요 — 하나만 움직이고 나머지는 그대로면 보통 소음이 아니라 선행 신호입니다.

골든 세트 구축하기​

Guided walkthrough1 of 5
  1. 실제 사용에서 20–100개의 작업을 가져옵니다(로그, 지원 티켓, 사용자 요청). 자주 발생하는 쉬운 경로, 까다로운 중간, 그리고 이미 당신을 물었던 엣지 케이스를 포함합니다.

LLM-as-judge — 저렴하고, 빠르지만, 보정하세요​

모호한 출력을 수동으로 채점하는 것은 확장되지 않습니다. 명시적 루브릭에 따라 읽는 유능한 모델은 확장됩니다 — Anthropic 자체 평가 방법론 가이드는 톤, 충실성, 유용성, 안전에 대해 이 패턴을 권장합니다.

판정자에게는 잘 문서화된 편향이 있습니다: 더 긴 답변, 먼저 표시된 옵션, 자신의 표현을 반영하는 출력을 선호합니다. 세 가지 습관이 그들을 정직하게 유지합니다:

  • 바이브가 아닌 루브릭. "유용성을 1–5로 평가"는 쓸모없습니다. 스케일의 모든 점을 관찰 가능한 행동에 고정하세요.
  • 사람이 라벨링한 샘플로 보정. 사람이 30–50개 사례를 채점하게 하고; 판정자 대 사람 일치도를 측정합니다(Cohen's κ ≥ 0.6 목표). 불일치하면 루브릭을 강화하세요.
  • 판정자로 다른 모델 사용. 출력을 생성한 것과 같은 모델로 채점하면 양방향으로 편향이 새어 나갑니다.
  • 매주 판정 스팟체크. 무작위 판정자 점수 10개와 그 근거를 읽으세요. 드리프트를 잡는 가장 저렴한 방법입니다.

LLM-as-judge 루브릭 템플릿

You are grading an AI assistant's response against a rubric. Be strict. Cite exact evidence from the response.

<task>{task}</task>
<response>{response}</response>

Rubric (rate 1–5 per dimension):
- Task completion: 1 = ignored task; 3 = partial; 5 = fully done, no gaps.
- Faithfulness: 1 = contains false claims; 3 = mostly grounded, one soft claim; 5 = every claim traceable to input/tools.
- Efficiency: 1 = wandered/looped; 3 = extra steps; 5 = minimum viable path.

Output JSON only:
{"task_completion": N, "faithfulness": N, "efficiency": N, "evidence": "<quote>", "verdict": "pass"|"fail"}

궤적 검토 프롬프트 (계층 2)

You are auditing an AI agent's tool-call trajectory. The goal was: {goal}
Expected minimum steps: {n_min}

<trajectory>
{list of tool_name(args) -> result, in order}
</trajectory>

Answer in JSON:
{"steps_taken": N, "wasted_steps": N, "wrong_tool_calls": [<indices>], "unsafe_actions": [<indices>], "verdict": "pass"|"fail", "reason": "<one sentence>"}

적대적 사례 생성기 (세트 성장)

Generate 5 new eval cases that are likely to break an agent whose current failures cluster around: {failure_pattern}.

For each case give: input, expected output OR pass criterion, ideal tool sequence, and why this case is hard.

Return YAML.

CI 게이트: 나쁜 변경이 배포되기 전에 실패시키기​

평가는 자동으로 퇴보를 차단할 때만 값을 합니다. 모든 프롬프트 / 모델 / 도구 변경에 대한 체크로 CI에 연결하세요:

# tests/eval_gate.py — runs on every PR
import json, sys
from anthropic import Anthropic
from my_agent import run_agent

client = Anthropic()
golden = json.load(open("evals/golden.v3.json"))

results = []
for case in golden:
    trace = run_agent(case["input"])
    layer1 = tool_calls_match(trace, case["expected_tools"])   # deterministic
    layer3 = judge(client, case, trace.final_output)           # LLM rubric
    results.append({"id": case["id"], "layer1": layer1, "layer3": layer3["verdict"]})

pass_rate = sum(r["layer3"] == "pass" for r in results) / len(results)
tool_acc  = sum(r["layer1"] for r in results) / len(results)

# Gates — tighten over time
assert pass_rate >= 0.85, f"Task success dropped to {pass_rate:.0%}"
assert tool_acc  >= 0.90, f"Tool-call accuracy dropped to {tool_acc:.0%}"
print(f"PASS: task={pass_rate:.0%} tools={tool_acc:.0%}")

실행별 점수를 저장하여 추세를 차트로 그릴 수 있도록 하세요. 병합 사이 3점 이상의 하락은 소음이 아니라 실제 퇴보입니다.

평가를 저조하게 만드는 안티패턴
  • 최종 답변만 판정 — 모든 궤적 버그를 놓칩니다. 계층 1과 2도 점수화하세요.
  • 정적 골든 세트 — 모든 프로덕션 실패와 함께 성장하지 않으면 프로덕션을 예측하는 것을 멈춥니다. 매월 시간을 예산에 편성하세요.
  • 에이전트와 판정자로 같은 모델 — 양방향 편향. 채점을 위해 다른 모델로 교체하세요.
  • 게이트에 비용 또는 지연 시간 없음 — 도구 호출 8개를 추가하는 프롬프트 조정이 청구서를 10배로 하면서 평가를 '통과'할 수 있습니다.
  • 바이브 전용 채점 — '더 나은 느낌'은 지표가 아닙니다. 두 숫자를 비교할 수 없으면 자신 있게 배포할 수 없습니다.
Key takeaways
  • 에이전트는 답변이 아닌 궤적을 생성합니다 — 결과뿐 아니라 경로를 평가하세요
  • 가장 저렴한 것부터 계층화: 도구 호출 정확성 → 궤적 품질 → 작업 성공 → 프로덕션 드리프트
  • 배포 결정을 이끄는 다섯 가지 지표: 작업 성공률, 성공당 비용, p50/p95 지연 시간, 도구 호출 정확도, 개입률
  • LLM-as-judge는 확장되지만, 명시적 루브릭, 다른 모델, 사람 라벨 대비 보정이 있어야만 가능합니다
  • 프로덕션 실패로부터 성장하지 않는 골든 세트는 프로덕션을 예측하는 것을 멈춥니다 — 매월 성장시키세요
  • 평가를 하드 게이트로 CI에 연결하세요 — 사용자보다 먼저 퇴보를 잡는 체크

자가 점검​

자가 점검

0/4
  1. 에이전트가 최종 답변 평가만이 아닌 궤적 평가가 필요한 이유는?
  2. 평가를 계층화하고 있습니다. 가장 저렴한 것부터 가장 비싼 순서로 올바른 것은?
  3. LLM-as-judge를 시간이 지나도 신뢰할 수 있도록 실제로 유지하는 습관의 쌍은?
  4. CI 게이트가 작업 성공률을 통과했지만 지연 시간과 작업당 비용이 두 배가 되었습니다. 올바른 판단은?
Enter 또는 스페이스 키를 눌러 카드를 뒤집습니다. 좌우 화살표 키로 카드를 이동할 수 있습니다.용어가 표시되었습니다.
1 / 7

다음​