Hamel Husain블로그
AI 평가 FAQ 모음: 새로운 답변 16건 (2026-09-01 ~ 2026-09-19)
2026년 9월 1일부터 19일 사이, Hamel Husain과 Shreya Shankar가 운영하는 AI 평가(Evals) FAQ에 새 질문 16건이 추가됐습니다. 각 답변 전문과 원문 링크를 함께 정리했습니다.
Q: 평가(eval)에 예시 데이터는 몇 개나 필요한가요?
평가 구축은 파이프라인 작업입니다. 단계마다 필요한 데이터 양이 다릅니다. 각 단계를 아래에서 설명합니다.
| 단계 | 할 일 |
|---|---|
| 1. 애플리케이션 검토 | 트레이스(trace)를 읽으며 애플리케이션의 실패 유형을 기록합니다. 이 과정을 오류 발견(error discovery)이라고 합니다. 다양한 트레이스 100개로 시작해, 적어도 30개는 직접 주석을 답니다. |
| 2. 평가자 생성 및 검증 | 두 가지 평가자 유형 중 하나를 선택합니다. 객관적인 규칙으로 실패를 판별할 수 있다면 코드 기반 평가(code-based eval)를 사용하고, 모든 조건과 중요한 엣지 케이스에 대해 통과·실패 예시를 포함합니다. 사람의 판단이 필요한 실패라면 LLM 판정자(LLM judge)를 사용하고, 각 실패 유형마다 예시 100~200개에 레이블을 답니다. |
| 3. 반복 실행 가능한 평가 세트 구축 | 주요 워크플로우와 확인된 실패 사례를 대표하는 예시를 수집합니다. 애플리케이션을 변경할 때마다 이 세트를 실행합니다. 이 세트는 보통 예시 100개 이상으로 늘어납니다. |
1단계: 트레이스를 검토해 실패 원인 찾기
트레이스란 사용자가 애플리케이션과 나눈 한 세션의 전체 기록입니다. 코딩 에이전트를 활용해 초기 풀(pool)에서 다양한 사용자와 워크플로우가 골고루 포함되도록 샘플링하세요. 평가 플러그인(evals plugin)을 사용하면 샘플링과 트레이스 주석 인터페이스 구축에 도움이 됩니다.
트레이스 30개 이상은 직접 검토하세요
에이전트에게 실패 사례 제안을 요청하기 전에, 오류 발견 과정을 통해 트레이스 30개 이상을 직접 주석 다는 것을 권장합니다. 사용자 관점에서 문제가 있어 보이는 부분을 자유로운 텍스트로 기록하세요. 이 예시들이 에이전트에게 여러분의 판단 기준을 구체적으로 보여주는 자료가 됩니다.
첫 번째 검토는 반드시 수동으로 진행하세요. 에이전트가 너무 일찍 문제를 제안하기 시작하면, 그 추측이 여러분의 판단을 편향시킬 수 있습니다. 제품 맥락이나 좋은 사용자 경험에 대한 정의에 따라 달라지는 실패 사례를 놓칠 수도 있습니다.
트레이스 30개를 검토한 뒤, 에이전트에게 나머지 풀에서 유사한 사례를 찾아달라고 요청하세요. 제안된 사례는 반드시 직접 검토하고, 하나씩 수락하거나 거부하면서 에이전트가 기준을 잘못 이해했을 때는 바로잡아 주세요.
언제 멈춰야 할까요
새 트레이스를 봐도 새로운 실패 유형이 나오지 않거나 기존 유형이 바뀌지 않을 때까지 계속하세요. 질적 연구자들은 이 상태를 이론적 포화(theoretical saturation)라고 부릅니다. 최소 트레이스 100개를 검토하고, 여전히 새로운 것을 배우고 있다면 100개를 넘어서 계속하세요.
실제 진행 과정을 보고 싶다면 라이브 워크스루(live walkthrough)를 참고하세요. 영상에서는 Shreya Shankar가 실패 기준 판단은 사람이 주도하면서 에이전트를 활용해 트레이스를 빠르게 검토하는 방법을 보여줍니다.
이 검토 과정을 통해 실패 분류 체계(failure taxonomy), 즉 애플리케이션이 실패하는 구체적인 유형 목록이 만들어집니다. 이 분류 체계를 기반으로 어떤 평가자를 구축할지 결정하세요.
2단계: 평가자 생성 및 검증
주요 실패 유형마다 평가자를 선택합니다. 평가자 유형에 따라 필요한 레이블 예시 수가 달라집니다. 코드 기반 평가는 객관적인 규칙에 적합하고, LLM 판정자는 사람의 판단이 필요한 실패 유형에 적합합니다.
코드 기반 평가는 커버리지가 중요합니다
결정론적 규칙으로 실패를 판별할 수 있을 때 코드 기반 평가를 사용하세요. JSON 파싱 여부나 툴 호출 시 올바른 인수를 사용하는지 확인하는 경우가 그 예입니다.
필요한 예시 수는 검사가 다루는 시나리오에 따라 달라집니다. 최소한 모든 조건에 대해 통과·실패 예시를 포함하세요. 오류 발견 과정에서 찾은 중요한 엣지 케이스도 추가하세요. 규칙 하나짜리 검사라면 통과 예시 몇 개와 실패 예시 몇 개만으로 충분할 수 있습니다.
LLM 판정자에는 레이블 예시가 필요합니다
주관적이거나 도메인 특화 판단이 필요한 실패에는 LLM 판정자를 사용하세요. 각 실패 유형마다 예시 100~200개에 레이블을 다는 것을 계획하세요. 오류 발견 과정에서 해당 실패 유형에 맞는 트레이스가 있다면 재사용하고, 그 범위에 도달할 때까지 추가로 수집하세요. 레이블은 신뢰할 수 있는 도메인 전문가가 달아야 하며, 두 클래스를 모두 평가할 수 있을 만큼 통과·실패 예시가 충분히 포함되어야 합니다.
예시를 학습(train), 개발(dev), 테스트(test) 세트로 분리하세요. 프롬프트에 포함될 수 있는 학습 예시에는 10~20%를 사용합니다. 판정자를 다듬는 동안은 40~45%를 개발 세트로 사용하고, 나머지 40~45%는 최종 테스트용으로 남겨두세요. 가능하다면 개발 세트와 테스트 세트 모두에 통과 예시 30~50개, 실패 예시 30~50개를 포함하세요.
전체 과정은 검증 가이드(validation guide)에서 확인할 수 있습니다. 판정자 검증 플래시카드(judge-validation flashcard)도 좋은 시각 참고 자료입니다.
평가자 검증이 끝나면, 개발 과정에서 반복적으로 실행할 예시들을 모아두세요.
3단계: 반복 실행 가능한 평가 세트 구축
오류 발견 과정에서 주요 실패 유형을 담은 예시로 시작합니다. 새로운 실패가 확인될 때마다 추가하세요.
목적에 맞게 구축한 평가 세트는 보통 예시 100개 이상으로 늘어납니다. 최종 크기는 커버리지에 따라 결정됩니다. 중요한 워크플로우와 알려진 실패 사례가 모두 포함되어야 하며, 자주 실행할 수 있을 만큼 비용이 적게 드는 세트여야 합니다. 코드 기반 검사와 LLM 판정자는 같은 예시에 함께 실행할 수 있습니다. 개발 과정에서 이 세트를 활용하는 방법은 CI 평가(CI evals) FAQ에서 확인하세요.
Q: 트레이스가 너무 클 때는 어떻게 검토하나요?
에이전트가 오래 실행되거나 대량의 컨텍스트를 가져올 때 트레이스가 매우 커질 수 있습니다. 이럴 때 유용한 경험 법칙은 첫 번째 상위 실패(first upstream failure)에 집중하는 것입니다. 오류는 연쇄적으로 발생하는 경향이 있으므로, 먼저 발생한 오류를 우선적으로 처리하면 시간을 절약할 수 있습니다.
검토 도구에서 점진적 노출(progressive disclosure) 방식을 사용하세요. 가장 관련성 높은 정보를 먼저 보여주고, 검토자가 필요할 때만 세부 내용을 펼쳐 볼 수 있도록 합니다. 예를 들어, 처음에는 대화 내용만 보여주고 툴 출력은 검토자가 확인이 필요할 때 펼쳐 보도록 접어두는 방식입니다.
트레이스 하나가 여전히 너무 커서 검토하기 어렵다면, 도메인 전문가와 협력해 무엇을 확인해야 하는지 파악하세요. 관련 증거를 추출하고 트레이스나 원본 문서에서 해당 위치로 연결하는 도구를 만드세요. 예를 들어, 긴 계약서에 관한 답변을 검토할 때는 관련 조항과 원본 페이지 링크를 함께 보여주는 도구가 도움이 됩니다. 이런 추출 방식은 반드시 도메인 전문가와 함께 검증하세요.
양보다 질이 중요합니다. 많은 트레이스를 빠르게 훑는 것보다, 몇 가지 실패 사례를 꼼꼼히 분석하는 편이 대개 더 많은 것을 배울 수 있습니다.
Q: 데이터에 주석을 달기 전에 정답 예시나 채점 기준이 필요한가요?
아니요. 예시를 검토하기 전에 채점 기준부터 작성하면 오히려 방해가 될 수 있습니다.
먼저 용어를 정리하겠습니다.
- 정답 예시(reference answer)는 올바른 응답의 예를 말합니다.
- 채점 기준(rubric)은 응답을 평가하는 기준 집합으로, 환불 정책 준수 여부 같은 항목이 예가 됩니다.
두 가지 모두 도움이 될 수 있지만, 초기 기대치는 수정해 나갈 출발점으로 여기세요.
세부적인 채점 기준은 예시를 어느 정도 검토한 뒤에 만드는 것이 대개 더 효과적입니다. 기준 항목만 체크하는 데 집중하다 보면 기준 밖의 문제를 놓치기 쉽습니다. 검토자가 예상치 못한 부분을 발견할 수 있도록 여지를 남겨두는 것이 중요합니다. '좋다'고 판단하는 기준이 이렇게 달라지는 현상을 "기준 변이(criteria drift)"라고 합니다.
예를 들어, 환불을 처리하는 고객 지원 에이전트가 정책에 따라 환불 건을 사람에게 에스컬레이션한다고 가정해봅시다. 몇 가지 상호작용을 읽어보기 전까지는 이 과정이 사용자에게 얼마나 답답하게 느껴지는지 깨닫지 못할 수 있습니다. 예시를 검토하면서 기준이 얼마나 많이 달라질 수 있는지 과소평가하지 마세요!
예시를 체계적으로 검토하고 채점 기준에 포함할 항목을 결정하려면 오류 분석(error analysis)을 활용하는 것을 권장합니다. 문제가 있어 보이는 부분을 자유롭게 기록한 뒤, 유사한 메모를 묶어 반복적으로 나타나는 문제를 파악하는 방식입니다. 자세한 과정은 라이브 데모를 참고하세요.
오류 분석을 마치면 사용자와 애플리케이션의 실제 동작을 반영한 더 나은 채점 기준을 작성할 수 있습니다. 채점 기준이 최신 상태를 유지하도록 오류 분석을 주기적으로 수행하세요.
Q: 트레이스에 민감한 데이터가 포함되어 있을 때 평가는 어떻게 하나요?
실제 상호작용을 직접 살펴보는 것을 대체할 방법은 없습니다. 이상적이지 않은 상황이지만, 몇 가지 선택지가 있습니다. 선호도 순서대로 정리하면 다음과 같습니다.
검토가 허용된 실제 데이터를 먼저 찾아보세요. 고객이 트레이스 일부를 공유하는 데 동의하거나, 테스트 사용자가 자신의 상호작용 검토를 허락하는 경우도 있습니다. 제한적인 접근이라도 사람들이 제품을 실제로 어떻게 사용하는지 파악할 수 있습니다.
데이터를 직접 볼 수 없다면, 열람 권한이 있는 도메인 전문가와 협력하세요. 전문가가 일상 업무에서 쉽게 검증할 수 있도록 제품을 설계하세요. 예를 들어, 의료 연구 보조 도구라면 각 주장의 근거를 임상의에게 보여주고 상충되는 출처를 검토 표시로 표시할 수 있습니다. 임상의는 제품을 사용하면서 특정 주장을 수정하거나 상충 사항을 해결할 수 있습니다. 이러한 결정은 저장 및 공유 제한 범위 내에서 평가용 추가 데이터로 활용될 수 있습니다.
이 접근법을 잘 설계하려면 전문가가 답변을 어떻게 확인하는지 파악하세요. 뒷받침 증거 링크와 검토할 수 있는 더 작은 작업 단위를 제공하세요. 최종 답변이 유용했는지만 묻는 방식으로는 무엇이 잘못됐는지 파악하기 어렵습니다. 이 접근법에 대한 자세한 내용은 이 게시물에서 확인하세요.
트레이스를 편집하거나 민감 정보를 삭제해 공유 가능하게 만드세요. 민감 정보를 저장할 수 없다면 로깅 전에 삭제하세요. 자동 삭제 도구가 민감 정보를 놓칠 수 있으므로 출력을 직접 확인하세요. 편집된 트레이스를 공유할 수 있다면, 개인 정보를 제거하고 민감한 세부 내용을 변경하는 방식으로 실제 사례를 검토에 활용할 수 있습니다. 다만 해당 편집이 평가하려는 동작을 그대로 보존하는지 반드시 확인하세요.
위 방법이 모두 불가능하다면, 합성 데이터(synthetic data)를 최후의 수단으로 사용하세요. 합성 데이터는 초기 문제 발견에 도움이 되지만, 실제 사용자의 행동 패턴에 대한 근거를 제한적으로만 제공한다는 단점이 있습니다. 합성 데이터가 신뢰할 수 없을 수 있는 경우에 대해 더 알아보세요.
Q: LLM 판정자에게 컨텍스트를 얼마나 줘야 하나요?
각 판정자에게는 해당 실패 유형 판단에 필요한 트레이스 부분만 제공하세요. 모든 판정자에게 동일한 전체 트레이스를 기본으로 제공하지 마세요. 불필요한 컨텍스트는 컨텍스트 오염(context rot)을 유발해 판정자 성능을 저하시킬 수 있습니다.
적절한 컨텍스트를 찾는 데는 실험이 필요합니다. 판정자의 결정을 사람의 레이블과 비교해 선택한 컨텍스트를 검증하세요. 그런 다음 불일치 사례를 살펴보며 판정자가 필요한 근거를 갖추지 못했는지, 아니면 불필요한 정보에 주의가 분산됐는지 파악하세요.
특정 정보가 도움이 되는지 확신이 없다면 에이블레이션 스터디(ablation study)를 시도하세요. 한 번에 정보 하나씩 제거하고 사람의 레이블 대비 결과가 어떻게 달라지는지 확인하는 방법입니다. 성능이 그대로이거나 오히려 향상된다면 해당 정보를 제외할 수 있습니다.
오래 실행되는 에이전트는 판정자의 컨텍스트 윈도우를 채우거나 초과하는 큰 트레이스를 생성할 수 있습니다. 이런 경우에는 판정자에게 필요한 부분을 검색하는 도구를 제공하는 방법을 고려해 보세요. 다만 꼭 필요한 경우에만 추가하세요. 이런 도구는 복잡성, 비용, 지연 시간을 높입니다.
Q: '골든' 평가 데이터셋이 오래됐을 때는 어떻게 해야 하나요?
제품과 사용자가 바뀜에 따라 평가 데이터셋은 자연스럽게 낡아집니다. 정기적인 오류 분석으로 새로운 문제를 발견하고 예시나 정답 예시를 업데이트하세요. 검토 주기는 사용 사례와 제품 또는 사용 패턴이 얼마나 빠르게 변하는지에 따라 달라집니다.
단위 테스트처럼, 평가는 수정 후 재발하는 문제를 잡아낼 수 있습니다. 다만 평가는 단위 테스트보다 유지 및 실행 비용이 훨씬 큰 경우가 많습니다. 따라서 각 평가의 비용 대비 신호 가치를 따져봐야 합니다. 모든 항목이 계속 통과된다면, 해당 평가가 더 이상 유용하지 않아 폐기하거나 실행 빈도를 줄여야 한다는 신호입니다.
평가 세트가 바뀌면 점수가 이전 점수와 직접 비교되지 않을 수 있습니다. 괜찮습니다! 평가의 목적 중 하나는 계속 개선할 수 있는 도전 과제를 제공하는 것입니다. 제품이 발전함에 따라 이 도전 과제도 함께 바뀌어야 계속 나아갈 수 있습니다.
더 긴 시간 범위에 걸쳐 지표로 성과를 추적하려면, 평가 외에 제품 지표도 함께 활용하는 것이 좋습니다. 이탈률, 활성 사용자 수, 매출 등이 제품 지표의 예입니다.
Q: 도메인 전문가가 아니어도 평가에 기여할 수 있나요?
네, 특히 평가를 처음 시작하는 단계에서는 더욱 그렇습니다. 데이터를 검토하다 보면 도메인 지식 없이도 발견할 수 있는 손쉬운 문제들이 생각보다 많아서 저도 종종 놀랍니다. 예를 들어, 외부인으로서 전문 도메인에서 발견한 문제들은 다음과 같습니다.
- 문자 메시지 챗봇이 짧게 끊어서 보내는 문자 특유의 대화 흐름에 혼란을 겪는 문제
- 사용자 요청이 명백히 모호한데도 추가 질문이나 명확화 없이 처리하는 문제
- 기본적인 계측, 로깅, 트레이스 자체가 없는 문제
- 사용자가 작업을 완료하는 데 도움이 되는 위젯, UI 요소, 기타 어포던스 없이 텍스트 응답에만 지나치게 의존하는 문제
또한, 도메인 전문가에게 예시를 하나 함께 살펴보며 왜 좋고 나쁜지 설명해달라고 요청하세요. 전문가가 무엇을 확인하고 어떤 근거가 필요한지 관찰한 내용을 바탕으로 더 나은 주석 인터페이스를 구축해 검토 과정을 효율화하세요.
팀의 상호작용 수집 및 정기 검토도 도울 수 있습니다. 교차 기능 협업 구조에 대한 아이디어는 프로덕트 매니저와 엔지니어가 오류 분석에서 협업하는 방법을 참고하세요.
마지막으로, 전문 지식이 필요한 판단은 전문가에게 맡기세요. 하지만 도메인 전문가가 아니라도 지금 바로 기여할 수 있다는 사실, 잊지 마세요!
Q: AI 출력 결과를 사람이 평가하기 쉽게 만들려면 어떻게 해야 하나요?
제품 설계부터 꼼꼼히 살펴보세요. 최종 결과물이 나오기 전에 사용자가 확인할 수 있는 중간 출력을 노출하면 도움이 되는 경우가 많습니다. 예를 들어, 환자의 병력을 종합해 의료 보고서를 작성하는 에이전트가 있다고 가정해봅시다. 의사에게 보고서 전체에 대한 피드백을 요청하는 대신, 추출된 사실 정보를 출처 링크와 함께 보여주고, 보고서 생성 전에 의사가 특정 사실을 수정하거나 상충되는 근거를 해결할 수 있도록 하세요. 이 방식은 의사를 프로세스에 참여시키고, 작업 과정을 직접 확인하며 신뢰를 쌓게 합니다. 이런 인터페이스의 대략적인 모습은 다음과 같습니다.
검증을 위한 설계에 대한 더 자세한 논의는 "평가하기 어렵다"는 건 제품 설계의 문제다("It's Hard to Eval" Is a Product Smell)를 참고하세요. 해당 글은 이 예시를 더 자세히 다루고, 이전·이후 목업을 곁들인 다른 사례들도 소개합니다.
검증을 위한 설계를 마쳤다면, 검토 인터페이스가 데이터 검토 과정의 마찰을 줄이는지 확인하세요. 검토 인터페이스 구축에 관한 조언도 참고하세요. 주요 팁은 다음과 같습니다.
- 출력을 친숙한 형식으로 표시하세요. 생성된 이메일은 이메일처럼 렌더링하고, 코드에는 구문 강조를 적용하세요.
- 검토자에게 필요한 컨텍스트를 같은 화면에 배치하세요. 중요도가 낮은 세부 정보는 필요할 때 펼쳐볼 수 있는 섹션에 두세요.
- 예시 간 이동과 판단 기록을 위한 키보드 단축키를 추가하세요. 마우스 없이도 메모를 쉽게 저장할 수 있어야 합니다.
- "100개 중 45개 검토 완료"와 같이 진행 상황을 표시해 검토자가 남은 작업량을 파악할 수 있도록 하세요.
다음으로는 검토 프로세스를 디버깅하세요. 처음에는 예시 수를 줄여 검토자가 각 예시를 꼼꼼히 살펴볼 수 있게 하세요. 여러 사람이 같은 예시를 독립적으로 검토한 뒤 이견을 논의하게 하세요. 함께 예시를 검토하며 어디서 막히는지 파악하는 것도 좋습니다. 이견은 지침이 불명확하거나 정보가 부족하다는 신호일 수 있습니다.
Q: 모델 책임이 아닌 문제도 기록해야 하나요?
네. 상호작용을 검토할 때 제품의 유용성을 떨어뜨리는 모든 문제를 기록하세요. 모델과 무관한 누락 기능이나 버그도 포함됩니다. 오류가 발생한 이유는 아직 따지지 마세요. 어떤 문제를 먼저 수정할지 우선순위를 정한 뒤에 원인 분석을 해도 늦지 않습니다.
예를 들어, 고객 지원 에이전트가 배송 완료를 안내하면서 운송장 번호 링크를 제공하지 않았다고 가정해봅시다. AI가 운송장 링크를 가져올 수 없는 상황이라도 이 문제를 기록하세요. 평가를 구축하기 위한 전제 조건은 오류 분석을 통해 어떤 문제를 수정할지 파악하고 우선순위를 정하는 것입니다. 일부 문제는 자동화된 평가자가 필요 없는 엔지니어링·설계 이슈로 드러날 수 있지만, 그래도 중요한 개선 사항입니다!
마지막으로, 근본 원인 분석을 뒤로 미루고 문제 자체에 집중하면 더 많은 데이터를 살펴보면서도 더 높은 품질의 주석을 작성할 수 있다는 것을 경험을 통해 알게 됐습니다.
Q: 평가에 Jev를 사용할 수 있나요?
네. TypeSafe의 Jev는 평가에 활용할 수 있는 범용 분류기입니다. 통과 또는 실패를 반환하는 LLM 판정자 역시 분류기의 일종입니다.
Jev는 평가에 사용하는 다른 분류기와 동일하게 검증합니다. 즉, 신뢰할 수 있는 레이블과 예측값을 비교하는 방식입니다. 그래서 저희는 기존 플래시카드에서 "LLM 판정자"에 취소선을 긋고 "평가용 분류기(Classifier for Evals)"로 바꿔 표시했습니다.
플래시카드에 설명된 검증 과정에 대한 자세한 내용은 이 게시물을 참고하세요.
빠르고 저렴한 분류기(Jev 등)의 장점은 자동화된 프롬프트 튜닝의 비용과 시간을 크게 줄일 수 있다는 점입니다. 프롬프트 튜닝은 평가자의 프롬프트에 자동으로 변경을 적용하고 사람의 레이블과 얼마나 더 일치하는지 측정하는 방식입니다. GEPA가 프롬프트 튜닝 알고리즘의 한 예입니다. 프롬프트 튜닝에는 수백에서 수천 번의 평가가 필요한 경우도 있어, 실행당 비용이 낮아지면 전체 비용 절감 효과가 상당합니다.
모든 평가에 최적인 단일 분류기는 없습니다. 사람의 레이블로 검증하면 애플리케이션에 맞는 정확도, 비용, 속도 간 트레이드오프를 파악하는 데 도움이 됩니다.
Q: 여러 평가를 하나의 지표로 합산하려면 어떻게 해야 하나요?
각 평가는 이진 결과(binary outcome)(통과 또는 실패)를 반환해야 합니다. 서로 다른 실패를 검사하는 평가가 여러 개 생기기 마련인데, 조직 내에서는 이를 하나의 숫자로 추적하길 원하는 경우가 많습니다.
제가 즐겨 쓰는 간단한 방법은 "전체 통과율(pass all rate)"입니다. 모든 검사를 통과한 경우에만 해당 예시가 통과된 것으로 봅니다. 예를 들어, 100개 중 80개 예시가 모든 검사를 통과했다면 전체 통과율은 80%입니다. 보고서나 대시보드는 전체 통과율에서 각 검사별 통과율로 드릴다운할 수 있도록 설계해, 어떤 검사가 실패에 가장 큰 영향을 미치는지 파악할 수 있게 하세요.
전체 점수 하나와 검사별 결과 사이의 절충안으로, 관련 검사를 주제별로 묶어 그룹별 전체 통과율을 보고하는 방법도 있습니다. 예를 들어, Nurture Boss의 아파트 임대 어시스턴트를 검토했을 때 대화 흐름, 사람에게 핸드오프, 일정 변경 관련 문제가 드러났는데, 이런 주제들을 평가 그룹으로 묶을 수 있습니다.
그룹을 나누는 또 다른 기준은 실패의 심각도입니다. 예를 들어, 릴리즈를 막아야 하는 검사의 전체 통과율과 허용 가능한 이슈의 전체 통과율을 별도로 보고할 수 있습니다. 이 방식은 프로덕션 릴리즈 게이팅에 유용합니다.
그래도 중요도 차이를 반영한 단일 점수가 필요하다면 일부 검사에 더 높은 가중치를 줄 수 있습니다. 다만 저는 LLM 판정자에 리커트 척도(Likert scales)를 권장하지 않는 이유와 같은 이유로, 복잡한 가중 점수도 권장하지 않습니다. 대시보드에서 종합 점수가 주 단위로 3.2에서 3.7로 올랐을 때, 사용자 경험의 어떤 부분이 개선됐는지 알지 못한 채 좋아지기 쉽습니다. 경험상 이런 대시보드는 형식적인 경우가 많고 모두의 시간을 낭비합니다.
어떤 방법을 선택하든, 평가 세트가 바뀌면 점수를 이전 점수와 직접 비교하지 못할 수 있다는 점을 기억하세요. 평가는 개선을 위한 도전 과제를 제공하고, 이 도전 과제는 제품이 발전함에 따라 함께 변해야 합니다. 더 긴 시간 범위에 걸쳐 지표로 성과를 추적하려면 평가 외에 제품 지표도 함께 사용하는 것이 좋습니다. 이탈률이나 활성 사용자 수 같은 지표는 평가가 변하는 동안 더 안정적인 비교 기준이 됩니다.
Q: 자동화된 평가를 신뢰할 수 있는지 어떻게 알 수 있나요?
판단을 내리는 평가자를 검증하려면, 탐지하려는 실패 유형에 대해 사람이 레이블을 붙인 예시를 기준으로 테스트하세요. LLM 판정자와 다른 머신러닝 분류기 모두에 해당하는 이야기입니다. 얼마나 자주 실패를 잡아내는지, 얼마나 자주 오탐이 발생하는지 파악해야 합니다. 코드로 조건을 직접 확인할 수 있다면 해당 검사에는 사람의 레이블이 필요 없습니다. 평가에 어떤 모델이나 방법을 사용할지를 참고하세요.
레이블이 붙은 예시를 세 개의 별도 세트로 나누는 것부터 시작하세요.
- 학습 세트(Training set): 평가자에게 무엇을 찾아야 하는지 가르치는 데 사용합니다. LLM 판정자나 Jev와 같은 제로샷(zero-shot) 분류기의 경우, 이 예시들을 프롬프트에 포함할 수 있습니다.
- 개발 세트(Development set, dev): 이 예시들로 평가자를 실행하고 결정을 레이블과 비교하세요. 이견을 살펴보며 프롬프트를 개선하거나 모델을 선택합니다. 평가자를 개발하는 동안 이 과정을 반복하세요. 프롬프트 튜닝 알고리즘은 개발 세트를 활용해 변경 방향을 결정합니다.
- 테스트 세트(Test set): 변경 작업을 마칠 때까지 이 예시들을 사용하지 마세요. 평가자의 어떤 결정에도 영향을 주지 않은 예시들로 최종 검증을 할 때 사용합니다.
개발 세트 결과를 보고 프롬프트를 수정하거나 모델을 선택할 때마다, 해당 예시의 정보가 평가자에 반영됩니다. 여러 번 반복하다 보면 개발 세트에서는 잘 작동하지만 새로운 예시에서는 성능이 떨어지는 과적합이 발생할 수 있습니다. 개발 세트 예시를 프롬프트에 직접 넣지 않았더라도 마찬가지입니다. 테스트 세트는 이런 변경에 영향을 받지 않은 데이터로 최종 검증을 제공합니다.
테스트 점수가 개발 점수보다 훨씬 낮다면 과적합 여부를 조사하세요. 샘플 크기가 작으면 측정 불확실성이 커지고, 세트 간 차이도 점수 격차의 원인이 될 수 있습니다. 과적합이 확인되면 지침과 예시를 재검토한 뒤, 최종 검증을 위해 새로운 미사용 테스트 세트를 확보해 개발을 처음부터 다시 진행하세요. 과적합 해결 방법은 이 FAQ의 범위를 벗어납니다.
평가자가 사람의 판단과 얼마나 일치하는지 측정하려면 다음 지표를 사용하세요. 여기서 "양성(positive)"은 아래 플래시카드와 동일하게, 오류가 존재하는 경우를 의미합니다.
- 진짜 양성 비율(TPR, True Positive Rate), 즉 재현율(recall)은 평가자가 실제 실패를 얼마나 잡아내는지 측정합니다. 사람이 실패 10건을 찾아냈을 때 평가자가 8건을 잡아냈다면 TPR은 80%입니다. 실패를 놓쳤을 때 비용이 크다면 이 지표를 우선시하세요.
- 진짜 음성 비율(TNR, True Negative Rate)은 평가자가 양호한 출력을 얼마나 정확하게 통과시키는지 측정합니다. 사람이 양호한 출력 100건을 식별했을 때 평가자가 95건을 통과시켰다면 TNR은 95%이며, 나머지 5건은 오탐입니다. TNR이 높으면 잘못 표시된 양호한 출력을 불필요하게 검토하는 시간을 줄일 수 있습니다.
변경을 가할 때마다 두 비율을 모두 추적하세요. 더 많은 실패를 잡아낼수록 오탐도 늘어날 수 있습니다. 애플리케이션의 결과에 따라 허용 가능한 수준을 설정하세요. 실패가 드물다면, 작은 오탐 비율도 불필요한 검토를 많이 만들어낼 수 있습니다.
아래 플래시카드는 LLM 판정자에 대한 이 과정을 설명합니다. 개발과 테스트의 분리 원칙은 다른 평가자에도 동일하게 적용됩니다.
플래시카드의 데이터셋 분할은 프롬프트 기반 판정자나 제로샷 분류기를 위한 예시입니다. 분류기를 학습시키는 경우에는 학습 데이터 비중이 더 커야 할 수 있습니다. 애플리케이션에서 실패를 놓쳤을 때와 오탐이 발생했을 때의 비용을 고려해 목표를 설정하세요.
Q: 코딩 에이전트는 어떻게 평가하나요?
코딩 에이전트가 다양한 작업을 처리한다면, 파운데이션 모델을 평가할 때처럼 공개 벤치마크부터 시작하세요. 특정 워크플로우만 다루는 에이전트라면 제품 특화 평가가 더 적합합니다. 이 차이에 대한 설명은 평가 FAQ를 참고하세요.
코딩 관련 인기 벤치마크로는 SWE-bench, Terminal-Bench, Aider Polyglot, HumanEval이 있습니다.
공개 벤치마크 외에도, 조직 내 어려운 작업을 모아 사내 전용 벤치마크를 구축할 수 있습니다. OpenAI는 Codex 출시 당시 실제 사내 소프트웨어 엔지니어링 태스크로 평가한 사례를 소개했습니다. 각 태스크에는 작동하는 환경과 에이전트가 태스크를 성공적으로 완료했는지 확인하는 코드 기반 테스트가 필요합니다.
포함할 태스크를 결정하려면 사람들이 에이전트를 어떻게 사용하는지, 어디서 실패하는지 살펴보세요. 엔지니어와 함께 실행 기록을 검토하고, 반복적으로 나타나는 문제를 묶어 유용한 예시를 테스트로 만드세요. 이것이 오류 분석이며, 코딩 제품에도 동일하게 적용됩니다. 기존 테스트가 이미 실패를 포착하고 있다면, 그 결과를 활용해 어떤 실행을 조사할지 정하세요.
Anthropic의 Clio 연구는 채팅 대화를 주제별로 클러스터링하는 관련 접근법을 보여줍니다. 이 아이디어를 코딩 세션에 적용하면 벤치마크가 다뤄야 할 작업 유형을 파악하는 데 도움이 됩니다.
Anthropic의 코딩 에이전트 평가 가이드에서는 명확하게 명세된 태스크와 단위 테스트로 결과를 검증할 수 있는 안정적인 환경으로 시작하기를 권장합니다. 단위 테스트를 갖춘 뒤에는 해당 테스트가 잡아내지 못하는 코드 품질이나 에이전트와 사용자의 상호작용 방식 같은 항목을 추가할 것을 권합니다. Claude Code 팀은 예를 들어 파일 편집에 대한 평가를 추가했고, 이후 과도한 엔지니어링(over-engineering) 평가도 추가했습니다. 파일 편집과 과도한 엔지니어링을 측정하는 방법은 다양하지만, 순증가 코드 라인 수나 순환 복잡도(cyclomatic complexity) 같은 지표로 시작할 수 있습니다.
John Berryman과 Shawn Simister의 Copilot 발표에서도 코딩 에이전트 평가의 추가 사례를 확인할 수 있습니다. 코드 완성의 경우, 팀은 리포지토리에서 함수 구현부를 제거하고 모델이 다시 생성하게 한 뒤 기존 테스트를 실행했습니다. 채팅의 경우, 구체적인 기준을 갖춘 LLM 판정자와 어시스턴트가 올바른 도구를 호출했는지 확인하는 별도 검사를 함께 사용했습니다. 또한 A/B 테스트를 실행해 사용자가 제안을 수락하고 이후에도 코드를 유지했는지 추적했으며, 이런 제품 지표가 오프라인 평가를 보완했습니다.
Q: 자동화된 평가를 구축할 때 어떤 모델이나 LLM을 사용해야 하나요?
먼저 코드 어설션(assertion)으로 조건을 테스트할 수 있는지 확인하세요. 예를 들어, AI 어시스턴트가 연락처를 관리한다고 할 때 요청 시 연락처를 생성하는지 테스트하고 싶다면, 새 연락처를 생성하도록 요청한 뒤 데이터베이스를 조회해 요청한 세부 정보가 담긴 일치하는 레코드가 정확히 하나 존재하는지 확인할 수 있습니다. 코드 어설션을 활용하면 사람의 레이블이 필요 없습니다.
판단이 필요한 검사에는 LLM이나 다른 머신러닝 분류기를 사용하세요. LLM 판정자를 사용할 때는 탐지하려는 오류에 대해 통과 또는 실패를 반환하는 분류기로 활용하기를 권장합니다. 어떤 모델을 사용하든, 신뢰하기 전에 사람의 레이블로 검증하세요.
예를 들어, TypeSafe의 Jev, BERT, 또는 로지스틱 회귀를 시도해볼 수 있습니다. 모델에 따라 비용이나 속도가 다르고, 사람의 레이블과의 일치도도 다를 수 있습니다. 데이터로 직접 이런 차이를 측정해 애플리케이션 요구사항을 충족하는 모델을 찾으세요. 예를 들어, 비용이 큰 실패를 잡아내야 한다면 느린 평가를 감수할 수 있고, 즉각적인 피드백이 필요하다면 빠른 모델을 선호할 수 있습니다.
LLM을 사용할 때는 성능이 좋은 모델로 시작하면 판정자 프롬프트를 개발하기 쉽습니다. 잘 작동하게 되면, 더 작고 저렴한 모델로 전환해보고 정확도 손실을 측정하세요. 애플리케이션과 같은 모델을 사용하는 것도 방법입니다.
태스크와 레이블 예시를 정의했다면 에이전트를 활용해 판정자 프롬프트를 최적화할 수 있습니다. 탐지할 특정 실패 유형과 레이블 대비 진전을 측정하는 방법을 명확히 제시하세요. "모든 오류를 찾아서 계속 개선해줘"는 너무 막연합니다. 에이전트는 무엇이 오류인지, 변경이 도움이 됐는지 어떻게 파악해야 하는지 알아야 합니다. 최적화 과정 외부에 별도의 테스트 세트를 유지해, 판정자가 튜닝에 사용되지 않은 예시에도 잘 일반화되는지 확인하세요.
Q: 사내 평가 플랫폼은 팀 전반에 걸쳐 무엇을 표준화해야 하나요?
사내 평가 플랫폼을 구축할 때는 도구, 인프라, 공유 지표부터 시작하고 싶은 유혹이 생깁니다. 하지만 그러다 보면 팀들이 플랫폼이 제공하는 것을 무비판적으로 채택해, 실제 제품의 문제를 찾고 수정하는 데 도움이 되는지 확인하지 않는 상황이 생길 수 있습니다.
먼저 팀들이 오류 분석을 수행하고 검토를 위해 데이터를 효과적으로 샘플링하도록 독려하세요. 발견한 실패를 바탕으로 어떤 자동화 검사를 구축할지 결정하고, 사람의 레이블로 평가자를 검증할 수 있습니다. 각 팀이 자체 지표와 필요한 경우 도구를 개발할 수 있도록 하면서, 이런 프로세스를 표준화하세요. 필드 가이드에서 이것들이 어떻게 연결되는지 예시를 볼 수 있습니다.
각 팀이 자체 도구를 구축할 수 있는 유연성을 주세요. AI 코딩 에이전트 덕분에 맞춤형 소프트웨어 개발 비용이 크게 낮아진 지금은 특히 그렇습니다. 예를 들어, 데이터 주석 도구는 검토하는 데이터에 맞는 맞춤형 인터페이스가 필요한 경우가 많습니다. 스캔된 문서에서 추출한 텍스트를 검토하는 인터페이스와 채팅 대화를 검토하는 인터페이스는 달라야 합니다.
플랫폼은 결과를 저장하는 공유 스토리지와 레이블링 협업 지원을 제공할 수 있습니다. 하나의 팀과 하나의 사용 사례를 잘 지원하는 것부터 시작해, 어떤 니즈가 공통적인지 파악하면서 확장하세요. 팀마다 니즈가 크게 다르고 자체 도구를 저렴하게 구축할 수 있다면, 표준화의 이점은 줄어듭니다.
프로젝트 간 평가 점수 비교는 검사와 테스트 데이터가 비교 가능한 경우에만 의미가 있습니다. 저희는 범용 지표, 즉 도움 여부나 일관성 같은 지표를 지름길로 제공하는 것을 강력히 권장하지 않습니다. 이런 지표는 품질 측정 도구로서의 유용성이 떨어지고, 실제 사용자에게 영향을 미치는 실패 유형에서 팀의 주의를 분산시키는 경향이 있습니다.
Q: LLM 판정자가 사람 검토자와 의견이 맞지 않을 때는 어떻게 해야 하나요?
LLM 판정자를 디버깅하려면 판정자의 결정을 비교할 사람의 통과/실패 레이블이 붙은 예시가 필요합니다. 이 레이블을 효율적으로 얻으려면 오류 분석을 활용하세요. 애플리케이션 데이터를 체계적으로 검토하고 오류를 찾는 구조화된 방법을 제공합니다.
레이블 예시를 수집하는 동안(통과 예시 50개, 실패 예시 50개 이상 권장), 판정자가 사람의 레이블과 의견이 다른 부분을 살펴보며 무엇을 수정해야 하는지 단서를 찾으세요. 흔한 문제로는 컨텍스트 누락이나 모호한 지침이 있습니다. 예시가 통과해야 할지 실패해야 할지 판단하기 어렵다면, 성공 기준을 더 명확하게 다듬어야 한다는 신호입니다.
자동화된 프롬프트 튜닝을 시도하기 전에 이견 사례 몇 가지를 직접 살펴보세요. GEPA와 같은 알고리즘은 판정자 프롬프트에 변경을 적용하고 사람의 레이블과 일치도가 개선됐는지 측정합니다. 너무 일찍 프롬프트 튜닝에 들어가면, 컨텍스트 누락이나 레이블 오류처럼 프롬프트와 무관한 중요한 문제를 놓칠 수 있습니다.
가장 흔한 실수는 LLM 판정자에게 한 번에 너무 많은 종류의 오류를 잡으라고 지시하는 것입니다. 대신 실패 유형마다 별도의 판정자를 구축하는 것을 권장합니다. 예를 들어, 전반적인 대화 품질을 평가하는 것보다 필요한 상황에서 어시스턴트가 사람에게 에스컬레이션했는지 확인하는 것이 훨씬 구체적입니다. 초점이 명확한 판정자는 사람의 레이블과 정렬하기도 쉽고 실행 가능한 인사이트도 더 많습니다.
마지막으로, 판정자가 아직 보지 않은 데이터에도 잘 일반화되는지(즉, 튜닝에 사용한 데이터에 과적합되지 않았는지) 확인하세요. 가장 좋은 방법은 사람이 레이블을 붙인 예시 일부를 따로 분리해 최종 테스트용으로 남겨두는 것입니다. 검증 FAQ에서 데이터를 어떻게 분할하고 판정자가 미확인 예시에서 사람 검토자와 얼마나 일치하는지 측정하는 방법을 확인하세요.
전체 FAQ 보기: AI 평가: 알아야 할 모든 것(AI Evals: Everything You Need to Know).
