환각을 일으키지 않는 RAG 구축하기

모든 RAG 튜토리얼은 똑같은 것을 약속합니다. 벡터 데이터베이스 (Vector Database)를 LLM에 연결하기만 하면, 갑자기 모델이 "근거를 갖게(grounded)" 되고 "더 이상 환각 (Hallucination)을 일으키지 않을 것"이라고 말이죠. 하지만 실제로 구축하여 실제 연구 논문들을 대상으로 실행해 보면, 모델이 원문 문서 어디에도 없는 주장을 자신 있게 인용하는 것을 목격하게 됩니다. RAG는 기본적으로 환각을 제거하지 않습니다. 단지 "컨텍스트 (Context)"라는 이름으로 포장하여 모델이 스스로 잘못된 결론을 내릴 수 있는 더 많은 여지를 줄 뿐입니다. PaperMind에서 이를 해결하기 위해 필요했던 것은 화려하지는 않지만 두 가지 핵심적인 요소였습니다. 바로 청킹 (Chunking)을 잘하는 것과, 모델의 불확실성을 사용자로부터 숨기지 않는 것이었습니다.

검색 파이프라인 (The retrieval pipeline)

PaperMind의 역할은 사용자가 연구 논문 코퍼스 (Corpus)를 대상으로 질문을 던졌을 때, LLaMA 3.1이 사전 학습 (Pretraining) 과정에서 기억하고 있는 내용이 아니라 실제 텍스트에 근거한 답변을 얻을 수 있도록 하는 것입니다. 그 이면의 파이프라인은 겉보기에는 상당히 표준적인 RAG 형태를 띠고 있습니다. 문서들이 청킹 (Chunked)되고, 임베딩 (Embedded)되어 Pinecone에 저장됩니다. 쿼리 (Query) 역시 동일한 방식으로 임베딩됩니다. 가장 관련성이 높은 청크 (Chunks)들이 검색되어 프롬프트 (Prompt)에 삽입됩니다. 그리고 Groq을 통해 제공되는 LLaMA 3.1이 해당 컨텍스트 (Context)로부터 답변을 생성합니다.
표준적인 형태는 대부분의 RAG 시스템이 조용히 실패하는 지점이기도 하며, 어디에서 실패하는지 구체적으로 짚어볼 가치가 있습니다.

단순한 청킹 (Naive chunking)이 문제를 일으키는 이유

대부분의 RAG 워크스루(walkthrough)에서 취하는 기본 방식은 고정 크기 청킹 (fixed-size chunking)입니다. 즉, 모든 문서를 예를 들어 500토큰 단위의 블록으로 나누고 다음 단계로 넘어가는 방식입니다. 연구 논문의 경우, 이러한 방식은 검색 품질 (retrieval quality)에 매우 부정적인 영향을 미칩니다. 500토큰의 윈도우 (window)는 문장을 중간에 끊어버리거나, 특정 주장 (claim)과 이를 뒷받침하는 인용 (citation)을 분리하거나, 표 (table)를 그 의미를 설명하는 캡션 (caption)으로부터 떨어뜨려 놓는 일이 빈번하게 발생합니다. 이렇게 깨진 청크 (chunk)가 검색되어 LLM에 "컨텍스트 (context)"로 전달되면, 모델은 정답을 만드는 데 꼭 필요한 정보가 누락된 파편을 사용하여 질문에 답하려고 시도하게 됩니다. 그리고 모델은 "정보가 충분하지 않습니다"라고 말하는 대신, 그 빈틈을 그럴듯하게 들리는 내용으로 채워버리는 경우가 많습니다.

이것이 바로 많은 RAG 환각 (hallucination) 현상의 실제 메커니즘입니다. 모델이 컨텍스트를 "무시"하는 것이 아니라, 프롬프트 (prompt)에 도달하기도 전에 이미 전달된 컨텍스트 자체가 깨져 있었던 것입니다.

PaperMind에서의 해결책은 의미론적 청킹 (semantic chunking)입니다. 고정된 토큰 수로 나누는 대신, 의미론적으로 일관된 단위 (semantically coherent units)를 중심으로 청크를 형성합니다. 즉, 주장과 이를 뒷받침하는 문장들을 함께 묶고, 임의의 경계에서 자르는 대신 섹션의 논증을 온전하게 유지합니다. 이는 고정 크기 분할보다 계산 비용이 더 많이 들며 아직 완전히 해결된 문제도 아닙니다. 모든 논문 구조에 완벽하게 들어맞는 청킹 전략은 존재하지 않기 때문입니다. 하지만 이 방식은 실제로 완전한 생각을 담고 있는 검색된 컨텍스트를 일관되게 생성하며, 이는 파이프라인의 다른 어떤 설정값보다 답변 품질에 더 결정적인 역할을 합니다.

Pinecone, 그리고 실제로 중요한 지루한 부분

벡터 저장소(Vector store) 자체 — 이 경우에는 Pinecone — 는 시스템에서 이야기하기에 가장 흥미가 떨어지는 부분이지만, 운영 측면에서 제대로 구축해야 하는 가장 중요한 부분 중 하나입니다. 임베딩(Embeddings)은 연구 논문 Q&A에서 무엇이 관련성이 있다고 간주되는지와 실제로 일치하는 '유사성(Similarity)' 개념을 가진 모델을 통해 생성되어야 합니다. 추상적인 의미론적 유사성(Abstract semantic similarity)은

임베딩(embeddings)을 얻고 LLM 호출(LLM call)을 작동시키는 것 이상으로, 실제로 중요한 두 가지로 압축하여 말씀드리자면 다음과 같습니다: 첫째, 문서의 구조와 유사하게 청킹(chunking)하는 것이 실제로 중요합니다. 왜냐하면 정말로 중요하기 때문입니다. 둘째, 최종 답변이 검색(retrieval) 단계의 신뢰도를 가리지 않도록 해야 합니다. 유창하고 자신감 있게 들리는 텍스트를 생성하는 LLM은 쉬운 부분입니다. LLM은 근거가 뒷받침되는지 여부와 상관없이 그 역할을 잘 수행합니다. 어려운 부분, 즉 실제 운영 환경에서 당신의 RAG 시스템이 신뢰할 수 있는지 여부를 결정하는 부분은 검색 단계가 찾아낸 것에 대해 정직하도록 보장하는 것과, 그 정직함이 벡터 스토어(vector store)와 사용자가 읽는 채팅창 사이에서 유실되지 않도록 보장하는 것입니다.