开篇：智能客服的三大“老毛病”
做智能客服的同学都懂，“答非所问”比“答不上来”更让用户抓狂。过去一年，我们团队把传统 FAQ-Bot 升级成 AI 大模型方案，踩坑无数，总结下来最痛的点无非三条：
- 知识库更新延迟：业务文档一周三版，模型微调一次 8 小时，上线后用户已经问到 2.0 功能，Bot 还在讲 1.0。
- 多轮对话上下文丢失：用户追问“那第二个方案呢？”，Bot 直接失忆，只能从头再来。
- 长尾问题应答率低：冷门报错代码、边缘场景占咨询量 20%，传统检索命中率 <30%，只能转人工。
RAG（Retrieval-Augmented Generation）把“实时检索”与“大模型生成”拼在一起，正好对症下药。下面把从 0 到 1 的实战笔记摊开，能抄的代码直接抄，能避的坑提前标红。
一、RAG 为什么比微调更香？一张表看懂
| 维度 | 微调（Fine-tune） | RAG |
|---|---|---|
| 数据更新 | 重新训练，天级延迟 | 向量库分钟级增量 |
| 训练成本 | GPU×小时+标注人力 | 仅需 Embedding 一次 |
| 推理时延 | 单模型 1× | 检索+LLM 2×，可并行 |
| 可维护性 | 版本回滚重训 | 向量增删即时生效 |
| 可解释性 | 黑盒 | 检索结果可透出 |
一句话：业务节奏快、知识常变，RAG 把“训练”变“索引”，运维同学也能搞定。
二、分层架构：Query→检索→生成
- Query 理解层
- 意图分类 + 关键词提取
- 指代消解（把“这个错误”还原成具体报错）
- 向量检索层
- 文本 Embedding（维度 768/1024）
- FAISS IndexFlatIP，支持实时增删
- LLM 生成层
- Prompt 模板拼接检索结果
- 温度 0.1，保证稳定输出
三、核心代码：FAISS + Prompt 工程
3.1 离线建索引
# embedding.py import faiss, json, torch from sentence_transformers import SentenceTransformer model = SentenceTransformer('paraphrase-multilingual-mpnet-base-v2') dim = model.get_sentence_embedding_dimension() docs = [d['content'] for d in json.load(open('kb.json'))] embeds = model.encode(docs, batch_size=64, show_progress_bar=True) index = faiss.IndexFlatIP(dim) # 内积相似度 index.add(embeds.astype('float32')) faiss.write_index(index, 'kb.index')时间复杂度：O(N×L) 其中 N 文档数，L 平均 token 长度；一次建库，离线完成。
3.2 在线检索
# retriever.py import faiss, torch, json from sentence_transformers import SentenceTransformer model = SentenceTransformer('paraphrase-multilingual-mpnet-base-v2') index = faiss.read_index('kb.index') meta = json.load(open('kb.json')) def search(query, top_k=5): qv = model.encode([query]) scores, ids = index.search(qv.astype('float32'), top_k) return [(meta[i]['content'], float(scores[0][k])) \ for k, i in enumerate(ids[0])]单次检索 <30 ms（10 万条 768 维，CPU）。
3.3 Prompt 模板
prompt_tmpl = """ 你是客服小助手，只能使用以下知识回答问题，禁止编造： {context} 用户问题：{query} 如果以上信息无法回答，请说“暂无答案”。 """把 top_k=3 结果拼进{context}，LLM 只负责“总结+口语化”，幻觉率明显下降。
四、性能：top_k 与耗时的跷跷板
实测 10 万条知识库，CPU 检索：
| top_k | 平均耗时 | 答案覆盖率 |
|---|---|---|
| 1 | 18 ms | 68 % |
| 3 | 21 ms | 85 % |
| 5 | 25 ms | 89 % |
| 10 | 32 ms | 90 % |
线上选 3，兼顾体验与召回；对长尾问题可异步再跑 10，Merge 后重排序。
五、大模型 API 限流 & 降级
- 令牌桶限流：单账号 60 req/min，超量返回 429。
- 降级策略：
- 触发限流 → 切换“检索结果直接返回”模式，去掉 LLM 总结；
- 监控检索置信度均值 <0.75 → 自动转人工。
代码片段（FastAPI middleware）：
from slowapi import Limiter limiter = Limiter(key_func=lambda: "global") @app.post("/chat") @limiter.limit("60/minute") def chat(req: Query): try: return llm_chain.run(req.query) except RateLimitError: return {"answer": search_only(req.query), "degraded": True}六、安全：别让 Bot 当“泄密侠”
6.1 敏感信息过滤
import re def mask_sensitive(text): patterns = [ (r'\b\d{15,}\b', '[银行卡]'), (r'1[3-9]\d{9}', '[手机号]'), (r'([A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,})', '[邮箱]'), ] for p, mask in patterns: text = re.sub(p, mask, text) return text在 Query 入口与知识入库双端过滤，确保日志干净。
6.2 版权合规检查流程
- 语料来源白名单：只采官方手册、公开文档。
- 上传时自动跑 Hash，与版权库比对，重复度 >80 % 直接拒绝。
- 每月人工抽检 5 %，发现侵权立即下架向量并记录审计。
七、避坑指南：向量维度灾难与状态幂等
7.1 向量维度灾难
768 维对 10 万条还好，上到千万级 IndexFlatIP 内存爆炸。解决：
- 量化：IndexIVFPQ(768→64, nlist=4096) 内存降 8×，召回率掉 2 % 可接受。
- 分层检索：先倒排关键词粗排 1000 条，再向量精排 top_k=5，耗时稳定 50 ms 内。
7.2 对话状态管理的幂等设计
用户重复点击“重新回答”会触发相同请求，不做幂等将重复扣费、生成不一致答案。做法：
- 用 session_id+query 做 key，Redis 缓存 5 分钟，TTL 内直接返回。
- 对状态ful 场景（订单号、工号）把变量抽成结构化 slot，存 Redis Hash，每次只改增量字段，保证重试结果一致。
7.3 冷启动语料增强
上线初期只有 300 条官方 FAQ，覆盖率 40 %。三招快速扩量：
- 把历史工单脱敏后跑关键词 TF-IDF，自动提取高频问句；
- 用 LLM 反向生成：给模型 prompt“用户可能会如何问以下答案？”批量生成 5 种问法；
- 灰度上线后，把用户“点踩”的问题自动加入待标注池，运营每日审核 50 条，一周扩到 2 k 条，覆盖率提到 80 %。
八、生产部署 checklist
- k8s 独立命名空间，CPU 节点跑检索，GPU 节点只跑 LLM，避免抢占。
- 向量库每天凌晨增量备份到对象存储，版本号=日期+git sha。
- Prometheus 监控：检索 P99<50 ms、LLM 成功率>99 %、幻觉率<3 %。
- 双集群热备，云厂商 LLM 异常 30 s 内自动切到备用账号。
九、还没想明白的问题
检索质量（召回、排序）与生成质量（幻觉、口语化）就像跷跷板：给 LLM 的上下文越多，生成越稳，但召回噪声也会把答案带偏。线上 A/B 测了一个月，发现把 top_k 从 3 提到 5，检索 F1 涨 4 %，但用户满意度却降 1 %——说明生成侧被冗余信息干扰了。
到底该怎么量化“检索-生成”权重？是各打 50 分，还是让检索做“守门员”生成只做“翻译”？欢迎有经验的朋友一起聊聊。
把 RAG 当乐高，检索和生成就是两块积木，拼得松了掉链子，拼得紧了转不动。希望这份避坑笔记能帮你少熬几个通宵，让客服 Bot 不再“已读乱回”。祝各位上线不炸服，日志零告警。
