AI 에이전트 평가: 결정론적 지표 + LLM 판사
수많은 작은 AI 에이전트를 운영하고 있습니다. 백엔드, 프론트엔드, 모바일, 데브옵스(devops)를 위한 에이전트가 각각 하나의 작업을 수행합니다.
에이전트가 많아지면 문제에 직면합니다. 이들이 잘 작동하는지 알 수 없습니다. 프롬프트를 수정했을 때 성능이 좋아졌는지 나빠졌는지 알 수 없습니다. 규모가 커지면 "괜찮아 보인다"는 식의 말은 통하지 않습니다.
이를 해결하기 위해 프레임워크를 구축했습니다. 이 프레임워크는 수치를 사용하여 성능을 측정하고 프롬프트를 자동으로 개선합니다.
전략
먼저 수학적으로 측정 가능한 것부터 측정하십시오. LLM 판사는 반드시 필요한 경우에만 사용하십시오. 결정론적 지표는 빠르고 비용이 들지 않지만, LLM 판사는 느리고 비용이 발생합니다.
시스템 작동 방식:
• 하네스(harness)는 각 에이전트를 별도의 프로세스로 실행합니다. • 에이전트에 작업을 전달합니다. • 출력을 캡처합니다. • 예상 데이터와 비교하여 결과에 점수를 매깁니다.
에이전트는 stdin에서 읽고 stdout으로 쓰기만 하면 됩니다. Python이나 셸 스크립트 모두 가능하며, 하네스는 이를 구분하지 않습니다.
추적해야 할 5가지 핵심 지표:
- 정확도(Accuracy): 출력이 목표와 일치하는가?
- 퍼지 점수(Fuzzy score): 텍스트가 대상과 얼마나 유사한가?
- 타임아웃 비율(Timeout rate): 에이전트가 작업을 완료하지 못하는 빈도는 어느 정도인가?
- 안전 위반(Safety violations): 출력이 안전하지 않은 패턴과 일치하는가?
- 재현성 분산(Reproducibility variance): 에이전트가 매번 동일한 답변을 내놓는가?
에이전트의 답변이 맞더라도 일관성이 없다면 그것은 버그입니다.
LLM 판사 (The LLM Judge)
수학적으로 측정하기 어려운 것들이 있습니다. 에이전트가 자신의 역할을 유지했는지, 혹은 제약 사항을 준수했는지 알아야 합니다.
이러한 경우, LLM 판사가 작업을 검토합니다. 판사는 루브릭(rubric)과 에이전트의 출력을 전달받습니다. 그리고 구조화된 판결을 반환합니다. 보고서가 깨지지 않도록 JSON 스키마를 통해 이 판결을 검증합니다.
판사는 단순히 점수만 매기는 것이 아닙니다. 해결책을 제안해야 합니다. "이것은 약하다"와 같은 비판은 쓸모가 없습니다. "프롬프트에 JSON 블록을 추가하라"와 같은 비판은 실행 가능합니다.
개선 루프
실패 사례는 파일에 저장됩니다. 이 파일은 자동화된 루프에 입력됩니다. 시스템은 프롬프트의 가장 취약한 부분을 찾아 수정하려고 시도합니다. 또한 우수한 후보군을 유지하며, 가장 좋은 버전을 다시 코드에 작성합니다.
단일 점수는 스냅샷일 뿐입니다. 이력을 사용하여 트렌드를 추적하십시오. 이를 통해 시간이 지남에 따라 성능이 향상되고 있는지 알 수 있습니다.
결정론적 지표를 토대로 기반을 구축하십시오. 판사는 망치가 아니라 메스처럼 사용해야 합니다.
AI 에이전트 평가: 결정론적 지표 vs LLM 판사
AI 에이전트의 성능을 평가하는 것은 매우 까다로운 작업입니다. 에이전트는 단순히 질문에 답하는 것을 넘어, 도구를 사용하고, 계획을 세우며, 복잡한 워크플로우를 실행하기 때문입니다. 이러한 복잡성으로 인해 에이전트가 "잘 작동한다"는 것을 정의하고 측정하는 것은 쉽지 않습니다.
에이전트를 평가하는 데는 크게 두 가지 접근 방식이 있습니다: **결정론적 지표(Deterministic Metrics)**와 **LLM 판사(LLM Judge)**입니다.
결정론적 지표 (Deterministic Metrics)
결정론적 지표는 명확하고 객관적인 규칙을 사용하여 출력을 평가합니다. 결과가 예상과 일치하는지 여부를 수학적 또는 논리적으로 확인할 수 있습니다.
주요 유형:
- 정확한 일치 (Exact Match): 에이전트의 출력이 미리 정의된 정답(Ground Truth)과 글자 하나 틀리지 않고 일치하는지 확인합니다.
- 정규 표현식 (Regex): 출력이 특정 패턴(예: 이메일 주소, 날짜 형식, 특정 키워드 포함 여부)을 따르는지 확인합니다.
- 코드 실행 (Code Execution): 에이전트가 생성한 코드가 실제로 실행 가능한지, 그리고 실행 결과가 예상되는 값인지 확인합니다.
- 지연 시간 및 비용 (Latency & Cost): 작업 완료까지 걸린 시간과 사용된 토큰 수를 측정하여 효율성을 평가합니다.
장점:
- 빠르고 저렴합니다.
- 결과가 일관적이며 재현 가능합니다.
- 편향이 없습니다.
단점:
- 유연성이 부족합니다.
- 언어의 미묘한 차이나 문맥적 의미를 이해할 수 없습니다.
- 조금만 형식이 달라져도 실패로 간주될 수 있습니다.
LLM 판사 (LLM Judge)
LLM 판사는 고성능 LLM(예: GPT-4o)을 사용하여 다른 모델이나 에이전트의 출력을 평가하는 방식입니다. 판사 역할을 하는 LLM에게 평가 기준(Rubric)을 제공하고, 에이전트의 응답을 점수화하거나 피드백을 주도록 합니다.
주요 특징:
- 뉘앙스 및 추론 평가: 문맥의 흐름, 논리적 일관성, 어조 등을 평가할 수 있습니다.
- 유연성: 정해진 형식이 없어도 의미상 정답인지 판단할 수 있습니다.
장점:
- 인간의 평가 방식과 가장 유사합니다.
- 복잡하고 비정형적인 데이터에 적합합니다.
- "왜" 틀렸는지에 대한 설명(Reasoning)을 제공할 수 있습니다.
단점:
- 비용이 많이 듭니다.
- 속도가 느립니다.
- 편향(Bias): 판사 모델이 특정 스타일을 선호하거나, 자신의 출력과 유사한 것을 선호하는 등의 편향이 발생할 수 있습니다.
결정론적 지표 vs LLM 판사 비교
| 특징 | 결정론적 지표 | LLM 판사 |
|---|---|---|
| 속도 | 매우 빠름 | 느림 |
| 비용 | 매우 낮음 | 높음 |
| 유연성 | 낮음 | 높음 |
| 복잡한 추론 평가 | 불가능 | 가능 |
| 일관성 | 매우 높음 | 보통 (확률적) |
결론: 하이브리드 접근 방식 (The Hybrid Approach)
최고의 평가 전략은 이 두 가지를 결합하는 것입니다.
- 결정론적 지표를 사용하여 기본적인 형식, 코드 실행 여부, 비용, 지연 시간과 같은 "하드 제약 조건"을 먼저 확인합니다.
- LLM 판사를 사용하여 내용의 정확성, 논리적 추론, 사용자 의도와의 부합 여부와 같은 "소프트 제약 조건"을 평가합니다.
이러한 계층적 접근 방식을 통해 비용 효율적이면서도 정교한 AI 에이전트 평가 파이프라인을 구축할 수 있습니다.
Optional learning community: https://t.me/GyaanSetuAi