AI知识库落地前的关键一步：源文件治理与RAG实践

接手这个项目的第一天，我面对的是服务器里将近一万个源文件。有专利文档、研发报告、设计方案、图纸扫描件、技术标准，还有各个部门七零八落导出的一堆PDF和Word，文件命名从“最终版”到“最终版2”再到“打死不改版”，乱到让人血压升高。项目目标很清晰，把这批源文件做成企业内部的AI知识底座，支持技术问答、专利检索、辅助研发决策这类场景。

但在把这些源文件喂给AI之前，我先做了一件事：对整个文件资产做了一次系统性的分类、清洗和索引构建。

这件事做完之后，后面的AI应用开发、知识库搭建、检索增强生成才真正跑得通。如果跳过这一步，直接把这些乱七八糟的文件灌给大模型，得到的答案质量会让你怀疑人生。

1. 为什么“喂文件”之前必须先做治理

1.1 项目背景：AI不能替你解决混乱

先说需求。公司要做的是一个面向研发团队的知识问答系统，底层是国产大模型加RAG架构。系统要能回答“某某技术方案之前在哪个项目里用过”“哪个专利覆盖了这个技术点”“某型号设备的维护规范是什么”这类问题。数据源就是那将近一万个源文件。

很多人有个误区，觉得大模型很强大，把文件一股脑丢进去就能自动理解。但实际跑过一遍就会明白，RAG系统的效果上限不是模型决定的，而是你喂进去的语料质量决定的。模型再聪明，从一段带满页眉页脚、OCR错别字、乱码、重复文件的垃圾内容里也检索不出正确答案。

我做过对比测试，同一批原始文件直接建索引，和经过治理后再建索引，回答的准确率差距非常大。混乱的源文件里，光是把同一个文件的不同版本都当成独立文档这一点，就足够让检索结果劣化到没法用。

1.2 第一课：AI只会读结构，不会替你理结构

大模型理解文本靠的是语义关联，但并不具备真正的“全局整理”能力。你把一万个文件丢给它，它不会自动意识到“A文档和B文档其实是同一个专利的申请稿和授权稿”“C图纸扫描件里的表格需要OCR才能提取”“D标准文件是已经被废止的旧版本”。

这些判断需要人来做。

所以喂AI之前的那件事，本质上是把一批杂乱的数字资产，转化成一套有明确边界、有元数据、有质量控制的可用语料。这个活儿没有太多高深算法，靠的是工程化的耐心和一套清晰的分类逻辑。

1.3 面对近万个文件，目标是什么

我在项目启动时定了三个目标，后面所有工作都围绕这三个目标展开：

• 每个文件都能被唯一标识，知道它是什么、属于哪个业务域、版本状态如何。
• 每个文件的内容是可读、可检索、可切片的，没有乱码和明显的识别错误。
• 文件之间的关联关系被梳理出来，至少做到“同一主题找得到彼此”。

这个目标听起来朴素，但在几千个文件规模下，要实现它需要一套完整的处理流程。接下来我把这套流程拆开讲，每一步都有参数和实测数据，可以当作一份可直接参考的实操手册。

2. 源文件盘点：先摸清家底，再谈分类

2.1 别急着清洗，先做文件画像

任何治理工作的前提是知道你有什么。面对近万个源文件，第一步不是写清洗脚本，而是先做一次全面的文件盘点。

我用Python写了个脚本，对全部文件做了扫描，统计出这些核心指标：

• 文件总数与总大小
• 文件类型分布（PDF、Word、Excel、图片、CAD图纸等）
• 命名规范情况（包含特殊字符、重复名称、无意义名称的文件数量）
• 重复文件检测（通过MD5值）
• 目录层级情况（深度分布）

实测下来，这批文件的总量是9773个，压缩前约186GB，类型分布如下：

这个画像直接影响后续的技术选型。比如PDF占了将近六成，而且其中相当一部分是扫描件，那么OCR能力就必须做好；CAD文件本身不能被向量化直接读取，需要先转成图片或提取属性信息。

提示：先扫一遍再动手，能避免你对着错误的方向浪费时间。我见过不止一个人上来就写清洗脚本，结果清洗完才发现有两千个文件是重复的，前面全白干。

2.2 分类体系：三维度建立文件地图

盘点做完，要根据业务需求设计分类体系。我的做法是三维度分类法，可以理解为给每个文件打上三组标签，这样后续不管从哪个角度切入都能检索到。

第一个维度是“文件类型”，解决“这是什么格式”的问题。PDF、Word、Excel、图片各归其位，因为不同格式对应不同的解析方式。

第二个维度是“业务域”，解决“这个文件在讲什么领域的事”的问题。我按公司业务拆成了几个大类：专利与知识产权、产品设计方案、工艺制造规范、测试验证报告、设备维护资料、项目管理文档。

第三个维度是“状态属性”，解决“这份文件能不能用、是不是当前有效版本”的问题。状态属性包括：有效、已废止、历史存档、外部参考。这个维度特别关键，如果AI把一份已经废止的旧标准当成现行标准，检索出来的答案就是错误的。

2.3 文件命名与目录重构：让路径本身成为信息

原始文件命名简直是重灾区。统计下来，命名中包含“最终”“修改”“新建文档”等无效词根的文件有1743个，完全以“未命名”开头的有86个。

我定的新目录结构是三级：

code复制source/
  01_知识资产/
    搜索主题1. 专利文献/ (以专利公开号+标题命名)
    搜索主题2. 设计文档/ (项目号+文档类型+版本号)
    搜索主题3. 工艺规范/ (标准编号+标题+年份)
    ...

文件名也做了统一规范，格式是“日期_业务域_文档类型_标题_版本号”。例如一个专利文件会被改为“20180325_专利_实用新型_一种XX装置及其使用方法_V2.pdf”。这样做的意义在于，文件名本身就成了一条元数据，即使后续脱离数据库，单看路径也能快速判断文件归属。

注意：重构目录前一定要先保留一份原始文件的映射表，记录原路径和新路径的对应关系。否则后续追责或者回溯时找不到原始出处，会非常被动。我用CSV记录了全部映射，等于给这批文件上了一道保险。

3. 内容清洗与格式统一：决定AI理解质量的下限

3.1 清洗清单：页眉页脚、乱码、识别错误一起处理

文件层面梳理清楚之后，进入到内容清洗阶段。这个阶段的目标只有一个：让文本内容干净、完整、可被模型正确理解。

我整理了一份清洗清单，逐项执行：

• 去除PDF提取文本中残留的页眉、页脚、页码和水印字符。
• 统一换行符，把单个换行替换为空格，保留段落标记。
• 处理全角半角混用问题，统一为全角标点。
• 修复中文乱码，常见原因是编码混用。
• 对扫描件统一做OCR，把图像里的文字提取出来。
• 移除文件里的嵌入批注、修订痕迹（尤其是Word文件）。

其中OCR是重头戏。将近六成PDF里有很大比例是扫描件，文字是图片的一部分。我用的方案是PaddleOCR，在GPU环境下跑了大概四五个小时才处理完。识别效果整体不错，但仍有少量表格和数据区域识别错误，需要人工抽检修正。

抽检很重要。OCR识别出来的内容如果不抽检，一些数字错误会直接进入AI知识库，而且它不会像人一样觉得“这个数字看起来不对”，而是会一本正经地用错误数据给你生成答案。我采取的策略是按类型抽样5%，发现了三类典型问题：表格线导致的错位、多栏排版被合并、公式与下标识别混乱。

3.2 格式归一化的几个大坑

格式归一化是指把所有文件统一转换成处理链路中最适合的格式。我的做法是全部转换成UTF-8编码的Markdown或者纯文本，再进入切片和向量化环节。

坑一：Word .doc格式是二进制老格式，很多库处理不好。我处理批量doc文件时，用LibreOffice命令行先把所有老格式转换成docx，再用python-docx提取文本。整个转换用了近一个小时。

坑二：PDF提取文本时，有些矢量字体提取出来是乱码。这是因为字体内嵌了自定义编码。遇到这种情况，我锁定文件清单后强行走OCR流程，把它们当图像处理。虽然慢，但至少结果正确。

坑三：Excel文件直接转文本会丢失表格结构。我的处理是把每个Sheet转成CSV，再用分隔符保留行列关系。AI对CSV表格的理解比对纯文本好得多。

3.3 清洗脚本的核心逻辑

清洗环节我用Python写了一套批处理脚本，核心流程包括读取、清洗、输出三部分。

python复制import re

def clean_text(text: str) -> str:
    # 去掉页眉页脚（根据具体文档特征调整正则）
    text = re.sub(r'\n\s*第\s*\d+\s*页\s*(共\s*\d+\s*页)?\s*\n', '\n', text)
    # 移除常见水印字样
    text = re.sub(r'(机密|内部资料|仅供内部使用)', '', text)
    # 合并被硬换行的英文和中文段内文字
    text = re.sub(r'(?<=[^。！？.!?；;])[\r\n]+(?=[^。！？.!?；;])', '', text)
    # 统一空白字符
    text = re.sub(r'[ \t]+', ' ', text)
    text = text.strip()
    return text

脚本本身不复杂，难的是正则表达式的调优。不同来源的文档，页眉格式差别很大。我最终维护了一个规则库，按文档来源分批应用不同的清洗规则，而不是一刀切。

4. 切片、向量化与索引构建：把源文件转化为AI语料

4.1 切片策略：按语义边界而不是固定字数

清洗完成后，下一步就是把文本切成小块，供向量化和检索使用。切片是RAG系统中最容易踩坑的环节之一。

固定字数切片是很多教程里的做法，但实际效果并不好。文档里的语义单元通常是按标题、段落、表格来划分的，你硬性按512字或1024字切，经常会把一个完整的技术方案从中截断，导致后续检索时丢失上下文。

我用的策略是分层切片：

• 第一步，按Markdown标题结构切出章节块。
• 第二步，对超大章节，按段落再切分。
• 第三步，段落仍超长的，按句子边界补齐到设定长度。

切片长度的选择我做了实验对比。最大长度在800到1200字之间，重叠150字，整体效果最好。太小了语义不完整，太大了向量化后的检索精度会下降，因为一个向量要表达的内容过多，概念被稀释。

提示：重叠区间是必要的，确保切在中间的关键信息至少在一个切片里是完整的。150字是我实测下来的平衡点，重叠太少会让跨切片的信息断裂，太多又会让切片数量膨胀。

4.2 元数据注入：让每条切片都知道自己是谁

这一步我强调再多次都不为过。切片不能是孤零零的一段文字，它必须携带来源文件的元数据。

每条切片我会附加以下字段：

• 文档编号（对应梳理阶段的唯一ID）
• 文档标题
• 业务域
• 章节路径
• 文件版本状态
• 原始文件名和路径
• 页码或位置信息

这些元数据在检索增强阶段非常有用。当大模型生成回答时，我们可以把命中的切片元数据一起给到大模型，让它依据这些信息组织答案结构、注明出处。更重要的是，元数据可以用于权限过滤——例如维护文档不向研发人员开放，这靠的是切片级别的标签控制而非模型本身判断。

实测中我发现，有元数据标注的检索结果比裸文本切片的相关性明显更准。原因不难理解：当语义向量相似度相近时，业务域一致性成为很好的排重和排序信号。

4.3 向量化与知识图谱的初步关联

切片之后做向量化嵌入，我选的是bge-large-zh-v1.5模型，输出维度1024。近万个文件的切片总量是25800多条，全部向量化在单张A10显卡上跑了几十分钟。

向量化本身不是难点，难点在于检索维度之外的关联构建。我在梳理文件时发现，很多源文件之间天然存在关联关系，例如：

• 专利文件里引用了某个产品型号，恰好有另外一份测试报告是关于该型号的。
• 某个设计文档里提到了某条标准编号，该标准在另一份文件夹里。
• 图纸编号和物料清单存在对应关系。

我用正则表达式和实体抽取做了一个初步的关联规则引擎，在切片写入索引时同步记录这些关联关系。这相当于给系统增加了一个知识图谱的浅层版本。有了它，用户在问“某型号产品有哪些测试报告”时，系统可以通过产品型号这个实体直接关联到对应切片，而不只是依赖语义相似度。

这里我引入了图谱查询作为第一层召回，向量检索作为第二层精排，整体查询质量提升明显，尤其在涉及标准编号、项目号这种精确实体的业务场景。

5. 分批喂给AI的实践与踩坑记录

5.1 别一次性全量灌入：分批策略与Token预算

源文件治理完后，真正“喂给AI”也需要讲究策略。一次性把两万多条切片全部塞给模型，在上下文窗口有限的今天是不可行的，也会造成信息冗余。

我采用的是RAG（检索增强生成）模式：用户问题到达后，先从索引中检索出最相关的20到50条切片，再把这些切片拼接到Prompt里，连同问题一起发送给大模型生成最终回答。

针对批量语料入库（知识库建索引）的过程，我按业务域分批执行，每个批次在3000条左右切片。这样做的目的是方便排查。

在一次批次执行中，发现某个知识域相关的结果准确率特别低。单独拉出来排查，才发现是这个域里有一部分研发报告没有经过清洗就直接进入流程，里面充满了公式识别错误和表格乱码。所以说分批灌入相当于给你留了一扇观察的窗户。

5.2 Token预算的粗算方法

给文件进入大模型做批处理时，要知道工作量得先算清Token数。中文场景下，1个汉字大约对应1到1.5个Token，这个可以按经验公式估算。

当时我估算了一下，25800条切片平均每条约600字，总文本量约1500万字，对应的Token量约2000万到2500万。如果全部做一次摘要处理，按模型价格和上下文限制粗略规划，耗时和成本都是需要事先预算好的。

注意：不同模型的Token计算器有差异，建议上线前用官方Tokenizer做一次精确统计，不要拍脑袋。我是先抽样100条切片精确统计，再乘以总数校准出的经验系数。

5.3 效果评测：怎么判断这次治理有没有用

做完整个流程后，我构建了一套评测集来量化治理效果。评测集包含300个真实业务问题，覆盖专利查询、方案对比、标准检索、缺陷排查等类型。

评测指标有三个：检索命中率（正确的切片是否排在前列）、答案准确率（大模型生成内容是否与原文一致）、引用完整率（回答是否给出了正确的文档出处）。

治理前后差距明显：

下降最严重的是答案准确率，原因就是AI经常把不同版本文件的错误信息缝合到一起。治理后这种情况大幅减少，因为旧版本文件被标记为“历史存档”，不会进入最高优先级的检索候选区。

5.4 常见问题速查与解决

最后把这次实操中遇到的问题整理成一张速查表，每组问题后面跟着我最后采用的解法，方便以后做类似项目少走弯路。

还有一个容易被忽视的小细节：清洗规则库一定要随文档来源迭代维护。这批文件里，设计部门和技术标准部门的页眉格式完全不同，单一正则规则无法同时处理。所以规则库我设计成按部门、按文档类型加载对应的清洗配置，这也是清洗效果能保持80分以上的原因之一。

这次做完近万个源文件的治理，我最大的体会是：AI项目里最贵的不一定是算力，而是数据处理的工程量。喂给AI之前那一件“小事”，决定了后面所有环节的成败。分类体系、命名规范、清洗规则、切片策略、元数据注入——这几步里任何一步偷懒，最后都会在检索结果上暴露出来。

按我这套流程走，花的时间大部分在前半程，后面不管是接RAG、做Agent还是建知识图谱，都是一马平川。如果你的项目也面临一堆源文件即将喂给AI，建议先照着这里的思路把家底摸清楚，把乱麻理成线，再让模型接手。