인용 링크가 붙어 있다고 그 근거가 실제 주장을 지지한다는 뜻은 아니다. TREC 2025 RAG 트랙은 출처 귀속뿐 아니라 "출처와 주장의 일치도"를 별도 지표로 평가하고, GaRAGe 벤치마크에서는 최신 LLM도 relevance-aware factuality가 최대 60%에 그쳤다. 2026년 기준 근거 표시 방식을 고를 때는 "표시 여부"가 아니라 "검증 가능 단위"를 기준으로 삼아야 한다.
인용 링크가 붙어 있으면 근거가 맞다는 뜻일까?
아니다. 인용 표시는 형식이고 주장-근거 일치는 내용이다. TREC 2025 RAG 트랙 관련 시스템 평가는 검색 적합성, 답변 완전성, 출처 귀속, 출처-주장 일치도를 분리해서 측정했는데, 이 네 가지는 서로 다른 값을 낼 수 있다는 전제를 깔고 있다. 출처
- 인용 표시 여부와 인용 정확도는 별개 지표다.
- 문장 단위 인용이 문단 단위 인용보다 검증하기 쉽다.
- chunk 분할 방식이 인용 가능한 span을 결정한다.
- 근거 부재 상황에서의 응답(거부 정확도)도 따로 측정해야 한다.
- 수치는 특정 데이터셋·모델·검색 설정에 한정된다.
흔한 함정은 "답변 끝에 출처 링크 하나 붙이면 끝"이라고 여기는 것이다. 문단 전체에 링크 하나를 걸어두면 그 문단 안의 여러 주장 중 일부만 근거가 있어도 전체가 "인용됨"으로 표시된다. GaRAGe 평가에서 관련 근거가 없을 때 답변을 거부하는 true-positive rate가 최대 31%였다는 수치는, 많은 시스템이 "근거 없음"을 인정하기보다 가장 가까운 passage를 끌어와 인용 형식만 맞춘다는 뜻으로 읽을 수 있다. 인용 링크의 존재 자체를 품질 지표로 쓰면 이 실패가 그대로 가려진다.
문장 단위 인용과 문단 단위 인용, 검증 난이도가 다를까?
다르다. TREC 2025 관련 시스템은 하위 질문별 답변을 먼저 생성한 뒤 최종 답변으로 합성하면서 문장 수준으로 출처를 붙이는 계층형 구조를 썼다. 이 방식은 최종 문장 하나하나가 어느 검색 결과에서 나왔는지 역추적할 수 있다. 반면 문단 끝에 출처 하나만 붙이는 후처리 방식은 부분적으로만 지지되는 주장과 무관한 인용을 걸러내기 어렵다. 출처
실무에서 이 차이는 프롬프트 설계로 드러난다. "질문 → 검색 근거 목록 → 근거에서 확인되는 사실만 추출 → 주장별 인용 ID 부여 → 근거가 부족하면 확인 불가" 순서로 생성 단계에서 인용을 강제하면, 인용 ID에 문서명뿐 아니라 페이지·섹션·문단·chunk ID까지 포함해 원문 위치를 재현할 수 있다. 인용을 생성 후에 붙이는 방식은 구현이 쉬워 보이지만, 검증 시점에 "이 문장이 정말 이 근거에서 나왔는가"를 다시 확인할 방법이 없다는 비용을 숨기고 있다.
검색 성능이 좋으면 인용도 자동으로 좋아질까?
아니다. 검색 재현율과 인용 정확도는 함께 측정해야 비로소 의미가 생긴다. TREC 2025 실험에서 하이브리드 검색은 MAP 0.1037, nDCG@30 0.527, Recall@100 0.158을 기록했는데, 이는 상위 100개 안에 정답 근거가 들어 있는 비율이 15.8% 수준이라는 뜻이다. 검색이 근거를 애초에 찾아오지 못하면 아무리 정교한 인용 포맷을 써도 틀린 passage에 정확하게 링크를 거는 결과가 된다. 출처
최근 문헌 리뷰는 dense retrieval 단독보다 BM25 같은 키워드 검색, 구조 인식 검색, 메타데이터 필터를 결합하는 모듈형 RAG로 흐름이 이동했다고 정리한다. 문서 QA에서는 고유명사·조항 번호·제품 코드에는 키워드 검색이 유리하고, 의미가 다른 표현에는 벡터 검색이 유리할 수 있어 단일 방식보다 조합을 실측해야 한다. 임베딩 모델도 이름값으로 고르지 말고 동일한 chunk·top-k·reranker 조건에서 Recall@5, Recall@10, MRR, nDCG@10을 같이 기록해야 비교가 성립한다. 출처
chunk 크기가 인용 가능 span을 얼마나 좌우할까?
상당히 좌우한다. 계약서·규정집처럼 조항 구조가 강한 문서는 제목·조항·항목 단위 분할을, 매뉴얼·FAQ는 질문-답변 또는 절 단위 분할을 비교해야 한다. chunk를 무작정 작게 쪼개면 검색 지표는 좋아 보여도 정작 인용할 문장이 chunk 경계에서 잘려 "근거는 찾았는데 인용은 불완전한" 상태가 된다. GaRAGe는 답변 전체가 아니라 생성된 개별 주장에 대응하는 grounding passage를 사람이 직접 주석한 벤치마크인데, 이런 세밀한 단위 평가가 필요한 이유도 같은 문제 때문이다. 출처
그래서 chunk 전략을 고를 때는 검색 성공률만이 아니라 "인용 가능한 span 포함률"을 별도로 봐야 한다. 둘 다 높은 chunk 크기가 항상 존재하는 건 아니며, 문서 유형별로 다른 분할을 쓰는 편이 현실적인 경우가 많다.
최신 모델을 쓰면 인용 품질 문제가 저절로 해결될까?
아니다. 이게 가장 흔한 오해다. GaRAGe 평가에서 여러 최신 LLM의 relevance-aware factuality는 최대 60%였고, 관련 근거가 없을 때 답변을 거부하는 true-positive rate는 최대 31%에 머물렀다. 모델이 똑똑해졌다는 것과 그 모델이 "제시한 근거가 실제로 답변을 뒷받침하는가"는 별도 검증 항목이라는 뜻이다. 출처
실무에서는 이 둘을 같은 테스트셋에서 동시에 측정해야 차이가 드러난다. 모델을 교체했을 때 "출처가 더 잘 붙는다"는 인상만으로 판단하지 말고, citation support 지표와 근거 부재 시 거부율을 따로 집계해야 한다. 사내 평가셋을 만들 때는 대표 질문뿐 아니라 복수 문서 비교 질문, 답이 없는 질문, 최신·구버전 문서가 충돌하는 질문을 분리해 골드 답변과 정답 근거 구간을 미리 준비해두는 편이 좋다.
문장 단위 인용을 도입하면 비용은 어디서 늘어날까?
주로 생성 단계와 지연시간에서 늘어난다. 하위 질문별 답변을 먼저 만들고 최종 답변으로 합성하는 계층형 인용 구조는 추가 생성 호출을 요구하므로 p95 지연시간과 질의 1,000건당 비용이 함께 올라간다. 품질만 보고 도입하면 이 비용이 운영 단계에서 뒤늦게 드러난다.
2025년 체계적 문헌고찰은 RAG 평가에 품질뿐 아니라 비용·지연시간·안전성·출처 추적성을 함께 포함해야 한다고 제안한다. 운영 평가표에는 최소한 Recall@k, answer relevance, faithfulness, citation support, p95 latency, 질의 1,000건당 비용을 함께 넣는 구성이 적합하다. 출처 리뷰 기록은 "모델: text-embedding-3-small / 검색: BM25+vector / chunk: 500 tokens, overlap 80 / top-k: 10 / reranker: 사용 안 함 / 평가셋: 사내 300문항 / Recall@10: 측정값 / citation support: 측정값 / p95: 측정값 / 비용: 1,000쿼리 기준" 형식으로 남겨야 재현과 비교가 가능하다. 임베딩 모델, 검색 엔진, chunk 규칙, top-k, reranker, 생성 모델, 프롬프트, 문서 색인 날짜 중 하나만 바뀌어도 이 숫자는 다시 측정해야 한다.
핵심 정리
- 인용 링크 존재 여부와 "근거가 주장을 지지하는가"는 별도 지표이며, TREC 2025는 이 둘을 분리해 평가한다.
- 문장 단위 계층형 인용이 문단 끝 단일 인용보다 주장-근거 연결을 검증하기 쉽다.
- 하이브리드 검색도 Recall@100 0.158 수준에 그칠 수 있어, 검색 재현율과 인용 정확도를 함께 측정해야 한다.
- 최신 LLM도 relevance-aware factuality 최대 60%, 근거 부재 거부율 최대 31%로 "모델 업그레이드 = 인용 품질 개선"은 성립하지 않는다.
- 운영 평가는 citation support와 함께 p95 지연시간, 질의 1,000건당 비용을 같이 기록해야 비교가 재현 가능하다.