Agent+RAG做复杂问答时，上下文总被截断，有什么好的策略吗？

先按问题相关性给chunk打分再重排，只留top几段，比硬截断强多了。

这个问题其实挺典型的，我们之前做多轮知识库Agent时也踩过。后来比较有效的做法是把检索和生成拆开，检索阶段多召回一些，比如top_k拉到20，然后用一个轻量rerank模型精排到5-8条，再进prompt。但关键不在这儿，关键是别把所有chunk原封不动塞进去，每个chunk先做一次query-aware的压缩，只保留和当前问题相关的句子，这样能砍掉一大半token。另外多轮追问时，历史对话别全留，用个滑动窗口加摘要，把早期轮次压成一句背景。还有个坑是chunk本身切得太碎或太大，切法对上下文影响很大，最好按语义切而不是固定长度。真要工程化，我建议加一层“上下文预算管理器”，动态决定每轮给检索结果多少token、给历史多少token。你们现在用的是哪个rerank和压缩方案？

我也踩过这个坑，后来改成先把召回结果按文档来源分组，每组让模型压成两三句话的要点，再拼进上下文，token一下就下来了。另外重排真的不能省，用cross-encoder过一遍top50再取前几，比单纯调阈值靠谱多了。多轮追问的话，可以把历史对话也做滚动摘要，别一股脑全塞回去。

我也踩过这个坑，后来发现光调top_k真没用。现在我的做法是检索后先做一轮rerank，只留最相关的三五条，再用一个小模型对每条chunk做定向摘要，只抽跟当前问题相关的句子。这样喂给Agent的上下文能压到原来的三分之一左右，信息还基本不丢。另外追问场景我会把历史对话也做压缩，不然多轮下来照样爆。你可以试试LangGraph里加个context trimming节点，挺顺手的。

先做重排再摘要，别一股脑塞，检索阶段就得控量。

这问题太真实了，我上个月刚踩过一模一样的坑。我的做法是把检索和生成拆开，检索阶段先多召回一些，然后加个轻量级的重排模型（比如bge-reranker）把最相关的压到3-5个chunk，再进prompt。但光靠重排还不够，追问场景下历史对话也会吃掉大量token，所以我会对历史做滚动摘要，只保留最近两三轮原文加上之前对话的摘要。另外有个技巧是别把chunk当整体塞，而是先按句子或小段落切细，重排后只取每个chunk里得分最高的那两三句，这样信息密度高很多。至于先摘要再喂给Agent，我试过，摘要模型本身可能丢关键细节，而且多一次调用延迟也上去了，不太适合实时问答。比较工程化的思路我觉得是分层过滤：粗召回→重排→句子级裁剪→必要时再压缩，每一步都设个token预算上限。你们现在用的LangGraph里有没有试过用conditional edge做动态裁剪？那个配合状态管理还挺顺手的。

我一般先做重排再按段落摘要压缩，最后只留最相关的两三段喂给模型，效果比硬截断稳多了。