RAG에서 인용이 안 맞을 때 원인, 벡터DB보다 먼저 확인할 5가지(청크·메타데이터·검색 쿼리)

RAG(검색 기반 생성)에서 “근거로 가져온 내용”이랑 “답변에 붙은 인용”이 어긋나면, 제일 먼저 드는 생각이 벡터DB 성능이에요. 근데 실제로는 청크가 잘려나간 방식, 메타데이터의 매칭 규칙, 검색 쿼리(질문)와 검색 결과의 연결에서 더 자주 문제가 터져요.

결론부터 말하면, 인용 불일치는 “검색 결과-근거 문장-인용 태그”를 이어주는 고리가 끊겨서 생깁니다. 그래서 벡터DB 튜닝 전에, 아래 5가지를 순서대로 확인해보세요.

1 청크: “인용으로 딱 집히는 단위”가 맞나요?

답변에 인용이 어긋날 때 가장 흔한 원인이 청크예요. 청크가 너무 커도 문제고, 너무 잘게 쪼개져도 문제죠.

예를 들어, 제목/목차는 한 청크에 있고 본문 문장은 다른 청크에 있는데 모델이 제목을 근거처럼 인용하면 “출처가 틀린 느낌”이 나요. 반대로 본문이 너무 한 덩어리로 합쳐져 있으면, 검색은 그 덩어리를 가져오지만 실제 답은 청크 내부 다른 문장에서 나오면서 인용이 어긋납니다.

2 메타데이터: 출처 식별자(키)가 일관되나요?

검색 결과에는 맞는 문서가 잡혔는데 인용이 어긋나는 경우, 보통 메타데이터가 모델이 읽는 방식과 인용 태그가 붙는 방식이 불일치해서 생깁니다.

특히 자주 놓치는 포인트는 “출처 키”예요. 페이지 번호, 문서 ID, 파일명, 섹션명 같은 값이 인덱싱 시점과 인용 출력 시점에서 같은 규칙으로 붙고 있는지 봐야 합니다.

• 문서 ID가 청크마다 다르게 들어가 있진 않나요? (같아야 하는데 다르면 출처가 튑니다.)
• 페이지/섹션 정보가 모델 프롬프트에 제대로 전달되나요?
• 필터링용 메타데이터(예: 제품명=OOO, 언어=ko)가 검색 단계에서만 쓰이고, 생성 단계에서는 빠져 있진 않나요?
• 메타데이터 타입(문자열/숫자)이나 키 이름이 파이프라인마다 다르게 매핑되진 않나요?

메타데이터는 “데이터를 설명하는 정보”라서, 인덱싱과 생성 사이에서 형식이 조금만 틀어져도 근거-인용이 어긋나는 계기가 됩니다. 메타데이터 개념은 메타데이터를 참고해 두면 전체 설계를 점검할 때 도움이 돼요.

3 검색 쿼리: 질문이 “근거 문장”을 유도하나요?

검색 쿼리가 약하면 벡터DB 탓을 하기 쉬워요. 하지만 인용이 안 맞는 문제는 “검색은 했는데 답에 필요한 문장까지는 안 잡힌” 상태에서 시작되는 경우가 많습니다.

다음 중 하나라도 해당되면 쿼리부터 손대는 게 빨라요.

• 질문이 너무 포괄적이라 근거 문장이 아니라 설명성 문단이 검색됩니다.
• 동의어/약어가 섞여 있어, 인덱스에 있는 표현과 임베딩 매칭이 애매해요.
• “어느 문서/기간/버전”을 물어보는데 쿼리에는 조건이 없어서 다른 버전 문서를 가져옵니다.
• 검색 쿼리는 맞는데, 생성 단계 프롬프트가 그 결과를 다른 형태로 재정리하면서 인용 태그 매핑이 밀립니다.

여기서 중요한 건 “질문을 더 길게”가 아니라, 인용에 필요한 조건을 쿼리에 담는 거예요. 예: “OOO 정책의 2024년 3월 공지 기준으로”처럼요.

4 “top-k 문서”와 “인용할 근거”의 선택 규칙이 맞나요?

검색 결과가 여러 개일 때, 인용은 보통 “그중 일부”만 선택합니다. 이때 선택 규칙이 명확하지 않으면 인용이 엇나가요.

• 모델이 top-k 중 아무 근거나 끌어오도록 되어 있나요, 아니면 답변 문장과의 정합성을 기준으로 근거를 고르나요?
• 인용 표기는 “문서 수준”인지 “청크 수준”인지 애매하진 않나요?
• 근거 선택 전에 중복 청크 제거(같은 내용 반복) 같은 처리가 있나요? 없으면 엉킨 인용이 나올 때가 있어요.
• 동일 청크가 여러 문서에서 재사용됐다면, 인용에 문서 ID가 정확히 들어가나요?

즉, 벡터DB가 “잘 찾아왔는지”보다 먼저 “찾아온 결과에서 어떤 것을 인용하도록 설계했는지”를 봐야 합니다.

5 벡터DB 점검 전에: “검색 결과 원문”이 실제로 연결되는지 확인

드디어 벡터DB 얘기할 차례인데, 여기서는 성능 튜닝보다 “파이프라인 연결”을 봅니다.

실무에서 자주 있는 케이스가 “임베딩용으로 만든 텍스트”와 “인용 출력용 원문”이 다르게 관리되는 경우예요. 이러면 검색은 성공해도 인용은 엇갈립니다.

자주 하는 실수 3가지

• 인용만 보고 검색 로그/메타데이터 로그를 안 보는 것: 인용 문제는 “표시 문제”가 아니라 “근거 연결 문제”인 경우가 많아요.
• 청크 전략을 바꿨는데 인용 규칙(청크/문장 수준)이 같이 바뀌지 않은 것.
• 검색 쿼리를 바꿨는데 버전/필터(문서 범위)가 쿼리 또는 필터로 동기화되지 않은 것.

빠르게 원인 좁히는 실행 체크리스트

1. 인용이 어긋난 사례 1개를 골라, 답변의 인용 문장과 “검색에 잡힌 청크 원문”을 비교합니다.
2. 그 청크의 메타데이터(문서 ID/페이지/섹션 등) 값이 생성 단계에 동일하게 전달되는지 확인합니다.
3. 검색용 쿼리를 “인용 조건(기간/대상/버전)”을 포함하도록 최소 수정해 재검색합니다.
4. top-k 중 근거 선택 규칙(문서/청크/문장)이 원하는 방식인지 점검합니다.
5. 원문 텍스트를 가져오는 저장소 매핑(ID/오프셋)이 연결이 끊기지 않았는지 확인합니다.

함께 점검하면 좋은 링크

• LLM 마이그레이션 시 호환성 문제, 모델 교체 전에 확인할 8가지 항목
• AI 모델 성능 평가, 정확도보다 먼저 볼 지표 3가지(환각·지연 포함)
• LLM 출력 품질 떨어질 때 원인, 온도·top_p보다 먼저 확인할 4가지 설정

자주 묻는 질문