AI 项目场景题

场景 1：企业知识库问答经常答错，怎么排查？

面试官可能这样问：

公司做了一个 RAG 知识库，但用户反馈经常答非所问。你会怎么排查？

回答思路：

• 先看检索结果，而不是先调模型。
• 检查文档是否成功入库、切分是否合理。
• 看 query 是否需要改写。
• 看 top-k 是否合适，是否需要 hybrid search。
• 看是否需要 rerank。
• 看 Prompt 是否要求基于资料回答和引用来源。
• 建评估集持续对比效果。

项目化解释：

真实 RAG 项目里，很多“模型答错”其实是“没检索到正确资料”。我会拿用户的 bad case 回放，先看召回的 chunk 是不是相关。如果召回就错了，优先调切分、embedding、关键词检索和 rerank。

如果召回正确但回答错了，再看 Prompt 是否过长、是否混入冲突资料、是否要求模型不知道就拒答。

追问点：

chunk size 怎么选？

根据文档结构和问题粒度选择。太小会丢上下文，太大检索不准且占 token。常见做法是按标题、段落、表格边界切分，再用评估集调参。

rerank 解决什么问题？

rerank 用更强的相关性模型对初次召回结果重新排序，解决 embedding 召回结果“有点相关但不是最相关”的问题。

如何评估 RAG？

拆成检索评估和生成评估。检索看正确资料是否被召回，生成看答案是否准确、是否基于资料、是否有引用、是否能拒答。

如何处理权限文档？

向量入库时把租户、角色、部门、文档权限写入 metadata，检索时先按权限过滤。不能先检索全量内容再让模型判断能不能看。

场景 2：AI 客服回答很自信但编造内容怎么办？

面试官可能这样问：

AI 客服有时候会编造政策，用户看起来还以为是真的。你怎么降低风险？

回答思路：

• 要求模型只基于检索资料回答。
• 检索不到明确答案时拒答或转人工。
• 输出必须带引用来源。
• 对高风险领域做规则校验。
• 建立人工审核和 bad case 回流。
• 调低随机性，控制输出格式。

项目化解释：

比如客服问“这个产品能不能退款”，如果知识库没有明确政策，模型不能自己猜。我会在系统提示里要求“资料未提及时回答无法确认”，同时让后端判断检索结果分数低于阈值时直接转人工。

对于退款、合同、医疗、法律这类高风险问题，还应该加规则或人工确认，不让模型单独做最终判断。

追问点：

只靠 Prompt 能解决幻觉吗？

不能。Prompt 可以降低幻觉，但还需要可靠检索、引用来源、规则校验、低置信度拒答和人工兜底。

引用来源怎么做？

检索结果要保留文档 ID、标题、页码、段落、URL 等 metadata。生成答案时把引用和内容一起传给模型，并要求按来源标注。

低置信度怎么判断？

可以结合检索分数、rerank 分数、召回数量、答案是否有引用、模型自检结果和历史评估阈值。低于阈值时拒答或转人工。

哪些场景必须人工兜底？

法律、医疗、金融、退款、合同、权限变更、删除数据等高风险场景必须人工确认或审核，不能让模型单独决定。

场景 3：Agent 调错工具，甚至要执行危险操作怎么办？

面试官可能这样问：

一个 AI Agent 可以查订单、发邮件、修改工单，但它偶尔会调用错误工具。你怎么设计安全边界？

回答思路：

• 工具权限最小化。
• 工具描述要清晰，参数 schema 严格。
• 高风险操作必须二次确认。
• 限制最大调用次数和执行时间。
• 工具返回结构化，减少模型误解。
• 记录 trace 和审计日志。

项目化解释：

比如“修改订单地址”这种操作，我不会让 Agent 直接执行。它可以先查询订单、生成修改草稿，然后让用户确认。确认后后端再校验权限、订单状态和参数合法性，最后执行。

Agent 适合做辅助决策和流程编排，但不能绕过业务规则。

追问点：

Function Calling 和 Agent 有什么区别？

Function Calling 是一次结构化工具调用方式；Agent 是围绕目标进行多步规划、调用工具和观察结果的流程。Agent 可以使用 Function Calling。

MCP 在这里能解决什么？

MCP 可以把订单、工单、邮件等工具以统一协议接入，让 Agent 更标准地发现工具、读取资源和调用能力。

如何防止 Agent 无限循环？

限制最大步骤、最大工具调用次数、最大耗时，并检测重复调用和无进展状态。失败时返回原因或转人工。

如何做工具调用审计？

记录调用人、工具名、参数、返回结果、耗时、模型版本、确认信息和 requestId。高风险操作要能追溯是谁确认的。

场景 4：AI 功能上线后成本暴涨怎么办？

面试官可能这样问：

AI 总结功能上线后 token 成本很高，你会怎么优化？

回答思路：

• 统计每个功能的调用量、输入 token、输出 token。
• 控制 Prompt 长度。
• 对重复内容做缓存。
• 简单任务用更小模型。
• 长文档先分段摘要再合并。
• 设置用户限流和配额。
• 对低价值请求降级。

项目化解释：

我会先加可观测性，知道钱花在哪里。比如发现每次总结都把整篇文档和历史对话塞进去，那就先做上下文裁剪，只保留必要内容。

如果同一篇文档被多人重复总结，可以缓存摘要结果。对普通摘要用小模型，对复杂分析再用强模型。

追问点：

如何监控 token？

按功能、用户、租户、模型、请求类型统计输入 token、输出 token、调用次数和成本。异常增长要能告警并追到具体功能。

模型路由怎么做？

根据任务复杂度选择模型。简单分类、改写、摘要用小模型，复杂推理、代码、长文档分析用强模型，也可以失败后升级模型重试。

缓存会不会影响准确性？

会。缓存适合稳定问题和重复内容，不适合实时数据、权限敏感或频繁变化的内容。缓存 key 要包含用户权限、文档版本和参数。

如何平衡成本和质量？

先定义质量底线，再用小模型、上下文裁剪、缓存、批处理和限流降本。核心链路保证质量，低价值请求可以降级。