RAG数据准备指南：从知识资产盘点到质量评估，构建企业级大模型应用基础

本文详细介绍了RAG系统数据准备的完整流程，包括知识资产盘点、数据清洗、文本分块、元数据提取与增强、向量化与索引以及质量评估。文章强调数据是RAG系统的核心基础，针对不同规模场景提供具体实施策略，并指出大多数问题源于数据而非模型，强调了构建Golden数据集和持续迭代的重要性。

数据准备阶段是架构落地的起点,因为:

RAG系统的核心就是知识库,没有高质量的知识数据,后续检索和生成都无从谈起
数据准备过程中发现架构设计的问题时,可以及时调整
为后续的检索、召回、生成等模块提供测试数据

知识数据准备 = 把“企业资料” → 变成“可被检索、可被引用、可被追责”的知识资产

不是“把文件随便丢进去”，是重构一套企业级知识工程。

一、知识资产盘点（Data Collection）

知识来源有哪些？

产品文档 / 技术手册
内部 Wiki（Confluence / Notion）
Word / PDF / PPT
邮件 / 工单 / FAQ
代码 / API 文档 / DB schema

谁是权威来源？

是否存在多份互相矛盾的文档？
哪份才是“最终解释权”？

是否允许被 AI 回答？

法务 / 合规 / 隐私文档
是否需要脱敏 / 屏蔽 / 分级授权？

👉这一阶段产出的是：

数据源清单
权威性标注
访问级别规则

二、原始数据清洗（Data Cleaning）

1️⃣ 删除“对人有用、对模型没用”的东西，比如：

页眉页脚、目录、版权声明
“本页故意留白”
重复段落
UI 导航文本等
对于表格、图片等非文本内容,需要考虑是否转换或提取其中的信息。

2️⃣ 转换为结构化数据，比如：

{ "title": "退款政策", "section": "退款条件", "content": "...", "source": "policy_v3.pdf", "page": 12 }

结构 = 未来可解释性 + 可引用性 + 可审计性

目前使用AI生成清洗脚本可以非常方便的进行数据清洗。

三、文本分块（Chunking）

不会切分 = 项目失败

切分规则，按“语义边界”：

标题
小节
段落
列表
问答对
API 参数块等

实战技巧:

Markdown文档:按##标题切分效果好
PDF合同:按条款编号切分
API文档:按endpoint切分
代码:按function/class切分

可以让ai按照规则生成切分代码，或者将文档丢给LLM切分。

四、元数据提取与数据增强（Enrichment）

4.1 元数据提取（Metadata Extraction）

目的：

Filtering（时间 / 部门 / 产品）
Hybrid Search（关键词 + 向量）
为后续 Rerank 提供支持

元数据类型：

类型	来源	说明
时间	文件名 / 正文 / 页眉	YYYY-MM-DD 或年月
作者	页眉 / 签批 / 邮件	找不到就空
部门	固定词表匹配	权限控制简单点可以直接根据部门
关键词	LLM	控制数量
实体	LLM + 正则	项目名 / 产品名
source	文件名/网址	回答时引用文档
权限标签	业务需求	ABAC / RBAC
文档版本	文件名 / 正文 / 页眉	灰度发布

Metadata 示例

{ "doc_id": "policy_hr_2025", "chunk_id": "policy_hr_2025_09", "date": "2025-12-01", "department": "人力资源部", "keywords": ["绩效考核", "KPI", "晋升"], "entities": ["绩效管理系统"] }

可以让LLM 帮忙提取Metadata的 Prompt：

你是企业知识治理专家。 请从以下文本中提取元数据，并严格按 JSON 输出。 字段说明： - date: 文本中明确出现的时间（ISO 格式），没有则为 null - author: 作者或签发人 - department: 所属部门（若无法判断则为 null） - keywords: 5 个以内关键词 - entities: 文中提到的产品名 / 项目名 / 系统名 文本： {{chunk_text}}

4.2 假设性问题生成（Doc2Query）（可选，建议）

做法：

每个 chunk 生成3–5 个用户可能会问的问题
用“问题向量”建索引
原文可选：只存 metadata + source

Prompt

你是企业知识库的用户。 请基于以下内容，生成 3-5 个真实用户可能提出的问题。 要求： - 用自然语言 - 不要复述原文 - 覆盖“怎么做 / 是什么 / 条件 / 限制” 内容： {{chunk_text}}

4.3 摘要生成（Hierarchical Summary）（可选，适用中大型 RAG）

用途

粗排（先看哪篇文档）
父子文档结构（Parent–Child RAG）
减少长文 token 压力

两级摘要：

层级	内容	面向谁	用来干什么
文档级	200–300 字	检索系统 / 粗排	筛选文档
章节级	1–2 句话	Parent–Child RAG	定位“该用哪一组 chunk”

Prompt：

请将以下文档总结为不超过 300 字的摘要， 重点说明： - 适用对象 - 核心规则 - 特殊限制 文档： {{full_text}}

文档级摘要：

1.放哪？

✅建议放入 Elasticsearch

{ "doc_id": "policy_hr_2025", "title": "员工绩效管理制度", "summary": "本制度适用于公司全体员工，规定了年度绩效考核的评估周期、评分等级及结果应用方式。绩效结果分为A/B/C/D四级，连续两年C级以下将触发岗位调整或劳动关系处理。特殊岗位考核标准另行规定。", "department": "人力资源部", "version": "2025" }

2.怎么用？

✅用于粗排 / 文档级筛选

User Query ↓ BM25 / Vector ↓ 先命中 10~20 篇文档（基于 summary / title） ↓ 只在这些文档的 chunk 里做细粒度检索

重要提醒：

❌ 不要把摘要直接喂给 LLM 当依据
❌ 不要让模型“基于摘要回答问题”

章节级摘要：Parent–Child RAG 怎么用？（可选中的可选）

1️⃣ 数据结构

文档 ├─ 第1章（summary） │ ├─ chunk_1 │ ├─ chunk_2 ├─ 第2章（summary） │ ├─ chunk_3 │ ├─ chunk_4

2️⃣ 章节级摘要生成规则

每个章节 1–2 句话
不超过 50 字
描述“这一章主要解决什么问题

3️⃣ 章节摘要存哪？

建议作为 Parent Document，不一定向量化

{ "parent_id": "policy_hr_2025_ch2", "summary": "本章规定绩效考核的评分标准及各等级对应的管理措施。", "child_chunks": [ "chunk_03", "chunk_04", "chunk_05" ] }

4️⃣ 检索时怎么用？（Parent–Child 流程）

User Query ↓ 向量 / BM25 命中 Parent Summary（章节级） ↓ 只取该 Parent 下的 chunk ↓ 再做 chunk 级向量检索 / rerank

判断是否需要用摘要：

当你满足任意一条，记得加上：

chunk > 5k
文档 > 300
Hybrid Recall 之后噪音仍高
Reranker 前的候选 > 100 仍很乱

五、向量化与索引（Embedding & Indexing）

Embedding 模型选择(推荐这两个)

BGE-M3
qwen3 embedding 0.6B/4B/8B

Rerank 模型（可选，但推荐）

bge-reranker-large/bge-reranker-v2-m3
Qwen3-Reranker 0.6B/4B/8B
jina-reranker-v3

这两种模型的作用与区别：

向量召回在做什么？

“大概是这个话题”

Reranker 在做什么？

“这一段，是不是真的能回答这个问题”

这是两个完全不同的任务。

两种模型可以分阶段实施：

阶段一

✅ Hybrid Recall（Vector + BM25）
❌ 先不加 Reranker
👉 目标：验证数据 & Enrichment 是否正确

阶段二（一周后）

✅ 加 Reranker
Top50 → Rerank → Top5
👉 看看效果是否会提升很多

场景化示例：

场景 A：MVP / 文档不多

👉 只对 Chunk 向量化

目标：

系统先跑起来
验证：

清洗是否干净
chunk 是否合理
引用链路是否正确

向量库 Schema（示例）

{ "id": "docA_chunk_003", "vector": [ ... ], "metadata": { "doc_id": "docA", "chunk_index": 3, "source": "员工绩效制度.pdf", "page": 5 } }

👉metadata 只保留“能反查原文”的信息

检索流程

User Query ↓ Query Embedding ↓ Vector Search (TopK=3~5) ↓ 直接送 LLM

场景 B：中小型知识库，开始“不太准了”

👉 Chunk + Doc2Query（问题向量）

目标：

解决下列问题：

“好像找得到，但不太准”
“有些问题答非所问”
“换种问法就不行了”

向量库 Schema：

Question 向量：

{ "id": "q_879123", "vector": [ ... ], "metadata": { "type": "question", "source_chunk": "docA_chunk_003", "doc_id": "docA" } }

Chunk 向量：

{ "id": "docA_chunk_003", "vector": [ ... ], "metadata": { "type": "chunk", "doc_id": "docA" } }

👉必须能从 Question 精确回溯 Chunk

检索流程：

User Query ↓ Query Embedding ↓ Vector Search ├─ Question vectors (TopK=20) ├─ Chunk vectors (TopK=20) ↓ Merge（按 source_chunk 去重） ↓ Top 5~8 Chunk → LLM

场景 C：大型知识库 / 问法杂 / 制度多

👉 Chunk + Question + Hybrid + Reranker

目标：

稳定 Recall
控制噪音

Embedding & Index 策略：

向量索引

存：

Chunk
Question

稀疏索引

索引字段：

chunk_text
keywords
entities

Metadata：

{ "doc_id": "policy_hr_2025", "department": "人力资源部", "version": "2025", "effective_date": "2025-12-01", "type": "chunk" }

检索流程：```code-snippet__js
User Query
↓
Query Rewrite（可选）
↓
Hybrid Recall
├─ Vector (Question) Top 50
├─ Vector (Chunk) Top 50
├─ BM25 Top 50
↓
Merge & Dedup（chunk_id）
↓
Reranker（Top 10）
↓
Top 3~5 Chunk
↓
LLM（强引用）

| 场景 | 向量对象 | 索引类型 | 是否 Rerank | | --- | --- | --- | --- | | A | Chunk | Vector | ❌ | | B | Chunk + Question | Vector | ⚠️ 可选 | | C | Chunk + Question | Vector + BM25 | ✅ 必须 | 六、质量评估与持续迭代 (QA & Evaluation) 第一步：构建 Golden Dataset ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- #### ✅ 来源一：真实用户问题 * 工单 * 客服记录 * 内部员工常问 👉 命中率最高，最有价值 --- #### ✅ 来源二：制度/文档的“关键条款” 比如： * “不合格会怎样” * “适用范围是什么” * “生效时间？” 👉 这些**必须能答对** --- #### ⚠️ 来源三：边界案例和困难样本 * 用于覆盖冷门场景 第二步：自动化评估（RAGAS / TruLens） 目标：快速定位问题在“哪一层” **检索质量指标**： ****1.Context Recall（上下文召回率）**** 定义：检索到的 chunk，是否包含回答所需的信息。 * 是 → Recall 高 * 否 → Recall 低 **Recall目标值：> 0.85** ### Recall 低，常见原因： | 原因 | 指向 | | --- | --- | | 没命中任何相关 chunk | 切片 / 向量 | | 命中但信息不完整 | chunk 太小 | | 换个问法就不行 | Doc2Query 缺失 | **2.Context Precision（上下文精确率）** ### 定义：检索到的，有多少是有用的信息。 ### 📌 判断逻辑 ```plaintext 有用的信息 / 检索到的总信息

高 → 干净
低 → 噪音多

Precision目标值：> 0.80

Precision 低，常见原因：

原因	处理方式
TopK 参数设置过大	减小
chunk 切得太碎	调整 chunk
没做过滤	metadata filtering
没 rerank	增加Reranker

生成质量指标：

******3.Faithfulness（忠实度）

定义：回答结果，是否能在 Context 里找到依据

目标值：> 0.90

4.Answer Relevance（答案相关性）

定义：回答结果是否切题

目标值：> 0.75******

****第三步：人工抽检

抽检比例：

每次抽10–20 条 Bad Case

重点关注：

Recall 失败的
用户觉得“答非所问”的

# Bad Case诊断模板 ## 案例信息 - **问题**：用户的原始问题 - **检索结果**：返回了哪些chunks（标题+前50字） - **生成答案**：系统的回答 - **用户反馈**：点赞/点踩/追问 ## 问题诊断 ### 检索问题 - [ ] 相关chunk未被召回（召回问题） - [ ] 相关chunk排名太低（排序问题） - [ ] 检索到太多无关chunk（精确度问题） ### 数据问题 - [ ] 文档切分不当（chunk边界问题） - [ ] OCR识别错误 - [ ] 关键信息缺失/过时 - [ ] 文档结构混乱 ### 生成问题 - [ ] 答非所问 - [ ] 信息幻觉 - [ ] 逻辑混乱 - [ ] 格式不友好 ## 根因分析 【详细描述问题的根因】 ## 改进方案 【具体的优化措施，责任人，预期效果】 ## 优先级 - [ ] P0 - 影响严重，立即修复 - [ ] P1 - 影响较大，本周修复 - [ ] P2 - 影响一般，下次迭代

第四步：形成“反馈闭环”

建立「问题 → 处理方式」对照

问题类型	处理方式
Recall 低	增加 Doc2Query
Precision 低	增加 filtering / rerank
答非所问	调整 chunk
来源错误	修改metadata

一次只改一个变量，定位问题原因。

形成持续迭代的完整流程：

code-snippet__js

准备 50 条 Golden Dataset
跑完整 RAG 流程
用 RAGAS 算 Recall / Precision
筛选 Recall < 阈值的 Case
人工分析 10 条 Bad Case
定位责任层（切片 / 向量 / rerank）
修改一项
回到第 2 步

最后说三条经验：

1️⃣先保 Recall，再谈 Precision
2️⃣ 绝大多数问题在数据，不在模型
3️⃣ **没有 Golden Dataset，就没有“优化”，只有“玄学”