최근 중국 AI 개발자 커뮤니티에서 이 이야기가 나왔습니다. IBM이 ‘Chunkless RAG’라는 것을 홍보하고 있는데, 이는 표준적인 문서-청크-임베딩 파이프라인 대신, AI 에이전트가 인간 독자가 문서를 탐색하는 방식처럼 문서 구조를 따라 이동한다는 것입니다. Docling 같은 도구는 PDF를 헤더, 테이블, 섹션 계층 구조 등을 보존하는 구조화된 표현으로 구문 분석하고, 이후 에이전트는 잘게 쪼갠 텍스트에 코사인 유사도를 적용하는 대신 그 구조를 따라가며 관련 콘텐츠를 찾습니다.

이 제안은 매력적입니다. 밀도 높은 기술 사양의 중간 부분에서 세 개의 조각(fragment)을 자신 있게 반환하지만, 이 조각들 각각이 주변 섹션 없이는 구조적으로 의미가 없는 경우를 본 사람이라면 누구나 고정 크기 청킹(fixed-size chunking)이 해결된 문제가 아님을 알고 있습니다. 따라서 표면적으로 볼 때, 이것은 진전처럼 들립니다.

하지만 저는 문서 구조가 청킹이 파괴하는 진짜 문제라는 핵심 주장이 과대 포장되었다고 생각합니다.

구조에 대한 주장은 문서가 구조를 가지고 있다는 것을 가정한다

실제 운영 코퍼스(production corpora)는 IBM의 데모가 보여주는 것보다 훨씬 지저분합니다. 헤더 계층 구조가 일관적이지 않은 법률 계약서. Docling의 레이아웃 파서가 자신 있게 쓰레기를 반환하는 스캔된 PDF. 누군가가 전체 제품 사양을 하나의 거대한 테이블에 넣기로 결정한 내부 위키. 지원 티켓 내보내기 파일. Slack 내보내기 덤프. 이메일 스레드.

이러한 경우, 청크리스 접근 방식이 명확하게 우위를 점한다고 보기 어렵습니다. 만약 파서가 의미 있는 문서 트리를 신뢰성 있게 추출할 수 없다면, 그 트리를 탐색하는 에이전트는 추가적인 지연 시간만 발생시키는 노이즈를 순회하고 있을 뿐입니다. 당신은 한 가지 실패 모드(임의 분할로 인한 맥락 손실)를 또 다른 실패 모드(잘못된 파서로 인한 환각 구조)로 대체했을 뿐입니다. 후자는 시스템이 문서를 이해한 것처럼 보이기 때문에 감지하기가 더 어려울 수 있습니다.

고정 크기 청킹(Fixed-size chunking)에 오버랩을 주는 것이 멍청한 방법인 것은 맞습니다. 하지만 그 실패 모드는 예측 가능합니다. 측정할 수 있습니다. 검색 벤치마크를 기준으로 청크 크기와 오버랩을 조정하면서 숫자가 변하는 것을 지켜볼 수 있습니다. 에이전트 네비게이션 접근 방식은 오프라인 평가에서 표면화하기가 훨씬 어려운 실패 모드를 가지고 있습니다.

실제 병목 현상은 보통 잘리는 곳에 있지 않다

제가 논의하거나 문서화된 대부분의 파이프라인에서, 검색 정밀도 문제는 청크가 구조적 맥락을 잃는 것이 주된 원인이 아닙니다. 근본적으로는 쿼리(query)와 관련 구절(relevant passage)이 충분한 어휘적 또는 의미론적 중첩을 공유하지 못해서 검색 자체가 작동하지 않는 경우입니다. 이는 특히 답변에 쿼리와 의미론적으로 거리가 먼 섹션들의 정보를 종합해야 하는 다단계 질문(multi-hop questions)에서 두드러지게 나타납니다.

청크리스 RAG(Chunkless RAG)와 에이전트 네비게이션은 이를 명확하게 해결하지 못합니다. 오히려 상황을 악화시킬 수도 있습니다. 왜냐하면 에이전트는 여전히 어떤 섹션으로 먼저 이동할지 결정해야 하고, 그 결정 과정 자체가 내부적으로는 검색 또는 분류(classification) 문제이기 때문입니다. 단지 어려운 부분을 한 단계 위로 옮기고 그 위에 에이전트 호출 오버헤드만 추가한 것일 뿐입니다.

실제로 이 문제를 개선하는 것처럼 보이는 접근 방식들은 HyDE(가상 문서 임베딩, hypothetical document embeddings), 프롬프트 변형을 통한 쿼리 확장(query expansion through prompt mutation), 또는 BM25와 밀집 벡터(dense vectors)를 혼합한 하이브리드 검색 등입니다. 원본 게시물의 한 댓글 작성자는 MinerU 파싱과 BM25 및 프롬프트 변형을 결합하여 좋은 결과를 얻는 Knowhere라는 프로젝트에 대해 언급했습니다. 이 조합은 문서를 그래프로 보존하는 것에 관한 것이 아니라, 쿼리의 의도와 검색된 콘텐츠 간의 일치도를 개선하는 것에 관한 것입니다.

청크리스 RAG가 아마 좋을 수 있는 경우

이 모든 것이 이 아이디어가 어디에서나 틀렸다는 것을 의미하지는 않습니다. 아마도 승리할 수 있는 실제 사용 사례가 있습니다. 바로 사용자 질문이 문서의 특정 섹션과 명확하게 매핑되는, 길고 잘 구조화된 기술 문서입니다. API 레퍼런스 문서, 일관된 섹션 번호가 지정된 규제 제출 서류, 표준 IMRaD 구조를 가진 학술 논문 등이 그렇습니다. 이러한 경우, '데이터 준비 방법론이란 무엇인가'에 대한 답이 2.2 섹션에 있다는 것을 알고 그곳으로 직접 이동하는 것이, 임베딩 공간이 질문과 해당 섹션을 충분히 가깝게 배치해 주기를 바라는 것보다 진정으로 더 좋습니다.

원래 게시물에서 법률 기술(legaltech) 관련 댓글을 단 사용자는 자신의 팀이 정확히 이러한 종류의 시스템을 구축하고 있다고 언급했으며, 구조화된 법률 문서의 경우 구조적 탐색이라는 주장이 더욱 설득력이 있습니다.

하지만 이것은 '청킹이 RAG에 적합하지 않은 기본 원리(primitive)'라는 주장보다 더 좁은 범위의 주장입니다. 이는 오히려 '잘 구조화된 문서를 위해서는 구조 인지 검색(structure-aware retrieval)이 평면적인 청킹(flat chunking)보다 우수하다'는 주장에 가깝습니다. 이 후자는 훨씬 놀랍지도 않고, 훨씬 혁명적이지도 않습니다.

프레이밍 자체가 기술보다 더 거슬린다

더 큰 문제는 '청크리스 RAG(Chunkless RAG)'라는 브랜드가 사람들에게 자신의 청킹 전략을 파이프라인의 핵심 실패 원인으로 생각하도록 부추긴다는 점입니다. 하지만 대부분의 프로덕션 시스템에서 그렇지 않습니다. 이질적인 코퍼스(heterogeneous corpora)에서 재현율(recall) 문제로 어려움을 겪는 개발자들은 이것을 읽고, Docling 통합과 에이전트 탐색 계층 구축에 2주를 소비한 후, 문제가 청크 경계 자체가 아니었기 때문에 자신들의 벤치마크 수치가 거의 움직이지 않았다는 것을 발견하게 될 것입니다.

유용한 질문은 '청킹을 해야 할까 말까?'가 아닙니다. 그것은 '내 파이프라인이 정확히 어디서 정보를 잃고 있으며, 그 특정 실패 모드에 대한 가장 저렴한 해결책은 무엇인가?'입니다. 때로는 더 나은 청킹일 수 있습니다. 때로는 리랭커(reranker)일 수 있습니다. 때로는 쿼리 재작성(query rewriting)일 수 있습니다. 때로는 소스 문서가 어떤 검색 전략으로도 사전 처리 투자가 없으면 잘 작동하기에는 너무 형편없이 구조화되어 있다는 것을 받아들이는 것일 수도 있습니다.

청크리스 RAG는 문서 파서가 개선됨에 따라 주목할 만한 실제 방향입니다. 하지만 문서 구조 탐색을 청킹(chunking)의 후계자로 취급하기보다는 여러 유용한 기술 중 하나로 간주해야 할 것 같습니다. 그렇지 않으면 많은 엔지니어를 잘못된 길로 이끌게 될 것입니다.

만약 복잡한 실제 코퍼스에서 구조 인식 에이전트 검색과 잘 조정된 청크 기반 검색을 직접 비교해 보셨다면, 실제로 수치상으로 어떤 결과를 보셨나요?