动态函数路由是怎么做的

1️⃣ 考察意图

面试官想看你是否理解“动态函数路由”在AI Agent中的核心地位——它本质上是意图识别与工具调用的桥梁。考察类型是系统设计+工程取舍，刁钻点在于：候选人常只背“用LLM判断”这种粗浅方案，却忽略了延迟、成本、准确率的三角权衡。答好了能展示你对多级路由架构的实战认知，包括如何用轻量级分类器过滤噪声、如何设计回退机制，以及如何评估路由质量（如召回率、延迟P99）。

2️⃣ 标准答

动态函数路由的核心目标：给定用户输入，从N个候选函数中选出最匹配的1个或多个，并生成参数。实现上分三个层级，从轻到重：

策略1：轻量规则（关键词+正则）
做法：维护一个函数名到关键词列表的映射（如search_flight→["航班","机票","北京到上海"]），用TF-IDF或简单字符串匹配（如re.search）做第一轮过滤。
为什么这么做：延迟<5ms，零成本，适合高频、意图明确的场景（如天气查询、计算器）。
坑与解法：关键词冲突（如“订机票”和“查航班”都匹配search_flight）→ 加优先级权重或互斥规则（如“订”优先于“查”）。
策略2：意图分类器（小模型+文本分类）
做法：用BERT或DistilBERT微调一个多标签分类器，输入用户query，输出函数ID的概率分布。常用框架：Hugging Face Transformers + ONNX Runtime推理。
为什么这么做：比规则泛化能力强，能处理同义表达（如“帮我看看明天去北京的票”→search_flight），延迟10-30ms，成本低（单次推理<0.01元）。
工程取舍：分类器需要标注数据（至少500条/函数），且冷启动时效果差。解法：先用规则兜底，同时用主动学习收集难例。
实际落地坑：类别不平衡（如search_flight占80%请求）→ 用Focal Loss或重采样；长尾函数召回低 → 加阈值回退（概率<0.5时走LLM）。
策略3：LLM先解释意图，再执行工具
做法：用GPT-4或Claude-3，在system prompt中定义函数列表（OpenAI function calling格式），让LLM输出JSON格式的function_call。典型流程：user query → LLM → {function: "search_flight", arguments: {"from": "北京", "to": "上海"}}。
为什么这么做：零样本、高准确率（>95%），适合复杂意图（如“帮我查明天北京到上海的航班，然后订最便宜的那个”需要多步路由）。
工程取舍：延迟高（1-3秒），成本贵（每调用0.01-0.1元），且可能幻觉（输出不存在的函数名）。解法：加函数名白名单校验 + 重试机制（最多3次）。
推荐架构：两阶段路由
第一阶段：策略1+策略2混合（规则过滤+分类器排序），将候选函数从100个缩小到5-10个。
第二阶段：LLM在缩小后的候选集中做最终决策，并生成参数。
为什么这么做：平衡延迟和准确率。第一阶段过滤掉90%无关函数，第二阶段LLM只需处理小集合，延迟从3秒降到500ms，成本降低80%。
实际落地坑：两阶段结果不一致（如分类器选A，LLM选B）→ 以LLM为准，但记录冲突日志用于迭代分类器。

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

“这个问题我从三个层面回答：第一，轻量规则，用关键词匹配实现低延迟路由，适合高频简单场景；第二，意图分类器，用BERT微调做多标签分类，平衡泛化能力和成本；第三，LLM直接路由，零样本但高延迟高成本。实际推荐两阶段架构：先用规则+分类器缩小候选，再用LLM做最终决策。总结一句：动态路由的核心是意图识别与工具调用的解耦，方案选择取决于延迟、成本和准确率的三角权衡。”

4️⃣ 高频追问 & 应对

追问1：如果用户输入是模糊的（如“帮我处理一下”），路由怎么兜底？

应对策略：设计一个“未知意图”回退机制。第一阶段：规则和分类器都返回低置信度（如概率<0.3）时，直接走LLM路由，并让LLM输出一个clarify函数，返回反问列表（如“您想处理订单还是查询信息？”）。第二阶段：如果LLM也失败（如输出空函数），则返回标准话术“抱歉，我无法理解您的需求，请重新描述”。实际落地中，模糊输入占比通常<5%，但影响用户体验，所以必须加日志监控和人工标注迭代。

追问2：如何评估路由系统的质量？用什么指标？

应对策略：核心指标是路由准确率（Top-1函数是否匹配）和召回率（多函数场景下是否覆盖所有相关函数）。离线评估用标注数据集（至少2000条），计算Precision/Recall/F1。线上监控用延迟P99（目标<500ms）和用户重试率（用户是否重复提问）。注意：路由错误会导致下游工具调用失败，所以还要加下游成功率（工具执行后是否返回有效结果）。一个实战坑：准确率99%时，用户仍可能遇到错误，所以必须加A/B测试验证用户满意度。

追问3：函数数量从100个扩展到1000个，路由方案怎么调整？

应对策略：两阶段架构天然可扩展。第一阶段：分类器从单模型改为分层分类（如先分“查询类”“操作类”，再细分具体函数），用Hierarchical Softmax或聚类减少候选数。第二阶段：LLM的prompt中函数列表太长（超过8K token）→ 用函数摘要（如只传函数名和一句话描述）或动态加载（根据分类器结果只传Top-10函数定义）。一个取舍：分层分类会增加延迟（多一次推理），但能支持万级函数，适合企业级SaaS场景。

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

❌ 只提“用LLM做路由”，说“LLM最准所以直接用” → ✅ 必须说明LLM的延迟和成本问题，并给出两阶段架构作为平衡方案。
❌ 说“规则和分类器过时了，现在都用LLM” → ✅ 规则和分类器在低延迟、低成本场景下仍是首选，LLM只适合复杂意图或冷启动阶段。
❌ 忽略参数生成，只讲函数选择 → ✅ 路由不仅要选函数，还要生成参数（如search_flight的出发地、目的地），LLM在这步比分类器强，所以两阶段中LLM负责参数填充。

6️⃣ 简历呼应

如果你有RAG项目：从“检索-排序”类比切入，说“动态路由类似RAG中的检索器，第一阶段是粗排（规则+分类器），第二阶段是精排（LLM）”，并强调你用过BM25和BERT做检索，迁移到路由中做意图分类。
如果你只做过传统NLP：用“文本分类+序列标注”类比，说“路由本质是多标签文本分类（选函数）+ 参数抽取（NER）”，并展示你微调过BERT做意图识别，可以复用数据标注和模型部署经验。
如果你是校招无项目：聚焦论文复现，说“我读过Toolformer和Gorilla论文，它们用LLM做路由，但我发现两阶段架构更实用”，并提到你写过一个demo：用FastText做分类器+OpenAI API做LLM路由，在20个函数上准确率达92%。
Toolformer: Language Models Can Teach Themselves to Use Tools (Schick et al., 2023)
Gorilla: Large Language Model Connected with Massive APIs (Patil et al., 2023)
Hugging Face Transformers + ONNX Runtime 部署指南（官方文档）
“两阶段路由在电商客服Agent中的实践”（博客，搜索关键词：two-stage function routing）
Focal Loss for Dense Object Detection (Lin et al., 2017) —— 用于解决分类器类别不平衡

—— 本场面试完 ——