在多个企业级RAG项目中摸爬滚打一圈后，有个感触越来越深：真正的挑战从来不在模型本身，而是藏在文档处理、领域知识融合和系统稳定性这些“看不见”的地方。最近正好看到Reddit上有一篇帖子，总结了他们团队在10多个企业级RAG项目中积累的关键经验，其中不少观点和实战中的体会不谋而合。这里结合自己的理解做一次深度梳理，希望能给正在做或准备做企业级RAG的朋友一些启发。
文档质量：先分类，再处理
很多教程都假设PDF文本清晰、格式规范，但现实世界里的企业文档，情况要复杂得多。有来自上世纪九十年代的扫描件，OCR识别错误率很高；也有带着复杂图表和表格的现代报告，甚至混杂着潦草的手写体。如果所有文档都采用同一种处理方式，效果自然好不到哪去。
曾经花了很多时间排查为什么某些文档检索效果极差，后来才意识到问题源头：在做任何处理之前，必须先对文档的“质量”进行预判和分类。基于这个思路，可以设计一套简单的质量评估机制：
- 高质量PDF（文字提取准确）：应用更精细的解析策略，充分保留文档结构信息。
- 普通文档（存在少量OCR错误）：采用常规分块加文本清洗的方式处理。
- 低质量文档（扫描件、手写体等）：简单分块即可，并标记“需人工复核”，避免“垃圾进、垃圾出”。
仅仅做这样一个改动，带来的效果提升，往往比后续调整模型参数更显著。
分块策略：尊重文档本身的结构
常见的教程里动不动就说“切成512 token，加点重叠就行”。但企业文档是有内在结构的——研究论文有摘要、方法、结果、讨论，财务报告有利润表、资产负债表，合规文件有条款、附件、附录。机械地按固定长度切分，很容易切断句子、把不同主题的内容混在一起，检索效果自然大打折扣。
更有效的做法是采用层次化分块策略，尊重文档原有的章节逻辑：
- 文档级：标题、作者、日期、类型等全局信息。
- 章节级：摘要、方法、结果、讨论等不同章节。
- 段落级：200–400 token 左右的粒度。
- 句子级：用于应对高精度问答场景。
还有一个实用技巧：根据查询语句的复杂度动态选择检索层级。像“请总结一下这份报告”这样的宽泛提问，用段落级就够了；而“表3中第二行的具体数值是多少”，则需要定位到句子甚至表格内部。可以通过检测查询中的关键词（如“具体”、“精确”、“表X”等）来自动切换检索模式。
元数据设计：花多少时间都不为过
如果说从这些项目中学到了什么最重要的事，那就是：没有好的元数据，再强的模型也发挥不出价值。企业查询往往带有强烈的场景属性。比如“儿科研究”和“老年用药”涉及的文件类型、监管要求、药物分类完全不同。如果检索时没有元数据做前置过滤，模型只能在所有文档里大海捞针。
因此，需要花大量时间和客户一起设计定制化的元数据体系。以两个典型场景为例：
- 制药场景：文档类型、药物分类、人群年龄段、监管机构、治疗领域……
- 金融场景：时间周期、财务指标（收入、利润等）、业务线、地区……
一个小建议：元数据提取尽量别完全依赖大模型，效果不稳定且不可控。很多时候，简单关键词匹配或者基于规则的提取方法反而更靠谱。比如查询中间出现“FDA”，就自动筛选 regulatory_category = "FDA" 的文档。
检索策略：纯语义搜索不是万能的
在专业化领域中，纯语义搜索的失败率比想象中要高，观察到的数据大约是15%–20%。问题主要集中在几个方面：
- 术语/缩写歧义：例如“CAR”在医学领域是嵌合抗原受体，在汽车行业就是汽车，截然不同。
- 精确查询失效：像“请找出Table 3中第二行的数据”，语义搜索往往会返回相似内容而非具体答案。
- 文档间引用丢失：很多文档需要互相参照信息才完整，但语义检索难以建立这种跨文档的关联。
针对这些问题，更稳妥的策略是“混合检索”：建一个图结构来维护文档间的关系；在语义检索后，追加一次关联文档的检索；建立专业术语词典配合规则来化解歧义；对关键数据查询，走专用的检索通道。
模型选型：开源模型正在成为主流选择
虽然GPT-4这样的API模型效果确实出色，但企业级项目有很多现实约束：文档量大了之后，API调用费用相当可观；金融、医疗等行业对数据合规的要求极为严格，不允许数据出境；通用模型在专业术语上容易出现“幻觉”或错误。
实践中，像Qwen-32B这类经过领域微调的开源模型，表现相当不错。成本大约是GPT-4的五分之一，支持本地部署满足合规要求，而且可以针对专业术语做定向优化，响应稳定，不受外部限流影响。微调方法其实不复杂：关键是准备高质量的领域问答对做有监督微调，保证训练数据干净、匹配真实场景。
表格处理：绕不开的核心难点
企业文档里充斥着大量表格：财务报表、临床试验数据、合规条款对照表……传统RAG要么直接跳过表格，要么把它们转成纯文本，丢失了所有结构信息。而这部分内容，往往又是文档中价值最高的核心信息。
现在更有效的处理方式是：独立检测和提取表格，按复杂度分级处理——简单表格转CSV，复杂表格保留层次结构；为表格内容单独建立检索索引，同时支持“语义查询”和“精确定位”。
工程能力：决定项目成败的“隐形”要素
模型算法固然重要，但真正决定项目能不能在生产环境跑起来的，往往是工程实现。比如并发请求的管理、GPU内存与推理效率的平衡、系统稳定性和响应延迟。很多客户本身就有现成的GPU资源，本地化部署反而比用云方案更顺畅。
通常会部署2–3个模型分别处理生成、嵌入和元数据提取，并通过量化、批处理等方式优化资源使用。工程稳定性是那个最容易被忽略、但又最致命的问题。
干货总结与企业实践建议
综合来看，企业级RAG的真正难点，大多不在模型本身，而在于文档预处理、领域知识融入和系统稳定性保障。以下几个要点，是从多个项目中提炼出来的最核心经验：
- 先做文档质量分级，再设计处理流程——这是最基础、也最容易见效的一步。
- 元数据设计 > 模型选型——没有好的元数据，检索的起点就偏了。
- 混合检索 > 纯语义检索——尤其是在专业领域，不能指望语义搜索解决所有问题。
- 必须处理好表格——这是企业文档中信息密度最高、也最难处理的部分。
- 工程稳定性决定项目成败——算法再强，线上跑不起来也是白搭。
虽然过程中会遇到无数意想不到的坑，但一旦系统真正跑通，带来的效率提升是巨大的——从“反复翻文档”变成“一键获取答案”，对专业团队来说，价值非常可观。