你的RAG Demo跑得飞起，上线后用户说"还不如百度"
这是RAG项目最常见的悲剧模式：Demo阶段，10个测试问题回答得完美。上线后，用户的第一批100个问题中，30个答案不对，20个"不知道"，10个是幻觉。
从Demo到生产，RAG系统需要跨越10个坑。以下是完整清单。
坑一：Demo数据 vs 生产数据
你的Demo用了100篇精心挑选的文档，检索效果完美。但生产环境有50万篇文档，质量参差不齐——有乱码的PDF、有扫描版的合同、有大量重复内容。
解决方案：在Demo阶段就用"脏数据"测试。如果生产的文档质量差，测试时就用差的数据。
金句：Demo用的是"干净数据"，生产是"脏数据"。用干净数据测出来的效果，在脏数据上打对折。
坑二：Chunking一刀切
50万篇文档，有PDF、Word、HTML、Markdown、代码文件。你用了统一的chunk_size=500。结果：代码文件被切成碎片，PDF表格被拦腰截断，HTML的标签被保留在chunk中。
解决方案：按文档类型分别处理。PDF用LlamaParse，代码文件用语言感知的切分，HTML先提取纯文本。
坑三：Embedding模型不匹配
你用了OpenAI的Embedding模型，但向量数据库配的是欧氏距离。或者你升级了Embedding模型，但旧数据没有重新Embedding。
解决方案：在数据Pipeline中校验Embedding维度和相似度度量。升级Embedding模型时，全量重建索引。
金句：Embedding模型和向量数据库的"匹配"是RAG系统最基础的工程问题。不匹配=检索不到。
坑四：没有Fallback机制
用户问了一个知识库中不存在的问题，RAG检索到一堆"不相关"的文档，LLM基于这些文档生成了一段"一本正经的胡说八道"。
解决方案：设置相似度阈值。如果检索结果的最高相似度低于阈值（如0.65），直接回答"我不知道"，而不是强行生成答案。
金句：RAG系统最危险的输出不是"不知道"，而是"不知道但假装知道"。
坑五：Token消耗失控
你的Prompt模板是：System Prompt（500 tokens）+ 检索上下文（5x1000 tokens）+ 对话历史（2000 tokens）+ 用户问题（100 tokens）= 7,600 tokens。每次查询消耗$0.04。
一天10万次查询，月成本$12,000。你以为是"技术问题"，其实是"成本问题"。
金句：RAG系统的Token消耗不是"技术优化"，而是"成本优化"。每个Token都在烧钱。
坑六：检索结果没有排序
向量检索返回的Top-5结果，第1名和第5名的相关度可能差很多。你直接把5个结果塞给LLM，LLM被"不太相关"的文档干扰，生成的答案质量下降。
解决方案：加入Reranker。不是所有检索结果都值得送给LLM。
坑七：增量更新缺失
知识库每周更新，但你的RAG系统是"全量重建"——每次更新都删除所有旧数据，重新导入。更新期间系统不可用，而且每次全量重建的Embedding费用是$6,500。
差点被砍掉：某公司因为每次更新都要花$6,500+停机4小时，业务方要求砍掉RAG项目。
解决方案：设计增量更新Pipeline。新增文档→Embedding→Insert。修改文档→更新。删除文档→按ID删除。
金句：RAG系统的更新策略，决定了它能活多久。全量重建=自杀。
坑八：没有监控和质量评估
上线后就不管了。3个月后，用户反馈答案质量下降。排查发现：新数据的向量分布偏移，索引参数不再适用。
解决方案：建立持续的质量监控体系。RAGAS自动评估+关键指标监控+告警。
坑九：多语言混用
知识库中中英文混用，你用了一个中文Embedding模型。英文文档的检索效果极差。
解决方案：用多语言Embedding模型（如BGE-M3、text-embedding-3-large），或者在检索前做语言检测和路由。
坑十：安全漏洞
没有做Prompt注入防护。攻击者可以：
- 注入恶意指令让RAG忽略安全规则
- 通过精心设计的查询提取其他用户的敏感信息
- 在检索的文档中嵌入恶意内容
金句：RAG系统的安全漏洞，不是"有没有"，而是"什么时候被发现"。**