- RAG 知识库的效果，首先取决于石墨导出资料是否干净、完整、可追踪
- Markdown 适合正文检索，PDF 适合原貌归档，Excel 适合业务表，三者不要互相替代
- 切分要尊重标题、段落、表格和业务边界，不要只按固定字数粗暴拆分
- 每个 chunk 都应带来源路径、更新时间、负责人、权限等级等元数据
- 上线前必须评测检索命中、引用准确、过期内容拒答和更新回滚
用石墨文档搭建 RAG 知识库，推荐流程是：先把石墨文档批量导出为 Markdown、PDF、Word、Excel 等本地文件，并保留文件夹层级；再把正文清洗成稳定文本，按标题和业务语义切分为 chunks；为每个 chunk 添加来源、目录、负责人、更新时间和权限标签；最后导入 Dify、RAGFlow、向量数据库或自建检索系统，使用标准问题集评测召回和引用。RAG 不会自动修复混乱资料，石墨导出后的数据治理是效果上限。
官方资料依据
Dify 官方文档把知识库用于保存和检索文档内容，并提供文档维护、chunking 和文本清洗说明。参考：Knowledge and documents maintenance、Chunking and cleaning text。RAGFlow 官方文档强调知识库配置、parser、chunk method 和 embedding model 会影响检索效果。参考：Configure knowledge base。Amazon Bedrock 官方知识库文档也把 chunking strategy 作为 ingest 数据时的重要配置。参考：Chunking options for knowledge bases。
为什么 RAG 特别依赖石墨导出质量？
RAG 的基本过程是：把文档切成片段，转成向量，用户提问时先检索相关片段，再让大模型基于片段回答。这个流程听起来像技术问题，但实际落地时最常见的失败原因是资料本身不适合检索。
石墨里常见的文档问题包括：目录页和正文混在一起、过期流程没有删除、同一政策有多个版本、图片里有关键步骤、表格字段没有说明、文档权限和业务范围没有写在正文里。导出后如果不处理，这些问题会被向量库放大。
| 原始问题 | RAG中的表现 | 处理方式 |
|---|---|---|
| 旧版政策未删除 | AI回答过期规则 | 用版本目录和生效日期过滤 |
| 截图承载关键知识 | 检索不到或解释不稳定 | 补充文字说明和步骤摘要 |
| 大表格直接切分 | 召回片段缺少表头和口径 | 保留Excel，另写字段说明 |
| 文件名无语义 | 来源不可追踪 | 统一命名并添加元数据 |
从石墨导出时怎么选格式？
RAG 不等于所有资料都转 Markdown。不同文件承担不同角色：Markdown 做主检索文本，PDF 做原貌留存，Word 做补充编辑，Excel 做结构化数据原件。
正文知识库优先从可读、可切分的 Markdown 开始。
推荐的资料包目录
建议把每次导出的资料包做成下面这样的结构。这样不管导入 Dify、RAGFlow 还是自建系统，来源都能追踪。
ai-knowledge-base-2026-07-17/
source/
markdown/
pdf/
excel/
metadata/
documents.csv
owners.csv
changelog.md
cleaned/
markdown/
table-summaries/
eval/
questions.csv
expected-sources.csv
source/ 保存原始导出，cleaned/ 保存准备进入知识库的文本，metadata/ 保存来源和权限，eval/ 保存验收题。不要只保留导入后的向量库，因为向量库很难反向还原原始文件。
导入前的清洗规则
保留标题层级，删除导航噪声
Markdown 的标题层级对 chunking 很重要。建议保留 #、##、### 结构，但删除“返回目录”“更新时间空模板”“无内容占位”“复制自某某”等噪声段落。
把图片知识变成文字
如果图片只是装饰，可以保留为附件；如果图片包含流程、架构图、表单截图或故障步骤，要在图片下方增加简短说明。RAG 检索文本时，文字说明比图片文件名更可靠。
给每篇文档增加头部元数据
建议在清洗后的 Markdown 顶部增加简短 front matter，便于后续导入系统或自建脚本读取。
---
source_path: "团队空间/客服中心/退款政策.md"
owner: "客服运营"
updated_at: "2026-07-10"
scope: "售后客服"
permission_level: "internal"
version: "v3"
---
切分策略：按语义，不只按字数
很多知识库工具都提供自动切分，但自动切分不是万能。比较稳的策略是先按标题分段，再在段落过长时按自然段或列表拆分。每个 chunk 应该能独立回答一个小问题，同时保留上级标题和文件来源。
| 内容类型 | 切分方式 | 注意事项 |
|---|---|---|
| FAQ | 一问一答一个 chunk | 问题、答案、适用范围放在一起 |
| 流程文档 | 一个流程阶段一个 chunk | 不要把前置条件和结果切开 |
| 制度政策 | 按条款和标题切分 | 保留生效日期和适用对象 |
| 表格说明 | 字段说明和口径说明分开 | 原始Excel单独保存 |
不要忽略负面样本
好的 RAG 知识库不仅要回答“资料里有的内容”，还要知道“资料里没有的内容”。如果知识库找不到依据，应该提示无法确认，而不是凭常识补全。
元数据决定能不能治理
没有元数据的知识库，很快会变成一个黑箱。用户看到答案时，不知道它来自哪份石墨文档、是否过期、能否对外使用。最少应记录这些字段：
source_path：石墨原始路径或导出路径。document_title：可读文件名。owner：业务负责人或维护团队。updated_at：资料最后确认日期。permission_level：公开、内部、受限、敏感。version：资料包版本或文档版本。
即使你使用的是低代码知识库，也建议在文件名、目录或文档头部写入这些信息。后续出现错误回答时，排查速度会快很多。
Dify、RAGFlow、自建向量库怎么选？
如果团队只是验证“石墨资料能不能被 AI 问答”，Dify 这类低代码知识库上手更快。如果 PDF、表格、扫描件和复杂版式很多，可以评估 RAGFlow 这类强调文档解析和知识库配置的工具。如果涉及细粒度权限、审计、内部系统联动和大规模更新，就需要自建检索服务或在现有平台上做二次开发。
| 方案 | 适合阶段 | 石墨导出侧重点 |
|---|---|---|
| Dify知识库 | 快速验证、内部助手、客服FAQ | 清晰Markdown、稳定标题、少量精选资料 |
| RAGFlow | PDF和复杂文档较多的团队实验 | 保留PDF原件，同时准备Markdown摘要 |
| 自建向量库 | 企业级权限、审计、集成和大规模更新 | 完整元数据、变更清单、版本目录 |
团队空间资料进入AI前，先做好权限、脱敏、更新和回滚。
RAG 知识库上线前怎么验收？
验收不要只让同事随便问几个问题。应该准备固定问题集，每次资料更新后都跑一遍。至少覆盖四类问题：
- 事实型：某政策的生效日期、负责人、适用范围是什么。
- 流程型：遇到某种情况应该按什么步骤处理。
- 边界型：哪些情况不适用该流程。
- 反证型：资料中没有的信息，AI 是否会承认无法确认。
| 指标 | 要看什么 | 常见修复 |
|---|---|---|
| 检索命中率 | 正确来源是否进入前几条召回 | 调整切分、补标题、补元数据 |
| 引用准确率 | 答案引用是否真的支持结论 | 增加来源路径和回答约束 |
| 过期内容率 | 是否召回旧版资料 | 按版本过滤或移除旧文件 |
| 拒答质量 | 没有依据时是否停止编造 | 增加系统提示和负面样本 |
更新和回滚怎么做？
RAG 知识库不是一次性项目。客服政策、产品文档、研发规范都会变，石墨里的源文档也会变。建议每次更新都产出一个日期目录，保留原始导出、清洗后文件、导入记录和评测结果。
小团队可以每周或每月全量导出重建；文档量大时，应维护增量清单：新增、修改、废弃、权限变化。任何一次导入后，如果验收题明显变差，应能回滚到上一版资料包和上一版索引。
常见问题
RAG知识库为什么要先清洗石墨导出文件？
RAG检索依赖切分后的文本块。石墨导出文件如果有重复标题、空段落、过期资料和权限噪声，会让检索召回错误内容，导致 AI 回答不稳定。
石墨文档导出Markdown后可以直接进向量库吗？
可以作为第一版实验，但生产知识库建议先补元数据、统一标题、处理图片说明和表格摘要，再导入向量库。
RAG知识库里表格应该怎么处理？
小表格可以转成 Markdown 表格，大型业务表应保留 Excel 原件，并额外写字段说明、统计口径和常见问答，不建议把整张大表当普通段落切分。
Dify、RAGFlow 和自建向量库该怎么选？
快速验证可以从 Dify 这类低代码知识库开始；文档解析复杂、PDF 和表格很多时可以评估 RAGFlow；有权限、审计和系统集成要求时再考虑自建。
RAG知识库多久更新一次？
和业务变化频率有关。客服、政策、产品资料建议至少按周检查变更；稳定归档资料可按月或版本发布时更新。关键是保留上一版索引和资料包。
