“那这一款呢？”怎么回答：企业 RAG 的多轮追问与对象确认

原始消息保留用户说过什么，状态记录当前任务已经确认的条件。例如商品标识、租期、地区、业务日期和未解决问题。每项状态都能追溯到用户消息或权威资料，不把模型自己的猜测写成已确认值。

状态无需塞进完整对话历史。可以保留小而明确的结构，并在需要时读取证据。Anthropic 的上下文工程文章讨论按需获取信息与维护上下文，本文将它用于业务追问，是本站设计。

“那三天呢”在不同前文里含义不同。可以在上下文明晰时改写为明确查询，涉及报价或执行则补齐影响结果的条件。对象切换后，清理原对象专属字段，例如单价、型号规格和适用例外。

可以把当前状态写成一条简短记录：商品 E100 已确认；租期三天由用户提出；地区尚未确认；当前只在咨询，没有发送或下单授权。用户说“换成 Pro”后，商品先变成待确认候选，原 E100 单价失效，三天租期是否继续适用由对话含义确认，地区仍保持未知。新检索只围绕确认后的对象展开。每次改变保存来源消息和时间，后续摘要不得把“待确认”压缩成“已确认”。这份记录不是业务执行凭证；当咨询转成报价或下单，还要重新检查关键条件与用户授权。

测试时让用户先纠正型号，再纠正租期，检查两次修改是否都生效。状态表中失效值可以留审计历史，但不能继续进入新查询或新草稿。

重写后的问题应包含当前已确认对象、用户想了解的属性和明确条件。保存原问题与重写问题，便于查出重写是否改变了意图。

不要把“这款能送吗”改写成“E100 可以免费送到北京吗”，除非这些条件已经得到确认。添加的免费、地区或型号会引导检索找到看似相关、实际不适用的资料。

Microsoft 的 RAG 文档介绍利用对话上下文规划查询和处理追问。具体产品功能与实现方式不同，这里强调的是重写前后意图可核对，不能把自动规划当成业务条件已确定。

上轮回答可能错误、过期或基于另一对象。新一轮需要当前依据时，重新读取获授权的资料，而不是引用上轮模型结论证明自己。历史回答可以帮助理解用户在讨论什么，但证据仍来自来源资料或业务系统。

对于稳定的文档可以使用受控缓存，但缓存要检查对象、版本和当前权限。价格、库存和余额等变动信息可能需要重新查询，不能沿用对话开始时的值。

对话持续很久时，明确已经确认的条件与待确认项。用户取消后重新开始，旧任务授权、草稿和未执行动作不要默认继续使用。

用户上一轮能查看某合同，不意味着权限撤销后仍能检索或下载。状态里保存的对象标识不能替代授权。服务端按当前身份与业务范围检查检索和引用。

对“给我看另一部门那份”这样的请求，先确认是否有权访问，不让查询重写扩大范围。无权内容不能通过旧会话摘要、缓存或工具错误信息泄露。

任务从咨询转为执行时，再检查当前内容、目标对象与权限。早先讨论过一个收件人，并不代表用户已经授权发送现在这份内容。

保存每轮输入、状态、重写查询、返回证据和结果。只测单轮问题无法发现状态污染；只检查最后答复，也可能漏掉中途越权检索。

选一次“回答成另一款”的失败对话，查对象是在状态更新、查询重写、检索还是生成阶段被替换。修复相应位置，用相似型号和用户纠正的样本回归。

这套方法适合客服、商品和制度问答。高影响业务动作需要更明确的确认步骤；并非所有追问都必须反问，但影响结果的对象或条件不明时，应宁可澄清也不把猜测当事实。