Deep Agents를 위한 평가(Evals) 구축 방법

핵심 요약 (Key Takeaways)

💡 요약 (TLDR): 가장 좋은 에이전트 평가(Evals)는 우리가 중요하게 생각하는 에이전트의 행동을 직접적으로 측정하는 것입니다. 여기서는 에이전트를 더 정확하고 신뢰할 수 있게 만들기 위해 데이터를 확보하고, 지표(Metrics)를 생성하며, 시간이 지남에 따라 잘 정의된 범위 내에서 타겟팅된 실험을 수행하는 방법을 소개합니다.

평가(Evals)는 에이전트의 행동을 형성합니다

우리는 Deep Agents를 측정하고 개선하기 위해 평가(Evaluations)를 큐레이션해 왔습니다. Deep Agents는 Fleet 및 Open SWE와 같은 제품을 구동하는 오픈 소스 기반의 모델 불가지론적(Model agnostic) 에이전트 하네스(Harness)입니다. 평가(Evals)는 에이전트의 행동을 정의하고 형성하므로, 이를 신중하게 설계하는 것이 매우 중요합니다.

모든 평가(Eval)는 에이전트 시스템의 행동을 변화시키는 벡터와 같습니다. 예를 들어, 효율적인 파일 읽기에 대한 평가(Eval)가 실패한다면, 해당 평가를 통과할 때까지 시스템 프롬프트(System prompt)나 read_file 도구 설명(Tool description)을 미세하게 조정하여 행동을 유도할 것입니다. 유지되는 모든 평가(Eval)는 시간이 지남에 따라 전체 시스템에 압력을 가하게 됩니다.

평가(Evals)를 추가할 때는 신중을 기하는 것이 매우 중요합니다. 수백(또는 수천) 개의 테스트를 맹목적으로 추가하고 싶은 유혹이 생길 수 있습니다. 하지만 이는 실제 운영 환경(Production)에서 중요하게 생각하는 행동을 정확하게 반영하지 못할 수도 있는 평가 세트(Eval suite)에서 높은 점수를 받음으로써, 마치 "에이전트를 개선하고 있다"는 환상을 심어줄 수 있습니다.

더 많은 평가(Evals)가 반드시 더 나은 에이전트를 의미하지는 않습니다. 대신, 운영 환경에서 원하는 행동을 반영하는 타겟팅된 평가(Evals)를 구축하십시오.

Deep Agents를 구축할 때, 우리는 파일 시스템의 여러 파일에서 콘텐츠를 검색하거나 5개 이상의 도구 호출(Tool calls)을 순차적으로 정확하게 구성하는 것과 같이 운영 환경에서 중요한 행동들을 카탈로그화합니다. 벤치마크 작업(Benchmark tasks)을 총체적으로 사용하는 대신, 우리는 다음과 같은 평가(Eval) 큐레이션 접근 방식을 취합니다:

• 에이전트가 따르기를 원하는 행동이 무엇인지 결정합니다. 그런 다음 해당 행동을 검증 가능한 방식으로 측정할 수 있는 타겟팅된 평가(Evals)를 조사하고 큐레이션합니다.
• 각 평가(Eval)에 에이전트의 능력을 어떻게 측정하는지 설명하는 독스트링(Docstring)을 추가합니다. 이를 통해 각 평가(Eval)가 자체적으로 문서화되도록 보장합니다. 또한 그룹화된 실행을 가능하게 하기 위해 각 평가(Eval)에 tool_use와 같은 카테고리 태그를 지정합니다.
• 실패 모드(Failure modes)를 이해하기 위해 출력 트레이스(Output traces)를 검토하고 평가(Eval) 커버리지를 업데이트합니다.

모든 평가(Eval) 실행을 공유된 LangSmith 프로젝트로 추적하기 때문에, 팀 내 누구라도 즉시 참여하여 문제를 분석하고, 수정하며, 특정 평가의 가치를 재평가할 수 있습니다. 이는 양질의 평가를 추가하고 유지 관리하는 데 있어 공동의 책임감을 형성합니다. 또한, 수많은 평가에 걸쳐 많은 모델을 실행하는 것은 비용이 많이 들 수 있으므로, 타겟팅된 평가(Targeted evals)를 통해 에이전트를 개선하면서 비용을 절감할 수 있습니다.

이 블로그에서는 다음 내용을 다룹니다:

• 데이터 큐레이션(Curate) 방법
• 지표(Metrics) 정의 방법
• 평가(Evals) 실행 방법

데이터 큐레이션 방법

평가 데이터를 확보하는 몇 가지 방법이 있습니다:

• 우리 에이전트를 직접 사용(Dogfooding)하며 얻은 피드백 활용
• 외부 벤치마크(Terminal Bench 2.0 또는 BFCL 등)에서 선택된 평가를 가져온 후, 특정 에이전트에 맞게 조정
• 중요하다고 생각되는 동작에 대해 직접 수동으로 작성한 (Artisanal) 평가 및 유닛 테스트(Unit tests)

💡

참고: 우리는 SDK 유닛 및 통합 테스트(System prompt passthrough, Interrupt config, Subagent routing)를 모델 능력 평가(Model capability evals)와 분리합니다. 어떤 모델이든 해당 테스트를 통과하므로, 이를 점수 산정에 포함하는 것은 아무런 신호(Signal)를 제공하지 못합니다. 유닛 및 통합 테스트는 반드시 작성해야 하지만, 이 블로그는 오로지 모델 능력 평가에만 집중합니다.

에이전트 직접 사용(Dogfooding) 및 트레이스(Traces) 검토는 훌륭한 평가 소스입니다

이 방식은 실수를 찾아내는 것을 가능하게 합니다. 트레이스는 에이전트의 동작을 이해할 수 있는 데이터를 제공합니다. 트레이스는 종종 방대하기 때문에, 우리는 Polly 또는 Insights와 같은 내장된 에이전트를 사용하여 대규모로 분석합니다. 여러분도 다른 에이전트(Claude Code 또는 Deep Agents CLI 등)와 LangSmith CLI와 같이 트레이스를 내려받을 수 있는 방법을 결합하여 동일하게 수행할 수 있습니다. 우리의 목표는 각 실패 모드(Failure mode)를 이해하고, 수정안을 제안하며, 에이전트를 다시 실행하고, 시간이 지남에 따른 진행 상황과 퇴보(Regressions)를 추적하는 것입니다.

예를 들어, 버그 수정 PR(Pull Requests)의 상당 부분은 현재 우리의 오픈 소스 백그라운드 코딩 에이전트인 Open SWE를 통해 수행됩니다. 이를 사용하는 팀들은 서로 다른 컨텍스트(Context), 관습(Conventions), 그리고 목표를 가진 수많은 다양한 코드베이스를 다룹니다. 이는 자연스럽게 실수를 유발합니다. Open SWE의 모든 상호작용은 추적되므로, 이러한 상호작용은 동일한 실수가 다시 발생하지 않도록 보장하는 평가(Evals)로 쉽게 전환될 수 있습니다.

다른 평가들은 함수 호출(Function calling)을 위한 BFCL과 같은 기존 벤치마크에서 가져오거나 조정하여 사용합니다. 코딩 작업의 경우, Harbor와 통합하여 Terminal Bench 2.0 작업과 같은 데이터셋의 선택된 작업들을 샌드박스(Sandboxed) 환경에서 실행합니다. 많은 평가가 처음부터 새로 작성되며, read_file 도구를 테스트하는 것과 같이 격리된 동작을 관찰하기 위한 집중적인 테스트 역할을 합니다.

우리는 테스트 대상에 따라 평가를 그룹화합니다

에이전트가 어떻게 성능을 내는지(단일 수치나 개별 실행이 아닌 중간 관점의 뷰)를 파악하기 위해서는 평가의 분류 체계(Taxonomy)를 갖추는 것이 도움이 됩니다.

우리가 정의한 몇 가지 카테고리와 테스트 대상은 다음과 같습니다:

현재 모든 평가는 작업에 대한 에이전트의 엔드 투 엔드(End-to-end) 실행입니다. 우리는 평가 구조의 다양성을 의도적으로 권장합니다. 어떤 작업은 입력 프롬프트로부터 단 한 번의 단계로 완료되는 반면, 어떤 작업은 다른 모델이 사용자를 시뮬레이션하며 10회 이상의 턴(Turns)을 거치기도 합니다.

지표(Metrics)를 정의하는 방법

에이전트에 사용할 모델을 선택할 때, 우리는 정확성(Correctness)부터 시작합니다. 만약 모델이 우리가 중요하게 생각하는 작업을 신뢰성 있게 완료할 수 없다면, 다른 것은 아무런 의미가 없습니다. 우리는 평가에서 여러 모델을 실행하며, 발견되는 문제들을 해결하기 위해 시간이 지남에 따라 하네스(Harness)를 개선해 나갑니다.

정확성을 측정하는 방법은 무엇을 테스트하느냐에 따라 달라집니다. 대부분의 내부 평가는 "에이전트가 도구 호출(Tool calls)을 병렬화했는가?"와 같은 커스텀 어설션(Custom assertions)을 사용합니다. BFCL과 같은 외부 벤치마크는 데이터셋의 정답(Ground truth)과 정확히 일치하는지 확인하는 매칭 방식을 사용합니다. 에이전트가 메모리에 올바른 내용을 유지했는지 여부와 같이 정확성이 의미론적(Semantic)인 평가의 경우, LLM-as-a-judge 방식을 사용합니다.

여러 모델이 그 기준을 통과하고 나면, 이제 효율성(Efficiency) 단계로 넘어갑니다. 동일한 작업을 해결하는 두 모델이라도 실제로는 매우 다르게 동작할 수 있습니다. 한 모델은 불필요한 단계를 더 거치거나, 불필요한 도구 호출(Tool calls)을 수행하거나, 모델 크기 때문에 작업을 더 느리게 진행할 수 있습니다. 프로덕션(Production) 환경에서 이러한 차이는 더 높은 지연 시간(Latency), 더 높은 비용, 그리고 더 나쁜 전반적인 사용자 경험으로 나타납니다.

종합적으로, 각 평가 실행(Evaluator run)에 대해 우리가 측정하는 지표는 다음과 같습니다:

해결률(Solve rate)은 에이전트가 작업을 얼마나 빨리 해결하는지를 측정하며, 예상되는 단계 수로 정규화(Normalized)합니다. 지연 시간 비율(Latency ratio)과 마찬가지로, 모델의 왕복 시간(Round trips), 제공자 지연 시간(Provider latency), 잘못된 경로(Wrong turns), 그리고 도구 실행 시간(Tool execution time)을 포함하여 작업을 해결하는 엔드 투 엔드(End-to-end) 시간을 포착합니다. 이상적인 궤적(Ideal trajectory)을 정의할 수 있는 간단한 작업의 경우, 해결률은 주어진 에이전트의 작업 시간만 측정하면 되기 때문에 지연 시간 비율보다 다루기 쉬울 수 있습니다.

이를 통해 타겟팅된 평가 세트(Eval set)를 사용하여 모델을 선택하는 간단한 방법을 얻을 수 있습니다:

• 먼저 정확성(Correctness) 확인: 실제로 중요하게 생각하는 작업에서 어떤 모델이 충분히 정확한가?
• 그다음, 효율성(Efficiency) 비교: 충분히 우수한 모델들 중에서 정확성, 지연 시간, 비용 사이의 최적의 트레이드오프(Tradeoff)를 제공하는 모델은 무엇인가?

평가 관련 유용한 지표의 예시

모델 비교를 실행 가능한 수준으로 만들기 위해, 우리는 모델이 어떻게 성공하고 실패하는지를 조사합니다. 이를 위해서는 정확성을 넘어

에이전트의 이상적인 궤적(trajectory)은 다음과 같을 수 있습니다:

• 필요한 도구 호출(tool calls)을 최소화함 (예: 사용자 해결 → 위치 해결 → 시간 및 날씨 가져오기)
• 가능한 경우 독립적인 도구 호출을 병렬화(parallelize)함
• 불필요한 중간 단계(intermediate turns) 없이 최종 답변을 생성함

이상적인 궤적: 4단계, 4번의 도구 호출, 약 8초

이제 기술적으로는 여전히 정확하지만, 효율성이 떨어지는 궤적과 비교해 보겠습니다.

비효율적인 궤적: 6단계, 5번의 도구 호출, 약 14초

정확하지만 비효율적인 궤적: 6번의 에이전트 단계, 5번의 도구 호출, 불필요한 도구 호출을 포함하며 도구 호출을 병렬화하지 않음.

위의 예시들은 설명을 돕기 위한 것입니다. REPL은 이 특정 작업을 훨씬 더 빠르게 해결할 수도 있지만, 더 단순한 도구 호출(tool-calling) 버전이 개념을 설명하기에 더 쉽습니다.

두 실행 모두 정확하지만, 두 번째 실행은 지연 시간(latency)과 비용을 증가시키고 실패할 가능성을 더 많이 만듭니다.

이러한 프레임워크를 통해 우리는 평가(evals) 과정에서 정확성과 효율성을 모두 평가할 수 있습니다. 우리는 실행 결과들을 실험 비교에 사용할 수 있는 측정 가능한 수치로 추출하기 위해 지표(metrics)를 유지하고 업데이트합니다.

위의 예시에서, 비효율적이지만 정확한 실행은 다음과 같은 점수를 받게 됩니다:

평가(evals)를 실행하는 방법

우리는 변경 사항이 깨끗하고 재현 가능한 환경에서 실행될 수 있도록 CI(지속적 통합)에서 평가를 실행하기 위해 GitHub Actions와 함께 pytest를 사용합니다. 각 평가는 주어진 모델로 Deep Agent 인스턴스를 생성하고, 여기에 작업을 입력하며, 정확성 및 효율성 지표를 계산합니다.

또한 비용을 절감하고 타겟팅된 실험을 측정하기 위해 태그(tags)를 사용하여 평가의 일부 서브셋(subset)만 실행할 수도 있습니다. 예를 들어, 많은 로컬 파일 처리 및 합성이 필요한 에이전트를 구축하는 경우, file_operations 및 tool_use 태그가 지정된 서브셋에 집중할 수 있습니다.

export LANGSMITH_API_KEY="lsv2_..."

uv run pytest tests/evals --eval-category file_operations --eval-category tool_use --model baseten:nvidia/zai-org/GLM-5

우리의 평가 아키텍처와 구현은 Deep Agents 리포지토리(repository)에 오픈 소스로 공개되어 있습니다.

다음 단계

우리는 평가 스위트(eval suite)를 확장하고 있으며, 오픈 소스 LLM(Large Language Models)에 관한 더 많은 작업을 진행하고 있습니다! 곧 공유하게 될 흥미로운 내용들은 다음과 같습니다:

• 다양한 평가 카테고리(eval categories) 전반에서 오픈 모델(Open Models)이 폐쇄형 프론티어 모델(closed frontier models)과 비교했을 때 어느 정도의 성능을 보이는지
• 실시간으로 작업을 수행하는 에이전트(agents)를 자동 개선(auto-improve)하기 위한 메커니즘으로서의 평가(Evals)
• 시간이 지남에 따라 에이전트별로 평가를 어떻게 유지, 축소 및 확장하는지에 대한 공개적인 공유

Deep Agents는 완전한 오픈 소스입니다. 직접 사용해 보시고 의견을 들려주세요! 우리는 팀들이 훌륭한 에이전트와 평가(evals)를 구축할 수 있도록 도울 수 있게 되어 매우 기쁩니다.