LLM 평가 지표 가이드: 실서비스 전 정확도·환각·안전성·비용 검증 기준 > 인사이트

본문 바로가기

인사이트

#AI·LLM

LLM 평가 지표 가이드: 실서비스 전 정확도·환각·안전성·비용 검증 기준

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

LLM 평가 지표 대시보드를 검토하는 B2B 기술팀의 어두운 워크스페이스
LLM 평가는 모델 고르기가 아니라 실서비스 배포 여부를 판단하는 운영 체계입니다.

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 checkJSON, 날짜, 금액, 필수 필드형식은 맞아도 내용이 틀릴 수 있음
F1·precision·recall다중 라벨, 개체 추출, 검색 결과치명 라벨은 전체 평균에서 분리해야 함
Text similarity전문가 답변과 유사도 비교의미가 비슷해도 핵심 수치가 틀릴 수 있음
LLM rubric score톤, 충실성, 설명 품질, 요약 품질사람 채점 샘플과 주기적으로 보정해야 함
Execution-based checkSQL, 코드, 자동 처리 에이전트샌드박스와 초기 상태를 안정적으로 고정해야 함

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 평가 워크플로우
평가 파이프라인은 요구사항, 골든셋, 채점기, 결과 대시보드, 회귀 테스트가 연결되어야 합니다.

실무형 LLM 평가 파이프라인은 한 번 보고서를 만드는 작업이 아닙니다. 기능 변경 때마다 돌아가는 회귀 테스트여야 합니다. OpenAI의 eval 문서는 과제를 설명하고, 테스트 입력으로 실행하고, 결과를 분석해 프롬프트를 개선하는 흐름을 제시합니다. Google은 데이터셋 생성, 지표 정의, 모델 응답 생성, 평가 실행, 결과 해석 단계를 설명합니다. ([platform.openai.com](https://platform.openai.com/docs/guides/evals))

  1. 평가 목적 정의: 이 AI 기능이 실패하면 어떤 업무 피해가 생기는지 적습니다.
  2. 골든셋 버전 관리: 정상, 경계, 위험, 과거 장애 케이스를 분리하고 변경 이력을 남깁니다.
  3. 모델 어댑터 작성: ChatGPT, Claude, Gemini, 오픈소스 서버, RAG 파이프라인을 같은 입력·출력 인터페이스로 감쌉니다.
  4. 채점기 구성: exact match, schema check, Python 검사, LLM judge, 사람 리뷰를 과제별로 조합합니다.
  5. 결과 대시보드: 전체 평균보다 실패 유형, 위험 등급, 모델별 비용·지연시간을 함께 보여줍니다.
  6. 실패 샘플 리뷰: 점수가 낮은 이유가 모델 문제인지, 검색 문제인지, 채점 기준 오류인지 사람이 확인합니다.
  7. CI·배포 게이트: 프롬프트, 모델, 인덱스, tool schema 변경 시 자동 재실행하고 기준 미달이면 배포를 막습니다.
  8. 운영 모니터링: 실제 로그에서 새로운 실패를 추출해 골든셋에 추가합니다.

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. 모델 비교는 공개 순위가 아니라 자사 시나리오로 한다

여러 LLM 후보를 품질, 비용, 지연시간, 보안 기준으로 비교하는 대시보드
모델 비교는 공개 벤치마크보다 우리 데이터, 우리 실패 유형, 우리 비용 구조에서 실행해야 합니다.

ChatGPT 계열, Claude, Gemini, 오픈소스 모델 중 무엇이 더 좋다는 일반론은 실서비스 의사결정에 충분하지 않습니다. 고객 응대에서는 안전하고 간결한 답변이 중요할 수 있고, 사내 RAG에서는 근거 인용과 문서 권한이 중요할 수 있으며, 관리자 자동화에서는 도구 호출 안정성과 롤백이 더 중요할 수 있습니다.

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

10. 배포 전 체크리스트: 이 항목을 통과해야 한다

LLM 기능 배포 전 체크리스트와 운영 모니터링 보드를 확인하는 회의 장면
배포 게이트는 품질 점수뿐 아니라 안전장치, 비용 한도, 롤백, 로그 모니터링까지 포함해야 합니다.

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/))

자주 묻는 질문

LLM 평가 지표는 정확도만 보면 안 되나요?
안 됩니다. 분류·추출처럼 정답이 명확한 기능은 정확도와 F1이 중요하지만, RAG 답변·요약·에이전트는 근거충실성, 누락, 안전성, 응답형식, 비용, 지연시간까지 함께 봐야 합니다. 실서비스 판단은 단일 점수가 아니라 배포 게이트입니다.
LLM 골든셋은 몇 개 정도 만들어야 하나요?
정해진 숫자는 없습니다. 초기에는 실제 문의, 과거 장애, 위험 케이스를 섞은 작은 세트로 시작해도 됩니다. 중요한 것은 개수보다 대표성입니다. 모델·프롬프트·검색 인덱스가 바뀔 때마다 같은 세트를 재실행할 수 있게 버전 관리해야 합니다.
RAG의 환각은 어떤 지표로 검증하나요?
질문에 맞는 문서가 검색됐는지 보는 context relevance 또는 context precision·recall, 답변의 주장마다 검색 문서에 근거가 있는지 보는 groundedness 또는 faithfulness, 최종 답변이 질문에 실제로 답했는지 보는 answer relevance를 나눠 봐야 합니다.
LLM-as-a-judge 자동 평가는 믿을 수 있나요?
반복 평가와 비교 평가에는 유용하지만 그대로 최종 판정자로 두면 위험합니다. 사람 전문가가 채점한 샘플과 정기적으로 비교하고, 판정 기준을 항목별로 분리하며, 충분한 정보가 없을 때는 모른다고 판정하도록 설계해야 합니다.
LLM 비용과 응답속도는 어떤 기준으로 배포 여부를 판단하나요?
평균값보다 p95·p99 지연시간, 입력·출력 토큰, 검색 문서 수, 도구 호출 수, 재시도율, 캐시 적중률을 봐야 합니다. 서비스별로 허용 가능한 월 비용과 응답 대기 시간을 먼저 정하고, 그 범위를 넘는 시나리오는 라우팅·캐싱·모델 변경 대상으로 분리합니다.
  • Company. 주식회사 에이전트밋
  • Addr.부산광역시 부산진구 서전로 8, 8층 101호 DD-33,34호(부전동) CEO. 윤성훈 Email. agentmit@naver.com
  • BR. 333-87-04232 TEL. 0507-1314-2790
Copyright © 2026 ~ 에이전트밋. All rights reserved.