chunk의 산이 아니라 지도를 건네기 ― PageIndex와 계층형 검색 (RAG 제5회)

지난번에는 Agentic RAG를 살펴보았습니다.

한 번 검색해서 답하는 것이 아니라, 부족하면 다시 조사한다.

답하기 전에, "이 정보로 충분한가"를 확인한다.

여기서 자연스럽게 다음 문제가 발생합니다.

Agent는 어디를 보러 가야 하는가.

검색기(Retriever)가 후보를 반환하는 것만으로는 아직 부족합니다.

긴 문서, 대량의 PDF, PPT, Excel, 폴더에 흩어진 사내 자료에서는 후보가 너무 많습니다.

비슷한 chunk는 반환됩니다.

하지만 어느 장(Chapter)을 읽어야 할지 알 수 없습니다.

어느 표가 본체인지 알 수 없습니다.

같은 단어가 나와 있을 뿐인 관계없는 페이지도 섞입니다.

모델은 대량의 파편을 읽게 되어 도중에 길을 잃습니다.

이 문제에 대한 하나의 사고방식이 PageIndex입니다.

PageIndex의 본질은 긴 문서를 평면적인 chunk의 집합으로 취급하지 않는 것입니다.

문서를 위에서 아래로 따라갈 수 있는 지도로 만드는 것입니다.

제5회에서는 PageIndex와 계층형 검색(Hierarchical Search)을 살펴봅니다.

많은 RAG에서는 문서를 chunk로 나눕니다.

PDF를 수백 자 단위로 자릅니다.

Markdown을 제목(Heading) 단위로 자릅니다.

슬라이드를 페이지 단위로 자릅니다.

표를 행이나 셀로 나눕니다.

그 후에 각각을 임베딩(embedding)하여 질문에 가까운 chunk를 가져옵니다.

이는 이해하기 쉬운 방법입니다.

구현하기도 쉽습니다.

하지만 긴 문서에서는 문제가 발생합니다.

먼저, 문서 전체의 구조가 사라집니다.

제1장 배경.

제2장 전제.

제3장 실험.

제4장 예외.

부록 표.

인간이 문서를 읽을 때는 이 구조를 보고 있습니다.

목차를 보고 필요한 장을 펼친 뒤, 거기서 해당 부분으로 나아갑니다.

그런데 flat chunk로 만들면 문서는 파편의 산으로 취급됩니다.

검색기는 질문과 유사한 파편을 집어 올립니다.

하지만 그 파편가 문서 전체의 어디에 있는지, 앞뒤에는 무엇이 있는지, 상위 장(Chapter)이 무엇을 말하고 있는지는 보기 어렵습니다.

다음으로 노이즈가 증가합니다.

긴 문서에는 비슷한 단어가 여러 번 등장합니다.

계약서라면 "해지", "지불", "예외".

기술 사양서라면 "인증", "에러", "제한".

조사 보고서라면 "리스크", "영향", "대응".

질문에 가까운 단어가 포함된 chunk는 많습니다.

하지만 정말 읽어야 할 곳은 적습니다.

RAG의 실패는 찾지 못하는 것뿐만이 아닙니다.

너무 많이 찾는 것으로도 발생합니다.

LLM은 관계없는 문맥이 들어오면 혼란을 느낍니다.

비슷하지만 다른 파편이 섞이면 답이 흐릿해집니다.

따라서 긴 문서에서는 "많이 찾는 것"보다 "읽는 순서를 만드는 것"이 더 중요해지는 상황이 있습니다.

PageIndex의 사고방식은 문서를 트리 구조(Tree Structure)로 만드는 것입니다.

가장 위에는 문서 전체의 요약이 있습니다.

그 아래에는 장(Chapter)이나 큰 덩어리가 있습니다.

더 그 아래에는 실제로 읽어야 할 본문의 단위가 있습니다.

대략적으로 쓰면 다음과 같습니다.

root:
문서 전체의 개요
페이지 범위
...

Agent는 갑자기 본문의 파편을 대량으로 읽게 되지 않습니다.

먼저 root를 봅니다.

다음으로 관련이 있어 보이는 section을 선택합니다.

필요하다면 더 아래의 section으로 들어갑니다.

마지막으로 leaf의 본문을 읽습니다.

이는 인간의 읽기 방식과 유사합니다.

책을 읽을 때 갑자기 무작위로 20페이지를 건네받으면 곤란합니다.

먼저 목차를 봅니다.

장 제목을 봅니다.

필요한 장을 펼칩니다.

그 안에서 해당 부분을 읽습니다.

PageIndex는 이러한 읽기 방식을 Agent에게 전달하기 위한 구조입니다.

여기서 중요한 것은 각 노드(Node)의 서머리(Summary)입니다.

서머리라고 하면 단순히 짧게 정리한 문장을 상상하기 쉽습니다.

하지만 PageIndex에서 필요한 서머리는 깔끔한 요약이 아닙니다.

Agent가 다음 단계로 나아갈지 판단하기 위한 재료입니다.

즉, 다음과 같은 정보가 들어있어야 합니다.

이 범위에 무엇이 쓰여 있는가
중요 용어
수치
...

두루뭉술한 서머리로는 판단 재료로서 불충분합니다.

"본 장에서는 시스템의 개요를 설명한다"라고만 되어 있으면 Agent는 판단할 수 없습니다.

"본 장에서는 OAuth 인증, API key, rate limit, 401/403 에러 처리를 설명한다"라고 적혀 있다면 다음에 나아갈지 판단할 수 있습니다.

PageIndex의 서머리는 읽기 좋은 글일 필요는 없습니다.

검색과 판단을 위해 구체적이어야 합니다.

이는 RAG의 전처리로서 상당히 효과적입니다.

좋은 chunking은 단순히 문서를 자르는 것이 아닙니다.

나중에 Agent가 선택할 수 있는 형태로, 문서의 구조와 단서를 남기는 것입니다.

PageIndex가 흥미로운 점은 의미뿐만 아니라 물리적 구조도 본다는 것입니다.

페이지 범위가 연속되어 있는가.

자식 노드의 범위가 부모 노드 안에 포함되어 있는가.

장의 순서가 흐트러지지 않았는가.

슬라이드라면 slide index가 있는가.

Excel이라면 sheet name이나 표 머리글을 알 수 있는가.

사소해 보이지만, 상당히 중요한 점입니다.

LLM은 의미를 읽는 데는 능숙합니다.

하지만 문서 처리에서는 「위치」도 큰 역할을 합니다.

계약서의 제8조인가.

부록의 표인가.

슬라이드 12인가.

Excel의 「요금표」 시트인가.

폴더의 어느 파일인가.

기업 문서에서는 이 위치 정보가 근거로서 작용합니다.

나중에 사람이 확인할 때도 페이지나 슬라이드, 시트 이름이 없으면 곤란합니다.

따라서 PageIndex는 의미의 지도인 동시에, 문서의 위치를 유지하는 메커니즘이기도 합니다.

PageIndex가 특히 효과적인 것은 문서가 길고, 구조를 가지고 있으며, 노이즈가 많은 상황입니다.

예를 들어, 다음과 같은 자료들입니다.

긴 PDF
계약서
사양서
...

이러한 문서들은 단순한 텍스트가 아닙니다.

목차가 있습니다.

장이 있습니다.

페이지가 있습니다.

표가 있습니다.

보충 자료가 있습니다.

파일명이나 폴더명에도 의미가 있습니다.

flat chunk RAG는 이러한 구조를 깨뜨리기 쉽습니다.

반대로 PageIndex는 그 구조를 활용합니다.

Agent는 먼저 큰 지도를 봅니다.

필요한 가지를 선택합니다.

아래로 내려갑니다.

마지막으로 본문을 읽습니다.

이러한 흐름으로 구성하면 불필요한 chunk를 읽는 양을 줄일 수 있습니다.

또한, 왜 그 부분을 읽었는지도 설명하기 쉬워집니다.

물론 PageIndex가 항상 필요한 것은 아닙니다.

짧은 기사.

구조가 단순한 Markdown.

이미 고품질의 헤딩(heading)으로 나누어져 있는 문서.

수천 건의 짧은 FAQ.

로그나 코드처럼 grep이나 BM25가 잘 통하는 대상.

이런 것들에 억지로 트리 구조를 만들 필요는 없습니다.

오히려 PageIndex를 구축하는 비용이 더 커집니다.

트리를 만들려면 문서를 읽고, 요약(summary)을 만들고, 범위를 확인하고, 노드 입도(granularity)를 결정해야 합니다.

대량의 문서에 대해 LLM으로 고품질의 요약을 만든다면 비용도 많이 듭니다.

또한 요약의 질이 낮으면 Agent는 잘못된 가지로 나아갑니다.

상위 노드의 설명이 부실하면 애초에 올바른 하위 노드를 선택할 수 없습니다.

PageIndex는 좋은 지도를 만들 수 있을 때 빛을 발합니다.

지도가 엉망이라면 길을 잃는 방식만 바뀔 뿐입니다.

제4회에서 다룬 Agentic RAG와 PageIndex는 궁합이 매우 좋습니다.

Agentic RAG는 정보가 부족하면 다시 한번 찾는 메커니즘이었습니다.

PageIndex는 다음에 어디를 찾을지 선택하기 쉽게 만드는 문서 지도입니다.

즉, 다음과 같이 연결됩니다.

Agentic RAG:
부족한 정보를 찾아냄
PageIndex:
... 

예를 들어, 계약의 환불 조건을 조사하고 있다고 가정해 봅시다.

먼저 root를 봅니다.

계약 전체에 「요금」, 「해지」, 「예외」, 「부록」이 있다는 것을 알게 됩니다.

다음으로 「해지」 장을 봅니다.

그곳에는 통지 기한이 있지만, 환불 금액은 부록의 요금표에 의존한다는 것을 알게 됩니다.

다음으로 「부록: 요금표」로 진행합니다.

마지막으로 해당 표를 읽습니다.

이것은 단순한 top-K 검색이 아닙니다.

조사의 경로입니다.

PageIndex가 있으면 Agentic RAG의 「다음에 무엇을 찾을 것인가」가 구체화되기 쉬워집니다.

여기서 오해하기 쉬운 점이 있습니다.

PageIndex는 벡터 검색으로 찾아낸 chunk를 조금 정리하기 위한 장식이 아닙니다.

발상 자체부터가 훨씬 앞단에서 다릅니다.

벡터 검색은 질문과 유사한 파편을 찾습니다.

PageIndex는 문서의 구조를 보면서 어떤 가지를 따라가야 할지 선택합니다.

즉, 중심에 있는 것은 유사도가 아니라 탐색의 경로입니다.

Agent는 먼저 문서 전체나 장의 요약을 읽습니다.

거기서 「이 장에 답이 있을 것 같다」라고 판단합니다.

필요하다면 더 아래의 절(section)로 내려갑니다.

마지막으로 본문을 읽습니다.

이 흐름은 벡터 검색 없이도 성립합니다.

root부터 순서대로 Agent가 읽으며 선택해도 됩니다.

BM25로 노드의 요약을 찾아도 됩니다.

물론 구현상으로는 상위 노드의 요약에 벡터 검색을 사용해도 무방합니다.

하지만 그 경우에도 주인공은 벡터 검색 (Vector Search)이 아닙니다.

검색 대상이 '본문 chunk (Chunk)만'이 아니게 됩니다.

본문 그 자체.

장의 요약 (Summary).

페이지 범위.

표의 제목.

슬라이드 이름.

파일명.

폴더 구조.

이것들을 사용하여, Agent (에이전트)가 '다음에 어디를 읽을지'를 결정합니다.

이것이 PageIndex의 핵심입니다.

따라서 PageIndex는 검색기의 종류가 아닙니다.

문서를 추론하며 따라갈 수 있는 형태로 바꾸는 설계입니다.

벡터 검색은 '가까운 것'을 찾습니다.

PageIndex는 '읽는 경로'를 만듭니다.

RAG에 대해 이야기하다 보면, 자기도 모르게 모델이나 벡터 데이터베이스 (Vector Database)에 눈길이 갑니다.

하지만 기업용 RAG에서 정말로 부담이 큰 부분은, 문서를 AI가 읽을 수 있는 형태로 만드는 곳입니다.

PDF의 텍스트 추출이 깨진다.

표가 망가진다.

각주가 본문에 섞인다.

슬라이드의 읽기 순서를 알 수 없다.

Excel의 표 헤더가 사라진다.

파일명이나 폴더명에 담긴 의미가 누락된다.

이 상태에서는 아무리 고성능 검색기를 도입해도 해결하기 어려워집니다.

모델이 틀린 것처럼 보여도, 사실은 입력 문서가 망가져 있는 것입니다.

검색이 약한 것처럼 보여도, 사실은 chunking (청킹) 과정에서 문맥을 너무 많이 끊어버린 것입니다.

답변이 흐릿한 것처럼 보여도, 사실은 노이즈 chunk를 너무 많이 넣은 것입니다.

PageIndex의 가치는 바로 이 부분을 정면으로 다룬다는 데 있습니다.

RAG의 전처리는 단순한 데이터 정형화가 아닙니다.

후속 Agent가 어떻게 사고할지를 결정하는, 인지의 입구입니다.

PageIndex의 개념을 작게 시험해보고 싶다면, 처음부터 거대한 도구를 만들 필요는 없습니다.

하나의 긴 문서에 대해 다음 4가지만 만들면 됩니다.

document_summary
section_summaries
leaf_texts
...

그리고 Agent에게 다음과 같이 사용하게 합니다.

먼저 document_summary를 읽는다
관련 있어 보이는 section을 선택한다
필요하다면 leaf_text를 읽는다
...

이것만으로도 단순한 chunk 검색과는 다른 움직임을 보입니다.

여유가 더 있다면, 각 section summary에 구체적인 단서를 넣습니다.

용어
수치
날짜
...

이 부분이 부실하면 지도로서 사용할 수 없습니다.

PageIndex의 품질은 요약 (Summary)의 품질입니다.

긴 문서를 RAG에 넣을 때, 문제는 '어떤 chunk가 질문에 가까운가'만이 아닙니다.

어느 장을 봐야 하는가.

어느 표가 근거인가.

어느 페이지 범위에 답이 있을 것인가.

어떤 순서로 읽어야 하는가.

이것을 놓치면 RAG는 단편적인 조각들의 산을 읽을 뿐이 됩니다.

PageIndex는 문서를 산이 아니라 지도로 만드는 사고방식입니다.

Agentic RAG가 '부족하다면 다시 한번 찾는다'는 메커니즘이라면, PageIndex는 '다음에 어느 가지를 따라갈지'를 도와주는 메커니즘입니다.

다음 회차에서는 지금까지 만들어온 RAG를 어떻게 평가할지 살펴보겠습니다.

검색이 제대로 되고 있는가.

근거에 따르고 있는가.

노이즈로 인해 망가지지 않았는가.

실패를 어떻게 수집하고, 어떻게 수정할 것인가.

제6회에서는 평가와 실패 모드 (Failure Mode)를 다룹니다.

―― AI 미래 편집실 「AI 워치」