Hamel Husain블로그
AI Evals FAQ 요약: 새 답변 2건 (2026-09-25 ~ 2026-09-27)
Hamel Husain과 Shreya Shankar의 AI Evals FAQ에 9월 25일부터 27일까지 새 질문 2건이 추가되었습니다. 각 답변은 전문을 그대로 실었으며, 원문 질문으로 연결되는 링크도 함께 제공합니다.
Hamel Husain과 Shreya Shankar의 AI Evals FAQ에 9월 25일부터 27일까지 새 질문 2건이 추가되었습니다. 전문을 그대로 실었으며, 각 답변에는 원문 페이지 링크가 붙어 있습니다.
Q: 내가 모르는 언어로 된 출력은 어떻게 평가해야 하나요?
LLM으로 외국어 대화를 번역해 볼 수는 있지만, 여기에 의존하는 것은 조심해야 합니다. 번역 과정에서는 직접 대응하는 표현이 없는 단어나 관용구 때문에 의미가 사라지는 경우가 많습니다. 게다가 무엇이 "좋은" 답변인지는 문화와 사회적 규범에 따라 달라지곤 합니다. 예를 들어 답변의 문자 그대로의 뜻을 이해했다고 해서, 다른 문화권에서 그 어조가 적절한지까지 판단할 수 있는 것은 아닙니다.
이런 한계 때문에, 사용자의 언어와 문화적 맥락을 모두 이해하는 검토자를 참여시킬 것을 권합니다. 그래도 검토 과정을 정리하고, 직접 파악할 수 있는 문제를 조사하는 방식으로 평가에 기여할 수 있습니다. 다만 오류 분석의 기준은 그 검토자가 세워야 합니다.
언어와 문화적 맥락을 모두 이해하는 검토자를 구하지 못했다면, 그만큼 평가에 한계가 있다는 점을 감안해야 합니다.
Q: 평가(eval)는 얼마나 자주 실행해야 하나요?
세 가지 측면을 고려해야 합니다.
- 평가를 실행하고 유지하는 데 드는 비용. 평가에 비용이 많이 들수록, 자주 실행할 만한 이점이 커야 합니다. 예를 들어 LLM-as-a-judge는 단위 테스트보다 실행 비용이 높습니다.
- 데이터셋에서 평가가 얼마나 포화되었는지. 평가가 모든 예시를 통과한다면 새로운 정보를 주지 못하는 것입니다. 포화 상태라면 평가를 폐기하거나 실행 빈도를 줄이는 방안을 검토하세요. 다만 그 전에, 애초에 포화되지 않도록 먼저 평가의 난도를 높여 보는 것이 좋습니다.
- 해당 오류를 잡아냈을 때의 비즈니스 가치. 치명적인 오류라면 이를 잡아내는 가치가 충분히 커서, 비용이 들더라도 더 자주 실행해야 할 수 있습니다. 단, 가상의 오류에 지나치게 매달리지는 마세요. 최소한 평가를 구현하기 전에 애플리케이션을 레드팀 방식으로 공격해 그 오류를 한 번은 실제로 발생시킬 수 있음을 확인해야 합니다. 그러면 더 좋은 평가를 만드는 데도 도움이 됩니다.
명확한 기준선은 없습니다. 공식에 대입하기보다는 판단이 필요한 결정입니다. 아래 그림은 트레이드오프를 생각해 볼 때 도움이 될 것입니다.
예시
각 요소를 이해하는 데 도움이 되도록 구체적인 예시를 준비했습니다. 어디까지나 설명을 위한 예시입니다.
| 평가 | 테스트 예시 통과 현황 | 실패 시 비즈니스 비용 | 권장 실행 주기 |
|---|---|---|---|
| GPT-6 Astra를 최대 추론 설정으로 사용하는 답변 품질 judge | 전부 통과 | 중간 | 폐기하거나 드물게 실행 (예: 2주에 한 번) |
| 연락처가 올바르게 저장되었는지 확인하는 코드 assertion | 전부 통과 | 중간 | 비용이 거의 들지 않으므로 변경할 때마다 실행해도 됩니다. |
| Fable 5 기반 judge가 고객 지원 에이전트가 새 환불 정책을 따르는지 확인 | 통과 없음 | 중간 | 비용은 많이 들지만 통과하는 예시가 하나도 없어 유용한 피드백을 주고 있고, 오류를 잡아내는 비즈니스 가치도 충분히 높습니다. 가능한 한 자주 실행하겠습니다. |
| GPT-6 Luna 기반 judge가 고객 지원 에이전트가 고객의 문제를 해결했는지 확인 | 일부 통과 | 중간 | 모델이 작아 judge 비용이 아주 크지 않고 평가가 여전히 오류를 잡아내고 있으므로, 비교적 자주(예: 매일 밤) 실행하겠습니다. |
| GPT-6 Astra를 최대 추론 설정으로 사용하는 judge가 법률 어시스턴트의 기밀 정보 부적절 노출 여부를 확인 | 전부 통과 | 높음 | 비용이 많이 들고 평가도 포화 상태지만, 오류를 잡아내는 비즈니스 가치가 충분히 높으므로 매 릴리스 전에 실행하겠습니다. 오류의 중요도를 고려하면 평가의 난도를 높여 활용도를 끌어올리는 방안도 시도하겠습니다. |
| GPT-6 Astra를 중간 추론 설정으로 사용하는 judge가 사소한 서식 선호도를 확인 | 일부 통과 | 낮음 | 가끔 실행하거나 폐기하세요. 가능하다면 코드로 대체하는 편이 좋습니다. |
더 저렴한 평가자를 꾸준히 찾아볼 가치가 있습니다. 더 적은 비용으로 사람이 매긴 레이블과 비슷하거나 더 잘 일치하는 평가자를 발견할 수도 있습니다.
오프라인 평가와 온라인 평가
여기서는 오프라인 평가를 중심으로 이야기했습니다. 온라인 평가도 고려할 점은 비슷하지만, 프로덕션 트레이스를 얼마나 샘플링할지 추가로 정해야 합니다. 예를 들어 저렴한 검사는 모든 트레이스에 실행하고, 비용이 큰 judge는 매일 밤 샘플에만 실행할 수 있습니다. 이런 방식들을 함께 활용하는 방법은 CI/CD와 프로덕션 모니터링에서 평가는 어떻게 다르게 쓰이나요?에서 더 자세히 다룹니다.
전체 FAQ 보기: AI Evals: Everything You Need to Know. 이전 요약: AI Evals FAQ 요약 (2026-09-19까지).
