평가

에이전트 시스템을 위한 평가 방법

에이전트 시스템은 전통적인 소프트웨어와 다르게 평가해야 합니다. 에이전트는 동적 결정을 내리고, 실행 간에 비결정론적이며, 종종 단일 정답이 없기 때문입니다. 이러한 특성을 고려하고, 실행 가능한 피드백을 제공하며, 회귀를 감지하고, 컨텍스트 엔지니어링 선택이 의도한 효과를 달성하는지 검증하는 평가 프레임워크를 구축하세요.

활성화 시점

다음과 같은 경우 이 스킬을 활성화하세요:

• 에이전트 성능을 체계적으로 테스트할 때
• 컨텍스트 엔지니어링 선택을 검증할 때
• 시간 경과에 따른 개선을 측정할 때
• 배포 전에 회귀를 감지할 때
• 에이전트 파이프라인을 위한 품질 게이트를 구축할 때
• 다양한 에이전트 구성을 비교할 때
• 프로덕션 시스템을 지속적으로 평가할 때

다른 스킬이 담당하는 인접 작업에는 이 스킬을 활성화하지 마세요:

• LLM 판독기 자체, 쌍별 비교, 판독기 보정, 또는 편향 완화 설계: advanced-evaluation.
• 자율 제어 표면, 참신성 게이트, 롤백, 또는 PR 승인 경계 설계: harness-engineering.
• 측정하기 전에 특정 컨텍스트 실패 모드 디버깅: context-degradation.

핵심 개념

에이전트가 목표에 도달하는 대체 유효 경로를 찾을 수 있으므로 실행 경로보다 결과에 초점을 맞추세요. 에이전트가 특정 단계 시퀀스를 따랐는지 여부가 아니라 합리적인 프로세스를 통해 올바른 결과를 달성하는지 판단하세요.

단일 점수는 특정 차원의 심각한 실패를 숨기므로 다차원 루브릭을 사용하세요. 사실적 정확성, 완전성, 인용 정확성, 출처 품질, 도구 효율성을 별도의 차원으로 캡처한 다음 사용 사례에 맞게 가중치를 부여하세요.

결정론적 검사와 루브릭이 안정화된 후에만 모델 판단 평가를 사용하세요. 작업이 판독기 프롬프트, 쌍별 비교, 보정, 또는 편향 완화에 중점을 둔 경우 고급 평가(Advanced Evaluation)로 전환하세요.

아티팩트가 기계적으로 확인 가능한 구조를 가질 때마다 LLM 판단보다 먼저 결정론적 검증을 실행하세요. 스키마 유효성, 중복 키, 루브릭 수학, 매니페스트 동기화, 검색 상태, 필수 증거 경로는 평가자가 토큰을 사용하거나 주관적인 점수를 반환하기 전에 빠르게 실패해야 합니다.

성능 동인

평가 예산을 설계할 때 브라우징 에이전트 연구를 적용하세요: 토큰 사용량, 도구 호출 및 모델 선택이 측정된 성능 차이를 지배할 수 있습니다 (claim-evaluation-browsecomp-variance).

요인	설명된 분산	의미
토큰 사용량	주요 동인	더 많은 탐색은 비용이나 컨텍스트 품질이 붕괴될 때까지 성능을 향상시킬 수 있음
도구 호출 수	2차 동인	도구 사용은 호출이 유용한 증거를 검색할 때만 도움이 됨
모델 선택	2차적이지만 곱연산	더 나은 모델은 종종 토큰과 도구를 더 효율적으로 사용함

평가를 설계할 때 이러한 의미에 따라 행동하세요:

• 현실적인 토큰 예산 설정: 무제한 리소스가 아닌 프로덕션 현실적인 토큰 제한으로 에이전트를 평가하세요.
• 모델 업그레이드와 토큰 증가 비교: 더 나은 모델은 더 큰 예산을 가진 약한 모델보다 토큰을 더 효율적으로 사용할 수 있습니다.
• 다중 에이전트 아키텍처 검증: 추가 에이전트는 토큰과 도구 호출을 추가합니다. 단일 에이전트 기준과 비교하여 평가하세요.

세부 주제

평가 과제

비결정론 및 다중 유효 경로 처리

에이전트가 목표에 도달하기 위해 완전히 다른 유효 경로를 취할 수 있으므로 경로 변화를 허용하는 평가를 설계하세요. 한 에이전트는 세 가지 출처를 검색하는 반면 다른 에이전트는 열 가지를 검색할 수 있습니다. 둘 다 정답을 생성할 수 있습니다. 특정 단계를 확인하지 마세요. 대신 결과 기준(정확성, 완전성, 품질)을 정의하고 이를 기준으로 점수를 매기고 실행 경로를 평가보다는 정보 제공용으로 취급하세요.

컨텍스트 의존적 실패 테스트

에이전트 실패는 종종 미묘한 방식으로 컨텍스트에 의존하기 때문에 다양한 복잡성 수준과 상호 작용 길이에 걸쳐 평가하세요. 에이전트는 단순한 쿼리에서는 성공하지만 복잡한 쿼리에서는 실패할 수 있고, 한 도구 세트에서는 잘 작동하지만 다른 도구 세트에서는 실패하거나, 컨텍스트가 축적됨에 따라 확장된 상호 작용 후에 성능이 저하될 수 있습니다. 이러한 패턴을 표면화하려면 단순, 중간, 복잡, 매우 복잡한 테스트 사례를 포함하세요.

복합 품질 차원을 별도로 점수화

에이전트 품질을 별도의 차원(사실적 정확성, 완전성, 일관성, 도구 효율성, 프로세스 품질)으로 나누고 각각을 독립적으로 점수화하세요. 에이전트는 정확성은 높지만 효율성은 낮을 수 있기 때문입니다. 그런 다음 사용 사례 우선순위에 맞게 조정된 가중치 집계를 계산하세요. 이 접근 방식은 신호를 평균화하는 대신 어떤 차원이 개선이 필요한지 보여줍니다.

평가 루브릭 설계

다차원 루브릭 구축

핵심 차원을 포괄하고 우수에서 실패까지 설명적 수준을 포함하는 루브릭을 정의하세요. 이러한 핵심 차원을 포함하고 사용 사례에 따라 가중치를 조정하세요:

• 사실적 정확성: 주장이 실제 사실과 일치함 (지식 작업에 높은 가중치)
• 완전성: 출력이 요청된 측면을 포괄함 (연구 작업에 높은 가중치)
• 인용 정확성: 인용이 주장된 출처와 일치함 (신뢰에 민감한 컨텍스트에 가중치)
• 출처 품질: 적절한 주요 출처를 사용함 (권위 있는 출력에 가중치)
• 도구 효율성: 적절한 도구를 합리적인 횟수로 사용함 (비용에 민감한 시스템에 가중치)

루브릭을 숫자 점수로 변환

차원 평가를 숫자 점수(0.0에서 1.0)에 매핑하고, 차원별 가중치를 적용하며, 가중치가 적용된 전체 점수를 계산하세요. 일반적으로 0.7, 고위험 애플리케이션의 경우 0.9와 같이 사용 사례 요구 사항에 따라 통과 임계값을 설정하세요. 집계 점수와 함께 개별 차원 점수를 저장하세요. 세부 분석이 목표 지향적인 개선을 주도하기 때문입니다.

평가 방법론

대규모 평가를 위한 LLM-as-Judge 사용

다음을 포함하는 LLM 기반 평가 프롬프트를 구축하세요: 명확한 작업 설명, 테스트 중인 에이전트 출력, 사용 가능한 경우 실제 사실, 명시적 수준 설명이 포함된 평가 척도, 추론과 함께 구조화된 판단 요청. LLM 판독기는 대규모 테스트 세트에서 일관되고 확장 가능한 평가를 제공합니다. 자기 강화 편향을 피하기 위해 평가 중인 에이전트와 다른 모델 제품군을 사용하세요.

인간 평가로 보완

에지 케이스, 비정상적인 쿼리 및 프로덕션 트래픽의 무작위 샘플을 인간 검토자에게 라우팅하세요. 인간은 자동화된 평가가 놓치는 환각 답변, 시스템 오류 및 미묘한 편향을 알아차리기 때문입니다. 인간 검토 전반의 패턴을 추적하여 체계적인 문제를 식별하고 발견 사항을 자동화된 평가 기준에 다시 반영하세요.

상태 저장 에이전트를 위한 최종 상태 평가 적용

영구 상태(파일, 데이터베이스, 구성)를 변경하는 에이전트의 경우 에이전트가 어떻게 도달했는지보다 최종 상태가 기대치와 일치하는지 평가하세요. 예상되는 최종 상태 어설션을 정의하고 각 테스트 실행 후 프로그래밍 방식으로 확인하세요.

테스트 세트 설계

대표 샘플 선택

변경 사항이 극적인 영향을 미치고 쉬운 개선이 풍부한 초기 개발 단계에서는 소규모 샘플(20-30건)로 시작하세요. 시스템이 성숙함에 따라 신뢰할 수 있는 신호를 위해 50건 이상으로 확장하세요. 실제 사용 패턴에서 샘플링하고, 알려진 에지 케이스를 추가하며, 복잡성 수준 간의 적용 범위를 보장하세요.

복잡성별 계층화

쉬운 예제가 점수를 부풀리는 것을 방지하기 위해 복잡성 수준에 걸쳐 테스트 세트를 구성하세요:

• 단순: 단일 도구 호출, 사실 조회
• 중간: 여러 도구 호출, 비교 논리
• 복잡: 많은 도구 호출, 상당한 모호성
• 매우 복잡: 확장된 상호 작용, 심층 추론, 종합

전체 점수와 함께 계층별 점수를 보고하여 에이전트가 실제로 어려움을 겪는 위치를 밝히세요.

컨텍스트 엔지니어링 평가

컨텍스트 전략을 체계적으로 검증

동일한 테스트 세트에서 다양한 컨텍스트 전략을 사용하여 에이전트를 실행하고 품질 점수, 토큰 사용량 및 효율성 메트릭을 비교하세요. 이는 컨텍스트 엔지니어링의 효과를 다른 변수로부터 분리하고 일화 기반 결정을 방지합니다.

성능 저하 테스트 실행

다양한 컨텍스트 크기에서 에이전트를 실행하여 컨텍스트 성능 저하가 성능에 어떤 영향을 미치는지 테스트하세요. 컨텍스트가 문제가 되는 성능 급락 지점을 식별하고 안전한 운영 한계를 설정하세요. 이러한 한계를 컨텍스트 관리 전략에 다시 반영하세요.

지속적 평가

자동화된 평가 파이프라인 구축

평가를 개발 워크플로에 통합하여 에이전트 변경 시 자동으로 평가가 실행되도록 하세요. 시간 경과에 따른 결과를 추적하고, 버전을 비교하며, 주요 메트릭에서 회귀하는 배포를 차단하세요.

프로덕션 품질 모니터링

프로덕션 상호 작용을 샘플링하고 지속적으로 평가하세요. 경고(0.85 통과율) 및 중요(0.70 통과율) 임계값 아래로 품질이 떨어지면 알림을 설정하세요. 시간 창에 걸친 추세 분석을 보여주는 대시보드를 유지하여 점진적인 성능 저하를 감지하세요.

실용적인 지침

평가 프레임워크 구축

이 순서에 따라 평가 프레임워크를 구축하세요. 초기 단계를 건너뛰면 측정이 실제 품질을 반영하지 못할 수 있기 때문입니다:

1. 평가 코드를 작성하기 전에 사용 사례와 관련된 품질 차원을 정의하세요. 나중에 선택된 차원은 중요한 것보다 측정하기 쉬운 것을 반영하는 경향이 있습니다.
2. 평가자(인간 또는 LLM)가 일관된 점수를 생성할 수 있도록 명확하고 설명적인 수준 정의와 함께 루브릭을 만드세요.
3. 실제 사용 패턴과 에지 케이스에서 테스트 세트를 구축하고, 복잡성별로 계층화하며, 신뢰할 수 있는 신호를 위해 최소 50건의 사례를 포함하세요.
4. 모든 중요한 변경 시 실행되는 자동화된 평가 파이프라인을 구현하세요.
5. 변경을 수행하기 전에 기준 메트릭을 설정하여 개선 사항을 알려진 참조와 비교하여 측정할 수 있도록 하세요.
6. 모든 중요한 변경에 대해 평가를 실행하고 기준과 비교하세요.
7. 시간 경과에 따른 메트릭을 추세 분석을 위해 추적하세요. 점진적인 성능 저하는 갑작스러운 하락보다 알아차리기 어렵기 때문입니다.
8. 정기적인 간격으로 인간 검토로 자동화된 평가를 보완하세요.
9. 결정론적 검증 실패를 품질 판단과 분리하여 유효하지 않은 아티팩트가 유리한 LLM 점수로 세탁되는 것을 방지하세요.

평가 함정 피하기

평가 신뢰성을 훼손하는 이러한 일반적인 실패를 방지하세요:

• 특정 경로에 대한 과적합: 에이전트는 새롭고 유효한 경로를 찾기 때문에 결과를 평가하고 특정 단계를 평가하지 마세요.
• 에지 케이스 무시: 전체 복잡성 스펙트럼을 포괄하는 다양한 테스트 시나리오를 포함하세요.
• 단일 메트릭 집착: 단일 점수는 차원별 실패를 숨기므로 다차원 루브릭을 사용하세요.
• 컨텍스트 효과 무시: 청정실 조건보다는 현실적인 컨텍스트 크기와 히스토리로 테스트하세요.
• 인간 평가 건너뛰기: 자동화된 평가는 인간이 확실히 잡아내는 미묘한 문제를 놓칩니다.

예제

예제 1: 간단한 평가

def evaluate_agent_response(response, expected):
    rubric = load_rubric()
    scores = {}
    for dimension, config in rubric.items():
        scores[dimension] = assess_dimension(response, expected, dimension)
    overall = weighted_average(scores, config["weights"])
    return {"passed": overall >= 0.7, "scores": scores}

예제 2: 테스트 세트 구조

테스트 세트는 포괄적인 평가를 보장하기 위해 여러 복잡성 수준에 걸쳐 있어야 합니다:

test_set = [
    {
        "name": "simple_lookup",
        "input": "프랑스의 수도는 무엇인가요?",
        "expected": {"type": "fact", "answer": "파리"},
        "complexity": "simple",
        "description": "단일 도구 호출, 사실 조회"
    },
    {
        "name": "medium_query",
        "input": "지난 분기 Apple과 Microsoft의 매출을 비교하세요",
        "complexity": "medium",
        "description": "여러 도구 호출, 비교 논리"
    },
    {
        "name": "multi_step_reasoning",
        "input": "1분기부터 4분기까지의 판매 데이터를 분석하고 추세가 포함된 요약 보고서를 만드세요",
        "complexity": "complex",
        "description": "많은 도구 호출, 집계, 분석"
    },
    {
        "name": "research_synthesis",
        "input": "떠오르는 AI 기술을 조사하고, 잠재적 영향을 평가하며, 도입 전략을 추천하세요",
        "complexity": "very_complex",
        "description": "확장된 상호 작용, 심층 추론, 종합"
    }
]

예제 3: 모델 판단 전 결정론적 게이트

def evaluate_pr_candidate(candidate):
    structure = run_validate_repo(candidate)
    if not structure.ok:
        return {"passed": False, "reason": "결정론적 검증 실패", "details": structure.errors}

    quality = run_rubric_eval(candidate)
    return {"passed": quality.overall >= 0.8, "scores": quality.dimensions}

예제 4: 품질 게이트 차원

gate:
  deterministic:
    - schema_valid
    - required_files_present
    - no_duplicate_ids
  quality:
    factual_accuracy: min 0.85
    completeness: min 0.80
    source_traceability: min 0.90

지침

1. 단일 메트릭이 아닌 다차원 루브릭을 사용하세요
2. 특정 실행 경로가 아닌 결과를 평가하세요
3. 단순에서 복잡까지 복잡성 수준을 포괄하세요
4. 현실적인 컨텍스트 크기와 히스토리로 테스트하세요
5. 릴리스 전에만이 아니라 지속적으로 평가를 실행하세요
6. LLM 평가를 인간 검토로 보완하세요
7. 추세 감지를 위해 시간 경과에 따른 메트릭을 추적하세요
8. 사용 사례에 기반한 명확한 통과/실패 임계값을 설정하세요

주의사항

1. 특정 코드 경로에 대한 평가 과적합: 테스트는 통과하지만 에이전트는 약간의 입력 변형에 실패합니다. 표면 패턴이 아닌 결과와 의미를 기준으로 평가 기준을 작성하고 테스트 입력을 주기적으로 변경하세요.
2. LLM 판독기 자기 강화 편향: 모델은 독립적인 판독기보다 자신의 출력을 더 높게 평가합니다. 평가 중인 모델과 다른 모델 제품군을 평가 판독기로 사용하세요.
3. 테스트 세트 오염: 평가 예제가 학습 데이터나 프롬프트 템플릿에 유출되어 점수가 부풀려집니다. 평가 세트를 버전 관리하고 프롬프트나 미세 조정에 사용되는 모든 데이터와 별도로 유지하세요.
4. 메트릭 게임: 측정되는 메트릭에 대해 최적화하지만 실제 사용자 만족도는 저하됩니다. 정기적으로 평가 기준을 감사하고 인간 연구와 비교하여 신호가 진정한 품질과 일치하는지 확인하세요.

참조

• 평가 설계에 대한 일반 원칙
• 브라우징 에이전트 토큰 및 도구 효율성 연구
• 다중 에이전트 시스템 평가 방법론
• 평가를 위한 LLM-as-Judge 구현