意图识别在 RAG 中怎么用?

这道题其实问的是，在[[RAG]]系统里，怎么让机器在动手检索之前先搞明白用户到底想要什么，而不是直接盲搜。我的理解是，意图识别扮演的是路由中枢的角色，它决定了后续用哪种检索方式、怎么改写查询，甚至影响生成阶段的策略。

具体说一下检索准确性这块。不同意图得匹配不同检索方式：事实类问价格、日期这种，用关键词或 [[BM25]] 最准，语义类像“帮我分析一下趋势”，向量检索更合适。真正落地的场景，比如电商客服里用户问“这个产品的退款周期是多久”，意图识别得先判断这是事实查询，然后自动补全产品名，避免向量检索搜到一堆相似但无关的文档。再一个，多跳意图比如“A和B哪个性价比更高”，系统得拆成两个子查询分别检索，再合并结果。如果只用一个向量检索，很容易语义漂移，召回一堆不相关的。

生成质量方面，意图识别能帮我过滤检索结果。比如用户问“有什么优缺点”，我优先保留带对比性的文本，而不是一堆基础介绍。Prompt路由也靠它：闲聊场景用宽松的[[System Prompt]]，专业问答得严格引用。还有[[幻觉]]防控，如果意图明显超出知识库范围，比如问“明年双十一满减政策”，系统得直接拒答或触发联网搜索，而不是瞎编。

这里有个坑，就是意图识别的精度和召回怎么平衡。如果分类太粗，比如所有问题都走向量检索，召回率可能高但精确度差，生成时容易引入噪音。如果分类太细，模型又可能过拟合，复杂意图识别不准。常见失败场景是用户用口语化表达，比如“这玩意儿咋退”，意图识别可能判成闲聊而不是退款咨询，导致检索错误。所以前提是训练数据要覆盖足够多的真实用户Query变体，不然上线后效果会崩。

所以我会更倾向用轻量级模型比如BERT做初分，快速过滤掉明显无关的查询，再对大模型拿不准的复杂意图做二次确认。这样既能保证速度，又能处理模糊场景。不过这里有个延伸点，就是当意图识别和外部工具联动时，比如识别到“查库存”意图后触发 [[Function Calling]]，怎么保证调用链路的可靠性和延迟，这个在实际工程里挺有挑战的。

总的来说，我把意图识别看成RAG系统的守门员，它做得好，检索和生成才能事半功倍。