外观
RAG、Agent 与 AI 工程高频一问一答
定位｜ 本页不是通用概念摘抄，而是围绕简历项目“企业内部系统与客服业务增强检索知识库”训练 18 道高频题。回答统一落到业务问题、本人决策、验证证据和事实边界。
目录
1. 项目口径与证据边界
面试中以“客服问某笔已锁订单今天能不能退款”为贯穿案例。这个问题不是找一段语义相近的文字就结束，而是要同时识别“锁单”等业务术语，确定订单、商品和渠道，读取当前订单状态，匹配当前有效制度，执行权限过滤，最后区分“解释规则”和“真正退款”。
回答时使用以下结构：
业务冲突是什么 → 我在链路中的具体决策 → 为什么不用更简单的方案 → 如何验证 → 当前证据边界
事实边界： 当前仓库可以证明结构化知识治理、版本管理、项目方案和评测设计；BM25、Dense Retrieval、Reranker、订单状态 API、线上 Trace、压测数据及客服业务收益仍属于参考实现或业务演练。面试时可以讲“我设计了、计划这样验证”，不能说成“已经上线并提升了某个指标”。
2. 项目能力链
图：技术调用流程｜客服退款问答从证据检索到受控行动
替代文本： 客服问题先经过术语、实体和实时状态解析，再执行权限与规则条件过滤、混合召回和业务重排；LLM 只生成带引用的解释，退款等高风险动作必须进入确定性接口和人工审批，整条链路由 Trace、评测和版本清单约束。
图表加载中…
读图结论： 这个项目的核心不是“向量库加大模型”，而是把业务术语、实时状态、规则版本、权限和确定性动作放进同一条可验证链路。
3. RAG 方向
Q01｜为什么用混合检索？纯向量在什么场景会翻车？
项目化回答： 在客服知识库里，我不会只用向量检索。比如问题里有订单号、错误码、商品型号或“锁单”这种内部术语，BM25 更容易保住精确词；用户说“被冻结的单子能不能撤销”，Dense Retrieval 又更擅长找到“锁单退款规则”这种同义表达。所以我设计 BM25 与 Dense 并行召回，用 RRF 做秩融合，再按订单实体、当前状态、规则有效期和权限重排。纯向量会在数字只差一位、新旧规则语义相似、否定条件、领域新词和长 Chunk 主题稀释时翻车。简历里我强调的不是“用了混合检索”，而是它服务于“精确标识 + 语义改写 + 规则适用性”三类冲突；效果要用同一标注集比较 Recall@K、MRR/NDCG、规则适用率、延迟和成本，当前没有实测提升数字。
Q02｜Chunk 大小怎么定？重叠为什么重要？
项目化回答： 我不会先拍脑袋定成 500 Token，而是从客服回答所需的“最小完整证据单元”反推。退款制度里的“适用条件、处理结论、例外、有效期”必须在一个父块中；错误码要和解释放在一起；表格要保留表头与当前行；操作流程可以按步骤切成子块，但通过
parent_id和section_path回扩完整章节。这样能避免只召回“可以退款”，却丢掉“仅限未锁单、仅适用于某渠道”这类关键条件。Overlap 只用于自然段跨边界、代词指向或上下句共同表达一条规则的情况，不能把整张规则表机械复制，否则会让重复旧制度挤占 Top-k。每个 Chunk 还要带来源、产品、渠道、权限、规则版本、有效期和稳定chunk_id。我会在固定问题集上比较必要证据 Recall@K、最终上下文覆盖率、重复率、截断率、Token 和延迟，再选择窗口与重叠；简历里对应的亮点是IndexManifest同时绑定 Parser、Chunk、Embedding、规则和权限版本，而不是背一个通用 Chunk 数字。
Q03｜重排怎么做、用什么模型、为什么能提升？
项目化回答： 这个项目的重排不能只看“问题和文档语义像不像”。例如旧培训文档和新退款制度都包含“锁单、退款”，纯语义分数可能都很高；我会先用 ACL、商品、渠道和有效期做硬过滤，再让轻量 Cross-Encoder 对
k_rerank候选联合编码，并叠加实体一致性、订单当前状态和规则适用性特征，最后只选k_context条证据。模型可以从 BGE Reranker 一类候选开始做基线，但选择依据必须是本项目固定集上的 MRR/NDCG、正确规则进入最终上下文的比例、P95 延迟和成本。这里要主动说明：Reranker 只能重排已经召回的候选，漏召回的新制度无法靠重排补回来；当前仓库有方案，没有模型对比实测。
Q04｜检索质量怎么评测？Recall@K 和人工标注集怎么建？
项目化回答： 我会从匿名客服 FAQ、制度问法和故障演练中构建问题集，专门覆盖术语别名、订单号或错误码、新旧规则冲突、不同商品与渠道、无答案和越权问题。每个问题不只标“相关文档”，还标必要证据、适用规则、当前业务条件、禁止泄露的证据以及无答案预期。
Recall@K计算 Top-k 找回了多少必要证据，MRR/NDCG 看正确规则的位置，最终还要看规则适用率、引用支持率、空召回率和越权率。关键样本由两人独立标注、冲突仲裁，并按时间切分，避免新制度同时进入训练和测试。简历中的业务指标如建议采纳率、平均处理时长和首次解决率属于上线后的结果指标；当前只能说明指标定义和实验设计，不能虚构改善幅度。
Q05｜知识库更新怎么处理：增量 Embedding，还是全量重建？
项目化回答： 客服制度经常新增或局部修订，普通内容变化我会按稳定
chunk_id + content_hash增量解析和 Embedding，只更新变化块；删除、撤权和过期规则用状态或 Tombstone 传播，并做真值库与索引对账。但如果 Parser、切片策略、Embedding 模型或维度、索引 Schema、权限模型发生变化，就构建全量候选索引，因为旧向量与新向量可能不可比。IndexManifest绑定语料、Parser、Chunk、Embedding、规则和权限版本，新索引先离线回放，再影子验证，最后通过别名原子切换；异常时整套切回旧版本，同时失效包含索引、规则和权限版本的缓存。这样回答能体现简历里的“版本一致性和可回滚发布”，而不是只在增量与全量之间二选一。
Q06｜语义相同但表述不同的问题，怎么保证都检索到？
项目化回答： 我不会承诺所有改写百分之百命中，而是把同义表达纳入业务语义层。例如“锁单、冻结订单、订单被占用、售后处理中”可能接近，但只有结合订单实体和当前状态才能判断是否真是同一概念。我会保留原始 Query 和订单号等精确词，再做带适用范围、有效期和来源的术语归一；BM25 保住精确标识，Dense Retrieval 覆盖口语改写，必要时生成受控 Multi-Query 后做候选并集与 RRF，最后用实体、状态和规则条件重排。评测时把同一意图组织成改写簇，分别统计簇内 Recall@K 和错误归一率。简历中的亮点应表述为“业务术语与实体层 + 混合检索”，而不是泛泛地说“Embedding 能理解语义”。
4. Agent 方向
Q07｜工具返回你校验了吗？不校验会出什么事？
项目化回答： 在“这笔锁单能不能退”的链路里，订单状态 API 的返回不能因为 HTTP 200 就直接交给模型。我会校验 Schema、租户和订单是否匹配、状态枚举、快照时间与版本、权限范围，以及错误码和数据是否完整；工具文本也按不可信输入处理，不能让其中的指令改变系统规则。如果退款接口超时，还要通过业务幂等键或外部任务 ID 对账，因为“已经成功但响应丢失”和“根本没执行”不能都重试。不校验会造成串单、使用过期状态、越权泄露、重复退款，甚至让模型把未知结果说成成功。简历里“概率性解释与确定性执行分离”就是为了解决这个风险。
Q08｜上下文爆了怎么办？短期、长期、结构化三层记忆怎么分？
项目化回答： 我会把当前客服会话、长期知识和订单控制状态分开。短期记忆保存当前问题、最近澄清和已经引用的证据；长期记忆只保存经确认且带来源、ACL、版本和有效期的术语、规则或用户偏好，不能把易变化的订单状态长期缓存；结构化记忆保存
order_id、实体、订单快照版本、当前计划、已完成步骤、审批状态和 Checkpoint。上下文超限时，系统与安全约束、当前订单状态、有效规则和最近用户意图优先，大段工具结果放外部对象，通过 ID 按需读取，旧对话生成可追溯摘要。压缩后还要检查订单号、否定条件和审批状态没有丢失，避免模型在摘要后把“未允许退款”记成“已退款”。
Q09｜模型调用了不存在的接口，怎么兜底？
项目化回答： 假设模型编造了
force_refund_order，Runtime 不能直接拼 URL 调用，而只接受 Tool Registry 中已注册、版本匹配且当前角色有权使用的工具。执行前校验工具名、参数 Schema、租户、订单和风险级别；不存在时返回类型化的TOOL_NOT_FOUND和当前可用工具摘要，允许一次受限纠错。若只有“查询订单状态”和“创建售后申请”，就退回这条受控流程，仍无法完成则明确告知能力边界并转人工，绝不能伪造“退款成功”。我还会用工具契约测试和 Trace 记录模型提出的工具名、注册表版本及兜底路径，把偶发幻觉变成可复现样本。
Q10｜多步规划失败怎么回退？人在环怎么接？
项目化回答： 退款问答可以拆成“确认订单 → 读取实时状态 → 检索有效规则 → 校验适用性 → 生成解释 → 必要时发起售后审批”。每一步都有输入输出契约和 Checkpoint；失败时区分参数缺失、证据冲突、工具超时、权限不足和高风险动作，再从最近可信状态重规划，不整条盲重跑。证据不足就向客服澄清，查询工具失败可有限重试，规则冲突或退款动作必须转人工。人工界面要展示订单快照、命中规则与版本、拟执行动作、风险和可选项，审批决定进入审计状态，后续从原 Checkpoint 继续。这样 Human-in-the-loop 是状态机的一部分，不是“出错了喊个人来看看”。
5. AI 工程方向
Q11｜高并发怎么扛？连接池、限流、队列、批处理分别做什么？
项目化回答： 我会先把链路拆成在线客服问答和离线知识入库，两者不能抢同一资源池。在线侧分别限制订单 API、搜索、Reranker 和模型调用的连接池与超时，按租户和接口限流，超额时优先保留订单查询与安全校验，允许降级为关键词检索或转人工；离线解析、Embedding 和索引构建进入有界持久化队列，通过批处理提高吞吐，并用背压避免拖垮在线服务。容量要基于峰值 QPS、平均服务时间、Token 分布和下游配额估算，验收看排队时间、拒绝率、P95/P99、池利用率、降级率和索引新鲜度。当前项目没有压测证据，所以简历不能写“支持多少 QPS”，只能讲容量设计和待验证方案。
Q12｜成本怎么控？缓存、模型路由、量化分别解决什么？
项目化回答： 我会先按解析、Embedding、检索、重排、生成、工具和人工返工拆出“每个成功解决工单的成本”。知识入库侧通过
content_hash复用未变化文档的解析与 Embedding；在线缓存键必须包含租户、权限、规则、索引、模型和 Prompt 版本，避免把旧制度或其他租户答案复用出来。简单 FAQ 可走 BM25 或小模型，涉及订单实时状态、新旧规则冲突和退款风险的请求才进入混合检索、Reranker 和更强模型。量化只在自托管模型且质量、硬件和算子验证通过时考虑，不是调用第三方 API 的通用开关。所有降本都要守住规则适用率、引用支持率、P95 和人工接管率，不能只看 Token 单价。
Q13｜线上回答错了怎么定位？Trace 怎么设计？
项目化回答： 如果系统引用了旧退款制度，我会沿 Trace 找“正确规则第一次消失”的位置。一次请求至少记录脱敏后的
raw_query、归一化术语、实体 ID、订单快照版本、ACL 与时间过滤条件、各通道候选及分数、RRF 名次、重排分数、最终 Chunk、截断原因、规则版本、Prompt/模型版本、工具调用和审批结果。候选阶段没有新制度，就查入库、索引或召回；候选有但被过滤，查商品、渠道、有效期和权限；重排后消失，查业务特征与硬负例；final_context正确但答错，再查 Prompt、模型和输出校验。Trace 的价值不是日志越多越好，而是能定位首次偏离并用同一失败样本重放。
Q14｜灰度怎么发、指标怎么看、怎么回滚？
项目化回答： 我会用
IndexManifest把语料、Parser、Chunk、Embedding、规则、权限、Prompt 和模型版本组成可追踪发布包。先用历史问题和“旧培训文档压过新制度”等故障集做离线回放，再做影子流量，只给客服建议、不自动触发动作，随后按内部团队或租户小流量灰度并保留控制组。指标分三层：技术层看术语 Recall、正确规则进入上下文的比例、引用支持率和延迟；流程层看建议采纳率和人工接管率；业务层才看处理时长、首次解决率、重复咨询和错误承诺率。红线触发时切回旧别名与旧版本包，并同步失效缓存；不能只回代码却继续使用新索引。当前指标只有定义，没有线上改善数据。
6. 开放题
Q15｜你做的 AI 项目最大挑战是什么？
项目化回答： 这个项目最难的不是接入大模型，而是在“语义相似”之外判断知识是否真的适用于当前业务对象。比如旧培训文档和新退款制度都能回答“锁单能不能退”，但只有结合订单状态、商品、渠道、权限和规则有效期，才能选择正确证据。我把问题拆成业务术语与实体层、实时状态读取、ACL 与条件过滤、混合召回和业务重排，再把解释与退款动作分开；前者要求引用和证据门禁，后者走确定性 API、幂等和人工审批。当前可证明的是知识治理和方案设计，在线指标仍需通过固定评测集、Trace 和灰度取得。这种回答既说明我做了什么，也主动交代证据边界。
Q16｜如果检索结果全是噪声怎么办？
项目化回答： 假设“这单已经锁了，今天能不能先退”召回的全是旧培训文档和无关商品规则，我会先停止自动建议，要求澄清或转人工，不把噪声继续交给模型。随后沿链路查原始 Query 是否被错误改写、“锁单”是否归一错、订单实体和状态快照是否正确、ACL 与商品/渠道/有效期过滤是否生效，再检查 BM25/Dense 候选、RRF、重排、重复 Chunk 和最终上下文。修复可能是恢复新制度索引、补术语范围、纠正过滤、增加旧制度硬负例或调整切片，但必须用同一失败集重放，并报告必要证据 Recall@K、正确规则排名、引用支持率、延迟和成本。直接增大 Top-k 只会把更多噪声塞进上下文。
Q17｜老板说“成本太高”，你怎么降？
项目化回答： 我先用 Trace 把成本拆到入库、检索、重排、生成、业务 API、失败重试和人工返工，并按“成功解决一次客服问题”计算，而不是只看模型账单。第一轮先去掉可确认的浪费：未变化文档不重复 Embedding，FAQ 结果按版本与权限安全缓存，限制上下文和输出长度，合并重复候选，修复失败重试；第二轮做请求路由，普通制度问答走关键词或小模型，涉及实时订单与退款风险才走完整链路；自托管时再评估量化和批处理。灰度时同时看规则适用率、引用支持率、P95、人工接管率和单位成功成本。若成本下降却增加错误承诺或人工返工，就不算优化成功。
Q18｜模型偶尔胡说，怎么不让它伤害用户？
项目化回答： 在这个项目里，我让模型负责“基于证据解释”，不让它成为订单状态和退款结果的真值源。实时状态必须来自受控业务 API，制度回答必须带当前有效规则的引用；证据不足、冲突或越权时只能澄清、拒答或转人工。退款、审批、账户变更等高风险动作进入确定性接口，执行前校验权限、参数和幂等键，必要时人工审批；结果未知时绝不能告诉用户“已经成功”。上线前用无答案、旧规则、越权和提示注入样本做红队测试，上线后监控引用支持率、无依据断言、越权、错误承诺和人工接管，并保留灰度与整套回滚。核心不是消灭所有幻觉，而是让幻觉无法直接变成业务伤害。
7. 深挖入口
| 目标 | 单一事实源 |
|---|---|
| 简历项目正文、指标口径与面试伏笔 | AI 项目简历内容与面试伏笔 |
| 客服增强检索业务链与锁单退款演练 | AI 知识库项目：内部系统与客服增强检索篇 |
| 当前仓库真实能力与线上 RAG 演进边界 | AI 知识库项目 |
| Chunk、Overlap 与索引更新 | RAG 基础链路：数据准备与切片篇 |
| 混合检索、重排与 Query 改写 | RAG 检索优化 |
| 评测、Trace、灰度与回滚 | RAG 评测与生产工程、AI 应用可观测性与 LLMOps |
| 工具校验、记忆与人工介入 | Tool Calling 与工具系统设计、Agent Memory 与 Context Engineering |
8. 总结
一句话记忆： 面试回答要证明这套 RAG 能为当前订单找到真正适用的证据，并让模型解释与高风险业务执行始终处在不同的安全边界。
一分钟面试复述版： 这 18 道题都可以回到同一个项目矛盾：客服问题不仅要语义相似，还要匹配正确实体、实时状态、有效规则、权限和动作边界。我通过结构化 Chunk、BM25 与 Dense 混合召回、业务重排和版本清单保证证据适用，通过 Tool Registry、Schema 校验、Checkpoint 和人工审批约束 Agent，通过分层 Trace、评测、灰度和回滚保证工程可控。当前有证据的是知识治理与方案设计，线上检索指标、并发和业务收益需要真实实现后再验证。
- Chunk 大小由“最小完整业务证据”决定，Overlap 只解决必要的跨边界语义；
- RAG 的目标不是找到相似文字，而是找到对当前订单真正适用的证据；
- Agent 可以提出解释和动作候选，但确定性 Runtime 决定能否执行；
- 成本、并发、Trace 和灰度都要落到同一业务链和可验证指标；
- 面试回答必须同时讲个人决策、替代方案、验证方法与事实边界。