很多人第一次做 LLM 应用时都习惯直接把 PDF 文件丢给大模型让模型“读”里面的内容。刚开始觉得挺顺利等到文件一多、格式一变、扫描件一出现问题就全冒出来了。其实 LLM 并不是一个 PDF 解析器它的任务是在“文本已经被正确提取”的前提下完成理解和生成。如果输入侧的数据本身就是乱的模型能力再强也无济于事。这篇文章想和你聊一个思路LLM Is Not a PDF Parser遇到 PDF 文件时先别急着往模型里塞先用 OpenDataLoader 这一类数据加载层把文件解析成干净、结构化、可检索的内容再交给 LLM。我会结合完整案例从环境准备、代码实现到常见报错排查一步步展开适合正在做 RAG、知识库问答、Agent 工具链的开发者也适合刚接触 LLM 应用开发的新手朋友。1. 为什么说“LLM Is Not a PDF Parser”1.1 LLM 被误用的场景先来看一个很常见的做法。业务部门给了一批 PDF 合同希望用大模型自动抽取关键字段。有的同学会直接把 PDF 二进制内容或转出来的文本一股脑塞给 Prompt甚至有人用工具把 PDF 转成图片后发给多模态模型让模型“看着办”。看起来模型确实能回答一些问题比如问“甲方是谁”模型能从文本上下文里猜出来。可一旦 PDF 是扫描件文本层不存在模型就只能靠 OCR 之后的文字来理解。而 OCR 的错字、分段混乱、表格错位都会直接影响模型的抽取结果。更关键的问题是PDF 本身不是一种面向文本阅读的格式。它更像一个“打印布局描述文件”记录的是页面上的坐标、字体、图像、路径。LLM 没有能力直接理解这种底层布局它只能处理字符串。所以在 LLM 和 PDF 之间必须有数据加载层负责格式转换。1.2 PDF 的结构复杂度很多人以为 PDF 就是一种“文档”用 CtrlA 复制出来就是文本。实际上 PDF 的内部结构远比想象中复杂纯文本型 PDF有文本对象可以用解析库直接提取。表格型 PDF文字和线条坐标交错直接提取会打乱阅读顺序。多栏 PDF左右两栏如果按坐标顺序提取第一栏和第二栏会交叉在一起。扫描型 PDF整个页面就是一张图片PDF 内部根本不存在文本层必须先 OCR。加密 PDF没有密码无法解析需要额外处理权限。填充表单型 PDF内容存储在表单字段中普通文本提取会遗漏。这些差异意味着PDF 解析不是一句“read_text()”就能解决的。选择什么策略取决于文件类型、内容版式和业务需要。1.3 直接让 LLM 解析 PDF 的四个隐患把未经处理的 PDF 直接交给 LLM 时通常会遇到四个问题。第一token 浪费严重。一个几十页的 PDF 转成文本后可能有几万甚至十几万 token而模型的上下文窗口是有限的。你为了把整份 PDF 塞进去可能不得不截断把重要的内容丢在后面。第二上下文窗口溢出。LLM 的上下文长度再长也经不住大批量文件的叠加。只要你的知识库稍微大一点就无法把全部 PDF 一次性塞进 Prompt。第三解析质量不稳定。PDF 文本提取顺序和 PDF 文件内部的 object 顺序有关。同一个 PDF 用不同解析库提取结果可能完全不同。如果不对提取结果做清洗LLM 会基于错误文本生成答案。第四幻觉概率上升。当文本断裂、表格错位、列值颠倒时LLM 会“脑补”出一些看起来合理但实际错误的信息。这对合同、报告、病历等严肃场景是非常危险的。1.4 正确分工先加载再理解所以我们要在架构上做一个明确分工加载层负责将 PDF、Word、Markdown、网页等原始文件转换为干净的文本或结构化 JSON。分块层负责把长文本切成合适的片段并保留标题、页码等元数据。向量化层负责将文本片段转换成向量。检索层根据用户问题召回最相关的片段。生成层由 LLM 基于召回结果组织最终答案。在这个链路里PDF 解析只属于加载层。LLM 应该坐在链路的最末端而不是最前面。OpenDataLoader First 这个说法的核心就是“数据加载优先”的工程理念。2. 认识 OpenDataLoader 与“数据加载优先”范式2.1 OpenDataLoader 是什么从名字上看OpenDataLoader 是一个面向 LLM 应用的数据加载器。它解决的核心问题是让各种格式的原始文件变成 LLM 可以理解、检索可以命中、程序可以处理的数据结构。在 LangChain、LlamaIndex 等生态中也有类似的 Loader 概念。不同之处在于OpenDataLoader 更强调“先加载再理解”的顺序。它不是要替代 LLM也不是简单的“PDF Reader”而是数据接入层的统一入口。在本文的示例中我会直接用 Python 实现一个简化版 OpenDataLoader用来演示这套思路。如果你在真实项目中已经引入了官方封装好的 OpenDataLoader 包只需要把下面代码里的读取函数替换成对应的 API 即可。核心思想是通用的。2.2 核心能力一个合格的 OpenDataLoader 至少需要具备以下能力文件类型识别根据扩展名或 MIME 判断是 PDF、Word、Markdown 还是 HTML。文本层提取从 PDF 中把 text object 读取出来。OCR 支持当页面没有文本层时可以调用 OCR 引擎识别图片文字。表格还原把表格区域识别出来尽量保持行和列关系。元数据保留记录文件名、页码范围、标题结构、创建时间等信息。输出格式统一无论输入是什么输出都统一为包含文本内容和元数据的对象。这样设计的好处是上游业务不需要关心文件格式下游 LLM 应用也不需要关心解析细节。所有格式差异都在加载层消化掉。2.3 与 LangChain、LlamaIndex 的分工你可能听说过 LangChain 和 LlamaIndex。它们和 OpenDataLoader 并不是对立关系而是分工不同。LangChain 是一套 LLM 应用开发框架它提供了很多文档加载器DocumentLoader比如 PyPDFLoader、UnstructuredPDFLoader。这些加载器的目标也是把 PDF 变成 Document 对象。LlamaIndex 更关注“数据索引与检索”它把加载、索引、查询整合在一起适合做知识库问答。OpenDataLoader First 的思路可以理解成在选框架之前先想清楚数据加载层怎么做。如果你们已经有自研的数据加载层LangChain 和 LlamaIndex 可以只负责链路的编排不需要重复实现解析逻辑。2.4 OpenDataLoader First 的典型流水线原始文件PDF / Word / HTML ↓ 1. 文件读取与格式识别 ↓ 2. 内容解析文本层 / OCR / 表格还原 ↓ 3. 数据清洗与结构化成 Document ↓ 4. 文本分块 ↓ 5. 向量化 ↓ 6. 存储进向量数据库 ↓ 7. LLM 基于检索结果生成回答在这个流程中第 1 到第 3 步就是 OpenDataLoader First 强调的部分。只有前面几步足够稳定后续的向量化和推理才有意义。3. 环境准备与项目初始化3.1 运行环境本文示例以 Python 3.9 以上版本为基础操作系统不限Windows、macOS、Linux 均可。建议使用虚拟环境管理项目依赖避免全局环境下出现包冲突。代码中会用到pypdf用于提取 PDF 文本层。pdfplumber用于更精细的文本、表格提取适合处理复杂版式。python-docx用于处理 Word 文档。langchain-text-splitters用于文本分块。sentence-transformers用于文本向量化。faiss-cpu用于本地向量检索。版本需要根据你的项目实际情况调整。本文重点演示的是工程思路不是锁定某个固定版本。3.2 创建项目结构先创建一个目录推荐按下面结构组织llm-pdf-loader-demo/ ├── data/ │ ├── sample.pdf │ └── sample.docx ├── src/ │ ├── __init__.py │ ├── loader/ │ │ ├── __init__.py │ │ ├── base.py │ │ └── pdf_loader.py │ ├── parser/ │ │ └── text_parser.py │ ├── chunker/ │ │ └── text_chunker.py │ └── vector/ │ ├── embedder.py │ └── vector_store.py ├── scripts/ │ └── build_kb.py └── requirements.txt这个结构把加载、解析、分块、向量化拆分成独立模块方便后续替换实现。3.3 安装依赖在项目根目录下创建虚拟环境并激活python -m venv venv source venv/bin/activateWindows 下激活命令是venv\Scripts\activate然后安装依赖pip install pypdf pdfplumber python-docx langchain-text-splitters sentence-transformers faiss-cpu如果你的网络环境拉取模型比较慢可以先不安装 sentence-transformers只测试 PDF 解析部分。3.4 准备测试 PDF在 data 目录放一份 sample.pdf。建议准备两种类型的 PDF 做对比一份是纯文字型 PDF比如从 Word 导出的文件。一份是扫描型 PDF比如用扫描仪生成的图片 PDF。纯文字型 PDF 可以直接提取文本层扫描型 PDF 则需要 OCR。后面我们会看到直接用 pypdf 提取扫描型 PDF 得到的是空字符串这正是我们需要警惕的坑。4. 用 OpenDataLoader 的思维完成 PDF 加载4.1 从文件系统读取第一步先定义一个统一的文档数据类。无论输入是 PDF 还是 DOCX最终都要变成这个结构。# src/loader/base.py from dataclasses import dataclass, field from typing import Dict, Any dataclass class Document: page_content: str metadata: Dict[str, Any] field(default_factorydict)这个类非常简单page_content 保存文本内容metadata 保存文件名、页码、来源等附加信息。后续的所有解析结果都会统一成这个类型。4.2 提取文本层下面实现一个用 pypdf 提取 PDF 文本的加载器。这里为了演示 OpenDataLoader 的思路我写成一个独立的类。# src/loader/pdf_loader.py from pypdf import PdfReader from pathlib import Path from typing import List from loader.base import Document class SimplePDFLoader: OpenDataLoader 风格的 PDF 加载器 def __init__(self, enable_ocr: bool False): self.enable_ocr enable_ocr def load(self, file_path: str) - List[Document]: file_path Path(file_path) if not file_path.exists(): raise FileNotFoundError(f文件不存在: {file_path}) reader PdfReader(str(file_path)) documents [] for page_number, page in enumerate(reader.pages, start1): text page.extract_text() or if not text.strip() and self.enable_ocr: # 这里可以接入 OCR 引擎 text self._ocr_page(file_path, page_number) print(f[OCR] 处理第 {page_number} 页) documents.append( Document( page_contenttext.strip(), metadata{ source: file_path.name, page: page_number, total_pages: len(reader.pages), }, ) ) return documents def _ocr_page(self, file_path: Path, page_number: int) - str: OCR 逻辑根据你的环境接入 PaddleOCR / Tesseract / 云服务 raise NotImplementedError(OCR 功能需要自行接入)解释几个关键点page.extract_text()返回的是 pypdf 提取出来的文本。如果是扫描件这里可能返回 None 或空字符串。enable_ocr参数控制是否启用 OCR。默认关闭因为 OCR 耗时较长。metadata 中保存了页码信息方便后续排查哪个页面出了问题。OCR 部分留出接口不同项目可以接不同的引擎。4.3 处理表格与多栏如果你的 PDF 中有表格单纯提取文本会把表格内容串成一行导致列顺序丢失。pdfplumber 对表格支持更好可以在加载器中增加表格提取逻辑。# src/loader/pdf_loader.py import pdfplumber def extract_with_pdfplumber(file_path: str): documents [] with pdfplumber.open(file_path) as pdf: for page_number, page in enumerate(pdf.pages, start1): text page.extract_text() or tables page.extract_tables() # 把表格转换成可读的结构化文本 table_text if tables: for table in tables: for row in table: row_text | .join([cell if cell else for cell in row]) table_text row_text \n combined_text text \n\n[表格内容]\n table_text documents.append( Document( page_contentcombined_text.strip(), metadata{source: file_path, page: page_number} ) ) return documents这段代码把表格的每一行用竖线拼接再加入文本之后。这样 LLM 在看到“合同编号 | 2024-001 | 甲方”至少能感知到列的边界。虽然不如原始表格完美但比直接一行挤在一起好很多。如果你遇到双栏 PDF可以使用 pdfplumber 的page.columns或page.crop功能先按栏切分再依次提取文本。这属于进阶场景在数据质量要求高时值得投入。4.4 输出结构化内容解析出来的 Document 对象需要序列化保存方便后续分块和向量化。推荐保存成 JSONL 格式每行一个 JSON 对象。# scripts/save_documents.py import json from pathlib import Path def save_documents(documents, output_path: str): output_path Path(output_path) output_path.parent.mkdir(parentsTrue, exist_okTrue) with open(output_path, w, encodingutf-8) as f: for doc in documents: line { page_content: doc.page_content, metadata: doc.metadata, } f.write(json.dumps(line, ensure_asciiFalse) \n)保存之后你可以用下面命令检查每页内容是否正常head -n 1 data/sample.jsonlJSONL 格式的好处是每行独立方便增量处理也方便与向量化工具对接。5. 完整实战基于 PDF 构建 RAG 问答管道这一节我们完成一个完整项目把 PDF 加载成结构化文本再分块、向量化最后让 LLM 基于检索结果回答问题。这是 LLM 应用开发中最常见的 RAG 场景。5.1 需求描述假设我们要做一个公司制度问答系统。制度文件是 PDF 格式用户会问“请假流程是什么”“报销需要哪些材料”。系统流程是加载 PDF。解析文本。分块。向量化并存入向量库。用户提问时先从向量库召回相关片段。将片段组装成上下文交给 LLM 生成答案。5.2 编写 PDF 加载模块我们已经实现了 SimplePDFLoader现在写一个统一的入口方便后续调用。# scripts/build_kb.py import sys from pathlib import Path sys.path.append(str(Path(__file__).resolve().parent.parent / src)) from loader.pdf_loader import SimplePDFLoader def load_all_pdfs(data_dir: str): loader SimplePDFLoader(enable_ocrFalse) all_documents [] for pdf_path in Path(data_dir).glob(*.pdf): print(f正在加载: {pdf_path}) docs loader.load(str(pdf_path)) all_documents.extend(docs) return all_documents if __name__ __main__: docs load_all_pdfs(data) print(f共加载 {len(docs)} 个页面)5.3 文本分块不分块直接向量化的后果是一个页面所有内容变成一个向量检索时语义容易被稀释。所以要把长文本切成有意义的块。# src/chunker/text_chunker.py from langchain_text_splitters import RecursiveCharacterTextSplitter def split_documents(documents, chunk_size500, chunk_overlap50): text_splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapchunk_overlap, separators[\n\n, \n, 。, , , , ], ) chunks [] for doc in documents: texts text_splitter.split_text(doc.page_content) for i, text in enumerate(texts): chunks.append({ text: text, metadata: { **doc.metadata, chunk_index: i, } }) return chunks这里使用了RecursiveCharacterTextSplitter它会优先按段落切分再按句子、标点逐层递归尽量保持语义完整。chunk_size 和 chunk_overlap 需要根据实际情况调整。一般建议 300 到 800 之间overlap 50 到 100。overlap 的作用是避免一个完整句子恰好被切到两个块的边界导致语义断裂。5.4 向量化与存储向量化使用 sentence-transformers 模型。不同模型向量维度不一样这里以常见的 all-MiniLM-L6-v2 为例输出 384 维向量。# src/vector/embedder.py from sentence_transformers import SentenceTransformer class Embedder: def __init__(self, model_name: str all-MiniLM-L6-v2): self.model SentenceTransformer(model_name) def embed_texts(self, texts): return self.model.encode(texts, normalize_embeddingsTrue)在中文场景下也可以换用其他开源 Embedding 模型或者调用线上 API。注意Embedding 模型和 LLM 模型是两回事Embedding 负责把文本变成向量LLM 负责解答问题。向量存储使用 FAISS 演示。FAISS 是 Facebook 开源的相似性搜索库适合本地演示。# src/vector/vector_store.py import faiss import numpy as np class FaissStore: def __init__(self, dimension: int): self.index faiss.IndexFlatIP(dimension) self.metadata [] def add(self, embeddings, metadata_list): self.index.add(np.array(embeddings)) self.metadata.extend(metadata_list) def search(self, query_embedding, top_k5): score, idx self.index.search(np.array([query_embedding]), top_k) results [] for score_val, idx_val in zip(score[0], idx[0]): if idx_val 0: results.append({ score: float(score_val), metadata: self.metadata[idx_val] }) return resultsIndexFlatIP 是内积索引配合 normalize_embeddingsTrue相当于余弦相似度。5.5 问答检索把整个流程串起来生成一个可以交互的问答脚本。# scripts/qa_demo.py import sys from pathlib import Path sys.path.append(str(Path(__file__).resolve().parent.parent / src)) from loader.pdf_loader import SimplePDFLoader from chunker.text_chunker import split_documents from vector.embedder import Embedder from vector.vector_store import FaissStore def build_index(data_dir: str): loader SimplePDFLoader() docs [] for pdf_path in Path(data_dir).glob(*.pdf): docs.extend(loader.load(str(pdf_path))) chunks split_documents(docs, chunk_size500, chunk_overlap50) texts [c[text] for c in chunks] metadata_list [c[metadata] for c in chunks] embedder Embedder() embeddings embedder.embed_texts(texts) store FaissStore(dimensionlen(embeddings[0])) store.add(embeddings, metadata_list) return embedder, store, texts def query(index_data, question: str): embedder, store, texts index_data q_vec embedder.embed_texts([question])[0] results store.search(q_vec, top_k3) context for r in results: idx next( (i for i, m in enumerate(store.metadata) if m r[metadata]), None ) # 简化处理实际建议在 metadata 中直接保存 chunk_id context r[metadata].get(source, ) 第 str(r[metadata].get(page, )) 页\n context texts[store.metadata.index(r[metadata])] \n\n return context if __name__ __main__: data build_index(data) question 请假流程是什么 context query(data, question) print(检索上下文\n, context)这里为了简化把 texts 和 metadata 直接对应。实际工程中最好为每个 chunk 分配唯一 ID避免用 index 定位带来混乱。最后一步是把 context 交给 LLM 生成答案。你可以使用 OpenAI API、Ollama、本地模型或者企业内部模型。下面是以 OpenAI API 风格为例的伪代码# 示意调用 LLM 生成答案 from openai import OpenAI client OpenAI() # 实际需要配置 base_url 和 api_key def generate_answer(question, context): prompt f请根据以下资料回答问题。 资料 {context} 问题{question} 要求答案要基于资料不能编造。如果资料中没有相关内容请明确说明。 response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一个知识库问答助手。}, {role: user, content: prompt} ] ) return response.choices[0].message.content如果你的项目使用 Ollama 接入本地模型只需要把 model 换成对应的模型名称并把 base_url 指向本机服务。5.6 运行验证运行构建脚本python scripts/build_kb.py预期输出正在加载: data/sample.pdf 共加载 12 个页面再运行问答脚本python scripts/qa_demo.py如果一切正常你会看到检索出来的上下文包含“请假流程”相关段落。如果检索结果不对优先检查 PDF 提取的文本质量而不是向量模型。6. 常见问题与排查思路PDF 加载和 LLM 应用结合时最容易出问题的地方集中在文本提取和分块。下面整理了几个高频问题。问题现象常见原因解决思路加载后文本为空扫描版 PDF 没有文本层开启 OCR 功能或使用带 OCR 的加载器中文出现乱码PDF 字体编码特殊pypdf 提取失败改用 pdfplumber、PyMuPDF或先 OCR表格内容顺序混乱表格行列结构在文本化后被拉平使用 pdfplumber extract_tables按行列拼接多栏文档左右串行提取顺序按页面坐标排列先按栏裁剪区域再分别提取大文件内存溢出整个 PDF 一次性加载按页流式处理限制同时读取的页数向量检索结果不相关分块过大导致语义稀释或 Embedding 模型不合适调整 chunk_size/overlap换用更合适的 Embedding 模型模型输出“资料里没有”检索上下文未命中正确内容检查 metadata、问答问题表达或增加 top_k下面展开几个重点问题。6.1 pypdf 提取为空如果你发现page.extract_text()返回空字符串不要急着调试代码先用 PDF 阅读器打开文件看能否选中文字。如果能选中文字说明是提取库的问题换 pdfplumber 或 PyMuPDF 试试。如果不能选中文字说明是扫描件必须 OCR。OCR 可以接入 PaddleOCR、Tesseract也可以使用云服务。需要注意OCR 的字符准确率直接决定后续结果建议在关键字段场景加入人工复核。6.2 中文乱码PDF 中的中文字体可能是嵌入子集也可能是自定义编码。pypdf 对某些字体的提取会得到乱码。解决方案# 使用 PyMuPDF 提取文本通常对中文更友好 import fitz def extract_with_fitz(file_path: str): doc fitz.open(file_path) for page in doc: text page.get_text() print(text)如果 PyMuPDF 仍然乱码可以考虑 OCR。乱码本质上是因为字体映射表缺失OCR 绕过字体层直接识别图像。6.3 表格丢失纯文本提取会把表格变成无序字符串。处理表格时建议分成两步先用 pdfplumber 的extract_tables()拿到结构化表格。再将表格转换成 Markdown 或 JSON 格式而不是简单拼接。import pdfplumber with pdfplumber.open(data/table.pdf) as pdf: page pdf.pages[0] table page.extract_table() if table: print(table)拿到二维数组后可以转成 Markdowndef table_to_markdown(table): header table[0] rows table[1:] md | | .join(header) |\n md | | .join([---] * len(header)) |\n for row in rows: md | | .join(row) |\n return md这样 LLM 理解结构化数据时效果远比一行切片好。6.4 大文件内存溢出几十页的 PDF 可以一次加载几百页的大文件就得注意内存。推荐按页读取处理完就释放。def load_large_pdf(file_path): reader PdfReader(file_path) for page in reader.pages: text page.extract_text() or # 处理单页 yield Document(page_contenttext, metadata{source: file_path})使用生成器可以避免一次性把所有页面文本放在内存里。但在向量化阶段你可能还是需要所有文本块这时可以把中间结果写入磁盘分批向量化。6.5 依赖冲突pypdf、pdfplumber、PyMuPDF 都可能依赖不同版本的typing_extensions或packaging一起安装时偶尔会冲突。建议在虚拟环境安装并使用 requirements.txt 锁定版本。如果已经出现冲突可以单独为某个解析库创建独立 venv通过外部命令调用而不是全部塞进同一个进程。7. 最佳实践与工程建议7.1 在加载层做数据质量检查很多 RAG 系统效果不好根因不在模型而在数据质量。建议在加载层加入检查项统计每个页面的字符数字符数为 0 的页面需要标注。记录解析耗时方便定位性能瓶颈。随机抽几页人工比对提取结果。可以写一个简单的质量报告def report_documents(documents): for doc in documents: page doc.metadata.get(page) source doc.metadata.get(source) length len(doc.page_content) print(f{source} 第{page}页 字符数: {length})7.2 元数据与溯源每一步处理都要保留来源信息。当 LLM 回答错误时我们要能追溯到底是从哪一页哪一段召回的错误信息。metadata 至少包括文件名页码chunk_index解析方式text/OCR/table处理时间在把上下文交给 LLM 时建议同时把来源一并展示给用户方便验证。7.3 按内容类型选择解析策略不同类型 PDF 适合不同解析策略内容类型推荐策略文字型合同pypdf / pdfplumber 提取文本财务表格报表pdfplumber extract_tables扫描书籍OCR 清洗杂志多栏排版按栏裁剪 顺序提取加密 PDF解密后再解析不要试图用一个万能解析器处理所有文件。先对文件类型做路由再用对应策略是工程化的做法。7.4 与 RAG/Agent 系统的集成在 Agent 场景中OpenDataLoader First 的思想同样适用。Agent 要“使用 PDF 工具”时不应该把 PDF 直接塞给模型而是先交给数据处理工具得到干净的文本或结构化数据再让模型做下一步。如果你在搭建 RAG 应用建议把加载器封装成独立的服务或模块避免在业务代码里到处写解析逻辑。这样后续切换解析库、增加 OCR、扩展支持格式时影响面会小很多。7.5 安全与合规PDF 文件中可能包含敏感信息比如合同价格、个人身份信息、内部报告。在处理这类文件时要注意只能在合法授权范围内使用文件。本地解析优先避免把敏感 PDF 直接上传到第三方 API。需要调用云 OCR 或云模型时先做脱敏和最小化传输。向量数据库中可能存储了敏感内容访问权限要做控制。日志中不要打印完整文档内容。安全边界不是上线后才考虑的事而是在设计加载链路时就要做好的基础约束。7.6 性能优化与缓存解析 PDF 是 IO 密集型操作重复构建知识库时同样的 PDF 会反复解析。建议在 metadata 中保存文件哈希值如果文件没有变化直接跳过解析。import hashlib def file_hash(path): with open(path, rb) as f: return hashlib.md5(f.read()).hexdigest()在向量化阶段可以提前将文本哈希后缓存向量避免重复调用 Embedding 接口节约成本。7.7 注意 LLM 精度与数据精度LLM 领域经常讨论 FP16、FP32、BF16 这些精度问题。它们会影响模型推理效率和输出质量。但有时候最终结果不准的问题并不是来自模型精度而是来自数据侧精度。PDF 提取时丢掉一个空格、表格列错位、OCR 把一个数字识别错都会让结果偏离真实。所以在纠结模型参数之前先确认数据加载层是否已经把信息完整、准确地保留下来。OpenDataLoader First 的字面意思就是这个顺序先保证加载质量再谈模型能力。8. 总结与进一步学习路线通过这篇文章我们把“LLM Is Not a PDF Parser”这个观点拆成了可落地的方法先使用 OpenDataLoader 这类数据加载器将 PDF 转成干净、结构化、带元数据的文本再完成分块、向量化、检索和问答。文章中的示例虽然以 PDF 为主但思路同样适用于 Word、Markdown、网页和扫描件。真正要记住的点有三个第一PDF 有很多形态不要假设它是纯文本。扫描件必须先 OCR表格要先还原结构多栏文档要按栏提取。第二加载层是 RAG 系统的地基。模型再强也无法从乱序、缺失、错位的文本中学到正确信息。把数据质量检查放在最前面能省掉后面大量排查时间。第三工程上要留好扩展位。文件格式会变解析库会更新业务会加需求。把加载、解析、分块、向量化拆成独立模块比写一个“万能脚本”更值得投入。下一步你可以继续深入学习这些方向熟悉 LangChain 和 LlamaIndex 的 Document Loader 机制与自研加载器做对比。尝试接入 OCR 引擎处理扫描版 PDF。研究不同 Embedding 模型在中文场景下的效果差异。学习向量数据库的索引原理比如 HNSW、IVF理解召回效果与性能的关系。在 Agent 应用中用同样的数据加载思路接入浏览器、Excel、数据库等知识源。如果你现在正好打算做知识库问答建议从一份真实 PDF 文件开始先把加载层跑通再逐步加入 OCR 和向量化。你会发现很多所谓“模型答不准”的问题其实是文件还没被正确打开而已。希望这篇实战笔记对你有帮助也欢迎在评论区分享你在 PDF 解析和 RAG 应用中踩过的坑。 LLM不是PDF解析器：用OpenDataLoader构建RAG数据加载层的实战指南
很多人第一次做 LLM 应用时都习惯直接把 PDF 文件丢给大模型让模型“读”里面的内容。刚开始觉得挺顺利等到文件一多、格式一变、扫描件一出现问题就全冒出来了。其实 LLM 并不是一个 PDF 解析器它的任务是在“文本已经被正确提取”的前提下完成理解和生成。如果输入侧的数据本身就是乱的模型能力再强也无济于事。这篇文章想和你聊一个思路LLM Is Not a PDF Parser遇到 PDF 文件时先别急着往模型里塞先用 OpenDataLoader 这一类数据加载层把文件解析成干净、结构化、可检索的内容再交给 LLM。我会结合完整案例从环境准备、代码实现到常见报错排查一步步展开适合正在做 RAG、知识库问答、Agent 工具链的开发者也适合刚接触 LLM 应用开发的新手朋友。1. 为什么说“LLM Is Not a PDF Parser”1.1 LLM 被误用的场景先来看一个很常见的做法。业务部门给了一批 PDF 合同希望用大模型自动抽取关键字段。有的同学会直接把 PDF 二进制内容或转出来的文本一股脑塞给 Prompt甚至有人用工具把 PDF 转成图片后发给多模态模型让模型“看着办”。看起来模型确实能回答一些问题比如问“甲方是谁”模型能从文本上下文里猜出来。可一旦 PDF 是扫描件文本层不存在模型就只能靠 OCR 之后的文字来理解。而 OCR 的错字、分段混乱、表格错位都会直接影响模型的抽取结果。更关键的问题是PDF 本身不是一种面向文本阅读的格式。它更像一个“打印布局描述文件”记录的是页面上的坐标、字体、图像、路径。LLM 没有能力直接理解这种底层布局它只能处理字符串。所以在 LLM 和 PDF 之间必须有数据加载层负责格式转换。1.2 PDF 的结构复杂度很多人以为 PDF 就是一种“文档”用 CtrlA 复制出来就是文本。实际上 PDF 的内部结构远比想象中复杂纯文本型 PDF有文本对象可以用解析库直接提取。表格型 PDF文字和线条坐标交错直接提取会打乱阅读顺序。多栏 PDF左右两栏如果按坐标顺序提取第一栏和第二栏会交叉在一起。扫描型 PDF整个页面就是一张图片PDF 内部根本不存在文本层必须先 OCR。加密 PDF没有密码无法解析需要额外处理权限。填充表单型 PDF内容存储在表单字段中普通文本提取会遗漏。这些差异意味着PDF 解析不是一句“read_text()”就能解决的。选择什么策略取决于文件类型、内容版式和业务需要。1.3 直接让 LLM 解析 PDF 的四个隐患把未经处理的 PDF 直接交给 LLM 时通常会遇到四个问题。第一token 浪费严重。一个几十页的 PDF 转成文本后可能有几万甚至十几万 token而模型的上下文窗口是有限的。你为了把整份 PDF 塞进去可能不得不截断把重要的内容丢在后面。第二上下文窗口溢出。LLM 的上下文长度再长也经不住大批量文件的叠加。只要你的知识库稍微大一点就无法把全部 PDF 一次性塞进 Prompt。第三解析质量不稳定。PDF 文本提取顺序和 PDF 文件内部的 object 顺序有关。同一个 PDF 用不同解析库提取结果可能完全不同。如果不对提取结果做清洗LLM 会基于错误文本生成答案。第四幻觉概率上升。当文本断裂、表格错位、列值颠倒时LLM 会“脑补”出一些看起来合理但实际错误的信息。这对合同、报告、病历等严肃场景是非常危险的。1.4 正确分工先加载再理解所以我们要在架构上做一个明确分工加载层负责将 PDF、Word、Markdown、网页等原始文件转换为干净的文本或结构化 JSON。分块层负责把长文本切成合适的片段并保留标题、页码等元数据。向量化层负责将文本片段转换成向量。检索层根据用户问题召回最相关的片段。生成层由 LLM 基于召回结果组织最终答案。在这个链路里PDF 解析只属于加载层。LLM 应该坐在链路的最末端而不是最前面。OpenDataLoader First 这个说法的核心就是“数据加载优先”的工程理念。2. 认识 OpenDataLoader 与“数据加载优先”范式2.1 OpenDataLoader 是什么从名字上看OpenDataLoader 是一个面向 LLM 应用的数据加载器。它解决的核心问题是让各种格式的原始文件变成 LLM 可以理解、检索可以命中、程序可以处理的数据结构。在 LangChain、LlamaIndex 等生态中也有类似的 Loader 概念。不同之处在于OpenDataLoader 更强调“先加载再理解”的顺序。它不是要替代 LLM也不是简单的“PDF Reader”而是数据接入层的统一入口。在本文的示例中我会直接用 Python 实现一个简化版 OpenDataLoader用来演示这套思路。如果你在真实项目中已经引入了官方封装好的 OpenDataLoader 包只需要把下面代码里的读取函数替换成对应的 API 即可。核心思想是通用的。2.2 核心能力一个合格的 OpenDataLoader 至少需要具备以下能力文件类型识别根据扩展名或 MIME 判断是 PDF、Word、Markdown 还是 HTML。文本层提取从 PDF 中把 text object 读取出来。OCR 支持当页面没有文本层时可以调用 OCR 引擎识别图片文字。表格还原把表格区域识别出来尽量保持行和列关系。元数据保留记录文件名、页码范围、标题结构、创建时间等信息。输出格式统一无论输入是什么输出都统一为包含文本内容和元数据的对象。这样设计的好处是上游业务不需要关心文件格式下游 LLM 应用也不需要关心解析细节。所有格式差异都在加载层消化掉。2.3 与 LangChain、LlamaIndex 的分工你可能听说过 LangChain 和 LlamaIndex。它们和 OpenDataLoader 并不是对立关系而是分工不同。LangChain 是一套 LLM 应用开发框架它提供了很多文档加载器DocumentLoader比如 PyPDFLoader、UnstructuredPDFLoader。这些加载器的目标也是把 PDF 变成 Document 对象。LlamaIndex 更关注“数据索引与检索”它把加载、索引、查询整合在一起适合做知识库问答。OpenDataLoader First 的思路可以理解成在选框架之前先想清楚数据加载层怎么做。如果你们已经有自研的数据加载层LangChain 和 LlamaIndex 可以只负责链路的编排不需要重复实现解析逻辑。2.4 OpenDataLoader First 的典型流水线原始文件PDF / Word / HTML ↓ 1. 文件读取与格式识别 ↓ 2. 内容解析文本层 / OCR / 表格还原 ↓ 3. 数据清洗与结构化成 Document ↓ 4. 文本分块 ↓ 5. 向量化 ↓ 6. 存储进向量数据库 ↓ 7. LLM 基于检索结果生成回答在这个流程中第 1 到第 3 步就是 OpenDataLoader First 强调的部分。只有前面几步足够稳定后续的向量化和推理才有意义。3. 环境准备与项目初始化3.1 运行环境本文示例以 Python 3.9 以上版本为基础操作系统不限Windows、macOS、Linux 均可。建议使用虚拟环境管理项目依赖避免全局环境下出现包冲突。代码中会用到pypdf用于提取 PDF 文本层。pdfplumber用于更精细的文本、表格提取适合处理复杂版式。python-docx用于处理 Word 文档。langchain-text-splitters用于文本分块。sentence-transformers用于文本向量化。faiss-cpu用于本地向量检索。版本需要根据你的项目实际情况调整。本文重点演示的是工程思路不是锁定某个固定版本。3.2 创建项目结构先创建一个目录推荐按下面结构组织llm-pdf-loader-demo/ ├── data/ │ ├── sample.pdf │ └── sample.docx ├── src/ │ ├── __init__.py │ ├── loader/ │ │ ├── __init__.py │ │ ├── base.py │ │ └── pdf_loader.py │ ├── parser/ │ │ └── text_parser.py │ ├── chunker/ │ │ └── text_chunker.py │ └── vector/ │ ├── embedder.py │ └── vector_store.py ├── scripts/ │ └── build_kb.py └── requirements.txt这个结构把加载、解析、分块、向量化拆分成独立模块方便后续替换实现。3.3 安装依赖在项目根目录下创建虚拟环境并激活python -m venv venv source venv/bin/activateWindows 下激活命令是venv\Scripts\activate然后安装依赖pip install pypdf pdfplumber python-docx langchain-text-splitters sentence-transformers faiss-cpu如果你的网络环境拉取模型比较慢可以先不安装 sentence-transformers只测试 PDF 解析部分。3.4 准备测试 PDF在 data 目录放一份 sample.pdf。建议准备两种类型的 PDF 做对比一份是纯文字型 PDF比如从 Word 导出的文件。一份是扫描型 PDF比如用扫描仪生成的图片 PDF。纯文字型 PDF 可以直接提取文本层扫描型 PDF 则需要 OCR。后面我们会看到直接用 pypdf 提取扫描型 PDF 得到的是空字符串这正是我们需要警惕的坑。4. 用 OpenDataLoader 的思维完成 PDF 加载4.1 从文件系统读取第一步先定义一个统一的文档数据类。无论输入是 PDF 还是 DOCX最终都要变成这个结构。# src/loader/base.py from dataclasses import dataclass, field from typing import Dict, Any dataclass class Document: page_content: str metadata: Dict[str, Any] field(default_factorydict)这个类非常简单page_content 保存文本内容metadata 保存文件名、页码、来源等附加信息。后续的所有解析结果都会统一成这个类型。4.2 提取文本层下面实现一个用 pypdf 提取 PDF 文本的加载器。这里为了演示 OpenDataLoader 的思路我写成一个独立的类。# src/loader/pdf_loader.py from pypdf import PdfReader from pathlib import Path from typing import List from loader.base import Document class SimplePDFLoader: OpenDataLoader 风格的 PDF 加载器 def __init__(self, enable_ocr: bool False): self.enable_ocr enable_ocr def load(self, file_path: str) - List[Document]: file_path Path(file_path) if not file_path.exists(): raise FileNotFoundError(f文件不存在: {file_path}) reader PdfReader(str(file_path)) documents [] for page_number, page in enumerate(reader.pages, start1): text page.extract_text() or if not text.strip() and self.enable_ocr: # 这里可以接入 OCR 引擎 text self._ocr_page(file_path, page_number) print(f[OCR] 处理第 {page_number} 页) documents.append( Document( page_contenttext.strip(), metadata{ source: file_path.name, page: page_number, total_pages: len(reader.pages), }, ) ) return documents def _ocr_page(self, file_path: Path, page_number: int) - str: OCR 逻辑根据你的环境接入 PaddleOCR / Tesseract / 云服务 raise NotImplementedError(OCR 功能需要自行接入)解释几个关键点page.extract_text()返回的是 pypdf 提取出来的文本。如果是扫描件这里可能返回 None 或空字符串。enable_ocr参数控制是否启用 OCR。默认关闭因为 OCR 耗时较长。metadata 中保存了页码信息方便后续排查哪个页面出了问题。OCR 部分留出接口不同项目可以接不同的引擎。4.3 处理表格与多栏如果你的 PDF 中有表格单纯提取文本会把表格内容串成一行导致列顺序丢失。pdfplumber 对表格支持更好可以在加载器中增加表格提取逻辑。# src/loader/pdf_loader.py import pdfplumber def extract_with_pdfplumber(file_path: str): documents [] with pdfplumber.open(file_path) as pdf: for page_number, page in enumerate(pdf.pages, start1): text page.extract_text() or tables page.extract_tables() # 把表格转换成可读的结构化文本 table_text if tables: for table in tables: for row in table: row_text | .join([cell if cell else for cell in row]) table_text row_text \n combined_text text \n\n[表格内容]\n table_text documents.append( Document( page_contentcombined_text.strip(), metadata{source: file_path, page: page_number} ) ) return documents这段代码把表格的每一行用竖线拼接再加入文本之后。这样 LLM 在看到“合同编号 | 2024-001 | 甲方”至少能感知到列的边界。虽然不如原始表格完美但比直接一行挤在一起好很多。如果你遇到双栏 PDF可以使用 pdfplumber 的page.columns或page.crop功能先按栏切分再依次提取文本。这属于进阶场景在数据质量要求高时值得投入。4.4 输出结构化内容解析出来的 Document 对象需要序列化保存方便后续分块和向量化。推荐保存成 JSONL 格式每行一个 JSON 对象。# scripts/save_documents.py import json from pathlib import Path def save_documents(documents, output_path: str): output_path Path(output_path) output_path.parent.mkdir(parentsTrue, exist_okTrue) with open(output_path, w, encodingutf-8) as f: for doc in documents: line { page_content: doc.page_content, metadata: doc.metadata, } f.write(json.dumps(line, ensure_asciiFalse) \n)保存之后你可以用下面命令检查每页内容是否正常head -n 1 data/sample.jsonlJSONL 格式的好处是每行独立方便增量处理也方便与向量化工具对接。5. 完整实战基于 PDF 构建 RAG 问答管道这一节我们完成一个完整项目把 PDF 加载成结构化文本再分块、向量化最后让 LLM 基于检索结果回答问题。这是 LLM 应用开发中最常见的 RAG 场景。5.1 需求描述假设我们要做一个公司制度问答系统。制度文件是 PDF 格式用户会问“请假流程是什么”“报销需要哪些材料”。系统流程是加载 PDF。解析文本。分块。向量化并存入向量库。用户提问时先从向量库召回相关片段。将片段组装成上下文交给 LLM 生成答案。5.2 编写 PDF 加载模块我们已经实现了 SimplePDFLoader现在写一个统一的入口方便后续调用。# scripts/build_kb.py import sys from pathlib import Path sys.path.append(str(Path(__file__).resolve().parent.parent / src)) from loader.pdf_loader import SimplePDFLoader def load_all_pdfs(data_dir: str): loader SimplePDFLoader(enable_ocrFalse) all_documents [] for pdf_path in Path(data_dir).glob(*.pdf): print(f正在加载: {pdf_path}) docs loader.load(str(pdf_path)) all_documents.extend(docs) return all_documents if __name__ __main__: docs load_all_pdfs(data) print(f共加载 {len(docs)} 个页面)5.3 文本分块不分块直接向量化的后果是一个页面所有内容变成一个向量检索时语义容易被稀释。所以要把长文本切成有意义的块。# src/chunker/text_chunker.py from langchain_text_splitters import RecursiveCharacterTextSplitter def split_documents(documents, chunk_size500, chunk_overlap50): text_splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapchunk_overlap, separators[\n\n, \n, 。, , , , ], ) chunks [] for doc in documents: texts text_splitter.split_text(doc.page_content) for i, text in enumerate(texts): chunks.append({ text: text, metadata: { **doc.metadata, chunk_index: i, } }) return chunks这里使用了RecursiveCharacterTextSplitter它会优先按段落切分再按句子、标点逐层递归尽量保持语义完整。chunk_size 和 chunk_overlap 需要根据实际情况调整。一般建议 300 到 800 之间overlap 50 到 100。overlap 的作用是避免一个完整句子恰好被切到两个块的边界导致语义断裂。5.4 向量化与存储向量化使用 sentence-transformers 模型。不同模型向量维度不一样这里以常见的 all-MiniLM-L6-v2 为例输出 384 维向量。# src/vector/embedder.py from sentence_transformers import SentenceTransformer class Embedder: def __init__(self, model_name: str all-MiniLM-L6-v2): self.model SentenceTransformer(model_name) def embed_texts(self, texts): return self.model.encode(texts, normalize_embeddingsTrue)在中文场景下也可以换用其他开源 Embedding 模型或者调用线上 API。注意Embedding 模型和 LLM 模型是两回事Embedding 负责把文本变成向量LLM 负责解答问题。向量存储使用 FAISS 演示。FAISS 是 Facebook 开源的相似性搜索库适合本地演示。# src/vector/vector_store.py import faiss import numpy as np class FaissStore: def __init__(self, dimension: int): self.index faiss.IndexFlatIP(dimension) self.metadata [] def add(self, embeddings, metadata_list): self.index.add(np.array(embeddings)) self.metadata.extend(metadata_list) def search(self, query_embedding, top_k5): score, idx self.index.search(np.array([query_embedding]), top_k) results [] for score_val, idx_val in zip(score[0], idx[0]): if idx_val 0: results.append({ score: float(score_val), metadata: self.metadata[idx_val] }) return resultsIndexFlatIP 是内积索引配合 normalize_embeddingsTrue相当于余弦相似度。5.5 问答检索把整个流程串起来生成一个可以交互的问答脚本。# scripts/qa_demo.py import sys from pathlib import Path sys.path.append(str(Path(__file__).resolve().parent.parent / src)) from loader.pdf_loader import SimplePDFLoader from chunker.text_chunker import split_documents from vector.embedder import Embedder from vector.vector_store import FaissStore def build_index(data_dir: str): loader SimplePDFLoader() docs [] for pdf_path in Path(data_dir).glob(*.pdf): docs.extend(loader.load(str(pdf_path))) chunks split_documents(docs, chunk_size500, chunk_overlap50) texts [c[text] for c in chunks] metadata_list [c[metadata] for c in chunks] embedder Embedder() embeddings embedder.embed_texts(texts) store FaissStore(dimensionlen(embeddings[0])) store.add(embeddings, metadata_list) return embedder, store, texts def query(index_data, question: str): embedder, store, texts index_data q_vec embedder.embed_texts([question])[0] results store.search(q_vec, top_k3) context for r in results: idx next( (i for i, m in enumerate(store.metadata) if m r[metadata]), None ) # 简化处理实际建议在 metadata 中直接保存 chunk_id context r[metadata].get(source, ) 第 str(r[metadata].get(page, )) 页\n context texts[store.metadata.index(r[metadata])] \n\n return context if __name__ __main__: data build_index(data) question 请假流程是什么 context query(data, question) print(检索上下文\n, context)这里为了简化把 texts 和 metadata 直接对应。实际工程中最好为每个 chunk 分配唯一 ID避免用 index 定位带来混乱。最后一步是把 context 交给 LLM 生成答案。你可以使用 OpenAI API、Ollama、本地模型或者企业内部模型。下面是以 OpenAI API 风格为例的伪代码# 示意调用 LLM 生成答案 from openai import OpenAI client OpenAI() # 实际需要配置 base_url 和 api_key def generate_answer(question, context): prompt f请根据以下资料回答问题。 资料 {context} 问题{question} 要求答案要基于资料不能编造。如果资料中没有相关内容请明确说明。 response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一个知识库问答助手。}, {role: user, content: prompt} ] ) return response.choices[0].message.content如果你的项目使用 Ollama 接入本地模型只需要把 model 换成对应的模型名称并把 base_url 指向本机服务。5.6 运行验证运行构建脚本python scripts/build_kb.py预期输出正在加载: data/sample.pdf 共加载 12 个页面再运行问答脚本python scripts/qa_demo.py如果一切正常你会看到检索出来的上下文包含“请假流程”相关段落。如果检索结果不对优先检查 PDF 提取的文本质量而不是向量模型。6. 常见问题与排查思路PDF 加载和 LLM 应用结合时最容易出问题的地方集中在文本提取和分块。下面整理了几个高频问题。问题现象常见原因解决思路加载后文本为空扫描版 PDF 没有文本层开启 OCR 功能或使用带 OCR 的加载器中文出现乱码PDF 字体编码特殊pypdf 提取失败改用 pdfplumber、PyMuPDF或先 OCR表格内容顺序混乱表格行列结构在文本化后被拉平使用 pdfplumber extract_tables按行列拼接多栏文档左右串行提取顺序按页面坐标排列先按栏裁剪区域再分别提取大文件内存溢出整个 PDF 一次性加载按页流式处理限制同时读取的页数向量检索结果不相关分块过大导致语义稀释或 Embedding 模型不合适调整 chunk_size/overlap换用更合适的 Embedding 模型模型输出“资料里没有”检索上下文未命中正确内容检查 metadata、问答问题表达或增加 top_k下面展开几个重点问题。6.1 pypdf 提取为空如果你发现page.extract_text()返回空字符串不要急着调试代码先用 PDF 阅读器打开文件看能否选中文字。如果能选中文字说明是提取库的问题换 pdfplumber 或 PyMuPDF 试试。如果不能选中文字说明是扫描件必须 OCR。OCR 可以接入 PaddleOCR、Tesseract也可以使用云服务。需要注意OCR 的字符准确率直接决定后续结果建议在关键字段场景加入人工复核。6.2 中文乱码PDF 中的中文字体可能是嵌入子集也可能是自定义编码。pypdf 对某些字体的提取会得到乱码。解决方案# 使用 PyMuPDF 提取文本通常对中文更友好 import fitz def extract_with_fitz(file_path: str): doc fitz.open(file_path) for page in doc: text page.get_text() print(text)如果 PyMuPDF 仍然乱码可以考虑 OCR。乱码本质上是因为字体映射表缺失OCR 绕过字体层直接识别图像。6.3 表格丢失纯文本提取会把表格变成无序字符串。处理表格时建议分成两步先用 pdfplumber 的extract_tables()拿到结构化表格。再将表格转换成 Markdown 或 JSON 格式而不是简单拼接。import pdfplumber with pdfplumber.open(data/table.pdf) as pdf: page pdf.pages[0] table page.extract_table() if table: print(table)拿到二维数组后可以转成 Markdowndef table_to_markdown(table): header table[0] rows table[1:] md | | .join(header) |\n md | | .join([---] * len(header)) |\n for row in rows: md | | .join(row) |\n return md这样 LLM 理解结构化数据时效果远比一行切片好。6.4 大文件内存溢出几十页的 PDF 可以一次加载几百页的大文件就得注意内存。推荐按页读取处理完就释放。def load_large_pdf(file_path): reader PdfReader(file_path) for page in reader.pages: text page.extract_text() or # 处理单页 yield Document(page_contenttext, metadata{source: file_path})使用生成器可以避免一次性把所有页面文本放在内存里。但在向量化阶段你可能还是需要所有文本块这时可以把中间结果写入磁盘分批向量化。6.5 依赖冲突pypdf、pdfplumber、PyMuPDF 都可能依赖不同版本的typing_extensions或packaging一起安装时偶尔会冲突。建议在虚拟环境安装并使用 requirements.txt 锁定版本。如果已经出现冲突可以单独为某个解析库创建独立 venv通过外部命令调用而不是全部塞进同一个进程。7. 最佳实践与工程建议7.1 在加载层做数据质量检查很多 RAG 系统效果不好根因不在模型而在数据质量。建议在加载层加入检查项统计每个页面的字符数字符数为 0 的页面需要标注。记录解析耗时方便定位性能瓶颈。随机抽几页人工比对提取结果。可以写一个简单的质量报告def report_documents(documents): for doc in documents: page doc.metadata.get(page) source doc.metadata.get(source) length len(doc.page_content) print(f{source} 第{page}页 字符数: {length})7.2 元数据与溯源每一步处理都要保留来源信息。当 LLM 回答错误时我们要能追溯到底是从哪一页哪一段召回的错误信息。metadata 至少包括文件名页码chunk_index解析方式text/OCR/table处理时间在把上下文交给 LLM 时建议同时把来源一并展示给用户方便验证。7.3 按内容类型选择解析策略不同类型 PDF 适合不同解析策略内容类型推荐策略文字型合同pypdf / pdfplumber 提取文本财务表格报表pdfplumber extract_tables扫描书籍OCR 清洗杂志多栏排版按栏裁剪 顺序提取加密 PDF解密后再解析不要试图用一个万能解析器处理所有文件。先对文件类型做路由再用对应策略是工程化的做法。7.4 与 RAG/Agent 系统的集成在 Agent 场景中OpenDataLoader First 的思想同样适用。Agent 要“使用 PDF 工具”时不应该把 PDF 直接塞给模型而是先交给数据处理工具得到干净的文本或结构化数据再让模型做下一步。如果你在搭建 RAG 应用建议把加载器封装成独立的服务或模块避免在业务代码里到处写解析逻辑。这样后续切换解析库、增加 OCR、扩展支持格式时影响面会小很多。7.5 安全与合规PDF 文件中可能包含敏感信息比如合同价格、个人身份信息、内部报告。在处理这类文件时要注意只能在合法授权范围内使用文件。本地解析优先避免把敏感 PDF 直接上传到第三方 API。需要调用云 OCR 或云模型时先做脱敏和最小化传输。向量数据库中可能存储了敏感内容访问权限要做控制。日志中不要打印完整文档内容。安全边界不是上线后才考虑的事而是在设计加载链路时就要做好的基础约束。7.6 性能优化与缓存解析 PDF 是 IO 密集型操作重复构建知识库时同样的 PDF 会反复解析。建议在 metadata 中保存文件哈希值如果文件没有变化直接跳过解析。import hashlib def file_hash(path): with open(path, rb) as f: return hashlib.md5(f.read()).hexdigest()在向量化阶段可以提前将文本哈希后缓存向量避免重复调用 Embedding 接口节约成本。7.7 注意 LLM 精度与数据精度LLM 领域经常讨论 FP16、FP32、BF16 这些精度问题。它们会影响模型推理效率和输出质量。但有时候最终结果不准的问题并不是来自模型精度而是来自数据侧精度。PDF 提取时丢掉一个空格、表格列错位、OCR 把一个数字识别错都会让结果偏离真实。所以在纠结模型参数之前先确认数据加载层是否已经把信息完整、准确地保留下来。OpenDataLoader First 的字面意思就是这个顺序先保证加载质量再谈模型能力。8. 总结与进一步学习路线通过这篇文章我们把“LLM Is Not a PDF Parser”这个观点拆成了可落地的方法先使用 OpenDataLoader 这类数据加载器将 PDF 转成干净、结构化、带元数据的文本再完成分块、向量化、检索和问答。文章中的示例虽然以 PDF 为主但思路同样适用于 Word、Markdown、网页和扫描件。真正要记住的点有三个第一PDF 有很多形态不要假设它是纯文本。扫描件必须先 OCR表格要先还原结构多栏文档要按栏提取。第二加载层是 RAG 系统的地基。模型再强也无法从乱序、缺失、错位的文本中学到正确信息。把数据质量检查放在最前面能省掉后面大量排查时间。第三工程上要留好扩展位。文件格式会变解析库会更新业务会加需求。把加载、解析、分块、向量化拆成独立模块比写一个“万能脚本”更值得投入。下一步你可以继续深入学习这些方向熟悉 LangChain 和 LlamaIndex 的 Document Loader 机制与自研加载器做对比。尝试接入 OCR 引擎处理扫描版 PDF。研究不同 Embedding 模型在中文场景下的效果差异。学习向量数据库的索引原理比如 HNSW、IVF理解召回效果与性能的关系。在 Agent 应用中用同样的数据加载思路接入浏览器、Excel、数据库等知识源。如果你现在正好打算做知识库问答建议从一份真实 PDF 文件开始先把加载层跑通再逐步加入 OCR 和向量化。你会发现很多所谓“模型答不准”的问题其实是文件还没被正确打开而已。希望这篇实战笔记对你有帮助也欢迎在评论区分享你在 PDF 解析和 RAG 应用中踩过的坑。