근거성 평가와 citation 설계

7장에서 우리는 검색 결과를 모델에게 잘 읽히는 근거 패키지로 바꾸는 방법을 보았다. 하지만 여기서 한 가지 더 남는다. 근거를 넣었다고 해서 모델이 그 근거를 정말 사용했다는 보장은 없다는 점이다. 문서를 프롬프트에 붙여 넣는 일과, 답변이 그 문서에 실제로 닻을 내리고 있는 일은 다르다.

그래서 이 장의 주제는 두 가지다. 첫째, 답변이 주어진 문서에 근거를 두고 있는지를 어떻게 평가할 것인가. 둘째, 답변 옆에 붙은 citation이 실제로 그 문장을 뒷받침하는지를 어떻게 설계하고 점검할 것인가. 이 두 가지가 빠지면 RAG는 그럴듯한 검색형 챗봇에 머물고, 이 두 가지가 갖춰지면 비로소 감사 가능하고 운영 가능한 내부 지식 QA로 올라선다.

근거성은 "맞는 말"보다 더 엄격하다

근거성, 즉 groundedness는 답변의 주장들이 제공된 문맥으로 실제 검증 가능한지를 보는 개념이다. 여기서 중요한 점은 답이 사실상 맞더라도, 주어진 문서에서 확인할 수 없으면 근거성 관점에서는 실패라는 것이다.¹ 이 차이를 이해하지 못하면 RAG 평가가 자꾸 흐려진다.

예를 들어 회사 정책 문서를 바탕으로 답해야 하는 내부 도우미가 있다고 해 보자. 사용자가 "육아휴직 신청은 몇 주 전에 해야 하나요?"라고 물었고, 모델이 일반적인 노동 상식을 바탕으로 그럴듯한 답을 했다. 그 답이 세상 일반 기준으로 맞을 수는 있다. 하지만 우리 시스템의 임무는 세상 일반론이 아니라 우리 회사 문서에 적힌 규정을 말하는 것이다. 문서에 없는 말을 했다면, 그 답은 도움이 될 수는 있어도 근거 기반 답변은 아니다.

이 때문에 실무에서는 정확성, 관련성, 완전성을 한 덩어리로 보지 말고 나눠서 봐야 한다.

특히 근거성과 관련성은 자주 헷갈린다. 관련성은 "질문에 잘 답했는가"를 보고, 근거성은 "그 답이 문서에서 확인되는가"를 본다. 둘은 비슷해 보여도 다른 축이다.² 또 근거성은 보통 정밀도 쪽에 가깝다. 문서 밖 내용을 섞지 않았는지를 본다. 반대로 완전성은 재현율 쪽에 가깝다. 문서 안에 있어야 할 중요한 내용을 놓치지 않았는지를 본다.³

이 구분이 중요한 이유는 아주 단순하다. 같은 답변도 평가 항목에 따라 전혀 다른 판정을 받을 수 있기 때문이다. 내부 지식 QA는 "맞아 보이는가"가 아니라 "문서로 확인 가능한가"를 먼저 통과해야 한다.

답변 평가는 문장 덩어리가 아니라 주장 단위로 해야 한다

근거성을 평가할 때 가장 흔한 실수는 답변 전체를 한 번에 보고 "대충 근거 있어 보인다"고 판단하는 것이다. 이 방식은 짧은 답에서는 통할 수 있어도, 실제 서비스 답변에는 금방 무너진다. 답변 하나 안에는 보통 여러 종류의 문장이 섞여 있기 때문이다.

예를 들어 이런 답을 생각해 보자.

해외 체류 중 근무는 사전 승인 시 가능하며, 최대 30일까지 허용됩니다. 다만 고객 데이터 접근 권한이 있는 직무는 제외됩니다. 신청은 팀장 승인 후 보안팀 검토를 거칩니다.

이 답은 한 덩어리처럼 보이지만, 실제로는 적어도 세 개의 주장으로 나뉜다.

• 사전 승인 시 가능하다.

• 최대 30일까지 허용된다.

• 고객 데이터 접근 직무는 제외된다.

• 팀장 승인과 보안팀 검토를 거친다.

이 중 앞의 세 문장은 문서에 있을 수 있지만, 마지막 절차 문장은 문서에 없을 수도 있다. 그렇다면 이 답변은 "절반은 grounded, 절반은 ungrounded"한 답변이다. 운영에서는 이런 식의 반쪽짜리 실패가 훨씬 많다.

그래서 근거성 평가는 가능하면 다음 순서로 쪼개는 편이 좋다.

• 답변에서 검증 가능한 주장을 추출한다.

• 각 주장마다 지지 근거가 있는지 확인한다.

• 근거가 있다면 어느 citation이 그 주장을 지지하는지 연결한다.

• 근거가 없다면 추측, 과잉 일반화, 문서 외 지식, 충돌 무시 중 어떤 실패인지 분류한다.

이렇게 보면 디버깅이 쉬워진다. "답변이 틀렸다"가 아니라 "두 번째 주장에 citation이 없고, 네 번째 문장은 문서 외 절차를 끼워 넣었다"처럼 구체적으로 고칠 수 있기 때문이다.

citation은 예쁜 꼬리표가 아니라 주소 체계다

많은 팀이 출처 표시를 뒤늦게 붙인다. 답변 마지막에 문서 제목 두세 개를 달아 두고 "출처 있음"이라고 생각하는 식이다. 하지만 이런 방식은 신뢰를 주는 장식은 될 수 있어도, 검증 가능한 citation은 아니다.

좋은 citation은 적어도 두 가지 질문에 답할 수 있어야 한다.

첫째, 이 문장이 어느 근거에서 왔는가? 둘째, 그 근거는 정말 이 문장을 충분히 지지하는가?

이 기준으로 보면 citation 설계는 단순히 링크를 보여 주는 UI 문제가 아니다. 답변 문장과 근거 조각을 연결하는 주소 체계 문제다. 그래서 내부 지식 QA에서는 문서 제목만 보여 주는 수준을 넘어, 최소한 chunk나 문단 단위 식별자를 함께 갖는 쪽이 훨씬 유리하다.

예를 들어 다음 두 형식을 비교해 보자.

나쁜 예:
해외 체류 중 근무는 승인 시 가능합니다. [원격근무 운영정책]

좋은 예:
해외 체류 중 근무는 사전 승인 시 최대 30일까지 허용됩니다. [HR-REMOTE-2026#4.2]
보안 제한 직무는 적용 대상에서 제외됩니다. [HR-REMOTE-2026#4.2]

첫 번째는 문서가 있다는 사실만 보여 준다. 두 번째는 어떤 조항을 봤는지까지 드러낸다. 운영자 입장에서는 두 번째가 훨씬 좋다. 잘못된 답이 나왔을 때 바로 해당 chunk를 열어 확인할 수 있기 때문이다.

citation 정확도는 네 가지로 나눠서 봐야 한다

citation을 평가할 때도 "출처가 붙었나?"만 보면 부족하다. 실무에서는 적어도 네 가지를 따로 봐야 한다.

첫째는 존재 여부다. 핵심 주장마다 citation이 있는가. 어떤 답변은 문서 끝에 citation 한 개만 붙여 놓고, 실제 핵심 주장들은 모두 무인 상태로 지나간다. 이 경우 사용자는 어느 문장을 믿어야 할지 알 수 없다.

둘째는 지지 충분성이다. citation이 달린 근거가 그 문장을 정말 뒷받침하는가. 예를 들어 "최대 30일"이라는 주장을 했는데 citation이 단지 "해외 체류 중 근무"를 설명하는 일반 문단만 가리킨다면, citation은 있어도 정확한 citation은 아니다.

셋째는 정밀도다. 너무 넓은 근거를 가리키고 있지 않은가. 문서 전체나 섹션 전체를 달아 두면 얼핏 안전해 보이지만, 실제 검증은 오히려 어려워진다. 특히 정책·법무·재무 영역은 한 줄 차이가 중요하므로 가능한 한 작은 근거 단위를 가리키는 편이 낫다.

넷째는 과잉 citation이다. 관련 없는 출처를 잔뜩 붙여 신뢰감을 부풀리고 있지 않은가. 출처가 많다고 좋은 것이 아니다. 핵심 주장에 필요한 근거만 정확히 붙는 쪽이 더 낫다.

짧게 말하면 citation은 많을수록 좋은 것이 아니라, 필요한 주장에 정확하고 충분하게 붙을수록 좋다.

답변 형식이 citation 품질을 결정한다

citation 품질은 나중에 후처리로만 해결되지 않는다. 답변 형식 자체가 citation을 강제하도록 설계되어야 한다. 가장 안전한 방식은 최종 답변과 근거 목록을 분리하되, 핵심 주장 옆에도 인라인 citation을 남기는 것이다.

예를 들면 이런 구조다.

{
  "answer": "해외 체류 중 근무는 사전 승인 시 최대 30일까지 허용됩니다 [HR-REMOTE-2026#4.2]. 다만 고객 데이터 접근 권한이 필요한 직무는 제외됩니다 [HR-REMOTE-2026#4.2].",
  "citations": [
    {
      "claim": "사전 승인 시 최대 30일까지 허용",
      "source_id": "HR-REMOTE-2026",
      "chunk_id": "4.2",
      "support_span": "사전 승인 시 최대 30일까지 허용한다"
    },
    {
      "claim": "고객 데이터 접근 직무 제외",
      "source_id": "HR-REMOTE-2026",
      "chunk_id": "4.2",
      "support_span": "고객 데이터 접근 권한이 필요한 직무는 제외한다"
    }
  ],
  "insufficient_context": false
}

이 구조의 장점은 분명하다. 사람은 읽기 쉬운 자연어 답을 보고, 시스템은 claim-to-evidence 연결을 별도 필드로 검사할 수 있다. 특히 support_span이 있으면 citation 정확도 점검이 훨씬 쉬워진다. "정말 그 줄이 그 문장을 지지하는가?"를 자동 검사나 사람 검토 모두에서 다루기 좋아진다.

문서 근거 없음 상황은 따로 설계해야 한다

내부 지식 QA에서 가장 위험한 실패 중 하나는 없는 답을 있는 것처럼 말하는 것이다. 근거가 부족한데도 말끔한 문장으로 메워 버리면, 사용자는 오히려 더 쉽게 속는다. 그래서 "문서 근거 없음"은 예외 상황이 아니라, 평가셋과 출력 구조 안에 독립적으로 들어가야 한다.

긴 문맥 QA에서는 두 가지 오류를 특히 조심해야 한다. 문서에 없는 답을 만들어 내는 false positive, 그리고 문서에 있는데도 없다고 말하는 false negative다.⁴ 둘 다 문제지만, 내부 지식 QA에서는 첫 번째가 대개 더 치명적이다. 정책이 없는 일을 있다고 답해 버리면 실제 업무가 잘못 흘러가기 때문이다.

그래서 시스템은 단순히 "모르면 모른다고 말하라"는 태도 지시만 받아서는 부족하다. 구조적으로도 다음을 갖춰야 한다.

• 답변 가능 여부를 판정하는 필드

• 근거 부족 시 사용할 표준 응답 문구

• 추가 확인이 필요한 경우의 후속 질문 규칙

• 검색 실패와 진짜 문서 부재를 구분하는 로깅

예를 들어 이런 식이다.

answer_status: answered | insufficient_context | conflicting_sources
answer: 사용자에게 보여 줄 답변
missing_information: 어떤 정보가 문서에 없는지 설명
suggested_next_step: 확인해야 할 문서나 담당 부서

이 구조가 있으면 "답을 못했다"가 실패가 아니라, 시스템이 안전하게 멈췄다는 성공이 될 수 있다.

평가셋에도 반드시 no-info 문제를 넣어야 한다

평가셋이 전부 답할 수 있는 질문만으로 구성되어 있으면, 모델은 무조건 뭔가 말하는 방향으로 학습되고 튜닝된다. 그러면 운영에 들어가서 문서에 없는 질문을 만났을 때도 자연스럽게 지어내기 시작한다. 따라서 내부 지식 QA 평가셋에는 반드시 답이 없는 질문, 즉 no-info 샘플이 들어가야 한다.⁴

좋은 평가셋은 보통 다음 유형을 섞는다.

• 문서에 답이 명확히 있는 단일 사실 질문

• 여러 조항을 함께 읽어야 하는 다중 근거 질문

• 문서 간 충돌이 있는 질문

• 문서에 답이 없는 no-info 질문

• 오래된 문서와 최신 문서가 함께 걸리는 질문

• 해석 여지가 있는 모호한 질문

특히 모호한 질문은 중요하다. 최근 연구에서도 애매한 QA 상황에서 모델들이 적어도 하나의 맞는 답은 내놓을 수 있어도, 여러 가능한 답을 함께 다루고 정확한 citation을 붙이는 데는 크게 약한 모습을 보였다.⁵ 즉 citation 문제는 단순한 형식 문제가 아니라, 모호성과 충돌을 다루는 능력과 연결되어 있다.

그래서 평가셋에도 "정답 하나"만 두기보다, 가능한 경우에는 다음 중 무엇이 허용되는지 함께 적는 편이 좋다.

• 허용 가능한 답변 범위

• 필수로 언급해야 하는 조건과 예외

• 허용 가능한 citation 집합

• no-answer가 정답인 경우의 기준 문구

• 충돌 시 우선해야 할 문서 규칙

이렇게 해야 LLM 평가기나 사람 평가자 모두 같은 기준으로 본다.

groundedness 평가는 retrieval 평가와 섞지 말아야 한다

실무에서 자주 생기는 혼란 하나가 있다. 검색이 나빠서 틀렸는지, 검색은 맞았는데 생성이 문서를 안 따라가서 틀렸는지를 한 항목으로 뭉뚱그리는 것이다. 그러면 무엇을 고쳐야 할지 알 수 없어진다.

retrieval 평가는 "필요한 문서나 문단을 가져왔는가"를 본다. groundedness 평가는 "가져온 문서를 바탕으로 답했는가"를 본다. 둘은 연결되어 있지만 다른 층위다. Microsoft의 RAG 평가 설명도 retrieval, groundedness, relevance, completeness를 별도 평가기로 분리해 두는 이유가 바로 여기에 있다.³

예를 들어 문서에 정답이 있었는데 답변이 엉뚱했다면, retrieval은 통과고 groundedness는 실패다. 반대로 검색이 잘못되어 엉뚱한 문단만 들어왔다면, groundedness는 높게 나올 수도 있다. 모델이 주어진 문맥만 충실히 따라 틀린 답을 한 경우다. 이때는 retrieval이 실패다.

이 구분은 매우 중요하다. 그래야 "더 좋은 검색이 필요한가, 더 강한 근거 사용 규칙이 필요한가, 아니면 citation 출력 형식이 허술한가"를 나눠서 개선할 수 있다.

LLM-as-a-judge는 유용하지만 판결문이 아니라 판정기다

근거성과 citation 정확도는 사람이 일일이 보면 가장 확실하지만, 운영 규모가 커지면 전수 검토가 어렵다. 그래서 현실적으로는 LLM-as-a-judge가 매우 유용하다. 특히 정답 표현이 다양하고, 단순 문자열 일치로는 평가하기 어려운 QA에서 더 그렇다.

최근 연구에서는 추출형 QA에서도 LLM-as-a-judge가 전통적인 EM, F1보다 인간 판단과 훨씬 높은 상관을 보였고, 사람 판단과의 상관이 0.85 수준까지 올라갔다고 보고한다.⁶ 이는 "평가도 의미 기반으로 봐야 한다"는 흐름을 잘 보여 준다.

하지만 여기서 중요한 태도가 있다. LLM judge는 심판이 아니라 판정기다. 즉 자동화된 1차 필터로는 훌륭하지만, 민감한 케이스의 최종 법원처럼 다뤄서는 안 된다. 좋은 운영 방식은 대체로 이렇다.

• 점수만 받지 말고 근거 이유를 함께 받는다.

• 자유 서술보다 구조화된 JSON 출력을 받는다.

• 온도는 낮게 두고, 평가 프롬프트는 짧고 엄격하게 유지한다.

• 경계 점수 구간은 사람 검토로 올린다.

• 정기적으로 사람 평가와 judge 결과를 맞춰 본다.

특히 citation 평가는 judge에게 "이 출처가 대충 관련 있나?"를 묻는 것보다, "이 claim을 이 support span이 충분히 지지하는가"를 묻는 쪽이 훨씬 안정적이다. 질문을 작게 쪼갤수록 판정도 또렷해진다.

근거성 그레이더는 이렇게 쪼개면 실용적이다

실무용 그레이더는 한 번에 모든 것을 판단하려 하지 않는 편이 좋다. 다음처럼 여러 개의 작은 판정기로 나누면 훨씬 운영하기 쉽다.

1. Claim Extraction

답변에서 검증 가능한 주장만 뽑아낸다. 인사말, 완곡 표현, 요약 문구는 버리고 사실 주장만 남긴다.

2. Claim Support Judge

각 claim이 제공된 context로 지지되는지 판정한다. 결과는 supported, partially_supported, unsupported, conflicting 정도로 두면 실무적으로 충분하다.

3. Citation Presence Checker

핵심 claim마다 citation이 붙어 있는지 본다. citation 없는 핵심 주장은 일단 경고다.

4. Citation Sufficiency Judge

붙은 citation의 support span이 그 claim을 충분히 뒷받침하는지 판정한다.

5. No-Info Policy Judge

문서 근거가 없을 때 답변이 적절히 멈췄는지, 혹은 불필요하게 지어냈는지 본다.

이렇게 쪼개면 대시보드도 좋아진다. 단순 평균 점수 하나보다, "unsupported claim 비율", "citation 없는 핵심 claim 비율", "no-info 질문에서 답변을 지어낸 비율" 같은 지표가 훨씬 유용하다.

내부 지식 QA에서는 citation 단위를 너무 크게 잡지 마라

문서 제목 단위 citation은 구현이 쉽지만, 내부 지식 QA에서는 금방 한계가 온다. 특히 정책 문서, 규정집, 매뉴얼처럼 예외 조항이 촘촘한 문서는 더 그렇다. 실무에서는 보통 세 단계 중 하나를 고르게 된다.

• 문서 단위: 구현은 쉽지만 검증이 거칠다.

• chunk 단위: 가장 실용적인 기본값이다.

• span 단위: 가장 정확하지만 구현 부담이 크다.

대부분의 팀에게는 chunk 단위가 좋은 출발점이다. 문단 또는 의미 단위 chunk에 고유 ID를 붙이고, 가능하면 원문 일부를 support span으로 같이 저장하면 된다. 그러면 검색, 답변, 평가, 감사 로그가 같은 주소 체계를 공유하게 된다.

이 일관성이 매우 중요하다. 주소 체계가 매번 바뀌면, 모델은 citation을 붙였는데 운영자는 원문을 찾지 못하는 우스운 일이 벌어진다.

충돌 문서와 오래된 문서는 citation 설계에서 따로 보라

citation 설계는 단순히 "어디서 가져왔는가"만 표시하면 끝나지 않는다. 현실 문서에는 충돌과 개정 이력이 있다. 이런 상황에서는 citation이 근거의 출처인 동시에 근거의 우선순위도 드러내야 한다.

예를 들어 다음 같은 메타데이터가 유용하다.

• source_type: policy, faq, guide, memo

• updated_at: 최신성 판단용 날짜

• authority_level: 공식성 수준

• version: 문서 버전

• supersedes: 대체된 문서 ID

이 메타데이터가 있으면 답변도 더 안전해진다. "FAQ에는 14일로 보이지만, 최신 정책 문서에는 30일로 명시되어 있어 정책 문서를 우선했습니다"처럼 설명할 수 있기 때문이다. 이런 답은 단순히 맞는 답보다 한 단계 더 좋다. 왜 그 citation을 믿어야 하는지까지 보여 주기 때문이다.

사람이 마지막으로 봐야 하는 항목은 따로 있다

자동 평가가 아무리 좋아져도 사람 검토가 꼭 필요한 지점은 남는다. 특히 다음 세 가지는 사람 눈을 거치는 편이 좋다.

• 정책 해석이 엇갈릴 수 있는 모호한 질문

• 여러 문서를 합쳐야 하는 고위험 질문

• no-info인지 retrieval 실패인지 구분이 어려운 질문

사람 검토의 역할은 단순히 점수 매기기가 아니다. 평가 기준 자체를 다듬는 일에 더 가깝다. 예를 들어 사람 검토에서 "이 답은 technically grounded지만 사용자에게는 오해를 부른다"는 케이스가 반복되면, 그때는 groundedness만이 아니라 completeness나 answer formatting 기준을 보강해야 한다.

즉 사람 검토는 자동 평가의 대체물이 아니라, 자동 평가기가 무엇을 놓치고 있는지 알려 주는 센서다.

작은 예시로 보는 평가 구조

질문이 다음과 같다고 하자.

계약직도 사내 교육비 지원을 받을 수 있나요?

검색 결과로는 세 개의 chunk가 들어왔다.

• BENEFIT-2026#2.1: 교육비 지원 대상은 정규직이다.

• BENEFIT-2026#2.3: 단기 계약직은 지원 대상에서 제외한다.

• FAQ-2025#edu-4: 계약직도 일부 교육 프로그램은 참여할 수 있다.

좋지 않은 답변은 이럴 수 있다.

계약직도 교육비 지원을 받을 수 있습니다. 일부 프로그램은 제한될 수 있습니다. [FAQ-2025]

이 답은 관련성은 있어 보이지만 groundedness와 citation 모두 불안하다. 최신 공식 문서보다 오래된 FAQ를 우선했고, "일부 프로그램은 제한"이라는 표현은 문서 어디에도 없을 수 있다.

더 좋은 답변은 이렇게 바뀐다.

최신 복지 규정 기준으로 교육비 지원 대상은 정규직이며, 단기 계약직은 제외됩니다 [BENEFIT-2026#2.1][BENEFIT-2026#2.3]. 다만 2025 FAQ에는 계약직의 일부 프로그램 참여 가능성이 언급되지만, 교육비 지원 여부를 뒤집는 근거로 보기는 어렵습니다 [FAQ-2025#edu-4].

이 답이 좋은 이유는 세 가지다. 최신 공식 문서를 우선했고, 충돌을 숨기지 않았고, 핵심 주장마다 citation이 붙어 있다. 바로 이런 구조가 감사 가능성을 만든다.

운영 지표는 평균 점수보다 실패 비율이 더 중요하다

마지막으로 운영 관점에서 기억할 점이 있다. 근거성과 citation은 평균 4.3점 같은 숫자 하나로만 보면 잘 안 보인다. 오히려 다음 같은 실패 비율 지표가 더 유용하다.

• unsupported claim 비율

• 핵심 claim 무인용 비율

• 잘못된 citation 비율

• no-info 질문에서 허위 답변 비율

• 충돌 문서를 평균 내어 뭉갠 비율

이 지표들은 바로 행동으로 이어진다. unsupported claim 비율이 높으면 근거 사용 규칙을 강화해야 하고, 무인용 비율이 높으면 출력 스키마를 고쳐야 하며, no-info 허위 답변 비율이 높으면 fallback 정책을 손봐야 한다.

운영 가능한 시스템은 대개 "얼마나 좋았나"보다 "어떻게 실패했나"를 더 잘 본다. 근거성 평가는 특히 그렇다.

정리

RAG에서 출처 표시는 장식이 아니다. 답변이 어디서 왔는지, 잘못되었을 때 무엇을 수정해야 하는지, 나중에 누가 어떤 근거로 판단했는지를 추적하게 만드는 핵심 장치다. 그래서 groundedness 평가는 단순한 사실 확인이 아니라 주장과 근거의 대응 관계를 보는 일이어야 하고, citation 설계는 링크 나열이 아니라 주소 체계 설계여야 한다.

좋은 내부 지식 QA는 세 가지를 함께 갖는다. 문서에 없는 말을 하지 않는 근거성, 핵심 주장마다 충분한 citation, 그리고 문서에 답이 없을 때 안전하게 멈추는 no-info 처리다. 이 셋이 함께 작동할 때 비로소 시스템은 "대답을 잘하는 AI"를 넘어, 신뢰할 수 있는 업무 도우미가 된다.

참고

¹azure.ai.evaluation.GroundednessEvaluator class | Microsoft Learn

²RAG Groundedness Evaluation Guide | Openlayer

³Retrieval-Augmented Generation (RAG) Evaluators for Generative AI - Microsoft Foundry | Microsoft Learn

⁴Evaluating Long-Context Question & Answer Systems

⁵[2412.18051] Factuality or Fiction? Benchmarking Modern LLMs on Ambiguous QA with Citations

⁶[2504.11972] LLM-as-a-Judge: Reassessing the Performance of LLMs in Extractive QA