05-09 14:36 华为_系统工程师

发布于上海

关注

【面试真题】字节 AI 应用岗

字节 AI 应用岗：一次挂掉之后的「补洞笔记」

简历里是 法律咨询 RAG + 三工具 Agent demo（搜索、计算器、文档查询）。去之前我以为主战场是八股，结果整场几乎没碰 Transformer，全在问 效果凭什么信、数据怎么切、Agent 错了谁兜底、你对公司产品在用什么颗粒度思考。

下面这篇不按面试时间表写——那张表别人已经写烂了。我按 「如果重来，我会怎么准备」 的顺序，把当时没接住的题，补成一份可以对着改的参考答案；只在章节末尾用一两句带一下「当时卡在哪」，避免整篇读起来像流水账复盘。

0. 这类岗实际在筛什么（先立坐标系）

应用向 AI 岗（偏 Agent / RAG / 产品化落地）常见误区是：把「能跑 demo」当成项目深度。面试官心里往往有一条很简单的分水岭：你能不能同时讲清 离线链路（数据→索引→评测） 和 在线链路（路由→工具→失败→观测），并且两边都能 用实验或设计说明白取舍，而不是报一个孤立的 Recall 数字。

下面五块是我事后重排的「准备顺序」：业务与产品感知 → 评测与实验 → Agent 工程 → RAG 与领域文本 → 面试表达与自检。你可以打乱自己的复习顺序，但内容上最好别缺角。

1. 业务与产品：别在最后一题才「现查」

1.1 「字节做 AI 应用最大的瓶颈是什么？」——可以怎么答

空泛答「算力、数据」等于没答。可以选 一条主线 + 两条辅线，把「瓶颈」落到 组织与产品能动作的事 上，例如：

主线：迭代速度与风险控制的张力。 模型能力涨得快，但 上线节奏 往往卡在 内容安全、合规、舆情与责任边界；真正能规模化的是 可复用的评测与灰度机制，而不是多训几个 prompt。
辅线一：端到端成本结构。 长上下文、多轮工具调用、重排与二次生成，延迟和钱 会先把体验压穿；瓶颈可能是 架构侧缓存、检索剪枝、模型级联，而不是单纯「再买卡」。
辅线二：数据闭环。 用户真实 query 分布漂移、bad case 回流是否进 标注与训练管线，决定你能不能 周级迭代；没有闭环时，「数据不够」只是表象。

答的时候不必全塞满，选你真有感触的两点，能举 豆包 / 扣子 / 飞书智能伙伴 里任意一个 你亲手用过的具体痛点（例如插件调试、工作流限流、回答保守导致可用性下降），可信度会高很多。

1.2 「豆包、扣子你用过吗？扣子是 Agent 平台还是工作流平台？」——完整说法

豆包：面向 C 端对话与多模态消费 的产品；面试里适合用来举例 安全对齐、人设、工具开放度与体验取舍。

扣子（Coze）：更接近 「低代码搭对话应用」：对话、知识库、插件（API）、工作流（可视化编排）、定时任务、多渠道发布。它有 ReAct / 函数调用 这类「Agent 能力」，但产品重心是 可编排、可运营、可发布，不是给研究员手搓一个 完全自主规划、任意改记忆结构 的通用 Agent OS。

和「纯工作流平台」的边界：扣子 强绑定对话与 bot 形态，工作流块常作为 对话中的一步或后台任务；传统意义上的 BPM/ETL 工作流（与企业审批流深度耦合）并不是它的主叙事。和「纯 Agent 框架」的边界：LangGraph、AutoGen 等更偏 代码级状态机与多角色协作；扣子降低的是 搭建与分发成本，牺牲一部分 任意拓扑与可测试性（当然也在进化）。

面试里一句够用的话：「扣子是有 Agent 能力的 对话应用搭建与工作流编排混合体；我会按场景选 对话内轻规划 还是 工作流强约束，而不是默认端到端 ReAct。」

1.3 我当时怎么挂的

业务题答成 填空题，产品只停留在 名字层面，被追问扣子定位时 脑子空白。这一题本质是：你有没有把「投递的公司」当成研究对象用过。

2. 评测与实验：Recall@5 = 0.81 凭什么「好」

2.1 面试官真正想听的是什么

他们想听的是：指标定义是否自洽、样本是否有代表性、对比基线是否公平、结论是否可复现。单点 0.81 没有 参照系 和分层，在工程语境里接近无效。

2.2 评测集：100 条够不够？分布怎么设计

够不够取决于 置信区间与决策粒度。100 条手工标注在 早期对比两种 chunk 策略谁更好 时可能够用；若声称「上线级可靠」，通常要 扩量 + 分层 + 时间切片验证（避免全在同一天标的同质化）。

分布建议（法律咨询 RAG 举例）：

维度	为什么要分
问法长度	短问（关键词）vs 长问（事实叙说）检索行为不同
是否需要多跳	单法条 vs 跨条/跨文档推理（若你系统不支持多跳，要在分布里标出来）
文档类型	法条、司法解释、合同模板、判例摘要
难度	直述条号 vs 口语化同义表述
时间/修订	是否容易检索到已废止版本（安全类 bad case）

构造方法：从真实日志 分层抽样 + 主动挖掘（低相似度点击、用户改写 query）+ 对抗样本（易混淆条号、近义词条款）。

2.3 Baseline 矩阵（至少能画这张表）

方案	作用
A. 无 RAG，直接生成	看幻觉率、法条引用错误；作「天花板伤害」对照
B. 全文 BM25 / 稀疏检索 only	验证向量是否真带来增益；很多法条场景 BM25 很强
C. 向量检索，无 rerank	隔离 embedding + chunk 的贡献
D. + cross-encoder rerank	看 precision 是否换得来延迟
E. hybrid（稀疏+稠密 + RRF）	工业界常见默认之一

解读 0.81：要在同一评测集、同一 k、同一 query 预处理 下报告 A～E 的曲线；若 BM25 已经 0.78，向量拉到 0.81 未必值得上线上成本。

2.4 指标别只报 Recall@k

检索侧：Recall@k、MRR、nDCG@k（若有多级相关性标注）；Hit@k 与 「首条是否命中」 对法务场景有时更敏感。
生成侧：引用一致性（生成中的条号/款号是否出现在上下文）、拒答是否合理（无依据时是否乱编）。可 人工 rubric（几分制 + 细则），或 LLM-as-judge（必须写清：评委模型偏见、与人工相关性、仅作辅助）。
端到端：可分 「检索对但生成错」 与 「检索错」，否则你只知道一个总分，无法指导迭代。

2.5 迭代闭环怎么说才像「做过产品」

准备 bad case 台账：每条记录 query、gold 文档 id、top5、根因标签（切分碎、别名、向量语义漂移、rerank 误杀等）→ 对应改法（改 parser、加同义词表、上 hybrid、调 temperature 等）→ 回归评测。面试里 念三条真实形态的 bad case 比背指标定义加分得多。

2.6 我当时怎么挂的

没有 baseline、没有分层、只有一个 Recall@5。补全上面任意两层，同一轮对话质量会完全不一样。

3. Agent：工具、路由、反思失败三次之后

3.1 「用 ReAct 让模型自己选工具」不够，还要补哪几层

（1）意图与路由（减方差）

轻量：规则 + 关键词 + 小型分类器（甚至embedding 最近邻）先粗分「要不要走计算器 / 是否必须查档」。
重一点：结构化输出（JSON schema）强制 tool_name 在枚举内；参数校验（数字格式、日期范围）在 调用前 由代码校验，不交给模型「自觉」。

（2）执行层：超时、重试、幂等

搜索类：超时、HTTP 重试、结果条数上限、敏感词过滤。
计算器：沙箱或白名单运算，避免代码注入。
文档查询：权限与租户隔离（面试里点到为止也很加分）。

（3）Reflection 到底检什么

要说清：检 工具是否选对、参数是否合理、证据是否支持结论 中的哪几项；每多一轮反思 延迟与 token 成本 多少，有没有 早停条件。

3.2 「反思失败三次以后怎么办？」——一份可直接说的状态机

用文字描述即可，不必背代码：

第 1～2 次失败：缩小搜索空间——改写 query、强制换工具（例如从「通用搜索」切到「仅法规库」）、或 降低模型温度 再试。
第 3 次仍失败：进入 降级策略（择一或组合，面试前选好你的「默认套餐」）：
- 只检索不生成：返回引用片段列表，让用户自己读；
- 固定安全话术：「当前材料不足以结论，建议咨询执业律师」；
- 转人工 / 工单：带 session id 与工具调用 trace；
- 硬熔断：MAX_STEPS 到达即停，避免死循环烧预算。
全程：结构化日志（每步 thought、tool、args、observation hash）便于离线复现。

3.3 伪代码级参考（面试白板够用）

state = INIT
fail_reflect = 0
while steps < MAX_STEPS:
    plan = model.plan(messages, allowed_tools=TOOL_ENUM)
    if not validate(plan): 
        messages.append(correction_hint); continue
    obs = execute(plan)  # with timeout / sandbox
    if reflection_ok(plan, obs):
        return finalize(obs)
    fail_reflect += 1
    if fail_reflect >= 3:
        return degrade_modes[FALLBACK_POLICY]  # 检索列表 / 固定话术 / 人工

关键是 FALLBACK_POLICY 是你设计过的，而不是沉默。

3.4 我当时怎么挂的

只会说 ReAct + reflection，被追问 第三次失败 时没有 可执行兜底，等于控制流 未定义。

4. RAG 与法律文本：「第三条第二款」和「第三条之二」

4.1 问题本质

固定 512 token 滑窗，极易在 款、项、引用条文 处切断；条号相似 还会导致检索 近邻混淆。面试官问的不是 token 数字，而是：你有没有把「法条是一个结构化对象」写进索引设计。

4.2 切片：从「字符窗」到「法条对象」

（1）结构解析优先

利用 PDF 书签/目录、Word 样式标题；扫描件则 OCR + 版面分析（标题块、正文块）。
正则 + 状态机 识别常见中式条号：第\\s*\\d+\\s*条、第[一二三四五六七八九十百]+款、（[一二三四五六七八九十]+） 等（按你语料微调）。

（2）层级 chunk 策略（推荐叙事）

父块：以「条」或「节」为父单元，保留完整语义，用于 粗检索 或 给模型拼上下文。
子块：超长条再按 款/项 或 固定 token 二次切，用于 细检索；子块 metadata 必须带父 id 与条号。
overlap：放在 同条内部 做滑动，尽量避免跨 不同条 的大 overlap；若必须跨条，用 较小 overlap + 检索后按条号重组。