十三、项目实战与场景深挖
这一章不考新知识，考的是"你有没有真做过"。题目全部围绕你自己的项目展开，标准打法是提前准备框架化的叙事模板、量化数据和可深挖的技术细节——临场组织语言一定不如提前排练。
129. 详细介绍一个你做过的 LLM / Agent 项目：业务背景、整体架构、我的贡献、上线效果数据。
必刷·中等
参考答案
用"背景 → 架构 → 贡献 → 数据"四段式回答，总时长控制在 2~3 分钟，细节留给追问。
第一段 · 业务背景（约 20 秒）：一句话讲清"谁、什么痛点、为什么用 LLM 解决"。要准备的素材：业务规模（日请求量、用户数）、旧方案瓶颈（人力成本、响应时长、覆盖率）、为什么 RAG / Agent 是合理选型而不是硬蹭热点。
第二段 · 整体架构（约 40 秒）：按数据流讲，不要按团队分工讲。通用骨架：接入层（网关、鉴权、限流）→ 理解层（意图识别、Query 改写）→ 检索 / 工具层（向量库 + BM25 混合检索，或工具编排）→ 生成层（模型选型、Prompt 管理）→ 治理层（评估、监控、审核）。技术栈点到为止，如"Milvus + Qwen + LangGraph"，面试官感兴趣自然会追问。
第三段 · 我的贡献（约 30 秒）：说清负责哪一层、关键决策是什么、和谁协作。团队项目要主动讲清边界——架构是我主导的，还是我实现了其中检索层？不含糊揽功，面试官一定会交叉验证。
第四段 · 效果数据（约 20 秒）：至少两个维度的量化指标：效果类（解决率、采纳率、准确率"从 X 到 Y"）+ 工程类（P95 延迟、成本降幅、人工工作量减少）。给对比，不要给孤立数字。
避坑提醒：数据要经得起"怎么测的"追问，提前想好指标口径；不要把 Demo 说成生产系统——灰度过程、峰值 QPS、线上事故这些生产细节编不出来；架构图要能徒手画，每条连线都能解释为什么这样连。
面试官可能追问
- 这个架构里最难的一层是什么？（自然过渡到下一题）
- 为什么选这个数据库 / 这个模型？当时做过什么对比？
- 上线后出过什么事故？怎么发现、怎么解决的？
130. 项目深挖必问：这个项目技术上最难的三个点是什么？分别怎么解决的？
必刷·较难
参考答案
这题决定面试官对你技术水平的最终判断，选材标准比表达更重要。
三个点的选材标准（要差异化，不要同质）：
- 技术深度型：涉及算法或系统层面的真问题，如"多轮对话下 Query 指代消解做不好导致检索召回率低"——体现你能定位到根因；
- 工程权衡型：涉及 trade-off 决策，如"推理成本压不下来，最终用小模型路由 + 语义缓存砍掉约 40% 成本"——体现约束下的取舍能力；
- 落地协作型：如"生成质量没有 ground truth，推动搭了 LLM as Judge + 人工抽检的评估闭环"——体现你能把项目推过终点线。
避开这三类素材：太琐碎的 bug（改改参数就好了）、纯业务问题（需求反复变更）、自己没深度参与的部分。
叙述结构用 STAR 变体：情境（问题现象 + 量化影响）→ 难点（常规方案为什么不行）→ 行动（分析过程 → 候选方案对比 → 最终选择及理由）→ 结果（量化改善 + 沉淀复用）。重点放在"候选方案对比"，这是区分背答案和真做过的关键。
常见深挖链路（每一环都要提前备好答案）：
- 检索效果差 → 怎么定位是召回还是精排问题？→ 用什么指标切分的？→ 为什么不用 GraphRAG？
- 生成不稳定 → 是模型问题还是 Prompt 问题？→ 怎么归因的？→ 评估集多大、怎么标的？
- 成本高 → Token 账单怎么拆的？→ 缓存命中率多少？→ 小模型路由的准确率怎么保证？
避坑提醒：不要选"Prompt 调了很久"这类没有技术含量的难点；三个全讲检索优化显得视野窄；被追问到第三层答不上时，坦诚说"这块是同事主导、我了解的结论是 X"远好过硬编。
面试官可能追问
- 这个方案有没有副作用或代价？
- 如果流量涨十倍，这个解决方案还成立吗？
- 事后看有更优解吗？为什么当时没选？
131. 如果重新做这个项目，你会改进哪些设计？为什么当时没这么做？
高频·中等
参考答案
这题同时考复盘能力和诚实度。框架：给 2~3 个改进点，每个按"现在会怎么做 → 为什么当时没做 → 通用教训"三步走。
改进点选材方向（按可信度排序）：
- 架构债：如"当初检索和生成耦合在一个服务里，应该早点拆成独立检索服务，让索引更新不影响在线问答"；
- 基础设施后补：如"Prompt 硬编码在代码里，应该一开始就上配置管理 + 版本化，后来一次误发布改坏了线上 Prompt 才补课"；
- 技术演进：如"当时用固定管道 RAG，现在看部分场景适合 Agentic RAG，让模型自主决定是否补充检索"；
- 可观测性：如"上线初期没有全链路 trace，排查 bad case 全靠翻日志，接入 Langfuse 之后才有轨迹回放"。
"为什么当时没做"只有三种站得住的理由：时间约束（MVP 优先验证业务价值，欠债是有意决策）、认知局限（当时业界还没有成熟方案）、信息不足（用户使用模式要上线后才能拿到）。一个可以说认知局限，三个全是就是能力问题。
避坑提醒：不要说"没什么可改进的"——显得没有复盘习惯；不要把责任推给前公司、同事或老板——只描述约束，不抱怨；不要选"换个模型 / 换个框架"这种一键替换式改进——没有思考含量。
收尾加一句方法论沉淀："这个项目让我建立了 X 原则，比如先搭评估再调效果"，把单个项目的复盘上升为通用能力。
面试官可能追问
- 这些改进后来真的落地了，还是停留在想法？
- 怎么避免下一个项目再欠同样的债？
- 给你两周和两个工程师，你先做哪个改进？为什么？
132. 智能客服场景：怎么平衡"解决问题"和"转人工"？拒答和兜底策略怎么设计？
高频·中等
参考答案
核心思路：知道边界比展示能力更重要。框架分三部分——路由决策闸门、兜底分级、指标闭环。
"解决 / 转人工"的三道决策闸门：
- 前置意图分层：进对话前先做意图分类——闲聊 / 标准咨询 / 复杂投诉 / 情绪激动 / 敏感话题。标准咨询走 LLM 通道；复杂投诉和敏感话题直接或快速转人工，不让模型硬扛；
- 置信度动态判断：回答附置信信号（检索相似度、多采样一致性、自评置信），低置信且高价值的问题（退款、账号安全）主动转人工；
- 多轮失败检测：用户重复表达不满、同一问题追问超过 N 轮、出现投诉关键词，命中即转，且转接时带上完整对话摘要，不让用户复述。
拒答和兜底分级：
- 有据拒答：知识库无依据时回答"未能查到，为您转接人工"，给用户下一步出口，而不是硬编答案；
- 降级回答：模型超时 / 限流时回退到 FAQ 精确匹配或标准话术模板；
- 安全兜底：涉政、医疗、法律等高风险域直接走预设应答 + 强制人工。
指标闭环：核心三联指标——一次解决率（FCR）、转人工率、转人工后投诉率。只压转人工率会把用户激怒成投诉，三个要联看。经验参考：LLM 客服的合理目标是机器人独立解决率 50%~70%，其余丝滑转出，而不是追求 100% 机器人化。
避坑提醒：转人工最大的体验杀手是"上下文丢失导致用户复述"；转接要同步对话摘要 + 情绪标记 + 已排除的原因，让坐席接手即可行动。
面试官可能追问
- 拒答率多高算健康？阈值怎么定？
- 置信度怎么量化？模型自报的置信可靠吗？
- 用户一句"转人工"就绕过机器人，要不要拦？
133. 企业知识库场景：文档更新频繁怎么办？多部门权限隔离怎么做？
中频·中等
参考答案
两个子问题分开答，各给机制再给取舍。
文档更新频繁——增量更新 pipeline：
- 变更感知：对接文档系统 webhook 或定时增量扫描，拿变更事件（增 / 改 / 删），不做全量重跑；
- 细粒度更新：以文档为单位维护 chunk 哈希指纹，编辑后只重新解析和重嵌入变化的 chunk，未变的向量直接复用——全量重嵌入的成本可能是增量式的几十倍；
- 版本与软删：向量记录带文档版本和状态字段，先写新版本再原子切换生效，删除做软删，可回滚；
- 一致性兜底：检索结果返回前校验源文档版本，不匹配的丢弃重检。秒级到分钟级的更新延迟在知识库场景通常够用，实时性要求高再考虑双写。
多部门权限隔离——两条路线：
- 逻辑隔离 + 检索前过滤（主流）：chunk 上带部门权限元数据，检索时强制 pre-filter，只返回用户有权限的结果。存储集中省资源；代价是强过滤会收窄向量检索的候选池、可能伤召回，需要调大 top-k 或选用支持过滤感知检索的引擎；
- 物理隔离（分 collection / 分库）：部门独立索引，权限模型最干净，但部门一多资源和管理成本爆炸，适合部门少且合规要求极高的场景。
权限判定必须收口在数据接入层和检索层，业务代码无法绕过。
避坑提醒：权限要管到 chunk 级而不是只到文档级——一篇文档可能只有一节涉密；员工调岗等权限变更要快速生效，权限缓存别超过分钟级；千万不要把权限校验只放在 Prompt 里（"不要回答无权限的内容"）——那是软约束，会被注入绕过。
面试官可能追问
- 文档更新后多久能被检索到？这个延迟怎么权衡？
- 权限过滤为什么会影响向量检索质量？怎么缓解？
- 一篇文档部分章节涉密，接入时怎么处理？
134. 数据分析 Agent 场景：怎么让模型可靠地生成 SQL？生成错了怎么兜底和自纠？
中频·较难
参考答案
按"事前降低出错率 → 事中硬拦截 → 事后自纠"三层作答。
事前 · 让模型一次写对：
- Schema 供给：不给全库几百张表，先做 schema linking——按业务域拆分，用 Query 和表 / 列注释做相关性检索，只注入相关的几张表结构，附列值样本（枚举值、日期格式）；
- 语义层：把业务口径固化成指标定义（如"活跃用户"的精确计算逻辑），模型面向语义层生成查询而不是裸表——这是可靠性的最大杠杆；
- Few-shot：给 3~5 个典型 Query→SQL 样例，重点覆盖多表 join 和时间窗；
- 约束生成：只读分析场景强制只输出 SELECT，禁止 DML / DDL。
事中 · 执行前硬校验：
- 语法解析（AST）+ 白名单校验：表、列必须真实存在，操作类型受限；
- EXPLAIN 代价预估：扫描量过高直接拒绝，防止一个笛卡尔积打挂数仓；
- 执行侧隔离：只读账号 + 查询超时 + 结果集上限，分析库和生产库物理隔离。
事后 · 错误自纠循环：
- 执行报错（语法错、表不存在）→ 把数据库错误信息回传重新生成，最多 2~3 轮——数据库报错是最有效的自纠信号；
- 结果合理性校验：行数为 0、数值异常（环比涨 100 倍）、答非所问 → 触发结果自查 Prompt，让模型核对"生成的 SQL 是否回答了用户问的问题"；
- 自纠失败 → 降级为澄清反问（"您是指近 7 天还是本月？"）或转人工，带上已尝试的 SQL 便于排查。
量级参考：受限业务域（schema linking + 语义层 + few-shot）的执行准确率经验上能到 80% 以上；开放域裸奔可能掉到一半以下。核心结论：用工程手段收窄问题空间，而不是指望模型本身。
面试官可能追问
- 多表 join 经常出错怎么办？
- 怎么防 SQL 注入和越权查数据？
- 准确率怎么评估？测试集怎么建？
135. 代码助手场景：补全、问答、重构任务的技术方案有什么不同？仓库级上下文怎么给？
中频·较难
参考答案
先分任务对比，再讲仓库级上下文这个公共难题。
三类任务的技术差异：
| 维度 | 补全 | 问答 | 重构 |
|---|---|---|---|
| 触发方式 | IDE 内自动触发 | 用户显式提问 | 框选 / 指令触发 |
| 延迟要求 | 极高（300ms 级，慢了打断心流） | 秒级可接受 | 分钟级可接受 |
| 上下文 | 当前文件 + 光标前后代码 + 最近编辑 | 检索到的相关代码片段 | 目标符号的全部引用点 |
| 技术要点 | FIM（Fill-in-the-Middle）补全模型、行级截断、触发概率阈值 | 代码 RAG：切分 + 检索 + 生成 + 引用 | 静态分析（LSP 找引用）+ 规划执行循环 + 批量 diff |
| 主要难点 | 误触发、补全接受率 | 仓库状态同步、答案可信 | 跨文件一致性、编译测试验证 |
仓库级上下文方案（核心是"按需检索"而不是"全量塞入"，百万行仓库远超任何窗口）：
- 建仓库索引：按函数 / 类等语法单元切分（不是固定行数），保留签名、import 依赖、文件路径等元信息；对函数名、类名再建符号级倒排索引；
- 多路召回融合：当前文件 import 链 + 光标处引用符号的定义（LSP 精确定位）+ 语义向量检索相似片段 + 最近打开文件，去重后按 Token 预算装箱；
- 结构优先：目录树、模块依赖摘要压缩到千级 Token 常驻上下文，让模型先有全局地图，细节按需展开；
- 新鲜度：文件保存 / 切换时增量更新索引，避免检索到过期代码。
避坑提醒：补全和问答不要共用一个模型——补全用专用 FIM 小模型追延迟，问答用对话模型追质量；重构类任务必须有编译 + 测试反馈环，没有验证的重构建议是灾难。
面试官可能追问
- 补全的接受率怎么统计和提升？
- 代码检索和普通文本检索有什么不同？
- monorepo 里多语言、多构建体系怎么处理？
136. 你的项目上线后效果怎么样？怎么证明收益是 LLM 方案带来的而不是其他因素？
高频·中等
参考答案
考的是量化思维和归因严谨性。框架：先报数据，再讲归因方法，最后坦诚边界。
第一步 · 分层报效果数据：业务指标（解决率、CSAT、人工工作量下降）→ 产品指标（采纳率、留存、使用频次）→ 技术指标（P95 延迟、幻觉率、单次成本）。给"基线 → 现值"对比，如"人工日均处理 2000 单，上线后机器人分流约 60%，整体响应时长从小时级降到秒级"。
第二步 · 归因方法（本题核心）：
- A/B 测试（最硬的证据）：同质用户分组，对照组走旧方案（FAQ / 人工），实验组走 LLM 方案。说清分流单位（按用户 ID 哈希，避免同一用户来回切换污染数据）和观察周期（覆盖周内周期性，通常 1~2 周起）；
- 前后对比 + 控制混杂变量：没条件 A/B（如全量切换）时，用上线时间点前后的同期对比，并剔除同期运营活动、流量结构变化的影响——这是弱证据，要主动说明；
- 中间量拆解：记录每单由 LLM 独立解决 / 辅助解决的比例、LLM 回答被采纳的比例，把"LLM 起作用"的链路拆开证明，而不是只看大盘涨跌。
第三步 · 坦诚边界：主动说哪些收益不能全记在 LLM 头上——响应时长下降可能部分来自流程改造，满意度提升里可能有新功能尝鲜效应。敢划掉混入的收益反而加分。
避坑提醒：不要只报好转不报代价（Token 成本、bad case 率）；数字要能回答统计口径（样本量、周期、显著性）；如果上线时连埋点和基线都没有，说明度量没设计，这本身要承认并反思。
面试官可能追问
- A/B 测试的分流怎么做？观察期多长、怎么定？
- 效果好但成本高，两个指标冲突时怎么决策？
- 上线后指标回落过吗？怎么发现和归因的？