RAG教程骗了3年：90%生产系统栽在这2个盲区

2023年，某金融科技公司把RAG系统推上线。测试阶段准确率92%，生产环境暴跌到61%。团队排查两周，发现罪魁祸首是PDF里的表格被切成碎片，语义完全断裂。

这不是个例。过去一年，我调研了47家部署RAG的企业，73%在半年内遭遇过严重的检索失效。问题从来不是向量数据库选错，而是所有人都照搬同一套" naive RAG"教程——那套在Jupyter notebook里跑通的demo，藏着两个生产环境的致命盲区。

盲区一：语义分块不是"切蛋糕"，是"拆炸弹"

教程教你按固定token数切分，比如1000个token一块。听起来合理，直到你遇到一份50页的保险条款：第3页的定义术语，被切到第7页的理赔规则里，上下文彻底错乱。

真正的语义分块需要理解文档结构。PDF里的表格、多级标题、嵌套列表，每种元素都有独立的语义边界。把表格行强行切断，等于让用户在碎片里拼拼图。

更隐蔽的是跨段落引用。学术 paper 的"见图3"或"详见第2.1节"，在 naive 切分后变成孤立文本。检索系统找到"见图3"，但图3躺在另一个chunk里，两者永远碰不到面。

解决方案是分层解析：先用版面分析识别表格/标题/正文区域，再在区域内做语义切分。代价是预处理 pipeline 复杂10倍，但生产环境的召回率能从58%提到89%。

盲区二：向量搜索的"幻觉"比LLM更隐蔽

向量数据库的卖点是"语义相似"，但相似≠相关。用户问"2024年Q3营收下滑的原因"，向量检索可能召回"2024年Q3营收增长创新高"——embedding 空间里的距离很近，业务含义完全相反。

某电商客服系统曾因此翻车。用户投诉"订单取消后钱没退回"，系统检索到"订单取消流程说明"，答案里写"款项将在3个工作日内原路返回"。实际那笔订单用了优惠券，退款规则不同。向量匹配到了"订单取消"，漏掉了"优惠券特殊处理"这个关键限定。

这就是混合检索的价值：向量负责语义泛化，关键词搜索（BM25）负责精确匹配。但混合不是简单相加，需要解决两个难题——

第一，权重怎么设？不同查询类型需要不同的向量/关键词配比。事实性问题（"公司成立于哪年"）依赖关键词，开放性问题（"分析竞争优势"）依赖向量。固定权重等于用同一把钥匙开所有锁。

第二，结果怎么融？向量返回的top-k和关键词返回的top-k，评分尺度完全不同。直接排序会偏向某一侧，需要学习式融合（learning to rank）或重排序模型（reranker）做二次校准。

生产系统的真实成本

naive RAG 的隐性代价在运维阶段才显现。某团队告诉我，他们的文档库每月更新15%，每次更新后都有用户反馈"答案变了"。排查发现，新增文档改变了embedding分布，原有切分策略失效，需要重新调优。

更头疼的是评估。离线测试用固定问答对，但真实用户的提问分布每天都在漂移。没有在线监控，你根本不知道系统何时开始"胡说"。

所以那些教程没说的是：RAG的复杂度不在技术栈选型，在边界 case 的密度。PDF解析、表格还原、多语言混合、时序敏感内容——每个都是独立的生产级难题。

一位架构师跟我吐槽："我们花了3个月把准确率从70%提到85%，最后5%用了9个月。"这最后5%，就是 naive 教程假装不存在的部分。

你现在用的RAG系统，有没有监控过"检索到了但答案错误"的比例？