QueWI (Chatbot) — 项目深挖防守稿

项目：面向客户的 Chatbot 解决方案，多模型动态自动选择
时间：2025年04月 – 2025年09月
角色：主导研发（从模型微调到服务部署的全栈）
技术核心：AI 网关 + vLLM 部署 + 模型路由 + MCP 工具链 + 意图识别 SFT
面试权重：★★★
来源：CV；未做一手考证
相关知识点：01-fundamentals/06-agent-infra/gateway-routing.md、vllm-pagedattention.md、01-fundamentals/02-post-training/sft.md

1. 三十秒叙事#

「这是面向客户的 Chatbot 解决方案，我主导从模型微调到服务部署的全栈。

项目有两条主线。第一条是基础设施：搭了 AI 网关、基于 vLLM 的推理部署、LLM 应用开发平台，以及 MCP 工具链 —— 这一层的目标是把「接一个新模型 / 接一个新工具」的成本降到最低。第二条是智能路由：不是所有请求都值得用最大的模型。我用语义理解分析请求意图（任务类型、需要哪些工具），动态调度最适配的模型 —— 在响应质量和计算成本之间取平衡。

另外基于真实线上用户数据对 Qwen2.5-4B 做了 SFT，专门优化意图识别场景，分类准确率提升约 23%。」

为什么这么开场：基础设施 + 路由 + 微调三条线，覆盖了「工程能力」的三个不同维度。对 FDE 类岗位，第一条线（基础设施）和第二条线（成本权衡）尤其值钱 —— 因为 FDE 要面对的就是「怎么用有限预算把客户的东西做出来」。

2. 架构与关键决策#

2.1 模型路由：这个项目的核心思想#

问题：不同请求的难度差异极大。一句「你好」和一段需要多步工具调用的复杂分析，用同一个模型是双重浪费 —— 简单的浪费钱和延迟，复杂的可能能力不够。

做法：先用一个便宜的语义理解步骤判断请求意图（任务类型是什么、需要哪些工具、预估复杂度），再据此选择模型。

用户请求 → 意图识别 / 复杂度估计 → 路由决策 → 小模型 / 中模型 / 大模型 → 响应
                    ↑
              这一步本身也用一个小而快的模型（Qwen2.5-4B）

关键设计点 —— 路由判断本身必须便宜。 如果为了决定用哪个模型，先调用了一个大模型，那就本末倒置了。所以路由用的模型必须小而快，这正是下面 2.3 要 SFT 的原因。

要能讲清的收益结构：

质量侧：把大模型算力集中在真正需要的请求上，整体响应质量不降
成本侧：大量简单请求分流到小模型，单位请求成本显著下降
延迟侧：小模型的首 token 延迟远低于大模型

2.2 AI 网关：为什么必须有一层统一入口#

网关解决的问题是**「模型和工具的接入点分散」。没有网关时，每个应用各自对接模型、各自管密钥、各自做限流 —— 结果是换模型要改全部应用代码**、密钥散落各处、成本无法归集。

网关把这些收拢成一层：

职责	解决什么
多模型统一接口	换模型 / 加模型不改上层应用
密钥与配额管理	密钥不散落，成本可按应用/客户归集
限流与降级	上游模型故障或限流时优雅降级
日志与链路追踪	出问题能定位；也是路由策略的评估数据来源
路由策略	2.1 的决策在这里落地

面试价值：这是「平台思维 vs 应用思维」的分界。能讲清「我建的不是一个 chatbot，是一个让后续 chatbot 都能更快建起来的基础设施」，层级立刻不同 —— 这也正是 FDE 岗位看重的能力。

2.3 为什么用 Qwen2.5-4B 做意图识别#

不是「因为 4B 便宜」这么简单，要能说清完整推理链：

意图识别是分类任务，不是生成任务 —— 输出空间很小（有限的意图类别 + 工具组合），不需要大模型的世界知识和生成能力
它在关键路径上 —— 每个请求都要过一次，所以延迟直接影响体感；小模型首 token 延迟低
它调用量大 —— 用量乘以单价就是总成本，小模型的成本优势被请求量放大
它必须可定制 —— 通用模型的意图分类不见得贴合业务的意图体系，所以需要 SFT 适配

这四条合起来才是完整答案。 只说「便宜」是初级回答。

2.4 基于真实线上用户数据做 SFT#

用真实用户输入做 SFT，比合成数据更贴合真实分布 —— 这是最大的优势。

但要能主动说出风险（很加分）：

隐私与合规：真实用户数据必须脱敏，且要有使用授权。这是法律问题不是技术问题
分布漂移：用历史数据训的模型，遇到新意图会失效 → 需要持续的线上监控和再训练机制
标注质量：真实数据需要人工标注意图标签，标注一致性直接影响上限

「23% 提升」的口径必须想清楚：

baseline 是未微调的 Qwen2.5-4B，还是通用大模型，还是规则系统？（这三个含义完全不同，必须说准）
测试集是留出的真实数据还是构造数据？
是准确率还是 F1？意图分类在类别不均衡时准确率会骗人

2.5 MCP 工具链#

用 MCP 把外部工具接进来。为什么要 MCP 而不是自己写 function calling：

标准化的接入协议 —— 工具提供方按 MCP 实现一次，所有支持 MCP 的客户端都能用，不用为每个应用重复适配（M×N → M+N）
工具与应用的解耦 —— 加工具不改应用代码
生态复用 —— 现成 MCP server 可以直接用

要能说清的边界：MCP 解决的是接入标准化问题，不解决工具选择准确性问题 —— 工具描述写得好不好、模型选得对不对，仍然是 prompt engineering 和评测的活。

3. 面试官会怎么往下挖#

第一层：动机#

Q：为什么要做模型路由？直接全用大模型不行吗？

要点：成本、延迟、质量三个维度。全用大模型在大量简单请求上浪费算力和延迟预算；关键是把大模型算力集中在真正需要的请求上。要能给出定性的成本结构分析，不要编数字。

Q：为什么用 MCP？

要点：M×N → M+N 的接入复杂度收敛；工具与应用解耦；生态复用。并主动说明 MCP 不解决工具选择准确性问题。

第二层：技术细节#

Q：路由判断错了怎么办？错误会怎么传播？

⚠️ 很尖锐。 要点：错误的代价是不对称的 —— 把复杂请求误判为简单（走小模型）会直接给出低质量回答，用户可感知；把简单请求误判为复杂（走大模型）只是浪费钱但体验没问题。所以阈值应该偏向保守（宁可多花钱也不要答错）。

缓解：置信度阈值、低置信时升级模型重试、以及把误判 case 记录下来回灌训练。

Q：路由本身的开销会不会抵消收益？

⚠️ 这题如果答不上，前面的论述全部失效。 要点：路由模型必须小而快（这就是用 4B 的原因），其开销相对大模型调用可以忽略。要能定性说明：路由是「每次一个短分类前向」，而被它省下的是「一次长上下文大模型生成」，量级差异明显。

Q：意图识别为什么不用规则 / 传统分类器？

要点：用户表达方式多样、需语义理解、意图体系会演化。规则维护成本随规模上升且召回差；传统分类器需要特征工程且泛化弱。用 LLM 做分类的好处是加新意图只需改 prompt 和补数据，迭代快。

Q：23% 提升的 baseline 是什么？测试集怎么来的？

⚠️ 必问。 必须能立刻说清：baseline 是未微调版本还是别的、测试集是留出真实数据还是构造数据、指标是准确率还是 F1。如果不确定，说清楚你能确定的部分，不要含糊。

Q：SFT 用真实用户数据，隐私怎么处理？

⚠️ 这题很关键，答不好是致命的。 要点：脱敏（PII 移除或替换）、使用授权与合规审查、数据留存策略、以及训练产物是否可能泄露原始数据。要能区分「脱敏」和「匿名化」的差别 —— 前者可逆、后者不可逆，合规要求不同。

第三层：工程与生产#

Q：vLLM 部署遇到什么问题？

可能的坑：显存不足（KV Cache 占用随并发增长）、批处理策略调优、长请求尾延迟、模型加载时间。要点是说清你遇到的具体瓶颈和解决思路，不要泛泛讲 vLLM 原理（那是 06-agent-infra 的内容，这里是「你怎么用的」）。

Q：网关怎么处理上游模型故障？

要点：超时与重试策略、降级到备用模型、熔断。要能说清降级后的质量损失怎么和用户沟通 —— 这是产品问题也是技术问题。

Q：怎么评估路由策略的好坏？

⚠️ 好问题，考的是评测思维。 要点：不能只看准确率。要看 ① 分流比例分布是否符合预期；② 各类请求的实际质量（分桶评测）；③ 单位成本变化；④ 线上用户反馈。最重要的是分桶评测 —— 整体指标好可能掩盖某一桶的严重退化。

第四层：反思#

Q：如果重做，你会改什么？

建议方向：① 路由的评估体系做得更细（分桶 + 成本联合优化）；② 把意图识别做成可持续迭代的闭环（线上误判自动回流）；③ 网关的路由策略做成可配置而不是硬编码；④ 更早考虑隐私合规流程。

4. 线上故障复盘#

米哈游面经：「所有技术点必须绑定业务场景 + 线上问题 + 量化结果」。这一节按 README.md《故障题的四段结构》准备。

⚠️ 下面三类是这套架构必然会长出来的故障（由设计推导），不是替你编的经历。你要做的是把每一类对应到自己真实遇到的那一次；确实没遇到的，就如实说没遇到，再讲你为它加了什么预防。

#	故障类型	现象（先给可观测的表象）	该往哪查	修法与复盘要点
1	路由误判：把难题判成简单	少数请求的回答质量突然变差，集中在某几类意图；单位成本降了，但这类请求的投诉上来了	按分桶看质量与分流比例，找出误判集中的意图；比对同一意图被分到小/中/大模型时的质量差	置信度阈值调保守 + 低置信直接升配重试 + 误判 case 回流意图训练集。复盘：误判代价不对称，所以阈值必须偏向多花钱
2	上游故障被重试放大	某家模型超时后，整体延迟被拉爆，甚至把其他模型/配额的额度也吃掉（雪崩）	网关侧的超时、重试次数、重试放大倍数、熔断状态；看故障时段的重试总量曲线	超时预算 + 有上限且带退避的重试 + 熔断降级到备用模型；并明确降级后的质量损失怎么和用户沟通。复盘：重试是最容易写成放大器的机制
3	vLLM 显存与尾延迟	并发上来后偶发 OOM，或尾延迟飙升（少数长请求拖住整批），平均值却看着正常	KV Cache 占用随并发的曲线、请求长度分布、批处理与调度策略	限制最大并发与单请求长度、按长度分桶、简单流量交给更小的模型承接。复盘：首 token 延迟是体感指标，尾延迟才是稳定性指标 —— 只看平均值会漏掉它

面试官还会接着问#

Q：你怎么判断是「路由判错了」还是「这个模型本身就不行」？

做一个反事实：把被分到小模型的那批请求，同一批问题用大模型再跑一遍，比较质量差。如果升配后明显变好 → 是路由策略的阈值问题；如果升配也好不了 → 是小模型能力边界的问题，那要改的是候选模型池，不是阈值。先把归因做对，再决定改哪一层。

Q：网关降级之后，用户侧会看到什么？

这题考的是「有没有把技术降级当成产品问题处理」。要能说清：降级是静默还是提示；如果是静默，回答质量会掉到什么程度；有没有兜底话术。含糊答「就降级了」等于没答。

5. 数字口径速查#

数字	口径必须说清
约 23% 提升	baseline 是什么版本；测试集来源（留出真实数据？构造数据？）；指标是准确率还是 F1；类别是否均衡
Qwen2.5-4B	用于意图识别这一子任务，不是整个系统的主模型
路由	讨论收益时用结构性描述（简单请求分流、单位成本下降），不要编具体百分比

⚠️ 23% 是 CV 上唯一的量化数字，一定会被追问。先备好口径再开口。

6. 红线#

不要 claim：

❌ 不要编路由带来的成本下降百分比。
❌ 不要把 vLLM / MCP / AI 网关的原理讲成大段背书 —— 那些是通用知识，这里要讲你怎么用的、遇到什么坑。
❌ 不要声称 SFT 用的真实用户数据「做过匿名化」除非确实不可逆 —— 用词要准确。
❌ 不要把「意图识别 23%」说成「整体准确率 23%」。

要主动说：

✅ 主动讲路由判断必须便宜这个设计约束 —— 它证明你想过闭环成本。
✅ 主动讲误判代价不对称、所以阈值偏保守 —— 这是产品思维的体现。
✅ 主动讲隐私合规的处理方式。
✅ 主动提一个具体的线上故障（见 §4）—— 这是「真做过」最有效的证据，也是米哈游面经里被单列出来的考察项。

7. 自测#

1. 为什么意图识别用 4B 小模型而不是让主模型顺便做掉？给出四条理由。

答案要点

① 意图识别是分类任务，输出空间小，不需要大模型的世界知识与生成能力；② 它在每个请求的关键路径上，延迟直接影响体感，小模型首 token 更快；③ 调用量极大，成本被请求量放大；④ 需要贴合业务意图体系做定制，通用模型未必适配，需要 SFT。

2. 路由判断错了，为什么阈值应该偏保守（宁可多花钱）？

答案要点

误判代价不对称：把复杂请求误判为简单会直接产生低质量回答、用户可感知且伤害信任；把简单请求误判复杂只是多花算力、体验无损。因此决策阈值应偏向「升配」，并用置信度阈值 + 低置信重试兜底。

3. 面试官问「路由本身的开销会不会抵消收益」，你怎么答？

答案要点

不会，量级差异明显：路由是每次一个短分类前向（小模型、几十个 token 输出），它省下的是长上下文的大模型生成。前提是路由模型必须小而快 —— 这也是选择 4B 的关键原因。若路由用大模型，收益确实会被抵消，那样的设计是错的。

4. 「意图识别准确率提升约 23%」—— 被追问时你需要说清哪三件事？

答案要点

① baseline 是哪个版本（未微调的 Qwen2.5-4B / 通用大模型 / 规则系统，含义完全不同）；② 测试集来源（留出的真实数据还是构造数据，是否与训练集去重）；③ 指标定义（准确率还是 F1；类别不均衡时准确率会高估性能）。

5. 用真实用户数据做 SFT，列出至少三个必须处理的风险。

答案要点

① 隐私与合规：PII 脱敏、使用授权、留存策略，且要区分「脱敏」（可逆）与「匿名化」（不可逆）；② 分布漂移：新意图出现后模型失效，需要持续监控与再训练闭环；③ 标注质量：意图标签的人工标注一致性直接决定上限；④ 训练产物可能记忆原始数据，需要评估泄露风险。