RAG系统意图识别技术解析与工程实践

1. 从面试惨案看RAG系统的致命盲区

上周一位学员的真实面试经历给我敲响了警钟。当面试官抛出"帮我算一下A款保险的理赔金额"这个看似简单的查询时，学员条件反射地给出了标准RAG处理流程：Embedding生成→向量检索→LLM生成回答。这个回答直接导致面试官脸色骤变——因为这暴露了当前大多数RAG系统存在的根本性缺陷：对所有查询类型无差别对待。

1.1 为什么通用检索链路会失效

在保险理赔场景中，用户查询至少包含五种截然不同的类型：

• 事实型查询（如"保障范围是什么"）：确实需要知识库检索
• 计算型查询（如"理赔金额计算"）：需要调用计算引擎
• 数据型查询（如"上月平均审批时长"）：需要NL2SQL转换
• 时效型查询（如"最新理赔流程"）：需要时间过滤检索
• 闲聊型查询（如"今天天气"）：应该直接拒绝响应

如果将所有查询都塞进同一条检索链路，就会出现"该算的不算、该滤的不滤"的荒诞场景。比如计算型查询检索回来的可能是政策条款文档，而用户需要的实际计算结果却永远无法获取。

1.2 意图识别的核心价值

通过分析10万条保险行业真实查询日志，我们发现：

• 计算型查询占比高达23%，但传统RAG对其处理准确率不足40%
• 包含时间约束的查询占31%，其中68%未正确应用时间过滤
• 错误路由导致的用户投诉占总投诉量的57%

这印证了面试官的质疑：没有意图识别的RAG系统就像没有交通灯的十字路口，所有车辆（查询）都挤在同一条车道上，必然造成混乱和事故。

2. 意图识别技术三重奏

2.1 规则引擎：快准狠的第一道防线

在金融领域，规则引擎始终是不可替代的首选方案。我们构建的关键词映射表采用多级分类策略：

python复制def classify_insurance_intent(query: str) -> str:
    # 第一级：业务领域识别
    domain_keywords = {
        "理赔": ["理赔", "赔偿", "报销"],
        "投保": ["投保", "购买", "续保"],
        "咨询": ["咨询", "了解", "请问"]
    }
    
    # 第二级：意图类型识别
    intent_keywords = {
        "计算求解": ["计算", "算一下", "多少钱", "怎么算", "共计"],
        "流程查询": ["流程", "步骤", "怎么办", "如何申请"],
        "条款解释": ["什么意思", "如何理解", "是否包含"],
        "进度查询": ["进度", "到哪了", "什么时候", "多久"]
    }
    
    # 业务领域判断
    for domain, keywords in domain_keywords.items():
        if any(kw in query for kw in keywords):
            # 意图类型判