RAG系统里文档切得太碎，Agent调用时上下文总丢怎么办？

我们团队也踩过这个坑，512确实太激进了。后来我们改成按文档原有章节或语义段落来切，不强求固定token数，再配合一个小的摘要索引，这样Agent能先定位到哪个章节有答案，再取整段内容。另外你提到的多轮检索，我们试过让Agent先发个粗粒度查询拿回候选段落，再根据这些段落补一个细粒度查询，上下文丢失的情况少了很多。切块粒度真不是越大越好，核心是让每个chunk自带足够上下文线索，必要时可以在切块时把标题和前后文摘要拼进去。

试试父子分块加个摘要索引，先粗检后精读，上下文和精度都能保住。

说实话你这问题我太有共鸣了，之前做内部知识库Agent时也被512切块坑惨过，后来发现压根不是chunk size的锅，而是检索策略太单一。我现在用的办法是双路召回，小段落（256-512）用来做精确匹配找证据，同时按文档的标题层级把大章节（比如整个配置流程那块）也塞进索引，Agent需要完整上下文时直接去调大块内容。另外你提到“多轮检索”，我试下来最有效的是让Agent先根据用户问题拆出几个子问题，分别去检索再拼接，而不是指望一次top-k就能拿全。还有个小技巧，把文档里那些“步骤1、步骤2”或者“首先、然后”这类序列词做成元数据标签，检索时优先匹配带这种结构标记的块，上下文断裂的概率会低很多。不过说实话，如果文档本身有清晰的Markdown结构，直接按标题递归切分比固定token数靠谱得多，你可以试试用unstructured库按语义边界切，配合一个重排序模型，精度和完整性都能兼顾。

我踩过类似的坑，后来改成按标题层级切，再给每个chunk补一句所属章节路径，效果好了不少。检索时可以先把相邻块一起召回，让模型自己判断要不要用，别一开始就把上下文掐断。另外小chunk检索、大chunk喂给Agent这种两段式也挺常见，你可以试试。

我也踩过这个坑，512确实太碎了，后来改成按标题层级切，每个chunk带上父级标题路径，效果好了不少。另外可以试试小块检索、大块喂给模型，就是命中的小块往外扩一圈拼成完整段落再塞进上下文。还有个思路是让Agent在检索时做多轮query改写，第一轮找不到就换个说法再搜一次，别让它一次没中就硬编。

我们也踩过这个坑，后来改成先按文档标题层级粗切，再用小窗口细切，检索时把父级标题和相邻块一起塞给模型。关键不是单块多大，而是让Agent能拿到“这一段属于哪一节”的路径信息。另外可以试试让检索返回top3块后再做一次重排，把跨段落的上下文拼回去，比单纯调chunk size管用。

可以试试小块检索大块召回，命中后把相邻块一起塞给模型，能补回不少上下文。

可以试试小块检索、大块喂给Agent，就是先精准命中再往回扩上下文。我这边用父子块效果还行，你可以参考下。

我去年也踩过这个坑，后来改成小块检索、大块喂给模型的两段式，就是先用512的小块做召回，命中后再把相邻块或者所属章节一起拉出来拼上下文。效果比单纯加大chunk好不少，尤其是配置步骤这种跨段的内容。另外你可以试试按标题层级切，让每个块带上父级路径，Agent拿到的时候就知道自己在文档哪一块。不过多轮检索也要控制好轮数，不然token烧得飞快。

这个问题我前段时间也踩过坑，感觉核心矛盾在于你用的是固定长度切块，但语义边界根本不是均匀分布的。512 token切出来经常把一段完整逻辑拦腰截断，检索的时候向量只匹配到半截信息，Agent自然拼不出全貌。我后来改成先按标题层级做粗切，再在段落内部按句子边界细分，每个chunk带上父级标题路径作为元数据，检索时把同一父节点的相邻块一起召回，效果好了不少。另外你可以试试在Agent那层加一个“回溯原文”的工具，让它发现信息不完整时主动去拉取相邻chunk，而不是硬编。还有个思路是用small-to-big，就是索引时用小块做向量匹配，但返回给LLM的是它所属的大块或整节内容，这样精度和完整性都能兼顾。多轮检索也确实有用，第一轮先定位到相关章节，第二轮再在那个范围内做细粒度搜索，相当于模拟人翻文档的过程。不过这些方案都会增加延迟和token消耗，得看你们业务能接受什么程度。

试试父子块检索，小块召回大块喂给Agent，上下文就不断了。

这个思路不错，收藏了。