RAG教程里说的流程是：分块、嵌入、向量搜索、生成答案。看起来非常简单，按这个思路搭了一套系统，测试没问题就上线了。但是结果出了怪事，经常会随机的失败。
输入一样，但是输出却不一样，而且这不是偶发，是还有一定的规律，这是怎么回事呢？
本文将介绍RAG在真实场景下为什么会崩，底层到底有什么坑，以及最后需要如何修改。
🚨 现象：测试结果飘忽不定
一套端到端的PDF处理管道，专门针对表格密集型文档。比如：财报、研究论文等，这类文档的特点是关键信息都在结构化表格里，传统RAG基本处理不好。
我用20个测试用例进行测试就开始玄学了：
运行1 → 3个失败
运行2 → 2个失败
运行3 → 0个失败
运行4 → 1个失败
运行5 → 0个失败
代码都一样。但是调试的时候每次跑出来结果都不一样？
🕵️ 逐层排查
为了搞清楚到底哪个环节出了问题，我哦们把每一步的中间状态都dump出来看。
MongoDB：表格提取正常，数据干净，索引也没问题。
Qdrant：向量嵌入一致，分块存储正常，语义搜索返回的内容也是相关的。
LLM的上下文窗口：检查了好几遍，模型每次拿到的context都是对的。
那么问题就来了：既然上下文没错，为什么模型有时候答对，有时候胡说八道或者漏掉数据？
那么问题只能是管道本身没坏，问题出自LLM。
🔍 三个隐藏的坑
经过一天的排查，最后定位到是下面三个问题叠加在一起造成的。
1、LLM的非确定性
Ollama温度的默认值大概在0.8左右。也就是说，同样的prompt可能给出不同答案，同样的数据可能产生不同推理，同样的表格也可能被解读出不同结果。
这导致RAG表面上看是确定性的流程，但实际上根本不是。0.8的温度让边界case变得完全不可预测，所以这一个问题就解释了一半的"随机"失败。
2、重复的表格数据
PDF本身就会有一些问题，比如同一张表格：
在文档里可能同时存在另一种形态：
Table data: Phase Requirements 2024-01-15 Review docs […]
于是LLM同时看到两个版本：一个是结构清晰的表格，一个是被打散成文本块的乱码版本。相同数据、不同格式、互相矛盾。
模型根本分不清该信哪个，有时从正经表格里提取，有时从噪声文本里提取，有时两边混着来。这是另外一个间歇性bug来源。
3、Prompt模糊
最开始写的指令大概是这种风格：
"使用提供的表格。考虑所有行。"
对LLM来说这就是一个建议，碰到边界情况，模型会直接无视第一行、括号里的备注、文档标题、日期列，列表也经常给会你截断。
叙述性文本用这种模糊指令没太大问题，但结构化数据不行，模糊指令会产生很多的问题。
🛠️ 重构方案
问题定位清楚之后，解决思路就明确了。
1、锁死温度参数
引入固定的温度预设：
class QueryEngine:
TEMPERATURE_DETERMINISTIC = 0.0 # default
temperature设成0，相同查询就能得到相同输出，测试也变得可以可复现，并且随机性也消失，系统立刻稳定下来。
2、过滤重复的表格分块
使用一套启发式规则来识别和剔除那些"看起来像表格"的文本块：检测"Table data:"前缀、统计YYYY-MM-DD日期模式出现次数、货币格式密度、文本和数字交替出现的模式、异常的空白字符分布。
在embedding之前把这些重复的表格噪声干掉，LLM就只能看到每张表格的唯一正确版本。
3、把Prompt写成硬性规则
重写了整个提示词，从"建议"改成"命令"：
文档标题必须纳入考虑（包含时间上下文）；每张表格的每一行都要读完；被问到提取数据时必须给出全部值；列表项不许跳过；括号里的备注（比如"(extended)"）必须保留。
这样表格读取错误就没有了
💡 最终架构：混合RAG
稳定之后的摄取和查询流程长这样：
详细摄取流程如下：
为什么要混合存储？表格数据需要SQL那种精确匹配能力，文本内容需要语义相似度搜索，两者结合才能把召回率拉到接近完美。
改完之后：
运行1: 20/20
运行2: 20/20
运行3: 20/20
稳定、确定、可上线。
🎯 总结
如果真要给实际业务文档做RAG不是那种demo用的博客文章，基本都会碰上这些问题：表格和文本混在一起、格式乱七八糟、LLM输出不稳定、提取结果模棱两可、检索匹配不准等等。
但这些都是工程问题，都有工程解法。确定性的LLM配置、靠谱的预处理流程、混合检索架构，三件套配齐，RAG系统就能做到稳定、准确、可以扔到生产环境里跑。
https://avoid.overfit.cn/post/c7aab3faef8948b29d54c0068a43abd6
作者：Islam Taha
