腾讯大模型算法面经合集：标签映射、语义模型训练与 Agent 编排选型

《面试题目》

面经 01

面试岗位：大模型算法岗 ｜ 面试时间：2026 年 10 月 2 日

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

面经 02

面试岗位：大模型算法岗 ｜ 面试时间：2026 年 9 月 28 日

19. 如果来实习，什么时候可以到岗？可以实习多久？
20. 手撕：【算法题】IP + 端口转成 uint64。
21. 手撕：【算法题】对折链表。
22. 手撕：【算法题】随机数生成、均匀抽样问题。
23. 你现在还在字节那边实习吗？
24. 你所在的团队主要做什么？你个人主要负责什么？
25. 你们团队的研发流程是怎样的？
26. 你们团队平时的研发节奏怎么样？
27. 整体系统架构是什么样的？
28. 这个平台主要解决什么问题？它的作用是什么？
29. 你提到优化了创建耗时，一般做这种性能优化时，你的思路是什么？
30. 回到你这个创建耗时优化案例，目前还有没有进一步的优化空间？
31. 最有挑战的事情是什么？
32. 你提到凭证托管比较复杂，复杂性具体体现在哪里？
33. Agent 中的这些 Skill 应该怎么构建？

《参考解析》

描述到标签的映射难在哪，为什么不能直接翻译或问大模型

难点不在语言转换，而在「描述是开放的、标签是有边界受控的」：用户描述往往口语化、含多个意图、带否定与程度词，一个描述可能同时命中多个标签，也可能落在标签体系的缝隙里；标签之间的语义边界常由业务规则划分（同类目下的近似标签），不是语言上的近义词差别。直接翻译只会得到字面词，问大模型则容易「看起来合理但落到体系外」——它不知道你库里究竟有哪几个标签、每个标签的准入规则是什么，也没有业务侧的排除条件。可行路线是把检索与决策分开：先把受控标签集做成带说明与示例的候选（每个标签写清准入、排除、反例），用语义模型召回 top-k 候选，再用一个小的判别模型或规则层做最终裁决，并把「无法归属」作为合法输出而不是硬塞一个标签。标签分组能提升排序，本质是先把候选空间按上位类目压缩，再在组内比相似度——组内语义更接近，区分度更高的特征（如组内的关键约束词）才能起作用，减少跨类目的误召回。

准确率怎么定义，测试集怎么构造、谁来评分

「准确率」必须先说清是哪个环节的指标，否则无法复现：端到端任务成功率、标签映射的 top-1 命中率、召回率（该召回的标签有没有进候选）、拒识率（应当判为无法归属的比例）、以及误匹配率（错误标签的代价，通常比漏召更贵）。多标签场景下要说明用精确匹配还是部分匹配，是否区分「必选标签」和「可选标签」。测试集构造要交代来源与分布：从线上真实请求抽样脱敏，按意图、难度、是否多意图分层，人工标注标准答案并记录标注口径；再补对抗样本（含糊指代、拼写错误、体系外描述、应当拒识的样例）。参考答案的来源要说实话：优先由业务专家标注，模型只做预标注、由人确认，绝不能只用模型自己生成的数据评自己。评分方式三层交叉：规则判定能客观核对的（格式、标签是否在体系内）、模型评审（按维度打分并给理由，注意位置与长度偏差，成对比较要交换顺序）、人工抽检作为校准基准。最后把评测集与评分口径一同版本化，指标才可比较。

评测看最终答案还是看工具调用过程

只看最终答案会把「碰巧答对」算成能力：工具选错、参数凑错、检索用了无关文档但答案恰好正确，这类成功不可复现。所以评测要拆成可独立观测的几层：意图识别是否正确、工具选择与参数是否正确、调用顺序与步数是否合理、最终答案是否忠实于工具返回与检索内容、有没有该拒答时硬答。落地的轨迹断言用软断言（期望工具集合、关键参数包含关系、步数上限、必须出现的中间产物），不要逐字比对；答案层用规则加模型打分再人工抽检校准。前提是每一步的工具名、参数、返回摘要、耗时都落库，没有 trace 就谈不上过程评测。文本回答、工具调用、长程任务要分开建集与分开看指标，混在一个总分里，涨跌会互相抵消。

为什么选 Plan-and-Execute，为什么不直接用工作流

Plan-and-Execute 的价值是把「规划」和「执行」解耦：先一次性产出结构化计划，再逐步执行，每一步的输入输出可被校验、可被重试；相比 ReAct 的「想一步做一步」，它减少了模型调用轮次和上下文增长，也更容易在计划层做人工确认与审计，所以延迟与成本更可控。对照组是固定工作流：如果问题空间和动作空间都固定、路径可穷举，工作流几乎总是更好的选择——确定性、可测、便宜。判据是任务路径能否预先枚举、输入的变化是否影响步骤顺序、失败代价多高。所以回答时要说清边界：路径固定就用工作流；路径随输入变化但仍可先规划后用确定性步骤执行，就用 Plan-and-Execute；只有必须根据中间结果反复试探（信息获取不确定、需要实时反馈）才上 ReAct。追问「延迟降低来自哪里」要诚实归因：主要来自模型调用次数减少与上下文变短，其次才是并发工具调用、流式返回、缓存与更小的模型；最好给出对照实验数据，而不是笼统说优化了架构。

MCP、REST API、Function Calling 与 Skills 文档的区别

三者不在一个层面上。REST API 是给人写的接口约定，鉴权、分页、错误码都按人类开发者习惯设计；模型直接读接口文档去调，能跑但每次都要在上下文里塞一堆说明，参数拼错无人拦。Function Calling 是模型侧的机制：你把参数 JSON Schema 交给模型，它产出结构化的调用意图，执行仍由你的程序完成——它解决了「怎么表达调用」，没解决「工具从哪来、怎么复用、怎么授权」。MCP 是协议与运行时约定：工具（或资源、提示）由独立的 Server 暴露，客户端动态发现与调用，鉴权、能力声明、传输层都有统一约定，好处是工具与模型厂商解耦、可跨应用复用、能按会话授权与审计，代价是多一层进程与协议开销、调试链路更长。把接口说明写成 Skills 文档，本质仍是「把知识塞进上下文让模型照着调」：轻量、无需额外进程，适合少量稳定工具和需要大量业务说明的场景；但发现、鉴权、版本与权限控制都要自己实现，工具一多上下文成本急剧上升。实际选型常是混合：少数高频稳定能力用 Skill 文档承载业务规则，涉及凭据、权限和跨应用复用的能力走 MCP。

三道手撕的要点

「IP + 端口转成 uint64」考的是位运算与边界：IPv4 四个字节各占 8 位拼成 32 位整数，端口 16 位，合起来 48 位放进 64 位整数；要先校验格式与范围（每段 0255、端口 065535），注意无符号数与 Java 没有无符号类型的坑（32 位 IP 用 long 承接 & 0xFFFFFFFFL）。「对折链表」先把链表从中间切开（快慢指针），把后半段原地反转，再与前半段交错合并；奇数长度时中间节点归属哪一半要先说清，并处理空链表与单节点。「随机数生成、均匀抽样」要区分场景：等概率抽样用 rand() % n 会因取模偏差导致不均匀，正确做法是拒绝采样或先缩放到 n 的整数倍；从流式数据里等概率取一个用蓄水池抽样（第 i 个元素以 1/i 概率替换已选），抽样 k 个同理；要求不重复时用部分 Fisher-Yates 洗牌。面试官通常看重你是否主动提「均匀性怎么验证」（卡方检验、大样本频次对照）和边界（n 为 0、k 大于 n、随机源种子）。