字节跳动大模型算法面经合集：Agent 评测体系、RAG 切分与长程任务评估

《面试题目》

面经 01

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

实习项目：企业内部行政 HR 助手

Agent 迭代与回归评测

1. 做过哪些 Agent 迭代？
2. 如何衡量改动效果？
3. 修好一类 bad case 后，如何发现其他场景是否退化？
4. 评测只看最终答案，还是也检查意图识别、工具选择与调用轨迹？
5. 人工标注的问答评测集如何自动化执行和判分？

RAG 切分与长上下文

6. 原有文档切分有什么问题，为什么按标题组织内容？
7. 规章制度文档可能并不长，为什么还需要切片？
8. 如果已经检索到相关文档，为什么不直接把整篇文档输入模型？
9. 是否实际比较过整篇输入与切片方案？

离线评测与线上观测

10. 是否统计线上有效会话？
11. 真实用户的表现与离线评测结果有什么差异？
12. 如何收集和分析用户负反馈？
13. 如何把线上错例回流到评测集？
14. 是否做过答案自动标注？

复杂任务与长程 Agent 评测

15. 简单问答与 Coding Agent、长程任务的评测有什么不同？
16. 对复杂执行链和复杂产物，如何观察线上效果？
17. 只看最终结果是否足够？
18. 详细讲一下个人项目。

搜索意图消歧

19. 同一查询词可能对应成语、电影、歌曲等不同对象，如何判断用户真正想找什么？
20. 除了语义检索，还能结合哪些信息提高意图判断的准确性？

Agent 框架与自研循环的选择

21. 手写 Agent Loop、使用图编排框架、使用更完整的 Agent SDK 或 Harness，各有什么取舍？
22. 选型前做过哪些调研？
23. 上下文压缩、工具调用与调试能力，是自己实现还是复用现有框架？

通用 Agent 的效果与竞品比较

24. 如果要评估一个覆盖问答、文档、创作等场景的通用 Agent，会怎样拆解任务？
25. 如何利用线上反馈和运行轨迹判断表现？
26. 两个产品的用户输入不同，如何控制变量、进行公平比较？
27. 无法获得竞品后台数据时，如何开展比较？
28. 执行时间长是否一定代表异常？
29. 不同任务是否应使用同一规则？
30. 手撕：实现一个类，输入为两个升序数组，输出合并后的降序数组，要求 O(n)。

面经 02

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

31. 手撕：大数相加、双栈模拟队列（面试官自己写的题目），手写 PPO、DPO、GRPO 公式。

经历、动机与岗位理解

32. 你能稳定实习六个月吗？
33. 你刚去快手不久，为什么又开始找下一段实习？

《参考解析》

Agent 迭代与回归评测怎么做

Agent 的改动天然全链路耦合——提示词、工具描述、模型版本、检索参数任意一处变动都会影响结果，所以每次迭代都要在固定评测集上跑回归。做法是先把线上真实请求抽样成集，标注期望行为：不只是最终答案，还包括该调用哪些工具、关键参数是什么、中间产物是否出现。指标要分层：按意图或任务类型分组统计通过率、平均步数、工具调用成功率、token 与延迟，只看总分会被涨跌互相抵消掩盖。「修好一类 bad case 会不会打坏别的场景」只能靠分层指标回答——某一组掉幅超过阈值就回滚或定向修复。评测集要持续扩充，把线上新错例补进去，否则几个月后它只覆盖老问题；同时固定住评测集与评分口径的版本，否则前后对比不成立。

整篇文档输入与切片的取舍

即便文档不长，切片也有三个作用：把检索单元和生成单元解耦，命中的是具体小节而不是整篇，上下文噪声更少；文档按标题组织，天然对应用户问题的粒度，问哪条制度就召回哪一节；召回可以带出处，答案可回溯，也便于按节增量更新。为什么整篇塞模型不合适：一次召回的往往是三五篇，长上下文下模型对中段信息的利用会明显下降（lost in the middle），token 成本与延迟线性上涨，还容易把不相关条款混进答案。合理链路是「粗召回整篇 → 细粒度挑节 → 按 token 预算拼接」，并且要真的用同一份评测集做过整篇输入与切片方案的对比，而不是靠直觉；切分粒度还可以按问题类型调（条款类要细，叙述类可粗），并用评测集验证。

线上观测与错例回流

先把「有效会话」定义清楚——排除测试流量、用户没提问就关闭的、一次就走的闲聊，否则指标会被噪声稀释。线上看过程与结果两类：无结果率、追问率、放弃率、点赞点踩、平均轮次、工具失败率、P95 延迟；再和离线评测对齐找偏差，常见偏差是线下题目太干净，线上口语化、带错别字，导致离线召回率虚高。错例回流要有固定管道：负反馈与「无结果」会话自动进候选池，人工过一遍并标注归因（意图、召回、生成、资料缺失），再合入评测集。答案自动标注只能当预填，让模型先给候选标签、人只做确认，否则错标会污染整个回归基线。差异分析还要落到维度上：新老用户、问题类型、渠道，看退化的是一类还是一片。

长程任务与复杂产物怎么评

区别在于结果不再是一个字符串。Coding Agent 的产物是可运行的程序，用编译、单测、lint 当客观判据；长程任务的产物是「多步执行链加中间态」，判据随之变成过程与状态：关键步骤有没有做到、中间产物是否符合约束、有没有绕过约束走捷径、失败后能不能恢复。所以评测分三层——终态检查（文件是否生成、测试是否通过）、过程检查（工具轨迹是否符合预期、有没有多余调用）、质量检查（产物本身的可用性与格式）。线上观测尤其难，因为一条会话可能跑很久、用户中途关掉；可行做法是按任务类型埋关键里程碑事件，统计到达率与耗时分布，对超时或中途退出的会话单独归因，而不是一律算失败。回答「只看最终结果是否足够」时，明确说不够，并给出过程判据的可落地形式（软断言而非逐字比对）。

通用 Agent 与竞品的公平比较

拿不到对方后台数据时，唯一能控制变量的办法是自建题集和统一入口：构造覆盖问答、文档、创作等场景的题目集，两端用完全相同的方式提问（同样的提示、同样的轮次限制，记录完整输出与耗时），再用同一套脚本离线判分；评分拆成客观项（格式、事实一致性、是否按要求输出）与主观项（隐藏产品名、随机顺序、多人盲评取一致性）。要特别注意「执行时间长不一定异常」：长任务天然慢，延迟应按任务类型分别看分位数，而不是所有任务用同一阈值；同理，两端默认开启的能力（联网、文件解析、多轮澄清）不同，也要拉齐条件，否则比的是配置而不是能力。拆解任务时按能力维度分组（理解、检索、生成、工具使用、多轮保持），每组给可判定的样例，并记录失败归因，才能回答「差在哪」而不只是「谁分高」。

手撕：O(n) 合并两个升序数组为降序，以及基模公式

合并两个升序数组输出降序，用双指针从两个数组的末尾（最大值）开始比较，把较大者依次放进结果数组的最前面，谁先用完就把另一个剩余部分整体填入——每个元素只被访问一次，时间 O(n+m)，空间 O(n+m)。要点是先讲清指针方向与填充顺序（从后往前填才不用搬移元素），再处理边界（其中一个为空、长度悬殊、相等元素谁先取）。第二场的手写公式属于基模八股：PPO 的目标是带裁剪的代理目标 L = E[min(r·A, clip(r, 1-ε, 1+ε)·A)]，r 是新旧策略的概率比，clip 限制单次更新幅度，配优势估计（GAE）与价值网络；DPO 跳过奖励模型，直接用偏好对构造损失 -log σ(β·(log π(y_w)/π_ref(y_w) - log π(y_l)/π_ref(y_l)))，把「偏好」变成对参考策略的相对概率约束；GRPO 去掉价值网络，对同一 prompt 采样一组输出，用组内奖励的均值与标准差归一化得到优势，再套 PPO 式裁剪目标。手写时把每项的符号、含义与「为什么这样设计」讲出来（裁剪防更新过猛、参考策略防跑偏、组内归一化省掉 critic），比默写公式更能得分。