如何处理文档智能体中的聚合/计数问题？RAG 总是让我失望

我在构建基于文档的智能体时一直遇到这个问题，想了解其他人是如何解决的。RAG 是我们给智能体默认的文档工具，它在“查找/解释关于 X 的段落”这类任务上表现出色——答案存在于一个地方，检索就能找到。但用户实际提出的问题常常是针对整个集合的聚合查询：“有多少发票未付”、“今年向该客户开具的总金额”、“未来 90 天内哪些合同到期”。Top-k 检索在结构上无法回答这些问题： * 聚合需要对每条记录进行扫描；而检索只给智能体 k 个块。因此，它是在样本上计算答案，而不是在全量数据上。如果要对 1000 个文档求和，设置 k=10，它实际上只对其中 10 个求和——然后满怀信心地输出结果。 * 对于同类集合，排序本身毫无意义：1000 张发票与“未付总额”距离大致相等，因此返回哪 k 个基本上是随机的。 * 提高 k 并不能解决问题——要保证正确性，k 必须等于 N，即把整个语料库塞进上下文。这无法扩展，而且更大的模型也无法解决，因为瓶颈在于检索步骤，模型在看到数据之前就已经受到限制了。 我见过/尝试过的方法包括：(a) 通过函数调用实现 text-to-SQL 操作结构化表格，(b) 预先将字段提取到元数据存储中并对其进行查询，(c) 直接承认 RAG 不适合这类任务，将聚合意图路由到其他地方。 对于那些在生产环境中部署文档智能体的人：你们实际采用什么模式来处理计数/聚合？是先对查询意图进行分类再路由，还是找到了某种真正能处理聚合的检索方案？ （很抱歉文字是 AI 生成的，只是因为我英语容易出错。）