RAG多轮对话常因上下文指代不明而失效，直接将残缺查询送入检索，系统无法理解。内容深入剖析了代词消解的挑战，并系统性地展示了一套包含查询改写、风控闸门与过程监控的完整解决方案，确保对话系统更精准、更可靠。
智能速览
多轮对话中的代词指代是RAG系统常见的失效点。
可利用大模型将残缺查询改写为语义完整的句子。
必须设置风控闸门，校验改写前后的语义一致性与实体完整性。
采用双路检索策略，用改写和原始查询同时搜索，实现兜底。
通过监控无结果率等指标，能判断改写模型是否在做负优化。
精华内容
RAG多轮对话中，如何处理“它在哪”这类残缺查询？直接检索必然失败。核心在于先利用LLM进行查询改写，但紧接着要防范AI改写可能带来的错误传播风险。
代词消解难题
在RAG多轮对话中，用户后续提问常包含代词，如“它适合穿什么”，直接检索无法理解。为解决此问题，架构上引入查询改写引擎。该模块利用大语言模型（LLM），结合对话历史上下文，将残缺的查询补全为完整、可检索的语句。例如，当历史记录包含“杭州明天天气”时，“它适合穿什么”会被精准改写为“杭州明天的天气适合穿什么”，为后续精准检索打下基础。
风控闸门设计
然而，盲目信任LLM改写存在巨大风险，一旦模型出错将导致错误传播。因此，必须设立风控闸门进行校验。第一层检查是语义相似度计算，确保改写前后查询核心意思未发生偏移。第二层是实体完整性检查，核对原句中的人名、地名等关键实体在改写后是否被保留或错误替换。任一检查未通过，系统将触发Fallback机制，宁可舍弃改写结果，也不能传播错误答案。
双路检索与监控
为确保检索的全面性，系统采用双路检索策略。主路使用改写后的高质量查询进行精准检索，同时，备用路也会使用原始查询进行兜底搜索，以防改写模型意外删除关键信息。上线后，监控至关重要。除了常规指标，需重点关注改写后查询的“无结果率”。如果该指标异常升高，往往意味着改写模型过度优化，添加了数据库中不存在的限定条件，说明模型可能在做负优化，需要立即调整。
构建高可用的RAG多轮对话系统，关键在于不能只依赖单一的LLM改写。通过引入“还原-阻断-监控”的闭环体系，才能在享受LLM强大能力的同时，有效控制其不确定性。除了文中的方法，还有哪些创新思路能进一步提升系统的鲁棒性？
