멀티 문서 대화형 RAG 파이프라인

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

LangChain LCEL과 ChromaDB로 만든 멀티 문서 대화형 RAG 파이프라인을 26개 구조화 질의로 평가했습니다. 대화 이력을 반영한 query rewriter는 모호한 후속 질문을 다시 작성해 k=5 기준 Multi-Turn MRR을 0.5000에서 0.6389로 높였고, 청크 설정 1000/200은 1000/100보다 안정적인 검색 결과를 냈습니다. Dense Retrieval의 hit rate는 88.46%에서 정체됐으며 정확한 도메인 용어 누락이 원인으로 확인돼 BM25를 결합한 Hybrid Search가 후속 과제로 남았습니다. 생성 답변은 LLM-as-a-Judge와 엄격한 Pydantic 스키마를 사용한 Faithfulness 평가에서 5.0/5.0을 기록했습니다.

주요 논점

01찬성소수

대화 이력을 이용한 query rewriting은 모호한 대명사를 검색 가능한 질의로 바꿔 Multi-Turn MRR을 0.5000에서 0.6389로 높였습니다.

02찬성소수

1000/200 청크 설정이 1000/100보다 높은 검색 성능을 보였고, overlap 부족이 문맥 분리를 일으킨다는 실험 결과가 확인됐습니다.

03찬성소수

Dense Retrieval의 hit rate가 88.46%에서 멈추고 정확한 도메인 용어를 놓친 사례가 있어 BM25와 Dense Retrieval의 결합이 개선 방향으로 제시됐습니다.

실용적 조언

멀티턴 질의에서는 원문 후속 질문을 바로 임베딩 검색에 넣지 말고 대화 이력에서 대명사와 생략된 대상을 복원하는 query rewriter를 먼저 실행하는 방식이 적합합니다. 이 단계의 효과는 Multi-Turn MRR처럼 순위 기반 지표로 별도 측정해야 합니다. 게시글의 설정에서는 k=5 기준 MRR이 0.5000에서 0.6389로 상승했습니다.
문서 청크를 1000자로 나눌 때 overlap을 100자에 고정하지 말고 200자 설정도 함께 비교해야 합니다. overlap이 너무 작으면 청크 경계에서 핵심 문맥이 끊겨 검색 순위가 하락할 수 있습니다. 해당 실험에서는 1000/200이 최적 설정이었고 1000/100에서는 baseline MRR이 0.3056까지 떨어졌습니다.
정확한 도메인 용어가 자주 등장하는 코퍼스에서는 Dense Retrieval의 hit rate만으로 검색 품질을 판단하지 않는 편이 좋습니다. BM25의 키워드 일치 결과와 Dense Retrieval의 의미 유사도 결과를 결합하는 Hybrid Search를 추가하고, 기존 88.46% hit rate에서 누락된 질의를 별도로 재평가해야 합니다.

섹션별 상세

26개의 구조화된 테스트 질의로 멀티턴 검색, 청크 겹침, Dense Retrieval의 실패 지점을 측정했습니다. 대화형 후속 질문을 원문 그대로 검색하면 대명사가 모호해져 관련 문서를 놓쳤지만, 대화 이력을 반영한 query rewriter를 추가하자 k=5 기준 Multi-Turn MRR이 0.5000에서 0.6389로 상승했습니다. 이전 대화에서 지칭 대상을 복원해 검색 질의를 다시 만드는 과정이 멀티턴 RAG의 검색 품질을 높인 핵심 요인입니다.

청크 크기 1000자에서 overlap을 100자로 줄이면 핵심 문맥이 청크 경계에서 분리되어 baseline MRR이 0.3056까지 하락했습니다. 1000/200 설정은 인접 청크 사이에 200자의 중복 문맥을 유지해 관련 정보가 나뉘는 문제를 줄였고, 실험에서 최적 설정으로 나타났습니다. 따라서 청크 크기만 고정하기보다 문서의 문맥 연결성과 검색 순위를 함께 측정해야 합니다.

Dense Retrieval의 hit rate는 88.46%에서 정체됐으며, 실패 사례에서는 정확한 도메인 용어를 임베딩 검색이 놓쳤습니다. 글은 의미 유사도에 의존하는 Dense Retrieval만으로는 용어 일치가 중요한 질의를 충분히 처리하기 어렵다고 보고, BM25와 Dense Retrieval을 결합하는 Hybrid Search가 필요하다고 결론냈습니다. 검색 방식의 한계를 실제 누락 사례와 hit rate로 확인했다는 점에서 후속 개선 방향이 구체적입니다.

생성 단계는 엄격한 Pydantic 스키마와 LLM-as-a-Judge를 사용해 Faithfulness 5.0/5.0을 받았습니다. 검색 결과를 바탕으로 생성된 답변이 근거 문서에 충실한지 구조화된 형식으로 채점해, 검색 품질과 생성 품질을 분리해 확인했습니다. 다만 게시글에 제시된 수치는 26개 테스트 질의와 해당 평가 설정에 기반하므로 다른 데이터셋에서도 같은 결과가 재현되는지는 추가 검증이 필요합니다.

용어 해설

검색 증강 생성(RAG): — RAG는 질문과 관련된 외부 문서를 먼저 검색한 뒤 그 내용을 언어 모델의 입력 맥락에 넣어 답변을 생성하는 방식입니다. 모델 내부 지식만 사용할 때보다 최신 문서와 특정 도메인 정보를 반영하기 쉽습니다.
LangChain Expression Language(LCEL): — LCEL은 LangChain 구성 요소를 실행 가능한 체인으로 연결하는 표현 방식입니다. 검색기와 프롬프트, 모델, 출력 처리 단계를 조합해 RAG 파이프라인의 처리 흐름을 코드로 구성할 수 있습니다.
ChromaDB 벡터 데이터베이스(ChromaDB): — ChromaDB는 문서 임베딩을 저장하고 질문 벡터와의 유사도를 계산해 관련 청크를 찾는 벡터 데이터베이스입니다. RAG에서는 문서 분할 결과를 저장하고 검색 결과를 반환하는 역할을 맡습니다.
평균 상호 순위(MRR): — MRR은 정답 문서가 검색 결과에서 몇 번째에 나타나는지를 반영하는 검색 평가 지표입니다. 정답 순위의 역수를 여러 질의에 대해 평균내므로 정답이 상위에 배치될수록 값이 높아집니다.
BM25 검색(BM25): — BM25는 단어의 출현 빈도와 문서 길이를 이용해 질의와 문서의 관련도를 계산하는 키워드 검색 방식입니다. Dense Retrieval이 놓칠 수 있는 정확한 도메인 용어를 찾기 위해 임베딩 검색과 결합할 수 있습니다.
LLM 기반 평가자(LLM-as-a-Judge): — LLM-as-a-Judge는 별도의 언어 모델이 생성 답변을 정해진 기준에 따라 채점하는 평가 방식입니다. 이 사례에서는 Pydantic 스키마를 사용해 Faithfulness 점수를 구조화된 형식으로 받았습니다.

언급된 도구

LangChain (LCEL)중립

검색기, 질의 재작성, 생성 단계를 연결해 멀티 문서 대화형 RAG 파이프라인을 구성합니다.

ChromaDB중립

문서 청크의 임베딩을 저장하고 Dense Retrieval에 필요한 유사도 검색을 수행합니다.

언급된 리소스

GitHubdenizzozupek/multi-doc-rag-assistant