SpineDoc:RAG 该重新理解文档了

最近在小某书上看到一个 GitHub 项目，叫 SpineDoc。

点进去看，发现它项目规模不大，但问题抓得很准。

有时候，有意思的作品，不在于做得多大，而在于它先看到了什么。

传统 RAG

传统做检索增强生成(RAG)，习惯先把文档切碎。

切成 chunk，做 embedding，进向量库。

再去召回、重排、生成。

这套流程已经很熟了，问题也很明显：长文档一旦先被切碎，很多信息在第一步就已经丢了。

论文、手册、财报、规范，这些都不是普通文本，它们不是一句接一句平铺出来的。

它们有目录，有章节，有展开顺序，有上下位关系。

人看这类文档时，会天然借助这些结构，但很多 RAG 系统不会。

它们直接把文档当成一堆等待切分的文字，然后再想办法，从碎片里把答案拼回来。

SpineDoc

SpineDoc 最有意思的地方，是它先看结构。

它没有先把重点放在知识图谱或复杂推理上，而是先去恢复文档的目录、章节和层级关系，再在这个基础上做检索。

它提出了一个关键的问题：文档先是结构，之后才是内容。

很多系统处理文档时，常常先切碎，再检索，再补上下文。

SpineDoc 做的是另外一件事：切分之前，先尽量把文档的骨架找回来。

它不是不要 chunk，而是把 chunk 放回结构里。

这点对长文档尤其重要。因为长文档的难点，很多时候不只是理解，更是定位、回溯和路径还原。

某个方法在哪一章。

某个结论出现在第几页。

某一节到底在讲什么。

一段回答能不能回到原文。

这些问题的核心，往往不是知识本身，而是定位。先找对位置，比立刻读懂所有细节更重要。

核心

SpineDoc 当然还不算成熟产品，也谈不上定义行业方向。

但它有意思的地方，也不在这里。

它没有一上来追求把系统做得很重，也没有急着堆很多新概念。

它只是先抓住了一个经常被忽略的问题：长文档 RAG 的问题，很多时候不是模型不够强，而是文档结构没有被认真用起来。

这个思路不宏大。

但很实用。

SpineDoc vs PageIndex

如果把 SpineDoc 和PageIndex放在一起看，会更清楚一点。

因为两者都在讨论同一件事:

长文档检索，到底该不该从传统 chunking 开始？

PageIndex 做得很彻底：它不是只把树结构检索推前，而是在尝试用树索引 + 推理式检索，去替代传统的向量相似度路径。

SpineDoc 则更克制。它没有直接把原有流程推翻。而是在提醒大家：

先别急着切，先看看这份文档本来是怎么组织的。

评价

一个不夸张的评价是：SpineDoc 是一个有观察力的作品。

它至少说明，越来越多人开始意识到，旧路径在长文档上已经暴露出局限。

过去的文档 RAG，更像在文本堆里找相似句子。

未来的文档 RAG，应该要先理解文档是怎么展开的。

前者解决的是相似度。

后者解决的是结构感。

未来

RAG 接下来会越来越分化，不是所有内容都适合同一种检索方式：

网页有网页的逻辑。

代码有代码的逻辑。

表格有表格的逻辑。

长文档也一样。

它们不该永远被当成一堆等待切分的文字。而应该被当成一个有目录、有层级、有顺序的对象。

未来的文档 RAG，重点可能不只是语义。

还会越来越看重结构。

结尾

SpineDoc 值得看的地方，不是它有多成熟。

而是它把那个最基础、也最容易被忽略的问题，重新摆了出来。

文档，到底该怎么被理解？

项目地址：https://github.com/yjh2222332024/spine-open

推荐阅读：个人开发瞄准月入20万日元的思路