文档加载怎么做：把 资料、网页和表格变成可检索资料

做 RAG 知识库时，很多人会把第一步说成“把资料传上去”。这个说法方便，但容易让人忽略真正的工作。文件上传只是把 资料、网页、表格或音频交给系统；文档加载要做的是把这些来源不同、格式不同、结构不同的资料，统一变成后续可以切分、向量化和检索的文本对象。

相关概念 在“使用 LangChain 访问个人数据”部分把这个流程放得很清楚：要让大模型使用自有数据，先要用文档加载器从不同数据源加载文档，然后再做切割、语义搜索、检索和问答。换句话说，加载是 RAG 的入口。入口处理得粗糙，后面的切分和检索会跟着吃亏。

现实里的资料很少规规矩矩。资料 可能有页眉页脚、目录、脚注和断行；网页可能夹着导航、脚本和评论区；表格里的每一行可能是一条商品资料，也可能只是某个字段；Notion 导出的 Markdown 会带层级和链接；音视频还要先转写成文本。文档加载的目标，就是先把这些东西变成一批可处理的 Document。

资料 资料里用 Py资料Loader 加载 资料 后，得到的 pages 是一个列表。列表里的每个元素都是 Document 类型。这个对象有两个关键部分：一个是 page_content，保存该页或该段的文本内容；另一个是 metadata，保存来源、页码等描述信息。这个设计很朴素，但对知识库很重要。

page_content 决定后面能不能被正确切分和检索。如果 资料 抽出来的文字断得很碎，或者表格内容顺序乱了，向量化时就会把混乱内容也一起编码进去。metadata 则决定以后能不能追溯来源。用户看到一个答案，如果系统能指出它来自哪份文件、哪一页、哪一行，可信度和可排查性都会高很多。

很多知识库上线后回答不稳，并不是向量库或模型出了神秘问题，而是加载阶段就丢了来源、页码、标题、版本这些信息。没有 metadata，后面即使召回了正确片段，也很难告诉用户依据在哪里；没有清楚的 page_content，模型拿到的上下文就像被拆散的纸条，读起来费劲，回答也容易漂。

资料 是最常见的知识库资料，但也是最容易出问题的来源。相关的页面布局是给人看的，不一定适合机器读取。教程里用 Py资料Loader 加载 资料，并展示每页的正文和 metadata。实际应用中还要额外看几件事：是否有扫描页，目录和页眉是否被混进正文，表格是否错位，章节标题是否还在。

CSV 或表格资料更像一行一条记录。示例里，CSVLoader 会把每一行变成一个 Document，并把 row 这样的信息放进 metadata。商品目录、FAQ、问题反馈、客服话术都适合这样处理。要注意的是，表格字段名不能丢。用户问“有没有防晒功能的衬衫”时，系统需要知道 name 是名称，description 是描述，否则一行数据只剩拼接文本，语义会变弱。

网页资料的麻烦在于噪声。教程里用 WebBaseLoader 加载网页后，原始 page_content 里包含大量 JSON 和页面结构信息，还需要再做进一步处理，才能提取真正的 Markdown 正文。这个例子很有提醒意义：网页能加载，不代表已经干净。进入知识库前，最好先把导航、侧边栏、脚本、评论、推荐区和无关 JSON 清掉。

Notion、语雀、飞书这类文档库的优势是本身有层级。教程里用 NotionDirectoryLoader 加载导出的 Markdown 文件，metadata 里保留了 source。做企业知识库时，不要把层级结构抹平。一级标题、二级标题、所属空间、文档路径，都应该尽量保留下来。后面切分时，标题会成为很好的语义边界。

有些资料不是文字，而是培训视频、会议录音、直播回放或课程音频。文中演示了一个 YouTube 音频加载流程：先用加载器把视频音频下载到本地，再用 OpenAI Whisper Parser 把音频转成文本，最后同样得到 Document。这个流程说明了一件事：RAG 的检索对象最终仍然要落到文本或可向量化内容上。

音视频资料进入知识库前，最好多做一步整理。自动转写会有口误、重复、断句、专有名词识别错误。会议里还可能有闲聊、寒暄、无效停顿。直接把转写文本入库，检索很可能命中一段口语噪声。更稳的做法是按主题或时间段整理摘要，保留时间戳，再把转写原文作为补充依据。

如果视频是教程或培训课，建议把章节标题、讲师、日期、课程名称、时间段放进 metadata。以后用户问某个操作怎么做，系统不但能回答，还能指向第几节、第几分钟附近。这样的知识库才像可查资料，而不是一大团转写文本。

文档加载完成后，不要急着向量化。先抽几条 Document 看看：正文是不是人能读懂，标题是否保留，页码是否正确，来源是否可追溯，是否有明显乱码和重复。这个检查很土，但很有用。资料对人都不清楚，对模型也不会稳定。

可以按来源各抽几条。资料 抽第一页、正文页、表格页和末页；CSV 抽几行长描述和短描述；网页抽正文开头和中间段；Notion 抽不同层级页面；音频抽转写开头、中段和结尾。重点看是否存在一类共性问题。如果 相关的每一页都有页眉，就在清洗阶段统一处理；如果网页总是带 JSON，就先写提取规则。

这一步也适合补 metadata。比如文档版本、所属部门、有效日期、权限等级、语言、产品线。RAG 系统后面经常需要按这些条件过滤资料。如果加载阶段没有保存，后面再补会很麻烦。尤其是企业知识库，权限和版本不能靠模型猜，应该在检索前由系统过滤。

第一版知识库不必支持所有格式。更现实的做法是先选两三类主要来源，比如 资料、Markdown 和 CSV，把加载规则做稳。每类资料都明确：用什么加载器，保留哪些 metadata，哪些内容要清洗，哪些内容不能入库，加载后如何抽样检查。

一个轻量标准可以这样定：每个 Document 必须有正文、来源、标题或路径、页码或行号、更新时间；正文中不保留页眉页脚、无关导航和重复版权声明；扫描 资料 要先 OCR；过期资料不进入默认索引；敏感资料要先分级。标准不需要很复杂，但要写下来，后面多人维护时才不会各做各的。

文档加载做好了，后面的切分才有基础。下一步讨论 chunk 大小、重叠、标题切分和 Markdown 结构时，都是在“文本已经干净、来源已经清楚”的前提下做选择。RAG 的第一道工序看起来不起眼，但它决定了知识库的地基是不是平的。