[번역·요약] Anthropic이 정리한 AI 에이전트 평가의 기본 구조

2026-08-31

이 글은 Anthropic Engineering의 Demystifying evals for AI agents를 한국어로 읽기 쉽게 재구성한 번역·요약 및 해설이다. 원문 전체의 직역본이 아니며, 세부 사례와 정확한 표현은 원문에서 확인할 수 있다.

원문 읽기 · 에이전트 평가 시리즈 허브

Introduction: 왜 agent eval이 필요한가

좋은 평가는 agent의 품질을 하나의 점수로 증명하는 장치가 아니다. 변경된 행동을 사용자에게 노출하기 전에 발견하고, 운영에서 찾은 실패가 다시 반복되지 않도록 제품의 기억으로 남기는 개발 feedback 장치다. 평가 없이 문제를 운영에서 발견하고, 원인을 추측해 고친 뒤, 다른 회귀를 다시 운영에서 발견하는 반응형 loop에서 벗어나게 한다.

Agent 평가는 일반적인 single-turn 응답 평가보다 어렵다. Agent는 여러 turn 동안 tool을 호출하고 environment state를 바꾸며, 중간 결과를 관찰한 뒤 다음 행동을 조정한다. Agent를 유용하게 만드는 자율성, 지능과 유연성이 동시에 평가의 재현성을 어렵게 만든다.

따라서 agent evaluation은 마지막 응답만 비교하는 문제가 아니다. 어떤 environment에서 무엇을 관찰했고, 어떤 행동을 했으며, 실제로 어떤 상태를 만들었는지를 함께 기록하고 판정해야 한다. 실패 사례와 성공 조건, grader가 누적될수록 이 평가 자산의 가치는 agent lifecycle 전체에 걸쳐 커진다.

이 글이 좋은 이유

Agent evaluation을 이야기하면 benchmark 점수, LLM judge, production monitoring과 simulator가 한꺼번에 등장한다. Anthropic의 글은 이들을 바로 framework 비교로 가져가지 않고, 먼저 평가를 구성하는 기본 단위를 정의한다.

그다음 좋은 task와 grader를 만드는 법, 비결정적인 agent를 반복 측정하는 법, evaluation suite를 장기 운영하는 법으로 범위를 넓힌다. 특정 도구 사용법보다 무엇을 평가한다고 부를 것인지 공통 언어부터 맞춘다는 점이 특히 유용하다.

The structure of an evaluation

Evaluation은 AI system에 입력을 주고, 그 출력에 grading logic을 적용해 성공 여부를 측정하는 test다. 원문은 그중에서도 실제 사용자 없이 개발 과정에서 반복 실행할 수 있는 automated eval을 중심으로 다룬다. Production monitoring과 A/B test, 사용자 feedback은 자동 평가가 놓치는 실제 사용 분포를 보완하는 별도 신호다.

Single-turn에서 agent evaluation으로

Single-turn evaluation은 prompt에 대한 response를 grading logic으로 판정하는 비교적 단순한 구조다. 반면 agent evaluation은 task와 tool뿐 아니라 실행 가능한 environment를 제공하고, 여러 turn의 agent loop가 environment를 어떻게 바꾸었는지까지 검증한다.

Single-turn evaluation과 agent evaluation의 구조 비교

Single-turn evaluation과 agent evaluation의 구조 비교. 출처: Anthropic, Demystifying evals for AI agents.

Agent는 tool을 사용하며 environment state를 바꾸고, 중간 결과에 적응해 다음 행동을 선택한다. 앞선 단계의 작은 오류가 이후 판단에 전파될 수 있기 때문에 마지막 response만으로는 실패 원인을 설명하기 어렵다. Agent evaluation의 핵심 산출물은 response 하나가 아니라 실행 과정 전체와 마지막 environment state다.

정상적인 해결 경로도 하나로 고정되지 않는다. Agent가 정적 reference에 없는 더 나은 방법을 찾아도 rigid한 grader는 이를 실패로 판정할 수 있다. 따라서 agent의 실패와 evaluation specification의 한계를 구분하려면 transcript와 outcome을 함께 살펴야 한다.

평가를 구성하는 기본 단위

원문 용어	한국어로 풀어쓴 의미
Task / problem / test case	입력과 성공 조건이 정의된 하나의 평가 문제
Trial	같은 task를 한 번 실행한 시도. 출력 변동성을 보기 위해 반복할 수 있다.
Grader	agent 행동이나 결과의 특정 측면을 판정하는 로직
Transcript / trace / trajectory	model output, tool call과 중간 상호작용을 포함한 trial 전체 기록
Outcome	trial이 끝났을 때 environment에 남은 최종 상태
Evaluation harness	task 실행, 기록, 채점과 집계를 담당하는 평가 인프라
Agent harness / scaffold	model이 tool을 호출하고 행동하도록 입력과 실행을 orchestration하는 시스템
Evaluation suite	특정 capability나 behavior를 측정하기 위해 묶은 task 집합

여기서 중요한 구분은 evaluation harness와 agent harness다. Evaluation harness는 평가를 실행하는 골격이고, agent harness는 model을 실제 agent로 동작하게 만드는 골격이다. “Agent 성능”을 측정할 때는 model만이 아니라 agent harness의 prompt, tool orchestration과 제약도 함께 평가된다.

Agent evaluation을 구성하는 evaluation harness, suite, task, trial, outcome과 grader

Agent evaluation의 구성 요소. 출처: Anthropic, Demystifying evals for AI agents.

원문 그림의 구조를 풀어쓰면 다음과 같다.

Evaluation harness는 전체 평가를 실행하는 인프라다. Evaluation suite를 실행하고 agent harness와 상호작용하며, outcome과 trajectory를 grader에 전달한다.
Evaluation suite는 공통된 capability나 behavior를 측정하는 여러 task의 집합이다.
Task는 입력, 성공 조건, grader와 추적할 metric으로 구성된다.
Trial은 하나의 task를 한 번 실행한 시도이고, trajectory는 그 실행에서 발생한 message, tool call, reasoning 등 전체 기록이다.
Outcome은 trial이 끝난 뒤 environment에 남은 최종 상태다.
Grader는 trajectory와 outcome을 바탕으로 agent performance의 여러 측면을 점수화한다.
Agent harness는 model이 입력을 처리하고 tool을 호출해 결과를 반환하도록 만든다. 따라서 agent 평가는 model과 agent harness가 함께 동작한 결과를 측정한다.

Transcript와 outcome은 같은 것이 아니다

Agent가 최종 응답으로 성공했다고 말해도 실제 environment state가 바뀌지 않았다면 outcome은 실패다. 반대로 기대한 결과를 만들었더라도 비효율적인 tool loop나 정책 위반이 있었다면 outcome만으로는 문제를 놓친다.

Outcome grader는 최종 파일, database state, test 통과와 실제 부작용을 확인한다.
Transcript grader는 tool 사용 순서, 금지 행동, turn 수와 상호작용 품질을 확인한다.

정상 경로가 여러 개인 task에서는 하나의 trajectory를 정답으로 강제하기보다 outcome을 우선 판정한다. 다만 안전 정책이나 반드시 거쳐야 하는 확인 단계처럼 경로 자체가 계약이라면 transcript도 명시적으로 채점한다.

Why build evaluations?

초기 agent 개발은 manual test, dogfooding과 팀의 직관만으로도 빠르게 진전될 수 있다. 그러나 사용자가 늘고 변경이 누적되면 “agent가 전보다 나빠진 것 같다”는 보고를 재현하고 검증하기 어려워진다. Eval이 없으면 문제 제보를 기다리고, 수동으로 재현하고, 한 문제를 고친 뒤 다른 회귀가 없기를 바라는 반응형 개발에 머문다.

Eval은 초기에는 성공의 의미를 명시하는 specification이고, 운영 이후에는 이미 확보한 품질을 지키는 regression safety net이다. 같은 요구사항을 읽은 구성원들이 edge case를 다르게 해석하는 문제도 task와 grader를 작성하는 과정에서 드러난다.

원문에 소개된 팀들은 서로 다른 시점에 eval을 도입했다.

사례	Eval이 발전한 방식
Claude Code	내부·외부 feedback 중심의 빠른 반복에서 시작해 간결성, 파일 수정과 더 복잡한 behavior를 평가하는 suite로 확장했다.
Descript	편집 결과의 안전성, 요청 이행과 품질을 나누어 정의하고 manual grading에서 LLM grader와 정기적인 human calibration으로 발전시켰다. Quality benchmark와 regression suite도 분리했다.
Bolt	제품이 널리 사용된 뒤 eval을 구축하고 static analysis, browser agent와 LLM judge를 서로 다른 판정 문제에 사용했다.

평가 자산은 새 model을 도입할 때도 영향을 준다. 고정된 task bank가 있으면 model, prompt와 agent harness 변경을 같은 조건에서 비교할 수 있고 latency, token usage, task당 비용과 error rate의 baseline도 함께 추적할 수 있다. Product team이 성공 조건을 task와 metric으로 표현하면 research team과의 공통 언어도 생긴다. 구축 비용은 즉시 보이지만 이런 이점은 시간이 흐를수록 누적된다.

How to evaluate AI agents

Coding, conversational, research와 computer-use agent는 서로 다른 결과를 만들지만 평가 설계의 공통 원리는 같다. Task를 명확히 정의하고, 실제 행동이 일어날 environment를 제공하며, transcript와 outcome의 성격에 맞는 grader를 조합한다.

Types of graders for agents

원문은 grader를 code-based, model-based와 human grader로 나눈다.

Code-based graders

적용 방법	강점	한계
Exact·regex·fuzzy string match Binary test Static analysis Outcome·tool call 검증 Turn·token 등 transcript 분석	빠르고 저렴하다. 판정이 객관적이고 재현 가능하다. 실패 조건을 추적하고 debug하기 쉽다.	정상적인 변형도 pattern과 다르면 실패시킬 수 있다. 뉘앙스와 주관적 품질을 다루기 어렵다.

Model-based graders

적용 방법	강점	한계
Rubric 기반 채점 자연어 assertion Pairwise comparison Reference 기반 평가 여러 judge의 합의	열린 형태의 결과에 유연하다. 대량 평가로 확장할 수 있다. 자연어의 뉘앙스와 복합 조건을 다룰 수 있다.	판정 자체가 비결정적이다. Code grader보다 비용이 크다. Human label과의 calibration이 필요하다.

Human graders

적용 방법	강점	한계
Domain expert review Crowdsourced judgment 표본 spot check A/B test 평가자 간 합의 측정	복잡하고 주관적인 문제의 기준점이 된다. 실제 전문 사용자의 판단을 반영한다. Model grader를 calibration할 수 있다.	비용과 시간이 많이 든다. 대규모 반복 실행이 어렵다. 전문가 확보와 평가자 간 일관성 관리가 필요하다.

하나의 grader가 모든 품질을 대표하지 않는다. 상담 agent라면 문제 해결 여부는 state check로, turn 제한은 transcript constraint로, 어조는 model 또는 human rubric으로 나눌 수 있다. Grader를 합칠 때도 모든 점수를 평균내기보다 task에 맞춰 weighted score, 모든 조건을 통과해야 하는 binary gate 또는 두 방식을 섞은 hybrid를 선택한다.

Capability vs. regression evals

Capability eval은 현재 agent가 얼마나 어려운 문제까지 풀 수 있는지를 묻는다. 개선할 목표를 제공하려면 아직 자주 실패하는 어려운 task가 필요하다.
Regression eval은 이미 가능했던 행동이 변경 이후에도 유지되는지를 묻는다. 지속적으로 실행하며 거의 모든 trial이 통과하는 상태를 기대한다.

점수가 포화된 capability task는 버리는 것이 아니라 regression suite로 승격할 수 있다. 그 뒤 더 어려운 task를 capability suite에 추가하면 “할 수 있는가”와 “계속 안정적으로 하는가”를 분리해 볼 수 있다.

Evaluating coding agents

Coding agent는 명확한 task, 안정적인 실행 environment와 충분한 test가 중요하다. 생성한 code가 실제로 실행되고 기존 동작을 깨뜨리지 않는지는 deterministic test로 판정하기 좋다. 여기에 static analysis, repository state와 security log 같은 outcome check를 필요한 만큼 추가할 수 있다.

Test 통과만으로 코드 품질과 상호작용까지 설명할 수는 없다. 불필요한 수정, tool 사용 방식과 사용자와의 소통은 transcript heuristic이나 명확한 rubric을 가진 model grader로 보완한다. 다만 가능한 grader를 모두 넣기보다 correctness test와 code-quality rubric에서 시작해 필요한 신호만 추가하는 편이 낫다.

Example: coding agent evaluation

원문은 접근 제어 결함을 수정하는 coding task를 예로 들어 여러 grader와 운영 metric을 한 계약에 배치한다. 아래 YAML은 그 구조를 일반화해 재구성한 것이다.

task:
  id: patch-access-control
  description: "빈 credential로 보호된 resource에 접근하지 못하게 수정한다"

graders:
  - type: deterministic_tests
    required:
      - rejects_empty_credential
      - rejects_missing_credential

  - type: llm_rubric
    rubric: rubrics/code_quality.md

  - type: static_analysis
    commands: [lint, typecheck, security_scan]

  - type: state_check
    expect:
      audit_event: access_denied

  - type: tool_calls
    required: [inspect_source, edit_source, run_tests]

tracked_metrics:
  transcript: [turns, tool_calls, total_tokens]
  latency: [time_to_first_token, time_to_completion]

이 예제는 가능한 grader의 범위를 보여주기 위해 의도적으로 많은 항목을 담는다. 실제 coding eval은 correctness를 확인하는 test와 전체 code quality rubric에서 시작하고, 필요가 확인된 state·tool·metric만 추가하는 편이 현실적이다.

Evaluating conversational agents

Conversational agent는 interaction 자체가 평가 대상이다. Ticket이 실제로 해결됐는지, 정해진 turn 안에 끝났는지, 정책을 지켰는지와 어조가 적절했는지를 서로 다른 grader로 확인한다. 여러 turn의 대화를 만들기 위해 user simulator를 사용할 수 있지만, 이 경우 simulator의 일관성과 현실성도 측정값에 영향을 준다.

Example: conversational agent evaluation

원문은 불만을 가진 사용자의 환불 요청을 처리하는 support task로 다차원 평가를 설명한다. 아래는 같은 평가 구조를 일반화한 예다.

task:
  id: resolve-return-request
  description: "사용자 확인을 거쳐 반품 요청을 처리하고 결과를 설명한다"

graders:
  - type: llm_rubric
    rubric: rubrics/interaction_quality.md
    assertions:
      - "사용자의 불편을 적절히 인지했는가"
      - "처리 결과와 다음 단계를 명확히 설명했는가"
      - "정책 조회 결과에 근거해 답했는가"

  - type: state_check
    expect:
      request_status: resolved
      return_status: accepted

  - type: tool_calls
    required: [verify_user, create_return, send_notice]

  - type: transcript
    max_turns: 10

tracked_metrics:
  transcript: [turns, tool_calls, total_tokens]
  latency: [time_to_first_token, time_to_completion]

Conversational task는 정답 문장이 하나가 아니므로 communication quality와 goal completion을 model-based grader로 평가하고, 실제 상태 변경은 deterministic state check로 분리하는 구성이 잘 맞는다.

Evaluating research agents

Research agent의 결과는 하나의 정답으로 고정하기 어렵다. “충분히 포괄적인가”, “출처가 신뢰할 만한가”, “주장이 근거에 연결되는가”는 task의 목적에 따라 달라진다. Groundedness, 핵심 사실 coverage, citation과 source quality를 각각 확인하고, 필요한 경우 domain expert나 human review로 calibration한다.

Computer-use agents

Computer-use agent는 screenshot, mouse, keyboard와 scroll을 통해 실제 GUI를 조작한다. 따라서 browser나 OS를 실제 또는 sandboxed environment에서 실행하고, 화면에 성공 메시지가 나타났는지가 아니라 backend state, file, application configuration과 UI property가 기대한 상태인지 확인해야 한다.

관찰 방식 자체도 성능에 영향을 준다. DOM 기반 상호작용은 빠르지만 token을 많이 쓸 수 있고, screenshot 기반 상호작용은 느리지만 특정 화면 task에서는 더 효율적일 수 있다. 어떤 상황에서 어떤 tool을 골랐는지까지 평가해야 하는 이유다.

How to think about non-determinism

같은 agent가 같은 task를 매번 똑같이 풀지는 않는다. Task별 성공률이 다르고, 한 eval run에서 통과한 task가 다음 run에서는 실패할 수도 있다. 그래서 한 번의 pass/fail보다 반복 trial의 분포를 봐야 한다.

pass@k는 k번 중 한 번 이상 성공할 가능성을 측정한다. 여러 후보를 만들 수 있고 그중 하나만 성공하면 되는 제품에 적합하다.
pass^k는 k번 모두 성공할 가능성을 측정한다. 매번 안정적인 행동이 중요한 사용자 대상 agent에 적합하다.

첫 trial의 성공률이 같아도 k가 증가하면 pass@k는 높아지고 pass^k는 낮아진다. 제품 요구사항이 “여러 번 중 한 번 해결”인지 “반복할 때마다 안정적으로 해결”인지가 metric 선택보다 먼저다.

pass@k와 pass^k가 trial 수에 따라 달라지는 모습

Trial 수가 늘어날 때 pass@k와 pass^k가 반대 방향으로 움직이는 모습. 출처: Anthropic, Demystifying evals for AI agents.

Going from zero to one: a roadmap to great evals

원문은 좋은 eval을 한 번에 완성하는 대신 evaluation suite 개발, harness 개발과 장기 유지보수의 세 단계로 나눈다.

Collect tasks for the initial eval dataset

지금, 일찍 시작한다. 처음부터 수백 개의 task가 필요하지 않다. 초기에는 실제 failure에서 가져온 수십 개의 명확한 task만으로도 큰 변화의 신호를 볼 수 있다.
수동으로 확인하던 사례에서 시작한다. Release 전 checklist, 자주 쓰는 workflow, bug tracker와 support 사례를 초기 dataset 후보로 삼는다.
모호하지 않은 task를 쓴다. Grader가 확인할 요구사항은 task 설명에서 이해할 수 있어야 하며, 알려진 정상 해법이 실제로 통과하는지 검증한다.
성공과 실패 사례를 균형 있게 담는다. 한 종류의 쉬운 사례나 production failure만 과대표집하지 않고 capability, 난이도와 positive·negative case를 의도적으로 구성한다.

Design the eval harness and graders

견고한 eval harness를 만든다. 각 trial을 깨끗한 상태에서 격리하고 file, cache와 resource 공유 문제가 agent failure처럼 보이지 않게 한다. 평가 환경이 실제 agent 동작과 지나치게 달라지지 않게 하는 것도 중요하다.
Grader를 신중하게 설계한다. Code, model과 human grader를 맞는 문제에 사용하고, rigid한 exact match나 모호한 rubric이 정상 답을 실패시키지 않는지 확인한다.

Maintain and use the eval long-term

Trajectory를 직접 읽는다. 점수만으로는 agent가 틀렸는지 grader가 틀렸는지 알 수 없다. Transcript와 판정 근거를 읽어 실패가 납득 가능한지 확인한다.
Capability eval의 포화를 감시한다. 거의 모두 통과하는 suite는 개선 방향을 구분하기 어렵다. 포화된 task는 regression으로 유지하고 더 어려운 failure mode를 추가한다.
장기 유지보수 대상으로 운영한다. Product, research와 domain expert가 task를 기여하게 하고, 낡거나 중복된 task와 grader를 지속적으로 정리한다.

좋은 agent evaluation을 만드는 0단계부터 8단계까지의 로드맵

Evaluation suite 개발, harness 개발과 장기 유지보수로 이어지는 로드맵. 출처: Anthropic, Demystifying evals for AI agents.

How evals fit with other methods

Automated eval은 launch 전 변경을 빠르게 비교하고 CI에서 regression을 막는 첫 방어선이다. 그러나 실제 사용 분포, 예상하지 못한 failure와 주관적 품질을 모두 대표하지는 못한다.

원문 페이지의 큰 overview는 별도 이미지가 아니라 다음 비교표로 구성되어 있다.

방법	강점	한계
Automated eval	반복이 빠르고 재현 가능하다. 실제 사용자에게 영향을 주지 않는다. 매 commit에서 많은 scenario를 실행할 수 있다.	초기 구축과 지속적인 유지보수가 필요하다. 실제 사용 분포와 다르면 잘못된 확신을 줄 수 있다.
Production monitoring	실제 사용자 behavior와 대규모 ground truth를 관찰한다. Synthetic eval이 놓친 문제를 찾는다.	문제가 사용자에게 도달한 뒤 발견하는 반응형 신호다. Noise가 크고 정답 label이 없는 경우가 많다.
A/B testing	실제 retention과 task completion 같은 사용자 결과를 비교한다. 교란 요인을 통제하며 확장할 수 있다.	통계적 유의성까지 시간이 걸리고 충분한 traffic이 필요하다. 배포한 변경만 비교하며 원인을 직접 설명하기 어렵다.
User feedback	예상하지 못한 문제와 실제 사례를 제공한다. Product goal과 가까운 신호를 얻는다.	드물고 self-selection bias가 있다. 심각한 문제에 치우치며 실패 이유가 생략되기 쉽다.
Manual transcript review	미묘한 failure를 찾고 좋은 behavior에 대한 팀의 직관을 만든다. 자동 grader가 놓친 맥락을 확인한다.	시간이 많이 들고 확장하기 어렵다. Coverage와 reviewer 일관성이 낮고 주로 정성적 신호를 준다.
Systematic human study	여러 평가자의 구조화된 판단으로 주관적 문제의 기준점을 만든다. Model grader 개선에 사용할 수 있다.	비용이 크고 turnaround가 느리다. 평가자 불일치 조정과 domain expert가 필요하다.

여러 평가 신호가 서로의 빈틈을 보완하는 Swiss Cheese Model

어떤 평가 계층도 모든 문제를 잡지 못하므로 여러 방법을 결합해야 한다는 Swiss Cheese Model. 출처: Anthropic, Demystifying evals for AI agents.

Offline eval, production signal과 human review는 하나의 점수로 합칠 대상이 아니라 서로 다른 빈틈을 막는 평가 계층이다. 빠른 개발 feedback은 automated eval이, 실제 분포는 production monitoring이, 주관적 판단과 grader calibration은 human review가 담당한다.

Conclusion

Eval이 없는 팀은 한 failure를 고치면서 다른 회귀를 만들고, 실제 성능 저하와 실행 노이즈를 구분하기 어려운 반응형 loop에 빠지기 쉽다. 반대로 failure를 task로 축적하고 성공 조건을 명확하게 유지하는 팀은 변경을 더 빠르게 검증할 수 있다.

원문의 실천 원칙은 단순하다. 완벽한 suite를 기다리지 말고 일찍 시작한다. 실제 failure에서 현실적인 task를 모으고, 성공 조건과 grader를 명확히 설계한다. Model이 구분될 만큼 어려운 문제를 유지하고, 점수뿐 아니라 transcript를 읽으며 evaluation 자체의 signal-to-noise도 계속 개선한다.

Agent evaluation은 아직 빠르게 변하고 있다. Task가 더 길어지고 multi-agent collaboration과 주관적 작업이 늘어날수록 현재 방법도 바뀌어야 한다. 평가 체계 역시 완성된 test set이 아니라 agent와 함께 진화하는 product component다.

Appendix: Eval frameworks

원문 부록은 framework 선택에 하나의 정답이 없다고 정리한다. Agent 유형, 기존 stack, offline evaluation과 production observability 중 필요한 범위에 따라 선택이 달라진다.

원문에 소개된 도구	강조하는 범위
Harbor	Containerized environment에서 task와 grader를 표준 형식으로 정의하고 trial을 대규모로 실행
Braintrust	Offline evaluation, production observability와 experiment tracking의 결합
LangSmith	LangChain 생태계와 결합된 tracing, dataset, offline·online evaluation
Langfuse	Self-hosted open-source 방식의 tracing과 evaluation, data residency 요구 대응
Phoenix / Arize AX	Open-source tracing·debugging·evaluation과 이를 확장한 관리형 monitoring

여러 도구를 조합하거나 작은 script에서 시작하는 팀도 있다. Framework는 실행과 표준화를 가속하지만 평가 품질은 결국 task와 grader의 품질을 넘을 수 없다. Workflow에 맞는 도구를 빠르게 선택한 뒤 test case와 grader를 반복 개선하는 데 더 많은 에너지를 쓰라는 것이 원문의 결론이다.

이 시리즈의 고민과 연결하면

이 글은 “최신 업계가 TC 기반을 버렸는가?”라는 질문에 비교적 명확한 답을 준다.

Task 또는 test case는 여전히 평가의 기본 단위다. 달라진 것은 그 task를 단순 input-output fixture가 아니라 environment, agent harness, 여러 grader와 반복 trial을 가진 실행 가능한 문제로 본다는 점이다.

따라서 다음 구조가 자연스럽다.

Production trace와 사용자 feedback에서 중요한 failure candidate를 찾는다.
알려진 회귀는 작고 결정적인 replay TC로 고정한다.
상태 변화와 긴 상호작용이 중요한 task는 sandbox나 simulator에서 실행한다.
Outcome과 transcript를 서로 다른 grader로 판정한다.
여러 trial과 production monitoring으로 비결정성과 실제 분포를 보완한다.

TC 기반 설계의 반성 지점은 TC를 사용했다는 사실이 아니다. 모든 위험을 하나의 canonical trajectory와 fixture로 표현하면서 curation과 유지보수 비용이 커졌는지, outcome과 environment fidelity를 충분히 다루었는지를 돌아보는 편이 더 정확하다.

원문

Anthropic Engineering — Demystifying evals for AI agents