Better Harness: 평가(Evals)를 활용한 Harness Hill-Climbing 레시피
요약
더 나은 에이전트를 구축하기 위해 평가(Evals)를 학습 신호로 활용하여 harness를 반복적으로 개선하는 'Harness Hill-Climbing' 방법론을 소개합니다. 평가를 단순한 검증 도구가 아닌 에이전트의 행동을 가이드하는 학습 데이터로 정의하며, 데이터 확보부터 최적화, 검토에 이르는 복합 시스템 엔지니어링 접근 방식을 제안합니다.
핵심 포인트
- 평가(Evals)는 에이전트가 실제 환경에서 보여야 할 행동을 인코딩하는 학습 데이터 역할을 합니다.
- Harness 개선은 데이터 확보, 실험 설계, 최적화, 검토 및 수락의 과정을 거치는 복합 시스템 엔지니어링입니다.
- 에이전트가 특정 평가에 과적합(overfit)되지 않고 일반화(generalize)할 수 있도록 설계하는 것이 중요합니다.
- 수동 큐레이션과 프로덕션 트레이스 등을 통해 양질의 평가 데이터를 확보해야 합니다.
핵심 요약 (Key Takeaways)
요약 (TL;DR): 더 나은 harness를 구축함으로써 더 나은 agent를 만들 수 있습니다. 하지만 자율적으로 "더 나은" harness를 구축하기 위해서는, 이를 바탕으로 "hill-climb (언덕 오르기)" 할 수 있는 강력한 학습 신호(learning signal)가 필요합니다. 우리는 평가(evals)를 해당 신호로 사용하는 방법과, agent가 과적합(overfit)되는 대신 일반화(generalize)할 수 있도록 돕는 설계 결정 사항들을 공유합니다. Better-Harness는 평가(evals)를 통해 harness를 반복적으로 확보하고 개선하는 시스템입니다.
평가(Evals)는 agent를 위한 학습 데이터입니다
전통적인 머신러닝 (Machine Learning)에서 학습 데이터는 모델의 학습 과정을 안내합니다. 각 학습 예시는 모델의 가중치(weights)를 "정확성"을 향해 업데이트하는 그래디언트 (gradient)를 제공합니다. 우리는 agent를 위해서도 이와 유사한 학습 루프를 가지고 있습니다.
평가(Evals)는 우리가 agent가 실제 운영 환경에서 보여주기를 원하는 행동을 인코딩합니다. 이것들은 harness 엔지니어링을 위한 "학습 데이터"입니다. 각 평가 케이스는 "agent가 올바른 행동을 취했는가" 또는 "올바른 결과를 생성했는가?"와 같은 신호를 제공합니다. 이 신호는 harness에 제안될 다음 수정 사항을 안내합니다.
우리가 모델 학습을 위해 데이터 품질과 큐레이션에 쏟는 것과 동일한 엄격함과 주의를 평가(eval) 설계에도 기울여야 합니다. 우리는 이전 포스트인 Deep Agents를 위한 평가(evals) 구축 방법에서 데이터 품질의 중요성에 대해 논의한 바 있습니다.
Stanford의 Meta-Harness와 DeepMind의 Auto-Harness를 포함하여, harness를 최적화하는 단계를 공식화한 훌륭한 최근 연구들이 있습니다. 우리는 또한 이전에 harness 레이어를 미세 조정함으로써 Terminal Bench 2.0을 hill-climb 하기 위한 Harness 개선 루프를 공유한 적이 있습니다. 우리는 업데이트 알고리즘 자체에 대해 수행할 수 있는 훌륭한 미래 연구가 있다고 생각하지만, harness 개선은 여기서 우리가 이야기하는 업데이트 알고리즘을 넘어서는 복합 시스템 (compound system)입니다.
Better-Harness는 복합 시스템 엔지니어링 (compound systems engineering)에 대한 접근 방식입니다.
데이터 확보 (data sourcing) → 실험 설계 (experiment design) —> 최적화 (optimization) —> 검토 및 수락 (review & acceptance)
따라서 우리는 업데이트 루프 (update loop)와 병행되는 실질적인 세부 사항들을 포함합니다. 예를 들어, 처음에 평가(evals)를 어떻게 확보하는지, 과적합 (overfitting)에 대비하여 어떻게 설계하는지, 시간이 지남에 따라 트레이스 (traces)를 어떻게 저장하는지, 그리고 프로덕션 (production)에 배포하는 모든 것에 대해 건전성 검사 (sanity check)를 수행하기 위해 업데이트를 어떻게 수동으로 검토하는지 등이 여기에 해당합니다.
양질의 평가(Evals) 확보하기
평가 (Evals)는 Harness Hill-Climbing 프로세스를 구동하는 토대입니다. 다음은 우리가 평가를 확보, 큐레이션 (curate), 그리고 사용하는 실질적인 방법들입니다.
수동 큐레이션 (Hand-curated). 특정 작업에 대해, 팀은 에이전트 (agent)가 프로덕션에서 수행해야 한다고 생각하는 바를 포착하는 예시들을 수동으로 작성합니다. 이러한 예시들은 종종 가치가 높지만, 대규모로 생성하기는 어렵습니다.
프로덕션 트레이스 (Production traces). 모든 에이전트 상호작용은 실패 사례가 평가 케이스 (eval cases)가 되는 트레이스 (trace)를 생성합니다. 평가 자료를 위해 트레이스를 마이닝 (mining)하는 것은 평가를 시간이 지남에 따라 개선할 수 있는 레버리지(leverage)가 높고 처리량 (throughput)이 많은 방법입니다. 에이전트를 평가에 실행하기 전이라도, 종종 우리 에이전트를 도그푸딩 (dogfooding)하는 팀이 Slack에 트레이스 (Trace) 링크와 함께 오류를 직접 보고하기도 합니다. 우리는 에이전트를 도그푸딩하고 모두가 볼 수 있도록 피드백을 직접 공유하는 것을 권장하며, 이는 에이전트 행동에 대한 공유된 지식을 구축하는 데 도움이 됩니다.
외부 데이터셋 (External datasets). 이러한 데이터셋들은 유용하지만, 에이전트를 개선하는 데 사용되는 테스트 케이스가 원하는 행동을 반영하도록 하기 위해 수동으로 큐레이션 (curated)될 필요가 있습니다. 종종 중요한 행동을 측정할 수 있도록 각 작업이 조정됩니다.
모든 것에 태그 달기 (Tag everything). 모든 평가는 "도구 선택 (tool selection)", "다단계 추론 (multi-step reasoning)" 등과 같은 행동 카테고리에 태그가 지정됩니다. 태그를 통해 의미 있는 홀드아웃 세트 (holdout sets)와 타겟팅된 실험이 가능해집니다. 또한 평가의 하위 집합 (subsets)만 실행할 수 있으므로 많은 비용을 절감할 수 있습니다.
일반화되는 학습 시스템 구축하기
모든 학습 시스템의 이상적인 결과는 **일반화 (generalization)**입니다. 우리는 실제 환경에서 원하는 행동의 분포 (distribution)를 포착하는 입력 신호를 제공합니다. 시스템은 이에 맞춰 적합 (fit)해지며, 그 후 한 번도 본 적 없는 새로운 입력에 대해서도 "그냥 작동하게" 됩니다.
명백한 문제: 우리에게 무한한 데이터가 있는 것은 아닙니다.
해결책: 중요한 행동 양식(behaviors)을 선별된 평가(evals)에 인코딩(encode)하십시오. 양(quantity)보다 질(quality)이 중요합니다. 당신이 중요하게 생각하는 행동 양식을 포괄하는, 태깅이 잘 된 소수의 평가 세트가 노이즈가 많고 커버리지만 높은 수천 개의 평가보다 훨씬 낫습니다.
미묘한 문제 → 에이전트(agents)는 유명한 부정행위자입니다: 모든 학습 시스템은 에이전트가 자신이 볼 수 있는 기존의 평가를 통과하기 위해 자신의 구조를 과적합(overfit)시키는 보상 해킹(reward hacking)에 취약합니다. 루프(loop)는 단지 "숫자를 높이는 것"만을 원할 뿐 일반화(generalization)에 대해서는 알지 못하기 때문에 이는 타당한 현상입니다. 우리는 과적합을 피하기 위해 프롬프트(prompt)를 사용하지만, 이것이 완벽하지는 않습니다.
해결책: 홀드아웃 세트(Holdout sets)가 진정한 일반화의 대리 지표(proxy)가 됩니다. 우리는 인간의 검토(human review)를 두 번째 신호로 결합하여, 프로덕션(prod)에서 원치 않는 행동은 피하면서 점수를 향상시킬 수 있는 반자동화된 시스템을 확인했습니다.
Better-Harness: Harness의 힐 클라이밍(hill climbing)을 위한 레시피
우리는 각 단계에서 평가(evals)를 신호로 사용하여 Harness를 자율적으로 개선하기 위한 스캐폴드(scaffold)를 만들었습니다. 연구용 버전은 여기에 오픈 소스로 공개되어 있으며, 주요 단계는 다음과 같습니다:
평가(Evals) 소싱 및 태깅. 이는 직접 작성한 평가(evals), 프로덕션 트레이스(production traces)에서 추출한 평가, 그리고 외부 데이터셋을 사용하거나 조정하는 방식이 혼합된 형태입니다. 우리는 각 평가를 행동 범주(예: 다단계 검색(multi-step retrieval))로 태깅하며, 포화 상태에 도달했거나 에이전트 및 현재 모델 세대에게 더 이상 유용하지 않다고 판단되는 평가는 정기적으로 제거합니다. 카테고리별 데이터 분할. 최적화(Optimization) 세트와 홀드아웃(Holdout) 세트를 생성합니다. 이는 매우 중요합니다! 우리는 자율적인 힐클라이밍(hill-climbing)이 작업에 과적합(overfit)되는 경향이 있음을 발견했으며, 홀드아웃 세트는 학습된 최적화가 이전에 보지 못한 데이터에서도 작동하도록 보장합니다. 이때 일반적인 분포는 기존 평가와 일치해야 합니다. 이는 실제 프로덕션 환경과 유사한 모습을 반영합니다. 베이스라인(Baseline) 실행. 어떠한 수정 사항을 적용하기 전에 최적화 및 홀드아웃 세트에서 베이스라인 실험을 실행합니다. 이를 통해 모든 업데이트를 업데이트 단계의 기준점에 고정합니다. 최적화. 각 반복(iteration)은 선택적인 인간 검토(human review)와 함께 자율적으로 실행됩니다:
진단(Diagnose): 트레이스(traces)로부터 수행합니다. 점수(Scores)는 카테고리별 성능을 집계하며, 트레이스는 무엇이 왜 잘못되었는지에 대한 세부 정보를 보여줍니다.
실험(Experiment): 타겟팅된 하네스(harness) 변경을 수행합니다. 혼란 변수(confounding)를 피하기 위해 한 번에 하나의 변경 사항으로 범위를 제한하지만, 이는 프롬프트와 도구(tool)를 동시에 업데이트하여 시스템이 함께 잘 작동하도록 하는 것을 의미할 수도 있습니다.
검증(Validate): 각 단계에서 루프는 제안된 변경 사항이 기존의 통과 사례에서 퇴보(regression)를 피하면서 새로운 평가를 통과하는 데 도움이 되었는지 확인합니다. 일부 변경 사항이 일부 퇴보를 일으키면서도 전체적인 순 점수(net overall score)는 상승하는 경우가 흔합니다. 에이전트는 이러한 퇴보에 대한 컨텍스트를 파악하여, 기존 업데이트의 이점을 잃지 않으면서 다음 업데이트에서 이를 수정하도록 시도할 수 있습니다.
인간 검토(Human review): 우리는 변경 사항과 지표가 놓치는 엣지 케이스(edge cases)를 수동으로 검토합니다. 여기에는 최적화 세트에 과적합된 지침(instructions)이 포함되는 경우가 많으며, 이러한 지침은 일반화(generalization)를 해치지는 않지만 결국 토큰 낭비를 초래합니다. 이는 우리에게 과적합을 방지하기 위한 또 다른 무결성 검사(sanity check) 및 게이트 역할을 합니다.
하네스 변경 사례
최적화 루프(optimization loop)가 발견하고 검증할 수 있는 변경 사항의 유형은 다음과 같습니다:
프롬프트 및 지시문(instruction) 업데이트. 가장 흔한 변경 사항입니다. 에이전트가 도구(tool)의 출력 형식을 계속 잘못 해석하거나, 먼저 명확한 질문을 던져야 할 상황에서 도구를 호출하는 데 너무 공격적일 때 발생합니다. 해결책은 "의존적인 정보를 가진 여러 파일을 쿼리할 때는 정보를 파일 시스템에 오프로드(offload)한 후 최종 답변을 내놓기 전에 다시 집계(re-aggregate)하십시오"와 같이 타겟팅된 지시문을 추가하는 것입니다.
도구 또는 도구 설명의 추가 및 업데이트. 에이전트가 새로운 도구를 언제 사용해야 하는지 문맥을 파악하는 데 실패할 수 있습니다. 수정 사항에는 사용 방법, 이 도구를 체이닝(chaining)하는 방법의 예시, 업데이트된 도구 설명, 그리고 유사한 도구들 사이의 모호함을 제거하기 위한 전체 도구 세트(tool suite) 편집 등이 포함됩니다.
Better-Harness 루프의 결과
우리는 평가(evals)의 하위 집합을 사용하여 Claude Sonnet 4.6 및 Z.ai의 GLM-5를 대상으로 이 접근 방식을 테스트했습니다. 참고: 우리는 deepagents에서 더 큰 평가 세트를 사용하여 많은 모델에 걸쳐 Better-Harness를 일반화하는 다른 작업을 진행 중입니다. 목표는 우리의 평가에 맞춰 튜닝된 각 모델의 미묘한 차이(nuances)를 포착한 일련의 **모델 프로필(model profiles)**을 공개 산출물(public artifact)로 게시하는 것입니다.
우리는 기존 평가 카테고리에서 작고 대표성 있는 샘플을 수집하였고, 일반화(generalization)를 평가하기 위해 해당 샘플을 힐 클라이밍(hill-climbing)용 세트와 홀드아웃(holdout) 세트로 나누었습니다. 크거나 비용이 많이 드는 평가 세트의 경우, 힐 클라이밍을 수행할 좋은 세트를 구성하기 위해 대표/층화 추출(representative/stratified sampling)을 권장합니다. 이것이 잘 작동하면 더 큰 세트로 확장할 수 있습니다.
주요 실험 목표: 우리의 평가에서 실패 모드(failure modes)를 발견하고 수정하는 것입니다. 평가 성능을 높이는 일반적인 변경 사항을 하네스(harness)로 다시 이식(port)합니다.
우리는 이전에 후속 질문을 과도하게 던지거나 새로운 도구들을 체이닝하는 과정에서의 오류와 같은 실패 모드를 관찰했습니다. 최적화 세트에서 힐 클라이밍을 수행한 후, tool_selection 및 followup_quality라는 두 가지 카테고리를 사용하여 홀드아웃 세트에서 최종 하네스를 평가했습니다.
search-then-email과 같이 기본 하네스(harness)에 새로운 도구를 주입하는 평가(evals)의 경우, 루프를 통해 해당 도구들을 어떻게 사용하고 조합해야 하는지에 대한 더 나은 설명(descriptions)을 발견했습니다. 이는 다양한 도메인에 걸쳐 버티컬 에이전트(vertical agents)를 구축하는 개발자들에게 유망한데, 최적화 루프(optimization loops)가 문맥 내의 작업 특성에 잘 적응하기 때문입니다.
평가(Evals) 유지 관리 및 회귀(Regressions)
힐 클라이밍(hill climbing)과 더불어, 평가는 시간이 지남에 따라 발생하는 회귀(regressions)를 명시적으로 포착하고 방지합니다. 일단 우리 에이전트가 특정 케이스를 올바르게 처리하게 되면, 그 성과를 잃고 싶지 않기 때문입니다. 이때 평가는 회귀 테스트(regression test)가 됩니다. 이는 테스트 주도 개발(TDD, Test Driven Development)과 같은 전통적인 소프트웨어 공학의 아이디어와 유사합니다. 시간이 흐르며 많은 변경 사항이 발생함에 따라 일부 회귀는 불가피하게 발생하므로, 우리는 항상 통과하기를 원하는 평가의 하위 집합을 선택하고, 이들이 갑자기 실패할 경우 실행 결과(run)를 의심스럽게 살펴봅니다.
우리는 평가 제품군(eval suite)이 단조 증가(monotonically)해야 한다고 생각하지 않으며, 평가의 대청소(spring cleaning)는 유익합니다! 우리는 더 지능적인 모델의 등장이나 에이전트에 대해 우리가 원하는 행동의 변화로 인해 특정 평가가 여전히 유용한지 정기적으로 평가합니다.
미래: 자동 오류 탐지 및 수정
이 접근 방식이 작동하는 이유는 트레이스(traces)가 밀도 높은 피드백 신호(feedback signal)를 제공하기 때문입니다. 평가는 트레이스를 활용하여 버전 간을 비교하고, 어떤 변경 사항이 더 나은 점수(이는 더 나은 사용자 경험의 좋은 대리 지표(proxy)가 되어야 합니다)에 기여하는지를 수치적으로 근거를 제시할 수 있습니다.
전반적으로, 우리는 다음과 같은 목적을 위해 에이전틱 컴퓨팅(agentic compute)을 트레이스에 집중시킵니다:
오류 자동 도출. 우리는 프로덕션 환경에서의 실패를 분류하고 클러스터링하기 위해 에이전트 트레이스를 지속적으로 모니터링하고자 합니다.
프로덕션으로부터 평가 생성. 에이전트가 실수를 한 트레이스는 하나의 평가 케이스가 됩니다. 사용자가 에이전트를 교정한 트레이스는 훨씬 더 좋습니다. 플라이휠(flywheel) 효과: 더 많은 사용 → 더 많은 트레이스 → 더 많은 평가 → 더 나은 하네스
하네스 버전 비교. 트레이스를 나란히 비교(side-by-side comparison)함으로써 새로운 행동에 기여한 하네스의 변경 사항이 무엇인지 확인할 수 있습니다.
모든 트레이스(trace)는 잠재적인 평가(eval)를 생성하기 위한 가치 있는 데이터를 포함하고 있습니다. 그리고 모든 (좋은) 평가(eval)는 하네스(harness)를 더 개선합니다. 이를 용이하게 하기 위해, 모든 에이전트 실행은 전체 트레이스와 함께 LangSmith에 기록됩니다. 이를 통해 우리는 최적화 루프(optimization loop)를 위한 트레이스 수준의 진단(trace-level diagnosis), 회귀 탐지(regression detection)를 위한 프로덕션 모니터링(production monitoring), 그리고 평가(eval) 생성을 위한 트레이스 마이닝(trace mining)을 수행할 수 있습니다.
우리의 주요 시사점 및 진행 중인 작업:
평가(Evals)는 자율적인 하네스 엔지니어링을 위한 학습 데이터입니다. 데이터 품질, 훈련/테스트 분할(train/test splits), 일반화 검사(generalization checks)와 같이 머신러닝(ML) 학습을 가능하게 하는 동일한 원칙들이 에이전트 개발에도 적용됩니다.
모델을 하네스에 맞추기(Fitting models to harnesses). 모든 모델을 각각의 하네스에 맞추는 데에는 방대한 양의 작업이 들어갑니다. 예를 들어, codex prompting guide는 그들의 Edit 도구에 대해 특정 형식을 제안합니다. 이는 더 큰 탐색 공간(search space)과 평가 세트(eval set)를 요구하며, 우리는 이를 수행하고자 하는 모든 팀을 위해 실제 사례가 어떤 모습인지 공유하게 되어 기쁩니다.
전반적으로, 트레이싱(tracing)을 수행하고 좋은 평가(evals)를 유지하는 것이 이 시스템을 실제로 작동하게 만드는 핵심입니다. 팀과 함께 이 부분에 조기에 투자하여, 자율적으로 개선되는 에이전트의 미래를 함께 만들어 갑시다. 우리는 빌더들이 실험해 볼 수 있도록 이 스캐폴드(scaffold)의 연구용 버전을 오픈 소스로 공개했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 LangChain Blog의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기