线上幻觉问题排查，这道真题在运维岗面试高频出现。大模型应用上线后，各种奇奇怪怪的问题接踵而来——模型胡说八道、响应延迟飙升、准确率突然下降、用户投诉扎堆。这些问题往往不像传统软件bug那样有明确的报错堆栈，排查起来让人头大。

今天就模拟真实线上故障排查场景，用12道真题带你捋清AI系统的诊断思路。

---

【真题1】线上出现幻觉怎么排查？

用户反馈我们的AI在回答数据类实时问题时会出现胡编乱造，比如问某公司2024年营收，模型编了一个看起来很真但实际错误的数字。如何排查？

参考解析：

这道题考查的是幻觉问题的根因定位能力和产品兜底思维。

幻觉问题分两大类排查方向：

第一类：生成结果与数据源不一致

• 检索召回的文档是否相关？有时候召回的文档本身就含错误信息
• 模型是否误解了上下文？需要在prompt里明确约束
• 训练数据和知识库数据是否对齐？有没有冲突的信息

第二类：用户问题超出模型认知边界

• 问题是否在知识库覆盖范围内？需要做准入判断
• 是否涉及实时数据？模型训练截止日期之后的信息天然不知道

排查步骤：

1. 拿到用户的原始问题和模型的回答
2. 检查检索日志，看召回了哪些文档
3. 人工判断召回文档是否相关、是否包含正确信息
4. 如果文档没问题，检查prompt是否有足够的约束
5. 如果prompt也正常，考虑是否需要工具调用能力

产品层面的止血方案：

prompt里强制约束"不知道就说不知道"，但这个方案约束性有限。更强的方式是引入工具调用——当用户问数据类问题时，模型不应该直接回答，而是调用API或数据库接口，拿到真实数据后再组织输出。

另一个关键是增加确定性标识。比如在回答上方提示"正在从财务系统查询最新数据"，让用户知道这个数据是查出来的不是编的。对于高风险数据，增加可点击的溯源图标，用户能看到数据来源、查询时间、原始链接。

---

【真题2】用户反馈回答不准确，如何定位问题出在哪一环？

客服系统上线后，用户反馈模型回答经常答非所问。系统包含意图识别、检索、重排序、生成多个模块，问题可能出在哪？

参考解析：

这道题考查的是系统化的分层排查能力。

AI产品是多模块串联的，问题往往隐藏在某个环节。排查时要分层拆解，逐个检查：

第一层：意图理解是否正确？

• 查询有没有被正确改写？
• 用户真正的需求有没有被识别出来？
• 如果意图识别就错了，后面全白搭

第二层：检索召回是否相关？

• 召回了哪些文档？人工看一遍是否相关
• 召回率够不够？关键信息有没有漏掉
• 如果检索没找到相关信息，可能是知识库本身缺失

第三层：重排序是否合理？

• 相关文档有没有排到前面？
• 排序策略是否符合业务场景

第四层：生成是否符合预期？

• prompt有没有给足够的约束？
• 上下文组织是否清晰？

实际排查时，我会深入分析系统日志和埋点数据：

• 检索召回率、生成token数等关键指标
• 异常堆栈、超时记录
• 人工抽检召回文档，判断问题出在检索还是生成

常见的根因会落在四个地方：数据问题、模型问题、工程问题、产品设计问题。比如某次排查发现，回答不准确是因为上线时赶工跳过了某个优化环节。

---

【真题3】RAG用了还是产生幻觉，为什么？

项目已经引入了RAG检索增强生成，但模型还是会胡编乱造，问题出在哪？

参考解析：

这道题考查的是对RAG局限性的理解。

很多人以为上了RAG就万事大吉，实际上RAG只能降低幻觉，不能根治。幻觉产生的根源有几种：

根源一：检索文档本身就不可靠

• 知识库里的文档质量参差不齐
• 多个文档之间存在矛盾信息
• 文档过时了但没有更新

根源二：检索召回不完整

• 用户问题需要的知识点分散在多个文档
• 召回的top-k文档没有覆盖全
• 关键信息被切分到不同的chunk，语义被切断

根源三：模型理解能力缺陷

• 模型误解了上下文
• prompt约束不够强，模型自己脑补了内容

解决方案：

prompt里加约束"请根据以上内容回答，不知道就说不知道"，能减少一些瞎编，但当问题和上下文有点关联时，模型还是会自己补全，约束性有限。

更强的方案是引入ReAct思想，让大模型对输出结果进行反思。或者集成知识图谱，不仅召回文档块，还召回图中的三元组，利用结构化的关联数据增强推理能力。

如果文档是PDF格式，知识图谱可以用大模型抽取三元组，比如"产品A支持功能B"。但抽取出错会让幻觉更严重，需要人工校验，成本较高。

---

【真题4】多轮对话上下文丢失怎么处理？

用户反馈和AI聊了几轮之后，AI就"失忆"了，忘了前面说的内容。这个问题怎么排查和解决？

参考解析：

这道题考查的是上下文管理能力。

上下文丢失和token消耗过高是关联问题——处理不好就会陷入"保留上下文就超token，砍掉上下文就丢信息"的死循环。

排查方向：

1. 当前使用的模型上下文窗口是多少？
2. 平均每轮对话消耗多少token？
3. 多少轮之后开始出现失忆？

解决方案：分层上下文管理 + 智能裁剪

分层管理：把历史对话拆成核心信息和冗余信息

• 核心信息：用户核心需求、关键约束条件、已确认结论，存到数据库，每次请求作为系统提示补充
• 冗余信息：寒暄、重复提问，只保留第一次问答

智能裁剪：设置token阈值（比如模型上限的80%），触发时做摘要

• 不是简单删除前面的内容
• 用模型生成对话摘要，把冗余对话压缩成一两句核心逻辑
• 比如用户聊了十轮关于退换货的问题，摘要后变成"用户购买连衣裙七天内未拆封，咨询无理由退换货流程和运费承担"

这个方案能把token消耗降低60%以上，同时保持对话连贯性。

---

【真题5】响应延迟突然从300ms涨到2秒，怎么排查？

智能客服系统平时响应300ms左右，最近突然飙升到2秒，偶发超时。如何定位和解决？

参考解析：

这道题考查的是性能问题排查和优化能力。

排查方向：

1. 监控大盘看趋势——是渐进式上涨还是突然跳变？
2. 检查请求量——是否有流量高峰？
3. 检查各环节耗时——意图识别、检索、调用LLM各花多少时间？
4. 检查上游服务——第三方API是否有异常？

常见原因：

• 第三方API响应延迟变高（最常见）
• 并发量超过系统承载能力
• 缓存失效导致大量请求穿透到模型层
• 数据库查询变慢

优化方案：三管齐下

减少请求量：

• 加多级缓存：一级精准匹配（问题哈希→回答），二级模糊匹配（问题向量→相似回答），三级热门文档embedding结果
• 这样30%的请求直接走缓存，不用调用大模型

优化请求链路：

• 异步调用 + 请求合并：同一模型3秒内的多个相关问题合成一个请求
• 用Celery做异步并发调用，并发量提升2倍

提升资源利用率：

• 对接模型服务的动态扩缩容接口
• 根据请求队列长度自动调整并发数
• 峰值扩到100，低谷缩到20

优化后95%的延迟控制在500ms以内，完全满足高峰期需求。

---

【真题6】模型准确率虚高但用户不满意，怎么分析？

算法团队报告模型准确率85%，但用户投诉推荐不精准。这个矛盾怎么解释？

参考解析：

这道题考查的是指标设计和用户需求的匹配度分析。

准确率虚高是AI产品常见问题，根源往往是指标计算方式和真实需求错位。

分析维度一：检查准确率的计算逻辑

推荐场景常见问题：准确率按"用户点击"计算，但用户点击可能是误触，或者点进去发现质量差立刻退出。这种无效点击被算成有效指标，导致虚高。

解决方案：加入点击后停留时长维度，过滤掉3秒内跳出的点击，准确率立刻现原形。

分析维度二：用户目标和模型目标是否对齐

模型只学了历史点击数据，但用户有潜在需求没被挖掘。比如用户买了婴儿奶粉，模型一直推奶粉，但用户接下来需要的是婴儿湿巾、辅食。模型准确率再高，也没满足真实需求。

解决方案：加入用户生命周期标签，结合产品场景拓展推荐维度。

分析维度三：体验细节

模型回答准确但生硬。比如用户问天气，模型回答"今天气温25度，降水概率30%“，准确率没问题，但用户想知道的是"要不要带伞、穿什么衣服”。

解决方案：在模型输出后加自然语言润色层，生成更有帮助的答案。

---

【真题7】冷启动问题怎么解决？

新上线的AI产品没有用户、没有数据、模型效果差，这个死循环怎么破？

参考解析：

这道题考查的是产品冷启动策略。

冷启动本质是没数据、没用户、模型效果差的恶性循环。需要从用户侧和模型侧双向解决。

用户侧：精准种子用户 + 低门槛反馈

不要一开始就铺向大众市场。找精准的种子用户群体——比如面向设计师的AI产品，先和设计社区合作，邀请1000个资深设计师免费用。他们的需求明确、反馈质量高，还能帮忙推广。

设计低门槛的反馈机制：用户用模型生成图片后，让他们选择"喜欢"或"不喜欢"，选完给积分，积分能换更多额度。

模型侧：借外部数据 + 降预期

借外部数据：购买行业公开数据集，或者用通用大模型能力做基础。比如做设计师配色服务，先用Stable Diffusion做基础对话，再用自有数据微调。

降预期：不宣称什么都能做，聚焦一个小场景。比如只帮设计师生成海报配色方案，针对性优化，效果会比泛泛的产品好很多。累积一两万条用户反馈后，再迭代拓展。

---

【真题8】判断业务是否适合用大模型，核心看什么？

业务方想用大模型改造某个流程，怎么判断值不值得做？

参考解析：

这道题考查的是技术选型的商业思维。

核心判断逻辑是看"值不值得做"，而不是"能不能做"。很多人只关注技术可行性，忽略了ROI。

四个维度初筛：

任务复杂度：像客服问答、文档总结这种用户问法千奇百怪、没法写成规则的场景，大模型优势明显。但点按钮导出报表这种固定流程，规则引擎足够了。

数据成本：以前做小模型要标几万条数据，现在用大模型配合prompt，几十个例子就能跑起来，适合标注资源少的场景。

投入产出比：客服团队20人每天处理1000咨询，大模型能自动解决70%，省下14人成本，划算。但一天就几十个请求，或者准确率只从90%提到95%，没必要。

技术风险：医疗法律这种容错率极低的场景，要加一堆防护机制。数据安全问题也要考虑，涉及隐私或商业机密，用公有API有风险，私有化部署成本又上去了。

两个硬性标准：

不可替代性：不用大模型有没有更便宜的方案？比如用户问"订单退了吗"，查数据库就行，不用上大模型。能用RAG解决的就不要用微调，能用规则兜底的就别全靠生成。

ROI量化：单次调用成本不能超过人工处理成本的1/10。比如客服人力成本1块1次，大模型方案必须压缩到1毛以内。做不到，效果再好也不批准上线。

必须有降级路径：大模型可能超时、返回乱码、编造答案。业务逻辑里一定要有Plan B：客服答不出来切FAQ，总结失败返回原文，识别不精准转人工。没有兜底的AI功能，上线就是埋雷。

---

【真题9】上线后周活率只有40%，远低于预期60%，怎么拆解？

智能知识库全公司上线一个月，周活率只有40%，预期是60%。问题出在哪？

参考解析：

这道题考查的是数据驱动的产品迭代能力。

我会从三个维度拆解：用户会不会用、用了有没有用、有没有动力用。先拿数据，再找真人访谈。

维度一：行为数据

看用户打开产品后30秒内退出的占比。如果很高，可能是引导不清楚，用户不知道怎么提问。

看提问后得到有效回答的比例。如果超过20%回答无效，核心功能没解决需求。

维度二：找真人访谈

不同部门需求不同。行政部门查报销流程，技术部门查接口文档。假设访谈后发现两个核心问题：一是用户觉得打字提问不如发问便捷，二是专业问题回答不准确。

维度三：针对性优化

问题一的解决方案：加语音快捷提问和常用问题一键触发功能。

问题二的解决方案：联动业务部门梳理高频专业问题，补充到知识库，优化匹配规则。同时联合运营做使用打卡活动，连续三天用产品查问题可兑换下午茶，提升初期使用率。

两周后看数据，重点盯退出率和有效回答率的变化，再调整后续策略。

---

【真题10】数据工程做了哪些关键工作？

你的项目数据集是怎么准备的？预处理做了什么？

参考解析：

这道题考查的是数据工程能力。实际上，AI项目70%的效果提升来自数据工程，只有30%来自模型改进。

数据来源：真实行业场景，5万条高质量问答，1000多份技术文档和操作手册。

预处理四件事：

清洗过滤：去除重复、语义残缺、长度小于10字的无效样本。

文本切块：对长文档做语义边界切分，每块控制在512 token内，保留100 token重叠，防止关键信息被切断。

结构化构造：长文档切分后，用规则+启发式方法生成"上下文+问题+答案"三元组，让模型学会从上下文中推理答案。

轻量增强：针对长尾问题，用同义替换、句式变换等方式扩充到万条，缓解小样本问题。

效果对比：

纯RAG方案测试过，但行业术语太专业，检索召回率低，经常答非所问。最终走了RAG+轻量微调路线：RAG负责动态更新，微调负责精准输出。这个思路是对的——不是微调不行，而是单一方案扛不住真实场景的复杂性。

---

【真题11】模型量化在项目里用过吗？效果如何？

参考解析：

这道题考查的是工程落地能力。

量化是把模型权重从float32转成int8或int4等低精度格式，目的是降低显存占用和推理延迟。

项目背景：模型要部署到边缘设备，显存限制16GB。

方案选择：

尝试了int8量化：

• 模型体积缩小到原来的1/4
• 推理速度提升30%
• 准确率只下降2%，可接受

也尝试了int4量化：

• 准确率下降接近6%
• 在目标设备上推理不稳定，经常崩溃

最终决策：int8是当前场景最优选择，2%的精度损失换来四倍体积压缩和30%速度提升。

量化不是万能的，需要根据场景权衡精度损失和性能收益。对于边缘设备部署，量化几乎是必选项。

---

【真题12】大模型与外部系统集成怎么设计？

项目需要对接ERP、CRM、内部知识库、数据库等多个系统，怎么设计交互方案？

参考解析：

这道题考查的是架构设计能力。

多系统集成要解决两个核心问题：跨系统数据格式不一致、敏感数据不泄露。

解决方案：中间适配层 + 安全校验机制

中间适配层用FastAPI写统一的接口网关，所有大模型调用外部系统的请求都走这个网关。

网关里做两件事：

数据格式转换：

• 把大模型的自然语言指令转成各系统支持的API参数格式
• 把外部系统返回的JSON数据统一转成模型能理解的结构化文本

请求路由：

• 根据指令关键词自动匹配对应系统接口
• 含"库存"“订单"的走ERP，含"客户”"跟进"的走CRM

安全校验机制：

• 敏感字段脱敏，比如客户手机号只传后四位
• 请求频率限制，防止恶意调用
• 日志审计，记录所有跨系统调用

这套方案让大模型能够安全、规范地调用多个外部系统，同时保持代码的可维护性。

---

故障排查Checklist

线上问题排查，有一套标准流程可以遵循：

第一步：问题分类和优先级判断

• 功能性bug：P0立刻响应
• 效果问题：P1当天解决
• 体验问题：P2排期处理
• 需求类反馈：P3纳入规划

第二步：复现问题

• 向用户索取关键信息：原始输入、期望结果、时间戳
• 测试环境和生产环境反复验证
• 多跑几次判断是稳定复现还是偶发波动

第三步：分层排查

• 意图理解是否正确？
• 检索召回是否相关？
• 重排序是否合理？
• 生成是否符合预期？

第四步：数据分析

• 系统日志：异常堆栈、超时记录
• 关键指标：检索召回率、生成token数、调用成功率
• 人工抽检：判断问题出在检索还是生成

第五步：确定根因

• 数据问题：知识库缺失、数据质量差
• 模型问题：理解能力不足、prompt约束弱
• 工程问题：并发处理、缓存失效
• 产品设计问题：需求理解偏差

第六步：止损和修复

• 紧急问题先快速止损：降级方案、回滚
• 根本性修复：优化策略、补充知识库、调整检索

日常预防措施：

• 监控大盘：响应延迟、调用成功率、用户反馈量
• 告警阈值：延迟超500ms、成功率低于95%触发告警
• 定期复盘：分析高频问题、优化知识库、迭代策略

掌握这套排查思路，线上问题就不会手忙脚乱。关键是养成"先分类、再复现、分层排查、数据驱动"的习惯。