企业级RAG实战：教程不会告诉你的坑
持续交付20约 6 分钟1 写在前面
本文算是做企业级 AI 项目的总结。主要讨论的内容业自一个受监管行业的中型企业（1000 人规模）。
这个 RAG 系统，说实话，比任何网上的教程都要复杂得多。
今天和大家分享的是一些真正重要的经验，而不是那些基础教程里的内容。
2 现实情况：你的数据并不完美
快速背景：
这类规模的公司通常有 1 万到 5 万份文档，被困在 SharePoint 或 2005 年的老系统里。不是干净的数据集，也不是精心整理的知识库——而是几十年的业务文档，你得想办法让它们变得可检索。
文档质量检测：没人认真谈过的关键点
这对我们来说是最大的启发。大多数教程默认你的 PDF 都完美无缺。现实是：企业文档乱得一塌糊涂。
有个制药客户，资料里有 1995 年的研究论文，是打字稿的扫描件。OCR 几乎不起作用。同时还混着现代的临床试验报告，动辄 500+ 页，里面还有嵌入的表格和图表。
试试对这两类文档套同一种分块策略，然后看着你的系统输出一堆完全不靠谱的结果吧。
花了好几个星期排查：“为什么某些文档的结果糟糕透顶，而另一些却还不错？”。
最后意识到：在处理之前必须给文档做质量评分。
我们的解决方案：
- 干净的 PDF
（文本提取效果完美）：走完整的分层处理流程 - 还行的文档
（有一些 OCR 伪影）：基础分块并做清理 - 很差的文档
（扫描的手写笔记）：简单固定长度分块 + 标记人工复核
我们做了一个简单的评分系统，关注文本提取质量、OCR 伪影、格式一致性。根据得分把文档路由到不同的处理管线。仅此一项改动，修复的检索问题就比我更换任意一个更强的嵌入模型要多。
3 为什么固定大小分块大多是错的
每个教程都说：『统一切成 512 tokens，再加重叠！』
现实：文档是有结构的。研究论文的方法部分和结论部分完全不同。财报有执行摘要，也有详细表格。如果你无视结构，就会得到在句子中途被切断、或把不相关概念混在一起的分块。
我们不得不构建能保留文档结构的分层分块：
- 文档层
（标题、作者、日期、类型） - 章节层
（摘要、方法、结果） - 段落层
（ 200-400tokens） - 句子层
（用于精确查询）
关键洞察：查询的复杂度应该决定检索层级。宽泛的问题停留在段落层。像『表 3 的确切剂量是多少？』这样的精确问题，需要句子级的精度。
我们使用简单的关键词触发——比如『exact（确切）』，『specific（具体）』，『table（表）』会触发精确模式。如果置信度低，系统会自动向更精细的分块下钻。
4 元数据架构：比你的嵌入模型更重要
我们在这里花了大约 40% 的开发时间，ROI 也是所有工作里最高的。
大多数人把元数据当成事后才考虑。但企业查询的上下文非常强。一个制药研究人员问『儿科研究』，和另一个人问『成年人群』，所需文档完全不同。
我们为不同领域构建了特定的元数据模式：
针对制药文档：
文档类型（研究论文、监管文件、临床试验） 药物分类 患者人群（儿科、成人、老年） 监管类别（ FDA、EMA）治疗领域（心血管、肿瘤）
针对金融文档：
时间区间（ 2023年Q1、2022财年）财务指标（营收、 EBITDA）业务板块 地理区域
重要提醒：不要用大模型来抽取元数据——它们的稳定性实在不行。
简单的关键词匹配往往更靠谱。
查询里包含『FDA』？就筛 regulatory_category: 『FDA』。
提到『pediatric（儿科）』？就应用患者人群过滤。
每个领域先从 100-200 个核心术语起步，再根据匹配不佳的查询逐步扩展。领域专家通常也乐于帮忙构建这些词表。
5 当语义搜索失效时（剧透：经常发生）
纯语义搜索的失败率远比人们承认的要高。在像制药、法律这样的专业领域，我们看到的失败率是 15-20%，而不是大家想象的 5%。
几个让我们抓狂的主要失败模式：
缩写歧义：『
CAR』在肿瘤学里指『嵌合抗原受体』，但在影像论文里可能是『计算机辅助放射学』。相同的嵌入，完全不同的含义。精确技术查询：有人问『表
3的确切剂量是多少？』语义搜索能找到概念上相近的内容，但错过了具体的表格引用。跨文献引用链：文档彼此之间经常互相引用。药物
A的研究引用药物B的相互作用数据。语义搜索完全捕捉不到这些关系网络。
解决思路：构建混合方案。在处理阶段建立图谱层，跟踪文档间的关系。在语义搜索之后，系统检查检索到的文档是否存在相关文档，且后者可能有更好的答案。
6 为什么我们选择开源模型（尤其是 Qwen）
很多人以为 GPT-4o 或 o3-mini 永远更好。但企业客户有各种奇怪的约束：
- 成本
：当你有 5万+ 文档、每天上千次查询时，API成本会爆炸 - 数据主权
：制药和金融行业不能把敏感数据发到外部 API - 领域术语
：通用模型对没训练过的专业术语更容易胡说八道
Qwen QWQ-32B 在做了领域微调后，表现出乎意料地好：
比 GPT-4o在高吞吐处理下便宜85%一切都留在客户自有基础设施内 可以针对医疗/金融术语做微调 响应时间稳定，没有 API限流
微调方法也很直接——用领域问答对做监督训练。比如构造『药物 X 的禁忌症有哪些？』并配上 FDA 指南的真实答案。基础的监督微调比像 RAFT 这种复杂方法更好用。关键在于训练数据要干净。
7 表格处理：隐藏的噩梦
企业文档里充满了复杂表格——财务模型、临床试验数据、合规矩阵。标准的 RAG 要么忽略表格，要么把表格抽成非结构化文本，从而丢失所有关系。
表格里往往包含最关键的信息。金融分析师需要特定季度的精确数字。研究人员需要临床表中的给药信息。如果你搞不定表格数据，其实错过了企业价值的一半。
我们的做法：
把表格作为独立实体，设计专门的处理管线 用启发式方法做表格检测（空白布局模式、网格结构） 简单表格：转成 CSV；复杂表格：在元数据里保留层级关系双重嵌入策略：既对结构化数据做嵌入，也对语义描述做嵌入
8 真正重要的关键经验
文档质量检测优先。 不能用同一种方式处理所有企业文档。质量评估要走在任何处理之前。
元数据先于嵌入。 糟糕的元数据会导致糟糕的检索，不管你的向量多好。务必投入时间做领域特定的元数据架构。
必须采用混合检索。 在专业领域里，纯语义搜索失败太频繁。需要规则回退和文档关系映射。
表格至关重要 如果你不能正确处理表格数据，就会错失企业价值的大块。
9 写在最后
企业级 RAG 更像是工程问题而不是纯机器学习问题。大多数失败不是模型不行，而是低估了文档处理挑战、元数据复杂度，以及生产基础设施要求。
现在的需求真的非常旺盛。只要有大量文档库的公司都需要这些系统，但多数人并不了解在真实世界的文档里会多么复杂。
总之，这东西比教程看起来难多了。企业文档里的各种边角案例会把你折腾到怀疑人生。但一旦跑顺，ROI 非常可观——我们见过团队把文档检索时间从几个小时降到几分钟。
如果你在实现中也遇到类似的墙，欢迎来交流提问。我们一起把这件事做得更好！
材料来源：https://www.reddit.com/r/AI_Agents/comments/1nbrm95/building_rag_systems_at_enterprise_scale_20k_docs/