企业级RAG实战：教程不会告诉你的坑

本文算是做企业级 AI 项目的总结。主要讨论的内容业自一个受监管行业的中型企业（1000 人规模）。

这个 RAG 系统，说实话，比任何网上的教程都要复杂得多。

今天和大家分享的是一些真正重要的经验，而不是那些基础教程里的内容。

不完美的现实

2 现实情况：你的数据并不完美

快速背景：

这类规模的公司通常有 1 万到 5 万份文档，被困在 SharePoint 或 2005 年的老系统里。不是干净的数据集，也不是精心整理的知识库——而是几十年的业务文档，你得想办法让它们变得可检索。

文档质量检测：没人认真谈过的关键点

这对我们来说是最大的启发。大多数教程默认你的 PDF 都完美无缺。现实是：企业文档乱得一塌糊涂。

标准vs现实

有个制药客户，资料里有 1995 年的研究论文，是打字稿的扫描件。OCR 几乎不起作用。同时还混着现代的临床试验报告，动辄 500+ 页，里面还有嵌入的表格和图表。

试试对这两类文档套同一种分块策略，然后看着你的系统输出一堆完全不靠谱的结果吧。

花了好几个星期排查：“为什么某些文档的结果糟糕透顶，而另一些却还不错？”。

最后意识到：在处理之前必须给文档做质量评分。

我们的解决方案：

三种分类

• 干净的 PDF（文本提取效果完美）：走完整的分层处理流程
• 还行的文档（有一些 OCR 伪影）：基础分块并做清理
• 很差的文档（扫描的手写笔记）：简单固定长度分块 + 标记人工复核

我们做了一个简单的评分系统，关注文本提取质量、OCR 伪影、格式一致性。根据得分把文档路由到不同的处理管线。仅此一项改动，修复的检索问题就比我更换任意一个更强的嵌入模型要多。

3 为什么固定大小分块大多是错的

每个教程都说：『统一切成 512 tokens，再加重叠！』

现实：文档是有结构的。研究论文的方法部分和结论部分完全不同。财报有执行摘要，也有详细表格。如果你无视结构，就会得到在句子中途被切断、或把不相关概念混在一起的分块。

文档分块

我们不得不构建能保留文档结构的分层分块：

• 文档层（标题、作者、日期、类型）
• 章节层（摘要、方法、结果）
• 段落层（200-400 tokens）
• 句子层（用于精确查询）

关键洞察：查询的复杂度应该决定检索层级。宽泛的问题停留在段落层。像『表 3 的确切剂量是多少？』这样的精确问题，需要句子级的精度。

我们使用简单的关键词触发——比如『exact（确切）』，『specific（具体）』，『table（表）』会触发精确模式。如果置信度低，系统会自动向更精细的分块下钻。

4 元数据架构：比你的嵌入模型更重要

我们在这里花了大约 40% 的开发时间，ROI 也是所有工作里最高的。

元数据更重要

大多数人把元数据当成事后才考虑。但企业查询的上下文非常强。一个制药研究人员问『儿科研究』，和另一个人问『成年人群』，所需文档完全不同。

我们为不同领域构建了特定的元数据模式：

针对制药文档：

• 文档类型（研究论文、监管文件、临床试验）
• 药物分类
• 患者人群（儿科、成人、老年）
• 监管类别（FDA、EMA）
• 治疗领域（心血管、肿瘤）

针对金融文档：

• 时间区间（2023 年 Q1、2022 财年）
• 财务指标（营收、EBITDA）
• 业务板块
• 地理区域

重要提醒：不要用大模型来抽取元数据——它们的稳定性实在不行。

简单的关键词匹配往往更靠谱。

查询里包含『FDA』？就筛 regulatory_category: 『FDA』。

提到『pediatric（儿科）』？就应用患者人群过滤。

每个领域先从 100-200 个核心术语起步，再根据匹配不佳的查询逐步扩展。领域专家通常也乐于帮忙构建这些词表。

5 当语义搜索失效时（剧透：经常发生）

纯语义搜索的失败率远比人们承认的要高。在像制药、法律这样的专业领域，我们看到的失败率是 15-20%，而不是大家想象的 5%。

几个让我们抓狂的主要失败模式：

1. 缩写歧义：『CAR』在肿瘤学里指『嵌合抗原受体』，但在影像论文里可能是『计算机辅助放射学』。相同的嵌入，完全不同的含义。
2. 精确技术查询：有人问『表 3 的确切剂量是多少？』语义搜索能找到概念上相近的内容，但错过了具体的表格引用。
3. 跨文献引用链：文档彼此之间经常互相引用。药物 A 的研究引用药物 B 的相互作用数据。语义搜索完全捕捉不到这些关系网络。

混合检索

解决思路：构建混合方案。在处理阶段建立图谱层，跟踪文档间的关系。在语义搜索之后，系统检查检索到的文档是否存在相关文档，且后者可能有更好的答案。

6 为什么我们选择开源模型（尤其是 Qwen）

很多人以为 GPT-4o 或 o3-mini 永远更好。但企业客户有各种奇怪的约束：

• 成本：当你有 5 万+ 文档、每天上千次查询时，API 成本会爆炸
• 数据主权：制药和金融行业不能把敏感数据发到外部 API
• 领域术语：通用模型对没训练过的专业术语更容易胡说八道

Qwen QWQ-32B 在做了领域微调后，表现出乎意料地好：

• 比 GPT-4o 在高吞吐处理下便宜 85%
• 一切都留在客户自有基础设施内
• 可以针对医疗/金融术语做微调
• 响应时间稳定，没有 API 限流

qwen3

微调方法也很直接——用领域问答对做监督训练。比如构造『药物 X 的禁忌症有哪些？』并配上 FDA 指南的真实答案。基础的监督微调比像 RAFT 这种复杂方法更好用。关键在于训练数据要干净。

7 表格处理：隐藏的噩梦

企业文档里充满了复杂表格——财务模型、临床试验数据、合规矩阵。标准的 RAG 要么忽略表格，要么把表格抽成非结构化文本，从而丢失所有关系。

表格里往往包含最关键的信息。金融分析师需要特定季度的精确数字。研究人员需要临床表中的给药信息。如果你搞不定表格数据，其实错过了企业价值的一半。

table is hiden

我们的做法：

• 把表格作为独立实体，设计专门的处理管线
• 用启发式方法做表格检测（空白布局模式、网格结构）
• 简单表格：转成 CSV；复杂表格：在元数据里保留层级关系
• 双重嵌入策略：既对结构化数据做嵌入，也对语义描述做嵌入

8 真正重要的关键经验

1. 文档质量检测优先。 不能用同一种方式处理所有企业文档。质量评估要走在任何处理之前。
2. 元数据先于嵌入。 糟糕的元数据会导致糟糕的检索，不管你的向量多好。务必投入时间做领域特定的元数据架构。
3. 必须采用混合检索。 在专业领域里，纯语义搜索失败太频繁。需要规则回退和文档关系映射。
4. 表格至关重要 如果你不能正确处理表格数据，就会错失企业价值的大块。

经验要点

9 写在最后

企业级 RAG 更像是工程问题而不是纯机器学习问题。大多数失败不是模型不行，而是低估了文档处理挑战、元数据复杂度，以及生产基础设施要求。

现在的需求真的非常旺盛。只要有大量文档库的公司都需要这些系统，但多数人并不了解在真实世界的文档里会多么复杂。

总之，这东西比教程看起来难多了。企业文档里的各种边角案例会把你折腾到怀疑人生。但一旦跑顺，ROI 非常可观——我们见过团队把文档检索时间从几个小时降到几分钟。

如果你在实现中也遇到类似的墙，欢迎来交流提问。我们一起把这件事做得更好！