最近在做一个知识库问答的Agent,用的LangGraph+RAG。简单单轮问答效果还行,但一旦用户连续追问,或者问题本身涉及多个文档片段,我就发现一个问题:检索回来的chunk太多,塞进prompt里经常超token限制,只能硬截断,结果模型回答就缺胳膊少腿的。我自己试过调top_k和相似度阈值,但要么漏信息,要么还是太长。想问问大家,在实际项目里是怎么处理这种“检索结果太多但上下文窗口有限”的矛盾的?是有什么高级的压缩/重排策略,还是说应该把检索结果先做个摘要再喂给Agent?求一个比较工程化的思路,别光讲理论,谢谢了。
楼主
2026-08-12
Agent+RAG做复杂问答时,上下文总被截断,有什么好的策略吗?
请 登录 后发表回复
全部回复
共 62 条
2楼
2天前
先按问题相关性给chunk打分再重排,只留top几段,比硬截断强多了。
3楼
9小时前
这个问题其实挺典型的,我们之前做多轮知识库Agent时也踩过。后来比较有效的做法是把检索和生成拆开,检索阶段多召回一些,比如top_k拉到20,然后用一个轻量rerank模型精排到5-8条,再进prompt。但关键不在这儿,关键是别把所有chunk原封不动塞进去,每个chunk先做一次query-aware的压缩,只保留和当前问题相关的句子,这样能砍掉一大半token。另外多轮追问时,历史对话别全留,用个滑动窗口加摘要,把早期轮次压成一句背景。还有个坑是chunk本身切得太碎或太大,切法对上下文影响很大,最好按语义切而不是固定长度。真要工程化,我建议加一层“上下文预算管理器”,动态决定每轮给检索结果多少token、给历史多少token。你们现在用的是哪个rerank和压缩方案?