场景判断题
这一类题考的是“该不该用某技术”。好答案不是报技术栈，而是先判断任务性质，再讲选择理由和边界。
答题方法
面试遇到“把全公司邮件接入 Agent”时，先问数据范围、权限和删除要求，再判断是否需要 RAG；若只是固定格式的日报，规则和模板可能比 Agent 更稳。
场景判断题固定按三步答：
- 先判断任务是否需要 LLM / RAG / Agent / 多 Agent。
- 再说明最小方案。
- 最后说升级条件。
Q1：用户问“公司年假制度是什么”，该用 RAG 吗？
参考答案
应该优先用 RAG，因为年假制度属于企业内部知识，可能更新，且需要来源。最小方案是按权限检索制度文档，返回答案和引用。
不应该直接让模型凭记忆回答，因为模型不知道公司内部最新制度。
Q2：用户问“2 + 3 * 5 等于多少”，该用 Agent 吗？
参考答案
不需要复杂 Agent。可以直接代码计算，或者一个简单 calculator 工具。Agent 适合多步不确定任务，这种确定性计算不应该交给模型发挥。
Q3：用户问“帮我调研某家公司近三个月动态”，该怎么做？
参考答案
适合调研 Agent。它需要搜索、筛选来源、判断时效、整理证据、生成报告。最小流程是：拆子问题 -> 搜索 -> 证据归一化 -> 可信度检查 -> 带来源报告。
Q4：用户问“把这段文本改成 JSON”，需要工具调用吗？
参考答案
通常不需要工具调用，可以用 structured output。除非需要查询外部系统、校验实体 ID 或写入数据库，否则模型结构化输出即可。
Q5：用户问“订单什么时候到”，该用 RAG 还是工具？
参考答案
应该用工具查订单系统。RAG 适合知识文档，订单状态是实时业务数据，必须调用业务 API。
可以同时用 RAG 查物流政策，但订单状态本身不能靠知识库回答。
Q6：用户问“退款规则是什么”，该用 RAG 还是工具？
参考答案
如果只是查政策，用 RAG。如果要判断某个订单能不能退款，需要先用工具查订单状态，再结合政策判断。
这是典型的 RAG + Tool 组合场景。
Q7：客服 Agent 能不能自动退款？
参考答案
默认不能直接自动退款。退款属于写操作和资产变动，至少需要身份校验、政策判断、金额展示、用户确认和审计。高金额或异常情况还要人工确认。
Q8：公司要做内部知识库，是否必须用向量数据库？
参考答案
不一定。小规模 FAQ 或结构化文档可以先用关键词检索或数据库查询。文档规模大、表达多样、语义检索需求强时，再引入向量库或混合检索。
Q9：FAQ 数量只有几十条，要不要上 RAG？
参考答案
可以不上完整 RAG。几十条 FAQ 用规则、关键词或简单相似度就够。RAG 的工程成本包括切分、索引、更新、评估和权限，不一定划算。
Q10：文档有严格权限隔离，能不能先检索再过滤？
参考答案
不能。权限过滤应该在检索前或检索时完成。否则无权限内容可能已经进入候选、rerank 或 prompt，存在泄露风险。
Q11：用户上传一份合同，让模型总结风险，要不要 RAG？
参考答案
如果只处理当前上传合同，可以用长上下文或文档解析后直接总结。如果还要对照公司条款、法律模板或历史合同库，就需要 RAG。
Q12：用户问“这个报错怎么修”，该用 RAG 吗？
参考答案
看场景。如果是通用错误，可以模型直接回答或查公开资料。如果是公司内部系统错误码，应该检索内部文档、日志或知识库。若要查实时服务状态，还要接工具。
Q13：代码审查 Agent 能不能直接改 PR？
参考答案
默认只评论，不直接改。自动改代码需要版本检查、补丁范围控制、测试验证和人工确认。否则很容易覆盖用户代码或引入新问题。
Q14：调研报告需要多 Agent 吗？
参考答案
不一定。简单调研单 Agent 就够。只有当任务包含明显阶段，比如调研、写作、审校、事实复核，并且每个阶段可独立验收时，才值得拆多 Agent。
Q15：什么时候用 Reflection？
参考答案
适合高价值输出，比如报告、审校、代码 review、引用核查。简单问答不必加 Reflection，因为它会增加成本和延迟。
Q16：什么时候用 Plan-and-Execute？
参考答案
适合阶段清晰的复杂任务，比如自动调研、数据分析、迁移方案。简单工具调用不需要先规划，否则会过度设计。
Q17：什么时候用小模型路由？
参考答案
当请求量大、任务类型差异明显时适合。小模型可以先做分类、意图识别、风险判断，把复杂任务交给大模型。
Q18：什么时候不该用大模型？
参考答案
确定性规则、简单计算、权限判断、金额计算、状态查询都不该靠大模型。大模型适合语言理解、生成、复杂判断，但确定性和安全边界应交给代码。
Q19：什么时候需要 LLM Gateway？
参考答案
当系统接入多个模型、多个团队、多个 Agent，且需要统一限流、路由、日志、成本统计和降级时，就需要 LLM Gateway。小 demo 不必一开始就建网关。
Q20：什么时候用 GraphRAG？
参考答案
当问题强依赖实体关系、多跳推理、组织结构或文档之间关系时可以考虑。普通 FAQ 或政策问答不一定需要图谱，普通 RAG 更简单。
Q21：什么时候需要人工接管？
参考答案
涉及高风险动作、用户投诉、证据不足、权限异常、模型连续失败、输出低置信度时都需要人工接管。人工接管不是失败，而是系统可靠性的一部分。
Q22：什么时候该拒答？
参考答案
当请求越权、要求泄露敏感信息、要求危险操作、没有足够证据却要求确定结论时，应该拒答或转人工。
Q23：什么时候该说“不知道”？
参考答案
检索不到证据、工具返回失败、来源冲突无法裁决、问题超出系统边界时应该说不知道。强行回答会制造幻觉。
Q24：什么时候需要缓存？
参考答案
高频重复请求、稳定 prompt 前缀、固定工具定义、重复检索结果都适合缓存。强动态、强个性化、敏感信息多的请求要谨慎缓存。
Q25：什么时候需要微调？
参考答案
当已有大量高质量样本、任务格式稳定、few-shot 成本太高或效果不稳时，可以考虑微调。知识更新类问题优先 RAG，不要用微调硬塞知识。
Q26：什么时候只用规则就够？
参考答案
字段校验、权限判断、金额阈值、敏感词检查、格式校验、状态流转等确定性逻辑，规则更合适。LLM 不该替代确定性代码。
Q27：什么时候需要多轮检索？
参考答案
复杂问题、第一轮证据不足、问题需要拆子问题、或者查询依赖上一步结果时需要多轮检索。多轮检索要有次数限制，否则成本容易失控。
Q28：什么时候用 rerank？
参考答案
当召回候选很多、top-k 相关性不稳定、生成上下文位置有限时，需要 rerank。小规模 FAQ 或召回本身很准时可以先不上。
Q29：什么时候用混合检索？
参考答案
当文档里有编号、错误码、术语、API 名称、人名、合同条款号时，混合检索通常比纯向量更稳。
Q30：什么时候需要输出引用？
参考答案
事实性、合规、政策、企业知识库、调研报告、法律金融医疗相关场景都需要引用。引用让答案可追溯，也能约束模型少编造。
Q31：用户要“实时显示答案”，应该直接流式输出吗？
推荐回答
是否流式输出取决于输出是否可安全地边生成边展示。普通总结、解释和低风险草稿可以流式输出，能降低用户感知等待；涉及引用核验、金额、审批结论、医疗法律建议或外部写操作时，应该先完成证据校验、规则校验或工具确认，再展示关键结论。
工程上可以分段流式：先显示“正在检索/正在查询订单”等状态；正文逐字流出；引用和最终操作按钮在验证完成后再出现。用户点击取消时要同时取消模型流、下游工具请求和队列任务，不能只停止前端显示。
Q32：企业要把所有历史邮件接给办公 Agent，应该立即全量入 RAG 吗？
推荐回答
不应该直接全量入库。邮件里包含个人隐私、附件、转发内容和可能的恶意指令，且很多邮件与用户任务无关。先要确认数据所有权、授权范围、保留期限、可检索人群和删除机制；再按用户或团队做隔离，解析正文与附件时做敏感信息处理，最后只索引允许搜索的字段和文件。
如果目标只是“根据当前会话生成回复”，更小的方案是只读取用户显式选择的邮件；只有确实要跨历史语义检索时才建设 RAG。检索过滤必须带邮箱/组织/文档 ACL，不能先召回全量邮件再过滤。
Q33：Agent 是否可以在测试通过后自动合并代码？
推荐回答
默认不可以。测试通过只能证明覆盖到的用例没有失败，不等于代码符合业务、权限、兼容性和发布策略。比较稳的渐进路线是：先只生成 review 建议，再生成 patch；由 CI、静态检查和沙箱测试验证；最后由具备权限的人确认合并。
如果确实对低风险仓库开放自动合并，也要限制到受保护分支之外、变更白名单、测试和安全扫描全绿、无冲突、明确 code owner 同意的范围，并保留一键回滚。不要让模型自己判断“风险很低”就绕过规则。
Q34：知识库回答质量不稳定，是先换更大 embedding 模型还是先做评估？
推荐回答
先做最小评估和问题切片。否则换模型后即使看起来变好，也不知道是 embedding、chunk、query、rerank 还是测试样本变化导致的。至少要区分：召回不到、召回到了但排序差、证据足够但生成乱编、无答案却硬答、权限过滤错。
当评估明确显示语义召回不足，并且 chunk、metadata、关键词召回和 query 改写都合理时，再比较 embedding 模型。模型选择同时看召回指标、中文/多语种能力、维度、索引成本、延迟和版本迁移成本，不是只比参数量。
Q35：用户要求“把所有操作都自动完成，不要再问我”，应该怎么做？
推荐回答
先把操作分级。读取、分析、草稿可在权限范围内自动执行；发送邮件、改日程、退款、删除数据、对外发布等有副作用动作不能仅因用户一句总授权就永久放开。可以让用户在清晰 scope 内授予短期、可撤销的授权，例如“本次会话可代为创建不含外部参与者的会议草稿”，但真正提交前仍按风险策略确认。
这不是体验问题，而是最小权限和可追责问题。系统还要让用户看到即将执行什么、影响谁、能否撤销，并记录授权依据。
Q36：要做多模态合同审核，应该只把 PDF 图片交给视觉模型吗？
推荐回答
不应该只依赖视觉模型。合同审核通常需要文档解析、版面结构、OCR 质量、条款定位、企业模板对照、版本差异和风险规则。更合理的链路是：先提取文字和页码/坐标，保留图片供表格、签章和复杂版面复核；对条款做结构化切分；再用规则、RAG 和模型判断；最后将风险结论回链到具体页码和原文。
当扫描质量差、印章/表格是关键信息或存在手写内容时，视觉模型价值更高；当目标是查固定条款、版本差异和权限规则时，结构化文本和规则往往更稳定。高风险法律结论必须标为辅助审阅，交给专业人员确认。