请教一下关于长上下文 RAG 检索，总结的最佳实践

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 84 天前的主题，其中的信息可能已经有所发展或是发生改变。

如果有一段很长的文档，包含以下内容

...以上省略若干段文字 ... abc 的指导思想如下： 一、要大力 xxxxxxx 二、要加强 xxxxxxx 三、要促进 xxxxxxx 四、要发挥 xxxxxxx 五、要改革 xxxxxxx 六、要总结 xxxxxxx 七、要克服 xxxxxxx ... ...以下省略若干段文字

依我去前写过的 rag demo 测试来看，在 chunking 阶段，按一定长度切开后向量化存储，那每个 chunk 向量之间已经没关联了，再使用关键字与每个 chunk embedding 后的向量得到最佳相似度的结果，比如：

提问：“促进 xxxx 的具体方案在哪里提出的？”，可能会匹配到包含"三、要促进 xxxxxxx"的 chunk ，但其它未包含相关关键字的结果就不在其中了。
提问：“abc 的指导思想是什么？”，也并不能得到全部的一~七的答案。

也搜索到了有一些优化方案（结合 ai ，可能有幻觉）：

其于语义切割：智能 chunk size ，大概就是不固定 chunk size ，而是一点点增加字符，并立即向量化，存储向量化结果至数组，当检测到添加的新向量和之前的差异超过一个阈值时，切开；
层次化切割（如 RAPTOR)：在以上基础上，对 chunk 进行聚类并生成摘要，在有必要的时候，可再对生成的摘要聚类形成摘要；未经测试，只依靠我的意想，"二、要加强 xxx" 也未必就一定和 "三、要促进 xxx"向量相近被聚类？（可能我举的例子不好，实际情况下，不一定都是以“要 xxx”开头）

其它方案：

GraphRAG：去年有试过，但是存在问题，对一篇长文太费 token ，而且慢；尝试使用本地模型（ qwen2.5:14b ）什么都跑不出来。
HippoRAG: 刚搜索到的，看其 github 各项指标均比 GraphRAG 好，未尝试

疑问：

这个需求是不是不适合用 RAG 来做，在上下文长度不够时，有其它方法吗？就算上下文够，llm 真的能在这么大的上下文中准确无误的提取？
使用 rag 的话，使用层次化切割这种方案看起来不错，比如：形成 abc 的指导思想 | | | 一、二、三、这种结构，检索时可以一层层由上向下展开，由下向上溯源。但是搜了相关 RAPTOR RAG github repo ，看 star 数并不理想（几十），故对这种方案的真实实用性存疑。
如果还涉及一些总结性的提问，关键词可能在原文未涉及，在检索这一步使用相似度比对得到相关向量结果肯定不理想，又有什么好的方案？

题外话： RagFlow: 未针以上场景测试过，但 docker 搭建玩了一下，忘了放着不管，大概 1 个月后竟然把磁盘写满了（有一个 1.5T 的报错日志，全是 redis 未连接上的）

rag

chunking

long context

3 条回复 2025-08-18 11:52:06 +08:00

coefu

84 天前

纯粹的文本切割 chunk 之后 ocr 是个效果一般的过渡路线产物，这条路线上无限优化也是差强人意的。主要还是图表文这种情况搞不好。

下一个路线是 VLM 对整个 doc/book/paper...做多模态的语义共享，对齐，融合。

Mithril

84 天前

chunk ，或者说 RAG 这些手段都只是为了解决 LLM 上下文长度有限的问题。你只要想办法把相关文档找出来就行了。

比如你觉得 embedding+chunk 效果可以，那就可以在文档分割成 chunk 的时候自己存个关联，命中 chunk 后带着同文档上下文相关的 chunk 就可以了。

或者更简单的，如果你每次输入的查询都很短，而且都是比较准确的，不需要语义相关性。那还不如直接做关键词查找。或者两者结合分配个权重。

zgqiu

84 天前

有几种优化的方案可以试下
1. 做标题增强，比如按点切分之后，把「 abc 的指导思想如下」分别加在下面每个分点的前面

2. 类似于层次切分的形式（ 1 ）层次分片，检索到子分片后，加入到 LLM 生成的时候使用的是包含更多内容的父分片（ 2 ）临近窗口的形式，检索到分片后，将前后临近的 N 个切片拼接成一个更大的上下文发给 LLM 。

RAPTOR 在切片之后还需要进行聚类和总结的生成，速度上会有点慢，之前实验的效果提升也不太明显。

可以在一定程度上解决，但是幻觉，检索效果不佳的还会继续存在