운영 환경에서 LLM 출력 품질 평가하기

2023년 3월에 GPT-4는 어떤 숫자가 소수인지 97.6%의 정확도로 알려줄 수 있었습니다. 같은 해 6월에는 _같은 모델 이름_이 동일한 질문들에 대해 단지 2.4%만 올바르게 답변했습니다. 아무도 잘못된 커밋을 푸시하지 않았습니다. 레포지토리에서 프롬프트도 변경되지 않았습니다. API 뒤에 있는 그 무언가가 그저... 움직였습니다.

이 수치는 Stanford와 Berkeley의 연구인

• 오프라인 평가 (Offline evals): 회귀 테스트 (regression tests)와 같이, 프롬프트나 모델이 변경될 때마다 실행하는 고정된 테스트 세트입니다.
• 참조 없는 검사 (Reference-free checks): 환각 탐지 (hallucination detection)와 같이, 비교할 "정답" 없이 실제 답변만으로 계산할 수 있는 신호입니다.
• 운영 모니터링 (Production monitoring): 실제 트래픽의 흐름을 관찰하며 드리프트 (drift), 거부 (refusals), 그리고 시간이 지남에 따른 품질 저하를 감시하는 것입니다.

이 세 가지를 모두 갖추면 안전망을 확보하게 됩니다. 이 중 하나라도 생략하면 잘못된 출력이 빠져나갈 구멍이 생깁니다.

골든 데이터셋 (Golden datasets): 회귀 테스트의 기준점

골든 데이터셋 (golden dataset)은 LLM 버전의 회귀 테스트 스위트 (regression test suite)입니다. 이는 예상 출력(또는 채점 기준/rubrics)과 쌍을 이루는, 큐레이션되고 버전 관리가 되는 입력 세트입니다. 프롬프트를 수정하거나, 모델을 교체하거나, 온도를 조절할 때마다 전체 세트를 실행하고 그 점수를 마지막으로 확인된 양호한 실행 결과와 비교합니다. 만약 근거성 (groundedness) 점수가 3점 하락했다면, 고객 지원 티켓이 접수되기 전에 CI (지속적 통합) 단계에서 이를 발견한 것입니다.

"골든 (golden)"이라는 부분이 중요합니다. 이것들은 무작위로 추출된 운영 샘플이 아닙니다. 특이한 사례들을 포함하여 실제로 중요하게 생각하는 케이스들을 나타내도록 수동으로 큐레이션되고 검토된 예시들입니다. 에지 케이스 (edge cases)가 핵심입니다. 빈 입력, 적대적 프롬프트 (adversarial prompt), 제품이 부분적으로만 지원하는 제2외국어로 된 질문, 파서를 망가뜨리는 고객 데이터 등이 이에 해당합니다. 80개의 날카로운 예시로 구성된 골든 세트는 8,000개의 무작위 샘플보다 훨씬 낫습니다. 무작위 샘플들은 쉬운 중간 단계에 몰려 있어, 치명적인 실패에 대해서는 아무런 정보도 주지 않기 때문입니다.

다음은 오프라인 평가의 형태입니다. 평가 도구 (eval harnesses)는 두 생태계 모두에서 사용되므로, 몇 가지 언어로 동일한 개념을 보여줍니다.

:::tabs
eval_golden.py

import json

# golden.jsonl: 한 줄당 하나의 {"input": ..., "expected": ..., "rubric": ...} 형태
...

eval_golden.ts

import { readFileSync } from "node:fs";

type Case = { input: string; expected?: string; rubric?: string };
...

:::

흥미로운 질문은 루프(loop)가 아니라 scorer입니다. 출력을 0에서 1 사이로 점수 매긴다는 것은 무엇을 의미할까요? 바로 그 지점에 대부분의 실제 작업이 집중되어 있습니다.

실제로 답변을 어떻게 점수 매기나요?

점수 매기기 방법에는 사다리 구조가 있으며, 아래로 갈수록 저렴하고 취약하며, 위로 갈수록 비용이 많이 들고 유연합니다.

정확한 일치 및 퍼지 매칭 (Exact and fuzzy match). 분류 레이블(classification label), SQL 쿼리(SQL query), JSON 필드와 같이 정답이 하나뿐인 경우에 유용합니다. output == expected를 확인하거나, 공백과 대소문자를 제거한 정규화된 버전을 사용합니다. 저렴하고 결정론적(deterministic)이며 모호함이 전혀 없습니다. 하지만 답변이 문단 형태가 되는 순간 무용지물이 됩니다.

휴리스틱 및 구조적 검사 (Heuristic and structural checks). 출력이 유효한 JSON으로 파싱(parse)되는가? 필요한 필드를 포함하고 있는가? 길이 제한을 초과하지 않았는가? "죄송합니다, 도와드릴 수 없습니다"라는 문구를 포함하고 있지는 않은가? 이러한 방식은 단순하고 빠르며 놀라울 정도로 많은 오류를 잡아냅니다. 파싱할 수 없는 출력의 급증은 상류(upstream) 단계에서 무언가 고장 났음을 알리는 가장 초기 경고 신호 중 하나입니다.

참조 기반 의미론적 점수 매기기 (Reference-based semantic scoring). 문자열이 아닌 의미를 기준으로 출력을 참조 답변(reference answer)과 비교합니다. 임베딩 유사도(Embedding similarity)나 BERTScore와 같은 지표를 사용합니다. 표현의 차이를 허용합니다. 단점은 참조 답변이 필요하며, 정답인 것과는 별개로 단순히 비슷하게 들리는 것에 점수를 준다는 점입니다.

LLM-as-a-judge (판사로서의 LLM). 출력값(그리고 선택적으로 루브릭(rubric)과 참조 답변)을 강력한 모델에게 전달하고 점수를 매기도록 요청합니다. "1점에서 5점 사이의 척도로, 이 답변이 제공된 문맥에 얼마나 충실합니까? 이유를 설명한 뒤 점수를 부여하세요." 이것은 현대적 평가(eval)의 핵심 동력입니다. 왜냐하면 인간과 유사한 판단을 수천 개의 사례에 대해 각각 단 몇 센트의 비용으로 확장할 수 있기 때문입니다. MT-Bench 저자들은 GPT-4가 인간 평가자와 일치하는 비율이 80%가 넘는다는 것을 발견했는데, 이는 대략 두 명의 인간이 서로 일치하는 비율과 비슷합니다. 이는 유용하게 사용하기에 충분히 좋은 수준이면서도, 동시에 당신을 곤란하게 만들 만큼 딱 적당히 신뢰할 수 없는 수준입니다. 이것이 바로 다음 섹션의 핵심 내용입니다.

LLM-as-a-judge는 예측 가능한 방식으로 당신에게 거짓말을 할 것입니다

LLM 판사(judge)를 홍보할 때 아무도 말해주지 않는 부분이 있습니다. 바로 판사에게는 편향(bias)이 있으며, 그 편향은 체계적이라는 점입니다. 즉, 편향이 평균적으로 상쇄되지 않는다는 뜻입니다. 편향은 수치를 일관된 방향으로 왜곡하며, 당신은 판사가 자신감 넘치는 설명을 함께 내놓기 때문에 그 결과를 신뢰하게 될 것입니다.

**위치 편향 (Position bias)**이 가장 심각한 문제입니다. 판사에게 "A와 B 중 어떤 답변이 더 나은가요?"라고 물으면, 내용은 상관없이 먼저 나온 답변을 선호합니다. "Large Language Models are not Fair Evaluators" 논문에서 연구진은 Vicuna-13B를 ChatGPT와 비교했는데, Vicuna가 첫 번째 슬롯에 있을 때의 승률은 51.3%였으나 두 번째 슬롯에 있을 때는 23.8%로 나타났습니다. 동일한 두 답변과 동일한 판사였지만, 바뀐 것은 오직 순서뿐이었습니다. 다른 연구에서는 GPT-4의 위치를 바꿀 때 판결이 약 절반의 확률로 뒤집힌다는 것을 발견했습니다. 만약 당신의 평가 파이프라인(eval pipeline)이 항상 새로운 프롬프트의 출력을 두 번째에 배치한다면, 당신은 배포할 때마다 발생하는 모든 변경 사항에 대해 조용히 불이익을 주고 있는 셈입니다.

해결책은 간단합니다. 각 비교를 양방향으로 실행하고, 두 순서 모두에서 판사가 일치할 때만 승리로 간주하십시오. 무승부는 "유의미한 차이 없음"으로 처리합니다.

judge_swap.py

def judge_pairwise(judge, question, answer_a, answer_b):
    # 위치 편향을 상쇄하기 위해 두 가지 순서로 모두 실행
    verdict_1 = judge(question, first=answer_a, second=answer_b)
...

**Verbosity bias (장황함 편향)**가 그다음입니다. 판독기(judge)는 더 짧고 명확하며 똑같이 정답인 답변보다, 더 길고 정교한 답변에 보상을 주는 경향이 있습니다. 만약 당신의 "개선된" 프롬프트가 더 장황한 출력을 생성한다면, 판독기는 단순히 단어 수 때문에 더 높은 점수를 줄 수 있으며, 당신은 실제로는 단순한 인플레이션에 불과한 승리를 측정하게 됩니다.

**Self-enhancement bias (자기 강화 편향)**는 교묘한 문제입니다. 모델들은 자기 자신이나 동일한 계열의 모델이 생성한 텍스트를 선호하는 경향이 있습니다. GPT-4를 사용하여 GPT-4의 출력을 판독하는 것은 마치 학생이 자신의 시험지를 직접 채점하게 하는 것과 비슷합니다. 중요한 상황이라면, 답변을 생성한 모델과 다른 모델 계열로 판독하거나, 보정(calibrate)을 위해 사람이 라벨링한 데이터 세트(human-labeled slice)를 유지하십시오.

경고
단일 LLM 판독기 점수를 정답(ground truth)으로 취급하지 마십시오. 먼저 수백 개의 사람이 라벨링한 예시를 통해 이를 보정하고, 판독기가 사람과 얼마나 자주 일치하는지 측정하십시오. 그 후에야 확장(scale) 단계에서 이를 신뢰할 수 있습니다. 보정되지 않은 판독기는 현실과의 관계가 알려지지 않은, 확신에 찬 숫자일 뿐입니다.

정답지가 없는 상황에서 환각(hallucination) 잡아내기

오프라인 평가(Offline evals)는 정답을 알고 있다고 가정합니다. 하지만 운영 환경(Production)은 그런 사치를 허용하지 않습니다. 사용자가 본 적 없는 질문을 던지고 모델이 답변하면, 당신은 비교할 참조 대상 없이 지금 당장 그 답변을 신뢰할지 결정해야 합니다. 이것이 참조 없는 평가(reference-free evaluation)이며, 진정으로 영리한 기술들이 존재하는 영역입니다.

제가 접한 가장 강력한 접근 방식은 2024년 Oxford 연구팀이 Nature에 발표한 **semantic entropy (의미론적 엔트로피)**입니다. 그 직관은 매우 아름다우며 한 문장으로 설명할 수 있습니다. 모델이 실제로 무언가를 알고 있을 때는 여러 가지 다른 방식으로 같은 내용을 말합니다. 반면, 모델이 말을 지어내고(confabulating) 있을 때는 매번 다른 내용을 만들어냅니다.

따라서 동일한 답변을 여러 번 샘플링(sample)합니다. 그다음, 이것이 핵심적인 단계인데, 문자열(strings)을 비교하는 것이 아니라 그 '의미(meanings)'를 비교합니다. 자연어 추론(natural-language-inference) 체크를 사용하여 샘플들이 서로 함의(entail)하는지 여부에 따라 샘플들을 클러스터링(cluster)합니다 (예: "Paris"와 "It's Paris, the capital of France"가 같은 의미인가요? 예, 같은 클러스터입니다). 그런 다음 토큰(tokens)이 아닌 이 '클러스터(clusters)'에 대해 엔트로피(entropy)를 측정합니다.

낮은 의미론적 엔트로피(Low semantic entropy)는 모든 샘플이 하나의 의미로 수렴했음을 의미합니다. 즉, 모델이 일관적이며 아마도 근거(grounded)가 확실하다는 뜻입니다. 높은 의미론적 엔트로피(High semantic entropy)는 샘플들이 여러 다른 의미로 흩어져 있음을 의미합니다. 즉, 모델이 추측하고 있으며, 이것이 바로 환각(hallucination) 플래그가 됩니다. 놀라운 점은 이것이 정답(ground truth)을 전혀 필요로 하지 않는다는 것입니다. 이는 모델이 '자기 자신'과 모순되는 지점을 잡아내는데, 모델은 실제로 내용을 알지 못할 때만 이런 모순을 일으키기 때문입니다.

semantic-entropy-sketch

prompt -> sample answer 5x
  "Paris"                         ┐
  "The capital is Paris"          ├─ cluster 1 (same meaning)
...

RAG 시스템의 경우, 알아둘 만한 더 단순한 형제 격인 **RAG 삼각측량(RAG triad)**이 있습니다. 모든 답변에 대해 세 가지를 점수화합니다: 충실도(faithfulness, 답변이 검색된 컨텍스트(context)를 따르는가, 아니면 그 너머의 내용을 지어내는가?), 답변 관련성(answer relevance, 실제로 질문에 답하고 있는가?), 그리고 컨텍스트 관련성(context relevance, 검색이 올바른 문서를 가져왔는가?). 삼각측량법이 잡아내는 치명적인 실수(footgun)는 매우 교묘한 것입니다. 바로 완벽하게 유창하고 완벽하게 자신감 넘치는 답변이, 정작 근거로 삼아야 할 소스 문서(source document)와 조용히 모순되는 경우입니다. 충실도 점수 측정은 바로 그 문제를 수면 위로 끌어올립니다.

직접 응시하지 않고도 운영 환경 모니터링하기

오프라인 평가 (Offline evals)는 배포하기 전에 변경 사항이 안전한지 알려줍니다. 하지만 3주 후에 모델이 드리프트 (drift)되는 현상이나, 제공업체가 엔드포인트(endpoint) 뒤에서 조용히 가중치 (weights)를 교체하는 경우, 또는 5명의 사람이 각각 이유를 기록하지 않고 프롬프트를 조금씩 수정하면서 여러분의 프롬프트가 서서히 부식되는 것에 대해서는 아무것도 말해주지 않습니다. 마지막 현상은 이제 _프롬프트 드리프트 (prompt drift)_라는 이름까지 붙었는데, 이는 기록되지 않은 작은 수정들로 인해 누적된 품질 저하를 의미하며, 운영 환경의 LLM 사고 중 상당 부분의 원인으로 지목됩니다.

모든 실시간 요청을 비용이 많이 드는 판정 모델 (judge)로 채점할 필요는 없습니다. 비용에 따라 다음과 같이 계층화하십시오: