Agent 평가 데이터셋 만들기: 실제 작업, 궤적 로그, 회귀 테스트까지

지난주까지 일일 리포트를 잘 만들던 Agent가 모델 업그레이드 뒤에도 “겉보기에는 맞는” 최종 요약을 반환했습니다. 하지만 궤적을 보면 권한 확인과 데이터 새로고침 도구가 빠져 있습니다. 고객 지원 Agent는 최종 답변은 맞았지만 환불 도구 인자를 잘못 호출했습니다. 공개 benchmark는 이런 위험을 보지 못합니다. 사고 회고에는 이미 traceId, tool call, approvalId, state event, 사람 판단이 있는데, 다음 release 전에 반드시 실행되는 테스트로 고정되지 않은 상태입니다.

이런 회귀는 모델을 바꾸거나 demo를 한 번 더 돌린다고 막을 수 없습니다. Agent 평가 데이터셋은 실제 작업 분포와 production 실패 궤적에서 나와야 합니다. 도구 호출, 인자 형식, 상태 전이, 승인 기록, 사람 라벨을 포함하고, CI gate의 회귀 테스트로 실행되어야 합니다. 여기서는 실패 사례와 실제 시나리오에 집중합니다. 지속적으로 실행되는 eval dataset을 만들고, 매 release의 품질 경계를 지키는 방법입니다.

1. 공개 benchmark만으로 부족한 이유

1.1 공개 benchmark의 한계

공개 benchmark가 측정하는 것은 모델 능력이지, 여러분의 비즈니스 작업 품질이 아닙니다. AgentBench, WebArena 같은 평가셋은 표준 작업을 제공하지만, 팀 고유의 toolchain, 권한 모델, state machine까지 덮지는 못합니다.

예를 들어 리포트 Agent가 check_permission, refresh_data, generate_report 세 도구를 호출하고 “확인 → 새로고침 → 생성” 순서로 실행해야 한다고 해봅시다. 공개 benchmark는 이 플로우를 테스트하지 않습니다. 여러분의 tool schema와 권한 경계를 모르기 때문입니다.

공개 benchmark 점수가 좋아도 비즈니스 작업이 회귀하지 않는다는 뜻은 아닙니다. Agent 평가 데이터셋은 일반 추론 능력이 아니라 실제 작업 분포를 측정해야 합니다.

1.2 자체 데이터셋의 핵심 가치

자체 eval dataset은 공개 benchmark가 보지 못하는 위험을 잡아냅니다. 대표적인 비교는 다음과 같습니다.

시나리오	공개 benchmark	자체 eval dataset
리포트 Agent가 권한 확인을 누락	보이지 않음. 해당 도구와 권한 모델이 없음	궤적 제약 포착: check_permission을 반드시 호출
지원 Agent가 잘못된 환불 인자 사용	해당 도구와 환불 schema가 없음	기대 tool call 목록 + 인자 형식 제약
모델 업그레이드 후 상태 전이가 악화	해당 state machine이 없음	상태 궤적 assertion: 확인 → 승인 → 실행
사고 회고가 테스트로 고정되지 않음	사고 데이터가 없음	실패 사례를 negative cases에 편입

공개 benchmark는 모델 선택에 쓰고, 자체 데이터셋은 release gate를 지키는 데 씁니다. 둘은 보완 관계이며 서로 대체할 수 없습니다. Agent 평가 benchmark 비교를 이미 읽었다면 어떤 공개 평가셋이 선택에 적합한지 알고 있을 것입니다. 여기서는 자체 production 환경에서 평가 데이터를 만드는 방법에 집중합니다.

2. Agent eval dataset의 핵심 필드

2.1 필수 필드

Agent eval dataset은 사용자 입력과 기대 답변만 저장하는 목록이 아닙니다. 도구 호출 궤적, 상태 전이, 사람 판단을 기록해야 합니다. 필수 필드는 다음과 같습니다.

필드	설명	출처
input	사용자 작업 설명	Production trace / 수동 설계
expected output	기대 최종 답변	사람 annotation / golden set
expected tool calls	기대 도구 호출 목록	궤적 분석. 예: ["check_permission", "refresh_data"]
trajectory assertions	궤적 제약(필수/금지/순서)	State machine + 승인 플로우
human labels	사람 판단(정답/오답/부분 정답)	사고 회고 / 라벨링 큐

LangSmith의 Evaluation concepts는 Agent 평가가 최종 답변만 보지 말고 도구 선택, 인자 형식, 실행 궤적을 포함해야 한다고 설명합니다. OpenAI Agents SDK Tracing은 trace_id, workflow_name, span 같은 필드로 도구 호출과 상태 이벤트를 기록합니다. 하지만 이러한 원시 필드는 비식별화와 추출을 거친 뒤에야 데이터셋에 들어갈 수 있습니다.

2.2 선택 필드

업무 필요에 따라 다음 필드를 추가합니다.

필드	설명	용도
approval records	승인 기록(승인자, 시간, 결과)	권한 모델에서 승인이 필요한 도구 호출
state transitions	상태 전이 시퀀스	State machine 제약. 예: ["init", "check", "approve"]
metadata	traceId, 환경, 모델 버전	회고 위치 추적과 버전 비교

Agent 권한 모델(N157)과 사람 승인 설계(N155)를 읽었다면 approval records에는 승인 단계, 승인자, 승인 결과를 기록해야 하며, 고위험 작업이 승인을 거쳤는지 검증하는 데 쓰인다는 점을 알 수 있습니다.

2.3 비식별화와 개인정보

Production trace는 그대로 평가셋에 들어갈 수 없습니다. OpenAI Agents SDK Tracing 문서는 일부 span이 모델 입출력이나 function tool 입출력을 캡처할 수 있으므로 민감 데이터를 포함할지 설정해야 한다고 안내합니다.

반드시 비식별화할 필드: PII(이름, 이메일, 전화번호), secret(API key, 데이터베이스 비밀번호), 고객 데이터(주문 번호, 거래 금액).

남길 필드: traceId, span_id(진단용), workflow_name(분류용), 도구명, 상태명(assertion용).

비식별화 방법에는 <user_id> 같은 placeholder로 대체, 해시 처리, 삭제가 있습니다. Phoenix Running Evals on Traces 문서는 trace를 평가 입력으로 바꿀 수 있음을 보여줍니다. 그래도 label/score/rubric은 필요합니다. 완전한 원시 trace를 eval dataset에 직접 넣으면 안 됩니다.

3. Production trace에서 eval example로

3.1 데이터 수집 흐름

Production trace로 eval example을 만들려면 비식별화, 라벨링, 계층화, 저장 네 단계가 필요합니다. 한 번 하고 끝나는 작업이 아니라 지속 운영입니다.

체크리스트:

1. 모니터링 platform에서 실패 trace를 내보냅니다(Agent 모니터링과 실패 복구 참고).
2. 실패 유형으로 분류합니다: 도구 호출 오류, 인자 형식 오류, 상태 전이 오류, 최종 답변 오류.
3. 비식별화합니다: PII/secret/고객 데이터를 삭제하고 traceId, span_id, workflow_name을 남깁니다.
4. 사람 라벨을 붙입니다: 정답/오답/부분 정답 + 실패 이유.
5. 계층별로 저장합니다: golden set / negative cases / edge cases.

Phoenix datasets 문서는 examples가 production, staging, evaluations, manual에서 수집될 수 있다고 설명합니다. Production은 실제 작업 분포를 제공하고, staging의 테스트 케이스는 경계 시나리오를 보완합니다.

3.2 계층화 기준

계층	기준	용도
golden set	100% 정답 + 고빈도 작업	release gate 필수 통과, pass rate 기준
negative cases	대표 실패 패턴	회귀 테스트 알림, 같은 오류 재발 방지
edge cases	long-tail / 경계 시나리오	보조 커버리지, 필요 시 편입

라벨링 차원(LLM-as-judge rubric 대응): 도구 선택 정확성, 인자 형식 정확성, 실행 순서 정확성, 최종 답변 품질, 사람 라벨과의 일치도.

OpenAI Evaluation best practices는 typical, edge, adversarial cases를 포함한 테스트 데이터와 human expert labellers 사용을 권장합니다. 여기의 계층화도 그 방향과 맞지만, 평가셋의 목적이 모든 시나리오를 덮는 것이 아니라 release gate를 지키는 것이므로 고빈도 작업과 대표 실패 패턴을 더 강조합니다.

4. Trajectory assertions 작성법

4.1 궤적 제약 유형

Trajectory assertions는 Agent가 지켜야 하는 도구 호출, 인자 형식, 상태 전이, 승인 규칙을 정의합니다. 대표 제약 유형은 다섯 가지입니다.

제약 유형	예시	실패 조건
필수 도구 목록	["check_permission", "refresh_data", "generate_report"]	필수 도구 중 하나라도 빠짐
금지 도구 목록	["delete_user", "drop_table"]	금지 도구를 호출함
인자 형식 제약	{"refund_amount": "number", "user_id": "uuid"}	인자 타입이 틀림
상태 전이 순서	["init", "check", "approve", "execute"]	상태가 건너뛰거나 반복됨
승인 단계 존재	["need_approval", "approval_granted"]	승인 이벤트가 빠짐

LangSmith Evaluation concepts는 Agent 평가에서 trajectory, tool selection, argument formatting을 평가해야 한다고 말합니다. Phoenix Running Evals on Traces 문서는 span_id로 평가 결과를 특정 실행 구간에 연결합니다. 즉 궤적 assertion은 실패 span까지 위치를 좁힐 수 있습니다.

Agent 계획 능력 평가(N158)와 state machine / prompt 경계를 읽었다면 상태 궤적 필드가 state/event/checkpoint에서 온다는 점을 알 수 있습니다. 이 필드는 상태 전이가 기대 순서와 맞는지 검증합니다.

4.2 코드 예시

다음은 일반적인 Agent 평가에 사용할 수 있는 trajectory assertions 의사 코드입니다.

# trajectory assertions 예시
def assert_trajectory_correct(result):
    # tool call 목록 추출
    tools_called = [call.tool for call in result.tool_calls]

    # 필수 도구
    required_tools = ["check_permission", "refresh_data"]
    for tool in required_tools:
        assert tool in tools_called, f"Missing required tool: {tool}"

    # 금지 도구
    forbidden_tools = ["delete_user"]
    for tool in forbidden_tools:
        assert tool not in tools_called, f"Called forbidden tool: {tool}"

    # 인자 형식 제약
    for call in result.tool_calls:
        if call.tool == "refund":
            assert isinstance(call.args["refund_amount"], (int, float)), "refund_amount must be number"
            assert len(call.args["user_id"]) == 36, "user_id must be uuid format"

    # 상태 전이 순서
    expected_states = ["init", "check", "approve", "execute"]
    actual_states = [event.state for event in result.state_events]
    assert actual_states == expected_states, "State transition order mismatch"

    # 승인 단계 존재
    approval_events = [e for e in result.state_events if e.type == "approval"]
    assert len(approval_events) >= 1, "Missing approval step"

이 코드는 필수 도구, 금지 도구, 인자 형식, 상태 전이 순서, 승인 단계를 어떻게 확인하는지 보여줍니다. 실제 구현에서는 LangSmith의 trajectory assertion이나 Phoenix의 trace eval을 쓸 수 있지만 핵심 로직은 같습니다.

Agent 계획 능력 평가를 읽었다면 계획 궤적도 회귀 샘플이 되어 작업 분해와 자기 수정 능력을 검증할 수 있다는 점을 알 수 있습니다.

5. LLM-as-judge의 계층형 rubric

5.1 총점만으로 부족한 이유

LLM-as-judge가 총점만 반환하면 결과가 흔들리고 문제 위치를 찾기 어렵습니다. 80점은 도구 선택은 틀렸지만 답이 우연히 맞았다는 뜻일 수도 있고, 답은 틀렸지만 형식은 좋아 보였다는 뜻일 수도 있습니다. prompt, tool schema, retrieval, state machine 중 어디가 문제인지 구분할 수 없습니다.

LangSmith Evaluation concepts는 Agent의 핵심 컴포넌트에 품질 기준을 정의하라고 권장합니다. correct tool selection, proper argument formatting, trajectory입니다. 각 컴포넌트를 따로 채점해야 모델 업그레이드나 prompt 변경 후 퇴화를 빠르게 찾을 수 있습니다.

Prompt 엔지니어링 고급 실전을 읽었다면 DeepEval도 TaskCompletenessMetric 같은 계층형 지표를 강조하며, 최종 출력만 보지 않는다는 점을 알 수 있습니다.

5.2 계층형 점수표

아래 rubric은 Agent 평가를 다섯 차원으로 나누고, 각 차원을 0-2점으로 채점합니다.

차원	0점	1점	2점
도구 선택 정확성	잘못된 도구	부분적으로 정확	완전히 정확
인자 형식 정확성	타입 오류	일부 필드 형식 오류	완전히 정확
실행 순서 정확성	상태 건너뜀	순서 편차	완전히 정확
최종 답변 품질	요구를 만족하지 않음	일부 만족	완전히 만족
사람 라벨과의 일치도	전문가 판단과 모순	일부 일치	높게 일치

LangSmith나 Phoenix에서 사용할 수 있는 rubric 설정 예시입니다.

rubric:
  dimensions:
    - name: tool_selection
      weight: 0.3
      criteria:
        0: "잘못된 도구를 호출함"
        1: "일부 올바른 도구를 호출함"
        2: "도구 선택이 완전히 정확함"

    - name: argument_formatting
      weight: 0.2
      criteria:
        0: "인자 타입이 잘못됨"
        1: "일부 필드 형식이 잘못됨"
        2: "인자 형식이 완전히 정확함"

    - name: execution_order
      weight: 0.2
      criteria:
        0: "상태 전이가 건너뛰거나 반복됨"
        1: "실행 순서에 편차가 있음"
        2: "실행 순서가 완전히 정확함"

    - name: final_answer_quality
      weight: 0.2
      criteria:
        0: "사용자 요청을 만족하지 않음"
        1: "요청을 일부 만족함"
        2: "요청을 완전히 만족함"

    - name: human_alignment
      weight: 0.1
      criteria:
        0: "전문가 판단과 모순됨"
        1: "일부 일치함"
        2: "높게 일치함"

도구 선택의 가중치가 가장 높은 이유(0.3)는 Agent의 핵심이 올바른 도구를 호출하는 것이기 때문입니다. 사람 라벨과의 일치도는 가장 낮은 가중치(0.1)를 두고, LLM-as-judge가 전문가 판단과 얼마나 맞는지 보정하는 데 씁니다.

6. Release gate와 회귀 테스트

6.1 CI 연동 단계

Agent eval dataset의 가치는 CI에 연결되어 release gate가 될 때 생깁니다. 연동 단계는 다음과 같습니다.

체크리스트:

1. CI pipeline에 eval 실행 단계를 추가합니다(pytest, LangSmith offline eval, Phoenix experiments 등).
2. pass rate 기준을 설정합니다(예: 90%).
3. golden set은 전부 통과(100%)하도록 설정합니다.
4. negative cases 알림 규칙을 설정합니다. 팀에 알리되 반드시 차단하지 않을 수도 있습니다.
5. 기준 버전과 현재 버전을 비교하는 version comparison(improvement/regression)을 설정합니다.
6. gate 실행 시점을 정의합니다(PR / merge / canary).

LangSmith Evaluation concepts는 offline evaluations가 datasets의 examples를 대상으로 regression testing, unit testing, backtesting에 쓰일 수 있다고 설명합니다. Phoenix experiments 문서는 prompt, LLM, 애플리케이션 로직 변경을 비교해 improvement/regression을 판단할 수 있다고 설명합니다. DeepEval은 pytest-native eval을 내세우며, CI/CD 또는 Python scripts에서 실행하고 LLMTestCase와 TaskCompletenessMetric으로 Agent trace를 계층별로 채점할 수 있다고 설명합니다.

6.2 기준값 설정표

지표	기준	실패 시 동작
pass rate	≥ 90%	merge 차단
golden set	100% 통과	merge 차단
negative cases	알림 발생	차단하지 않되 팀 책임자에게 알림
version comparison	regression 없음	merge 차단

CI 설정 예시입니다.

evaluation:
  triggers:
    - pull_request
    - merge_to_main
    - canary_deployment

  conditions:
    pass_rate: 0.9
    golden_set: 1.0
    no_regression: true

  notifications:
    on_failure: ["team-lead", "on-call"]
    on_negative_alert: ["team-lead"]

gate 실행 시점에는 문제 코드가 main branch에 들어가지 못하게 하는 PR, merge 후에도 조건을 만족하는지 확인하는 merge, production traffic 전에 검증하는 canary가 있습니다. 비용 제어와 모델 라우팅(N156)을 읽었다면 비용 기준도 gate 조건이 될 수 있음을 알 수 있습니다. 여기서는 평가 기준에 집중합니다.

7. 실제 사례 회고

7.1 시나리오 설명

일일 리포트 Agent는 지난주 정상적으로 보고서를 생성했습니다. check_permission으로 권한을 확인하고, refresh_data로 데이터를 새로고침한 뒤, generate_report로 보고서를 만들었습니다. 모델 업그레이드 후에도 Agent는 “겉보기에는 맞는” 최종 요약을 반환했지만, 궤적에는 check_permission과 refresh_data가 빠져 있었습니다.

사용자는 권한 확인도, 데이터 새로고침도 없는 보고서를 받았지만 표면적으로는 알아차리기 어렵습니다. 공개 benchmark는 여러분의 tool schema와 state machine을 갖고 있지 않으므로 이 위험을 측정하지 못합니다.

7.2 문제 위치 찾기

모니터링 platform에서 실패 trace를 내보냅니다(Agent 모니터링과 실패 복구 참고). 궤적을 분석하면 tool call 목록에 check_permission과 refresh_data가 없고, 상태 전이가 init에서 execute로 바로 건너뛰며, check와 approve 단계가 없습니다. 최종 답변은 맞아 보이지만 데이터 소스는 새로고침되지 않았습니다.

라벨은 도구 선택 오류 + 상태 전이 건너뜀입니다.

7.3 데이터셋 업데이트

실패 사례를 negative cases에 추가합니다. 동시에 golden set도 보강합니다. 지난주 성공한 일일 리포트 작업을 찾아 전체 tool call 시퀀스를 포함하고, 올바른 사례로 라벨링합니다.

trajectory assertions를 업데이트합니다. 필수 도구 목록에 check_permission과 refresh_data를 추가하고, 상태 전이 순서 assertion을 ["init", "check", "approve", "execute"]로 설정합니다.

7.4 CI gate 차단

다음 PR이 eval 실행을 트리거합니다. negative case가 알림을 발생시킵니다: check_permission 도구 호출이 빠졌습니다. golden set은 전부 통과했으므로 성공 기준은 유지되고 있습니다.

원인은 prompt였습니다. 업그레이드된 모델은 “보고서 생성” 지시를 직접 실행으로 해석했고, 사전 권한 확인과 데이터 새로고침을 무시했습니다.

7.5 수정과 회귀 확인

prompt를 수정해 “보고서를 생성하기 전에 반드시 권한을 확인하고 데이터를 새로고침해야 한다”고 명시합니다. eval을 다시 실행하면 pass rate가 85%에서 95%로 올라가고, negative case는 알림 없이 통과하며, golden set도 전부 통과합니다. version comparison도 regression 없는 improvement를 보여줍니다.

merge하고 release합니다. CI gate가 이 회귀를 production 전에 막았습니다.

7.6 필드 매핑표

단계	사용한 필드
문제 위치 찾기	traceId, span_id, tool_calls, state_events
데이터셋 업데이트	input, expected tool calls, trajectory assertions, human labels
CI gate	pass rate, golden set, negative cases
수정 검증	pass rate, version comparison

이 순환은 production 실패에서 회귀 테스트까지의 전체 흐름을 보여줍니다. 사고 회고마다 traceId, tool call, approvalId, state event, 사람 판단을 eval example로 고정하면 다음 release 전에 같은 실패를 막을 수 있습니다.

8. 다음에 읽을 글

• Agent state machine과 prompt 경계: 상태 전이 제약과 trajectory assertion 필드의 출처 이해
• Agent 권한 모델: approval records와 고위험 tool call 규칙 이해
• 사람 승인 설계: approval records와 승인 플로우를 지속 가능한 테스트로 고정하는 방법 이해
• 비용 제어와 모델 라우팅: 비용 기준을 gate 조건으로 쓰는 방법 이해
• Agent 모니터링과 실패 복구: failed traces를 내보내고 사고 회고 루프 만들기