先泼一盆冷水：RAG 的 demo 和生产的距离
Demo 阶段的 RAG 都很好：随便找几篇文档灌进去，问什么都能「答」出来。但一上生产就露馅——答非所问、编造数据、引用错文件、用户问法一变就崩。
我在项目里反复看到同一个规律：知识库类项目 80% 的失败，不是模型不行，是检索链路不行。检索决定上限，生成只是把检索到的内容翻译成人话。
检索链路：四个被低估的环节
1. 切分（Chunking）不是「按字数切」
默认按 500 字硬切，会把一个完整的业务规则从中间劈开，召回时上下文残缺。踩坑后的做法：
- 优先按语义边界切：Markdown 标题、段落、表格行。
- 为每个 chunk 保留父文档引用：召回后回带整节内容，而不是孤零零一段。
- 表格、代码片段单独处理——向量化表格行效果很差，往往需要「行 + 表头」拼接。
2. 召回（Retrieval）不只是向量搜索
向量搜索对「同义改写」友好，但对「精确术语、编号、条件判断」很弱。生产做法是混合检索：向量召回 + 关键词/BM25 召回，用 RRF（倒数排名融合）合并，再按业务规则重排。
踩坑记录：用户问「报销超过 5000 元需要什么流程」，向量只召回「报销流程」相关段落，但「5000 元阈值」这个精确条件全靠 BM25 命中。没有混合检索，这类问题必错。
3. 重排（Rerank）
top-50 粗召回后用一个重排模型精排到 top-5，召回质量能明显提升。这一步很多人跳过，却常常是「能用」和「好用」的分界线。
4. 引用可验证
生产环境必须给用户「引用来源」，否则答错了用户无法自查，信任崩塌。引用还要精确到段落，而不是「来自 3 号文档」。
幻觉治理：先认清幻觉的三个来源
- 检索不到：库里根本没有答案 → 应该让模型明确说「不知道」，而不是硬编。我在提示词里强制输出「未找到相关内容」分支，配合答案置信度阈值。
- 检索到但拼错了：多文档信息冲突 → 需要文档时效性排序、权威性加权。
- 模型「太想答」：prompt 与温度设置问题 → 业务场景温度拉低（≤0.2），答案格式约束为 JSON 便于校验。
核心观点：幻觉治理的第一优先级不是模型，是「让模型有机会说不知道」。一个允许拒绝回答的系统，比一个硬答的系统可信得多。
生产级架构：缓存、限流与降级
把大模型当后端组件，就要按后端组件的标准对待：
- 缓存：完全相同的 query 直接命中缓存；语义相似 query 用 embedding 相似度做短时缓存。token 成本能省 30%–50%。
- 限流：按用户 + 按全局双层限流，防止爬虫和刷量把账单打爆。
- 降级：模型超时/不可用时，降级为「仅检索，返回原文片段」，而不是报错。用户能拿到原文，体验远好于 500。
- 可观测性：记录每次问答的 query、命中 chunk、token 用量、延迟与「拒绝回答」率——这是调优的唯一依据。（详见系列后续章节）
成本账：为什么必须算「每次问答」的钱
很多人只算了模型单价，没算清楚：
单次问答成本 = 输入 tokens × 输入单价 + 输出 tokens × 输出单价
RAG 的输入含检索上下文，经常是 3000–5000 tokens；一次用户对话平均 2–3 轮。一个日活 1 万的场景，月成本可以轻松到五位数。缓存的收益在这里不是优化，是生存问题。
落地清单
- 切分按语义边界，保留父文档引用
- 混合检索（向量 + BM25）+ RRF 融合
- 接入重排模型精排 top-5
- 答案带段落级引用
- 支持「拒绝回答」分支与置信度阈值
- query 缓存 + 双层限流 + 降级为原文返回
- 记录全链路可观测日志
- 上线前用真实业务问题集跑一遍准确率基线
延伸阅读：AI 项目 POC 评估清单 · 工具见 工具与工作流