답변에 AI를 포함하지 않는 검색, 그리고 Tree-RAG 대신 일반 청크(Plain Chunks)를 선택한 이유

저는 WordPress를 위한 개인정보 보호 우선 RAG 챗봇을 개발하고 있습니다. 이 글은 pagecoder.ai의 검색 및 청킹 (Chunking)에 관한 두 가지 글을 결합한 것이며, AI 채팅 플러그인이 질문당 유출하는 정보에 관한 이전 게시물의 연장선에 있습니다.

지난 사이클 동안 저는 사람들이 계속해서 요청했던 두 가지 기능을 제 WordPress RAG 플러그인에 추가했습니다. 바로 방문자용 검색과 대용량 PDF 인덱싱(Indexing)입니다. 각각의 기능은 기록할 가치가 있는 검색(Retrieval) 결정으로 귀결되었습니다.

1. 검색: 검색은 하되, 생성은 하지 마라

제 챗봇은 두 단계로 답변합니다. 가장 관련성 높은 콘텐츠를 검색(Retrieve)한 다음, 이를 답변을 작성할 모델에 전달합니다. 검색은 단지 첫 번째 단계이며, 두 번째 단계가 시작되기 전에 멈추는 것입니다.

검색창에 타이핑을 하면, 챗봇이 사용하는 것과 동일한 검색(Retrieval) 과정을 실행한 후 멈춥니다. 답변을 구성하도록 모델에 요청하지 않습니다. 대신 검색어에 하이라이트가 표시된 순위별 결과와 같은 가공되지 않은 매칭 결과(Raw matches)를 돌려받게 됩니다.

조기에 멈추는 것이 핵심입니다. 이를 통해 세 가지를 얻을 수 있습니다:

• 환각 (Hallucination) 없음. 아무것도 생성되지 않으므로, 아무것도 지어낼 수 없습니다. 모든 결과는 실제 페이지로 연결됩니다.
• 출처로 바로 이동. 페이지와 일치할 수도 있고 아닐 수도 있는 의역된 문장이 아니라, 순위가 매겨진 링크를 제공합니다.
• 더 가볍습니다. 채팅 답변에서 느리고 비용이 많이 드는 부분은 모델이 수백 단어를 작성하는 과정입니다. 이 과정을 건너뛰면 동일한 조회 작업을 더 저렴하고 빠르게 수행할 수 있습니다.

제품의 핵심이 과장하지 않는 것에 있는 만큼, 솔직한 주의 사항을 하나 덧붙이자면: 검색이 AI를 '전혀' 사용하지 않는 것은 아닙니다. 단순 키워드가 아닌 의미를 매칭하기 위해, 쿼리(Query)는 여전히 임베딩 (Embedding)으로 변환됩니다 (챗봇이 사용하는 것과 동일한 백엔드를 사용한 후 폐기됩니다). 하지만 사람들이 실제로 걱정하는 부분, 즉 모델이 사용자의 콘텐츠에 대해 텍스트를 작성하는 일은 일어나지 않습니다.

2. 청킹 (Chunking): 지루한 방식이 영리한 방식을 이기다

대용량 PDF를 인덱싱하려면 먼저 조각으로 잘라야 합니다. 여기에는 지루한 방식과 영리한 방식이 있습니다.

지루한 방식 (Boring): 고정 크기 청크 (fixed-size chunks). 문서를 따라가며 각 조각이 몇 개의 문단 정도로 대략 동일한 크기가 되도록 자릅니다. 경계에 있는 문장이 유실되지 않도록 약간의 중첩 (overlap)을 둡니다. 제목이 무엇인지는 고려하지 않습니다. 그저 일관된 조각들일 뿐입니다.

영리한 방식 (Clever): Tree-RAG (예: PageIndex). 목차 (table of contents)로부터 트리를 구축합니다. 섹션 (sections)이 노드 (nodes)가 되며, 쿼리 (query) 시점에 가장 관련 있는 브랜치 (branch)를 따라 내려가 해당 섹션 전체를 가져옵니다. 이론적으로는 길고 구조화된 문서에 분명히 더 좋습니다.

저는 영리한 방식을 원했습니다. 직접 만들었다고 말하기에 더 인상적이기 때문입니다. 그래서 추측하는 대신 제대로 테스트했습니다. 일반적인 페이지와, 트리가 가장 잘 작동할 환경인 목차가 많은 긴 PDF 모두에 대해 등급 평가 (graded eval, 모든 답변에 대해 정답/부분 정답/오답 점수 부여)를 실시했습니다.

결과는 승리하지 못했습니다. 방향성 있는 결과이므로, 제 수치를 믿기보다는 직접 평가를 실행해 보시길 권장합니다:

측정 항목	고정 크기 청크 (Fixed-size chunks)	Tree-RAG
일반 페이지에서의 정확도	더 높음	더 낮음
...

승리한 이유: 토큰 (tokens)과 비용

결국 모델에 얼마나 많은 양을 전달하느냐의 문제입니다. 트리가 "가장 관련 있는 섹션"을 가져올 때, 그 섹션은 수 페이지에 달할 수 있으며 그 전체가 프롬프트 (prompt)에 포함됩니다. 반면 고정 크기 청크는 몇 개의 밀도 있는 조각만을 전달하고 그 외에는 아무것도 전달하지 않습니다. 이는 비용 (모델이 읽는 만큼 비용을 지불함)과 품질 (주변 텍스트에 정답을 묻어버리면 모델이 엉뚱한 방향으로 흐를 여지를 줌) 모두에서 나타납니다. 효율적인 검색 (Lean retrieval)은 단순히 더 저렴할 뿐만 아니라 종종 더 정확합니다.

솔직한 주의사항

트리가 쓸모없었던 것은 아닙니다. "이 문서 전체의 주제가 무엇인가?"와 같은 질문에는 진정으로 더 나았습니다. 모델에게 구조화된 섹션 전체를 한 번에 제공할 수 있기 때문입니다. 만약 사용 사례가 거의 전적으로 문서 전체 요약 (whole-document summarization)에 집중되어 있다면, 비용을 들일 가치가 있을 것입니다. 하지만 실제 방문자들이 묻는 구체적인 "X라고 적힌 부분이 어디인가?"와 같은 질문에는 지루한 조각 방식이 승리했습니다. 그래서 저는 청크 (chunks) 방식을 배포하고 트리는 보류했습니다.

이것이 PDF (그리고 여러분의 데이터)에 의미하는 바

저는 검증된 방식으로 대용량 PDF를 인덱싱 (indexing) 합니다. 텍스트를 추출 (extracted) 하고, 자르고 (sliced), 검색 (searched) 합니다. 개인정보 보호 측면에서는 제품의 나머지 부분과 동일하게 작동합니다. 추출은 메모리 내에서 발생하며, 파일 자체는 제 쪽에 절대 저장되지 않고, 검색 가능한 조각들은 귀하의 자체 데이터베이스에 존재합니다.

복음이 아닌 하나의 조언으로 받아들이세요

제가 의견을 읽는 대신 직접 테스트를 한 이유는, 이러한 것들은 주장하기 쉽고 확인하기도 쉽기 때문입니다. 만약 검색 (retrieval) 또는 청킹 (chunking) 전략을 선택하고 있다면, 화려한 기술을 채택하기 전에 귀하의 문서로 작은 등급 평가 (graded eval)를 구축해 보세요. 그것은 귀하가 RAG를 위해 보낼 시간 중 가장 유용한 오후가 될 것입니다.

저는 WordPress를 위한 개인정보 보호 우선 AI 챗봇 + 검색 서비스인 RAG Chat을 만듭니다. 7일 무료 체험이 가능하며, 카드는 필요하지 않습니다. 맞춤형 구축이 필요하신가요? 필요한 내용을 말씀해 주세요. 이 포스트에는 트래킹 픽셀 (tracking pixels)이 사용되지 않았습니다.