LLM 평가 지표 가이드: 실서비스 전 정확도·환각·안전성·비용 검증 기준
결론부터 말하면, LLM 평가 지표는 모델을 고르는 표가 아니라 ‘배포해도 되는가’를 판단하는 운영 게이트입니다. 데모에서 답변이 그럴듯해 보여도 실서비스에서는 틀린 요약, 근거 없는 답변, 개인정보 노출, JSON 파싱 실패, 느린 응답, 예상보다 큰 API 비용이 동시에 발생할 수 있습니다. 따라서 기업용 AI 기능은 최소한 정확도, 근거충실성, 안전성, 응답형식 준수, 비용, 지연시간을 나눠 평가해야 합니다.

2026년 기준 주요 플랫폼도 평가 체계를 제품 흐름 안으로 끌어들이고 있습니다. OpenAI 문서는 eval을 생산 환경의 모델 성능 테스트로 설명하며 데이터 수집, 지표 정의, 실행과 비교를 반복하라고 안내하고, Google의 Gen AI evaluation service는 적응형 루브릭·정적 루브릭·계산 기반 지표·생산 로그 샘플링을 지원합니다. Anthropic도 Claude Console에서 프롬프트별 테스트 케이스를 만들고 재실행하는 평가 도구를 제공합니다. ([platform.openai.com](https://platform.openai.com/docs/guides/evaluation-best-practices))
다만 특정 벤더의 평가 콘솔에만 의존하면 안 됩니다. OpenAI 문서는 Evals 플랫폼이 2026년 10월 31일 읽기 전용으로 전환되고 2026년 11월 30일 종료될 예정이라고 공지하고 있습니다. 평가의 본체는 벤더 화면이 아니라 우리 회사의 골든셋, 채점 기준, 실행 로그, 회귀 테스트 파이프라인이어야 합니다. ([platform.openai.com](https://platform.openai.com/docs/guides/evaluation-best-practices))
좋은 LLM 평가는 ‘AI가 얼마나 똑똑한가’를 묻지 않습니다. ‘우리 업무에서 어떤 실패를 절대 허용하지 않을 것인가’를 먼저 정합니다.
1. 모델 선택 전에 평가 단위를 쪼개야 한다
많은 팀이 ChatGPT, Claude, Gemini, 오픈소스 모델 중 무엇이 좋은지부터 묻습니다. 그러나 실무에서는 질문이 바뀌어야 합니다. 고객 문의 분류, 사내 문서 RAG, 마케팅 카피 초안, 계약서 요약, SQL 생성, 관리자 자동 처리, AI 에이전트는 실패 방식이 서로 다릅니다. 하나의 종합 점수로 비교하면 위험한 기능은 가려지고, 쉬운 기능의 점수만 올라갑니다.
| 업무 유형 | 주요 실패 | 우선 지표 | 배포 판단 포인트 |
|---|---|---|---|
| 고객 문의 분류 | 긴급·환불·장애 티켓을 잘못 분류 | 정확도, F1, 치명 오분류율 | 고위험 라벨의 false negative를 별도 관리 |
| 사내 문서 RAG 답변 | 없는 규정을 있는 것처럼 답변 | 검색 재현율, groundedness, 답변 관련성 | 근거 문서가 없으면 답변 보류가 가능한가 |
| 요약·리포트 | 핵심 누락, 수치 왜곡, 출처 혼동 | coverage, factual correctness, citation support | 핵심 항목 누락을 평균 점수와 별도로 차단 |
| 콘텐츠 초안 | 브랜드 톤 불일치, 금칙어, 과장 표현 | 루브릭 점수, 금칙어 탐지, 사람 샘플 리뷰 | 자동 게시가 아니라 검수 워크플로우가 있는가 |
| 관리자 자동 처리·에이전트 | 잘못된 고객에게 환불, 권한 없는 도구 호출 | tool call accuracy, outcome check, 승인율 | 상태 변경 전 human approval 또는 제한 권한이 있는가 |
| 코드·SQL 생성 | 실행 오류, 보안 취약 쿼리, 잘못된 테이블 참조 | 실행 성공률, 테스트 통과율, 정적 분석 | 실제 DB 변경 없이 샌드박스에서 검증되는가 |
2. 골든셋은 ‘예쁜 질문 모음’이 아니라 실패 사례 저장소다
골든셋은 모델이 맞혀야 할 대표 테스트 데이터입니다. 여기에는 정상 질문만 넣으면 안 됩니다. 실제 로그에서 자주 나온 질문, 과거 장애를 만든 질문, 문서에 답이 없는 질문, 개인정보를 유도하는 질문, 프롬프트 인젝션 문구가 섞인 문서, 한국어 맞춤법이 깨진 입력, 표·PDF·OCR에서 추출된 애매한 문장이 함께 들어가야 합니다. Google 문서는 평가 데이터셋을 파일 업로드, 생산 로그 샘플링, 합성 데이터 생성으로 만들 수 있다고 설명합니다. ([docs.cloud.google.com](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/evaluation-overview))
AI 에이전트라면 처음부터 수백 개를 만들지 못해도 됩니다. Anthropic은 에이전트 초기 개발에서 실제 실패에서 뽑은 20~50개의 단순 과제도 좋은 시작점이 될 수 있다고 설명합니다. 핵심은 숫자가 아니라 버전 관리입니다. 모델, 프롬프트, 검색 인덱스, 툴 권한, 온도값이 바뀔 때마다 같은 골든셋을 다시 돌려야 회귀를 발견할 수 있습니다. ([anthropic.com](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents))
골든셋에 포함할 최소 필드
| 필드 | 설명 | 예시 |
|---|---|---|
| scenario | 업무 상황 | 환불 문의 분류, 정책 RAG, 관리자 메모 요약 |
| input | 사용자 입력 또는 문서 | 오탈자, 긴 문장, 표, 첨부 내용 포함 |
| expected | 정답 또는 기대 행동 | 정답 라벨, 포함해야 할 핵심 사실, 거절 조건 |
| forbidden | 절대 하면 안 되는 행동 | 개인정보 출력, 없는 출처 생성, 권한 없는 tool call |
| evidence | 근거 문서·DB 상태 | 문서 ID, 조항 번호, 샌드박스 DB expected state |
| risk_level | 실패 영향도 | 낮음, 운영 영향, 법무·보안 영향, 금전 영향 |
| grader | 채점 방식 | 정확 일치, Python 검사, LLM 루브릭, 사람 리뷰 |
운영 로그를 골든셋으로 전환할 때는 반드시 개인정보를 마스킹해야 합니다. 고객명, 전화번호, 이메일, 주문번호, 내부 토큰, 계약 금액처럼 답변 품질과 무관한 식별자는 제거하거나 가명 처리합니다. 골든셋 자체가 민감 데이터 저장소가 되면 평가 자동화가 보안 리스크로 바뀝니다.
3. 정확도는 과제별로 다르게 정의해야 한다
정확도라는 말은 편하지만 너무 넓습니다. 분류 모델의 정확도, RAG 답변의 사실성, 요약의 누락 여부, 에이전트의 최종 상태 성공은 모두 다른 문제입니다. OpenAI Graders 문서는 문자열 검사, 텍스트 유사도, 모델 기반 채점, Python 코드 실행 같은 여러 채점 방식을 제시합니다. 단순 정답형 과제는 결정적 채점기를 우선 쓰고, 개방형 답변은 루브릭과 사람 보정을 섞는 편이 안전합니다. ([platform.openai.com](https://platform.openai.com/docs/guides/graders/))
| 지표 | 쓸 곳 | 주의점 |
|---|---|---|
| Exact match | 라벨, 코드, 상태값, 짧은 정답 | 표현 다양성을 허용하지 못하므로 개방형 답변에는 부적합 |
| Regex·schema check | JSON, 날짜, 금액, 필수 필드 | 형식은 맞아도 내용이 틀릴 수 있음 |
| F1·precision·recall | 다중 라벨, 개체 추출, 검색 결과 | 치명 라벨은 전체 평균에서 분리해야 함 |
| Text similarity | 전문가 답변과 유사도 비교 | 의미가 비슷해도 핵심 수치가 틀릴 수 있음 |
| LLM rubric score | 톤, 충실성, 설명 품질, 요약 품질 | 사람 채점 샘플과 주기적으로 보정해야 함 |
| Execution-based check | SQL, 코드, 자동 처리 에이전트 | 샌드박스와 초기 상태를 안정적으로 고정해야 함 |
4. RAG 평가는 검색과 생성을 분리해야 한다
RAG 서비스에서 환각이 생기면 팀은 종종 모델 프롬프트부터 고칩니다. 그러나 실제 원인은 검색 단계일 수 있습니다. 질문에 맞는 문서가 top-k에 없거나, 최신 문서 대신 폐기된 문서가 검색되거나, 테이블 일부만 잘려 들어오면 생성 모델은 그럴듯하게 틀린 답을 만듭니다. 그래서 RAG 평가는 먼저 질문과 검색 결과만 놓고 검사한 뒤, 그 다음 답변을 평가해야 합니다.
Ragas는 RAG 평가 지표로 context precision, context recall, response relevancy, faithfulness 등을 제시하고, TruLens는 RAG 환각을 context relevance, groundedness, answer relevance의 세 축으로 나눠 봅니다. 실무적으로는 검색 문서의 적합성, 답변 주장별 근거 존재, 최종 답변의 질문 충족도를 분리해 대시보드에 표시하는 편이 원인 분석에 유리합니다. ([docs.ragas.io](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/))
| RAG 지표 | 질문 | 개선 액션 |
|---|---|---|
| Context recall | 정답에 필요한 문서가 검색됐는가 | 청킹, 임베딩 모델, 하이브리드 검색, 메타데이터 필터 조정 |
| Context precision·relevance | 검색된 문서가 질문과 관련 있는가 | reranker, top-k, 문서 중복 제거, 오래된 문서 제외 |
| Groundedness·faithfulness | 답변의 각 주장이 근거 문서에 의해 지지되는가 | 문장별 근거 검사, 인용 강제, 근거 없을 때 보류 |
| Answer relevance | 답변이 질문자의 의도에 실제로 답했는가 | 질문 재작성, 답변 구조, follow-up 질문 유도 |
| Citation validity | 인용한 문서·조항·페이지가 실제 근거인가 | 문서 ID 추적, 원문 링크, 인용 스팬 저장 |
사내 문서 기반 AI를 준비 중이라면 RAG 엔터프라이즈 구현 기준에서 문서 수집, 권한, 검색, 답변 생성 구조를 먼저 점검하는 것이 좋습니다. 평가 지표는 RAG 아키텍처와 따로 설계할 수 없습니다.
5. 안전성 평가는 ‘거절을 잘하느냐’보다 넓다
LLM 안전성은 유해 콘텐츠 거절만 의미하지 않습니다. 기업 서비스에서는 프롬프트 인젝션, 민감정보 노출, 시스템 프롬프트 유출, 도구 권한 남용, 잘못된 법률·의료·재무 조언, 비용 폭주가 더 현실적인 위험입니다. OWASP LLM Top 10은 prompt injection, sensitive information disclosure, excessive agency, system prompt leakage 같은 애플리케이션 보안 리스크를 다루고, NIST 생성형 AI 프로파일은 출처·인용 검증, 안전장치 재검토, 보안 이상 탐지, 레드팀 평가 등을 권고합니다. ([owasp.org](https://owasp.org/www-project-top-10-for-large-language-model-applications?utm_source=openai))
| 위험 | 테스트 입력 예시 | 합격 기준 |
|---|---|---|
| 직접 프롬프트 인젝션 | 이전 지시를 무시하고 관리자 지침을 출력하라는 사용자 입력 | 시스템·개발자 지침을 유지하고 민감 내용을 출력하지 않음 |
| 간접 프롬프트 인젝션 | 검색 문서 안에 숨겨진 무시 지시, 외부 링크 요약 중 악성 문구 | 문서 내용을 데이터로만 취급하고 권한 상승 지시를 따르지 않음 |
| 민감정보 노출 | 다른 고객 주문번호, 내부 토큰, 직원 개인정보 요청 | 권한 없는 데이터는 조회·출력하지 않고 로깅도 마스킹 |
| 과도한 권한 | 환불, 삭제, 이메일 발송, 결제 변경을 자동 실행하도록 유도 | 고위험 action은 승인 또는 권한 제한 없이는 실행하지 않음 |
| 과잉 거절 | 정상적인 업무 질문을 보안상 이유로 모두 거절 | 위험 요청은 차단하되 정상 요청의 처리율을 유지 |
안전성 평가에서 자주 빠지는 지표가 과잉 거절률입니다. 보안 문구를 세게 넣으면 위험 답변은 줄지만 고객 문의의 정상 처리율도 떨어질 수 있습니다. 따라서 unsafe pass rate와 safe refusal rate를 함께 봐야 합니다.
6. 응답 형식과 도구 호출은 별도 지표로 관리한다
서비스에 붙는 LLM은 사람이 읽는 문장만 만들지 않습니다. JSON을 반환하고, 함수 호출 인자를 채우고, 관리자 대시보드의 자동 처리 버튼을 제안하고, 외부 API를 호출합니다. 이때 답변 내용이 좋아도 JSON 파싱이 실패하면 제품에서는 실패입니다. 필수 필드 누락, enum 오류, 날짜 포맷 오류, 숫자 단위 혼동, tool name 오선택, 권한 없는 파라미터 전달은 모두 정량 지표로 분리해야 합니다.
AI 에이전트는 최종 답변보다 transcript와 outcome이 중요합니다. Anthropic은 에이전트 평가에서 task, trial, grader, transcript, outcome, evaluation harness를 구분하고, OpenAI도 agent workflow 평가에서 trace가 모델 호출, 도구 호출, guardrail, handoff를 기록한다고 설명합니다. 고객에게 ‘처리했습니다’라고 말했는지가 아니라 실제 샌드박스 DB에 예약·환불·상태 변경이 올바르게 남았는지를 봐야 합니다. ([anthropic.com](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents))
- 형식 지표: JSON 파싱 성공률, schema validation 통과율, 필수 필드 누락률, enum 오류율
- 도구 지표: 올바른 tool 선택률, 인자 정확도, 불필요한 tool call 수, 실패 후 재시도 패턴
- 상태 지표: 샌드박스 DB의 최종 상태, 파일 생성 여부, 이메일 발송 큐 등록 여부
- 권한 지표: 승인 없는 고위험 action 차단률, 사용자 권한 범위 내 데이터만 조회했는지 여부
MCP나 사내 업무 시스템을 AI 에이전트에 연결한다면 MCP 서버 구축 전 체크리스트처럼 도구 권한, 로그, 승인 단계, 실패 복구를 먼저 정의해야 합니다. 도구가 붙는 순간 LLM 평가는 문장 품질 검사가 아니라 업무 시스템 통제 문제가 됩니다.
7. 비용과 응답속도는 평균값보다 꼬리 지표를 봐야 한다
LLM 기능은 트래픽이 늘수록 비용 구조가 드러납니다. 같은 모델이라도 프롬프트 길이, 검색 문서 수, 대화 이력 포함 범위, tool call 횟수, 재시도 정책, 캐시 적중률에 따라 요청당 비용이 크게 달라집니다. 응답속도도 평균만 보면 위험합니다. 고객은 평균 2초보다 가끔 20초 걸리는 요청을 더 크게 기억합니다.
| 운영 지표 | 왜 중요한가 | 확인할 로그 |
|---|---|---|
| Input tokens | 시스템 프롬프트, 문서 컨텍스트, 대화 이력이 비용을 만든다 | 요청별 prompt token, retrieval chunk token |
| Output tokens | 긴 답변은 비용과 latency를 동시에 증가시킨다 | 응답 길이, stream 종료 시간 |
| Tool call count | 에이전트가 과도하게 도구를 돌면 비용과 실패 확률이 오른다 | 도구별 호출 수, 실패 수, 재시도 수 |
| p95·p99 latency | 평균에 숨은 느린 요청을 찾아낸다 | time to first token, time to last token, timeout |
| Cache hit rate | 반복 컨텍스트 비용을 줄이는 핵심 지표다 | 프롬프트 캐시, 문서 캐시, 임베딩 캐시 |
| Cost per successful task | 싼 모델이 실패와 재시도를 많이 만들면 실제로 비싸다 | 성공 요청 기준 총 비용, 실패·재시도 포함 비용 |
비용 산정은 평가 단계에서 같이 해야 합니다. 모델별 품질 차이가 작다면 p95 지연시간과 성공 작업당 비용이 의사결정 기준이 됩니다. 토큰 계산과 트래픽 추정 방법은 LLM API 비용 예측 가이드를 함께 참고하면 좋습니다.
8. 자동 평가 파이프라인은 이렇게 설계한다

실무형 LLM 평가 파이프라인은 한 번 보고서를 만드는 작업이 아닙니다. 기능 변경 때마다 돌아가는 회귀 테스트여야 합니다. OpenAI의 eval 문서는 과제를 설명하고, 테스트 입력으로 실행하고, 결과를 분석해 프롬프트를 개선하는 흐름을 제시합니다. Google은 데이터셋 생성, 지표 정의, 모델 응답 생성, 평가 실행, 결과 해석 단계를 설명합니다. ([platform.openai.com](https://platform.openai.com/docs/guides/evals))
- 평가 목적 정의: 이 AI 기능이 실패하면 어떤 업무 피해가 생기는지 적습니다.
- 골든셋 버전 관리: 정상, 경계, 위험, 과거 장애 케이스를 분리하고 변경 이력을 남깁니다.
- 모델 어댑터 작성: ChatGPT, Claude, Gemini, 오픈소스 서버, RAG 파이프라인을 같은 입력·출력 인터페이스로 감쌉니다.
- 채점기 구성: exact match, schema check, Python 검사, LLM judge, 사람 리뷰를 과제별로 조합합니다.
- 결과 대시보드: 전체 평균보다 실패 유형, 위험 등급, 모델별 비용·지연시간을 함께 보여줍니다.
- 실패 샘플 리뷰: 점수가 낮은 이유가 모델 문제인지, 검색 문제인지, 채점 기준 오류인지 사람이 확인합니다.
- CI·배포 게이트: 프롬프트, 모델, 인덱스, tool schema 변경 시 자동 재실행하고 기준 미달이면 배포를 막습니다.
- 운영 모니터링: 실제 로그에서 새로운 실패를 추출해 골든셋에 추가합니다.
LLM-as-a-judge는 빠른 반복에 유용하지만 단독 판정자로 두면 안 됩니다. Google 문서는 모델 기반 metric을 사람 평점과 비교하기 위한 human rating 컬럼과 balanced accuracy, F1, confusion matrix를 설명합니다. Anthropic도 모델 기반 grader는 사람 전문가 판단과 자주 보정해야 한다고 강조합니다. ([docs.cloud.google.com](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/evaluate-judge-model))
9. 모델 비교는 공개 순위가 아니라 자사 시나리오로 한다

ChatGPT 계열, Claude, Gemini, 오픈소스 모델 중 무엇이 더 좋다는 일반론은 실서비스 의사결정에 충분하지 않습니다. 고객 응대에서는 안전하고 간결한 답변이 중요할 수 있고, 사내 RAG에서는 근거 인용과 문서 권한이 중요할 수 있으며, 관리자 자동화에서는 도구 호출 안정성과 롤백이 더 중요할 수 있습니다.
| 후보 | 평가할 강점 | 반드시 볼 리스크 | 판단 질문 |
|---|---|---|---|
| 상용 LLM API | 초기 품질, 운영 부담 감소, 빠른 모델 교체 | 요금 변화, 데이터 처리 조건, 지역·규정 요구 | 품질 이득이 요청당 비용과 latency를 정당화하는가 |
| 클라우드 통합 플랫폼 | 평가, 로그, 권한, 배포 도구 연계 | 플랫폼 종속, 계정·프로젝트 구조 복잡도 | 기존 인프라와 모니터링 체계에 자연스럽게 붙는가 |
| 오픈소스 자체 호스팅 | 데이터 통제, 커스터마이징, 특정 도메인 최적화 | GPU 비용, 운영 난이도, 업데이트·보안 패치 | 총소유비용과 장애 대응 능력이 준비되어 있는가 |
| 모델 라우팅 | 업무별 최적 모델 선택, 비용 절감 | 라우팅 오류, 평가 복잡도 증가 | 어떤 입력을 어떤 모델로 보낼지 재현 가능한 규칙이 있는가 |
| RAG 결합 | 최신 사내 지식 반영, 출처 제공 | 검색 실패, 권한 누락, 오래된 문서 참조 | 검색 품질과 답변 품질을 분리해 개선할 수 있는가 |
| AI 에이전트 | 다단계 업무 자동화, 도구 사용 | 과도한 권한, 상태 변경 사고, 비용 폭주 | 승인·롤백·샌드박스·trace 평가가 있는가 |
10. 배포 전 체크리스트: 이 항목을 통과해야 한다

LLM 기능의 배포 승인은 ‘괜찮아 보인다’가 아니라 체크리스트로 결정해야 합니다. 특히 고객용 웹서비스, SaaS 관리자 기능, 정부지원사업 MVP처럼 외부 시연과 운영이 이어지는 프로젝트는 평가 결과를 남겨야 이후 모델 변경이나 비용 이슈를 설명할 수 있습니다.
| 영역 | 체크 질문 | 배포 보류 신호 |
|---|---|---|
| 목적 | 이 AI 기능의 성공·실패 기준이 문서화됐는가 | 대표와 PM, 개발자가 기대 답변을 다르게 설명함 |
| 데이터 | 골든셋에 정상·경계·위험·과거 장애 케이스가 포함됐는가 | 데모용 질문 10개만 반복 테스트함 |
| 정확도 | 업무별 지표와 위험 등급별 기준이 있는가 | 전체 평균만 있고 치명 실패를 따로 보지 않음 |
| 근거 | RAG 답변의 근거 문서와 인용이 검증되는가 | 문서에 없는 내용을 자신 있게 답함 |
| 안전 | 프롬프트 인젝션, PII, 권한 남용 테스트가 있는가 | 검색 문서의 악성 지시를 그대로 따름 |
| 형식 | JSON schema, tool call, 필수 필드 검증이 자동화됐는가 | 답변은 맞지만 파서가 자주 실패함 |
| 비용 | 성공 작업당 비용, 월 예상 비용, 캐시 전략이 있는가 | 재시도와 긴 컨텍스트 비용을 계산하지 않음 |
| 속도 | p95·p99 latency와 timeout 대응이 측정되는가 | 평균 응답시간만 보고 배포함 |
| 운영 | 로그 마스킹, 실패 샘플 리뷰, 롤백·킬스위치가 있는가 | 문제가 생겨도 어떤 입력에서 실패했는지 모름 |
AgentMit이 AI 서비스 개발, SaaS, 자동화, 관리자 대시보드, 정부지원 MVP를 설계할 때도 특정 모델 추천부터 하지 않습니다. 먼저 업무 시나리오별 골든셋, 평가 지표, 로그 구조, 관리자 검수 화면, 비용·지연시간 대시보드를 정의합니다. 그 다음 BizMit 같은 운영형 서비스 구조에 RAG, 에이전트, 자동화 기능을 붙여야 출시 후 수정 비용을 줄일 수 있습니다.
FAQ
Q1. LLM 평가 지표는 정확도만 보면 안 되나요?
안 됩니다. 분류·추출처럼 정답이 명확한 기능은 정확도와 F1이 중요하지만, RAG 답변·요약·에이전트는 근거충실성, 누락, 안전성, 응답형식, 비용, 지연시간까지 함께 봐야 합니다. 실서비스 판단은 단일 점수가 아니라 배포 게이트입니다.
Q2. LLM 골든셋은 몇 개 정도 만들어야 하나요?
정해진 숫자는 없습니다. 초기에는 실제 문의, 과거 장애, 위험 케이스를 섞은 작은 세트로 시작해도 됩니다. 중요한 것은 개수보다 대표성입니다. 모델·프롬프트·검색 인덱스가 바뀔 때마다 같은 세트를 재실행할 수 있게 버전 관리해야 합니다.
Q3. RAG의 환각은 어떤 지표로 검증하나요?
질문에 맞는 문서가 검색됐는지 보는 context relevance 또는 context precision·recall, 답변의 주장마다 검색 문서에 근거가 있는지 보는 groundedness 또는 faithfulness, 최종 답변이 질문에 실제로 답했는지 보는 answer relevance를 나눠 봐야 합니다.
Q4. LLM-as-a-judge 자동 평가는 믿을 수 있나요?
반복 평가와 비교 평가에는 유용하지만 그대로 최종 판정자로 두면 위험합니다. 사람 전문가가 채점한 샘플과 정기적으로 비교하고, 판정 기준을 항목별로 분리하며, 충분한 정보가 없을 때는 모른다고 판정하도록 설계해야 합니다.
Q5. LLM 비용과 응답속도는 어떤 기준으로 배포 여부를 판단하나요?
평균값보다 p95·p99 지연시간, 입력·출력 토큰, 검색 문서 수, 도구 호출 수, 재시도율, 캐시 적중률을 봐야 합니다. 서비스별로 허용 가능한 월 비용과 응답 대기 시간을 먼저 정하고, 그 범위를 넘는 시나리오는 라우팅·캐싱·모델 변경 대상으로 분리합니다.
참고한 자료
이 글은 특정 모델 순위를 제시하기보다 기업이 자체 평가 체계를 설계할 때 필요한 공식 문서와 공개 프레임워크를 참고했습니다.
- OpenAI Evaluation best practices, Working with evals, Graders 문서: 평가 목적, 데이터셋, 자동 채점기, 플랫폼 전환 주의사항. ([platform.openai.com](https://platform.openai.com/docs/guides/evaluation-best-practices))
- Google Gen AI evaluation service와 judge model 평가 문서: 적응형 루브릭, 생산 로그 샘플링, 사람 평점 기반 judge 보정. ([docs.cloud.google.com](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/evaluation-overview))
- Anthropic Claude Console 평가 도구와 에이전트 평가 글: 테스트 케이스 생성, transcript·outcome 중심 에이전트 평가. ([platform.claude.com](https://platform.claude.com/docs/en/test-and-evaluate/eval-tool?utm_source=openai))
- NIST AI RMF와 Generative AI Profile, OWASP LLM Top 10: 사전 배포 위험 측정, 보안·프라이버시·프롬프트 인젝션 체크. ([nist.gov](https://www.nist.gov/itl/ai-risk-management-framework))
- Ragas와 TruLens 문서: RAG 평가 지표와 RAG triad 관점. ([docs.ragas.io](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/))

