腾讯 260824 风控算法 Agent 开发一面

《面试题目》

1. 这个映射的真正难点是什么？为什么直接翻译或者问大模型不够？
2. 你如何把用户描述映射到目标标签？
3. 这个项目的技术细节与选型是怎么考虑的？
4. 如果用户描述一个具体物品，返回结果里却包含大量泛化类别和属性词，这些词虽然语义相关却没有实际帮助，怎么处理？
5. 用标签分组优化排序，为什么能解决刚才的问题？
6. 如果自动识别类别仍然使用向量相似度，怎么避免原来的混淆？
7. 用户没有搜到预期结果时，如何分析？
8. 使用的语义模型大致是什么结构，如何训练？
9. 你说的准确率到底怎么定义？
10. 测试集怎么构造？参考答案从哪里来？谁来评分？
11. 测试是否覆盖文本回答、工具调用等不同任务？
12. 评测只看最终答案，还是也看中间的工具调用过程？
13. 为什么选 Plan-and-Execute？
14. 为什么认为 ReAct 会带来更多轮次或更高的延迟？
15. 延迟降低主要来自控制模型调用次数，还是其他优化？
16. 如果问题和动作空间都比较固定，为什么不用标准工作流？
17. 这个场景是否需要多轮交互？状态和上下文怎么管理？
18. 对大模型训练、推理加速了解多少？
19. MCP 和直接提供 REST API、Function Calling 的区别是什么？
20. 如果把接口说明写成 Skills 文档、让模型照着调用，和 MCP 的区别在哪里？

《参考解析》

模糊语义搜索的难点在「描述到标签」的映射，不在相似度计算

用户说的是自然语言描述（「能装下一台 15 寸笔记本的包」），系统要落到的是结构化的类目和标签，两者之间隔着一次语义归一。直接翻译解决不了，因为翻译只换语言、不消歧；直接问大模型也不够稳，因为每次调用都要重新猜一遍词表，同一句描述可能落到不同标签上，不可控也不可缓存。可用的做法是把标签体系当成受控词表：先用模型把描述抽成「主体 + 属性 + 约束」，再把每个属性分别召回候选标签，最后在候选集合内做组合与打分；模型的职责是理解与扩充同义词，落标签这一步由规则和词表收口，这样口径才稳定。常见的追问是「词表没覆盖的新词怎么办」——答案是走一个可回流的兜底通道（聚类到最近的标签并记录待人工确认的新词），而不是让模型当场自造标签。

泛化词污染结果：靠标签分组和类别约束，而不是调阈值

「语义相关但没有帮助」的典型表现是，一个具体物品的 query 召回了「电子产品」「配件」这类上位词，它们和 query 的向量距离很近，但点进去什么都不是。单纯抬高相似度阈值会把长尾的具体物品一起误杀，因为上位词的相似度未必比正确结果低。更有效的做法是在排序前先做类别约束：把标签按层级分组，先判定 query 属于哪个细分类别，再在组内排序，组外的上位词直接降权或过滤。分组之所以有效，是因为它把「语义相近」换成了「类别相容」这个更硬的判据，向量只用于组内排序。这里面试官通常会追一句：类别识别如果还是用向量相似度，不就把原来的混淆搬过去了吗——所以类别判定要么用有监督的分类模型（训练数据来自点击与人工标注），要么用两级召回加规则校验，不能只是换一个阈值的同一套逻辑。

评测怎么定义：先定任务，再定口径

「准确率」在 Agent 场景里必须先拆对象，否则数字没有意义。至少拆三层：检索层看召回与排序（命中率、MRR、NDCG），回答层看事实正确性与是否切题，执行层看工具选择是否正确、参数是否正确、是否越权。口径定了再谈测试集：参考答案要么来自人工标注的黄金集，要么来自可执行的判定（能查库验证的答案优先用程序判，主观题才用模型评审加人工抽检）。测试集构造上要覆盖三类样本——高频常规、长尾边界、以及诱导性的坏输入，并保证每一类有明确来源和难度分层。评分最好机器可复现，人只做抽检和争议裁决。面试里更值钱的补充是「我会怎么做更好」：比如给每道题标注期望的工具调用序列，把「过程对不对」也纳入评测，这样失败可以归因到检索、规划还是工具执行，而不是只看到一个总分。

Plan-and-Execute 与 ReAct 的取舍

ReAct 是边想边做，每一步都依赖上一步的观察，灵活但轮次多：一次任务里模型要反复「思考—调工具—读结果」，token 与延迟随步数线性上涨。Plan-and-Execute 先把步骤规划出来，再逐步执行，好处是规划阶段可以把全局约束一次想清、执行阶段可以并行或批量调用工具、中间步骤可以用确定性代码代替模型判断。面试官问「为什么认为 ReAct 更慢」时，要点不在框架本身，而在模型调用次数：ReAct 每一步都要过一次模型，Plan-and-Execute 把「想」集中到少数几次调用里。反过来也要承认它的代价——计划一旦错了，后面全错，所以要有重规划机制与执行前的校验，这也是常见的追问方向。

动作空间固定时，为什么不用标准工作流

这题考的是「什么时候不该用 Agent」。如果问题空间收敛、动作可枚举、分支有限，那么标准工作流（状态机、规则、固定编排）在延迟、成本、可测试性上都更优，模型只该出现在真正需要语义判断的那一步。选 Plan-and-Execute 的理由通常是三个：输入形态开放（用户表达不受控）、步骤数不固定（有的问题要走三步、有的要走十步）、以及需要跨工具组合。如果三个都不成立，就该老实回答「这种情况我会退化成工作流」，而不是硬给框架找理由。

MCP 与 REST / Function Calling / Skills 文档的区别

Function Calling 是模型侧的输出格式约定：它把「可调用的工具」按 schema 描述给模型，模型回一个结构化的调用请求，工具本身怎么部署、怎么鉴权它不管，每个应用都要自己接一遍。MCP 是协议层标准，管的是工具如何被发现、描述、调用和传参，模型侧与工具侧解耦，同一批工具换一个客户端就能复用；代价是多了一跳进程通信和协议实现的复杂度，鉴权与权限边界要额外设计。把接口说明写成 Skills 文档给模型看，等价于「文档即工具描述」，最轻量、没有协议开销，但缺少强约束——模型可能读错、漏读或幻觉参数，也没有统一的错误返回和权限校验，适合少量、低频、容错的工具；工具一多、要被多方复用、或需要审计与权限控制时，就应该上 MCP。