知识库答不准、引用旧制度，很多时候不是模型“不聪明”。更常见的情况是：模型拿到的材料本身就不完整、不可信，或者根本没法追溯。
做企业知识库、RAG 或大模型应用时，很多团队会先讨论模型、Prompt、向量库、召回策略。那些当然重要，但我更建议先把问题往前挪一步：这些被模型使用的资料，真的已经变成可用语料了吗？
企业 RAG 项目先把语料管明白：解析、清洗、脱敏、切分、评测，每一步都决定答案质量。
在企业项目里，上传文件只是开始。真正影响答案质量的，是资料有没有经过解析、清洗、脱敏、切分、标注、权限控制、版本治理和评测验证。
这篇文章只讲一件事：RAG 项目先别急着调模型，先把语料工程这道关过掉。
先看这篇文章解决什么问题
如果你正在做企业知识库，可以把这篇文章当成一份语料工程检查清单。它主要回答四个问题：
- 为什么很多 RAG 问题，根因不在模型，而在语料？
- 一份普通文档，怎样才算变成可用语料？
- 语料处理过程中，解析、清洗、脱敏、切分、评测分别要注意什么？
- 如果项目刚启动，怎样用两周跑通一个最小闭环？
一、很多“模型问题”，其实是语料问题
知识库上线后，常见的问题差不多是这些：
- 用户问“项目验收需要什么材料”，系统只找到了半截流程。
- 制度已经更新，回答却引用旧版本。
- 内部审计报告被系统当成公开制度引用。
- 同一类问题，每次回答都不一样。
- 用户看完答案后继续追问：“这个依据来自哪里？”
这些问题看起来像模型幻觉、Prompt 不稳定、检索能力弱。真正排查时，很多都落回到语料上。
1. 三个项目现场里的典型问题
某制造业客户上传了 3000 多份 PDF。测试搜索“焊接工艺参数”时，系统返回的是 2019 年旧规程。后来发现，新版规程是扫描件，OCR 识别率只有 60% 左右，关键术语没有被正确索引。模型不是不想引用新版，是根本没拿到。
另一个金融客户，问答系统把内部审计报告当成公开制度引用。原因也不复杂：文档权限字段为空，检索阶段没有过滤条件。
还有一个政府项目，同一份“项目验收制度”被人工改过三次，知识库里三个版本同时存在。用户提问时，系统随机命中不同版本，回答自然不稳定。
2. 这些问题靠换模型很难解决
根因是文件还没有被加工成模型能稳定使用、业务也能核验的语料。
如果语料里本来就是旧版本、半截流程、无权限字段、无来源信息，模型后面再怎么组织语言，也只能在错误材料上继续生成。
二、先说清楚：什么是语料
“语料”原本是语言学里的说法，指研究者收集的书籍、报纸、演讲、对话等语言材料。到了大模型和 RAG 场景里，范围更广。
制度文件、客服问答、会议纪要、项目材料、产品说明、操作手册、代码、视频字幕、图片说明、表格，都可能成为语料。
但关键不在文件类型，而在用途。
一份项目管理制度，放在网盘里时只是文档；当它被用来检索“项目验收规则”、支撑模型回答、作为评测依据时，它才进入语料范围。
我更愿意把企业语料理解成：为训练、检索、评测或改进模型而准备的内容资产。
这里有两个容易被忽略的点。
第一，语料不是原始数据。订单记录、客服录音、设备日志、制度 PDF，都只是原材料。它们需要被处理，才可能被模型稳定使用。
第二，语料必须服务于具体任务。没有明确用途的资料堆积，只会增加检索噪声，不会自动变成知识库能力。
从原始资料到可用语料
原始数据 / 原始文档
↓
内容解析：把 PDF、Word、PPT、图片、音视频转成可处理文本
↓
清洗去重：去掉乱码、页眉页脚、重复内容、无效段落
↓
脱敏与合规处理：识别敏感字段、内部信息、客户信息
↓
分类与标注：补充来源、版本、权限、业务对象、有效期
↓
语义切分：按完整业务含义切成可检索片段
↓
入库与评测：进入检索链路，并用真实问题验证效果
这条链路少一步，后面都可能出问题。
三、语料处理不是“导入文件”，每一步都要过关
这一部分可以直接当作入库前检查表使用。
1. 解析：先确认内容真的被读出来了
很多项目把“文件上传成功”当成“知识入库成功”。这是第一个坑。
常见问题包括：
- PDF 是扫描件，文字其实是图片。
- Word 里的嵌入 Excel、Visio、附件没有被解析。
- PPT 里的 SmartArt、流程图、备注顺序混乱。
- 表格跨页后，表头和内容关系断了。
- 图片里的说明文字完全丢失。
入库前至少做一次抽检。
| 检查项 | 怎么看 | 不通过怎么办 |
|---|---|---|
| 文本是否完整 | 抽 3 页原文，与解析结果对照 | 补 OCR，或更换解析器 |
| 表格关系是否保留 | 检查表头、合并单元格、跨页表格 | 表格单独抽取，不按普通段落处理 |
| 图片信息是否丢失 | 看流程图、截图、盖章页是否有文字说明 | 增加图片 OCR，必要时人工摘要 |
| 附件是否遗漏 | 检查 Word/PDF 中的嵌入文件 | 作为独立资料建关联关系 |
| 标题层级是否正确 | 看 H1/H2/H3 是否被识别 | 解析后重建标题结构 |
解析质量不要只看“有没有文本”。真正要看的是：关键业务信息有没有被正确读出来。
2. 清洗：近似重复比完全重复更麻烦
企业文档里最隐蔽的问题，往往不是完全重复，而是近似重复。
比如：
- 同一份制度改了几个字后重新上传。
- 不同部门复制同一模板，只改了部门名称。
- 草稿版、送审版、正式版同时存在。
- 页眉页脚、页码、水印混进正文。
- 目录、封面、修订记录被当成正文检索。
只做文件哈希去重，基本发现不了这些问题。
更稳妥的做法：
- 先做结构清洗，去掉封面、目录、页眉页脚、空白页、水印噪声。
- 再做语义去重，用文本相似度或向量相似度识别近似重复。
- 最后抽样人审，尤其是制度、合同、审计、财务这类高风险资料。
一个简单规则：同一业务主题下，两份文档相似度超过 85%，必须检查版本、生效日期和责任部门，不能直接同时入库。
3. 脱敏：别把合规风险留给模型
正则能识别手机号、身份证号、银行卡号这类结构化信息，但企业内部真正麻烦的敏感信息，通常没这么规整。
更难处理的是客户简称、项目代号、合同金额、报价策略、内部审计结论、供应商评估材料，以及只对某区域、某部门可见的制度。
建议用三层方式处理：
| 层级 | 处理对象 | 示例 |
|---|---|---|
| 规则识别 | 结构化敏感信息 | 手机号、邮箱、身份证、统一社会信用代码 |
| 实体识别 | 业务实体 | 客户名、项目名、人名、地址、金额、合同编号 |
| 业务字典识别 | 企业内部叫法 | 客户简称、项目代号、产品代号、组织简称 |
脱敏后必须抽检。脱敏不足是合规风险，脱敏过度也会让语料不可用。比如把所有数字都替换成 ***，报销标准、审批金额、时限要求就都没法回答。
4. 切分：RAG 里最容易被低估的环节
很多系统默认按固定字数切分，比如 500 字一段、100 字重叠。这种做法实现简单，但很容易把业务语义切断。
举个例子：
金额超过 100 万元的项目，必须经过专项审批。
如果“金额条件”和“审批要求”被切到两个语料块里，检索命中其中一半都不够。模型拿到的上下文不完整，答案就会飘。
切分时要守住一个原则：一个语料块应能独立表达一个完整业务含义。
| 切分方式 | 适合什么资料 | 好处 | 风险 |
|---|---|---|---|
| 固定长度切分 | 叙述型报告、会议纪要 | 简单、成本低 | 容易截断规则和表格 |
| 标题层级切分 | 制度、手册、方案 | 能保留章节结构 | 依赖文档标题规范 |
| 语义切分 | 培训材料、客服对话、技术方案 | 更贴近话题边界 | 成本更高，需要嵌入计算 |
| 混合切分 | 大多数企业知识库 | 稳定性更好 | 需要规则和工程配置 |
| 表格整体切分 | 费用标准、审批矩阵、参数表 | 保留行列关系 | 块可能较大，需要摘要辅助 |
几个实战建议：
- 制度文件优先按标题层级切分，并把上级标题保留下来。
- 表格不要按单元格切，至少按完整表格或完整业务行组处理。
- 流程类内容要把步骤、条件、例外、责任人放在同一个上下文里。
- 超长章节可以先按标题切，再做语义二次切分。
- 每个块都要带上来源、页码、章节、版本、生效日期和权限标签。
四、同一份资料，用法不同，处理方式也不同
“给模型喂资料”不是一个动作。资料到底用来做什么，决定了它该怎么处理。
| 用法 | 主要目标 | 处理重点 |
|---|---|---|
| 预训练语料 | 学习语言、常识和通用能力 | 规模、覆盖面、基础质量 |
| 微调语料 | 学会格式、风格和任务套路 | 样本一致性、输入输出格式、测试集 |
| RAG 语料 | 回答当前问题，并给出依据 | 时效性、可追溯性、权限、切分 |
| 评测语料 | 判断系统是否真的答对 | 真实问题、标准答案、评分维度 |
| 反馈语料 | 把线上问题沉淀为改进材料 | 错误归因、周期复盘、定向修复 |
1. 预训练语料：别指望它解决企业当前事实
预训练语料用于让模型学习语言、常识和通用能力，通常来自公开网页、书籍、论文、代码和对话，规模非常大。
如果目标是企业内部知识库，不要把主要精力放在“整理预训练语料”上。几千份制度文件对预训练来说太少，成本也不划算。
2. 微调语料：让模型学会格式、风格和任务套路
微调更适合让模型学会特定输出格式、表达习惯和任务流程，比如把会议记录整理成待办、按企业格式生成周报、按固定字段输出项目风险、按数据治理术语解释质量规则。
微调语料的重点不是数量，而是一致性。
高质量样本通常包含这些内容：
用户指令：明确任务和业务上下文
输入材料：需要处理的原始内容
标准输出：格式稳定、字段完整、边界清楚
评审理由：为什么这样输出，哪些内容不能编造
我的经验是：500 条格式统一、业务准确的样本，往往比 5000 条凑数样本更有用。
3. RAG 语料：回答当前问题，并给出依据
RAG 更适合处理经常变化、需要引用依据的企业知识，比如最新制度、项目流程、产品说明、报销标准、交付规范、运维手册。
RAG 语料有两个要求很难绕开：时效性和可追溯性。
- 时效性意味着制度更新后，语料库要同步刷新。不是“有人想起来再传一版”，而是要能识别版本变化，并触发重新解析和入库。
- 可追溯性意味着回答要能回到原文、版本和具体位置。用户问“现行项目验收流程是什么”，系统不能只回答得像真的，还要告诉他依据来自哪份文件、哪个版本、哪一节。
4. 评测语料：没有它，验收就是凭感觉
很多项目验收时，只靠几个人现场问几个问题，然后说“感觉还行”。这和没有测试用例就上线业务系统差不多。
一个可用的 RAG 评测集，至少应该包含：
| 字段 | 说明 |
|---|---|
| 用户问题 | 来自真实业务场景，而不是凭空编 |
| 用户角色 | 不同角色可能有不同权限和回答范围 |
| 参考依据 | 明确到文件、版本、章节或页码 |
| 标准答案 | 表达可以不同，但关键信息不能缺 |
| 必含要点 | 必须覆盖的条件、步骤、例外 |
| 禁止事项 | 不能泄露、不能编造、不能越权引用的内容 |
| 评分维度 | 检索相关性、答案忠实度、完整性、可追溯性 |
评测集不要只放简单题。至少要有四类：
- 直接检索题：制度里明确写了答案。
- 条件判断题：需要结合金额、角色、地区、时间等条件。
- 多文档综合题：需要同时参考制度、流程、表单或 FAQ。
- 拒答题：资料不足、权限不足或不属于系统范围时，系统应该拒绝。
这一类题很重要。系统宁可说“不知道”或“资料不足”，也不要编一个看起来完整的答案。
5. 反馈语料：线上问题不要白白发生
上线后的用户反馈，是语料持续改进的重要来源。
最小可行做法很简单：问答界面加“答对了 / 答错了”。用户点“答错了”时，给一个文本框让他补充原因。每周导出反馈数据，按错误类型分类，再针对 Top 问题修复语料、切分、权限或检索策略。
错误可以先分成几类：
| 错误类型 | 典型表现 | 优先排查 |
|---|---|---|
| 检索失败 | 没找到相关段落 | 解析、切分、索引、关键词缺失 |
| 检索噪声 | 找到一堆不相关内容 | 元数据过滤、去重、召回策略 |
| 生成错误 | 依据正确但回答错 | Prompt、答案约束、模型能力 |
| 版本错误 | 引用了旧制度 | 版本治理、生效日期、现行标记 |
| 权限错误 | 引用了不该看的资料 | 权限标签、检索过滤、用户身份映射 |
| 拒答失败 | 不知道还硬答 | 安全边界、置信度阈值、拒答策略 |
不要等攒了三个月再看反馈。到那时，很多资料可能又变了。
五、语料治理：把模型看不出来的判断补进去
人看到两份制度，可能知道哪份是现行版、哪份只是草稿、哪些内容不能外发。模型不会天然知道这些。
如果来源、版本、权限、有效期和责任人没有被明确管理，模型在回答时也补不上这层判断。
语料治理至少要回答这些问题：
- 这份内容从哪里来？
- 谁对内容负责？
- 它现在是否有效？
- 是否有替代版本？
- 适用于哪些部门、区域、角色或场景？
- 哪些用户有权限访问？
- 出问题时能否回到原文核验？
- 内容是否完整、准确、可解析？
可以把语料当成一种内容型数据资产来管。刚开始不用建很重的平台，先维护下面这些属性就够用了。
| 属性维度 | 关键字段 | 缺失后的典型后果 |
|---|---|---|
| 来源 | 源文件路径、上传人、所属部门、创建时间 | 引用来源不明的材料 |
| 版本 | 版本号、生效日期、是否现行版、替代关系 | 引用已废止制度 |
| 权限 | 密级、可见角色、可见部门、是否可外发 | 内部资料被越权引用 |
| 内容质量 | OCR 质量、乱码比例、完整性评分 | 检索命中但答案残缺 |
| 时效 | 失效日期、更新周期、最后检查时间 | 过期流程继续被使用 |
| 覆盖度 | 业务场景、问题类型、适用范围 | 高频问题检索不到 |
| 可追溯 | 原文链接、页码、章节、段落 ID | 用户无法核验来源 |
| 责任机制 | 内容负责人、审核人、更新责任人 | 发现问题后没人维护 |
优先级可以这样排：
- 先补权限和版本，因为最容易出事故。
- 再补来源、责任人和可追溯位置，因为影响信任和追责。
- 最后逐步补质量评分、覆盖度和更新周期。
刚起步时，用 Excel 或在线表格维护 50 份核心文档的元数据，也比完全没有强。不要一开始就追求平台化、自动化、大而全。
六、别从“导入多少文件”开始，从一个真实问题开始
很多知识库项目一开始就盘点几千份文档，然后讨论怎么批量导入。这样很容易陷入资料搬运。
更好的起点，是一个高频、边界清楚、风险可控的问题。
比如：
- 项目验收要提交哪些材料？
- 差旅报销标准是什么？
- 退款申请如何处理？
- 某类设备操作前要检查什么？
选择第一个场景的三个条件
| 标准 | 建议 | 不建议 |
|---|---|---|
| 高频 | 用户经常问，答对有感知 | 很少有人问的问题 |
| 边界清楚 | 答案来自明确制度或流程 | 需要大量主观判断的问题 |
| 风险可控 | 答错影响可控，可人工兜底 | 涉及薪酬、审计、合同机密等高风险内容 |
选定问题后，再倒推语料：
- 谁会问这个问题？
- 系统需要回答到什么程度？
- 哪些内容必须回答？
- 哪些内容不应该回答？
- 需要引用哪些制度、流程、表单或历史问答？
- 回答是否涉及权限、地区、金额、时间等条件？
这样做，语料建设就不会变成“资料越多越好”，而是围绕一个能验证的业务闭环展开。
七、上库前，用六个问题卡一道关
面对一份制度、一个案例或一批历史问答，先别急着入库。用六个问题过一遍：
- 它解决什么具体业务问题？
- 来源是否可信，谁对内容负责？
- 现在是否有效，有没有更新或替代版本？
- 离开全文后，它还能不能表达完整规则？
- 哪些人可以访问它？
- 模型引用它时，能否回到原始位置核验？
有一两项答不上来，不代表内容必须丢弃，但说明它还不适合直接进入回答链路。
| 检查结果 | 处理建议 |
|---|---|
| 来源不清 | 暂缓入库，先找责任部门确认 |
| 版本不清 | 标记为待核验，不参与正式回答 |
| 权限不清 | 默认按更严格权限处理 |
| 内容不完整 | 补全文、补附件或补上下文后再入库 |
| 不可追溯 | 补原文链接、页码、章节或段落编号 |
| 业务问题不明确 | 先归档，不进入主检索库 |
这道关比“文件格式支不支持上传”重要得多。
八、两周跑通一个语料工程 MVP
如果你正在推进知识库项目，不必一开始就做大而全的平台。可以先用两周跑一个最小闭环。
| 周期 | 目标 | 关键产出 |
|---|---|---|
| 第一周 | 把一批资料变成可测语料 | 可检索语料、元数据清单、评测集、已知问题列表 |
| 第二周 | 用真实问题验证并修正 | 评测报告、错误案例清单、语料处理 SOP、反馈机制 |
第一周：把一批资料变成可测语料
目标是选一个场景，跑通从资料到语料的链路。
建议这样做：
- 选定一个高频、边界清楚的业务问题。
- 收集 10-20 份源文档，包括制度、流程、表单、FAQ、历史问答。
- 完成解析、清洗、去重、脱敏、切分。
- 为每个语料块补充元数据：来源、版本、权限、章节、生效日期。
- 建一个 20 道题左右的评测集。
第一周的产出不要只写“导入了多少文件”。更有价值的是这些东西：
- 一批可检索语料
- 一份元数据清单
- 一个评测集
- 一份已知问题列表
第二周：用真实问题验证并修正
目标是验证系统能不能稳定回答真实问题。
可以按这个顺序来：
- 跑首轮检索评测。
- 记录每个问题命中的语料块。
- 分析至少 5 个错误案例。
- 判断错误来自解析、切分、检索、版本、权限还是生成。
- 针对问题修正语料或调整策略。
- 在界面上加入最小反馈机制。
第二周建议留下四个产出：评测报告、错误案例清单、语料处理 SOP、反馈机制。
这比“三个月后再整体看效果”靠谱得多。
九、一个可复用的语料入库 SOP
如果要把这些动作落到团队流程里，可以先用下面这套 SOP。
| 步骤 | 要做什么 | 关键检查点 |
|---|---|---|
| 1. 定义问题 | 明确用户、问题、回答范围、禁止回答内容 | 问题是否足够具体 |
| 2. 筛选资料 | 只收集与问题直接相关的资料 | 来源、责任人、版本是否清楚 |
| 3. 解析和清洗 | 检查 OCR、表格、图片、附件、标题层级 | 是否有乱码、缺页、重复、无效内容 |
| 4. 脱敏和权限标注 | 做规则脱敏、实体识别、业务字典识别 | 权限是否按最小可见范围处理 |
| 5. 切分和元数据补充 | 按标题、语义和业务规则混合切分 | 是否保留来源、版本、章节、生效日期 |
| 6. 入库和评测 | 用真实问题测试检索和答案忠实度 | 是否记录未命中、错命中、旧版本、越权命中 |
| 7. 上线后反馈闭环 | 收集反馈，每周归类错误 | 是否优先修复高频、高风险问题 |
步骤 1：定义问题
- 明确用户是谁。
- 明确用户会问什么。
- 明确系统应该回答到什么程度。
- 明确哪些内容不能回答。
步骤 2：筛选资料
- 只收集与问题直接相关的资料。
- 优先选择来源清楚、责任人明确、版本有效的资料。
- 来源不清、权限不清、版本不明的资料先暂缓。
步骤 3：解析和清洗
- 检查 OCR、表格、图片、附件、标题层级。
- 去掉封面、目录、页眉页脚、无效重复内容。
- 对近似重复文档做版本判断。
步骤 4：脱敏和权限标注
- 做规则脱敏、实体识别和业务字典识别。
- 给文档和语料块打权限标签。
- 默认采用最小可见范围。
步骤 5：切分和元数据补充
- 按标题、语义和业务规则混合切分。
- 保留上级标题、来源、版本、页码、章节、生效日期。
- 表格、流程、条件规则要保留完整上下文。
步骤 6：入库和评测
- 用真实问题测试检索命中率和答案忠实度。
- 记录未命中、错命中、旧版本命中、越权命中。
- 把问题回写到语料处理规则里。
步骤 7：上线后反馈闭环
- 收集用户反馈。
- 每周归类错误。
- 优先修复高频、高风险问题。
- 持续更新评测集。
十、最后：别让模型替语料背锅
接入多少文件，并不能说明知识库已经可用。模型可以换，向量库可以换，Prompt 也可以继续调。但如果语料的来源、版本、权限、质量、评测和反馈没有被管起来，系统拿到的仍然可能是错的、旧的、不完整的内容。
RAG 项目不是把资料全部塞进去，而是让模型在需要回答时，能拿到正确、完整、有效、可追溯、并且符合权限要求的内容。
如果你正在推进一个企业知识库项目，不用一开始就开大而全的资料盘点会。
先选一个真实问题，抽 10 份资料，用“六个问题”过一遍。你很快就能看出来，团队真正缺的是模型能力，还是一套能让内容被可靠使用的语料管理方式。
这个小闭环跑通后，再扩大范围、增加自动化、建设平台，会稳很多。
