美团 AI后端开发 二面：Agent 路由、RAG 召回与营销投放设计

《面试题目》

项目与 RAG

1. 项目 1 的 Agent 里，哪些阶段是由 Agent 完成的？
2. 这个项目是为了解决线上真实存在的痛点才启动的吗？
3. 召回率这个指标是怎么计算的？
4. 召回的样本是你们自己定义和维护的吗？
5. 关键词提取是模型做的还是规则做的？
6. 召回没有做到更高，有没有分析过原因？
7. RAG 知识库的更新频率如何？怎么维护？
8. 整个 Agent 项目的业务价值有没有被验证？
9. Agent 的生成结果有没有统计采纳率？如何区分有效回答和模型幻觉导致的错误回答？
10. 开发过程中遇到过哪些问题，是怎么解决的？

场景设计

11. 基于用户意图的场景路由机制是怎么实现的？
12. 如果路由选错 skill，该怎么处理？
13. 怎么解决不同规格识别、模糊检索的问题？请举例。
14. 日志数据量很大，会全部塞进模型上下文吗？
15. 多轮对话上下文膨胀、产生幻觉，怎么处理？
16. 设计题：面向营销投放的 Agent，输入目标和预算，自动查历史方案、生成报告，你会怎么设计？
17. 如何证明 Agent 输出的报告是可信的？

技术选型与学习

18. 你平时怎么学习 Agent 前沿能力和新工具？
19. 学习新技术时遇到过什么卡点，是怎么解决的？
20. 当时做技术选型为什么选择 RAG？
21. 你做过大模型微调，简单介绍一下。

项目 2 与 HR 问题

22. 讲一下项目 2 的框架。
23. 目前手上有没有拿到 offer？
24. 是否考虑来北京发展？

《参考解析》

召回率要先把分母说清楚，否则这个数字没有意义。 工程上通常报 Recall@K：在一个查询的标注相关集合里，前 K 条召回结果覆盖了多少，即 命中相关文档数 / 全部相关文档数。分母来自评测集，不是模型自己挑的样本。样本维护一般分三路：从线上 query 日志分层抽样（按业务场景、 query 长度、长尾程度分层）、业务专家补充高频与高风险问题、bad case 回流；每条 query 标出相关文档和等级，双人标注加仲裁，评测集版本化管理，避免被训练数据污染。召回上不去时不要笼统说“模型效果不好”，要按链路做消融：固定同一批 query，分别关掉 query 改写、混合检索、rerank、元数据过滤，观察 Recall@K 与 MRR 的变化，再结合错误样本判断是切分粒度、embedding 语义鸿沟、过滤条件过严，还是索引更新不及时。关键词提取可以是规则先行、模型兜底：高频词和业务词典用规则保证稳定，长尾和同义改写交给模型；知识库更新则按数据源分全量和增量，文档变更触发重新切分与 embedding，给索引设版本和过期时间，定期重建避免碎片。最后还要把召回指标和端到端采纳率对齐，否则可能出现召回涨了、答案反而更差的情况。

业务价值与采纳率要分开定义“有效”和“没幻觉”。 采纳率可以分层统计：直接复制/直接采用、修改后采用、点踩或重问、人工兜底。只看点赞会把“看起来顺眼”当成正确。区分有效回答与幻觉，靠三类信号交叉：一是引用校验，答案里的每个关键结论能否落到检索到的原文片段；二是工具回读，涉及订单、库存、价格这类事实时，让 Agent 调接口复核而不是凭上下文生成；三是结构化校验与拒答机制，字段缺失、数值越界、置信度低时明确说“查不到”，而不是补一个看似合理的数。上线价值则看业务侧的前后对照：单均处理时长、人工转接率、一次解决率、错误导致的返工或赔付，最好有灰度组和对照组。面试里能把“采纳率、正确率、拒答率、业务指标”四个口径分开讲，可信度会高很多。

场景路由不要做成一次分类就结束，要有置信度和可回退的执行链。 常见实现是三层：规则/词典先拦高频和强约束意图；向量检索用历史 query 找最近邻；剩下交给小模型或 LLM 做 few-shot 分类。每层都输出候选 skill 和分数，低于阈值不硬选，而是追问澄清或走通用检索。路由选错的兜底要设计在执行前：skill 调用前做参数与权限校验，高风险写操作先 dry-run 或让用户确认；执行中捕获工具错误，能回退到上一级路由就回退，不能回退就转人工；执行后记录“路由结果、实际使用 skill、用户是否纠正”，离线算混淆矩阵，重点看哪些意图总被互相混淆。路由日志还可以反哺训练集和规则，形成闭环。不同规格识别、模糊检索这类问题，通常要把结构化字段抽取和向量检索结合：能落成枚举/单位的先归一化，不能确定的保留候选并让模型或用户确认，别用一个相似度分数硬判。要让面试官听到一个关键判断：路由是概率组件，系统必须假设它会错，而不是假设它总对。

日志和多轮上下文的关键是“按需取片段”，不是把原始数据塞进窗口。 日志量大的场景先做结构化：时间、服务、错误码、请求 ID、关键指标，原文落对象存储，模型上下文里只放聚合统计和与当前问题相关的几段日志；需要细节时让 Agent 通过工具按请求 ID 回查。多轮对话则做分层记忆：系统约束与安全规则常驻，任务状态和已确认参数用结构化槽位保存，最近 N 轮保留原文，更早的对话压成滚动摘要，并单独维护实体表（人名、订单号、时间、金额）和未完成事项，避免摘要把关键数字压没。压缩后要用探针问题验证：关键实体是否还在、约束是否还遵守、指代是否还能消解。幻觉的工程解法是 grounding：回答必须带引用，数值由工具计算，输出走 schema 校验，置信度不足时拒答或转人工，而不是靠调低温度这种弱手段。

营销投放 Agent 要拆成“算”和“写”两段，模型负责编排与解释，数值由工具负责。 输入是目标（GMV、ROI、拉新）、预算、时间窗和约束（行业、渠道、合规、库存），先做目标解析和约束校验，再把历史方案按行业、人群、渠道、季节、预算档位检索出来，生成若干候选组合；每个组合用预估模型算曝光、点击、转化、CPA 和预算分配，必要时做敏感性分析，最后才让模型写报告。报告结构固定为：目标与假设、历史依据、候选方案对比、推荐方案与预算曲线、风险与止损条件。执行环节必须有人工审批和预算上限，投放后持续监控实际 CPA，偏差超过阈值就暂停或重规划。证明报告可信，靠的是数据血缘和可复算：每个数字能追到哪张表、哪个时间窗、哪个模型版本；结论附置信区间和历史回测；关键假设做敏感性分析；上线前用历史窗口回放，上线后做小流量 AB。审计日志要记录模型版本、提示词版本、工具调用参数和人工修改，出问题能复盘。

RAG 与微调不是二选一，先看知识形态和错误成本。 RAG 适合知识更新快、需要引用溯源、按权限隔离、冷启动没有标注数据的场景；代价是检索链路长、延迟和成本高，效果上限受切分、embedding 和 rerank 影响。微调适合固定输出风格、格式约束、领域术语和把小模型蒸馏到可接受的效果；它不擅长注入频繁变化的事实，硬把知识记进参数还会带来灾难性遗忘和更新困难。常见组合是：微调一个小模型做意图路由、query 改写或结构化抽取，主回答仍走 RAG 拿事实；等积累了大量高质量领域数据，再考虑把稳定部分蒸馏进模型。回答“为什么选 RAG”时要把当时的约束讲出来：知识库多大、更新频率、是否要求引用、团队有没有标注和训练资源、延迟预算多少，这比背优缺点更有说服力。

学习路径和卡点要讲成可复用的方法。 比较有说服力的说法是：先跟官方文档和 release note 建立版本感，再挑一个最小可运行例子跑通，然后读源码或关键 issue 理解边界，最后把学到的东西接进现有项目做一次小实验。卡点通常不在“看不懂概念”，而在环境、版本、评测和成本：比如工具调用格式随版本变化、长上下文成本和延迟超预期、评测集太小导致结论不可信。解决方式分别是锁定版本并写最小复现、先做离线小样本压测再上线、用人工抽检和线上指标校准评测集。HR 问题照实回答即可，offer 进度和城市意愿不需要包装，但可以说清选择标准：业务方向、团队技术积累、个人成长空间。