乐堡 AI 应用开发四面面经：RAG 项目深挖、Agent 超时熔断与交叉面

《面试题目》

一面（技术面，约 45 分钟）

1. 自我介绍。
2. 简历上的 RAG 知识库项目，文档是怎么分割的？
3. 召回环节是怎么实现的？
4. 怎么判断召回结果是否准确？
5. 上下文压缩是怎么设计的？
6. Agent 调用工具超时了怎么处理？如果一直失败会不会重复调用，有没有设计熔断机制？
7. Java 基础：HashMap、重载和重写的区别。

二面（技术面，约 40 分钟）

1. 选一个项目深入聊：你是怎么设计的？
2. 遇到过什么问题？
3. 哪些是你自己的思考？
4. 你选这个框架的原因是什么？
5. 有没有对比过其他方案？
6. 一道手撕题（原帖未记录具体题目），写完追问了时间复杂度。

三面（交叉面，约 30 分钟）

1. 最近在学什么新技术？
2. 你怎么看 AI 应用开发这个方向？

四面（HR 面，约 20 分钟）

1. 期望薪资是多少？
2. 为什么选乐堡？
3. 有没有其他 offer 在流程中？
4. 平时有什么爱好？

---

《参考解析》

RAG 项目被深挖时，四道题考的是四个不同的工程判断

「文档怎么分割」不要只答「按 500 字切」。真正的考点是分块策略与检索效果的关系：分块太大，一个 chunk 里混了多个主题，召回时向量被平均掉、命中精度下降，塞进上下文还挤占窗口；分块太小，语义被切碎，答案需要的上下文凑不齐。工程上的常见做法是结构优先、长度兜底——先按文档天然结构（标题层级、段落、表格、代码块）切，再对超长段做滑窗切分并保留 10%~20% 重叠，让跨块句子不被切断；同时给每个 chunk 补上元数据（所属文档、章节路径、标题、页码），检索时既能过滤又能把出处回填给用户。这块的追问点一般是「表格和代码块怎么处理」「重叠会不会导致重复召回」——表格最好转成结构化文本或按行配表头再切，重复召回可以用去重（同文档相邻块做合并）解决。

「召回环节怎么实现」要讲清链路而不是名词：query 侧做改写或扩展（多轮对话必须先结合历史把指代补全，否则「它怎么配置」这种问题召不回任何东西）→ 向量化 → 检索。检索通常是混合检索：向量召回负责语义相近，BM25 或关键词召回负责专有名词、型号、编号这类字面匹配，两路结果用 RRF 之类的融合排序合并，再上 rerank 模型精排取 Top-N。要向面试官主动交代的关键取舍是：向量模型和 rerank 模型是不是同一个、Top-K 取多少、加不加元数据过滤，以及多路召回带来的延迟代价。

「怎么判断召回结果是否准确」是最能拉开差距的一问，因为很多人只会说「看回答对不对」。正确答法是分层建评测集：先人工标注一批「问题 → 标准答案所在文档」的样本（几十到几百条即可起步），用 Recall@K / MRR / Hit Rate 度量召回层——召回层没捞到正确答案，后面再强的模型也救不回来；再用 忠实度（答案是否只依据召回内容）、答案相关性、上下文精度 度量生成层，忠实度可以靠「答案里的每个事实能否在召回片段中找到出处」来判。此外要建回归集与 bad case 回流：线上用户点踩或人工抽查出的坏例，标注后进评测集，每次改分块、换模型、调 Top-K 都跑一遍，否则优化全靠感觉。

「上下文压缩怎么设计」要区分两种目标：一种是省 token 降成本，一种是提精度抗干扰。可行手段包括：只保留与问题相关的句子（用小模型或交叉编码器给候选句打分后裁剪）、把多轮对话压成结构化的对话状态（已确认的事实、未决问题、约束条件）而不是自由摘要、把历史内容存进可检索的外部记忆、按问题动态回灌原文。必须主动说出的代价是——自由文本摘要会丢数字、否定和约束条件，这三类信息丢了比丢一大段无关内容危险得多，所以压缩后要加一道自检（关键实体与数字是否还在），并把「压缩后的多轮任务成功率」纳入评测。

Agent 超时与熔断：这道题答的是分布式系统常识 + 对大模型调用特点的理解

工具调用超时不是「重试几次就好」，要按失败性质分治。第一步是分类：连接超时、读超时、限流（429）、服务端错误（5xx）、参数错误（4xx）含义完全不同——参数错误重试一百次也没用，必须把错误信息回给模型让它改参数；限流要退避；5xx 和网络抖动才值得重试。第二步是重试策略：指数退避加随机抖动（避免所有请求同一时刻重试打爆下游），并设最大次数和总时限，超过就放弃。第三步是幂等性，这也是「一直失败会不会重复调用」的正面回答：写类工具（下单、发消息、扣款）必须带幂等键，服务端按 key 去重，否则重试就是重复扣钱；只读工具重试安全，但仍要限次。

熔断是第四步：按工具维度维护失败率与连续失败计数，达到阈值后进入打开状态，一段时间内直接快速失败不再真实调用，冷却后放行少量探针请求做半开验证，成功再恢复。熔断器一般三态——关闭、打开、半开。再往上一层是兜底与降级：某个工具不可用时，是改用备用工具、改用缓存或静态知识回答、还是明确告诉用户「当前无法完成」并要求人工接手。原帖里面试官点出的正是这一层——生产环境里方向和逻辑对了之外，还要有明确的降级路径和不让错误扩散的边界。另外要提死循环防护：给整个 Agent 设最大步数或最大 token 预算，防止模型在两个工具之间反复试探直到烧穿额度。

二面的项目深挖，考的是「你自己的思考」而不是项目本身

「你选这个框架的原因是什么、有没有对比过其他方案」这类问题，要看穿它在问什么：面试官不是要你背框架对比表，是要确认技术选型是你做的、你有判断依据。可用的答题结构是「约束 → 候选 → 判据 → 结论与代价」：先说清场景约束（团队规模、交付时间、是否需要多模型切换、有没有运维能力），再列出当时比较过的两三个方案，给判据（编排能力、生态与社区活跃度、可观测性、调试体验、锁定风险），最后给结论并主动说出这个选择的代价——比如「选了编排能力强的框架，代价是抽象层多、出问题时排查链路长」。主动认代价比把选型说成完美无缺更可信。原帖作者承认有些地方现在回头看可以做得更好，面试官的反应也说明这轮看重的是思路而不是完美。

手撕题本身原帖没记，但「写完追问时间复杂度」是标准动作：写完之后不要等面试官问，主动报出时间与空间复杂度、说明为什么、再指出可以怎么优化；如果最优解和当前解不同，先给出能跑通的版本再讨论优化方向，比一上来纠结最优解更稳。

交叉面的两道开放题，答的是信息量和方向感

「最近在学什么新技术」不要答「在看大模型相关的」，要给一个具体的、带判断的答案：在学什么、为什么学、动手做过什么、看出了什么问题。原帖作者讲了自己对 Agent 落地的兴趣和在做开源项目——这正是这类问题想要的形态，因为交叉面的面试官通常是另一个组的负责人，他听的是你有没有主动输入的渠道和动手的痕迹。

「你怎么看 AI 应用开发这个方向」这题没有标准答案，但有几个必须避开的坑：不要只说「前景很好」，也不要空谈模型能力。可以按「现在能做到什么 → 卡在哪 → 因此缺什么角色」来搭：模型能力已经不是瓶颈的主要部分，卡点在数据质量、评测体系和与真实业务流程的对接，所以 AI 应用开发的价值在于把不确定的模型能力包成可交付、可评估、可回滚的产品形态。落到自己身上，说清你想做哪一段。

HR 面的四个问题里，真正被记录的是三个数字

期望薪资、为什么选乐堡、有没有其他 offer 在流程中，这三问是一组：HR 要先知道你的价格和你的选择空间，才能判断能不能推进。「有没有其他 offer」不用编也不用全盘托出，给进度和大致范围即可，但要说实话——后续流程里这句话会被反复引用。「为什么选乐堡」要落到具体的东西上（岗位方向、团队在做的业务、培养方式），别只夸公司。

原帖记下的福利信息是：薪资对标头部游戏和互联网公司，全年 13-17 薪，七险一金全额缴纳，另有住房补贴和交通补助；作者提到 HR 还问了平时有什么爱好，并说团队比较看重工作与生活的平衡。这类信息可以直接用来判断预期是否匹配，但薪资口径要以书面 offer 为准，面试口头说的范围只是参考。整份面经的另一半价值在体验层面：面试官会引导、会肯定、会分享真实做法，作者从投简历到拿 offer 大约两周、共四轮；它不能推广成所有公司的常态，但可以作为判断「这家公司在不在认真招人」的参考——四轮里技术面占了绝大部分时间，且都是围绕候选人真实做过的项目追问。