컨텍스트 품질을 평가하는 법

좋은 AI 시스템을 만들고 싶다면, 이제 질문을 이렇게 바꿔야 한다. 답이 맞았는가가 아니라, 왜 맞았는가. 그리고 틀렸다면 어디서부터 틀어졌는가.

컨텍스트 엔지니어링에서는 이 질문이 특히 중요하다. LangChain이 설명하듯, 컨텍스트 엔지니어링은 적절한 정보와 도구를 적절한 형식으로 모델에 제공해 일을 완수하게 만드는 일이다.¹ 그렇다면 평가도 당연히 최종 문장 하나만 볼 것이 아니라, 그 문장을 만들어 낸 정보 환경 전체를 봐야 한다.

이 장의 핵심은 단순하다. 정답률 하나로는 보이지 않던 문제를, 평가 체계로 드러내자는 것이다. 관련성, 충실성, 최신성, 간결성, 재현성이라는 다섯 기준으로 컨텍스트를 측정하면, 모델을 바꾸기 전에 무엇을 고쳐야 하는지 훨씬 선명하게 보이기 시작한다.

정답률 하나로는 왜 부족한가

시험 점수만 보면 공부가 잘되는 것 같지만, 실제로는 전혀 다른 두 학생이 같은 점수를 받을 수 있다. 한 학생은 개념을 이해했고, 다른 학생은 찍어서 맞혔다. AI도 비슷하다.

예를 들어 고객지원 챗봇의 정답률이 85퍼센트라고 해보자. 숫자만 보면 괜찮아 보인다. 하지만 속을 열어 보면 완전히 다른 시스템일 수 있다. 하나는 최신 정책을 잘 찾아와서 짧고 정확하게 답한다. 다른 하나는 오래된 문서를 자주 섞고, 우연히 맞는 답을 내며, 같은 질문에도 들쭉날쭉한 답을 낸다. 둘 다 85퍼센트일 수 있다.

바로 여기서 평가의 해상도가 중요해진다. 자동 평가는 사람 평가를 완전히 대체하기보다 보완하는 방식으로 쓰이며, 참조 정답과 비교하는 방법뿐 아니라 정답 없이 컨텍스트를 기준으로 보는 방법도 함께 사용된다.²³ 다시 말해, 우리는 정답이 맞았는지뿐 아니라 그 답이 질문에 맞았는지, 근거를 벗어나지 않았는지, 오래된 정보를 섞지 않았는지, 불필요하게 길지는 않았는지까지 따로 봐야 한다.

정답률 하나만 보면 놓치기 쉬운 문제는 대체로 다섯 가지다.

• 질문과 무관한 정보를 길게 답하는 문제

• 검색된 문서에 없는 내용을 그럴듯하게 보태는 문제

• 최신 정책 대신 예전 규정을 가져오는 문제

• 필요한 것보다 훨씬 많은 맥락을 넣어 답을 흐리는 문제

• 같은 입력인데 실행할 때마다 결과 품질이 크게 흔들리는 문제

이 다섯 문제는 모두 컨텍스트 문제인데, 정답률 하나로는 서로 구분되지 않는다.

무엇을 평가해야 하는가

컨텍스트 품질 평가는 최종 답변만 채점하는 일이 아니다. 실제로는 세 층을 함께 본다.

첫째는 입력 층이다. 어떤 지시문이 들어갔는지, 어떤 문서가 검색되었는지, 어떤 기억이 붙었는지, 어떤 도구 결과가 주어졌는지를 본다.

둘째는 출력 층이다. 답이 질문에 맞는지, 근거를 지켰는지, 형식 요구를 만족하는지, 불필요하게 장황하지는 않은지를 본다.

셋째는 실행 층이다. 같은 조건에서 비슷한 결과가 반복되는지, 버전 변경 뒤 성능이 갑자기 떨어지지 않았는지, 운영 중 품질이 서서히 나빠지지 않는지를 본다.

이 세 층을 따로 보면 원인이 보인다. 검색은 잘됐는데 답이 헛나가면 생성 단계 문제다. 검색 자체가 엉뚱하면 선택 단계 문제다. 어떤 날은 잘되고 어떤 날은 망가지면 재현성 문제다. 즉, 평가는 채점이 아니라 진단이다.

컨텍스트 품질의 다섯 기준

이 책에서는 컨텍스트 품질을 다음 다섯 기준으로 본다.

이 다섯 기준은 서로 연결되어 있지만, 일부러 나눠서 봐야 한다. 관련성이 높아도 충실성이 낮을 수 있다. 질문에는 딱 맞지만 근거 밖 이야기를 보태는 경우다. 반대로 충실성은 높은데 관련성이 낮을 수도 있다. 문서는 잘 요약했지만 사용자의 질문에는 답하지 못한 경우다.

최신성과 간결성도 자주 오해된다. 정보가 많다고 항상 좋은 것이 아니다. 오래된 정보가 최신 정보와 함께 들어오면 충돌이 생기고, 너무 긴 컨텍스트는 모델을 산만하게 만든다. 컨텍스트 엔지니어링에서는 더 많이 넣는 것보다 더 정확히 고르는 것이 중요하다.

재현성은 특히 운영 단계에서 빛난다. 데모에서는 멋졌는데 배포 후 품질이 흔들리는 시스템은 실무에서 믿기 어렵다. 그래서 평가 결과는 한 번의 감상이 아니라, 반복 가능한 숫자와 기록으로 남아야 한다.

평가셋은 어떻게 만들어야 하는가

좋은 평가는 좋은 질문지에서 시작한다. 여기서 질문지는 단순한 프롬프트 목록이 아니라, 실제 사용 상황을 닮은 테스트셋이다.

작게 시작해도 괜찮다. 처음부터 천 개를 만들 필요는 없다. 오히려 자주 틀리는 장면을 잘 담은 30개에서 100개 정도의 대표 케이스가 더 유용하다. 중요한 것은 다양성이다. 쉬운 질문만 모으면 점수는 높게 나오지만 시스템은 현장에서 무너진다.

평가셋에는 최소한 다음과 같은 장면이 들어가야 한다.

• 최신 문서가 없으면 틀리는 질문

• 여러 문서를 함께 읽어야 답할 수 있는 질문

• 검색 없이 내부 기억이나 사용자 선호가 필요한 요청

• 도구 호출이 정확해야 끝나는 작업

• 답변 거절이나 사람 이관이 정답인 상황

각 테스트 케이스에는 입력만 넣지 말고, 무엇이 좋은 결과인지도 적어 두는 편이 좋다. 정답 문장이 하나뿐일 필요는 없다. 대신 기대 행동을 정의하면 된다. 예를 들면 최신 정책을 우선 인용할 것, 출처 없는 추정은 하지 말 것, 5문장 안에 요약할 것, 민감 작업은 승인 요청 후 진행할 것 같은 식이다.

이렇게 만들어진 평가셋은 두 가지 역할을 한다. 하나는 개선 전후를 비교하는 기준선이다. 다른 하나는 회귀를 잡는 안전장치다. 즉, 오늘 고친 것이 내일 다른 곳을 망가뜨리지 않는지 확인해 준다.

어떤 방식으로 점수를 매길 것인가

평가 방법은 하나로 끝나지 않는다. 보통은 규칙 기반 평가, 참조 기반 평가, LLM judge, 사람 검토를 섞어서 쓴다.²³⁴

규칙 기반 평가는 가장 먼저 둔다

규칙 기반 평가는 빠르고 싸고 흔들림이 적다. 형식이 맞는지, JSON이 유효한지, 금지어가 있는지, 지정한 길이를 넘겼는지, 특정 필드가 비어 있는지를 검사하는 데 아주 좋다. 이런 평가는 말 그대로 기계적으로 확인할 수 있으므로, 가장 먼저 통과해야 하는 문지기로 두면 된다.

특히 간결성과 재현성 평가의 바닥을 잡아 주는 데 유용하다. 예를 들어 답변 길이 상한, 필수 인용 수, 도구 호출 여부, 승인 절차 누락 여부 같은 것은 규칙으로 잡아낼 수 있다.

참조 기반 평가는 정답이 있을 때 강하다

질문마다 기대 답이 비교적 분명하다면 참조 기반 평가를 쓸 수 있다. exact match, 문자열 거리, 의미 유사도 같은 방식이 여기에 속한다.² 다만 여기에는 함정이 있다. 말만 다르고 뜻은 같은 답을 과하게 감점할 수 있고, 반대로 뜻은 미묘하게 틀렸는데 표현이 비슷하다고 점수를 후하게 줄 수도 있다.

그래서 참조 기반 평가는 특히 구조화된 출력이나 짧은 사실 답변에서 강하고, 열린 서술형 작업에서는 단독 기준으로 쓰기 어렵다.

LLM judge는 애매한 품질을 수치화할 때 쓴다

관련성, 충실성, 도움됨, 문맥 일치처럼 사람 눈으로 판단하던 항목은 LLM judge가 잘 다룬다. 다만 막연하게 이 답이 좋은가를 묻기보다, 판정 기준을 구체적으로 쪼개야 한다. 예를 들어 다음처럼 묻는 편이 훨씬 낫다.

이 답은 질문에 직접 답하는가.

이 답의 각 주장은 제공된 문서 또는 도구 결과로 지지되는가.

이 답은 오래된 정책보다 최신 문서를 우선했는가.

이 답은 불필요한 배경설명 없이 핵심을 먼저 제시하는가.

Arize는 이런 평가에서 연속 점수보다 범주형 판정이 더 안정적이고 해석하기 쉬운 경우가 많다고 설명한다.⁴ 현장에서는 0.83 같은 숫자 하나보다 통과, 부분 통과, 실패 같은 구분이 개선으로 연결되기 쉬운 경우가 많다.

사람 검토는 마지막 안전핀이다

자동 평가는 필수지만, 사람 검토를 버리면 안 된다. Databricks가 강조하듯, 인간은 미묘한 오류, 맥락적 어색함, 윤리적 문제, 실제 업무 적합성을 여전히 더 잘 잡아낸다.³ 특히 고위험 도메인에서는 표본 검토가 꼭 필요하다.

좋은 방식은 자동 평가로 넓게 걸러내고, 사람 검토로 깊게 보는 것이다. 자동 평가는 속도를, 사람 평가는 현실감을 책임진다.

다섯 기준을 실제로 어떻게 측정할까

이제 기준을 숫자로 바꿔 보자.

관련성

관련성은 두 군데에서 본다. 검색된 컨텍스트가 질문과 관련 있는가, 그리고 최종 답변이 질문에 직접 답하는가다. 전자는 검색 품질이고, 후자는 생성 품질이다.

RAG 시스템이라면 retrieval precision, recall, MRR, nDCG 같은 전통적 검색 지표를 함께 볼 수 있다. 여기에 최근에는 answer relevancy, context relevancy 같은 LLM judge 기반 항목을 더한다.⁴⁶ 중요한 것은 문서가 비슷해 보이는가가 아니라, 이 질문을 푸는 데 필요한가다.

충실성

충실성은 답변이 근거를 벗어나지 않는가를 본다. RAGAS가 널리 알려지게 만든 것도 바로 이 축이다. faithfulness는 답변의 주장들을 쪼갠 뒤, 각각이 검색된 컨텍스트로 지지되는지 판단한다.⁶ 이 점수가 낮다면 모델이 똑똑하지 않은 것이 아니라, 근거를 무시하거나 근거가 부족하거나 지시문이 느슨한 경우가 많다.

실무적으로는 다음 질문을 던지면 된다. 답변 속 각 문장에 근거를 붙일 수 있는가. 붙일 수 없다면 충실성 경고다.

최신성

최신성은 생각보다 자주 빠지는 항목이다. 모델은 최신과 오래됨을 자동으로 구분해 주지 않는다. 컨텍스트에 둘 다 들어오면 둘 다 재료로 쓴다. 그래서 최신성은 별도 규칙과 별도 평가가 필요하다.

방법은 어렵지 않다. 테스트셋 안에 최신 문서가 결정적으로 중요한 질문을 넣고, 오래된 문서를 일부러 섞어 본다. 그 다음 최신 문서를 우선 인용했는지, 답변 내용이 최신 정책과 일치하는지 확인하면 된다. 운영에서는 검색된 문서의 날짜 분포, 오래된 문서 인용률, 정책 버전 충돌률을 함께 보는 것이 좋다.

간결성

간결성은 단순히 짧은 답을 뜻하지 않는다. 필요한 정보 대비 불필요한 정보가 적은 상태를 뜻한다. 너무 긴 컨텍스트는 모델의 주의를 분산시키고, 너무 긴 답변은 사용자의 판단 속도를 늦춘다.

평가는 두 군데에서 한다. 입력 쪽에서는 top-k가 과한지, 대화 히스토리가 너무 길지 않은지, 요약이 제 역할을 하는지를 본다. 출력 쪽에서는 핵심 답이 앞부분에 나오는지, 군더더기 설명이 과한지, 길이 제한을 지키는지를 본다.

간결성은 보통 관련성과 함께 움직인다. 관련성이 낮으면 대개 불필요한 문장이 늘어난다. 그래서 장황함은 문체 문제가 아니라 선택 실패의 신호일 때가 많다.

재현성

재현성은 같은 질문을 같은 조건에서 여러 번 실행했을 때 점수가 얼마나 흔들리는지 본다. 평가셋 전체 평균도 중요하지만, 편차도 중요하다. 어떤 시스템은 평균은 높아도 최악의 경우가 자주 나온다. 실무에서는 이런 시스템이 더 위험하다.

Evidently가 설명하듯, LLM 평가는 입력 단위 점수와 데이터셋 단위 집계를 구분해서 봐야 한다.⁵ 평균만 보면 몇 개의 심각한 실패가 묻힌다. 그래서 평균 점수와 함께 실패 비율, 최저 점수, 기준 미달 케이스 수를 같이 보는 편이 좋다.

또한 버전 변경 전후 비교도 중요하다. Braintrust가 강조하듯, 좋은 평가는 개선 실험, 회귀 탐지, A/B 테스트, 운영 모니터링까지 이어져야 한다.⁷ 한마디로 재현성은 실험실 점수가 아니라 배포 가능한 안정성을 뜻한다.

RAG와 에이전트는 따로, 함께 평가해야 한다

컨텍스트 엔지니어링에서 특히 많이 쓰는 두 구조가 RAG와 에이전트다. 둘 다 평가할 때 중요한 원칙은 같다. 전체 점수 하나만 보지 말고, 부품별로 나눠 보라는 것이다.

RAG에서는 검색과 생성을 분리해서 봐야 한다. 검색은 관련 문서를 제대로 가져왔는가가 핵심이고, 생성은 그 문서를 바탕으로 답했는가가 핵심이다. RAGAS의 answer relevancy, faithfulness, context precision, context recall이 유용한 이유도 여기에 있다.⁶

에이전트에서는 여기에 한 층이 더 붙는다. 도구를 올바르게 골랐는가, 도구 입력을 제대로 만들었는가, 도구 결과를 잘 해석했는가, 불확실할 때 멈췄는가를 따로 봐야 한다. 즉, 에이전트의 평가는 답변 평가이면서 동시에 워크플로 평가다.

실무에서 자주 쓰는 간단한 진단법은 이렇다.

• 관련성 낮음, 충실성 높음: 질문과 다른 문서를 충실하게 요약하고 있을 가능성

• 관련성 높음, 충실성 낮음: 질문에는 맞지만 근거 밖 추정을 하고 있을 가능성

• 최신성 낮음, 충실성 높음: 오래된 문서를 성실하게 따르고 있을 가능성

• 간결성 낮음, 관련성 낮음: 너무 많은 컨텍스트가 들어와 선택 실패가 난 가능성

• 재현성 낮음: 프롬프트, judge, 검색 순서, 도구 응답이 불안정할 가능성

이렇게 보면 점수는 비난이 아니라 힌트가 된다.

실패 케이스를 개선 루프로 연결하는 법

평가의 목적은 보고서가 아니라 개선이다. 그래서 점수표는 결국 다음 행동으로 이어져야 한다.

1. 먼저 기준선을 만든다. 현재 버전으로 평가셋을 돌려 다섯 기준의 평균과 실패 케이스를 기록한다.

2. 평균보다 실패 사례를 먼저 본다. 어디서 많이 틀렸는지, 어떤 유형에서만 틀렸는지 분류한다.

3. 원인을 한 단계 앞에서 찾는다. 답이 틀렸다면 검색, 메모리, 지시문, 도구, 요약 중 무엇이 문제인지 역추적한다.

4. 한 번에 한 변수만 바꾼다. 프롬프트와 검색기와 요약기를 한꺼번에 바꾸면 무엇이 효과였는지 모르게 된다.

5. 다시 평가해 회귀 여부를 확인한다. 좋아진 항목과 나빠진 항목을 함께 본다.

6. 통과 기준을 정하고 배포에 연결한다. 예를 들어 충실성 0.85 미만이면 배포 보류, 최신성 실패율 5퍼센트 초과면 재색인 같은 식이다.

이 흐름이 자리 잡으면 팀의 대화가 달라진다. 느낌상 좋아진 것 같다가 아니라, 관련성은 올랐지만 최신성이 떨어졌다는 식으로 말하게 된다. 그러면 설계도 훨씬 빨리 성숙해진다.

운영 단계에서는 무엇을 계속 봐야 하는가

오프라인 평가만으로 끝내면 절반만 한 것이다. 실제 사용 환경에서는 질문 유형이 변하고, 문서가 갱신되고, 사용자 행동도 달라진다. 그래서 운영에서는 생산 로그를 표본 추출해 계속 평가해야 한다.

운영 모니터링에서 특히 유용한 지표는 다음과 같다. 관련 없는 검색 청크 비율, 근거 없는 주장 비율, 오래된 문서 인용 비율, 평균 답변 길이와 상위 95퍼센타일 길이, 동일 질문군에서의 점수 편차, 버전별 실패 유형 분포다. 이런 지표는 시간이 지나며 시스템이 어디서 썩어 가는지 보여준다.

컨텍스트 품질은 종종 조용히 나빠진다. 문서가 늘어나며 검색 노이즈가 커지고, 메모리가 쌓이며 오래된 선호가 남고, 요약이 누적되며 중요한 정보가 빠진다. 그래서 운영 평가는 보험이 아니라 정비다.

평가에서 흔히 빠지는 함정

마지막으로, 많은 팀이 반복해서 빠지는 함정을 짚고 넘어가자.

첫째, 점수 최적화가 목적이 되는 경우다. 사용자가 원하는 것은 높은 BLEU가 아니라 문제 해결이다. 점수는 방향판이지 종착지가 아니다.

둘째, 쉬운 테스트셋에 과적합하는 경우다. 자주 묻는 질문 몇 개만 잘 맞히는 시스템은 현장에서 금방 무너진다.

셋째, judge 프롬프트가 모호한 경우다. 좋은지 나쁜지 알아서 판단하라고 하면 평가도 흔들린다. 판정 기준은 구체적이어야 한다.

넷째, 평균 점수만 보는 경우다. 평균은 예쁘지만, 사용자는 최악의 한 번을 기억한다.

다섯째, 답변 품질과 컨텍스트 품질을 섞어 보는 경우다. 답이 틀렸다고 무조건 모델 탓을 하면, 가장 큰 개선 지점을 놓친다.

평가는 모델을 심판하는 일이 아니라 설계를 성숙하게 만드는 일

컨텍스트 엔지니어링의 진짜 어려움은 멋진 지시문을 쓰는 데 있지 않다. 어떤 정보를 넣고, 무엇을 빼고, 어떤 순서로 보여 주고, 언제 기억하게 하고, 언제 잊게 할지를 설계하는 데 있다. 그렇다면 평가도 그 설계를 비춰 보는 거울이어야 한다.

정답률 하나만 볼 때는 AI가 잘하느냐 못하느냐만 보인다. 하지만 관련성, 충실성, 최신성, 간결성, 재현성을 함께 보기 시작하면, 비로소 어디를 고쳐야 하는지가 보인다. 그리고 그 순간부터 우리는 프롬프트를 고치는 사람이 아니라, AI가 제대로 일하도록 환경을 설계하는 사람이 된다.

참고

¹Context engineering in agents - Docs by LangChain

²A list of metrics for evaluating LLM-generated content

³Best Practices and Methods for LLM Evaluation

⁵LLM evaluation metrics and methods, explained simply

⁶RAGAS 완전 가이드: RAG 시스템을 어떻게 정량적으로 평가하는가

⁷LLM evaluation metrics: Full guide to LLM evals and key metrics