AI应用开发面试题精讲（五）：踩坑复盘与实战经验高频15问
文章目录
- AI应用开发面试题精讲（五）：踩坑复盘与实战经验高频15问
-
- 前言
- 一、RAG踩坑
-
- [1. 切分不合理导致召回差，怎么排查和解决？](#1. 切分不合理导致召回差，怎么排查和解决？)
- [2. 检索Top-K设置不合理，怎么调？](#2. 检索Top-K设置不合理，怎么调？)
- [3. 知识库更新了但RAG还是返回旧答案，为什么？](#3. 知识库更新了但RAG还是返回旧答案，为什么？)
- 二、大模型输出问题
-
- [4. 大模型输出JSON格式不稳定，怎么处理？](#4. 大模型输出JSON格式不稳定，怎么处理？)
- [5. 同一个问题，大模型每次回答都不一样，怎么办？](#5. 同一个问题，大模型每次回答都不一样，怎么办？)
- [6. 大模型输出截断（生成到一半停了），怎么处理？](#6. 大模型输出截断（生成到一半停了），怎么处理？)
- 三、Prompt工程踩坑
-
- [7. Prompt越来越长，成本飙升，怎么控制？](#7. Prompt越来越长，成本飙升，怎么控制？)
- [8. Few-Shot例子选择不当导致效果变差](#8. Few-Shot例子选择不当导致效果变差)
- 四、成本与性能踩坑
-
- [9. Token成本突然飙升，怎么排查？](#9. Token成本突然飙升，怎么排查？)
- [10. 缓存命中率低，怎么优化？](#10. 缓存命中率低，怎么优化？)
- 五、Demo到上线
-
- [11. Demo效果好但上线后效果差，最大的原因是什么？](#11. Demo效果好但上线后效果差，最大的原因是什么？)
- [12. AI应用怎么做测试？传统测试方法够用吗？](#12. AI应用怎么做测试？传统测试方法够用吗？)
- [13. 线上没有监控，出了问题怎么定位？](#13. 线上没有监控，出了问题怎么定位？)
- [14. 用户反馈说"回答不对"，怎么收集和处理？](#14. 用户反馈说"回答不对"，怎么收集和处理？)
- [15. AI应用上线后怎么持续优化？](#15. AI应用上线后怎么持续优化？)
- 总结
前言
这道面试题最区分人："你踩过什么坑？"背概念谁都会，但真正做过项目的人，能说出具体的问题现象、排查过程和解决方案。这篇整理了AI应用开发中最真实的15个踩坑场景。
一、RAG踩坑
1. 切分不合理导致召回差，怎么排查和解决？
参考答案：
问题现象：RAG系统上线后，用户反馈"明明文档里有答案，但系统答不出来"或"答非所问"。
排查步骤：
- 拿到bad case的query，手动检索知识库，看正确答案在哪个Chunk里
- 检查这个Chunk的切分边界是否合理------关键信息是否被切到两个Chunk里
- 检查Chunk大小------是否太大导致检索精度低，或太小导致上下文不足
- 检查Embedding------这个Chunk和query的相似度排名，是否在Top-K之外
常见原因和解决：
- 固定长度切分把一个完整概念切成了两半 → 改用递归切分或按结构切分
- Chunk太大（>1000 Token）→ 缩小到500-800 Token
- 没有重叠窗口 → 加50-100 Token重叠
- FAQ类文档按长度切分破坏了问答结构 → 按问答对切分
2. 检索Top-K设置不合理，怎么调？
参考答案：
问题现象：Top-K太少漏掉正确答案，太多引入噪音导致模型被干扰。
调优方法：
- 先评估召回率：用测试集统计不同Top-K下正确答案的召回率
- 看召回率曲线：Top-K从3到5到10到20，召回率提升的边际效应
- 配合重排器：召回Top-20-50，重排后取Top-5
经验值：
- 精确问答（FAQ）：Top-3-5，不需要重排
- 开放问答（知识库）：Top-5-10 + 重排
- 宽泛问题（"介绍一下X"）：Top-10-20 + 重排
坑点：Top-K不是越大越好。某次把Top-K从5调到20，准确率反而下降------因为20个Chunk里有15个不相关，模型被噪音干扰了。加重排器后解决。
3. 知识库更新了但RAG还是返回旧答案，为什么？
参考答案：
问题现象：文档已更新，但RAG系统还在返回基于旧文档的答案。
常见原因：
- 向量库没更新：文档改了但没触发重新Embedding和索引
- 缓存没清：语义缓存命中了旧答案
- CDN缓存：如果文档通过CDN分发，CDN缓存未刷新
- 增量索引失败：增量更新流程有bug，新文档没入库
解决和预防：
- 建立文档更新→索引更新的自动化流水线
- 文档更新时主动清除相关缓存
- 向量库中每条数据带版本号和更新时间
- 定期做全量重建对齐，防止增量累积偏差
- 监控知识库更新后N小时内的查询质量
二、大模型输出问题
4. 大模型输出JSON格式不稳定，怎么处理？
参考答案：
问题现象：Prompt里要求输出JSON，但模型偶尔输出带多余文字、字段缺失、嵌套错误。
原因分析：
- Prompt描述不够明确
- Temperature过高
- JSON结构太复杂（嵌套超过3层）
- 模型本身对结构化输出的支持不够好
解决方案：
- 用Function Calling：比Prompt描述格式更可靠
- Prompt优化：给一个最小JSON示例，比文字描述有效
- 降低Temperature：0-0.3，减少格式变异
- 输出校验+修复重试：解析失败时把错误信息附在Prompt后面让模型修正
- 降级解析：用正则从非标准JSON中提取关键字段
- 多次采样取优：生成3次取第一个通过校验的
预防措施：上线前用1000条测试case验证格式合规率，低于99%不上线。
5. 同一个问题，大模型每次回答都不一样，怎么办？
参考答案：
问题现象：同一query多次调用，答案内容、格式、准确度差异很大。
原因分析：
- Temperature过高
- 上下文拼接不稳定（历史对话裁剪逻辑有问题）
- 检索结果不稳定（向量库更新或并发写入导致排序变化）
- 模型服务端更新
解决步骤：
- 先固定Temperature=0，看是否还不一致
- 固定检索结果（关闭增量索引，用快照），看是否稳定
- 检查Prompt是否有随机性（如"随机选一个角度回答"）
- 如果以上都排除了还不一致，可能是模型服务端问题
实践建议：生产环境关键场景Temperature设0-0.3，需要多样性时用0.5-0.7，不要超过1.0。
6. 大模型输出截断（生成到一半停了），怎么处理？
参考答案：
原因分析：
- max_tokens设置太小：输出长度限制不够
- 上下文窗口不够：输入太长，留给输出的空间不够
- Stop sequence误触发：输出中碰巧包含了stop词
- API超时：生成时间太长被服务端断开
解决方案：
- 合理设置max_tokens，根据任务类型预留足够空间
- 精简输入Prompt，给输出留足窗口
- 检查stop sequence是否过于宽泛
- 用流式输出避免超时------流式连接不容易被断开
- 截断检测：输出末尾不是正常结束符（如句号、```）时，自动续写
三、Prompt工程踩坑
7. Prompt越来越长，成本飙升，怎么控制？
参考答案：
问题现象：系统Prompt从最初的500 Token膨胀到3000 Token，每次调用都在烧钱。
常见原因：
- 不断往系统Prompt里加规则、加约束、加例子
- Few-Shot例子越加越多
- 上下文历史越拼越长
控制手段：
- 定期审计Prompt：去掉冗余规则、合并相似约束
- 动态Few-Shot：不固定所有例子，按query类型选2-3个最相关的
- 上下文裁剪：只保留最近N轮+摘要，不堆全量历史
- Prompt分层：系统Prompt（固定）+ 场景Prompt（动态）+ 用户输入
- Token监控：按场景设置Token预算，超预算告警
8. Few-Shot例子选择不当导致效果变差
参考答案：
问题现象：加了Few-Shot例子后，效果不升反降。
常见问题：
- 例子和当前query不相关，误导模型
- 例子之间有矛盾，模型不知道该学哪个
- 例子格式不统一，模型学到了不一致的输出模式
- 例子太多，占用了大量上下文空间
解决方法：
- 动态选择例子：用向量检索选和当前query最相似的case作为Few-Shot
- 例子去重：确保例子之间有差异性
- 格式统一：所有例子严格遵循同一格式
- 控制数量：2-3个例子通常就够，不要超过5个
- 定期更新例子库：发现bad case后加入例子库，好case保留
四、成本与性能踩坑
9. Token成本突然飙升，怎么排查？
参考答案：
排查步骤：
- 看监控：是哪个API/哪个用户/哪个场景的Token突增？
- 看输入Token占比：如果是输入Token突增，可能是上下文没裁剪好
- 看重试次数：是否因为错误率升高导致大量重试
- 看缓存命中率：缓存是否失效导致全量走模型
- 看是否有异常调用：是否有用户在刷接口
常见原因：
- 对话历史没做裁剪，越聊越长
- RAG召回太多文档塞进上下文
- 缓存策略改了导致命中率骤降
- 某个用户大量调用（可能在爬数据）
- Prompt被改了变长了
10. 缓存命中率低，怎么优化？
参考答案：
问题现象：上了语义缓存，但命中率只有5%，没起到降本作用。
排查和优化：
- 看相似度阈值：太高（0.99）几乎命中不了，太低（0.85）可能返回错误答案。建议从0.95开始调
- 看query分布：如果用户query非常分散（每个都不一样），缓存本来就不太有效
- 看缓存TTL：TTL太短，热点还没形成就过期了
- 看缓存大小：容量太小，LRU淘汰太快
优化策略：
- 对FAQ类高频问题，可以预填充缓存
- 对时效性不敏感的场景，TTL设长一些（24小时+）
- 分场景设不同阈值------FAQ场景设高阈值，通用问答设中阈值
- 监控缓存命中后的用户反馈，确保没有"答非所问"
五、Demo到上线
11. Demo效果好但上线后效果差，最大的原因是什么？
参考答案：
核心原因：Demo的测试数据太干净，生产数据太脏。
具体差异：
- 输入质量：Demo用标准问题，生产中用户提问各种各样、表述不清、有错别字
- 知识库差异：Demo用精选文档，生产的知识库有大量低质量、过时、重复文档
- 并发压力：Demo单请求，生产高并发导致排队、超时、降级
- 用户预期：Demo你自己测，知道边界在哪；生产用户会问各种边界问题
- 数据漂移：Demo用的模型版本和生产可能不同
解决方法：
- 上线前用真实用户数据做测试（从客服日志里挖）
- 做"红队测试"------专门找人尝试问各种刁钻问题
- 灰度发布，先放5%流量观察
- 建立"bad case收集→分析→修复"的闭环
12. AI应用怎么做测试？传统测试方法够用吗？
参考答案：
传统测试不够：传统测试是"给定输入，期望确定输出"，AI应用输出非确定。
AI测试方法：
- 评估集测试：人工标注100-500个case（query+期望答案要点），每次发版跑一遍
- LLM自动评估：用另一个大模型评估输出质量（打分1-5）
- 对抗测试：Prompt注入、越界输入、极端长度
- A/B测试：线上对比新旧版本
- 混沌测试：模拟模型超时、向量库故障等异常场景
关键指标：
- 格式合规率 > 99%
- 准确率（人工评估）> 90%
- 拒答率 < 5%（该答的不拒）
- 幻觉率 < 3%
13. 线上没有监控，出了问题怎么定位？
参考答案：
这就是一个坑------没有监控的AI系统就像盲飞。
紧急定位：
- 先看大模型API的调用日志（请求量、错误率、延迟）
- 看应用服务器日志，搜error/timeout关键词
- 找几个出问题的case，手动复现
- 检查最近是否有变更（Prompt修改、模型升级、数据更新）
亡羊补牢：
- 立刻加：Token消耗监控、错误率监控、延迟监控
- 尽快加：链路追踪（每个请求的完整调用链）、质量监控（采样人工check）
- 逐步加：用户反馈收集、自动评估流水线
面试金句：没有监控的AI系统不应该上线。监控的成本远低于线上事故的损失。
14. 用户反馈说"回答不对"，怎么收集和处理？
参考答案：
收集渠道：
- 显性反馈：点赞/踩、反馈按钮、投诉
- 隐性反馈：用户重试、重新提问、放弃使用
- 主动收集：定期抽样回访、用户问卷
处理流程：
- 分类：是检索问题、生成问题、还是用户预期问题
- 归因：检索没召回→优化切分/检索策略；召回了但答错→优化Prompt/模型
- 修复：bad case加入评估集，修复后回归测试
- 反馈：告诉用户"问题已修复"------这很重要，用户觉得反馈有价值才会继续反馈
15. AI应用上线后怎么持续优化？
参考答案：
优化闭环：
- 收集：bad case + 用户反馈 + 监控告警
- 分析：归类原因（检索/生成/Prompt/模型/数据）
- 优化：针对性改进
- 验证：评估集回归测试 + 灰度发布
- 上线：全量发布 + 持续监控
- 回到1
优化优先级：
- 先修P0（线上故障、安全问题）
- 再修P1（高频bad case、成本问题）
- 最后做P2（体验优化、长尾case）
关键原则：每次优化只改一个变量，不要一次改切分策略+换模型+改Prompt------出问题都不知道是哪个导致的。
总结
踩坑复盘题考察的是真实经验。面试官想听的是"我遇到了什么问题→我怎么排查的→我怎么解决的→我学到了什么"。如果你只说概念不说故事，面试官会觉得你没做过。最好的准备方式是：把你的项目经历写成"踩坑日志"，每个坑记录清楚问题、原因、方案和教训。