The Most Common Questions About Agent Evals, Answered

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

에이전트 평가는 실제 트레이스에서 시작해 오프라인·온라인 평가를 연결하고, 코드·LLM 심사·사람의 검토와 다단계 벤치마크를 조합해 동작과 결과를 검증하는 과정이다.

📌 핵심 요약

• 에이전트는 같은 요청에도 출력과 실행 경로가 달라질 수 있어, 최종 답변뿐 아니라 도구 호출, 전체 대화, 실행 궤적, 환경의 최종 상태까지 평가해야 한다.
• 중요한 동작 하나를 선택하고 실제 트레이스에서 10~20개 예시로 초기 데이터셋을 만든 뒤, 현재 에이전트의 기준선 실험을 저장하고 새로운 실패를 예시로 추가하는 방식으로 시작한다.
• 오프라인 평가는 배포 전 고정된 데이터셋으로 버전을 비교하고 회귀를 탐지하며, 온라인 평가는 운영 트레이스를 평가해 기존 데이터셋이 놓친 문제를 찾는다. 온라인에서 발견한 실패는 오프라인 데이터셋에 반영한다.
• 코드 평가기는 결정적으로 확인할 수 있는 조건에, LLM 심사는 코드로 판정하기 어려운 품질에, 사람의 검토는 주관적 품질과 평가기 검증에 적합하다. LLM 심사는 사람의 점수와 대조하고, 좁은 질문과 명확한 점수 체계로 보정한다.
• Terminal-Bench 같은 벤치마크는 독립된 컨테이너 환경과 채점 스크립트를 갖춘 오프라인 평가다. Harbor는 긴 다단계 작업을 실행하고 결과를 LangSmith 실험에 기록하며, 원문은 Deep Agents의 Terminal-Bench 2.0 개선과 LangSmith Engine용 IssueBench 구축 사례를 소개한다.

🧩 주요 포인트

1. 실제 실패를 데이터셋에 누적하면 운영에서 발견한 문제가 다음 버전의 비교 기준이 되어, 배포 전 검증과 배포 후 관찰이 하나의 개선 순환으로 연결된다.
2. 평가 대상과 채점 방식은 별도로 선택할 수 있으므로, 최종 답변의 품질과 도구 사용·전체 대화·환경 상태의 적절성을 나누어 확인할 수 있다.
3. 다단계 작업에서는 답변만으로 실행 결과를 판단하기 어렵기 때문에, 컨테이너 환경의 최종 상태를 검사하는 벤치마크와 실패 원인을 설명하는 트레이스 분석을 함께 활용한다.

🧠 상세 정리

1. 에이전트 평가가 필요한 이유

전통적인 소프트웨어는 같은 입력에 같은 출력이 나온다는 전제에서 정확한 결과를 단위 테스트로 확인할 수 있지만, 에이전트는 같은 요청에도 실행마다 출력이 달라질 수 있다. 하나의 요청에 올바른 답이 여러 개일 수도 있어 정답과의 완전 일치만으로는 품질을 충분히 판단하기 어렵다. 에이전트가 실행 단계를 스스로 선택한다는 점도 중요하며, 최종 답변이 맞더라도 불필요한 도구를 호출하거나 사용자 허락 없이 행동했을 가능성이 있다. 에이전트 평가는 이러한 변동성을 고려하는 기준으로 실행을 채점해 기대한 동작을 했는지 확인한다. 원문은 모든 제품에 통하는 단일 평가 조합이 있다고 보지 않으며, 팀과 제품, 최적화하려는 목표에 따라 적절한 평가 구성이 달라진다고 설명한다.

2. 실제 트레이스에서 작은 기준선 만들기

평가의 출발점은 에이전트가 실제로 무엇을 하는지 이해하는 것이며, 트레이스는 한 번의 실행에 포함된 입력과 출력, 그 사이의 모든 모델 호출과 도구 호출을 기록한다. 먼저 일부 트레이스를 읽어 요청을 처리하는 방식과 실패 지점을 살피고, 여행 도우미가 사용자가 지정한 날짜와 가격 범위로 예약하는지처럼 중요한 동작 하나를 선택한다. 초기 데이터셋은 해당 동작의 예시 10~20개로 시작할 수 있고, 각 예시는 입력과 필요에 따라 기대 출력을 담는 개별 테스트 사례가 된다. LangSmith에서는 트레이싱 화면에서 실행을 데이터셋에 직접 추가할 수 있으며, 아직 운영 전이라면 팀이나 신뢰할 수 있는 소수의 디자인 파트너가 시험한 트레이스를 활용한다. 현재 버전을 데이터셋으로 실행하고 평가 점수와 함께 실험으로 저장하면 이후 버전의 비교 기준선이 된다. 이후 테스트나 운영에서 발견한 실패를 예시로 추가하고, 에이전트를 개선한 뒤 다시 실행하는 과정을 반복한다.

3. 오프라인 평가와 온라인 평가의 연결

오프라인 평가는 변경 사항을 배포하기 전에 선택한 데이터셋으로 에이전트를 실행하는 방식이며, 입력뿐 아니라 참조 출력이라고도 부르는 기대 출력을 포함할 수 있다. 같은 데이터셋의 실험 결과를 비교하면 새로운 프롬프트, 모델, 도구가 성능을 개선했는지 확인하고 사용자에게 도달하기 전에 회귀를 발견할 수 있다. 온라인 평가는 실제 운영 트레이스가 들어오는 대로 채점하며, 일반적으로 참조 출력이 없으므로 실행 자체를 판단할 수 있는 코드 검사와 LLM 심사에 의존한다. 온라인 평가의 주된 용도는 실제 사용자 환경에서 품질을 관찰하고 기존 데이터셋이 다루지 못한 문제를 찾는 것이다. 원문은 두 방식이 모두 필요하며, 온라인 평가가 포착한 실패를 오프라인 데이터셋의 새 예시로 전환해야 한다고 설명한다. Terminal-Bench처럼 고정된 작업 집합으로 에이전트나 모델, 버전을 비교하는 벤치마크도 오프라인 평가에 속한다.

4. 데이터셋의 구성과 분리 기준

LangSmith에서 오프라인 평가용 데이터셋을 만드는 방법에는 예시를 직접 작성하거나 기존 트레이스의 실행을 추가하는 방식이 있다. 팀이 주석 검토 대기열에서 검토한 실행을 보내거나, CSV 또는 JSONL 파일을 업로드하거나, 기존의 소수 예시에서 합성 예시를 생성하는 방법도 제시된다. 평가 범위가 커질 때 같은 동작을 같은 평가기로 검사하는 예시들은 하나의 데이터셋에 유지하는 것이 시간에 따른 실험 비교에 유리하다. 반면 단일 요청과 전체 대화처럼 입력 형태가 다르거나 필요한 평가기가 달라지면 별도 데이터셋을 만드는 것이 권장된다. 모든 풀 리퀘스트에서 실행하는 작은 집합과 릴리스 전에 실행하는 큰 집합처럼 목적이 다를 때도 데이터셋을 나눌 수 있다. 하나의 데이터셋 안에서 일부 예시만 실행하려면 분할 기능을 사용할 수 있어, 예시를 추가할 때에는 검증하는 동작과 평가 방식, 실행 목적을 함께 고려하게 된다.

5. 평가기의 종류와 평가 대상

평가기란 실행에 점수를 부여하는 로직이며, 원문은 대부분의 팀이 네 가지 유형 중 한두 가지로 시작해 점차 확장한다고 설명한다. 코드 평가기는 예약 가격이 사용자 예산 이하인지처럼 결정적으로 판정할 수 있는 조건을 빠르고 저렴하며 일관되게 검사하지만, 결정적인 입력과 출력이 필요하다는 제약이 있다. LLM 심사는 항공편 세부 사항을 명확하게 확인해 주었는지처럼 코드로 판단하기 어려운 품질을 평가하고, 사람의 검토는 느리지만 주관적 품질과 다른 평가기의 적절성을 확인하는 데 가장 좋은 신호로 제시된다. 쌍대 비교 평가기는 두 출력을 나란히 놓고 더 나은 것을 선택하므로 두 프롬프트나 모델 중 하나를 고를 때 유용하다. 이러한 평가기들은 search_flights가 올바른 날짜로 호출됐는지 같은 단일 단계, 최종 응답, 여러 차례 변경 요청을 포함한 전체 대화에 적용할 수 있다. 또한 독립된 컨테이너에서 실행한 뒤 모의 예약 시스템에 남은 기록처럼 환경의 최종 상태를 평가할 수 있으며, 원문은 이를 컨테이너 기반 평가라고 부르기도 한다고 설명한다.

6. LLM 심사의 신뢰성을 높이는 방법

LLM 심사는 답변이 검색된 문서로 뒷받침되는지처럼 코드로 검사하기 어려운 내용을 유연하게 판단할 수 있지만, 결과가 일관되지 않거나 팀의 판단과 어긋날 수 있다. 따라서 사람이 일부 실행을 직접 채점하고 LLM 심사와 의견이 갈리는 지점을 확인한 뒤, 판단이 맞아들도록 심사 프롬프트나 예시를 조정하는 과정이 필요하다. 원문은 LangSmith의 주석 검토 대기열이 이러한 비교를 돕는다고 설명하며, 작은 표본의 사람 검토를 LLM 평가기의 판단에 반영하는 방식을 제시한다. 질문도 범위를 좁혀야 하며, 여행 도우미의 답변이 좋은지 포괄적으로 묻기보다 모든 경유지를 언급했는지 묻는 편이 판정하기 쉽다. 점수 체계는 통과·실패나 소수의 명확한 범주처럼 구체적으로 정의하는 것이 권장된다. 1~10점 척도는 6점과 7점의 차이처럼 모델이 구분하기 어려운 경계를 만들 수 있어, 원문은 이진 판정이나 명시적 범주가 훨씬 재현성이 높다고 설명한다.

7. 벤치마크가 다단계 실행을 평가하는 방식

벤치마크는 작업 집합으로 구성된 오프라인 평가이며, 각 작업에는 지시 사항과 컨테이너 환경, 결과를 채점하는 테스트 스크립트가 포함된다. 에이전트가 코드를 실행하고 파일을 수정하며 서비스와 상호작용할 수 있게 되면서, 단순한 LLM 심사나 코드 기반 평가만으로는 충분하지 않은 경우가 생긴다는 것이 원문의 설명이다. 하나의 작업을 완료하는 동안 패키지를 설치하고 파일을 편집하며 수십 번의 도구 호출에 걸쳐 명령을 실행할 수 있으므로, 벤치마크는 작업별로 격리된 환경을 제공한다. 채점 스크립트는 실행 후 테스트 통과 여부나 올바른 파일의 존재처럼 에이전트가 남긴 상태를 검사하며, 트레이스를 검토할 수 있어도 점수는 수행한 행동과 그 결과 상태에서 나온다. 여행 도우미의 예로는 폭풍으로 취소된 덴버행 항공편을 다시 예약하고 호텔 일정도 맞추는 요청이 제시된다. 이 경우 에이전트가 작업을 마친 뒤 데이터베이스의 예약 기록을 검사해 요청이 실제로 반영됐는지 평가한다.

8. Harbor 연동과 실제 개선 사례

Harbor는 긴 작업을 평가하기 위한 기반을 제공하는 오픈 소스 평가 실행 프레임워크로, Terminal-Bench를 구동하며 같은 작업 형식으로 자체 벤치마크를 만드는 데도 사용할 수 있다. LangSmith와 연동하면 각 Harbor 실행이 LangSmith 실험으로 기록되고 작업마다 컨테이너가 만들어지며, LangSmith 트레이스를 활용해 작업 환경을 실제 운영 환경에 더 가깝게 구성할 수 있다. 벤치마크 결과는 다른 평가 결과와 함께 볼 수 있고, 개별 실행을 열면 점수 옆에서 전체 트레이스를 확인할 수 있다. 원문은 이 구성을 활용해 트레이스에서 실패 유형을 찾고 실행 프레임워크를 변경함으로써 Terminal-Bench 2.0에서 Deep Agents를 개선했다고 소개한다. 또한 LangSmith Engine용 IssueBench를 구축했으며, 각 작업은 Engine에 트레이스 묶음을 주고 올바른 트레이스를 적절한 이슈 군집으로 묶는지 채점한다. 자체 벤치마크를 만들 때는 트레이스의 실패를 환경이 딸린 Harbor 작업으로 전환하고, 평가 기준에 맞는 LLM 심사나 코드 평가기를 정의한 뒤 점수로 변경 사항을 A/B 비교하는 절차를 제안한다. 제공된 원문은 에이전트 반복 실행 구성을 언급하는 문장 중간에서 끝나므로, 그 이후의 구체적인 자동화 방식은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 운영에서 발견한 실패를 반복 가능한 평가 예시로 바꾸는 과정이 중요하다. 이렇게 해야 실제 문제의 발견이 이후 버전의 검증으로 이어진다.
• 최종 답변의 정확성과 실행 과정의 적절성은 별개의 평가 축이다. 올바른 답을 냈더라도 불필요한 도구 호출이나 허락 없는 행동이 있었다면 다른 평가 결과가 나올 수 있다.
• LLM 심사의 유연성은 사람의 판단과 대조하고 판정 범위를 좁힐 때 더 신뢰할 수 있으며, 다단계 작업에서는 환경 상태 검사와 트레이스 검토가 서로 보완한다.

✅ 액션 아이템

• 중요한 동작 하나를 정하고 실제 트레이스에서 10~20개 예시를 모아 초기 데이터셋과 기준선 실험 구성.
• 온라인 평가에서 발견한 실패를 오프라인 데이터셋에 추가하고, 변경된 에이전트의 결과를 기준선과 비교.
• LLM 심사를 사람의 점수와 대조해 보정하고, 다단계 작업의 도구 사용과 환경의 최종 상태까지 평가 범위 확장.

❓ 열린 질문

• 초기 데이터셋의 10~20개 예시로 우선 검증할 가장 중요한 동작은 무엇인가?
• LLM 심사와 사람의 점수가 어긋나는 항목은 무엇이며, 질문과 점수 체계를 어떻게 좁힐 수 있는가?
• 현재 다단계 작업에서 최종 답변만으로 확인하기 어려워 환경의 최종 상태를 검사해야 하는 결과는 무엇인가?