语料不只是文档:一文讲透 RAG 项目中的语料建设与落地

知识库答不准、引用旧制度，很多时候不是模型“不聪明”。更常见的情况是：模型拿到的材料本身就不完整、不可信，或者根本没法追溯。

做企业知识库、RAG 或大模型应用时，很多团队会先讨论模型、Prompt、向量库、召回策略。那些当然重要，但我更建议先把问题往前挪一步：这些被模型使用的资料，真的已经变成可用语料了吗？

先看这篇文章解决什么问题

如果你正在做企业知识库，可以把这篇文章当成一份语料工程检查清单。它主要回答四个问题：

知识库上线后，常见的问题差不多是这些：

这些问题看起来像模型幻觉、Prompt 不稳定、检索能力弱。真正排查时，很多都落回到语料上。

1. 三个项目现场里的典型问题

某制造业客户上传了 3000 多份 PDF。测试搜索“焊接工艺参数”时，系统返回的是 2019 年旧规程。后来发现，新版规程是扫描件，OCR 识别率只有 60% 左右，关键术语没有被正确索引。模型不是不想引用新版，是根本没拿到。

另一个金融客户，问答系统把内部审计报告当成公开制度引用。原因也不复杂：文档权限字段为空，检索阶段没有过滤条件。

还有一个政府项目，同一份“项目验收制度”被人工改过三次，知识库里三个版本同时存在。用户提问时，系统随机命中不同版本，回答自然不稳定。

2. 这些问题靠换模型很难解决

根因是文件还没有被加工成模型能稳定使用、业务也能核验的语料。

如果语料里本来就是旧版本、半截流程、无权限字段、无来源信息，模型后面再怎么组织语言，也只能在错误材料上继续生成。

“语料”原本是语言学里的说法，指研究者收集的书籍、报纸、演讲、对话等语言材料。到了大模型和 RAG 场景里，范围更广。

制度文件、客服问答、会议纪要、项目材料、产品说明、操作手册、代码、视频字幕、图片说明、表格，都可能成为语料。

但关键不在文件类型，而在用途。

一份项目管理制度，放在网盘里时只是文档；当它被用来检索“项目验收规则”、支撑模型回答、作为评测依据时，它才进入语料范围。

这里有两个容易被忽略的点。

第一，语料不是原始数据。订单记录、客服录音、设备日志、制度 PDF，都只是原材料。它们需要被处理，才可能被模型稳定使用。

第二，语料必须服务于具体任务。没有明确用途的资料堆积，只会增加检索噪声，不会自动变成知识库能力。

从原始资料到可用语料

这条链路少一步，后面都可能出问题。

这一部分可以直接当作入库前检查表使用。

1. 解析：先确认内容真的被读出来了

很多项目把“文件上传成功”当成“知识入库成功”。这是第一个坑。

常见问题包括：

入库前至少做一次抽检。

解析质量不要只看“有没有文本”。真正要看的是：关键业务信息有没有被正确读出来。

2. 清洗：近似重复比完全重复更麻烦

企业文档里最隐蔽的问题，往往不是完全重复，而是近似重复。

比如：

只做文件哈希去重，基本发现不了这些问题。

更稳妥的做法：

3. 脱敏：别把合规风险留给模型

正则能识别手机号、身份证号、银行卡号这类结构化信息，但企业内部真正麻烦的敏感信息，通常没这么规整。

更难处理的是客户简称、项目代号、合同金额、报价策略、内部审计结论、供应商评估材料，以及只对某区域、某部门可见的制度。

建议用三层方式处理：

脱敏后必须抽检。脱敏不足是合规风险，脱敏过度也会让语料不可用。比如把所有数字都替换成 `***`，报销标准、审批金额、时限要求就都没法回答。

4. 切分：RAG 里最容易被低估的环节

很多系统默认按固定字数切分，比如 500 字一段、100 字重叠。这种做法实现简单，但很容易把业务语义切断。

举个例子：

如果“金额条件”和“审批要求”被切到两个语料块里，检索命中其中一半都不够。模型拿到的上下文不完整，答案就会飘。

切分时要守住一个原则：一个语料块应能独立表达一个完整业务含义。

几个实战建议：

“给模型喂资料”不是一个动作。资料到底用来做什么，决定了它该怎么处理。

1. 预训练语料：别指望它解决企业当前事实

预训练语料用于让模型学习语言、常识和通用能力，通常来自公开网页、书籍、论文、代码和对话，规模非常大。

如果目标是企业内部知识库，不要把主要精力放在“整理预训练语料”上。几千份制度文件对预训练来说太少，成本也不划算。

2. 微调语料：让模型学会格式、风格和任务套路

微调更适合让模型学会特定输出格式、表达习惯和任务流程，比如把会议记录整理成待办、按企业格式生成周报、按固定字段输出项目风险、按数据治理术语解释质量规则。

微调语料的重点不是数量，而是一致性。

高质量样本通常包含这些内容：

我的经验是：500 条格式统一、业务准确的样本，往往比 5000 条凑数样本更有用。

3. RAG 语料：回答当前问题，并给出依据

RAG 更适合处理经常变化、需要引用依据的企业知识，比如最新制度、项目流程、产品说明、报销标准、交付规范、运维手册。

RAG 语料有两个要求很难绕开：时效性和可追溯性。

4. 评测语料：没有它，验收就是凭感觉

很多项目验收时，只靠几个人现场问几个问题，然后说“感觉还行”。这和没有测试用例就上线业务系统差不多。

一个可用的 RAG 评测集，至少应该包含：

评测集不要只放简单题。至少要有四类：

这一类题很重要。系统宁可说“不知道”或“资料不足”，也不要编一个看起来完整的答案。

5. 反馈语料：线上问题不要白白发生

上线后的用户反馈，是语料持续改进的重要来源。

最小可行做法很简单：问答界面加“答对了 / 答错了”。用户点“答错了”时，给一个文本框让他补充原因。每周导出反馈数据，按错误类型分类，再针对 Top 问题修复语料、切分、权限或检索策略。

错误可以先分成几类：

不要等攒了三个月再看反馈。到那时，很多资料可能又变了。

人看到两份制度，可能知道哪份是现行版、哪份只是草稿、哪些内容不能外发。模型不会天然知道这些。

如果来源、版本、权限、有效期和责任人没有被明确管理，模型在回答时也补不上这层判断。

语料治理至少要回答这些问题：

可以把语料当成一种内容型数据资产来管。刚开始不用建很重的平台，先维护下面这些属性就够用了。

优先级可以这样排：

很多知识库项目一开始就盘点几千份文档，然后讨论怎么批量导入。这样很容易陷入资料搬运。

更好的起点，是一个高频、边界清楚、风险可控的问题。

比如：

选择第一个场景的三个条件

选定问题后，再倒推语料：

这样做，语料建设就不会变成“资料越多越好”，而是围绕一个能验证的业务闭环展开。

面对一份制度、一个案例或一批历史问答，先别急着入库。用六个问题过一遍：

有一两项答不上来，不代表内容必须丢弃，但说明它还不适合直接进入回答链路。

这道关比“文件格式支不支持上传”重要得多。

如果你正在推进知识库项目，不必一开始就做大而全的平台。可以先用两周跑一个最小闭环。

第一周：把一批资料变成可测语料

目标是选一个场景，跑通从资料到语料的链路。

建议这样做：

第一周的产出不要只写“导入了多少文件”。更有价值的是这些东西：

第二周：用真实问题验证并修正

目标是验证系统能不能稳定回答真实问题。

可以按这个顺序来：

第二周建议留下四个产出：评测报告、错误案例清单、语料处理 SOP、反馈机制。

这比“三个月后再整体看效果”靠谱得多。

如果要把这些动作落到团队流程里，可以先用下面这套 SOP。

步骤 1：定义问题

步骤 2：筛选资料

步骤 3：解析和清洗

步骤 4：脱敏和权限标注

步骤 5：切分和元数据补充

步骤 6：入库和评测

步骤 7：上线后反馈闭环

接入多少文件，并不能说明知识库已经可用。模型可以换，向量库可以换，Prompt 也可以继续调。但如果语料的来源、版本、权限、质量、评测和反馈没有被管起来，系统拿到的仍然可能是错的、旧的、不完整的内容。

RAG 项目不是把资料全部塞进去，而是让模型在需要回答时，能拿到正确、完整、有效、可追溯、并且符合权限要求的内容。

如果你正在推进一个企业知识库项目，不用一开始就开大而全的资料盘点会。

先选一个真实问题，抽 10 份资料，用“六个问题”过一遍。你很快就能看出来，团队真正缺的是模型能力，还是一套能让内容被可靠使用的语料管理方式。

这个小闭环跑通后，再扩大范围、增加自动化、建设平台，会稳很多。