面经策

LangChain 中的 DocumentLoader 有哪些类型？如何选择？ ​

  • 标签：LangChain、DocumentLoader 文档加载

🏛 业务架构师 ​

LangChain 的 DocumentLoader 负责把各来源数据统一为 Document（内容+元数据）对象，类型按数据源分：

  • 文件类：PDF（含扫描件 OCR 变体）、Word、CSV、JSON、HTML、Markdown、图片（EXIF/描述）；
  • 在线内容：WebBaseLoader（网页抓取）、SitemapLoader、YouTube 字幕；
  • 协作工具：Confluence、Notion、飞书文档、Google Drive；
  • 数据系统：数据库（SQL）、Elasticsearch、消息队列；
  • 云存储：S3、Azure Blob 等。

怎么选，我按三个业务问题决策：

  1. 知识源在哪：先盘点企业知识资产分布（多数企业在 Confluence/飞书 + 文档库 + 数据库三处），按数据源选对应 Loader，多源用组合加载；
  2. 格式复杂度：PDF 是重灾区——原生 PDF 用标准 Loader，扫描件/复杂表格要升级解析方案（Unstructured、MinerU 或多模态模型抽取），普通 Loader 会丢表格；
  3. 更新模式：静态知识库一次性加载即可；持续更新的源（Confluence 每天新增）要配合增量同步机制（按修改时间拉取、变更触发重建索引）——Loader 选择要考虑它是否支持增量。

生产提醒：加载环节必须保留并补齐元数据（来源、部门、时间、权限标记）——这是后续检索过滤与合规的命根子；解析质量抽检要纳入流程，垃圾进垃圾出，Loader 阶段的 1% 错误到检索层就是 100% 的答非所问。

🏗 系统架构师 ​

LangChain DocumentLoader 我按数据源类型归类，选型看格式与规模：

类型谱系：

  • 本地文件类：TextLoader、CSVLoader、JSONLoader、UnstructuredFileLoader（多格式统一解析：PDF/Word/PPT/HTML/图片）；
  • Web 类：WebBaseLoader（网页抓取）、SitemapLoader、GitHubDocumentLoader；
  • 知识/协作工具类：Notion、Confluence、Slack、飞书等 SaaS 连接器；
  • 数据管道类：Airbyte、langchain 的 LlamaIndex 适配等大杂烩。

选型逻辑（架构师视角）：

  • 格式简单（txt/md/csv/json）：专用 Loader，轻量直接；
  • 复杂文档（PDF 表格/扫描件/多栏版式）：Unstructured 或 LlamaParse/视觉模型解析——解析质量决定 RAG 上限，值得在这里花钱（一个表格解析错，后面全链路调优白费）；按文档价值分级选用解析器（成本差 5~10 倍）；
  • 企业数据源：优先官方/社区连接器，注意增量同步能力（全量重灌 vs 变更检测）；
  • 大规模：Loader 只是读取层，重活在下游（解析/分块/嵌入的批处理管道）——用 Airflow/任务队列编排，Loader 换成分布式批任务，别指望 LangChain Loader 扛生产吞吐。

生产提醒：加载层要做幂等与断点（文档级去重、失败重试）；文档指纹（内容 hash）贯穿管道——同一文档重复加载不重复建索引；权限标签在加载时注入（检索层 pre-filter 的前提）。Loader 常被当作"简单小事"，实际是数据治理工程的入口。

💻 全栈开发专家 ​

DocumentLoader 按数据源分类（LangChain 生态有上百个，记类别不记清单）：

  • 文档类：PDF（PyMuPDFLoader/UnstructuredPDFLoader）、Word、PPT、Excel/CSV；
  • 网页类：WebBaseLoader（+trafilatura 正文抽取）、SitemapLoader、PlaywrightLoader（JS 渲染页）；
  • 结构化数据：Notion、飞书/Lark、Confluence、Google Drive、S3 目录；
  • 代码类：GitHub repo loader、按语言的 AST 切分；
  • 通用兜底：UnstructuredLoader（万能但解析质量对复杂版式一般）。

选择原则（按效果影响排序）：

  1. 解析质量优先于通用性：中文 PDF 复杂版式（表格、双栏）上 MinerU/Docling 类专业解析器远胜通用 loader——RAG 坏例里三成根因在解析，这一步值得花钱花时间；
  2. 格式保真：选能输出 Markdown/HTML 结构的 loader（表格不碎、标题层级保留），而不是纯文本流；
  3. 扫描件分流：PDF loader 识别为扫描版时走 OCR 管道（PaddleOCR）或 VLM 直读，普通 loader 出来是空的/乱码；
  4. 增量与权限：数据源对接要考虑增量同步（mtime/hash 比对）和权限继承（企业网盘的 ACL 映射到 chunk metadata）。
python
docs = UnstructuredMarkdownLoader("guide.md").load()
# 生产管道：类型路由 → 专用解析器 → 统一 Markdown 中间格式 → 清洗入库

架构建议：做一个「文档类型→loader」的路由配置，解析层与业务解耦——换解析器不动主流程。