用户在你们系统里输入'帮我算一下 A 款保险的理赔金额'，你的系统怎么处理的

P1 · rag · 🏢 字节

🏷 标签：intent_recognition, query_routing, rag, financial_domain

1️⃣ 考察意图

面试官想看你是否具备系统级设计思维，而非只会套 RAG 模板。这道题是典型的工程取舍 + 系统设计类型，刁钻点在于：用户 query 表面是“问问题”，实际是“要计算”。如果你直接走检索-生成链路，就是灾难——检索出条款文本，LLM 硬算理赔金额，结果既不准又不可控。答好了能展示你对意图识别、查询路由、工具调用的实战理解，以及金融场景下安全性与可解释性的落地能力。

2️⃣ 标准答

系统不会一刀切走 RAG，而是先做意图识别与查询路由，再分派到不同处理模块。具体流程分四步：

**Step 1：意图识别（Intent Classification）**用轻量级分类模型（如 BERT-base 微调，或直接用 LLM 做 few-shot 分类）判断 query 类型。常见类别：计算型、事实型（如“理赔需要什么材料”）、操作型（如“我要报案”）、闲聊型。
对“帮我算一下 A 款保险的理赔金额”，模型应输出 计算型。关键 trade-off：用 LLM 做分类更灵活但延迟高、成本高；用小模型（<100M 参数）速度快但需要维护类别样本。生产环境通常两者结合——小模型兜底 80% 常见 query，LLM 处理边缘 case。
实际坑：用户可能说“算算 A 款能赔多少”，这是计算型；但“A 款保险怎么赔”是事实型。需要设计正则 + 语义双保险，比如检测“算/计算/多少/金额”等触发词，同时用模型判断。 Step 2：参数提取（Slot Filling）
对计算型 query，提取关键数值参数：保险产品 ID（A 款）、保额、免赔额、赔付比例、事故类型（如医疗/意外）。用命名实体识别（NER） 或LLM 结构化输出（如 function calling）完成。
例如：用户没说保额，需要从用户画像或保单数据库拉取。工程取舍：参数不全时，是反问用户还是用默认值？金融场景必须反问，避免默认值导致理赔纠纷。 Step 3：路由到计算模块
不碰向量库。直接调用预定义计算函数（如 calculate_claim(premium, deductible, ratio, accident_type)），函数内封装保险精算规则（如“医疗险免赔额 1 万，超出部分 100% 赔付”）。
如果规则复杂（如多险种叠加），可以让 LLM 做数学推理，但必须限制在沙箱环境，输出 JSON 格式结果，再由后端校验。为什么这么做：避免 LLM 幻觉编造赔付公式，金融场景可解释性优先于灵活性。 Step 4：结果生成与校验
计算模块返回数值（如“理赔金额为 8500 元”），系统再包装成自然语言回复。实际落地的坑：用户可能问“A 款和 B 款哪个赔得多”，这是比较型计算，需要并行调用两个计算函数，再让 LLM 对比输出。系统必须支持多路并发路由。

总结：核心是先分类，再路由，计算不走检索。整个链路依赖一个意图识别模型 + 规则引擎的混合架构，生产环境用 Apache Flink 或自研调度框架做实时路由。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从意图识别、参数提取、计算路由三个层面回答。首先，系统不会直接走 RAG 检索，而是用意图分类模型判断 query 是计算型；然后，通过 NER 或 function calling 提取保额、免赔额等参数；最后，路由到预定义计算函数或 LLM 数学推理模块，输出结果。总结一句：计算型 query 的核心是参数驱动，不是文档驱动。”

4️⃣ 高频追问 & 应对

追问 1：如果用户说“帮我算一下理赔金额”，但没指定哪款保险，你怎么处理？

这是参数缺失的典型 case。系统会先做实体识别，发现“产品 ID”字段为空，则触发反问策略：返回“请问您指的是哪款保险？A 款还是 B 款？”同时，可以结合用户历史对话或保单列表做主动推荐（如“您最近咨询过 A 款，是否计算 A 款？”）。工程取舍：不要用 LLM 猜默认值，金融场景猜错就是合规事故。

追问 2：如果计算规则特别复杂，比如涉及医保报销、自费药比例，预定义函数写不过来怎么办？

采用混合方案：预定义函数处理核心公式（如免赔额、赔付比例），复杂逻辑（如医保目录匹配）交给 LLM 做结构化推理。具体做法：让 LLM 输出中间步骤（如“医保报销 60%，自费药 2000 元不计入”），再由后端规则引擎校验每个步骤的数值范围。关键点：LLM 只做推理，不做最终计算，防止幻觉。

追问 3：意图识别模型误判了，把计算型 query 当成事实型，走 RAG 检索了，怎么兜底？

设计后校验机制：检索结果返回后，用正则检测是否包含数值计算关键词（如“金额”“赔付”），如果命中但结果无数值，则触发二次路由。同时，在日志中记录误判 case，用于模型迭代。实际坑：不要完全依赖模型，规则引擎作为最后一道防线，比如“如果 query 包含‘算’字且无检索结果，强制走计算模块”。

5️⃣ 避坑 · 常见错误答法

❌ “先做 embedding 检索，把相关条款给 LLM，让 LLM 自己算理赔金额。”→ ✅ “先做意图识别，判断为计算型后，直接路由到计算模块，不碰向量库。LLM 只做参数提取和结果包装，不做数值计算。”
❌ “用 LLM 直接生成理赔金额，因为 LLM 数学能力很强。”→ ✅ “LLM 数学推理不可靠，金融场景必须用预定义函数或沙箱计算器。LLM 只负责理解 query 和输出结构化参数。”
❌ “所有 query 统一走 RAG，因为意图识别会增加延迟。”→ ✅ “延迟和准确性是 trade-off。计算型 query 走 RAG 会导致 100% 错误，而意图识别模型延迟 <50ms，值得加。”

6️⃣ 简历呼应

如果你有 RAG 项目：从“我曾在 XX 项目中实现多路路由”切入，强调你如何用意图识别区分事实型/计算型 query，并给出延迟对比数据（如路由后准确率从 60% 提升到 95%）。
如果你只做过传统 NLP：用“意图分类 + 槽位填充”类比迁移，说“这就像对话系统中的 NLU 模块，只是下游从对话管理变成了计算函数调用”。
如果你是校招无项目：聚焦“我复现过一篇关于 query routing 的论文（如《Routing Queries in Multi-Model Systems》）”，并说明你如何用 BERT 微调做意图分类，demo 里区分了 3 种 query 类型。
《Query Routing in Hybrid Search Systems: A Survey》（综述论文，涵盖规则/模型/LLM 三种路由方法）
《PAL: Program-Aided Language Models》（让 LLM 调用 Python 计算器做数学推理，适合复杂计算场景）
《Function Calling in LLMs: OpenAI 官方文档》（实现结构化参数提取的最佳实践）
《Intent Classification with BERT: 金融领域微调指南》（博客，含样本构建和评估指标）
《Apache Flink 实时路由引擎实战》（博客，讲如何用流处理框架做多路并发路由）

—— 本场面试完 ——