这里写自定义目录标题欢迎使用Markdown编辑器引言为什么说数据集构建是 RAG 的第一生产力第一步文档解析决定后续所有环节的上限多格式输入的统一抽象PDF 解析的三大流派扫描件的 OCR 兜底第二步清洗把看起来能读变成检索起来能用清洗的四个维度清洗的自动化与人工复核第三步分块Chunking全流程中变量最大的一环固定长度切分为什么不够用结构化感知分块分块参数的实验方法论第四步嵌入与索引嵌入模型选型的现实考量混合检索别把宝全押在向量上第五步质量验证与持续迭代三个层次的评估数据飞轮我的几点额外思考结语新的改变功能快捷键合理的创建标题有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能丰富你的文章UML图表流程图FLowchart流程图导出与导入导出导入欢迎使用Markdown编辑器你好 这是你第一次使用# RAG 知识库数据集构建一份从文档到高质量语料的完整工程手册引言为什么说数据集构建是 RAG 的第一生产力过去两年里我接触了大量 RAG检索增强生成项目发现一个非常普遍的规律团队花在向量数据库选型、检索算法调优上的时间往往远多于花在数据本身上的时间。但最终的线上效果几乎总是由数据质量决定的而不是由检索参数决定的。你可以把 Embedding 模型换得更强可以把 Top-K 从 4 调到 8可以把 chunk 大小改来改去但如果语料本身是脏的、碎的、语义错位的这些调整统统是在错误的地基上盖楼。把原始文档变成可被检索、可被模型正确消费的高质量语料这中间隔着一条完整的流水线格式解析、内容清洗、结构识别、分块策略、嵌入与索引。每一环都有大量细节性的决策而这些决策几乎不存在放之四海皆准的标准答案只能根据业务场景反复实验。这篇文章不打算给出一个银弹而是把这条流水线上每个环节的决策要点、常用工具、常见坑和可行的验证方法完整梳理一遍希望它成为你搭建知识库时的工程手册。第一步文档解析决定后续所有环节的上限多格式输入的统一抽象企业知识库的文档来源几乎永远是异构的Word、PDF、PPT、Excel、Markdown、HTML、扫描件。第一步要做的不是为每种格式写一个专用函数然后各自为政而是抽象出一个统一的文档模型。实践中我倾向于把解析结果统一为结构化块列表每个块至少包含三个字段层级路径用于表达文档结构、文本内容、元数据来源文件、页码、章节标题等。后续的切分、过滤、嵌入都基于这个统一模型进行格式差异在入口处就被抹平这是工程上最重要的一步。PDF 解析的三大流派PDF 是最让人头疼的格式因为 PDF 本身只描述怎么画不描述是什么。目前主流方案大致分三类第一类是规则解析派代表是 PyMuPDF、pdfplumber 这类库。它们直接读取 PDF 的文本层和坐标信息速度快、对文本型 PDF 效果好但对复杂排版多栏、表格、页眉页脚混排容易输出错乱。我的经验是先用这一类做一遍命中率大约覆盖六成到七成的文档。第二类是版面分析派代表是 LayoutParser、以及各类基于深度学习的版面恢复模型。它们先做版面分割识别标题、正文、表格、图片区域再分别提取处理扫描件和复杂排版能力显著更强但依赖 GPU 或云端服务成本高、速度慢。第三类是端到端文档解析引擎代表是 Marker、MinerU、RAGFlow 内置的 DeepDoc。它们把版面分析、OCR、公式识别、表格还原串成一条完整的流水线输出结构化程度很高的 Markdown是目前构建高质量知识库的主流选择。特别是 MinerU 这类开源方案在中文文档上表现已经很能打。扫描件的 OCR 兜底如果文档是纯扫描件上面所有方案都会失效必须先过 OCR。Tesseract 免费但中文效果一般PaddleOCR 中文识别质量好、部署简单商业方案如腾讯、百度、阿里云的 OCR 服务在复杂表格和手写体上更强。一个务实的策略是优先用 PaddleOCR 自建满足不了再上云服务因为自建意味着数据不出域这在企业场景里往往比识别率更关键。第二步清洗把看起来能读变成检索起来能用清洗的四个维度很多人以为清洗就是把空格和换行去掉这远远不够。我建议从四个维度系统性检查语料噪声剔除页眉页脚、页码、水印、目录重复项、版本声明这些高频噪声必须去掉。页眉页脚尤其阴险它们会均匀地出现在每个 chunk 里检索时高频命中却毫无信息量稀释真正的答案。一个实用技巧是统计全文出现频率最高的 20 个短句手动检查一次通常就能把页眉页脚一网打尽。格式还原PDF 解析产生的段落断裂、表格被拆成碎片、连字符断词等问题需要用启发式规则修复。例如上一行结尾没有句号且下一行不是新段落起始就应当合并。这类规则看着笨但处理常见文档时收益极大。语义去重同一知识在多份文档中重复出现是常态。可以去嵌入向量做相似度聚类簇内保留最完整的一条。这一步对控制索引体积和减少检索歧义都很有帮助。敏感信息治理个人手机号、身份证号、内部接口地址、测试账号密码这类信息在入库前就要按策略脱敏或剔除。这不仅是合规要求也避免模型在生成时把敏感信息原样引用出去酿成事故。清洗的自动化与人工复核清洗规则写成管道脚本后一定要用抽样人工复核闭环。我的建议是每轮清洗后随机抽 200 个 chunk让业务方的人看一遍把这 chunk 读起来像不像人话当作用户验收标准。数据质量的验收必须由了解业务的人来做工程师只能保证规则被执行保证不了规则是否正确。第三步分块Chunking全流程中变量最大的一环固定长度切分为什么不够用最朴素的做法是固定字符数切分比如每 500 字一段、重叠 100 字。它能跑但效果上限很低。原因在于固定长度切分无视语义边界经常把一句话、一个表格、一段代码拦腰截断导致检索命中时上下文残缺模型拿着半截信息去回答幻觉率显著上升。结构化感知分块正确的思路是结构化感知优先尊重文档的自然语义单元。Markdown 按标题层级切HTML按标签层级切代码按函数边界切表格按行列语义切。LangChain 的 RecursiveCharacterTextSplitter 之所以流行是因为它用分隔符优先级列表先按段落、再按句子、最后按字符递归切分在简单场景下已经能逼近语义边界。对结构清晰的文档我推荐一条更激进的分块策略以二级标题为天然分块锚点标题正文作为一个大块超过上限再向下切。这样每个 chunk 自带章节语义检索时天然带上这是在讲什么主题的上下文配合元数据里的标题信息召回质量会有肉眼可见的提升。分块参数的实验方法论chunk 大小和重叠量没有标准答案但可以用一套可复现的实验方法来找准备一组与业务一致的测试问题至少 50 个每个带标准答案和答案所在的原始段落然后用不同参数组合跑检索比较答案所在段落是否进入 Top-K 上下文的命中率。不要凭感觉定参数数据会告诉你答案。实践经验上中文文档 300-800 字、重叠 50-150 字是一个比较稳妥的起点区间实际值随文档类型波动。第四步嵌入与索引嵌入模型选型的现实考量Embedding 模型的选型优先级我的排序是中文领域效果 维度与成本 榜单分数。很多团队迷信 MTEB 榜单但榜单任务分布和你的业务分布可能完全不一致。更务实的做法是拿你自己的 50 个测试问题在几个候选模型上各跑一遍召回率用业务数据投票。另外要注意维度差异带来的成本768 维和 1536 维的向量在千万级语料下存储和检索成本的差距是实打实的。混合检索别把宝全押在向量上向量检索擅长语义模糊匹配但精确匹配型号、编号、专有名词常常不如 BM25 关键词检索。成熟的 RAG 系统基本都走向量 关键词混合检索再配合 RRFReciprocal Rank Fusion融合排序。原因很好理解用户的查询往往同时包含语义意图和精确实体两种成分单一检索器很难两全。另一个常被忽略的点是重排Rerank模型先用粗排捞回 Top 50再用交叉编码器精排出 Top 5 喂给大模型这一层对最终答案质量的提升往往比换更强的 Embedding 模型更明显因为交叉编码器真正看到了 query 和 passage 的完整交互。第五步质量验证与持续迭代三个层次的评估建完索引不等于完事。我习惯把 RAG 数据质量验证拆成三层单层验证随机抽 chunk人工看切分是否完整、元数据是否正确。这层最便宜也最容易执行。检索层验证用测试问题集跑召回看答案所在文档/段落是否进入 Top-K。这层直接反映索引构建质量且不依赖生成模型问题定位清晰。端到端验证走完整问答链路看最终答案的准确率、完整率、忠实度是否忠于检索到的上下文。这层最接近用户体验但也最难定位问题出在检索还是生成。三层之间是递进关系哪一层不过就回到哪一层修不要跨层瞎调。数据飞轮知识库上线后要做持续更新把用户问过但答不好的问题沉淀下来人工标注正确答案回流到测试集和语料库。RAG 项目做得越久这套问题沉淀-标注-回流的飞轮就越值钱它比任何一次性调优都更能决定系统的长期表现。同时要建立语料版本管理每次数据变更可回滚、可对比评估避免改崩了不知道改坏了什么。我的几点额外思考第一RAG 的本质是用检索器对抗幻觉而检索器的能力边界由语料决定。与其花大力气调生成侧的 prompt不如先确认上下文里有没有正确答案——如果检索都捞不回来模型再聪明也无米下锅。这个认知顺序经常被团队搞反。第二GraphRAG、Agentic RAG 这类新范式解决的是复杂多跳问题和检索策略智能化但它们的底座依然是高质量的结构化语料。先把基础数据工程做扎实再谈架构升级这个顺序不能颠倒否则新架构只会放大旧数据的问题。第三很多团队把切分参数调优当成了数据工程的终点其实切分只是手段让检索命中正确的语义单元才是目的。与其在参数上反复横跳不如在文档结构梳理和元数据建设上多投入后者往往是投入产出比最高的环节。结语RAG 知识库建设说到底是把文档资产转化为可计算资产的过程。解析、清洗、切分、嵌入、索引、验证每一环都是决策点每一环的失误都会在下游放大。把数据集构建当成一等公民配以可复现的实验方法和持续迭代的飞轮机制你的 RAG 系统才真正有了稳定的地基。希望这份工程手册能帮你少走一些弯路把精力花在真正决定效果的地方。Markdown编辑器所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章了解一下Markdown的基本语法知识。新的改变我们对Markdown编辑器进行了一些功能拓展与语法支持除了标准的Markdown编辑器功能我们增加了如下几点新功能帮助你用它写博客全新的界面设计将会带来全新的写作体验在创作中心设置你喜爱的代码高亮样式Markdown将代码片显示选择的高亮样式进行展示增加了图片拖拽功能你可以将本地的图片直接拖拽到编辑区域直接展示全新的KaTeX数学公式语法增加了支持甘特图的mermaid语法1功能增加了多屏幕编辑Markdown文章功能增加了焦点写作模式、预览模式、简洁写作模式、左右区域同步滚轮设置等功能功能按钮位于编辑区域与预览区域中间增加了检查列表功能。功能快捷键撤销Ctrl/CommandZ重做Ctrl/CommandY加粗Ctrl/CommandB斜体Ctrl/CommandI标题Ctrl/CommandShiftH无序列表Ctrl/CommandShiftU有序列表Ctrl/CommandShiftO检查列表Ctrl/CommandShiftC插入代码Ctrl/CommandShiftK插入链接Ctrl/CommandShiftL插入图片Ctrl/CommandShiftG查找Ctrl/CommandF替换Ctrl/CommandG合理的创建标题有助于目录的生成直接输入1次#并按下space后将生成1级标题。输入2次#并按下space后将生成2级标题。以此类推我们支持6级标题。有助于使用TOC语法后生成一个完美的目录。如何改变文本的样式强调文本强调文本加粗文本加粗文本标记文本删除文本引用文本H2O is是液体。210运算结果是 1024.插入链接与图片链接: link.图片:带尺寸的图片:居中的图片:居中并且带尺寸的图片:当然我们为了让用户更加便捷我们增加了图片拖拽功能。如何插入一段漂亮的代码片去博客设置页面选择一款你喜欢的代码片高亮样式下面展示同样高亮的代码片.// An highlighted blockvarfoobar;生成一个适合你的列表项目项目项目项目1项目2项目3计划任务完成任务创建一个表格一个简单的表格是这么创建的项目Value电脑$1600手机$12导管$1设定内容居中、居左、居右使用:---------:居中使用:----------居左使用----------:居右第一列第二列第三列第一列文本居中第二列文本居右第三列文本居左SmartyPantsSmartyPants 是一个文本转换工具主要功能是将普通的 ASCII 标点符号自动转换为更美观的印刷体标点符号。例如原始符号转换后说明引号“引号”直引号变弯引号单引号‘单引号’直单引号变弯单引号--–两个连字符变短破折号---—三个连字符变长破折号...…三个点变省略号创建一个自定义列表MarkdownText-to-HTMLconversion toolAuthorsJohnLuke如何创建一个注脚一个具有注脚的文本。2注释也是必不可少的Markdown将文本转换为HTML。KaTeX数学公式您可以使用渲染LaTeX数学表达式 KaTeX:Gamma公式展示Γ ( n ) ( n − 1 ) ! ∀ n ∈ N \Gamma(n) (n-1)!\quad\forall n\in\mathbb NΓ(n)(n−1)!∀n∈N是通过欧拉积分Γ ( z ) ∫ 0 ∞ t z − 1 e − t d t . \Gamma(z) \int_0^\infty t^{z-1}e^{-t}dt\,.Γ(z)∫0∞​tz−1e−tdt.你可以找到更多关于的信息LaTeX数学表达式here.新的甘特图功能丰富你的文章2014-01-072014-01-092014-01-112014-01-132014-01-152014-01-172014-01-192014-01-21已完成进行中计划一计划二现有任务Adding GANTT diagram functionality to mermaid关于甘特图语法参考 这儿,UML图表可以使用UML图表进行渲染例如下面产生的一个序列图王五李四张三王五李四张三李四想了很长时间, 文字太长了不适合放在一行.你好李四, 最近怎么样?你最近怎么样王五我很好谢谢!我很好谢谢!打量着王五...很好... 王五, 你怎么样?关于UML图表语法参考 这儿,流程图链接长方形圆圆角长方形菱形关于Mermaid语法参考 这儿,FLowchart流程图我们依旧会支持flowchart.js的流程图语法Created with Raphaël 2.3.0开始我的操作确认结束yesno关于Flowchart流程图语法参考 这儿.导出与导入导出如果你想尝试使用此编辑器, 你可以在此篇文章任意编辑。当你完成了一篇文章的写作, 在上方工具栏找到文章导出生成一个.md文件或者.html文件进行本地保存。导入如果你想加载一篇你写过的.md文件在上方工具栏可以选择导入功能进行对应扩展名的文件导入继续你的创作。mermaid语法说明 ↩︎注脚的解释 ↩︎