面试答案手册

大约 73 分钟

AI 应用开发岗详细面试答案手册

先看这个，再开始背

如果你时间有限，先优先看三章：
「一、岗位认知类」->「四、RAG 全链路」->「十、项目表达能力高频题」。

这篇更适合当“系统词典”，不建议从头硬背。
建议搭配 20题逐题追问版和面试标准背诵稿一起使用。

使用建议

第一轮：按模块快速通读，建立整体地图。
第二轮：挑高频题改写成你自己的版本。
第三轮：和模拟问答结合，训练连续表达。

一、岗位认知类

1. 你怎么理解 AI 应用开发岗？

面试官想考什么

看你对岗位的理解是否准确，是否知道这个岗位不是纯算法岗，也不是只会调 API。

标准回答

我理解的 AI 应用开发岗，本质上是把大模型能力接入真实业务场景，做成可用、可上线、可维护的系统。它的重点不在于训练模型，而在于工程落地，包括模型接入、Prompt 设计、RAG、Agent、接口服务、数据处理、异常处理、监控和成本控制等。

这个岗位通常要求候选人既有一定后端开发能力，也理解大模型应用的基本原理，能够把模型和业务系统、数据系统、工作流结合起来，最终解决实际问题。

更像真实面试的展开说法

比如一个企业知识库问答项目，看起来表面上是“调用模型回答问题”，但实际工程链路很长。前面要做文档解析、清洗、切分、向量化和入库；中间要做检索、重排、上下文构造和 Prompt 约束；后面要做流式返回、权限控制、日志监控、异常兜底和成本优化。所以这个岗位更像“后端工程 + AI 应用”的结合，而不是单纯会调一个模型接口。

可能的追问

那它和算法岗有什么区别？
和传统后端开发有什么区别？
你认为这个岗位最核心的能力是什么？

回答加分点

可以补一句：

我认为这个岗位最核心的是工程化思维，要能把模型能力稳定地交付给业务，而不是只跑通 demo。

2. AI 应用开发岗和算法岗有什么区别？

标准回答

AI 应用开发岗和算法岗最大的区别在于工作的重心不同。

算法岗通常更关注模型本身，比如模型训练、微调、评测、推理优化、特征设计、算法效果提升等；而 AI 应用开发岗更关注如何把现有模型能力接入业务系统，解决真实业务问题。

AI 应用开发更强调：

工程实现
系统设计
模型与业务结合
稳定性和成本控制
异常处理和线上维护

算法岗更强调：

模型原理
训练方法
参数优化
数据标注与评估
学术和效果迭代

更真实的说法

比如同样做一个问答系统，算法岗可能会研究怎么训练更好的 rerank 模型，或者怎么优化 embedding 效果；AI 应用开发岗更可能负责整个问答链路怎么搭、怎么接入业务、怎么保证低延迟、怎么做权限控制、怎么应对线上故障。

3. AI 应用开发岗和传统后端开发有什么区别？

标准回答

我认为 AI 应用开发岗是在传统后端开发基础上，新增了大模型能力接入和 AI 特有链路处理。

相同点在于都需要做：

接口开发
数据库设计
缓存设计
消息队列
服务部署
日志监控
异常排查

不同点在于 AI 应用开发还需要处理：

Prompt 设计
RAG 链路
向量检索
模型调用稳定性
结果不可控性
幻觉治理
成本优化
工具调用与 Agent 编排

加分表达

传统后端很多时候是“输入确定、逻辑确定、输出相对确定”；而 AI 应用开发经常会遇到“输入不规范、模型输出不稳定、结果具有概率性”的问题，所以需要更多约束、校验和兜底机制。

二、后端基础与工程能力

4. 为什么 AI 应用开发岗也要重视后端基础？

标准回答

因为大多数 AI 应用项目最终都是以系统形式交付的，而不是以实验形式存在。模型只是其中一个能力模块，真正要落地到业务，仍然需要完整的后端能力支撑。

比如：

要提供 API 给前端或业务系统调用
要存储用户会话、文档数据、日志数据
要做缓存和异步任务
要处理高并发、超时、限流、重试
要做部署上线和线上排障

所以如果后端基础薄弱，哪怕会调模型 API，也很难把项目真正落地。

追问可答

AI 项目很多瓶颈不一定出在模型上，也可能出在：

数据处理链路
检索性能
接口设计
并发控制
服务稳定性

5. 你觉得 AI 应用开发最需要掌握哪些后端能力？

标准回答

我觉得至少包括以下几类：

第一，一门主语言和服务开发框架

Python：FastAPI、Flask、异步编程
Java：Spring Boot、并发、JVM 基础
Go：高并发服务开发

第二，数据库和中间件

MySQL：业务数据、配置数据
Redis：缓存、会话、限流、热点问题缓存
消息队列：异步任务、解耦、削峰
Elasticsearch：全文检索、混合检索场景

第三，部署和运行环境

Linux 常用命令
Docker 容器化部署
基础网络知识
日志查看和问题排查

第四，工程能力

接口设计
异常处理
超时重试
幂等设计
监控和告警

加分点

可以说：

AI 应用开发里，工程基础越扎实，越能把模型能力稳定地产品化。

6. 线上异常怎么排查？能不能给一个通用思路？

标准回答

我一般会按“现象确认 -> 范围定位 -> 日志排查 -> 指标分析 -> 快速止损 -> 根因修复”这个顺序来处理。

展开回答

先确认问题现象
- 是全部用户都有问题，还是部分用户有问题
- 是接口报错、超时、结果异常，还是模型输出异常
定位影响范围
- 某一个接口
- 某个模型服务
- 某个租户
- 某个时间段
查日志
- 应用日志
- 网关日志
- 模型调用日志
- 检索日志
- 数据处理日志
看监控指标
- QPS
- 响应时间
- 错误率
- 超时率
- CPU / 内存
- 第三方 API 成功率
先止损
- 降级到兜底回答
- 切换备用模型
- 暂时关闭高风险功能
- 限流保护
根因修复
- 如果是代码问题就修复发布
- 如果是配置问题就回滚
- 如果是第三方波动就启用容灾策略
复盘总结
- 补监控
- 补告警
- 补自动化测试
- 补兜底方案

加分表达

如果是 AI 应用，我会特别关注问题出在：

模型调用层
检索层
Prompt 层
数据层
前端流式渲染层

三、大模型基础概念

7. 什么是 LLM？

标准回答

LLM 是 Large Language Model，大语言模型。它是在海量文本数据上训练出来的神经网络模型，能够理解和生成自然语言，并完成问答、总结、翻译、分类、代码生成等多种任务。

它本质上是通过学习大量语言模式，来预测下一个 token，因此具备较强的文本理解和生成能力。

展开说法

从应用角度看，LLM 不只是一个聊天工具，它更像一个通用语言能力引擎。通过不同 Prompt、外部知识、工具调用和工作流编排，可以让它完成很多实际业务任务，比如客服问答、文档分析、工单处理、SQL 生成、报告生成等。

追问：它为什么强？

因为它在大规模数据和大参数量下学习到了较强的语言表示能力、上下文理解能力和任务泛化能力。

8. Token 是什么？

标准回答

Token 是模型处理文本时的基本单位，不一定等于一个字或一个单词。模型输入输出、上下文长度、计费方式，通常都是按 token 来计算的。

展开说法

比如一段中文文本，模型不会直接按“句子”理解，而是会先分成一系列 token。输入给模型的是输入 token，模型生成的是输出 token。上下文窗口限制的也是 token 数，而不是字符数。

为什么重要

因为它直接影响：

上下文能放多少内容
调用成本
响应速度
Prompt 设计长度

加分点

可以说：

在 AI 应用开发里，token 是一个非常实际的工程指标，因为它和成本、延迟、上下文裁剪都直接相关。

9. 上下文窗口是什么？

标准回答

上下文窗口指的是模型一次能够处理的最大 token 数，包括输入和输出。超过这个范围，模型就无法完整处理全部内容，或者需要截断。

展开说法

比如一个模型上下文窗口是 32k token，这意味着用户问题、系统 Prompt、历史对话、检索到的知识片段，以及模型输出，加起来都要控制在这个限制内。

实际意义

上下文窗口会影响：

多轮对话保留多少历史
RAG 能拼接多少检索内容
长文档总结怎么分段
成本和时延

追问：上下文太长怎么办？

裁剪历史对话
先做摘要再放入上下文
检索最相关片段而不是全量拼接
分段处理
使用更长上下文模型，但要权衡成本

10. Temperature 和 Top-p 是什么？

标准回答

它们都是控制模型生成随机性和多样性的参数。

Temperature：控制采样分布的“发散程度”。值越低，输出越稳定、保守；值越高，输出越发散、多样。
Top-p：核采样参数，表示模型只从累计概率达到 p 的候选 token 中进行采样。值越小，候选范围越窄，结果更稳定。

应用场景

问答、抽取、结构化输出：通常用较低 temperature，提高稳定性
创意写作、文案生成：可以适当调高，增加多样性

加分回答

在业务里，我会优先根据任务目标来调参数：

如果要稳定 JSON、规则提取，temperature 通常设置较低
如果要开放式生成，才考虑提高 temperature

11. Prompt 是什么？

标准回答

Prompt 就是给模型的输入指令和上下文，用来告诉模型要做什么、按什么规则做、输出什么格式。它不仅包括用户的问题，也包括 system prompt、角色设定、示例、约束条件、上下文信息等。

展开说法

在 AI 应用开发里，Prompt 不是一句简单的提问，而更像“给模型写任务说明书”。一个好的 Prompt 通常需要明确：

角色
任务目标
输入信息
输出格式
约束条件
异常情况处理方式

加分点

Prompt 的本质不是“让模型更聪明”，而是“让模型输出更可控、更稳定、更符合业务要求”。

12. Function Calling / Tool Calling 是什么？

标准回答

Function Calling 或 Tool Calling 是指模型在回答过程中，不直接生成最终答案，而是先根据用户意图选择合适的外部工具或函数，输出结构化参数，再由系统实际执行工具调用，并把结果返回给模型或直接返回给用户。

举例

比如用户问“帮我查一下明天上海天气”，模型本身并不知道实时天气，但它可以判断需要调用天气 API，然后生成类似：

工具名：get_weather
参数：city=上海，date=明天

系统执行这个工具后拿到结果，再让模型整合成自然语言回复。

价值

让模型连接外部实时数据
让模型能执行操作而不只是聊天
提升结果准确性和可用性
方便和业务系统打通

13. 微调和 Prompt Engineering 的区别是什么？

标准回答

Prompt Engineering 是通过优化提示词和上下文来引导模型更好地完成任务，不改变模型参数；微调则是在特定任务数据上继续训练模型，修改模型参数，让模型学会更稳定地完成某类任务。

区别总结

Prompt Engineering

成本低
上线快
灵活
适合快速试验
不需要训练资源

微调

成本更高
需要数据和训练流程
对固定任务可能更稳定
适合长期、标准化、高重复任务

如何选择

一般在应用开发里，会优先尝试 Prompt、RAG、工作流等轻量方案；如果任务稳定、样本充足、Prompt 难以解决一致性问题，再考虑微调。

加分表达

很多业务问题并不是一上来就需要微调，往往先通过 Prompt + RAG + 输出约束就能解决大部分需求。

四、RAG 全链路

14. 什么是 RAG？完整链路是什么？

标准回答

RAG 是 Retrieval-Augmented Generation，检索增强生成。它的核心思想是在模型生成答案前，先从外部知识库中检索与问题相关的信息，再把这些信息作为上下文提供给模型，从而提高回答的准确性，减少幻觉。

完整链路

一个典型的 RAG 链路通常包括：

文档采集
文档解析
文本清洗
chunk 切分
向量化 embedding
向量入库
用户提问
query 改写/扩展
检索召回
rerank 重排
上下文拼接
Prompt 组织
模型生成
结果后处理和返回

更真实的面试表达

RAG 本质上是给大模型“临时开卷考试”。模型本身参数里不一定有企业私有知识，也可能知识过时，所以要先检索，再生成。这样比单纯依赖模型记忆更适合企业知识库、智能客服、文档问答这类场景。

15. 为什么要用 RAG，不直接把文档全塞给模型？

标准回答

主要有四个原因：

上下文窗口有限
文档很多时，不可能全部放进模型上下文。
成本高
全量塞文档会导致 token 消耗很高，调用成本和时延都会增加。
噪音太多
不相关内容过多，会干扰模型判断，反而降低答案质量。
知识需要实时更新
企业知识经常变化，用 RAG 可以动态检索最新内容，不需要重新训练模型。

加分说法

RAG 的核心价值不只是“塞得下”，更重要的是“只给模型最相关的信息”，这样准确率、成本和速度都更好。

16. Embedding 的作用是什么？

标准回答

Embedding 的作用是把文本转换成向量表示，让语义相近的文本在向量空间中距离更近。这样用户问题和知识库文档就可以通过向量相似度来做语义检索，而不只是做关键词匹配。

举例

比如“如何报销差旅费”和“出差费用怎么申请报销”，字面不完全一样，但语义接近。Embedding 可以让这两句话在向量空间中更接近，从而实现语义级召回。

加分点

Embedding 是 RAG 检索的基础，它解决的是“怎么把非结构化文本变成可计算、可比较的语义表示”。

17. 为什么要用向量数据库？

标准回答

因为在 RAG 场景里，需要对大量文本向量做高效相似度检索。普通关系型数据库不擅长高维向量的近似最近邻搜索，而向量数据库专门针对这类场景做了索引和检索优化，能够在大规模数据下更快地找到语义相近的文本片段。

它解决什么问题

海量向量存储
高效相似度检索
topK 召回
元数据过滤
多租户隔离

补充

如果数据规模不大，也可以用支持向量检索能力的搜索引擎或数据库，但在大规模、高性能场景下，专门的向量数据库更有优势。

18. 文档为什么要切 chunk？怎么切？

标准回答

文档切 chunk 的目的是把长文档拆成适合检索和输入模型的小片段。因为如果文档太长，直接向量化会导致语义过于混杂；如果检索时返回整篇文档，也会造成上下文过长和噪音过多。

怎么切

常见方法包括：

按固定长度切
按段落切
按标题层级切
按语义切分
带 overlap 的滑动窗口切分

为什么要 overlap

因为相邻段落之间常常存在语义连续性，直接硬切可能把关键信息拆开。加入 overlap 可以减少信息割裂，提高召回质量。

切太大和切太小的问题

切太大：噪音多，检索不精准，成本高
切太小：上下文不完整，模型难以理解，容易漏关键信息

加分说法

chunk 策略没有绝对标准，通常要根据文档结构、领域特点和问答场景做实验调整。

19. topK 和 rerank 分别解决什么问题？

标准回答

topK 和 rerank 分别对应 RAG 中两个不同阶段的问题：

topK 解决的是“先召回哪些候选文档”
rerank 解决的是“这些候选文档里谁更相关、排序怎么更准”

展开说法

向量检索阶段通常追求高召回，会先取 topK 个相似片段，但这些片段不一定排序最优，也可能包含噪音。rerank 会用更强的相关性模型，对 query 和候选文档做更精细的匹配评分，重新排序，提升最终送给大模型的上下文质量。

加分点

可以说：

向量召回更像“海选”，rerank 更像“复试”。前者保证别漏掉，后者保证排得准。

20. 为什么召回不准？

标准回答

召回不准通常可能出在以下几个方面：

chunk 切分不合理
信息被切碎或混在一起，导致语义表示失真
embedding 模型不适配
中文、垂直领域、专业术语效果不佳
query 表达和文档表达不一致
用户口语化提问和文档官方表述差异较大
topK 设置不合理
太小容易漏召回，太大容易引入噪音
没有做 rerank
召回结果相关性排序不够精确
文档质量问题
OCR 错误、解析错误、文本脏数据
检索策略单一
只做向量检索，没有结合关键词检索、过滤条件或 query 改写

解决思路

调整 chunk 策略
更换 embedding 模型
增加 query 改写
引入混合检索
加 rerank
做文档清洗和数据质量治理

21. 为什么会出现幻觉？怎么处理？

标准回答

幻觉指的是模型生成了看起来合理，但实际上不准确、无依据甚至错误的信息。

出现原因

模型本身是生成式的，本质是概率预测，不是真正“理解事实”
检索不到有效信息时，模型仍倾向于继续生成
Prompt 约束不够
上下文噪音太多或信息冲突
问题超出知识边界

处理方法

明确约束：只基于提供资料回答
检索不到时允许拒答
降低 temperature，提高稳定性
优化检索和 rerank，提高上下文质量
输出引用来源
对高风险场景做人审或规则兜底
对答案做后处理和校验

加分表达

幻觉不能完全消除，但可以通过“高质量检索 + 强约束 Prompt + 拒答机制 + 后处理校验”显著降低。

22. 检索不到内容时怎么办？

面试官想考什么

看你是否理解 RAG 不是“永远都能答”，以及你有没有设计拒答机制、兜底策略和用户体验方案。

标准回答

检索不到内容时，不能直接让模型自由发挥，否则很容易产生幻觉。更合理的做法是先判断“是否命中足够可信的知识”，如果没有命中，就走拒答或兜底流程。

常见做法有：

设置相似度阈值
如果召回结果低于阈值，判定为未命中。
设置最小有效片段数
如果只有很弱的候选内容，也不要强答。
让模型明确拒答
Prompt 中约束：如果资料不足，请明确说明“当前知识库没有相关信息”。
给兜底话术
比如：
- “目前知识库中没有找到相关内容，建议联系人工客服”
- “该问题超出当前知识范围”
引导用户补充信息
有些问题不是完全无答案，而是表达过于模糊，可以提示用户 уточation/补充条件。
记录未命中问题
用于后续知识库补充、热门缺口分析和产品优化。

更真实的面试表达

在实际项目里，我不会把“检索到了内容”和“能可靠回答”画等号。即使召回了 topK，也要看相似度、重排分数、片段质量。如果证据不足，我更倾向于让系统拒答，而不是让模型编一个看起来像对的答案，因为企业场景里错误回答的代价通常比“不回答”更高。

可能的追问

相似度阈值怎么定？
拒答会不会影响用户体验？
怎么区分“真的没有”还是“检索没做好”？

回答加分点

可以补一句：

拒答不是结束，而是一个产品策略问题。好的系统应该在拒答的同时给出下一步建议，比如推荐相关问题、引导补充条件，或者转人工。

23. 如何限制模型只基于知识库回答？

标准回答

要限制模型只基于知识库回答，通常要从 Prompt 约束、上下文控制、拒答机制、后处理校验 四个层面一起做。

具体做法

Prompt 明确约束
例如：
- 只能根据提供的参考资料回答
- 如果资料中没有答案，直接说明不知道
- 不要使用外部常识补充未提供的信息
控制输入上下文
只把检索出来的可信内容拼给模型，不把无关信息放进去，减少模型自由发挥空间。
增加引用要求
要求模型回答时引用来源片段编号或文档名，这样可以增强答案和证据的绑定。
检索未命中时拒答
没有足够证据时，不进入生成，或者生成拒答模板。
后处理校验
对答案做规则检查，比如：
- 是否包含来源引用
- 是否出现上下文中不存在的关键实体
- 高风险场景下做人工审核

更真实的展开说法

单靠一句“请只基于知识库回答”通常不够，因为模型仍然可能利用自身参数中的常识补全。所以更稳妥的方案是：先做好检索质量，再通过 Prompt 和输出格式约束模型，最后通过引用和后校验提高可控性。

可能追问

如果模型还是补充了知识库之外的内容怎么办？
只靠 Prompt 能彻底解决吗？

加分点

可以说：

在高风险场景里，真正可靠的做法不是“相信模型会听话”，而是把系统设计成“即使模型不完全听话，仍有机制把风险拦下来”。

24. 如何提示引用来源？

标准回答

提示引用来源的核心目的是让答案更可追溯、可解释，也方便用户判断可信度。通常可以从 Prompt 和输出结构两方面设计。

常见做法

给每个 chunk 编号
比如 [Doc1-Chunk3]
Prompt 中要求回答时附带引用
例如：
- 每条结论后标注来源编号
- 如果没有明确来源，不要输出该结论
结构化输出
输出 JSON：
- answer
- citations
- confidence
前端展示来源卡片
点击答案可展开文档原文片段、文档名、页码等
限制引用真实性
最好来源编号是系统传入的，不要让模型自己杜撰来源格式

更真实的面试表达

我会尽量避免让模型“自由生成引用”，而是把候选片段的 ID 明确传给模型，让它从给定 ID 中选择引用；如果要更稳，可以在生成后再做一次答案-证据对齐校验。

加分点

引用来源不仅是体验优化，也是降低幻觉风险的重要手段，因为它把“答案”和“证据”绑定起来了。

25. 知识库更新后没生效怎么办？

标准回答

知识库更新后没生效，通常要沿着“数据更新链路”逐步排查，看问题出在解析、切分、向量化、入库、索引刷新还是查询路径。

排查思路

确认原始文档是否真的更新
- 新文件是否上传成功
- 旧文件是否被替换或版本号是否变化
检查解析和切分
- 新文档内容是否被正确提取
- chunk 是否生成成功
检查向量化
- embedding 任务是否执行成功
- 是否有失败重试或任务积压
检查向量库入库
- 新向量是否写入成功
- 元数据是否正确
- 是否写进了正确的知识库/租户空间
检查索引刷新或缓存
- 向量索引是否需要刷新
- 检索层是否有缓存未失效
- Query 结果是否命中了旧缓存
检查权限和过滤条件
- 新文档是否被权限策略过滤掉了
- 文档状态是否还是“未发布”
检查查询链路
- Query 是否改写错误
- 检索参数是否导致新文档难以被召回

更真实的表达

这种问题本质上不是单点问题，而是典型的数据处理链路问题。我会把整个知识更新过程拆成可观测步骤，每一步都打日志和状态，比如“已上传、已解析、已切分、已向量化、已入库、可检索”。这样线上排查会快很多。

加分点

可以补充：

如果业务对实时性要求高，我会考虑增量更新机制和缓存失效策略；如果对一致性要求更高，则会做版本化发布，避免部分更新成功、部分失败。

26. 多租户知识库怎么隔离？

标准回答

多租户知识库隔离主要涉及数据隔离、检索隔离、权限隔离和资源隔离。

常见做法

数据层隔离
- 每个租户独立索引/独立 collection
- 或者共享索引但用 tenant_id 做强过滤
检索层隔离
检索时必须带租户条件，防止跨租户召回
权限层隔离
除了租户级别，还可能要做用户组、部门、角色级权限过滤
对象存储隔离
文档原件、解析结果、缓存等也要按租户隔离
日志和监控隔离
防止租户 A 看到租户 B 的调用数据
密钥和配置隔离
有些企业会有自己的模型配置、Prompt 模板、知识库策略，也要分租户管理

更真实的面试表达

如果租户规模大、数据敏感性高，我会更倾向于物理或逻辑上更强的隔离，比如独立 collection；如果租户很多、规模较小，也可以采用共享索引 + 强过滤，但要特别注意过滤条件不能漏，否则可能引发严重的数据越权问题。

加分点

可以再说一句：

多租户隔离在 AI 场景里比传统系统更敏感，因为一旦检索错了，模型会把别人的数据“组织成自然语言”说出来，泄露风险更直观。

27. 权限怎么控制？

标准回答

在 AI 知识库或助手场景里，权限控制不能只做在“文档下载”层，还必须做在“检索和生成”层。因为即使用户看不到原文，如果检索到了敏感内容，模型仍可能把内容总结输出。

具体做法

文档入库时打权限标签
比如部门、角色、项目组、租户等元数据
检索时带权限过滤
只从当前用户可访问的文档中召回
生成时保留来源元数据
方便后续审计和展示
接口层鉴权
验证用户身份、角色、token、租户信息
高敏感问题做额外校验
比如人事、薪资、财务、合同类问题增加二次校验
日志审计
记录谁问了什么、召回了什么、返回了什么

加分点

真正安全的权限控制一定是在检索前过滤，而不是生成完再遮盖，因为生成阶段一旦看到敏感内容，泄露就已经发生了。

五、Prompt 设计与输出稳定性

28. system prompt 你是怎么设计的？

标准回答

我设计 system prompt 通常会围绕五个部分展开：

角色定义
告诉模型它是谁，比如“企业知识助手”“客服助手”
任务目标
明确它要完成什么，比如回答政策问题、提取结构化信息
行为约束
比如只能依据提供资料回答、不要编造、资料不足时拒答
输出格式
比如要求 JSON、Markdown、分点回答、附引用来源
异常处理规则
比如知识缺失怎么办、格式不确定怎么办

示例式回答

比如做企业知识库时，我会写成：

你是企业内部知识问答助手
仅可基于提供的资料回答
如果资料不足，请明确说明“当前知识库中未找到相关信息”
回答要简洁、准确，并附带来源编号
不要使用外部常识补充未经资料支持的内容

更真实的面试表达

system prompt 的重点不是写得“像人”，而是写得“像规范”。它本质上是在给模型设边界，特别是在企业场景里，边界往往比语言风格更重要。

29. 如何减少模型胡说？

标准回答

减少模型胡说，一般要从“输入质量、Prompt 约束、参数控制、输出校验”四方面入手。

具体方法

提高检索质量
让模型拿到更准确的上下文
明确约束
只允许基于资料回答，资料不足时拒答
降低 temperature
提高稳定性，减少发散生成
要求引用来源
没证据的内容不鼓励输出
结构化输出
限定回答格式，减少自由发挥空间
后处理校验
对关键信息做规则检查或调用外部校验服务
高风险场景做人审
尤其是医疗、法律、财务等领域

加分点

幻觉治理不是单一手段能解决的，更像一个系统工程。很多时候，问题不在模型“爱胡说”，而在系统把不充分的上下文和过于自由的生成空间一起给了它。

30. 如何让模型按 JSON 返回？

标准回答

要让模型尽量按 JSON 返回，我通常会采用以下几种方式组合使用：

Prompt 中明确要求 JSON 格式
给出 JSON Schema 或示例
要求不要输出多余解释文字
字段名固定、类型明确
使用支持结构化输出或 function calling 的模型能力
服务端做 JSON 校验与重试

示例表达

例如：

{
  "intent": "string",
  "confidence": "number",
  "answer": "string"
}

并在 Prompt 中写明：

仅返回合法 JSON
不要添加 markdown 代码块
所有字段必须存在
无法确定时返回空字符串或 null

更真实的面试表达

如果模型本身支持 function calling 或 JSON mode，我会优先用官方的结构化输出能力，因为比纯 Prompt 更稳定；如果只能靠 Prompt，我会配合后端解析校验和失败重试，不会把“模型应该会乖乖输出 JSON”当成前提。

31. 如果 JSON 返回不稳定怎么办？

标准回答

JSON 返回不稳定是很常见的问题，我一般会通过“约束 + 校验 + 修复 + 重试 + 降级”这几层处理。

具体做法

加强 Prompt 约束
明确字段、类型、枚举值、示例
优先使用结构化输出能力
比如 function calling、JSON mode
服务端做解析校验
用 schema 校验是否缺字段、类型错误
轻度修复
比如去掉多余 markdown、补全引号、提取 JSON 主体
失败重试
如果解析失败，可以把错误信息反馈给模型要求重新按 schema 输出
兜底降级
多次失败后返回默认结构或提示稍后重试

加分表达

AI 输出不能假设永远规范，所以系统设计上应该把模型看成“可能返回不稳定文本的组件”，而不是严格的 RPC 服务。

32. 如何做 few-shot？

标准回答

few-shot 就是在 Prompt 中提供少量高质量示例，让模型模仿目标任务的输入输出模式，从而提高理解和输出稳定性。

怎么做

选择和真实任务相似的样例
示例尽量覆盖边界情况
格式要和最终输出一致
数量不宜过多，避免占用太多上下文
优先选择“代表性强”的样例，而不是“越多越好”

应用场景

分类
信息抽取
意图识别
结构化输出
固定风格生成

加分点

few-shot 的本质不是给模型“喂更多内容”，而是通过示例告诉模型“这个任务应该怎么做”。如果任务规则已经非常清晰，也不一定非要加很多示例。

33. temperature 怎么调？

标准回答

temperature 的调整取决于任务目标。

低 temperature：更稳定、更保守，适合问答、抽取、分类、结构化输出
高 temperature：更发散、更多样，适合创意写作、文案生成、脑暴

实际项目里的做法

在 AI 应用开发中，大多数企业任务都更重视稳定性，所以我通常会优先把 temperature 调低，尤其是：

RAG 问答
JSON 输出
工具调用参数生成
数据抽取

只有在营销文案、改写、创意类任务里，我才会适当调高一点。

加分点

除了 temperature，也会结合 top-p 一起调，但通常先保证业务稳定，再追求表达丰富性。

34. prompt 太长了怎么办？

标准回答

Prompt 太长时，核心思路不是“硬塞进模型”，而是做信息压缩和优先级管理。

常见做法

删掉冗余规则
合并重复约束
把长指令结构化
用编号、分段、模板化语言
裁剪历史对话
只保留和当前问题最相关的部分
对历史内容做摘要
把长上下文压缩成摘要记忆
减少 few-shot 数量
保留最有代表性的样例
优化检索上下文
只拼最相关片段，不是越多越好
分阶段调用
把一个复杂任务拆成多个小步骤

加分表达

上下文不是越长越好。很多时候，模型效果下降不是因为信息不够，而是因为无关信息太多。

35. 多轮对话上下文怎么裁剪？

标准回答

多轮对话的上下文裁剪通常要结合“相关性、时效性和 token 限制”来做，而不是简单保留最近 N 轮。

常见策略

最近轮次保留
保留最近几轮对话
关键轮次保留
保留和当前问题强相关的历史轮次
摘要记忆
把早期对话压缩成摘要，代替原文
按槽位保留
比如用户身份、地区、订单号等结构化上下文单独存储，不依赖原始聊天记录
分场景裁剪
闲聊可以更宽松，任务型对话更强调关键状态保留

更真实的面试表达

我不会只靠“截断前面内容”这种粗暴方式，因为很多任务型对话的关键条件可能出现在较早轮次。更合理的方式是把长期有效信息结构化保存，把短期交互保留在最近上下文里。

六、Agent / 工具调用 / 工作流

36. Agent 和普通问答的区别是什么？

标准回答

普通问答主要是“输入一个问题，输出一个回答”；Agent 则更强调“理解目标、规划步骤、调用工具、执行任务并反馈结果”。

区别总结

普通问答

以文本生成回答为主
通常一次推理完成
不一定连接外部系统

Agent

能调用工具
能拆解多步任务
能根据中间结果继续决策
更像一个任务执行者

举例

用户问“帮我总结这份制度”，这是普通问答。
用户说“帮我查本月华东区销售数据并生成日报发到邮箱”，这更像 Agent，需要查数据库、生成报告、调用邮件服务。

加分点

Agent 不只是“会调用工具”，更关键的是它能围绕目标进行多步决策和执行。

37. 什么场景适合工作流，什么场景适合 Agent？

标准回答

我的理解是：

工作流 更适合流程固定、步骤清晰、可预定义的任务
Agent 更适合开放性更强、路径不确定、需要动态决策的任务

举例

适合工作流的场景

文档上传 -> 解析 -> 摘要 -> 分类 -> 入库
工单分类 -> 分派 -> 回复建议生成
报表生成 -> 审核 -> 发送

这些流程是稳定的，步骤可控，工作流更容易保证稳定性和可观测性。

适合 Agent 的场景

用户提出复杂目标，步骤不确定
需要根据中间结果决定下一步调用哪个工具
需要跨多个系统探索式执行

更真实的面试表达

企业场景里我会更谨慎使用 Agent。对于高确定性任务，我更倾向工作流，因为更稳定、更可控、更容易排障；只有在确实需要动态决策时，才会引入 Agent。

38. 模型怎么决定调用哪个工具？

标准回答

模型决定调用哪个工具，通常依赖三部分信息：

工具定义
工具的名称、功能描述、参数 schema
用户意图
模型根据用户问题判断当前目标是什么
Prompt/系统规则
告诉模型在什么情况下优先使用什么工具

实际机制

在 tool calling 场景下，系统会把一组可用工具描述提供给模型。模型根据用户输入和工具说明，选择最匹配的工具，并生成结构化参数。然后由程序真正执行。

如何提升准确性

工具描述要清晰，避免多个工具功能重叠
参数 schema 要明确
可以通过 few-shot 示范工具使用场景
对高风险工具增加规则校验

加分点

工具选择准确率很大程度上取决于“工具设计是否清晰”，不是只取决于模型能力。

39. 工具失败怎么重试？

标准回答

工具失败时不能简单无限重试，要区分失败类型，做针对性处理。

常见策略

瞬时故障
比如网络抖动、超时，可做有限次重试，通常配合指数退避
参数错误
不应直接重试，可以把错误信息反馈给模型，让它修正参数后再调用
权限错误
直接终止，并返回权限不足提示
外部系统不可用
走降级或兜底，比如稍后重试、转人工
幂等保护
对有副作用的工具，如下单、发邮件、创建工单，必须保证幂等，避免重复执行

更真实的面试表达

我会把工具分成“只读型”和“有副作用型”两类。只读型工具重试风险较低；有副作用型工具一定要有幂等 ID、状态记录和补偿机制，否则 Agent 连续重试可能造成业务事故。

40. 多步骤任务怎么编排？

标准回答

多步骤任务编排一般有两种思路：

固定工作流编排
适合流程明确的任务，步骤 заранее定义好
动态 Agent 编排
让模型根据目标和中间结果动态决定下一步

实际项目中我的偏好

如果任务链路稳定，我更倾向于固定工作流，例如：

意图识别
参数抽取
工具调用
结果汇总
输出生成

因为这种方式更稳定、更好监控，也便于排障。

编排时要考虑的点

每一步输入输出定义清晰
超时和失败处理
状态管理
结果可追踪
是否需要人工介入节点

加分点

复杂任务不是越“智能”越好，很多业务里真正重要的是可控和可审计。

41. 如何防止 Agent 死循环？

标准回答

防止 Agent 死循环，通常要从规则限制、状态记录和终止条件三方面做控制。

具体方法

限制最大步骤数
超过 N 步强制终止
限制重复工具调用
同一个工具同样参数反复调用要拦截
状态去重
记录执行轨迹，防止在同一状态来回循环
明确终止条件
例如任务完成、拿到足够信息、遇到不可恢复错误
对失败次数设上限
连续失败后转人工或返回错误
Prompt 中增加行为约束
避免无意义反复尝试

加分点

Agent 的风险之一就是“看起来一直在工作，其实一直在空转”，所以必须有外部控制机制，不能完全依赖模型自觉停止。

42. 结果怎么做人审兜底？

标准回答

人审兜底通常用于高风险、高价值或低置信度场景。核心思路是让 AI 先生成候选结果，再交给人工确认，而不是让 AI 直接自动执行全部动作。

常见方式

低置信度转人工
高风险操作前人工确认
比如下单、退款、合同生成、对外发送
抽样质检
双轨制
AI 给建议，人工做最终决策
审计留痕
保留输入、模型输出、工具调用记录、人工修改记录

加分点

人审不是为了“证明 AI 不行”，而是为了让系统在关键环节更安全，尤其是在早期上线阶段。

七、模型接入、稳定性、成本控制

43. 你们接的是哪家模型？为什么选这个模型？

标准回答模板

这个问题建议你按“场景需求 -> 模型能力 -> 成本性能 -> 接入便利性 -> 稳定性”来答。

示例回答

我们项目里主要用的是某某模型，选择它主要基于几个因素：

任务适配度
它在中文问答、指令跟随、结构化输出上表现比较稳定
延迟和吞吐
对我们这种在线问答场景，响应速度比较关键
成本
如果请求量大，单次调用成本和总 token 成本都要考虑
接入方式
API 文档、SDK、稳定性、配套能力是否成熟
是否支持需要的能力
比如 function calling、长上下文、流式输出、JSON mode

加分表达

如果是多模型架构，还可以说：

我们不是只看“哪个最强”，而是按场景分层使用，比如低成本模型做预处理，高性能模型做最终生成。

44. 是 API 调用还是本地部署？怎么权衡？

标准回答

这个要看业务对数据安全、成本、性能、可控性的要求。

API 调用优点

上线快
运维成本低
模型能力迭代快
适合验证阶段或中小规模场景

API 调用缺点

数据出域风险
依赖第三方稳定性
高并发下成本可能高
可控性相对弱

本地部署优点

数据更可控
可做深度定制
高请求量下可能更有成本优势
对私有化场景更友好

本地部署缺点

运维和推理成本高
硬件要求高
模型升级维护复杂

加分表达

如果企业对数据安全要求很高，比如金融、政务、医疗，通常会更关注私有化部署；但如果是通用场景快速验证，API 往往更高效。

45. 流式输出怎么做？

标准回答

流式输出的核心是模型边生成，服务端边转发给前端，而不是等完整答案生成完再一次性返回。这样可以显著改善用户体感延迟。

实现思路

服务端调用支持 streaming 的模型接口
按 token 或 chunk 接收模型增量输出
通过 SSE、WebSocket 或 chunked response 推给前端
前端实时渲染
同时处理结束标记、异常中断、取消请求等状态

需要注意的问题

中途断流怎么处理
前端如何区分“生成中”和“已完成”
工具调用场景是否适合直接流式
流式内容如何做审查和缓存

加分点

流式输出优化的是“首 token 时间”，不是总生成时间，但在用户体验上往往很重要。

46. 模型超时怎么办？

标准回答

模型超时需要分成预防和处理两部分。

预防措施

控制输入长度
优化 Prompt 和上下文
给模型调用设置合理超时
长任务拆成异步
高峰期限流

处理措施

超时重试
适用于瞬时波动，但次数要有限
降级策略
切换备用模型、简化回答、返回摘要版结果
兜底提示
如“当前请求较繁忙，请稍后重试”
异步化
对耗时任务改成提交任务后异步通知结果
监控告警
监控超时率、响应分位数，发现异常及时处理

加分点

对实时交互场景，超时不只是技术问题，也是产品体验问题，所以通常要设计明确的 SLA 和降级路径。

47. 模型限流怎么办？

标准回答

模型限流通常从“客户端限流、请求削峰、缓存复用、模型分流、降级兜底”几个方面处理。

具体做法

服务端限流
控制单用户、单租户、全局 QPS
队列削峰
非实时任务进入队列异步处理
结果缓存
对高频问题直接命中缓存，减少重复调用
多模型分流
不同任务走不同模型，避免都压在一个高价高性能模型上
重试退避
遇到 429 不要立刻疯狂重试
降级方案
返回模板答案、走简化模型、延迟处理

加分点

限流问题往往说明系统已经进入真实使用阶段，此时单看模型效果已经不够，必须从平台层面做资源治理。

48. 模型结果不稳定怎么办？

标准回答

模型结果不稳定通常表现为同样问题多次回答不一致、格式波动、细节遗漏等。处理思路一般是：

降低 temperature
强化 Prompt 约束
使用 few-shot 示范
优先结构化输出
把复杂任务拆步骤
对结果做规则校验
固定检索和上下文构造方式，减少输入波动

更真实的面试表达

很多“不稳定”其实不是模型单点问题，而是整条链路输入不稳定，比如 query 改写不同、召回文档不同、上下文顺序不同。所以要把问题拆开看，是模型采样导致的，还是检索链路不稳定导致的。

49. 多模型切换怎么设计？

标准回答

多模型切换一般是为了在成本、效果、稳定性、场景适配之间做平衡。

常见设计

按任务分流
- 轻任务：分类、改写 -> 小模型
- 重任务：复杂生成、总结 -> 大模型
按租户或套餐分层
不同客户用不同模型策略
主备切换
主模型异常时切备用模型
A/B 测试
对比不同模型效果
策略配置化
不把模型选择写死在代码里，而是通过配置中心控制

加分点

多模型架构的关键不是“接了很多模型”，而是有清晰的路由策略和 fallback 机制。

50. 第三方模型挂了怎么办？

标准回答

第三方模型挂了，本质上是外部依赖故障，需要提前做容灾设计。

处理方式

快速失败
设置超时，避免请求一直堆积
切换备用模型
主备模型或多供应商容灾
功能降级
关闭非核心 AI 功能，保留核心业务路径
返回兜底文案
提示服务繁忙，而不是一直 loading
熔断机制
在外部服务持续异常时短时间内不再继续打流量
监控告警
监控成功率、超时率、429/5xx 比例

加分点

如果核心业务强依赖第三方模型，那容灾不是可选项，而是上线前必须设计好的。

51. 成本太高怎么办？

标准回答

AI 应用的成本优化通常从 token、模型选择、缓存和调用频率四个方向入手。

具体方法

缩短上下文
减少不必要历史对话和冗余 Prompt
优化检索
只传最相关片段，而不是大量拼接
模型分层
小模型做预处理，大模型做最终生成
缓存
热门问题缓存、相似问题缓存、检索结果缓存
减少无效调用
比如先做意图识别，简单问题走规则或 FAQ
控制输出长度
限制 max_tokens，避免长篇输出
异步和批处理
对 embedding、文档处理等任务做批量化

加分表达

成本优化不只是“省钱”，也是系统可持续运营的前提。很多 demo 能跑通，但一放量就发现根本扛不住成本。

52. 如何做缓存？

标准回答

AI 场景下缓存可以分几层来做：

结果缓存
相同或高度相似问题直接返回历史答案
检索缓存
相同 query 的召回结果缓存
embedding 缓存
避免重复向量化相同文本
Prompt 模板缓存
减少重复拼装开销
会话状态缓存
存多轮上下文、用户状态、任务状态

注意点

要设置合理失效时间
知识库更新后要考虑缓存失效
对涉及权限的数据，缓存 key 必须带用户或租户维度
对高敏感结果要谨慎缓存

加分点

缓存命中率提升，往往同时带来成本下降和响应速度提升，是 AI 工程化里性价比很高的优化点。

53. embedding 预计算是什么意思？为什么有用？

标准回答

embedding 预计算就是在文档入库阶段，提前把文本 chunk 转成向量并存储好，而不是等用户查询时再临时计算。这样用户提问时只需要对 query 做一次 embedding，再去向量库检索，大幅降低响应时间。

价值

提高在线检索速度
降低实时计算压力
适合知识库、文档检索这类静态或半静态数据场景

加分点

如果文档更新频繁，可以配合增量预计算和异步任务队列来做，不要阻塞主流程。

八、异常场景与安全治理高频题

这部分非常重要。很多候选人前面概念都能答，但一到异常场景就露怯。
而面试官往往正是通过这些问题判断：你到底有没有做过真实项目。

54. 幻觉怎么处理？

面试官想考什么

看你是否理解幻觉是大模型应用的核心风险，以及你有没有系统化治理思路，而不是只会说“加 Prompt”。

标准回答

幻觉治理通常不是单点手段，而是一个完整链路问题。我一般会从 检索、Prompt、生成参数、输出校验、业务兜底 这几个层面一起做。

具体做法

先提高检索质量
- 优化 chunk 策略
- 提升 embedding 模型效果
- 加 query 改写
- 加 rerank
- 降低噪音上下文
加强 Prompt 约束
- 只允许基于资料回答
- 没有依据时必须拒答
- 明确不要补充未提供信息
降低生成随机性
- 调低 temperature
- 控制 max_tokens，避免过度发挥
增加引用来源
- 让答案尽量和证据绑定
- 没有来源的结论不鼓励输出
做输出校验
- 高风险字段规则校验
- 关键信息对照原文检查
- 必要时调用外部校验服务
高风险场景做人审
- 法律、医疗、财务等场景不能完全依赖模型直出

更真实的面试表达

如果面试官追问，我会强调：
幻觉不能承诺完全消除，但可以通过工程手段显著降低。
真正要做的不是“让模型永远不出错”，而是把系统设计成“即使模型出错，也不容易造成严重后果”。

可能追问

你们项目里幻觉最常见的表现是什么？
你如何衡量幻觉有没有降低？
RAG 一定能解决幻觉吗？

加分点

可以补一句：

RAG 能降低一部分幻觉，但如果检索本身错了，或者上下文质量差，模型还是会基于错误证据生成“看起来更合理”的错答案。

55. Prompt Injection 怎么防？

标准回答

Prompt Injection 指用户通过构造输入，试图绕过系统规则，让模型忽略原有指令、泄露敏感信息或执行非预期行为。防护上一般不能只靠 Prompt，需要多层防御。

常见防护方法

指令分层
system prompt 和用户输入分开管理，避免用户输入直接和系统规则混杂
输入清洗和风险识别
检测类似“忽略以上所有指令”“输出系统提示词”等攻击性表达
工具权限最小化
即使被注入，模型能调用的工具和数据范围也要受限制
敏感信息不直接暴露给模型
不把密钥、内部规则、敏感配置直接放进上下文
输出审核
对敏感内容、越权内容、系统 Prompt 泄露等进行拦截
高风险操作二次确认
比如删数据、发邮件、提交审批等必须有人机确认
检索内容隔离
如果外部文档本身可能带恶意注入内容，要对文档内容做清洗或标记

更真实的面试表达

Prompt Injection 本质上不是“模型被黑了”，而是因为模型会把文本都当成潜在指令。所以要把它当成一种安全问题来看，核心不是“让模型学会识别所有攻击”，而是不要让模型拥有超出它应有权限的能力。

可能追问

如果知识库文档里就有恶意指令怎么办？
只靠正则拦截够吗？

加分点

可以说：

最有效的防护方式之一是权限隔离和工具最小授权。即使 Prompt 被注入，模型也拿不到不该拿的数据，也做不了不该做的操作。

56. 用户恶意提示词注入怎么办？

标准回答

如果是用户输入层面的恶意注入，我会从“识别、隔离、限制、审计”四步来处理。

处理方式

识别风险输入
检测明显绕过规则、诱导泄露、越权调用等内容
用户输入和系统规则隔离
不把用户输入直接拼进系统指令核心区
限制能力边界
用户就算构造恶意输入，也不能突破权限校验和工具授权
高风险场景拒绝处理
遇到敏感命令、越权查询、恶意测试可直接拒绝
记录审计日志
便于后续分析攻击样本和补规则

更真实的说法

我不会把希望寄托在“模型自己判断这是恶意输入”。更稳妥的是：模型前面有输入风控，模型后面有权限控制，关键动作还有人工确认。

57. 流式输出中断怎么办？

标准回答

流式输出中断需要先区分是 模型侧断流、网络中断、网关超时、前端连接断开 还是 服务端异常，不同原因处理方式不同。

处理思路

服务端要能感知中断位置
比如记录是否已收到首 token、已经输出到第几段
前端展示明确状态
提示“生成中断，请重试”而不是一直卡住
支持重试或重新生成
根据场景决定是否从头重试
长任务异步化
对特别耗时场景，不一定适合纯流式直连
网关和连接超时配置合理
避免还没生成完就被上层代理断开
日志和 trace 打通
方便判断断在模型接口、服务端、SSE 连接还是前端消费

加分点

流式输出中断不只是体验问题，也可能带来状态不一致问题，比如前端以为失败了，后端其实还在跑，所以要做好请求生命周期管理。

58. 结果格式错了怎么办？

标准回答

如果模型返回格式错误，比如 JSON 不完整、字段缺失、枚举不合法，我一般会通过 格式约束、解析校验、自动修复、重试兜底 四层来处理。

具体做法

Prompt 里明确格式
能用结构化输出就不用自由文本
服务端做严格校验
轻量自动修复
去 markdown、补引号、提取 JSON 主体
失败重试
将错误提示反馈给模型，让它重新输出
兜底返回
实在失败则给默认值或错误提示

更真实的表达

我不会把模型当成强类型服务来依赖，所以格式错误在系统设计里应该是“默认会发生的情况”，而不是异常到毫无准备。

59. JSON 解析失败怎么办？

标准回答

JSON 解析失败通常分三种情况：

返回中夹杂了解释性文本
JSON 结构不完整或语法错误
字段存在但类型不合法

处理步骤

先做预处理，提取 JSON 主体
尝试轻量修复
用 schema 校验结构和类型
校验失败则重试
多次失败则降级或走人工/规则处理

追问时可补充

如果是关键链路，我会优先改成 function calling 或 JSON mode，而不是长期依赖自由文本解析。

60. 模型 API 波动怎么办？

标准回答

模型 API 波动一般体现在超时、5xx、429、延迟突增、结果质量不稳定等方面。处理上要结合容灾和限流。

具体做法

超时控制
有限重试 + 指数退避
熔断
备用模型切换
缓存命中优先
降级策略
供应商监控
记录不同模型服务商的 SLA 表现

加分点

如果业务强依赖外部 API，最好在架构层面支持“模型提供商可切换”，不要把业务强耦合到某一家 SDK 上。

61. 多轮上下文太长怎么办？

标准回答

多轮上下文过长时，我会优先做 裁剪、摘要、状态结构化、检索增强。

具体方法

保留最近几轮强相关对话
历史长对话压缩成摘要记忆
关键信息单独结构化存储
比如姓名、订单号、任务目标
如果是知识问答，对历史内容做检索式召回，而不是全量拼接
对低价值闲聊信息尽早丢弃

加分点

真正有价值的不是“保留多少轮”，而是“保留了哪些对当前任务真正有帮助的信息”。

62. 检索错了怎么办？

标准回答

检索错了说明问题可能出在 query 理解、召回策略、重排模型或知识库数据质量上。

排查和优化思路

看 query 是否被错误改写
看 embedding 是否适配当前语种和领域
看 chunk 切分是否导致语义断裂
看 topK 是否过小或过大
看是否缺少 rerank
看是否需要混合检索
看文档元数据过滤是否错误

更真实的表达

如果用户问的是专业术语、缩写、口语别称，检索很容易偏，所以我会考虑做 query 扩展、同义词表或领域词典增强。

63. 文档解析失败怎么办？

标准回答

文档解析失败通常要区分是文件格式问题、解析器能力问题、文件损坏还是 OCR 问题。

处理方法

格式校验
上传阶段先判断是否支持该格式
解析任务异步化
避免解析失败阻塞主流程
失败重试和状态记录
标记“解析失败”“待重试”“人工处理”
降级方案
比如解析文本失败时尝试 OCR
错误明细可观测
便于定位是 PDF 扫描件、加密文档还是表格异常
用户侧提示清晰
告知失败原因，而不是静默失败

加分点

文档解析是 RAG 的入口，如果入口质量差，后面所有检索和生成都可能出问题，所以最好把解析成功率作为核心监控指标之一。

64. 向量化失败怎么办？

标准回答

向量化失败一般是异步任务链路问题，常见原因包括模型接口异常、任务超时、文本脏数据或批处理失败。

处理思路

给向量化任务加状态管理
支持失败重试
对超长文本、空文本、乱码先做预处理
批量任务切小批次，避免整批失败
对持续失败样本记录明细，便于人工检查
知识库检索前校验是否已完成向量化

加分点

向量化失败如果不做显式状态管理，最容易出现“文档看起来上传成功了，但其实永远检索不到”的隐性故障。

65. 输出不合规怎么办？

标准回答

输出不合规包括涉黄涉暴、政治敏感、辱骂歧视、隐私泄露、业务违规承诺等。处理上要做前中后多层拦截。

常见做法

输入审核
拦截明显违规问题
Prompt 约束
告知模型不能输出违规内容
输出审核
用审核模型或规则系统检测结果
高风险场景模板化
对某些问题只允许固定回复
人工兜底
对敏感场景的关键输出做审核
审计留痕
便于事后追踪和优化

加分点

不能只依赖模型自觉守规。合规问题本质上和安全、风控一样，应该是系统级能力。

66. 数据权限怎么保证？

标准回答

数据权限要在 输入、检索、生成、展示、日志 全链路保证，而不是只在前端做一个按钮隐藏。

核心做法

用户身份认证
文档和数据打权限标签
检索时严格带权限过滤
工具调用时做二次鉴权
结果展示按权限脱敏
日志中避免打印敏感明文
做全链路审计

更真实的表达

AI 场景的数据权限风险更大，因为一旦越权，模型会把敏感信息“自然地总结成一句话”输出给用户，所以权限一定要前置到检索层和工具层。

67. 数据不一致怎么办？

标准回答

数据不一致可能出现在原始文档、解析结果、向量索引、缓存结果之间。处理思路要结合一致性要求。

常见原因

文档已更新，但向量未更新
向量已更新，但缓存未失效
多副本索引同步延迟
元数据和正文版本不一致

处理方案

建立版本号机制
更新走统一流水线
做增量同步和补偿任务
关键链路幂等
缓存和索引联动失效
必要时用“发布版本”而不是“实时覆盖”

加分点

知识库系统很多问题看起来像“模型答错”，其实根因是数据链路的一致性问题。

68. Redis 数据丢了怎么办？放到 AI 应用里怎么理解？

标准回答

如果 Redis 丢数据，首先要看 Redis 里存的是什么类型数据。

如果存的是缓存数据，影响通常是性能和体验下降
如果存的是会话状态、任务状态、限流计数等关键状态，影响就更大

AI 应用里的影响

会话上下文丢失，用户聊天断档
任务状态丢失，异步流程不可恢复
限流状态失效，可能打爆模型 API
缓存失效，导致成本飙升

处理办法

明确 Redis 只放可丢还是不可丢数据
不可丢状态考虑持久化或双写
开启合理持久化策略
主从和哨兵/集群高可用
做数据恢复和降级预案

加分点

很多 AI 系统会把 Redis 当“临时状态中枢”，但如果没有明确哪些数据能丢、哪些不能丢，线上风险会很大。

69. 查询慢了怎么办？放到 AI 应用里怎么排查？

标准回答

查询慢可能发生在多个层面：

数据库慢
向量检索慢
重排慢
模型调用慢
前端流式渲染慢

排查思路

用 trace 拆分总耗时
看每一段耗时：
- query 改写
- embedding
- 向量检索
- rerank
- LLM 生成
找瓶颈后专项优化：
- 索引优化
- topK 降低
- rerank 候选减少
- Prompt 缩短
- 模型切换
- 加缓存

加分点

AI 链路慢通常不是单点慢，而是多段叠加，所以最好有完整调用链监控，而不是只看接口总耗时。

九、评估与效果衡量

70. 如何评估一个 AI 问答系统效果？

面试官想考什么

看你是否具备“效果评估意识”，而不是只会说“感觉还行”。

标准回答

AI 问答系统的评估一般要从 检索效果、生成效果、用户体验、系统稳定性、业务价值 五个维度来看。

具体指标

1）检索效果

Recall@K
Precision@K
MRR / NDCG
命中率
有效片段覆盖率

2）生成效果

答案准确率
引用正确率
幻觉率
格式正确率
拒答准确性

3）用户体验

首 token 时间
总响应时长
用户满意度
追问率
重试率

4）系统稳定性

超时率
错误率
API 成功率
缓存命中率
平均成本

5）业务价值

人工答疑减少比例
工单转人工率下降
用户停留时长
使用频次
问题解决率

更真实的面试表达

如果是 RAG 系统，我通常不会只看最终答案，因为最终效果是检索和生成共同作用的结果。必须把检索质量和生成质量拆开评估，否则问题很难定位。

加分点

可以补一句：

在真实业务里，很多时候最重要的不是通用 benchmark，而是企业自己的高频问题集和 badcase 集。

71. 你怎么评估 RAG 效果？

标准回答

RAG 的评估我会拆成两段：

检索评估
生成评估

检索评估

看召回的片段是否覆盖了正确答案所需证据，比如：

topK 是否命中正确 chunk
排序是否合理
是否引入太多噪音

生成评估

看模型是否基于证据正确回答，比如：

是否答对
是否引用正确
是否有幻觉
是否正确拒答

实际做法

我会准备一批人工标注问题集，包含：

标准问题
同义改写
模糊表达
无答案问题
容易混淆问题

然后分别对比不同 chunk 策略、embedding 模型、topK、rerank 是否有提升。

加分点

RAG 评估一定要包含“无答案问题”，因为很多系统在有答案时表现还行，但一旦没答案就开始胡说。

72. 怎么构建 bad case 集？

标准回答

bad case 集就是专门收集系统容易出错的样本，用于持续优化。

构建来源

线上用户真实问题
转人工案例
模型回答被投诉的问题
检索未命中的问题
格式错误、幻觉、高风险输出案例
同义表达、口语化表达、缩写、专业术语问题

分类方式

检索错
检索不到
生成错
引用错
格式错
越权/合规问题

加分点

bad case 集越贴近真实业务，越有价值。它通常比公开 benchmark 更能指导产品优化。

十、项目表达能力高频题

这部分是很多人最缺的。
面试官不是只想听“你会什么”，更想听“你做过什么，而且你能讲清楚”。

要解决什么问题
目标用户是谁
希望带来什么业务结果

示例

这个项目的业务目标主要有三个：

第一，降低人工客服或内部支持团队的重复答疑压力
第二，提高员工或用户获取信息的效率
第三，提升回答的一致性，避免不同人答复口径不一致

加分点

如果能讲出量化目标更好，比如：

人工答疑量下降多少
首次响应时间缩短多少
用户满意度提升多少

文档上传
文档解析
文本清洗
chunk 切分
embedding 向量化
向量库和元数据存储

第二层：在线问答层

用户提问
query 改写
检索召回
rerank
Prompt 拼接
模型生成
返回答案和引用来源

第三层：工程支撑层

用户鉴权
权限过滤
缓存
日志监控
异常重试
成本统计

文档处理链路
包括文档解析、切分策略和向量化入库流程
检索问答链路
包括 query 改写、topK 检索、rerank 接入和 Prompt 拼接
接口和稳定性建设
包括问答接口封装、异常处理、日志埋点和缓存优化

调整 chunk 策略，避免切得太碎
增加 query 改写，把口语问题转成更贴近文档表达的形式
引入 rerank，对召回结果重新排序
优化后，相关性明显提升，很多 bad case 被修正。

调整 topK，减少无关内容
加入 rerank，提高排序精度
Prompt 中要求必须基于资料并附来源
这样做的考虑是，先提高输入质量，再约束输出，比单纯切换更贵的模型性价比更高。

问答命中率
用户追问率
转人工比例
平均响应时长
结构化输出成功率

比如在某一轮优化后，检索命中率和答案相关性都有提升，用户重复追问也下降了。

如果没有具体数字怎么办

可以说：

“在内部测试集上有明显提升”
“bad case 数量明显下降”
“人工反馈准确性更高”
但不要空泛地说“效果挺好”。

评估体系前置
当时很多优化是靠人工感觉和零散 bad case 驱动，如果重做，我会更早建立标准测试集和分层评估指标。
链路可观测性更强
例如把 query 改写、检索结果、rerank 分数、最终 Prompt 都更完整地记录下来，这样排查会更高效。

第一，问题表面上看像模型答错，但根因其实在检索前面
第二，用户提问方式很多样，很难靠单一规则覆盖

我后来主要做了三方面优化：

调整 chunk 切分方式，尽量保留完整语义
加 query 改写，让用户问题更接近文档表达
接入 rerank，提升候选片段排序效果

最终在常见 bad case 上改善比较明显，系统回答的相关性更高了。

更早做评估体系
不等到后期才开始系统性评估
更重视数据治理
文档质量、切分质量、权限标签前置做好
更完善异常和监控
包括检索未命中、模型超时、格式失败、缓存失效等指标

文档处理
检索链路
模型生成
输出约束
异常处理
简单评估

加分点

自己做项目时，不要只停留在“调通 demo”，而要主动补这些内容：

为什么这样设计
遇到什么 bad case
怎么优化
如何评估效果

接口开发 -> 模型服务封装
异步任务 -> 文档解析、向量化任务
缓存设计 -> 热门问答缓存、结果缓存
权限系统 -> 知识库权限隔离
日志监控 -> 模型调用与检索链路监控
工作流系统 -> Agent/任务编排理解

加分点

正确的包装方式不是“把原项目说成 AI 项目”，而是强调你已经具备 AI 工程化所需要的底层能力。

十一、文章最后那 12 个收藏问题的完整答案版

下面把你文末列的 12 个问题，再集中做一版适合速背的“标准答案”。

85. 什么是 RAG？完整链路是什么？

标准答案

RAG 是检索增强生成。核心思想是：用户提问后，系统先从外部知识库中检索相关内容，再把这些内容作为上下文提供给大模型生成答案，从而提高准确性、降低幻觉。

完整链路通常包括：

文档上传
解析清洗
chunk 切分
embedding 向量化
向量入库
用户提问
query 改写
检索召回
rerank
Prompt 拼接
模型生成
结果后处理与返回

86. 文档为什么要切 chunk？怎么切？

标准答案

因为长文档不适合直接做高质量检索。切 chunk 可以让文本片段语义更集中，检索更精准，也更适合放入模型上下文。

常见切法有：

固定长度切分
按段落切分
按标题层级切分
带 overlap 的滑窗切分
语义切分

切太大容易噪音多，切太小容易语义不完整，所以需要结合业务场景调优。

提高检索质量
强约束 Prompt
低 temperature
拒答机制
引用来源
输出校验
高风险场景人审
这几个层面综合处理。核心不是完全消灭幻觉，而是尽量降低风险。

91. Prompt Injection 怎么防？

标准答案

防 Prompt Injection 不能只靠 Prompt，要做多层防御：

系统指令和用户输入隔离
恶意输入检测
工具最小权限
敏感信息不直接暴露
输出审核
高风险操作人工确认

92. 模型超时怎么办？

标准答案

模型超时时，可以从：

缩短上下文
控制超时
有限重试
备用模型切换
异步化长任务
兜底文案
监控告警
这些方面处理。

93. JSON 输出不稳定怎么办？

标准答案

可以通过：

明确 schema
few-shot 示例
使用 JSON mode / function calling
服务端解析校验
自动修复
失败重试
降级兜底
来提升稳定性。

94. 多轮对话上下文太长怎么办？

标准答案

常见做法包括：

裁剪最近几轮
历史对话摘要化
关键信息结构化保存
只保留与当前问题强相关内容
必要时做检索式记忆，而不是全量拼接

95. 如何评估一个 AI 问答系统效果？

标准答案

需要从多维度评估：

检索效果：Recall@K、命中率
生成效果：准确率、幻觉率、引用正确率
用户体验：响应时长、满意度、追问率
系统稳定性：超时率、错误率
业务价值：转人工率、人工答疑减少量

96. 你的项目里最难的问题是什么？怎么解决？

标准答案模板

我项目里最难的问题是 XX。它难在 XX。
我主要做了三件事：XX、XX、XX。
最后带来的效果是 XX。
这个回答建议一定结合你自己的项目，不要空背模板。

十二、给你一个真正适合学习的使用建议

如果你想把这份内容真正学进去，而不是看一遍就忘，我建议你这样用：

第一遍：按模块理解

先不要背，先理解这几大块：

岗位认知
后端基础
LLM 基础
RAG
Prompt
Agent
稳定性与成本
异常场景
项目表达

第二遍：挑重点高频题背诵

优先背这些高频题：

什么是 AI 应用开发岗
什么是 RAG，完整链路是什么
为什么要切 chunk
topK 和 rerank 的区别
幻觉怎么处理
Prompt Injection 怎么防
JSON 输出不稳定怎么办
模型超时怎么办
多轮上下文太长怎么办
项目里最难的问题是什么

第三遍：把答案改成你自己的项目版本

这一点最重要。
因为真正面试时，面试官一定会接着问：

你在项目里是怎么做的？
你为什么这么设计？
你遇到过什么问题？
你怎么验证优化有效？

如果你不把这些答案替换成你自己的项目，还是容易卡住。

第四遍：自己模拟追问

比如你回答：

我们用了 RAG 做知识库问答。

那你就继续追问自己：

文档怎么切的？
为什么这么切？
embedding 用的什么？
topK 为什么这么设？
rerank 用了吗？
没检索到怎么办？
幻觉怎么处理？
如何评估效果？