RAG 애플리케이션
평가하기 Evaluating Your RAG Application

고칠 수 없는 것을
측정하지 않는 대가

자체 구축이든 플랫폼이든, 사용자가 애플리케이션을 쓸 때 보게 되는 응답의 품질을 측정할 수 있어야 한다. 이것을 RAG 평가라 부른다. 시스템이 올바른 문서나 청크를 얼마나 정확히 찾아내는지(검색 정확도)와, 그 문서나 청크로부터 얼마나 일관되고 올바르게 응답을 만들어내는지(생성 정확도)를 측정한다. 세부로 뛰어들기 전에 두 종류의 평가를 구별해 두는 것이 도움이 된다.

이 장은 주로 오프라인 평가에 집중해 그것이 왜 중요한지, 어떤 지표를 고려해야 하는지, 각 지표를 어떻게 해석해야 하는지 논의한다. 온라인 평가는 뒤에서 간략히 다루며 몇 가지 모범 사례를 제시한다.

RAG는 어떻게 실패하는가

품질을 측정하는 체계적 접근이 없다는 것은 기술적 부주의에 그치지 않는다. AI 전략 전체를 허물 수 있는 사업 위험이다. 구조적이고 엄정한 평가 틀이 없으면 환각이나 부정확한 답변을 내놓는 애플리케이션을 배포하는 위험을 감수하게 되고, 결국 사용자 신뢰가 침식되며 사업에 주는 이득도 깎인다. 프로덕션에서 이런 기술적 실패는 고객 만족도 하락, 순추천지수(NPS) 하락, 심지어 (흔히 값비싼) 컴플라이언스 사고의 증가로 나타난다.

1장에서 배운 대로 질의 흐름은 최소한 두 개의 구별되지만 상호의존적인 구성요소, 검색기와 생성기로 이루어진다. 그중 어느 하나의 실패나 저하가 저품질 출력으로 이어질 수 있다. 그러므로 견고한 평가 전략은 질의 흐름의 모든 구성요소의 문제를 독립적으로 진단할 수 있으면서, 동시에 그것들의 상승적 성능까지 평가할 수 있어야 한다.

검색 실패

RAG에서 가장 결정적이고 흔한 실패 유형이 검색에서 일어난다. 검색 과정에 결함이 있으면 시스템 전체가 훼손된다. 생성기 LLM이 아무리 진보했어도 잘못되거나 무관한 맥락으로 올바르고 관련 있는 답을 만들어낼 수는 없다.

하나의 질의, 세 개의 청크

“프로젝트 출시의 필수 최종 승인 단계는 무엇이고, 위험 평가서 제출의 구체적 기한은 언제인가?”라는 질의를 생각해 보자. 시스템에는 세 개의 청크가 있다.

결국 견고한 검색은 정밀도와 재현율을 동시에 최적화하는 데 달려 있다. recall@k, precision@k, nDCG, UMBRELA 같은 지표를 활용하면 검색 파이프라인의 문제를 식별하고 고쳐, 생성 LLM이 의지할 올바른 사실을 갖게 할 수 있다.

튜닝으로 풀 수 없는 것 — 아키텍처적 한계

많은 검색 실패는 파이프라인 자체를 조정해 해결할 수 있지만, 어떤 실패는 검색 방식 자체의 아키텍처적 한계에 뿌리를 두고 있다. 표준 RAG는 “스타트업 X를 인수한 회사의 본사 위치는 어디인가?” 같은 복잡한 멀티홉 질의나, “엔지니어링 팀은 새 정책을 어떻게 생각하는가?” 같은 넓은 “의미 파악(sensemaking)” 질의에서 흔히 힘들어한다. 이런 질의는 단순한 의미 매칭 이상을 요구하며, 해결하려면 에이전틱 RAG(7장)나 지식 그래프(9장)를 봐야 한다.

생성 실패

검색이 완벽하게(적어도 상당히 잘) 작동해 질의에 답할 최선의 청크를 전달했더라도, 생성 단계의 실패 때문에 나쁜 결과가 나올 수 있다. 효과적인 시스템에는 검색기라는 좋은 사서만이 아니라 생성기라는 유능하고 믿을 만한 저자도 필요하다.

충실성 실패

가장 흔히 환각으로 알려진 유형이며, 아마도 가장 심각한 생성 오류다. LLM의 답변이 제공된 청크의 사실과 직접 모순되거나 그 사실로 뒷받침되지 않을 때 일어난다. 어떤 청크가 “프로젝트 기한은 7월 31일이다”라고 명시했는데 LLM이 “프로젝트 기한은 8월 초다”라고 자신 있게 답한다면, 제공된 정보에 근거해 응답을 생성하라는 일차 명령을 어긴 것이다. 사실 정확성을 위해 시스템에 의존하는 기업 사용자에게 이것은 가장 파괴적인 오류다. 애플리케이션의 신뢰성을 완전히 부순다.

맥락 활용 실패

검색기가 여러 관련 청크를 성공적으로 식별해 제공했는데 LLM이 그것들을 최종 답변에 모두 반영하지 못하는 경우다. 첫 청크나 마지막 청크에만 집중하는 순서 편향 같은 LLM의 난점 때문에 일어날 수 있고, 그러면 모델은 제공된 맥락의 결정적 조각을 사실상 무시한다.

사용자가 “프로젝트 아틀라스의 재무적 위험과 이득은 무엇인가?”라고 묻는다. 검색기는 두 청크를 올바르게 공급한다. 하나는 높은 매출 잠재력(이득)을, 다른 하나는 위험 평가 문서에서 온 심각한 시장 변동성(위험)을 서술한다. 맥락 활용 실패는 LLM이 매출 이득만 서술하고 위험에 관한 맥락은 완전히 무시한 답을 생성할 때 일어난다. 그 답은 맥락의 일부에 근거하고 있으므로 환각은 아니지만, 위험하게 불완전하고 오해를 유발하며, 왜곡된 그림을 제시해 나쁜 의사결정으로 이어질 수 있다.

답변 관련성 실패

LLM의 답변이 제공된 맥락에 온전히 충실하고 관련 사실을 모두 담고 있는데도, 사용자의 핵심 질문이나 의도에 끝내 응답하지 못하는 경우다. 사용자가 “새 업데이트를 배포해도 안전한가?”라고 묻고 맥락이 업데이트의 기능을 나열하고 있을 때, “새 업데이트는 기능 A, B, C를 담고 있다”는 답이 답변 관련성 실패다. 맥락에 따르면 사실적으로 옳지만, 이 응답은 추론의 부담을 사용자에게 되돌려 놓는다. 사용자는 이제 그 기능들을 해석해 배포가 안전한지 스스로 판단해야 한다. 시스템은 요청받은 결론적 통찰을 전달하지 못했고, 그래서 도움이 되는 조수라는 역할에 실패했다.

부실한 데이터 적재로 인한 실패

“쓰레기가 들어가면 쓰레기가 나온다”는 원리가 RAG에 절실하게 적용된다. 시스템 출력의 품질은 원천에서 적재된 데이터의 품질에 근본적으로 갇혀 있다. 파싱과 정제와 색인을 담당하는 적재 파이프라인에 결함이 있으면, RAG가 근거로 삼을 데이터가 본질적으로 훼손된다. 검색기가 아무리 정확하고 생성기가 아무리 정밀해도, 불완전하거나 잘못 구조화되었거나 낡았거나 그저 틀린 진실의 원천을 보상할 수는 없다.

LLM을 심판으로 쓰기

LLM이 더 강력하고 다재다능해지면서 평가에 LLM을 쓰자는 발상이 등장했다. 이 접근의 통용 명칭이 LLM-as-a-judge다. 주어진 지표에 대해 “공정한 심판자”를 시뮬레이션하도록 LLM을 활용한다.

이 접근에서 LLM은 사용자 질의, 애플리케이션이 생성한 응답, 그리고 명시적인 평가 기준(“이 요약을 정확성·간결성·일관성 면에서 1~10점으로 평가하라”)을 받는다. 심판은 주어진 프롬프트에 따라 수치 점수, 범주 등급, 또는 평가를 정당화하는 상세한 서술적 비평을 제공한다.

주된 이점은 유연성이다. 전통적 지표와 달리 자연어 프롬프트로 맞춤화된 상세 루브릭을 줄 수 있다. 간결성, 특정 페르소나의 준수, 인과 추론, 창의성 등 정의하는 거의 모든 기준으로 출력을 채점하도록 지시할 수 있다. 예컨대 심판에게 “회의적인 전문가로 행동해, 답변이 제공된 맥락으로 온전히 뒷받침되며 외연을 넓힌 정보를 담고 있지 않은지 검증하라”고 지시할 수 있다. 그러면 이 복잡하고 다면적인 지시를 수행해 요청받은 형태로 피드백을 제공한다.

연구에 따르면 최적 구성에서 최상급 모델의 판정은 인간 선호와 놀랄 만큼 잘 상관한다. 그러나 이 효과는 “꽂으면 되는” 보장이 아니다. 모델 선택과 프롬프트 설계의 섬세한 균형이다.

LLM 심판은 어떻게 작동하는가

사실성과 답변 관련성을 채점하는 LLM 심판을 만드는 예제 코드를 본다. Ragas의 접근과 유사하다.

import os, json, re
from openai import OpenAI

client = OpenAI()

def evaluate_with_llm_judge(query, context, generated_answer, model="gpt-4o"):
    """LLM으로 RAG 생성 답변의 품질을 평가한다.
    반환: 심판의 점수와 근거를 담은 딕셔너리."""
    if not client:
        return {"error": "OpenAI client not initialized."}

    prompt = f"""
You are an impartial judge evaluating the quality of an answer generated by
a Retrieval-Augmented Generation (RAG) system.

Your task is to evaluate the generated answer based on two criteria:
1. **Factuality**: Is the generated answer factually grounded in the
   provided context? A faithful answer only uses information present in the
   context and does not contradict it.
2. **Answer Relevance**: Is the generated answer relevant and helpful for
   the given query?

You must provide a score from 1 to 5 for each criterion (1=Poor,
5=Excellent) and a brief explanation for your scores.

**Query:** {query}
**Retrieved Context:** {context}
**Generated Answer:** {generated_answer}

Please provide your evaluation *only* in a valid JSON format with the
following keys: "factuality_score", "factuality_reasoning",
"relevance_score", "relevance_reasoning". Your response MUST be a single
JSON object and nothing else.
"""

    try:
        response = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "system", "content": """You are an expert evaluator of
                 AI-generated text that responds only in valid JSON."""},
                {"role": "user", "content": prompt}
            ],
            temperature=0,
        )
        response_text = response.choices[0].message.content

        # 모델이 JSON을 코드 블록으로 감쌀 경우까지 처리한다
        json_match = re.search(r'\{.*\}', response_text, re.DOTALL)
        if json_match:
            return json.loads(json_match.group(0))
        else:
            print("Error: Could not find a valid JSON object in the response.")
            print(f"Full response: {response_text}")
            return None
    except Exception as e:
        print(f"An error occurred during API call or JSON parsing: {e}")
        return None

evaluation_data = {
    "query": "What is the boiling point of water?",
    "context": """At standard atmospheric pressure, water (H₂O) boils at
                 100° Celsius (212° Fahrenheit).""",
    "generated_answer": "Water boils at 100 degrees."
}

evaluation_result = evaluate_with_llm_judge(
    item['query'], item['context'], item['generated_answer']
)

검색 지표

검색 평가는 어떤 RAG 애플리케이션을 진단하든 가장 결정적인 단계다. 결국 하나의 질문으로 귀결된다. “검색 파이프라인이 사용자 질의에 답할 가장 관련성 높은 청크를 원천 데이터셋에서 정확히 식별하고 가져오는가?”

정밀도, 재현율, F1 점수 같은 전통적 정보검색 지표나, MRR·MAP·nDCG 같은 순위 인식 지표를 계산하려면 골든 청크, 즉 사람이 선별해 순위를 매긴 관련 청크 목록을 지정해야 한다. 질의마다 이 골든 청크를 만들고 유지하는 일은, 특히 동적인 프로덕션 환경에서는 악명 높게 어렵고 흔히 불가능하다. 원천 데이터가 진화하면서 정답이 빠르게 낡기 때문이다. 그래도 작은 규모에서는 유용하므로 기초 지표에서 시작해 UMBRELA 같은 더 확장 가능한 기법으로 넘어간다.

기초 지표 — 정밀도, 재현율, F1

보다시피 두 지표 모두 상위 k 안의 관련 청크 수에 의존하며, 그것을 알려면 앞서 말한 골든 청크가 필요하다. 정밀도와 재현율 중 무엇이 더 중요한가. 현실은 둘이 서로 다른 관점에서 검색 시스템의 품질을 평가한다는 것이다. 정밀도는 찾아낸 것의 품질에 집중하고, 재현율은 “찾아야 했던 것”에 비추어 찾아낸 관련 항목의 양에 집중한다.

정밀도와 재현율 사이에는 자연스러운 긴장이 있다. 아주 많은 청크를 그냥 반환하면 시스템은 손쉽게 높은 재현율을 얻지만, 무관한 결과가 대량 포함되어 정밀도가 크게 떨어질 것이다. 반대로 극히 확신하는 몇 개만 반환하면 높은 정밀도를 얻지만, 다른 관련 청크를 많이 놓쳐 재현율이 상한다. 이것이 정밀도–재현율 트레이드오프다.

순위 인식 지표 — MRR, MAP, nDCG

정밀도, 재현율, F1은 기초 지표이지만 주목할 만한 한계가 있다. 상위 k 안의 모든 위치를 동등하게 취급한다. 실무에서 1위의 관련 청크는 10위의 것보다 훨씬 값질 수 있고, “중간에서 길을 잃는” 효과가 작동할 수 있는 긴 프롬프트에서는 특히 그렇다.¹ 순위 인식 지표는 목록의 위쪽에 나타나는 관련 청크에 더 큰 가중을 부여해 이를 다룬다.

MRR은 첫 관련 결과의 위치만 보는 가장 단순한 지표로, 좋은 답 하나를 빠르게 찾는 것이 목표인 과제에 적합하다. MAP는 관련 문서가 나타나는 각 위치의 정밀도를 평균해 더 견고한 평가를 제공하며, 관련 항목을 여러 개 찾을 뿐 아니라 그것을 높이 순위 매기는 시스템에 효과적으로 보상한다. nDCG는 더 높은 순위에 보상하는 데 그치지 않고 관련성의 정도까지 반영할 수 있어 복잡한 검색 흐름 평가의 표준이다.

UMBRELA — 기준 없는 검색 평가

지금까지 논의한 정밀도, 재현율, MRR, MAP의 실무적 난관은 평가에 포함된 질의마다 관련 청크(골든 청크)를 선별하는 어려움이다. 골든 청크를 만드는 일은 수작업이고 시간을 잡아먹으며, 크고 동적인 프로덕션 규모 애플리케이션에서는 실질적으로 불가능한 경우가 많다. 그래서 기준 없는(reference-free) 검색 평가 방법이 개발되었고, Open RAG Eval에 구현된 UMBRELA가 그 예다. 검색된 청크를 정적인 골든 집합과 비교하는 대신, LLM 심판이 각 검색 청크가 질의에 답하는 데 얼마나 관련 있는지 평가한다.

UMBRELA의 성공에 결정적인 점은, 논문이 보이는 대로 이 LLM 생성 점수가 인간 평가자의 점수와 높게 상관한다는 사실이다. 그것이 검색 평가의 견고한 접근으로서 UMBRELA를 정당화한다.

UMBRELA_PROMPT = """
Given a query and a passage, you must provide a score on an integer scale of 0
to 3 with the following meanings:
0 = represents that the passage has nothing to do with the query,
1 = represents that the passage seems related to the query but does not
    answer it,
2 = represents that the passage has some answer for the query, but the
    answer may be a bit unclear, or hidden amongst extraneous information and
3 = represents that the passage is dedicated to the query and contains
    the exact answer.

Important Instructions:
Assign category 1 if the passage is somewhat related to the topic but not
completely, category 2 if the passage presents something very important related
to the entire topic but also has some extra information, and category 3 if the
passage only and entirely refers to the topic.
If none of the above satisfies, give it category 0.

Query: {query}
Passage: {chunk}

Split this problem into steps:
Consider the underlying intent of the search.
Measure how well the content matches a likely intent of the query (M).
Measure how trustworthy the passage is (T).
Consider the aspects above and the relative importance of each, and decide on a
final score (O). The final score must be an integer value only.
Do not provide any code in the result. Provide each score in the format of a
single integer without any reasoning.
"""

query = "How does photosynthesis work in plants?"
chunks = [
    "Photosynthesis is the process used by plants, algae, and certain bacteria
     to convert light energy into chemical energy, through a process that
     converts carbon dioxide and water into glucose and oxygen.",
    "Chlorophyll, the pigment that gives plants their green color, is crucial
     for absorbing sunlight in organelles called chloroplasts.",
    "Mitochondria are known as the powerhouses of the cell, responsible for
     generating most of the cell's supply of adenosine triphosphate (ATP)."
]

기대와 정확히 맞는다. 첫 청크는 질의에 정확한 답을 제공하므로 3점, 두 번째는 질의와 관련된 정보를 담고 있어 2점, 세 번째는 광합성과 아무 관계가 없어 0점이다.

UMBRELA는 인간이 주석한 정답에서 동적이고 AI가 판정하는 방식으로의 전환을 가능하게 하고, 검색 평가를 확장 가능하고 자동화되고 거의 모든 질의와 문서 컬렉션에 적응할 수 있게 만든다. 생성 쪽에서도 AutoNuggetizer가 비슷한 접근을 취한다.

생성 지표

고품질 검색기는 좋은 답변의 재료를 제공하지만 좋은 답변을 보장하지는 않는다. 생성기 LLM은 검색된 맥락을 사실적으로 일관되고 사용자 질의에 직접 응답하며 궁극적으로 옳고 도움이 되는 응답으로 종합해야 한다. 그래서 핵심 질문은 이렇다. “생성 LLM이 제공된 청크를 효과적이고 적절하게 써서 사용자 질의에 대한 고품질 응답을 만들어내는가?”

맥락 활용

맥락 활용은 생성기가 검색된 맥락의 정보를 얼마나 효과적이고 포괄적으로 쓰는지 측정한다. 높은 점수는 필요한 사실을 모두 종합하면서 잡다한 세부에 정신을 팔지 않는 효율적이고 철저한 생성기를 뜻한다. LLM 응답에 인라인 인용이 있으면, 그 인용에 나타난 어떤 맥락 항목이 응답의 어느 부분을 만드는 데 쓰였는지 관찰함으로써 맥락 활용을 부분적으로 볼 수 있다. 더 엄정한 접근이 AutoNuggetizer 지표이며, 다음처럼 작동한다.

1. 너깃 생성과 분류. 시스템이 주어진 질의에 관련된 원자적 사실이나 정보 조각인 “너깃”을 생성한다. 질의와 관련 청크를 함께 분석해 수행한다. 그다음 중요도로 분류한다. Vital 너깃은 포괄적이고 올바른 답에 필수적인 사실이며, 좋은 응답은 이것을 반드시 담아야 한다. OK 너깃은 세부를 더하기에 관련되고 있으면 좋지만, 답이 옳다고 인정되기 위해 엄격히 필요한 것은 아니다.
2. 답변의 너깃 포함 여부 평가. 분류된 너깃이 확립되면 언어모델이 만든 실제 답변을 평가한다. 각 답변에 대해 Supported(너깃의 사실을 온전하고 정확하게 담고 있다), Partially supported(너깃의 정보 일부를 담고 있으나 불완전하거나 완전히 정확하지 않을 수 있다), Not supported(너깃의 정보를 전혀 담고 있지 않다)로 판정한다.
3. 집계. 이 지지 판정들을 점수화하고 집계해 모델 응답의 전체 평가를 산출한다.

답변 정확도

답변 정확도에는 보통 두 지표가 있다. 답변 유사도는 정답과 생성된 답변을 비교하며, 두 문자열의 의미 유사도를 계산하는 인정된 방식인 BERTScore나 ROUGE-L 같은 척도를 쓴다. 답변 관련성은 생성된 답변이 원래 질문에 얼마나 적절한지 평가하며, 불완전하거나 중복된 정보를 담은 답변에 벌점을 준다.

중요한 점은 답변 유사도와 답변 관련성이 모두 골든 답변을 요구한다는 것이다. 반면 (AutoNuggetizer를 통한) 맥락 활용과 충실성은 그것을 요구하지 않는다.

충실성

충실성(사실 일관성)은 생성된 응답이 제공된 청크에 얼마나 근거하고 있는지 측정하며, 생성기가 검색된 청크에 없는 정보를 조작하는 RAG 환각을 평가하는 핵심 지표다. 응답이 하는 모든 진술이 검색된 청크에서 직접 검증될 수 있으면 충실하다고 보고, 모델이 제공된 정보를 넘어 외연을 넓혔으면 환각으로 본다. 사실 일관성은 HHEM 같은 환각 검출 모델을 한 번 호출해 측정할 수도 있고, LLM-as-a-judge로 측정할 수도 있다.

인용 정확도

많은 RAG 시스템이 응답에 인라인 인용을 제공한다. 인용 정확도는 그 인용이 신뢰할 만하며 자신이 박혀 있는 응답 부분을 올바르게 반영하는지 측정한다. 가장 흔한 형태가 인용 정밀도로, 특정 진술에 인용된 출처가 실제로 그 진술을 뒷받침하는지 측정한다. 모델이 문장을 생성하고 인용을 붙였다면, 사용자가 그 링크를 따라가 뒷받침하는 증거를 쉽게 찾을 수 있어야 한다. 높은 정밀도는 시스템이 생성한 진술을 올바른 원본 문서(또는 그 안의 청크)에 정확히 귀속시켜, 오귀속을 막고 검증을 매끄럽게 한다는 뜻이다.

응답 일관성

응답 일관성은 이름 그대로다. 같은 질의를 질의 흐름에 여러 번 돌렸을 때 같은 답을 얻는가, 다른 답을 얻는가. 왜 매번 다를 수 있는가. 주된 이유 하나는 LLM이 비결정적이라는 것이다. 온도를 0으로 설정해도, 같은 프롬프트와 같은 “상위 k 청크”로도 다른 답을 돌려줄 수 있다.

응답 일관성을 체계적으로 측정하는 일은 프로덕션급 애플리케이션의 근본 요구사항이며, 응답의 예측 가능성에 관한 통찰을 준다. 언어모델의 확률적 본성 때문에 표현의 사소한 변동은 받아들일 만하지만, 응답의 사실적 실질은 안정적이어야 한다.

편향과 안전

평가 과정에 안전 가드레일을 직접 통합하면 RAG 평가를 결정적인 안전 검사점으로 확장할 수 있다. 검색된 데이터 청크와 최종 생성 답변 양쪽을 특정한 바람직하지 않은 특성, 그리고 응답의 편향이나 차별에 대해 능동적으로 검사하는 일이다. 흔한 접근은 ShieldGemma나 Llama Guard 같은 전문 안전 모델을 넣어 응답의 안전성이나 편향에 표시를 달게 하는 것이다.

이런 모델은 검색과 생성 단계를 조정해 문제 있는 원천 데이터를 배제하거나 부적절한 응답의 생성을 거부하게 해, 모델이 실세계에서 책임 있게 행동하도록 보장한다. 검색과 생성 양쪽에 쓸 수 있는 지표가 많은데, 어떤 것은 골든 답변을 요구하고 어떤 것은 요구하지 않는다. 사실 일관성은 생성기 평가에서 가장 결정적인 차원일 것이다. RAG의 일차적 약속이 LLM 응답을 검증 가능한 사실에 근거지어 환각 위험을 줄이는 것이기 때문이다.

레드팀 — 자동 지표가 놓치는 것

평가의 일부로 자동 안전 모델을 활용하는 데 더해, 레드팀은 숨은 편향을 스트레스 테스트하는 결정적인 인간 개입 접근을 제공한다. 전담 팀이나 개인이 적대자로 행동해, 편향되거나 불공정한 응답을 유발하도록 설계된 프롬프트와 시나리오를 의도적으로 만들어낸다. 레드팀은 미묘한 언어, 문화적 맥락, 복잡한 윤리적 딜레마를 써서 관습적이지 않은 방식으로 취약점을 탐색하고, 검색과 생성을 평가할 때 자동 지표가 놓칠 수 있는 것을 파헤친다. 시스템이 단일 관점을 반영하는 문서 집합에 과도하게 의존하고 있지 않은가, 해로운 고정관념을 미묘하게 강화하는 언어를 생성하고 있지 않은가 같은 질문이다.

레드팀에서 얻은 통찰은 반복적 개선에 값을 매길 수 없다. 레드팀이 편향된 응답을 성공적으로 끌어내면, 그것으로 더 견고한 안전 필터를 만들고, 특정 유형의 편향된 언어를 피하도록 프롬프트를 수정하고, 나아가 애플리케이션에 적재되는 기저 데이터가 더 다양하고 대표성 있게 되도록 조정을 안내할 수 있다.

평가 도구의 지형

평가 시스템을 직접 만들 수도 있지만 상당한 노력이 필요할 수 있다. 다행히 평가 도구 생태계는 빠르게 성숙하고 있어, 강력한 오픈소스 프레임워크와 상용 도구 가운데서 고를 수 있다. 그 선택은 흔히 유연성과 통제(오픈소스) 대 사용 편의와 관리형 인프라(상용) 사이의 트레이드오프로 귀결된다.

Open RAG Eval

골든 청크나 골든 답변을 요구하지 않는 기준 없는 지표를 도입한 것으로 이름을 얻은, RAG 평가 지형의 최근 추가물이다. Vectara가 워털루 대학 연구자들과 협력해 개발했고, 대규모 실세계 엔터프라이즈 애플리케이션을 위해 정답 데이터셋을 만들고 유지하는 막대한 어려움과 비용을 극복하도록 설계되었다. 기준 없는 목표를 달성하기 위해 연구에 뒷받침된 새 지표들을 통합한다.

Open RAG Eval로 평가하려면 먼저 질의 목록을 만든다. 중요한 점은 질의만 만들면 되고 골든 답변은 필요 없다는 것이다. 유연한 커넥터 아키텍처를 제공해, 지원되지 않는 애플리케이션이라면 커넥터를 손쉽게 만들 수 있고, Vectara·LangChain·LlamaIndex용 기존 커넥터를 쓸 수도 있다. 시스템에서 데이터를 수동으로 JSON 파일에 모아 직접 먹일 수도 있다. 실행할 때는 질의 파일의 위치, 쓸 커넥터, 포함할 평가 지표의 유형을 정의하는 YAML 설정 파일을 만든다. 평가가 끝나면 결과 JSON 파일을 깊이 탐색하거나, 결과를 시각화하는 앱인 Open Evaluation을 쓸 수 있다.

Open RAG Eval의 주된 이점은 기준 없는 평가라는 새로운 접근에 있고, 온전한 투명성과 확장성을 제공하는 간결하고 완전히 오픈소스인 구현에 있다.

Ragas

Ragas(Retrieval-Augmented Generation Assessment)는 또 하나의 오픈소스 평가 프레임워크다. 주로 LLM-as-a-judge 접근을 쓰며, RAG용과 최근에는 에이전틱 워크플로용까지 큰 지표 집합을 포함한다.

전형적인 워크플로는 흔히 허깅페이스 데이터셋 형태로 평가 데이터셋을 만드는 일로 시작한다. 이 데이터셋에는 질문, 생성된 답변, 검색된 맥락 열이 있어야 하고, 정답을 담은 ground_truth 열도 포함할 수 있다. 데이터셋이 준비되면 ragas.evaluate() 함수에 넘기고, 이 함수가 지정된 지표의 점수를 계산해 돌려주기 위한 LLM 호출을 관리한다.

주요 강점 하나는 LangChain, LlamaIndex 같은 인기 라이브러리와의 통합이다. 특히 강력한 기능은 문서 컬렉션에서 테스트셋을 합성해 생성하는 능력이며, 기존 테스트셋이 없을 때 평가를 시작하는 데 도움이 된다. 다만 합성 데이터셋은 사용자 질의나 평가 대상 문서를 정확히 대표하지 않을 수 있으니 주의해서 써야 한다.

이점에도 불구하고 Ragas와 그 지표의 내부 작동은 다소 이해하기 어려울 수 있고, 낮은 점수의 구체적 원인을 진단하는 일이 까다로워질 수 있다. 게다가 기준 없는 지표를 전혀 제공하지 않아 골든 데이터셋의 수동 생성이라는 요구가 무겁게 남는다.

DeepEval

DeepEval은 LLM 평가를 단위 테스트처럼 취급한다는 핵심 철학을 가진 오픈소스 평가 프레임워크다. 전형적 워크플로는 근본적으로 코드 중심이며, pytest 같은 테스트 프레임워크를 쓰는 개발자에게 친숙하도록 설계되었다. 전체 데이터셋을 한 번에 평가하는 대신 개별 LLMTestCase 객체를 정의한다. 그 테스트 케이스를 테스트 함수 안에서 deepeval.assert_test()로 평가하며, 출력이 미리 정한 지표 임계값을 만족하는지 확인한다.

이 접근으로 특정 행동과 예외 사례에 대한 명시적 테스트를 작성할 수 있고, 통상적인 코드에 단위 테스트를 쓰는 방식을 그대로 반영한다. 주요 강점은 pytest 프레임워크와의 긴밀한 통합이며, CI/CD 파이프라인 안의 자동 회귀 테스트에 예외적으로 잘 맞는다. Ragas와 마찬가지로 충실성, 답변 관련성, 맥락 재현율 등 14개가 넘는 지표를 포괄적으로 제공한다.

DeepEval은 G-Eval 지표도 제공해 기준 기반의 커스텀 평가를 가능하게 한다. 주된 장점은 유연성이다. 고정된 지표 집합에 갇히지 않으며, 매우 주관적이거나 도메인에 특수한 것을 평가해야 한다면 그것을 위한 신뢰할 만한 커스텀 지표를 만들 수 있다.

Amazon Bedrock

Amazon Bedrock은 AWS 생태계 안에서 확장 가능한 종단간 해법을 제공하도록 설계된 완전 관리형 서비스로 RAG 평가를 제공한다. 워크플로는 “평가 작업(evaluation job)”을 만드는 것을 중심에 두며, 앤스로픽의 클로드 같은 강력한 기반 모델을 LLM-as-a-judge로 쓰도록 선택한다. 이 작업은 검색 구성요소만 따로 평가하도록, 또는 검색-생성 전체 파이프라인을 평가하도록 설정할 수 있다.

Ragas와 DeepEval과 비슷하게 검색 단계에서는 맥락 관련성과 맥락 재현율을 평가해 올바른 정보가 발견되는지 확인할 수 있다. 생성 단계에서는 (환각을 검출하기 위한) 충실성과, 정답이 있을 때의 정확성 같은 지표로 품질을 측정한다.

Bedrock의 중요한 역량은 책임 있는 AI 평가의 내장 지원이다. 유해성, 고정관념, 답변 거부 같은 차원에서 응답을 자동으로 채점한다. 품질과 안전에 대한 이 이중 초점이 실세계 성능의 더 총체적인 그림을 제공한다. Bedrock의 일차적 강점은 관리형 서비스의 편의와 확장성이며, 팀이 자체 평가 인프라를 만들고 유지할 필요를 없앤다. Guardrails 같은 다른 AWS 서비스와의 깊은 통합이 응집된 개발·거버넌스 경험을 만든다. 다만 상용 플랫폼이므로 심판 모델 사용에 결부된 운영 비용이 따르고, 오픈소스 프레임워크에 비해 기저 평가 프롬프트에 대한 투명성이 낮다.

인간 피드백

자동 평가의 놀라운 진전에도 인간의 판단은 값진 입력으로 남는다. 자동 지표는 미묘함, 복잡한 사용자 의도, 섬세한 인간 가치와의 정렬에서 힘들어할 수 있다. 가장 명백한 접근 하나는 애플리케이션에 좋아요·싫어요 버튼을 넣고 최종 사용자의 응답을 수집해 만족도를 파악하는 것이다. 프록시(자동) 지표에만 의존하는 대신 사용자의 명시적 피드백으로 사용자 만족 점수나 수용률을 계산하고, 그것을 일차 핵심성과지표로 삼는다.

이 접근을 쓰려면 먼저 애플리케이션이 모든 상호작용을 로깅하고 그에 결부된 피드백을 포착하도록 구성해야 한다. 다음 필드를 담은 이벤트를 로깅할 수 있다.

• 상호작용의 고유 ID
• 사용자의 프롬프트
• 검색된 맥락(문서 또는 텍스트 청크)
• 최종 생성된 답변
• 사용자 피드백(좋아요, 싫어요)
• 타임스탬프와 그 밖의 메타데이터(사용자 ID, 세션 ID 등)

이 데이터를 수집하기 시작하면 강력한 지표 몇 가지를 계산할 수 있다.

좋아요·싫어요 피드백을 평가의 직접적 원천으로 취급하는 일은 프로덕션 시스템의 모범 사례다. 핵심은 애플리케이션을 계측해 피드백을 포착하고, 가장 문제 있는 질의나 주제를 정기적으로 검토하고 나쁜 응답의 이유를 분석해 문제를 해결하는 절차를 세우는 것이다.

프로덕션에 평가를 통합하기

어떤 지표를 쓰든 성숙한 평가 틀은 두 가지 근본 과제를 가능하게 해야 한다. 측정과 튜닝이다.

평가 틀을 파이프라인에 통합하면 그것은 “블랙박스”에서 조율 가능한 시스템으로 바뀐다. 애플리케이션의 생애 주기 어디에 있느냐에 따라 오프라인과 온라인이라는 두 순환을 통해 측정과 튜닝을 활용한다. 오프라인 평가는 튜닝의 일차 엔진이다. 고정된 골든 데이터셋에 대해 서로 다른 설정(청킹 전략 조정, 임베딩 모델 교체 등)의 영향을 체계적으로 측정한다. 일단 라이브가 되면 온라인 평가가 조기 경보 시스템으로 작동해, 조율된 모델이 실세계 사용자 의도의 예측 불가능성 앞에서 어떻게 작동하는지 감시한다.

프로덕션에서 LLM 심판을 다루는 법

LLM-as-a-judge가 여러 지표에 중요하므로, 심판을 애플리케이션 자체와 같은 운영적 엄정함으로 다뤄야 한다. 심판은 사실상 이차 모델 호출이므로 비용과 지연이라는 형태로 개발 주기에 “세금”을 매긴다.

오프라인 평가 — 평가 게이트

성숙한 평가 틀은 MLOps 생애 주기, 특히 CI/CD 파이프라인에 깊이 통합되어야 한다. 갱신된 임베딩 모델, 새 재순위기, 정련된 프롬프트 같은 새 구성요소가 프로덕션에 배포되거나 업그레이드되기 전에 평가 게이트를 통과해야 한다. 이 게이트가 품질을 붙잡아 두며, 어떤 변경이든 최소한의 품질 수준을 만족하는지 벤치마크 데이터셋에 대해 테스트하도록 요구한다.

대부분의 프로덕션 시스템에서 이것은 결정적 지표에 대한 무회귀(no-regression) 정책의 집행을 뜻한다. 예컨대 충실성과 검색 관련성 점수가 일정 임계값 위에 머물거나 이전 릴리스보다 개선되기를 요구하면서, P95 지연이 5% 이상 증가하지 않도록 보장하는 식이다.

이 게이트를 유지하려면 애플리케이션과 함께 진화하는 살아 있는 벤치마크가 필요하다. 제품의 범위가 커지거나 새 데이터가 추가되면 그 변화를 반영하도록 벤치마크 집합을 갱신해야 하고, 흔히 어렵거나 실패한 실세계 사용자 질의를 테스트 스위트로 승격시켜 수행한다. 그래야 평가 게이트가 대표성 있는 관문으로 남는다. 그러므로 이 벤치마크 데이터셋을 코드와 함께 버전 관리해 투명한 감사 추적을 유지하고 시간에 걸친 성능 드리프트를 막기를 권한다.

온라인 평가 — 실제 트래픽 위에서

온라인 평가, 즉 라이브 시스템 트래픽에서 수행하는 평가는 실제 사용자 질의에 근거해 문제를 식별하도록 돕고, 오프라인 전략을 잘 보완한다. 그러나 예상대로 몇 가지 난관을 제기한다.

예산을 깨거나 애플리케이션을 느리게 만들지 않으면서 온라인 평가를 실현하려면 “차단형” 평가에서 벗어나기를 권한다. 사용자가 심판의 승인을 기다리게 하는 대신 비동기 평가 파이프라인을 구현한다. 이 아키텍처에서 RAG 시스템은 응답을 즉시 전달하고, 배경 작업자가 질의와 맥락과 답변을 로깅해 “대역 밖에서(out-of-band)” 평가한다. 그러면 UMBRELA나 AutoNuggetizer 같은 기준 없는 검사를 사용자가 체감하는 지연에 1밀리초도 더하지 않고 돌릴 수 있다. 비용을 붙잡아 두기 위해 트래픽의 100%를 평가할 필요는 없다. 상호작용의 5~10%만 지능적으로 표본화해도 시스템 건강의 통계적으로 유의미한 그림을 얻기에 보통 충분하다.

진전된 온라인 평가에는 언제나 A/B 테스트를 시도할 수 있다. 지속적 개선의 표준이다. 사용자의 일부를 “챌린저” 파이프라인(새 재순위 모델이나 정련된 프롬프트를 쓰는)으로 라우팅하고 그 성능을 “챔피언”(현재) 파이프라인과 비교하면, 이 질문에 직접 답을 얻는다. 이 변경이 실제로 사용자를 돕는가? 이런 자동 비동기 점수를 좋아요·싫어요 같은 실시간 인간 피드백과 결합하면, 실사용에서 회귀를 잡아내고 고가치 실패 사례를 오프라인 골든 데이터셋으로 승격시켜 더 튜닝하게 하는 강력한 평가 플라이휠이 만들어진다.

시스템 지표: 지연과 가동률

지금까지는 주로 검색된 청크와 생성된 응답의 품질 측정에 집중했다. 그것을 넘어 표준적인 데브옵스·운영 지표를 품질 대시보드에 넣을 만하다. 이 지표들은 사용자 경험, 확장성, 그리고 애플리케이션의 경제적 존립 가능성에 직접 영향을 주므로 필수적이다.

이 시스템 고려사항은 성공에 결정적이다. 관련 청크를 만들어내는 최고의 검색 파이프라인과 응답을 생성하는 최고의 LLM을 갖췄더라도, 사용자가 애플리케이션의 지속적 장애를 겪는다면 그들은 그냥 쓰기를 멈춘다.