Ara Khan: 평가가 엉망이지만 어쨌든 사용하라
Ara Khan: 평가가 엉망이지만 어쨌든 사용하라
핵심 갈등: 객관적 지표 vs. 감각
AI 개발에서는 평가(evals)에 대해 두 가지 잘못된 진영으로 나뉘곤 합니다. 객관적 지표 진영은 벤치마크 점수(ELO나 SweetBench 등)를 있는 그대로 받아들이고, 감각/바이브 진영은 숫자를 완전히 무시하고 주관적인 느낌에 의존합니다.
두 접근 모두 충분하지 않습니다. 객관적인 벤치마크는 연구소가 실제 유용성을 개선하지 않고도 높은 점수를 얻도록 조작될 수 있으며, "바이브"에만 의존하면 체계적인 개선이 불가능합니다. 효과적인 길은 중간에 있습니다: 평가를 절대적인 진리로 보지 않고, 반복적인 개발을 위한 중요한 휴리스틱으로 활용하는 것입니다.
외부 평가를 해석하기 위한 휴리스틱
모델 연구소나 다른 기업이 제공하는 벤치마크를 평가할 때, 개발자는 마케팅 숫자에 현혹되지 않기 위해 세 가지 주요 휴리스틱을 적용해야 합니다:
1. 연구소 평가를 근사치로 간주하기
모델 연구소(예: GPT 또는 Claude 출시)의 숫자를 "신의 말씀"처럼 여기지 마세요. 일반적으로 꽤 괜찮은 근사치이지만, 절대적인 우월성의 증거로 받아들이기보다는 신중히 활용해야 합니다.
2. 초기 채택보다 안정성 우선하기
빠르게 변하는 AI 환경에서는 "최고" 모델이 몇 달마다 바뀝니다. 새로운 모델이 출시되는 즉시 절대적인 최전선 모델로 전환하려 하면 과도한 정신적 부담이 발생합니다. 권장 방법은 몇 주 정도 상황이 안정될 때까지 기다렸다가 새로운 모델을 프로덕션 워크플로에 통합하는 것입니다.
3. 문제에 특화된 벤치마크 찾기
일반 목적 벤치마크는 실제 유용성을 반영하지 못하는 경우가 많습니다. 예를 들어, SWE‑bench는 한때 코딩 에이전트의 표준이었지만 결국 "포화" 상태에 이르러 모델들이 너무 높은 점수를 받아 품질 차이를 구분하지 못하게 되었습니다. 개발자는 쇼핑, 인프라, 특정 코딩 작업 등 자신의 문제 영역을 밀접하게 반영하는 평가를 찾아야 합니다.
코딩 에이전트를 위한 에이전시 평가 구현
에이전트를 평가하는 것은 단일 턴 LLM 응답을 평가하는 것과 근본적으로 다릅니다. 에이전트는 여러 턴을 수행하고, 다양한 도구를 사용하며, 서로 다른 경로를 따라가기 때문에 답변 공간이 사실상 무한합니다.
실제 작업으로의 전환
많은 초기 평가는 피보나치 수열 구현과 같은 사소한 학술 문제에 초점을 맞췄습니다. 이는 전문 소프트웨어 엔지니어링에 적용되지 않습니다. 이를 해결하기 위해 Cline 팀은 Terminal Bench(Stanford ALOT Institute에서 개발)를 채택했으며, 여기에는 데이터베이스 문제, 레이스 컨디션, 프론트엔드 버그 등을 포함한 89개의 실제 소프트웨어 엔지니어링 작업이 들어 있습니다.
에이전시 평가 프로세스
결정론적 테스트와 달리, 에이전시 평가는 에이전트가 장시간(때로는 30‑45분) 실행되도록 허용하고, 웹 검색, 라이브러리 설치, 파일 편집 등을 수행하게 합니다. 성공 여부는 결정론적 유닛 테스트를 통해 최종 출력이 실행되고 요구된 테스트를 통과하는지 확인함으로써 측정됩니다.
추적해야 할 핵심 지표
품질과 비용의 균형을 맞추기 위해 개발자는 다음을 추적해야 합니다:
- 턴 수: 에이전트가 수행한 반복 횟수.
- 도구 호출: 사용된 도구의 호출 횟수.
- 토큰 사용량: 실행 전체에 소요된 토큰 비용.
- 실행 시간: 전체 벽시계 시간.
견고한 평가 인프라 구축
평가를 효과적으로 실행하고 작업 간 간섭을 방지하려면 격리가 필수입니다.
- 컨테이너화: 각 평가 작업은 자체 종속성과 환경을 가진 격리된 컨테이너에서 실행되어야 합니다. 이는 한 작업이 다른 작업의 환경을 오염시키는 것을 방지합니다.
- 병렬화: 평가를 순차적으로 실행하면 몇 시간이 걸릴 수 있습니다. Modal과 같은 인프라를 사용하면 컨테이너화된 환경을 병렬로 실행하여 피드백 루프 시간을 크게 단축할 수 있습니다.
반복적 개선 루프
평가는 개발자가 철학적 추측에서 엔지니어링으로 전환하도록 돕습니다. "실패 포트폴리오 할당"을 분석함으로써 오류를 넓은 범주(예: "파일 읽기 실패", "추론 오류", "설치 루프")로 분류할 수 있습니다.
세 가지 개선 영역
- 구역 1: 명백한 결함 –
read_file도구가 깨졌거나 체크포인트가 실패하는 등 근본적인 문제를 해결합니다. 이는 에이전트를 작동 가능하게 만듭니다. - 구역 2: 힐 클라이밍 – 최적화의 주요 영역입니다. 개발자는 프롬프트 엔지니어링을 다듬고, 도구 정의를 조정하며, 재시도 로직을 최적화해 에이전트의 문제 해결 접근 방식을 개선합니다.
- 구역 3: 위험 구역 – 과적합 위험이 존재합니다. 개발자는 벤치마크 점수만을 위해 특정 해킹을 추가해 테스트를 통과시키면서 일반 성능을 저하시키는 일을 피해야 합니다.
삼중 정렬
성공적인 에이전트 성능은 세 요소 간의 정렬을 필요로 합니다:
- 모델: 기본 LLM의 능력.
- 하네스: 에이전트 스캐폴딩 및 도구 구현.
- 문제: 실제 해결하려는 작업.
우수한 모델이라도 하네스가 형편없으면 실패합니다. 반복적인 평가는 실패가 모델의 지능 때문인지, 에이전트 스캐폴딩의 결함 때문인지 식별하는 데 도움을 줍니다.
요약: Ara Khan은 AI 에이전트 개발자가 '바이브'를 넘어 구조화된 평가를 사용해야 한다고 설명합니다. 비록 평가에 결함이 있더라도, 이를 통해 에이전트 성능과 도구 신뢰성을 반복적으로 개선할 수 있습니다.
제목: Ara Khan: 평가가 엉망이지만 어쨌든 사용하라