Five hard earned lessons about Evals - Ankur Goyal, Braintrust

영상 링크: Five hard earned lessons about Evals — Ankur Goyal, Braintrust
채널명: AI Engineer

Evals(평가 시스템)에 대해 어렵게 얻은 5가지 교훈 핵심 요약

• 발표자는 다양한 조직에서 Evals(모델 평가 시스템)의 도입 및 개선을 통해 얻은 중요한 5가지 교훈을 공유함
• 성공적인 Evals의 징후로 신모델 출시 24시간 내 제품 업그레이드, 사용자 피드백의 즉각적 평가 반영, 출시 전에 적용 가능성을 정확히 파악할 수 있는 공격형 평가 체계 구축 등을 제시
• 진정한 평가 시스템은 단순 공개 데이터셋, LLM 판정에만 의존하지 않고 데이터와 스코어러(채점 함수)를 직접 엔지니어링해야 함을 강조
• 현대 LLM 기반 에이전트에서는 프롬프트의 컨텍스트, 툴 정의 및 출력 설계가 모델 성능에 대단히 큰 영향을 미침 (예: JSON 대신 YAML 출력을 써서 토큰 효율성 및 해석력 극대화)
• 새 모델이 출시될 때마다 시스템 전체(제품, 팀, 마인드셋)를 즉각적으로 대응·변경 가능하도록 엔지니어링하는 것이 필수적임을 반복 강조
• 야심찬 평가 벤치마크를 선제적으로 설계하면, 신모델로 바뀔 때 해당 기능을 즉시 시험·출시 가능
• **시스템 전체 관점의 최적화(데이터, 프롬프트, 도구, 스코어러 등)**가 부분별 최적화(프롬프트만 개선)에 비해 훨씬 월등한 결과를 가져오는 실제 데이터 예시 공유
• 발표자는 Braintrust의 신기능 ‘loop’ 등으로 Prompt, 데이터셋, 점수 함수를 LLM이 자동으로 개선·최적화하여 실질적 수작업을 크게 줄일 수 있음을 시연
• Q&A를 통해 사용자 피드백 평가 반영의 오버피팅 우려, 평가 시스템 내 툴 토큰의 비중, 신모델 출시 대응 전략 등 실무적 고민을 구체적으로 설명
• 전체적으로 단순 평가 도구 활용이 아닌, 조직 전체의 데이터·프롬프트·툴·스코어링 엔지니어링과 신속한 업그레이드 체계 구축이 LLM 제품 경쟁력의 핵심임을 강조

세부 요약 - 주제별 정리

성공적인 Evals 구축을 위한 세 가지 핵심 진단법이 업무 효율과 경쟁력을 좌우함

• Evals가 조직에 실질적 가치를 주는지 판단하는 3가지 기준을 구체적으로 제시
  • 1. 신모델 출시 후 24시간 내 제품 반영: Notion(노션) 사례처럼, 새로운 LLM이 나왔을 때 24시간 이내에 제품에 통합·업데이트 가능하면 평가 시스템이 제대로 작동하는 것
  • 2. 사용자 피드백 즉시 평가에 반영: 사용자 이슈/불만이 발생했을 때, 이를 바로 데이터셋과 평가 시스템에 반영할 수 있는 체계가 있는지 점검 필요
  • 3. Evals를 공격적으로 활용하여 제품 적용 가능성 사전 진단: 단순히 유닛 테스트처럼 회귀테스트만 하는 것이 아니라, 사전에 Evals로 실제 성능과 적용 한계를 정확히 예측하여야 함
• 위 세 기준 중 하나라도 충족하지 않으면 조직의 평가 시스템이 미흡하다는 의미로 보고 개선 필요성을 강조
• 실제 Notion에서는 최근 주요 LLM(모델) 출시 때마다 이 과정을 성공적으로 반복함을 언급

우수한 평가 지표(Scorer)와 데이터셋 구축에는 적극적인 엔지니어링 투자가 필수임

• 기존에 자주 쓰는 synthetic(합성) 데이터셋, LLM 판정 등 오픈소스 기본 패키지만으로는 실제 서비스 사용성 반영이 불가능함을 강조
• 대부분의 실제 서비스 use case에서는 미리 만들어 두는 데이터셋이 ‘현실’을 전혀 대변하지 못함
• 최고 수준의 데이터셋은 실제 사용자 경험을 지속적으로 반영·정제하며 직접 ‘조율(reconcile)’하는 과정에서 만들어짐
• 채점 함수(scorer) 역시 “off-the-shelf”(범용 공개 함수)만 쓰면 ‘남의 프로젝트 스펙’을 적용하는 것에 불과하다고 비판
• 우수한 기업들은 반드시 자체 scoring 함수를 제작, 반복적으로 개선함을 경험적으로 확인
• Scorer는 제품 스펙의 일부이므로 맞춤 개발이 당연함을 거듭 강조

프롬프트 품질은 시스템 프롬프트보다 전체 컨텍스트·툴 정의의 설계가 더 많은 차이를 만든다

• 현대 LLM 기반 에이전트 프롬프트 구성 예시를 상세히 설명: 시스템 프롬프트 외에 for 루프로 LLM과 툴 호출, 응답 등을 프롬프트에 반복적으로 결합
• 내부 분석 결과, 평균적으로 시스템 프롬프트 외의 ‘툴 정의’, ‘툴 응답’, 사용자/어시스턴트 메시지 등 기타 데이터가 전체 토큰 수의 ‘대다수’ 차지(구체적 수치 비율로 설명)
• 따라서 시스템 프롬프트 자체보다, 툴의 정의와 출력 결과 포맷을 LLM이 최적으로 활용할 수 있게 설계하는 것이 성능 향상에 결정적임
• 예시: 단순히 현재 서비스의 API 그 자체를 툴로 노출하면 최적의 성능이 나오지 않음 → LLM 중심으로 툴 설계 방식 변화 필요

툴의 출력 포맷 변화 하나로도 LLM 성능이 극적으로 달라질 수 있음을 실증적으로 제시

• 내부 실험 사례: 툴의 출력 포맷을 JSON에서 YAML로 변경했더니 LLM의 해석 효율과 토큰 효율이 크게 늘어남
• LLM과 달리 JS 등 일반 코드·도구에서는 YAML/JSON이 큰 차이가 없으나, LLM에겐 ‘데이터 구조의 컴팩트함, 가독성’이 직접 성능에 영향
• 조직은 툴의 API 정의/출력 방식을 ‘모델 최적화 관점’에서 재설계해야 함을 강조

조직, 팀, 제품은 신모델 출시 때마다 ‘모두 바뀔 수 있다’는 가정 하에 설계되어야만 한다

• Replit 등 선도 기업 사례를 들어, 신모델 출시 → 시스템 전체(제품, 팀, 마인드) 재구축이 곧바로 가능해야 진정한 경쟁력이 된다고 정의
• 실제 내부 product feature 사례: 몇 개월 간 같은 평가(Eval)를 반복적으로 실행하면서 신모델 등장 시 성능 수치(벤치마크)가 어떻게 한계치(viable 수준)를 넘는지 시계열 그래프·수치로 설명 (예: GPT-4.0 → 4.1 → Claude 4 Sonnet 순으로 성능 급상승)
• 신모델 통해 기존에는 ‘10% 성공률’로 불가능했던 기능이 ‘즉시 론칭 가능’ 수준(성공률 대폭 상승)으로 변한 실제 예시 제시
• 조직의 평가(Eval)는 현존 모델로 당장은 불가능한 매우 야심찬 테스트도 계속 준비해뒀다가 새 모델 등장 시 즉시 적용해보는 방식이 권장됨

평가 시스템은 모델 간 마이그레이션(호환성)을 감안해 설계되어야 신속한 실험이 가능함

• Braintrust는 Braintrust Proxy라는 툴로 코드 수정 없이 다양한 모델(예: Gemini, Claude, OAI 등)을 빠르게 교체·실험할 수 있도록 제공
• Google Gemini의 최신 모델 실측 예시와 같은 결과도 실수치로 제공 (예: Gemini 2.5 Pro0520은 특정 벤치마크에서 1%로 아예 표에 못 들어감)
• 모델 출시 직후 빠른 A/B 테스트 및 교체가 실질적으로 얼마나 중요한지 사례로 부연

전체 시스템 관점의 최적화가 프롬프트만 개선할 때보다 훨씬 더 큰 성능 차이를 만들어 낸다

• 단순히 프롬프트만 LLM으로 최적화(‘이 프롬프트를 개선해줘’)한 결과와, 프롬프트·데이터셋·채점함수 전부를 통합적으로 LLM이 개선하게 한 결과치를 직접 벤치마크로 비교
• 이 방식에서 단순 프롬프트 개선은 여전히 불가능한데, 시스템 전체를 LLM이 최적화할 경우 기능이 ‘불가능(10% 성공)’에서 ‘실제 가능(상당한 성공률)’ 수준으로 개선됨을 실측으로 보여줌
• 즉 프롬프트, 데이터셋, 채점함수, 툴 정의 등 ‘전체 구조 최적화’가 최우선임을 강조

Braintrust의 신기능 ‘loop’는 Eval 시스템 자체의 반복적 개선을 LLM이 자동화하는 구조를 제공함

• ‘loop’ 기능은 Braintrust의 feature flag를 켜서 현재 바로 사용 가능함을 안내
• prompt, 데이터셋, score를 입력값으로 넣으면 LLM이 해당 요소를 직접 만들고 개선해주며, 반복적으로 best 조합을 찾아간다
• “이 프롬프트를 최적화해줘”, “이 데이터셋에 추가로 넣으면 검증에 도움이 될 사례는?”, “왜 내 점수가 낮을까?”, “더 엄격한 scoring 함수 제시해줘” 등 실질적 질문에 대한 LLM 자동 개선 기능을 갖춤
• Claude 4 Sonnet, Opus, GPT 등 주요 최신 모델에서의 실제 성능 비교 결과(자세한 수치 포함)를 안내, 다양한 모델 실험 권고

앞으로 LLM 발전으로 평가 시스템 개선의 워크플로우가 근본적으로 혁신될 것을 전망함

• 컨텍스트 설계, 프롬프트와 데이터셋, 스코어 개선 등 반복 작업의 상당부분이 LLM 자동화로 대체될 것으로 보고 있음
• loop 등 자동화 도구로 자동 iterative 개선 구조가 활성화될 것임을 암시

Q&A를 통해 사용자 피드백의 오버피팅 우려, 평가 시스템 내 툴 토큰 비중 등 실무 이슈를 구체적으로 응답

• 사용자 피드백을 평가(Eval)로 전환 시 오버피팅 우려에 대한 질문: “사용자 피드백 없이 만든 고정 데이터셋이 오히려 더 현실과 괴리된다”라고 답변
  • 현 시점에서는 단순히 모든 사용자 피드백을 자동 추가하는 것이 아니라, 사용자가 결국 ‘어떤 피드백을 샘플로 추가할지’에 대한 최소한의 판단·선별이 중요함을 언급
  • 예: “이 피드백은 명백히 우리 제품에서 잘 되었어야 하는데 안 된다면, 샘플에 추가해 반드시 개선해야 함”이라는 실무적 설명
• 평가 내 툴, 프롬프트 토큰 비중 문의에 별도의 데이터 검토 내용(액터별 토큰 분포 및 그 역할) 부연
  • 현대 LLM 시스템에서 툴 정의·응답이 전체 토큰 예산에서 차지하는 비중이 매우 높음을 거듭 강조
• 신모델 출시가 실제로 ‘모든 것을 바꾼다’는 점에 대한 구체적 사례/설명 요청에, 실제 loop 평가 세트의 여러 벤치마크 중 “야심 찬 벤치마크는 최근까지 모델 점수가 계속 낮았으나, 신모델(Model) 출시 직후 단번에 threshold를 넘기며 양상이 바뀐” 경험을 상세히 소개
• 동시에 어떤 활용(예: 영화 대사 분류 등)은 GPT-3.5 이후 꾸준히 잘 맞지만, ‘야심 찬 업무’는 모델 세대교체 때마다 성능 지형이 급변함을 실제로 보여 줌

발표자는 최종적으로 전체 평가 시스템의 수준향상이 경쟁력임을 정리하며 Q&A를 마무리함

• 효율적이고 공격적으로 설계된 평가 시스템만이 신모델 출시·피드백 신속 반영·전체 제품 경쟁력 강화로 연결됨을 재강조
• 조직의 평가 시스템 숙련도, 데이터셋·프롬프트·툴·스코어러의 커스텀 설계, 신모델 대응력, 시스템 전체 최적화의 중요성을 마지막으로 요약