청크리스 RAG란 무엇인가 — Docling과 AI 에이전트가 문서 구조를 따라 답을 찾는 방식 정리

핵심 메시지

• 일반적인 RAG는 문서를 500단어 단위 등으로 잘라 벡터로 바꾸고 질문과 비슷한 조각을 골라 넣는데, 자르는 순간 문서가 어떻게 구성됐는지가 버려진다.
• 제목이 그 아래 문단과 떨어지고 표가 표를 설명하는 문장과 분리되며, 답이 여러 절에 걸쳐 있으면 유사도 검색은 그 절들이 한 덩어리라는 사실을 알 수 없다.
• 청크리스 RAG는 문서를 트리로 유지하고, 짧은 요약이 붙은 목차를 본 에이전트가 답이 있을 법한 절을 추론해 그 절만 열어 읽는 방식이다.
• 트리를 걸어왔기 때문에 문단이 어느 절과 하위 절에 속하는지가 함께 따라오고, 정의가 있는 절과 근거가 있는 절이 떨어져 있어도 오가며 답을 맞출 수 있다.
• PDF에는 걸어갈 구조가 없기 때문에, Docling이 절·제목·읽기 순서·표를 복원한 문서 객체를 만들어 줘야 이 방식이 성립한다.

쉽게 이해하기

200쪽짜리 연차 보고서를 모델에게 주고 '올해 수익 인식 정책에서 무엇이 바뀌었고 보고서 어디에서 그 이유를 설명하는가'를 묻는다고 해봅시다. 문서를 아는 사람이라면 해당 절을 펼쳐 읽고 2분이면 답합니다. 그런데 기계가 같은 질문에 답하는 통상적인 방식은, 사람이라면 문제를 쉽게 만드는 데 썼을 바로 그 정보를 버리는 데서 시작합니다.

통상적인 방식은 검색 증강 생성, 즉 RAG입니다. 문서를 500단어나 문단 단위로 잘라 각 조각을 벡터로 만들어 저장해 두고, 질문이 들어오면 질문도 벡터로 바꿔 가장 비슷해 보이는 조각 몇 개를 꺼내 모델의 문맥에 넣습니다. 값싸고 유용하며 많은 질문에는 이것으로 충분합니다. 문제는 크고 구조가 있는 문서 하나가 들어올 때입니다. 자르는 순간 제목은 그것이 소개하던 문단들과 떨어지고, 표는 그 표가 무엇을 뜻하는지 말해 주는 문장에서 분리됩니다. 답이 여러 절에 걸쳐 있으면 유사도 검색은 그 절들이 서로 속해 있다는 사실을 알 길이 없고, 모델은 조각들이 어떻게 이어지는지 추측해야 합니다.

하지만 그 문서는 애초에 텍스트 더미가 아니었습니다. 제목이 있고 헤더가 있고 절과 하위 절, 문단, 표, 이미지가 트리 아래에 놓여 있습니다. 저자가 이미 정보를 정리해 둔 것입니다. 청킹은 그 트리를 평평하게 만들어 유사도 검색을 가능하게 하지만, 그 과정에서 구조를 부수고 나서 바로 거기에 있던 관계를 다시 복원하느라 훨씬 많은 힘을 씁니다. 그래서 대안은 단순합니다. 트리를 그대로 두고, 유사도 매칭 대신 모델이 스스로 알맞은 자리까지 추론해 가게 하는 것입니다.

사람이 그 수익 인식 질문에 답하는 방식이 곧 설계도입니다. 200쪽을 다 읽지 않고 목차를 열어 회계 정책 절을 찾아 펼치고, 필요하면 각주 참조를 따라갑니다. 에이전트도 같은 일을 합니다. 각 절에 짧은 요약이 붙은 트리 개요에서 본문을 읽지 않고도 문서의 모양을 파악하고, 답이 있을 법한 절을 골라 그것만 열어 읽습니다. 충분하면 답하고, 부족하면 다음 절을 골라 몇 단계씩 이어 갑니다. 여기서 두 가지가 따라옵니다. 문단을 읽는 동안에도 그것이 어느 절과 하위 절에 속하는지가 경로로 남아 문맥이 공짜로 딸려 오고, 문서 전체에 걸친 질문에도 다른 가지로 갔다가 제자리로 돌아올 수 있습니다.

이 모든 것은 트리가 실제로 있어야 성립합니다. 그런데 대부분의 문서는 PDF로 들어오고, PDF는 사실상 문자와 도형을 페이지에 배치하라는 지시문이라 걸어갈 구조가 없습니다. 이 일을 하는 것이 Docling입니다. PDF를 넣으면 실제 절과 제목, 보존된 읽기 순서, 여전히 표인 표를 갖춘 Docling 문서를 돌려주고, 그 구조 위에서 쓰고 편집하고 필드를 추출하고 절을 보강하는 에이전트를 함께 제공합니다. 프로젝트는 이 방식을 청크리스 RAG라 부릅니다. 목표는 여느 검색과 같지만, 잘라서 유사도로 맞추는 대신 문서 구조를 추론해 근거에 도달한다는 점이 다릅니다.

주요 인사이트

• 핵심 문제는 검색 기술이 아니라, 저자가 이미 그려 둔 지도를 스스로 버린 뒤 그 관계를 다시 찾느라 힘을 쓰는 구조에 있다.
• 에이전트가 트리를 걸으면 총 작업량이 줄지는 않는다. 달라지는 것은 마지막에 모델 앞에 놓이는 재료의 질로, 제목이 붙은 채로 관련 절 하나가 올라온다.
• 진짜 병목은 파싱이다. 현실의 문서를 깨끗한 구조로 만드는 일이 어렵고, 엔지니어링의 대부분이 여기에 들어간다.
• 구조를 따라가는 방식은 단일 벡터 조회보다 모델과 주고받는 왕복이 많아 지연 시간과 호출 수가 늘어난다.
• 수백만 건의 문서에서 'X에 대한 아무거나'를 찾는 질문이라면 유사도 검색이 여전히 강하다. 실제 시스템에서는 유사도로 문서를 찾고 구조로 그 안을 항해하는 식으로 둘을 함께 쓰게 된다.

자주 묻는 질문

관련 AI 소식