RAG 답변이 엉뚱하다면, 모델보다 먼저 검색을 점검하자

검색 결과가 엉뚱하다면 더 큰 모델을 붙이기 전에 문서가 어떻게 읽히고 나뉘었는지 확인해야 해요. 표의 열이 뒤섞였거나 제목이 본문에서 분리되면, 검색과 생성 단계가 그 오류를 보정하기 어렵습니다. RAG 품질은 파싱부터 평가까지 이어지는 과정에서 결정됩니다.

이 글은 기업용 RAG 시리즈의 두 번째 편입니다. 첫 편에서는 마크다운 지식베이스와 도구 선택을 다뤘고, 여기서는 파싱·청킹·검색을 살펴봅니다. 마지막 편에서는 권한, 기억, 보안과 운영 비용으로 이어집니다.

파싱에서 보존해야 할 문서 구조

PDF에서 텍스트만 추출하면 읽는 순서가 바뀌거나 표의 행과 열이 끊길 수 있습니다. 계약서의 조항 번호, 매뉴얼의 제목, 표의 열 제목은 내용만큼이나 중요해요. 파서는 파일에서 텍스트와 레이아웃을 추출하고, 이 구조를 검색 시스템이 다룰 수 있는 표현으로 바꿉니다.

Docling처럼 문서 레이아웃 분석과 표 처리를 제공하는 도구가 있지만, 공개 벤치마크의 수치가 우리 문서의 결과를 보장하지는 않습니다. Unstructured의 문서 분해 도구나 LlamaParse 같은 관리형 파싱 서비스도 비교할 수 있지만, 공개 라이브러리와 유료 API는 기능과 데이터 처리 경로가 다릅니다. 대표적인 스캔 PDF, 다단 문서, 병합 셀이 있는 표를 넣고 추출 결과를 원본과 대조해보세요. 표 제목과 행·열 관계가 보존되는지, 페이지 머리말이 반복해서 본문에 붙지 않는지 확인하는 편이 실용적입니다.

질문에 필요한 문맥을 담는 청크

문서 전체를 한 번에 검색하면 질문에 맞는 부분을 가려내기 어렵고, 반대로 너무 작게 쪼개면 답을 이해하는 데 필요한 조건이 떨어져 나갑니다. 마크다운 헤더나 문단 경계를 우선 살펴보되, 모든 문서에 같은 분할 규칙이 맞는다고 볼 수는 없어요. 표, 목록, FAQ, 정책 문서는 각기 다른 경계를 가질 수 있습니다.

예를 들어 “출장 식비 한도는 얼마인가요?”라는 질문에는 금액만 있는 청크보다 적용 대상과 예외 조건이 같이 있는 청크가 낫습니다. 헤더 경로를 청크에 덧붙이거나 인접 문단을 함께 제공하는 방법도 시험할 수 있어요. 청크 크기와 겹침 길이는 정답처럼 정해진 값이 아닙니다. 실제 질문에서 근거가 잘렸는지 확인하면서 조정합니다. LangChain의 MarkdownHeaderTextSplitter처럼 헤더별로 나눈 뒤 긴 섹션을 추가 분할하는 도구도 쓸 수 있어요. 청크에는 원본 문서 ID, 제목 경로, 버전과 출처 위치를 함께 남겨야 답변의 근거를 추적하기 쉽습니다.

어휘 검색과 의미 검색을 결합하는 이유

벡터 검색은 표현이 달라도 의미가 가까운 문서를 찾는 데 도움을 줍니다. 반면 사내 제품 코드, 오류 식별자, 조항 번호처럼 정확히 일치해야 하는 표현은 BM25 같은 어휘 검색이 더 잘 잡는 경우가 있어요. 두 방식을 함께 쓰는 하이브리드 검색은 서로 다른 검색 신호를 보완하는 선택지입니다. 다만 모든 코퍼스와 질문에서 반드시 성능을 높이는 규칙은 아니므로, 어휘 검색만으로 충분한지 함께 평가해야 합니다.

두 결과의 점수 범위가 서로 다를 때는 순위를 기준으로 합치는 RRF(Reciprocal Rank Fusion)를 사용할 수 있습니다. 이 방식은 각 검색 엔진의 점수 척도를 직접 맞추지 않고, 결과가 어느 순위에 있었는지를 반영합니다. 어떤 결합이 나은지는 질문별 정답 문서와 검색 후보 수에 달려 있어요. 소수의 대표 질문만으로 결론을 내기보다, 자주 묻는 질문과 어려운 질문을 함께 평가 세트로 만드세요.

한국어 임베딩을 고르는 자체 평가 기준

한국어 문서는 조사와 어미, 띄어쓰기 변형, 영문 약어와 제품명이 함께 나타납니다. BGE-M3와 multilingual E5처럼 다국어를 지원하는 공개 모델도 있고, API로 제공되는 임베딩도 있어요. 모델 카드의 언어 지원이나 출력 차원은 후보를 좁히는 정보이지, 우리 사내 검색 성능의 순위표는 아닙니다. 상용 API와 로컬 배포 모델은 비용 구조, 데이터 처리 방식, 운영 부담도 함께 비교해야 해요.

질문과 정답 문서 쌍을 모아 Recall@k나 nDCG 같은 검색 지표를 확인하면, 관련 문서가 상위 결과에 들어오는지 비교할 수 있습니다. Recall@k는 정답 근거가 상위 k개에 얼마나 포함됐는지, nDCG는 관련성이 높은 결과를 앞에 배치했는지 보는 지표예요. 여기에 지연 시간과 요청 비용을 더해 운영 조건을 살펴보세요. 실제 검색 로그에서 표현이 다른 같은 질문, 사내 약어, 특정 문서 번호를 골라 테스트하면 모델 카드로 알기 어려운 차이를 발견할 수 있습니다.

한국어 전처리도 조심스럽게 적용해야 해요. 명사만 남기거나 불용어를 일괄 제거하면 부정, 조건, 시점 표현이 사라져 의미가 달라질 수 있습니다. 형태소 분석이 도움이 될 수 있는 코퍼스도 있지만, 원문을 보존한 기준 검색과 비교해 개선 여부를 확인한 뒤 적용하는 편이 안전합니다.

리랭킹과 최신성 가중의 적용 기준

첫 검색이 관련 문서를 넓게 모았다면, 리랭커는 질문과 각 문서를 함께 보고 순서를 다시 정할 수 있습니다. 후보가 많거나 의미가 비슷한 문서 사이의 우선순위가 중요할 때 유용하지만, 모델 호출과 계산량이 늘어납니다. 리랭킹 전후의 정답 문서 위치와 응답 품질을 비교해 실제로 이득이 있는지 확인하세요. 후보 수나 응답 시간이 모든 시스템에서 같다고 가정할 수는 없습니다.

최신성 역시 날짜만으로 결정하지 말아야 해요. 공지일보다 시행일, 개정 상태, 폐기 여부가 중요한 업무가 있습니다. 문서에 작성일·유효 시작일·종료일·버전 같은 메타데이터를 두고, 업무 규칙에 맞게 검색 결과에 반영할 수 있어요. 오래된 자료가 여전히 유효한 사례도 정답 세트에 포함해야 합니다. 현재 규정을 묻는 질문과 과거 시점의 규정을 묻는 질문도 나눠야 해요. 폐기 여부와 유효 기간으로 후보를 먼저 제한할지, 남은 후보에 최신성 가중을 줄지 구분해야 과거 자료를 찾는 질문을 망치지 않습니다.

검색 실패와 생성 실패를 나눠 평가하기

RAG 답변이 틀렸을 때는 원인을 나눠야 개선할 수 있습니다. 정답 근거가 후보에 없었다면 파싱·청킹·검색 문제일 수 있고, 후보에 있었지만 답변에 쓰이지 않았다면 문맥 구성이나 생성 문제가 될 수 있어요. 정답 문서와 답변에 필요한 근거 구간을 기록하고, 각 단계에서 무엇이 선택되었는지 살펴보세요.

성능 수치 하나로 도입을 결정하기보다, 실제 업무 질문에서 근거를 찾는지와 잘못된 답을 얼마나 쉽게 발견할 수 있는지를 보세요. 문서에 사용자별 권한이 붙거나 대화 기억을 더하는 순간 검색 설계는 보안 설계와 맞물립니다. 그 경계는 시리즈 마지막 편에서 이어서 다룹니다.