ai · 面试题库

输出 schema、超时重试、拒答状态、版本绑定；schema 合法还要做业务校验。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

需要。schema 只保证形状，ID、金额、权限、引用真实性必须由业务代码校验。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

记录完整 messages、模型和 prompt 版本、检索结果、原始输出、finish_reason、token、耗时和 trace_id。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

结构化任务通常低温；创意任务可高温。通常只调一个，并用多次评估观察方差。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

优先按标题、段落、表格和代码结构切；检索小块、生成返回父块，并保留元数据。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

补全多轮指代、拆分多意图、弥合口语和文档术语差异；简单单轮问题可跳过。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

区分摄入、召回和排序问题；用 BM25+向量混合检索、扩大候选、元数据过滤和 rerank。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

先用双塔快速召回，再用交叉编码器对少量候选精排，换延迟和成本提升相关性。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

沿 trace 检查解析、过滤、召回、排序、上下文组装和生成；手工置顶正确片段做对照。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

用 eval 测，不追求越多越好；材料要少而准，受 token 预算、相关性和成本约束。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

模型只输出受控引用 ID，服务端映射并校验真实 chunk；无法定位就不展示引用。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

用更新时间和内容哈希检测变更，先写新块再删旧块；换 embedding 模型时建新索引切 alias。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

只有路径需要动态决策时才用；能枚举的流程用工作流，Agent 必须有步数、预算和超时上限。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

字段少而明确，枚举和单位写清，描述边界和副作用；代码层仍要校验参数。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

区分参数错、瞬时错和永久错；分别修参、有限退避重试或换方案，结果不能盲信。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

记录状态和工具调用，设置最大步数、重复动作检测、预算和超时，达到上限返回已完成部分。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

任务简单、上下文共享多或协调成本高时更差；先用单 Agent 或确定性工作流。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

不信自报；要求文件、URL、记录 ID 等可验证凭据，并由主流程实际读取校验。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

区分当前上下文、会话历史、长期用户事实和外部知识；写入要有来源、时间、权限和过期策略。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

手工覆盖核心路径，再把线上失败、拒答和用户反馈脱敏加入回归集。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

只能作辅助；先用人工样本校准，检查偏差和一致性，关键指标仍需人工或规则复核。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

测有依据陈述率、无依据率、引用准确率和拒答率，同时看完整性，不能只压幻觉。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

版本化，跑快速集和全量集，做灰度和回滚；模型、prompt、schema、索引版本要绑定。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

拆 trace 找瓶颈，再做上下文裁剪、小模型路由、并行、缓存和异步；所有方案在同一 eval 集比较。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

key 包含 query、租户、权限、模型、prompt 和索引版本；敏感和实时数据谨慎缓存并支持失效。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

检索内容和工具结果都是不可信数据；权限由代码强制，工具最小权限，副作用操作需确认。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

function calling 是一次调用中的工具声明；MCP 是跨应用发现和访问工具、资源、提示的标准协议，不自动授予权限。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

工具描述也不可信；做来源白名单、schema 校验、最小权限、出网控制、审计和高风险确认。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

检索前按租户和 ACL 过滤，缓存、历史、索引和日志都带权限维度，返回前再次校验引用。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

前置过滤安全但可能损失召回；后置过滤只能兜底，不能替代前置 ACL。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

保留页码坐标，表格保留表头并分组，图片保存描述和位置；解析产物要可追溯。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

分别评估 OCR、表格结构、图片字段、检索 Recall@k、引用定位和最终事实正确率。

追问：请结合真实项目说明一个失败现象、排查依据和取舍。

Agent 工程实现（简历高频词的兑付层）

一个 while 循环，每轮把「完整对话历史 + 工具 schema 列表」发给模型，看返回类型分流：返回纯文本就结束循环；返回 tool_calls 就执行工具、把结果以 role: "tool" 追加进历史、进下一轮。历史是累积的，所以第 N 轮模型能看到前面所有工具的输入输出。

四个必须自己处理的地方，缺一个就会在线上暴露：

• 终止条件：除了「模型返回文本」，还要有最大轮次上限。模型可能反复调同一个工具不收敛，没有上限就是无限账单。
• 并行工具调用：一轮里模型可能返回多个 tool_calls。无依赖的要并发执行再一起塞回，串行做会让延迟翻几倍。
• 工具报错也要回灌：工具抛异常时，把错误信息当作工具结果返回给模型，让它自己决定改参数重试还是换路子。直接把异常抛给用户，等于放弃了 Agent 的自愈能力。
• 消息角色严格交替：assistant 发起的 tool_calls，每一个 tool_call_id 都必须有对应的 tool 消息回应，缺一条整个请求会被 API 拒绝。

上下文会随轮次线性膨胀，这是 Agent 成本的主要来源 —— 一个 20 轮的任务，第 20 次调用要把前 19 轮的工具输出全部重发一遍。所以要么压缩历史，要么把大块工具输出落盘只回灌摘要。

追问「你的循环跑到第几轮会失控，怎么发现的」：说得出具体轮次和现象才算做过。典型答案是「工具返回了一个几万字符的结果，第 8 轮开始每次请求都是 9 万 token，延迟从 3 秒涨到 40 秒」，对应的修法是超过阈值的工具输出写文件、只回灌路径和前 200 字。答不出具体数字就是没上线过。

不能全塞进 context —— 100 个工具的完整 schema 轻松上万 token，每轮都发一遍，而且选项越多模型越容易选错。

两级加载是标准做法：系统提示里只放「名字 + 一句话触发条件」的清单，模型判断相关了再调一个 load_tool / read_skill 把完整说明取回来。代价是多一轮往返，收益是 context 从上万降到几百 token。

让「选对」这件事真正成立，靠的是描述而不是数量：

• 描述写触发条件，不写功能。「Use when <什么情况>」比「一个查询天气的工具」有用得多 —— 模型是在做匹配，不是在读产品手册。
• 前 50 个字符决定命中率。清单里通常只截断显示开头，触发词必须前置。
• 重叠的工具要写清边界。两个功能相近的工具，各自的描述里要点明「什么时候该用另一个」，否则模型会随机挑。
• 分组或按场景过滤。当前任务明显只涉及某一类时，只暴露那一组。

评估方式是建一个「问题 → 应该选哪个工具」的标注集，跑准确率。没有这个集合，「选得准」就只是感觉。

追问「工具数量从 20 涨到 100，选择准确率掉了多少」：这题的价值在于承认存在退化。诚实的答案是「掉了，尤其是描述相近的那几个」，然后给出你的应对 —— 合并近似工具、重写触发词、或者按场景分组。回答「没影响」的候选人，通常是没测过。

不可信，这个数字本身就是要被追问的地方。

语义缓存的原理是把问题转成向量，新问题进来先算相似度，超过阈值就直接返回缓存答案。真实业务里的命中率通常在 30%–60% —— 用户问法千变万化，能被判定为「语义相同」的比例有限。

99% 只有三种解释：

• 请求高度重复。比如固定几个模板化的定时任务在跑。这时候高命中率是业务特征，不是技术成果，说出来反而暴露场景单一。
• 相似度阈值定得太松。阈值降到 0.7 命中率会飙升，代价是「北京今天天气」和「上海明天天气」被判成同一个问题，返回错答案。命中率和错答率是一组此消彼长的指标，只报前者等于没报。
• 统计口径把不该算的算进去了。最常见的是把「prompt 前缀缓存」（provider 侧对相同前缀 token 的复用，是计费优化）和「语义缓存」（跳过整次调用）混成一个数。前者命中率确实能到 90% 以上，但它省的是钱不是调用。

所以被问到时，正确的答法是先说口径：命中率的分母是什么、阈值多少、错答率是多少、有没有做人工抽检。报单一数字不报口径，面试官会认为你没参与实际度量。

追问「阈值调低 0.05，命中率和错答率各变多少」：这题只有真跑过 A/B 的人答得出。要能说出「阈值从 0.85 降到 0.80，命中率涨了 12 个点，但抽检发现 3% 的答案答的是相邻问题，最后收回到 0.83」这种带回退过程的答案。

ReAct 是边想边做：每轮让模型输出「思考 → 动作」，看到结果再决定下一步。Plan-and-Execute 是先出完整计划，再逐条执行。

选择依据是任务的步骤能不能提前确定：

• 探索型任务（排查线上问题、在陌生代码库里找东西）用 ReAct。计划在第二步就会因为看到实际情况而作废，提前规划是浪费。
• 步骤固定的流水线（文档批处理、多阶段内容生成）用 Plan-and-Execute。计划可以校验、可以给人审、失败能从断点续跑。
• 长任务常混用：先出粗粒度计划，每一步内部用 ReAct 展开。

各自的失效方式要说得出来：ReAct 容易在两个动作间反复摆动不收敛（A 查不到查 B，B 查不到又回 A），需要给最大轮次和「重复动作检测」。Plan-and-Execute 的问题是计划一旦基于错误假设，后面每一步都在错误方向上执行，所以每步执行完要校验前提是否还成立，不成立就重新规划。

追问「你的 Agent 在什么情况下会来回打转，怎么止住的」：答案要具体到检测手段 —— 比如记录最近 N 轮的 (工具名, 参数) 指纹，重复出现就强制让模型换策略或直接终止。答「加了最大轮次」只是兜底，不是解法。

这类数字是简历里最容易被拆的地方，因为它需要四个前提同时成立，缺一个数字就不成立。

成功的定义谁给的。是规则判定（有没有产出、格式合不合法）、模型判定（LLM-as-judge）、还是人工标注？三种口径的绝对值差很远。模型判定还要说清 judge 用的哪个模型、和人工标注的一致率是多少 —— 一致率没测过，82% 就是另一个模型的主观分。

样本是多少、怎么抽的。50 条和 5000 条的置信区间完全不同。抽样方式更关键：如果 45% 是早期真实流量、82% 是后来自己挑的测试集，两个数没有可比性。

有没有对照组。中间可能同时换了模型、改了 prompt、加了检索。不做变量隔离就说不出提升来自哪一项，面试官追问「哪一步贡献最大」就答不上。

基线怎么测的。45% 是上线前实测的，还是事后回忆的？回忆值不能当基线。

诚实的表述方式是把口径写进句子：「在 300 条人工标注的测试集上，首条产出通过审核的比例从 45% 提升到 82%，主要来自检索召回改进（贡献约 20 个点）和输出 schema 约束（约 12 个点）」。这样说反而更有分量 —— 它证明你参与了度量，不只是拿到了一个结论。

追问「这 300 条测试集里，改动之后新挂掉的有几条」：真做过评估的人一定见过「整体涨了但某类退化」的情况。答得出「有 7 条原来对的变错了，都是长文档的场景，因为分块变小之后上下文断了」，可信度立刻不一样。答「全都变好了」基本等于没做过对比。

抽一层统一的调用接口，把差异关在适配器里，业务代码只认自己的抽象。需要处理的差异比想象的多：

• 协议形状。OpenAI 的 chat completions、Anthropic 的 messages、以及各家的推理字段（reasoning_content 之类）结构都不同。
• 工具调用格式。参数是 JSON 字符串还是对象、流式下增量怎么拼、finish_reason 叫什么，各家不一致。
• 计费口径。有的把缓存命中的 token 单独计价，有的不区分，成本核算要按供应商分别算。
• 失败语义。同一个 429 可能是限流（该退避重试）也可能是余额耗尽（重试无意义），要按供应商映射成自己的错误类型再决定重试策略。

切换机制上，主用一家 + 失败降级到备用是最小可用形态。三个坑：

降级链只对特定错误生效。限流、5xx、连接错误该降级；但「HTTP 200 但流是空的」这种不会触发任何重试逻辑，请求会一直挂着 —— 这是实际会遇到的最难查的一类。

能力不是按供应商而是按模型。同一家、同一个 key、同一分钟，模型 A 流式非流式都通，模型 B 只有流式能用，模型 C 直接无可用通道。所以不能因为一个模型能用就推断同家的其他模型能用。

降级会静默改变行为。备用模型的能力和风格不同，用户会感觉到「今天回答变差了」却找不到原因。所以每次调用要记录实际使用的供应商和模型，否则事后无法归因。

追问「切到备用之后，怎么知道自己切了」：答案是可观测性 —— 每次调用落一条含供应商、模型、token、延迟的日志，异常降级发告警。说不出记录了什么字段，就说明线上出问题时只能靠猜。