深信服 Java 一面：RAG 答不出就说不知道、Agent 里做资金扣减怎么设计

《面试题目》

1. RAG 中并没有检索到目标 chunk，但 LLM 给出了回答，这个回答无法判断是否正确，怎么办？
2. 那怎么提高答案的覆盖率？
3. 假如现在有一个 Agent，其中有一些创建订单或者资金扣减的操作，你要怎么设计这个 Agent？
4. 假如在调用 MCP 的时候失败了，你会怎么处理？
5. 你在实习中有自己从需求提出到落地的实践吗？遇到的难点有哪些？
6. 邮件识别是怎么做的？
7. 你更倾向于传统项目还是 Agent 项目？为什么学 Agent 相关技术？
8. 你的项目是从 0 到 1 吗，包括部署？
9. 你更倾向于维护成熟项目还是从 0 到 1 开发新项目？

《参考解析》

检索不到还硬答

这是 RAG 最典型的事故形态。三层处理：检索层加阈值，相似度低于阈值的 chunk 不进上下文，同时把「检索为空」作为一等信号传给生成层；生成层在提示词里明确「只能基于给定资料回答，资料不足时回答不知道并说明缺什么」，并强制引用片段编号；出口层做校验——答案里出现的数字、专有名词如果不在引用片段中，就拦下来转人工或降级为「未找到依据」。评测上要专门维护一组「知识库里没有答案」的负样本，看模型是不是在编。

提高覆盖率

分召回与表达两侧。召回侧：切分按语义而不是定长、加父子块（小块召回、大块喂给模型）、混合检索（BM25 + 向量）加重排、做 query 改写与多查询扩展（同义、拆子问题）、把高频问答对直接做索引。表达侧：允许模型做受控归纳而不是逐字摘抄；对表格、图片先结构化再入库。业务侧还有一条常被忽略的：把「用户问不到」的样本回流，每周看零召回查询，补语料比调参有效得多。

涉及下单和资金扣减的 Agent

原则是「模型提方案，代码做决定」。具体四件事：一是把危险动作做成受控工具，工具只能调固定签名的接口，参数有类型和白名单，金额、账户这类关键字段不接受模型自由生成，必须由用户显式确认后从上下文取；二是加人工确认节点（human-in-the-loop），超过阈值金额、首次收款账户、批量操作一律走二次确认；三是幂等与补偿，每个动作带 requestId，重复调用不重复扣款，失败要有反向冲正；四是全链路审计，记录模型输入、决策理由、工具入参与结果，出问题能回溯。再叠一层权限：Agent 的服务账号只授予它真正需要的最小权限，用户越权由后端业务校验拦住，不能靠 Agent 自觉。

MCP 调用失败

分三类处理。可重试的（超时、5xx、限流）做指数退避重试，带次数上限和 jitter；不可重试的（参数错误、鉴权失败）不重试，直接把结构化错误交回模型，让它在同一轮里改参数或换工具；结果未知的（写了但没拿到响应）走幂等键查状态，绝不盲目重发。上层还要有降级：关键工具不可用时给用户明确提示，而不是让模型自己编一个结果。

邮件识别

典型做法是解析（MIME 解码、正文抽取、附件文本）、结构化（把邮件头、发件人、主题、时间、正文分别取出来）、抽取（LLM 按 schema 输出字段，如订单号、金额、诉求类型，用 JSON schema 约束）、校验（正则兜底关键字段、与业务系统对账）、路由（按类型分派给对应流程）。工程重点在失败处理：解析失败进人工队列、抽取置信度低就转人工，不要静默丢弃。

其余几问

「从 0 到 1 还是维护」没有标准答案，但要给出真实偏好和理由，并说明你在两种场景里各自做过什么。职业规划讲两年内的能力目标（把一个方向做深 + 能独立负责一条链路）比讲职级更可信。