chunk_size 调了二十轮，检索准确率还在 40% 到 55% 之间晃；换了更大的 embedding、加了 rerank、改了混合检索，准确率曲线依旧纹丝不动。如果你的 RAG 知识库正卡在这种状态，先停下手里的检索层调参——问题很可能在文档入库的那一刻就已经定下来了。
这两天我把全网最近的 RAG 落地讨论翻了一遍，知乎、小红书、36氪上多个上线后被骂过的团队，正在形成同一个结论：检索质量的天花板，由文档预处理决定，下游所有的 embedding、向量检索、rerank 都只能逼近这个天花板，突破不了。知乎
你的文档，入库时就"半身不遂"了
一位做了两年多电力行业 AI 落地的工程师在知乎写了他的踩坑记录：系统刚上线时，搜"变压器瓦斯保护动作处理"，返回的是"日常巡检注意事项"。知乎他第一反应是 chunk_size 不对：改 256，一段完整的操作步骤被切成碎片，搜到一半上下文没了；改 1024，无关条款全被带进来。来来回回调了一个星期，准确率就在 40% 到 55% 之间晃。
后来他把切分逻辑改成按条款编号切、同一条款内容放一个 chunk、不管长短，检索准确率直接从 40% 跳到 70% 多。LangChain 们默认的按字数递归切分，对文档结构是没有概念的——一条规程前半段在 chunk A、后半段在 chunk B，向量检索两条都命中但都不完整，rerank 也救不回来。
除了结构切断，还有两类典型"垃圾"：一是表格被扁平化，参数表、报价单被提取成一串连续字符串，行列边界消失，模型根本不知道这是一张表，条件查询必错；二是页眉页脚页码混进向量，高频噪声反复占用检索位。做企业知识库项目的小红书作者把这种状态总结成一句话：解析成功和解析能用，是两码事。小红书文件从 38 份涨到 300 份之后，谁检查、谁整改、谁验收，往往就成了没人说的清楚的灰色地带。
三个数字，看清力气该往哪使
把多个团队公开的实测数据摆在一起，有三个数字值得贴在工位上。
85%→62%：上面那支电力团队自己跑 benchmark 准确率 85%，看着挺美；后来拉了两个老值班员，每人花一周，对着 300 个真实问题逐条标"对不对、够不够、有没有遗漏"，标完发现真实问题集上只有 62%。知乎那 23 个点的差距，全藏在用户提问不规范、多文档冲突、上下文缺失这些地方——没有一个是靠调检索参数能补上的。
3%→放大：扫描版 PDF 过 OCR，识别率 97%，听着挺高，但就是那 3% 的错误，在分块之后被放大——一个术语识别错，整段 chunk 的向量就和正确表达对不上。知乎垃圾进垃圾出，在 RAG 里是真理。
所以投入优先级很清楚：先数据质量，再切分策略，最后才轮到检索层参数。
一份马上能动手的清单
综合多个团队公开的实现经验，按性价比排序：
先抽查 chunk：从向量库里随机抽 50 条，肉眼读一遍。看到切断的条款、页眉套话、散架的表格，问题就坐实了，不用再怀疑模型。
结构化文档换结构切分：规程、手册、合同类按条款号或章节切，一条一款一个 chunk；通用文档用递归切分 512 起步。
清洗页眉页脚：别靠关键词黑名单，用页面 Y 轴坐标定顶底固定区间，再统计每页高频重复短文本，动态建噪声黑名单。
表格还原成 Markdown：保留行列语义，参数表、报价单、指标对照表这一步收益最大。
扫描件先过 OCR 预处理：关键文档必须人工校对一遍。
以上都做完，再考虑换 embedding 模型。
切分参数上，多条一线团队的工程经验收敛到同一个区间：中文场景 overlap 设置为 chunk_size 的 10%～25%，简短知识点文档取下限，长篇连贯技术文档取上限。知乎embedding 模型则在显存允许时尽量选大的——有团队实测从 BGE-M3（1024 维，中文 MTEB 得分 59.56）换到 Qwen3-Embedding-4B（2560 维，MTEB 69.45），检索命中率的提升比调任何一轮 chunk_size 都大，但代价是显存占用翻约六倍，且 pgvector 的 HNSW 索引维度上限 2000，2560 维得用 halfvec 半精度压缩，INT4 量化则会让召回掉 1-3%，生产环境不建议。知乎
两盆冷水
第一盆：别过度工程。知识库只有几十份文档、结构本身干净、问题多是简单事实查询的话，做一天数据清洗就够了，不必上完整的 ETL 流水线。预处理投入的价值和文档量、结构复杂度成正比——这是知识库从 38 份涨到 300 份的团队用灰色地带换来的教训。
第二盆：数据质量上去之后，还会浮出两个新问题——文档版本冲突和评估。规程 A 说跳闸后 15 分钟内汇报，规程 B 说立即处置并汇报，两条都检索到了、都相关、都正确，模型听谁的？这类问题靠技术解决不了，只能一条一条梳理优先级表，跟着版本更新维护。评估更是如此：别迷信合成 benchmark，先找真实终端用户，收集 100 个他们真实会问的问题，用这 100 个问题测你的系统。知乎
2026 年的 RAG 已经不算新词，但"能用"和"demo 能跑"之间的差距，比很多人大想象的要大。这个差距大多不在模型选型，而在那步不起眼的文档预处理。如果你正卡着，不妨先花一个下午，把库里的 chunk 抽出来肉眼读一遍——答案大概率就写在那里。
