[AI Agent] 2기 4주차: LLM 평가 방법과 RAG 지표 이해하기

평가가 필요한 이유

자연스러운 답변이 나와도 요청을 제대로 해결했는지는 따로 확인해야 합니다.
문장이 매끄러워도 중요한 사실이 빠지거나 지시한 형식을 어길 수 있습니다.
평가는 이런 차이를 일정한 기준으로 확인하고 시스템의 변경이 어떤 영향을 줬는지 판단하는 과정입니다.

평가에는 답변 품질과 시스템 성능이라는 두 측면이 있습니다.
지시 준수·문맥의 일관성·사실성은 답변의 품질에 해당합니다.
응답 시간·비용·신뢰성은 서비스를 운영할 때 확인할 성능입니다.
더 정확한 답변을 얻었어도 응답이 지나치게 느려졌다면 그 비용까지 함께 봐야 합니다.

처음 측정한 결과를 기준선으로 두면 모델이나 프롬프트를 바꾼 뒤 같은 조건에서 비교할 수 있습니다.
이전에 처리하던 요청을 다시 실패하는 회귀도 이 과정에서 찾습니다.

다만 특정 시험의 점수가 높다는 사실만으로 서비스 전체의 품질을 설명할 수는 없습니다.
평가에 어떤 질문을 넣었는지, 그 질문과 기준이 실제 사용 상황을 얼마나 반영하는지에 따라 점수의 의미가 달라집니다.

• Stanford CME295 — LLM Evaluation
• Anthropic — Demystifying evals for AI agents

평가를 구성하는 요소

평가 방식을 비교하려면 무엇을 평가하는지와 누가 판정하는지를 먼저 구분해야 합니다.
모델이 만든 답변 하나를 볼 수도 있고 검색과 도구 실행을 포함한 시스템 전체의 결과를 볼 수도 있습니다.
답변에 “완료했다”고 적혀 있어도 실제 작업이 끝났는지는 실행 결과로 확인해야 합니다.

Reference와 Rubric은 서로 다른 역할을 합니다.
Reference는 비교할 답이나 결과를 제시하고 Rubric은 무엇을 근거로 어떤 평가를 내릴지 설명합니다.
정답이 하나로 정해지지 않는 요약이나 설명도 Rubric으로 정확성·완전성·읽기 쉬움 등을 평가할 수 있습니다.

예를 들어 ‘설명이 충분한가’를 판단하려면 어떤 핵심 내용을 포함해야 하고 어떤 누락을 실패로 볼지 구체화해야 합니다.
이 기준을 사람이 읽고 평가할 수도 있고 LLM에 전달해 판정하게 할 수도 있습니다.

규칙은 프로그램으로 검사할 조건을 명시하고 Rubric은 품질을 판단할 항목과 수준을 설명합니다.
코드는 명시적인 검사를 실행하며 사람과 LLM은 Rubric을 해석해 판정할 수 있습니다.
Rubric의 항목 중 길이나 필수 필드처럼 조건을 명확히 표현할 수 있는 부분은 코드로 검사할 수도 있습니다.

코드·사람·LLM 평가는 비용·속도·유연성과 판단의 일관성에서 차이가 있습니다.
기준이 모호하면 평가자를 바꾸어도 점수의 의미가 불안정해집니다.

• Stanford CS329Z — LLM-as-Judge & Evaluation Infrastructure
• Stanford CME295 — LLM Evaluation

규칙·코드 기반 평가

규칙·코드 기반 평가는 사람이 정한 검사나 계산식을 프로그램으로 실행하는 방식입니다.
판정 조건을 명시할 수 있는 항목에 적합합니다.
정답 문자열 일치, 필수 필드와 자료형 검사, 금지 표현 탐지, 프로그램의 테스트 통과 여부 같은 항목입니다.

예를 들어 응답이 JSON인지와 필수 필드가 있는지는 코드로 검사할 수 있습니다.
다만 형식이 맞다는 결과만으로 그 안의 설명까지 정확하다고 판단할 수는 없습니다.

정답과 생성 문장의 표현을 비교하는 지표도 있습니다.
BLEU는 번역문과 참고 번역 사이의 n-gram 일치도를 수정 정밀도와 길이 패널티로 계산합니다.
ROUGE는 요약문을 비교하는 지표 모음이며 ROUGE-N은 참고 요약의 n-gram을 얼마나 포함했는지 확인합니다.

이 지표들을 계산하려면 비교할 참고 번역이나 참고 요약을 준비해야 합니다.
두 지표는 표현의 겹침을 정해진 방식으로 계산하지만 같은 뜻을 다른 말로 표현한 답변이나 사실의 정확성까지 충분히 판정하지는 못합니다.

이 방식은 빠르고 비교적 저렴하며 같은 입력·평가 코드·실행 환경에서 채점을 반복하기 쉽습니다.
모델이 매번 다른 답변을 생성하는 것과 저장된 한 답변을 같은 코드로 채점하는 것은 구분해야 합니다.

그러나 같은 점수를 반복해서 얻는다는 사실이 올바른 평가 기준을 뜻하지는 않습니다.
테스트가 확인하지 않는 오류는 통과할 수 있고 문자열 일치는 의미가 같은 다른 표현을 오답으로 처리할 수 있습니다.
따라서 규칙이 실제 성공 조건의 어느 부분을 확인하는지 살펴야 합니다.

도시명 추출 문제에서 정답이 ‘대전’이라면 ‘대전광역시’도 같은 도시를 가리킬 수 있습니다.
문자열 일치를 적용하려면 허용할 표기와 정규화 범위를 먼저 정해야 합니다.
검사 규칙을 바꾸면 같은 답변의 점수도 달라질 수 있으므로 비교할 때에는 채점 조건도 함께 확인합니다.

• Stanford CS329Z — 코드 기반 평가
• Stanford CME295 — 규칙 기반 지표와 한계
• BLEU 원 논문
• ROUGE 원 논문

사람 평가

사람 평가는 평가자가 답변이나 작업 결과를 읽고 정해진 기준에 따라 판단하는 방식입니다.
도메인 전문가가 사실의 정확성을 검토하거나 실제 사용자가 설명의 유용성을 판단할 수 있습니다.
개별 평가는 기준에 따라 한 답변에 점수·통과 여부를 부여하고 pairwise 평가는 같은 요청에 대한 두 답변을 비교합니다.

사람은 문맥과 사용 목적을 고려하고 예상하지 못한 오류도 설명할 수 있습니다.
이때 Rubric이 ‘좋은 답변’의 의미를 구체화합니다.
요약 평가라면 ‘원문에 없는 사실을 추가했는가’와 ‘중요한 내용을 빠뜨렸는가’를 나누어 볼 수 있습니다.
문장이 매끄럽다는 인상과 내용이 정확하다는 판단을 구분하는 데에도 기준표가 필요합니다.

평가자가 무엇을 보고 판단하는지도 중요합니다.
원문과 요약문을 함께 읽는 사실 검토와, 요약문만 읽고 이해하기 쉬운지 판단하는 평가는 서로 다른 질문에 답합니다.
평가 항목이 같아 보여도 제공한 정보와 점수의 의미가 다르면 결과를 직접 비교하기 어렵습니다.

한계는 시간·비용과 평가자 간 차이입니다.
평가자나 평가 시점이 달라지면 같은 판정을 다시 얻기 어려울 수 있습니다.
같은 ‘유용성’이라는 항목도 평가자의 지식이나 기대에 따라 다르게 해석할 수 있습니다.

평가 지침과 예시를 공유한 뒤 여러 사람이 같은 응답을 판정해 불일치를 살피면 모호한 기준이나 놓친 조건을 찾을 수 있습니다.
단순 일치율에 더해 우연히 일치할 가능성을 고려하는 Cohen’s kappa 같은 지표도 사용합니다.
일치도는 판단의 일관성을 보여주지만 여러 사람이 같은 오해를 할 가능성까지 없애지는 않습니다.

사람이 만든 기대 답변이나 라벨도 검토 대상입니다.
평가자가 원문을 잘못 읽거나 허용할 수 있는 다른 답을 빠뜨리면 자동 평가도 그 오류를 이어받습니다.
사람 평가를 기준으로 활용할 때에는 평가자의 전문성, 적용한 기준과 판단 근거를 함께 확인해야 합니다.

• Stanford CS329Z — 사람 평가의 방식과 한계
• Stanford CME295 — 평가자 간 일치도
• Best practices for the human evaluation of automatically generated text

LLM 평가

LLM 평가는 모델에 입력·응답·평가 기준을 주고 결과를 판정하게 하는 방식입니다.
문자열이 달라도 같은 의미인지, 설명이 질문에 충분히 답했는지처럼 규칙으로 표현하기 어려운 관계를 평가할 때 사용할 수 있습니다.
이처럼 LLM으로 결과를 판정하는 방식을 LLM-as-a-Judge라고 부릅니다.

기대 답변을 함께 주고 실제 응답과 비교하는 평가를 reference-based 평가라고 합니다.
기대 답변을 준비하지 않은 요약·설명에서는 Rubric에 따라 관련성이나 완전성을 판정할 수도 있습니다.

여기서 reference-free는 비교용 기대 답변을 사용하지 않는다는 뜻입니다.
요약의 사실 일치를 확인하려면 원문이 필요하듯, 판정에 필요한 자료까지 없어도 된다는 뜻은 아닙니다.
Rubric은 두 경우 모두에 사용할 수 있습니다.

판정 형식도 구분해 보겠습니다.
Pointwise 평가는 응답 하나를 기준에 맞춰 채점합니다.
Pairwise 평가는 두 응답 중 어느 쪽이 더 나은지 비교합니다.

기대 답변의 사용 여부와 응답을 비교하는 형식은 서로 다른 선택입니다.
두 답변을 비교해 하나를 골랐어도 두 답변 모두 기준 미달일 수 있습니다.

LLM은 같은 Rubric을 많은 응답에 반복 적용하기 편하지만 판정의 정확성은 별도로 확인해야 합니다.
앞에 놓인 응답을 선호하는 위치 편향, 긴 답변을 높게 평가하는 장황함 편향, 자신이 만든 답변을 선호하는 편향이 나타날 수 있습니다.
같은 입력에도 판정이 달라질 수 있어 평가 모델과 프롬프트·설정을 기록해야 합니다.

채점 기준을 명확히 정하고 점수와 판단 근거를 함께 기록합니다.
두 답변의 순서를 바꿔 점검하거나 생성과 평가에 다른 모델을 쓰는 방법도 검토할 수 있습니다.
이 조치만으로 편향이 사라지지는 않습니다.
사람이 검수한 성공·실패 응답과 Judge의 판단을 대조하고 불일치가 생긴 이유를 읽어야 합니다.

• Stanford CME295 — LLM Evaluation
• Stanford CS329Z — LLM-as-Judge & Evaluation Infrastructure
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

평가 방식의 조합

하나의 응답에도 형식·정확성·완전성처럼 서로 다른 평가 항목이 있습니다.
각 항목을 잘 판정할 수 있는 평가 방식을 연결하면 서로의 한계를 보완할 수 있습니다.
코드 검사, LLM의 의미 판단과 사람의 검토를 평가 항목에 맞게 연결할 수 있습니다.

예를 들어 문서를 요약해 JSON으로 반환하는 응답을 평가한다고 가정해 보겠습니다.
코드는 JSON 파싱과 필수 필드의 존재를 검사할 수 있습니다.

사람은 원문과 요약을 읽어 핵심 조건이 빠졌는지 검토합니다.
LLM에는 같은 원문과 Rubric을 주어 많은 응답의 사실 일치·누락 여부를 판정하게 할 수 있습니다.
어느 평가자가 맡든 정확성과 완전성의 기준은 같아야 합니다.

결과를 합치는 방법도 평가 목적에 따라 달라집니다.
필수 조건은 모두 통과해야 하는 방식과 항목별 점수를 가중 합산하는 방식이 있습니다.

형식이 올바르다는 높은 점수가 사실 오류를 가리지 않도록, 전체 점수와 항목별 실패를 함께 읽어야 합니다.
사람의 검토도 처음 정답을 만드는 단계와 자동 평가의 불일치를 확인하는 단계에 연결할 수 있습니다.

• Stanford CS329Z — 평가자 조합과 결과 집계, PDF 23쪽

RAG에서 검색과 답변을 나눠 평가하는 이유

평가 방식과 지표의 차이를 RAG에 적용해 보겠습니다.
RAG의 답변이 틀렸다면 필요한 자료를 찾지 못했는지, 찾은 근거를 잘못 해석했는지 구분해야 합니다.

검색에는 관련 근거를 찾는 지표를 적용하고 생성 답변에는 근거 충실성과 기대 답변의 충족 여부를 적용합니다.
같은 평가 방식도 무엇을 비교하느냐에 따라 다른 지표가 됩니다.

Precision과 Recall

Precision은 검색한 결과 중 관련 결과의 비율이고 Recall은 전체 관련 결과 중 검색한 비율입니다.
상위 K개를 평가할 때는 문서나 청크처럼 관련성을 판정할 단위를 먼저 정합니다.

Precision@K = 상위 K개 중 관련 청크 수 / K
Recall@K = 상위 K개에서 찾은 관련 청크 수 / 전체 관련 청크 수

설명용으로 관련 청크가 총 4개이고 상위 3개에서 그중 2개를 찾았다고 가정해 보겠습니다.
Precision@3은 2/3이고 Recall@3은 2/4입니다.
첫 값은 검색 결과에서 관련 청크의 비율을, 둘째 값은 전체 관련 청크 중 찾은 비율을 나타냅니다.

관련 청크 전체 집합을 모르면 정확한 Recall@K의 분모도 정할 수 없습니다.
필수 사실을 몇 개 찾았는지 확인할 수는 있지만 이 경우에는 사실 단위의 근거 충족률이라고 구분합니다.

K를 늘리면 더 많은 근거를 찾을 수 있는 대신 무관한 내용과 중복도 늘 수 있습니다.
같은 순위 목록에서 K를 늘릴 때 Recall은 내려가지 않지만 Precision은 관련 결과의 분포에 따라 달라집니다.

관련성 라벨을 사람이 만들고 코드로 비율을 계산할 수도 있고 LLM이 관련성을 판단하게 할 수도 있습니다.
계산식이 같아도 관련성 판정이 달라지면 점수가 달라집니다.

Ragas의 LLM 기반 ContextPrecision은 관련 청크의 순위를 반영하며 ContextRecall은 기대 답변의 주장 중 검색 근거가 뒷받침하는 비율을 봅니다.
두 지표를 위의 청크 집합 기반 Precision@K·Recall@K와 같은 값으로 취급하지 않습니다.

• Stanford Introduction to Information Retrieval — Precision과 Recall
• Ragas — Context Precision
• Ragas — Context Recall

Faithfulness와 Factual Correctness

Faithfulness는 답변에 포함된 주장을 평가에 입력한 컨텍스트가 뒷받침하는지 확인합니다.
RAG의 실제 입력에 대한 근거 충실성을 평가하려면 생성 모델에 전달한 컨텍스트를 사용해야 합니다.
Ragas의 LLM 기반 지표는 답변을 주장으로 나눈 뒤 각 주장의 근거 지지 여부를 판정해 비율을 계산합니다.
기대 답변과 비교하는 FactualCorrectness는 실제 답변의 사실이 기대한 내용과 얼마나 일치하는지 평가합니다.

설명용 원문에 ‘도서관은 평일 9~18시에 운영하고 주말에는 쉰다’고 적혀 있다고 가정해 보겠습니다.
질문이 평일 운영시간과 주말 운영 여부를 모두 물었는데 ‘평일 9~18시에 운영한다’고만 답했다면, 말한 내용은 근거에 충실해도 주말 안내가 빠져 있습니다.
Faithfulness가 높다는 사실만으로 질문 전체에 충분히 답했다고 판단할 수는 없습니다.

FactualCorrectness의 precision 모드는 답변에 쓴 사실의 일치를, recall 모드는 기대한 사실의 누락을 살피며 F1은 두 값을 함께 반영합니다.
이 판정도 기대 답변이 정확하고 충분하다는 조건에 의존합니다.

전달된 근거에 잘못된 내용이 있고 답변이 이를 그대로 옮겼다면 Faithfulness는 높아도 올바른 기대 답변과 비교한 FactualCorrectness는 낮을 수 있습니다.
반대로 모델의 사전 지식으로 정답을 맞혔지만 전달된 근거에는 없다면 Faithfulness는 낮고 FactualCorrectness는 높을 수 있습니다.

검색 지표에는 검색 결과의 순위 목록을, Faithfulness에는 실제 생성에 전달한 컨텍스트를 넣습니다.
검색된 청크 전체와 생성 모델에 전달한 컨텍스트는 길이 제한 등의 이유로 다를 수 있습니다.

Faithfulness에 다른 실행의 검색 결과를 넣으면 실제 입력을 기준으로 한 평가가 되지 않습니다.
어떤 점수가 낮은지 확인한 뒤 해당 문항의 근거와 답변을 읽어야 검색·컨텍스트 구성·생성 중 개선할 위치를 좁힐 수 있습니다.

• Ragas — Faithfulness
• Ragas — Factual Correctness

평가 결과를 읽는 기준

평균 점수는 전체 경향을 보여주지만 어느 질문에서 왜 실패했는지까지 설명하지는 않습니다.
질문 유형별 결과와 대표 실패를 함께 읽으면 대부분의 쉬운 질문에 가려진 오류를 찾을 수 있습니다.
같은 입력을 반복 실행했다면 가장 좋은 결과만 고르지 않고 실행 횟수와 변동을 함께 표시합니다.

평가 데이터도 실제 사용 범위를 대표해야 합니다.
개발 과정에서 계속 확인한 문항은 조정용으로 관리하고 최종 확인에는 별도 문항을 남깁니다.
데이터가 작거나 특정 유형에 치우쳐 있다면 그 결과로 서비스 전체의 우열을 단정하기 어렵습니다.

시스템을 비교할 때는 평가 데이터·기준·지표·평가자 조건을 맞춥니다.
답변 점수가 높아져도 응답 시간과 비용이 크게 늘었다면 서비스에서 받아들일 수 있는 변화인지 따로 판단해야 합니다.
평가자의 판정이 바뀌어서 오른 점수와 시스템의 실제 개선도 구분해야 합니다.

Ragas 같은 프레임워크는 데이터를 반복 실행하고 지표를 계산하는 일을 돕습니다.
사용할 지표가 무엇을 측정하는지와 결과를 어떤 판단에 쓸지는 서비스의 목적에 맞게 정합니다.
기준과 평가자의 판단이 적절한지도 함께 확인해야 합니다.

• Anthropic — Demystifying evals for AI agents
• Stanford CS329Z — LLM-as-Judge & Evaluation Infrastructure

참고 자료

• Stanford CME295 — LLM Evaluation
• Stanford CS329Z — LLM-as-Judge & Evaluation Infrastructure
• Anthropic — Demystifying evals for AI agents
• BLEU 원 논문
• ROUGE 원 논문
• Best practices for the human evaluation of automatically generated text
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
• Stanford Introduction to Information Retrieval — Precision과 Recall
• Ragas — Context Precision
• Ragas — Context Recall
• Ragas — Faithfulness
• Ragas — Factual Correctness