双模型意图路由：面试表达手册

这份材料用于把真实做过的工作讲清楚。重点不是背指标，而是说明为什么做、怎么验证、发现了什么问题，以及下一步如何让它成为可靠的产品能力。30 秒版本我为 ScholarAgent 做了一个可切换的双模型意图识别模块。CPU 路线用 BGE-small 做四分类，适合低延迟默认路由；GPU 路线用...

字数: 1629 | 语雀原文

这份材料用于把真实做过的工作讲清楚。重点不是背指标，而是说明为什么做、怎么验证、发现了什么问题，以及下一步如何让它成为可靠的产品能力。

30 秒版本

我为 ScholarAgent 做了一个可切换的双模型意图识别模块。CPU 路线用 BGE-small 做四分类，适合低延迟默认路由；GPU 路线用 Qwen3-0.6B 加 LoRA，除了意图还能生成实体和约束。两条路线共用同一套 train/dev 和冻结测试集。我在 V100 上真实训练后，BGE 测试 Accuracy 是 96.25%，远端 CPU 单条平均约 9.55 ms；Qwen 测试 Accuracy 是 98.75%，但 GPU 生成平均约 301.56 ms。最终设计不是二选一，而是 BERT 快速分流、Qwen 处理复杂或低置信度请求。

2 分钟版本

项目最初的意图识别偏规则和通用大模型调用，我希望把它变成一个可以训练、评测和切换的独立子模块。先定义了四个和科研 Agent 工作流直接对应的标签：框架评测、论文复现、代码执行和一般请求。然后构建 640 条训练、160 条开发、80 条冻结测试数据，并检查三个划分没有归一化文本重叠。

第一条路线是 BAAI/bge-small-zh-v1.5 的序列分类微调，总参数约 2400 万。它训练只用了约 6.82 秒，测试 Accuracy 96.25%，CPU 单样本平均延迟 9.55 ms，优点是快、输出受控、适合本地部署。

第二条路线是 Qwen3-0.6B 的 LoRA 指令微调，只训练约 1009 万参数，占含 adapter 总参数的 1.67%。它输出严格 JSON，可以携带 intent、entities 和 constraints。训练约 306 秒，测试 Accuracy 98.75%，JSON 全部可解析，但有一条生成了 schema 外的 Plotting 标签，所以 schema 合法率是 98.75%，GPU 平均延迟约 301.56 ms。

这个错误还帮我发现了评测实现中的 bug：未知预测原本只扣 Accuracy，没有计入真实类别的 FN，Macro-F1 会被虚高。我修了统计逻辑并补了回归测试。这个过程让我确认，Agent 子模块不能只看“模型跑通”，还要验证输出契约、未知类别和失败样例。

STAR 结构

Situation：科研 Agent 需要把自然语言请求稳定路由到评测、复现、执行等不同工作流，规则难覆盖复杂表达，全部调用大模型又慢且成本高。

Task：实现一个可学习、可评测、CPU/GPU 可切换的意图路由模块，并在真实 GPU 环境跑通两条训练链路。

Action：定义四类业务标签和统一 JSON 契约；生成平衡 train/dev 数据并冻结已有 benchmark 作为 test；分别实现 BGE 全参数分类微调和 Qwen3-0.6B LoRA 指令微调；记录 Accuracy、Macro-F1、schema 合法率和端到端延迟；逐条审查失败预测并修复未知标签导致的 Macro-F1 统计错误。

Result：BGE 在测试集达到 96.25% Accuracy、CPU 平均 9.55 ms；Qwen 达到 98.75% Accuracy、100% JSON parse rate 和 98.75% schema valid rate。由此形成分层路由方案：BGE 负责高频确定性请求，Qwen 负责复杂结构化解析和低置信度回退。

技术追问

为什么不只用 Qwen？

Qwen 的表达能力更强，但本次单样本生成平均延迟约 301.56 ms，而且生成式输出存在 schema 外标签。BGE 的 CPU 平均延迟约 9.55 ms，标签空间由分类头硬约束，更适合高频入口。产品上应按请求难度和置信度分层，而不是让每条请求都承担生成式模型成本。

BERT 分类微调和 Qwen LoRA 有什么本质区别？

BGE/BERT 是双向编码器，把整段文本编码后通过分类头一次选出标签，损失主要作用于类别概率。Qwen 是因果解码器，按 token 生成 JSON；训练时只对回答部分计算语言模型损失。LoRA 不更新全部基座参数，而是在注意力和 MLP 投影层学习低秩增量，因此显存和保存成本更低。

为什么 Macro-F1 比 Accuracy 更重要？

Accuracy 只看总体正确数。Macro-F1 先计算每类 F1 再平均，可以暴露某一类召回很差的问题。即使本次测试集均衡，Macro-F1 仍帮助发现未知生成标签没有正确计入 FN 的评测 bug。

如何保证没有数据泄漏？

我固定数据生成种子，为每个划分记录 SHA-256，并对归一化文本做交集检查，train/dev、train/test、dev/test 都是 0。测试集沿用仓库已有 benchmark，训练过程不使用 test 选 checkpoint。

为什么 Qwen 的 Macro-F1 高于 Accuracy？

测试集中唯一错误是一个未知标签。它使 Code_Execution 的召回率降为 0.95、该类 F1 为 0.9744，其余三类 F1 都是 1.0，因此四类 Macro-F1 为 0.9936；总体 80 条错 1 条，Accuracy 为 0.9875。两者统计口径不同，这不是矛盾。

下一步怎么做？

优先补三件事：使用真实用户请求做人工标注和难例回流；运行多随机种子与 OOD 测试；给 entities/constraints 增加字段级评测。工程上还要做置信度校准、schema 约束解码、超时降级和线上漂移监控。

可以主动强调的亮点

不只训练模型，还设计了双路部署和回退边界。
同时报告分类质量、结构化输出合法率和端到端延迟。
保存数据哈希、随机种子、逐样本预测和模型权重哈希，结果可追踪。
从失败样例反查评测代码，修复了会虚高 Macro-F1 的真实 bug。
对局限保持诚实，没有把小规模合成数据实验包装成生产效果。完整实验参数、哈希和失败样例见真实训练记录。