企业官网建设流程全解析

做RAG（检索增强生成）知识库的，十有八九都在PDF上栽过跟头。明明用的是当前主流的框架，喂进去的也是正经文档，可一问细节就翻车，不是答非所问，就是一本正经地编。我做了几个企业的知识库项目之后发现，问题往往出在最前面那一层——PDF文档解析。这篇把PDF解析拆成三层来讲：第一层解决“抽文本”，第二层解决“识结构”，第三层解决“可检索”。不管你是正在做企业知识库、智能问答，还是刚接触RAG准备搭第一个demo，这套思路都值得花点时间看完。

1. 为什么要把PDF解析拆成三层来做

1.1 直接"全文入库"为什么会翻车

先说一个最常见的现象：不少人拿到PDF，不管三七二十一，把整篇文档转成字符串，调一下切块参数就塞进向量库。跑起来看似没问题，真正一问细节就露馅，答案找不到、上下文对不上、表格数据全乱。本质原因是，PDF本身就是“给人看的”，不是“给模型用的”数据格式。PDF内部记录的是文字、图形和坐标，它不保证段落之间有严格的逻辑关系，也没有语义顺序，甚至不保证你能按视觉阅读顺序把文字读出来。

另外，embedding模型对输入长度有上限，文本越长，向量语义表达越容易被稀释。把三五十页的文档整篇编码，得到的向量就像一锅大杂烩，谈不上精确定位。现在你应该明白了，直接“全文进库”相当于把“文档理解”这件事完全甩给模型，模型当然搞不定。

1.2 三层各自的定位与分工

我讲的“三层”，不是网络里常说的三层交换机，也不是MVC软件架构里的那三层，而是按数据处理深度拆出来的三层：

• L1 文本层（Text Layer）：把PDF里的字符、内容完整提取出来，做到“抽得准、抽得全”。
• L2 结构层（Structure Layer）：识别文档的标题层级、段落边界、表格、列表等结构，把纯文本变成有组织的文档。
• L3 应用层（Application Layer）：根据语义和检索需求做切块、加元数据、向量化、召回，让文档真正能被RAG系统使用。

可以用一个生活化的类比来理解：处理一栋楼，先要把砖、水泥、钢筋这些材料准确拆出来（L1），再搞清楚哪些是承重墙、哪些是框架、哪些是隔断（L2），最后才能根据户型图去设计水路电路（L3）。少了任何一步，后面的工作都会很被动。

1.3 这个分层思路适合用到哪里

我实际用下来的感受是，凡是文档形式比较复杂、内容比较正式的RAG场景，都需要这套思路。比如企业制度问答、产品手册问答、研究报告分析、技术文档智能客服。反过来，如果是几十行的小文档、临时测试用的一段话，直接用最简单的切块也能凑合，没有必要套这么多层。所以这个分层不是为了炫技，是为了让数据加工过程可控、可追踪、可优化。你遇到了问题，能知道该去哪个环节排查，而不是对着黑盒干瞪眼。

2. 第一层实战：把PDF变成干净的纯文本

2.1 文本抽取工具选型：PyMuPDF为什么是首选

提取PDF文本的第一选择，我强烈建议PyMuPDF，也就是Python里的fitz。它支持的文件类型全，运行速度快，在普通笔记本上解析一份几十页的PDF通常只要一两秒。pdfplumber虽然也常用，但速度慢一个量级，更适合处理表格这类需要精细坐标信息的任务。pypdf的抽取能力比较弱，遇到复杂版面容易乱。简单对比一下：

如果你处理的PDF很多，批量任务跑一晚上，PyMuPDF和pdfplumber的耗时差距会非常明显。所以我的默认选择是PyMuPDF，遇到表格再单独用pdfplumber或专用表格解析工具。

2.2 用PyMuPDF写一个最小文本抽取脚本

代码非常简单，核心就是fitz.open加page.get_text：

import fitz doc = fitz.open("example.pdf") for page_num in range(len(doc)): page = doc.load_page(page_num) text = page.get_text("text") print(f"===== 第 {page_num + 1} 页 =====") print(text)

如果你只需要纯文本，用get_text("text")即可。这个方法抽取的是PDF内部的文字对象，不是像素级的东西。绝大多数单栏、正常排版的PDF，抽出来的文本顺序都没问题。这里有个小技巧：如果你在做日志排查，给每页文本前面加上页码标记，后面定位问题会方便很多。

2.3 双栏排版、页眉页脚、乱序文本这几个坑必须躲开

双栏PDF是重灾区。学术论文、行业报告都喜欢双栏排版，直接抽取时文字会按物理行交叉混排，读起来完全不通。解决办法是用get_text("dict")拿到每个文本块的位置坐标，按x坐标排序；或者把页面在中间一分为二，左右两半分别抽取再拼接。

blocks = page.get_text("dict")["blocks"] # 每个block里有lines，每个line里有spans # 按block["bbox"][0]即左上角x坐标排序，就能恢复左栏到右栏的顺序

页眉页脚、页码这类噪声也很要命。不过滤的话，后面切块时每个块都带着“第X页”“公司内部资料”这种垃圾信息，检索时还会干扰向量排名。最简单的做法：统计分析高频出现的短字符串，做成一个stoplist，抽取文本后直接把命中的内容删掉。另外一个常见的坑是换行符。PDF里的自动换行是排版行为，不是语义结束。如果直接按换行符切文本，一句话会被劈成好几段。后面做段落边界判断时，需要把这些“行尾回行”合并回完整的段落。

3. 第二层实战：从纯文本到结构化文档

3.1 为什么要做结构识别

纯文本抽取完，它还是一串扁平的文本流。如果拿这份文本直接切块，切出来的块一定会跨标题、跨段落，甚至把表格从中间劈成两半。问题就出在这：RAG检索到一个“半句话”之后，它自己都搞不清这条信息属于哪个章节、上下文是什么。结构层要做的事，就是把标题、段落、表格这些边界识别出来。别小看这一步，它决定了后面所有切块和检索的质量。

3.2 标题层级识别：用字体、字号和编号规则就够了

对于绝大多数排版规范的PDF，标题层级不需要上深度学习，靠规则就够用。可以从这几个维度入手：

• 字号是否比正文大；
• 字体是否加粗；
• 是否带“1、1.1、一、（一）”这类编号；
• 前后是否有明显间距。

我一般写一套简单规则：先把文档所有文本行拆出来，记录每行的字号、字体、缩进和页码，再按阅读顺序排好，用“字号大于正文 + 加粗 + 编号模式”这几个特征给行打标签。比如，一个文本行字号比正文大2pt以上，而且加粗，编号匹配^\d+\.\d+，基本可以判定是H2级别的标题。

import re body_size = 10.5 # 从文档正文抽样得到的字号 def identify_heading(line): if line["size"] > body_size + 1.5 and line["bold"]: if re.match(r"^\d+(\.\d+)*", line["text"].strip()): depth = line["text"].strip().split(".")[0].count(".") return f"H{depth + 1}" return None

这套规则在标准技术文档上命中率很高。但扫描版PDF就不一定了，因为OCR拿到的字体信息不可靠，这时候就得靠版面分析模型或者人工校准。这是后话，后面在常见问题里展开。

3.3 表格识别与表格转Markdown

表格在PDF里是老大难，因为PDF不保留表格的逻辑结构，很多表格本质是一堆绝对定位的文本块。处理路径我一般分两步：先识别表格区域，再把识别出来的二维数组转成Markdown表格。Markdown表格是当前对RAG最友好的表格表达方式，既保留行列关系又不带复杂样式。

import pdfplumber with pdfplumber.open("sample.pdf") as pdf: page = pdf.pages[0] table = page.extract_table() if table: md = [] for i, row in enumerate(table): cells = [(c or "").replace("\n", " ") for c in row] md.append("| " + " | ".join(cells) + " |") if i == 0: md.append("|" + "---|" * len(row)) print("\n".join(md))

提醒一下，不是所有表格都能被识别出来。无边框表格、表头跨行跨列、合并单元格，都非常容易识别失败。所以工程上要加一道“校验 + 兜底”逻辑：表格识别失败时，按段落文本保留该区域内容，并把表格前后的文本块关联起来，至少别让信息丢失。你想想，一份技术手册里的参数表问不出来，用户就会觉得系统“不智能”。

3.4 段落边界：怎么按语义块而不是按字数切文本

传统字符串切块，本质是“数着字数切”。结构化方式应该是“按语义组织切”。最简单有效的做法：先利用标题结构把文档切到章节级别，再按段落做细切。段落边界以换行符、句号、缩进为判断依据，但不能看到换行就断，特别是PDF排版中的强制换行很容易造成误判。我处理时会把“换行”分成两类：段内换行，就是行尾自动回行，特征是上一行末尾没有句号、下一行没有缩进；段间换行，特征是存在空行或明显段间距。合并段内换行、保留段间边界，这一步做完，文本结构就清楚多了。

4. 第三层实战：把结构化文档变成RAG可用的数据

4.1 切块策略：从“一刀切”到“结构感知切块”

切块看起来简单，实际是RAG效果的天花板之一。最死板的是按固定长度切，比如512字符一段，再叠加128字符重叠。面对规整的纯文本，这种方式能跑；但遇到带结构的文档就很吃亏，经常把完整的一句话、一个列表项、一个表格行拦腰截断。我推荐的做法是结构感知切块：基于第二层识别出来的标题层级，先划分章节区间；在每个章节内部，以段落（或表格）为最小语义单元；再根据embedding模型的最大token限制，决定是把多个相邻段落拼成一个块，还是把一个超长段落拆成几个子块。切的时候有一个原则：宁可切大一点，也不要让块的头部出现“标题断层”。什么是标题断层？就是检索出来的片段没有章节信息，模型不知道它属于哪一段内容。

4.2 元数据是RAG检索的“隐形助攻”

每个块入库之前，除了文本本身，一定要带上元数据。一套比较完整的最小元数据集合长这样：

• doc_id：文档唯一ID；
• page_num：页码，用于溯源；
• chapter_path：章节路径，例如“2.3 环境配置”；
• chunk_type：块类型，如“paragraph”“table”“title”；
• token_size：块的大致token数量，方便后续过滤。

有了这些字段，你可以在检索时做过滤。比如用户问到“第二章提到的接口地址”，你可以直接限定chapter_path LIKE '2.%'再向量检索，精度会提升一大截。后面做答案溯源时，也能直接定位到源文件第几页，这个体验对B端用户尤其重要。

4.3 向量化与入库：用pgvector跑通闭环

向量数据库选择很多，拿pgvector举例是因为它不需要引入额外基础设施，在已有的PostgreSQL里加一个插件就能用。embedding模型方面，中文场景我用的是BAAI/bge-large-zh-v1.5这类中文向量模型，效果比通用英文模型好很多。编码时打开normalize_embeddings=True，后续计算余弦距离可以直接用点积。

建表和插入的简化流程如下：

CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE doc_chunks ( id BIGSERIAL PRIMARY KEY, content TEXT NOT NULL, meta JSONB, embedding vector(1024) );

from sentence_transformers import SentenceTransformer import psycopg2, json model = SentenceTransformer("BAAI/bge-large-zh-v1.5") chunks = [...] # [(content, meta), ...] texts = [c[0] for c in chunks] embeddings = model.encode(texts, normalize_embeddings=True) conn = psycopg2.connect("host=localhost dbname=ragdb user=postgres password=your_password") cur = conn.cursor() for (content, meta), emb in zip(chunks, embeddings): cur.execute( "INSERT INTO doc_chunks (content, meta, embedding) VALUES (%s, %s, %s)", (content, json.dumps(meta, ensure_ascii=False), emb.tolist()) ) conn.commit()

查询时用向量距离排序：

SELECT content, meta, 1 - (embedding <=> %s::vector) AS similarity FROM doc_chunks WHERE (meta->>'doc_id') = 'xxx' ORDER BY embedding <=> %s::vector LIMIT 5;

<=>就是余弦距离，返回的是距离值，越小越相似。用1 - distance换算成相似度更直观。注意，生产环境记得给embedding列建IVFFlat或HNSW索引，不然数据量一上来，查询速度会明显拖后腿。

4.4 检索不是终点：有必要加一层Rerank

很多刚入门的朋友以为向量检索排完就结束了，实际生产环境中，这个效果往往不够。我建议在向量召回Top 20之后，再加一层重排序，也就是Rerank。用跨编码器模型对“用户问题 + 召回文本”做精确打分，再取Top 5喂给大模型。这一步对中文文档问答的提升非常明显，尤其是术语多、问句长的场景，能把原来排在后面的关键段落捞上来。预算有限的场景，也可以用“关键词召回 + 向量召回”融合：关键词负责精准匹配专有名词，向量负责语义相似，两边各取TopN去重后再合并。这个思路实现简单，收益稳定。

5. 常见问题与排查技巧实录

5.1 问题速查表

5.2 扫描版PDF怎么低成本接入OCR

扫描版PDF是RAG最让人头疼的类型。低成本方案是：把每页PDF转成图片，然后用PaddleOCR之类的开源引擎识别。识别完的文字一定要保留每个词的坐标，这样才能复用第二层的结构解析逻辑。坐标信息在处理扫描版表格时尤其重要，纯OCR出来的文字流没有行列概念，必须靠坐标聚类还原表格边框和行列关系。这里有个经验：扫描版PDF别急着上，先用page.get_text()试抽几页，如果返回空字符串，再走OCR，能省不少时间。

5.3 检索结果有上下文缺失怎么排查

如果用户问一个问题，你把它喂给大模型，模型回答依赖某个上下文，而这个上下文并没有包含在召回的Top N里，模型就只能开始“编”。解决办法有两个方向：一个是在切块阶段做“父子切块”，小的子块负责精确检索，命中后把包含它的父级块整体喂给模型；另一个是扩充上文窗口，把段落的前几句、章节标题一起拼进去，让大模型能看到完整来龙去脉。我实测下来，父子切块对长文档的效果提升最明显。不过代价是存储和检索的块数量会变多，要提前规划好向量库的容量。

6. 完整样例：从PDF到RAG问答一次跑通

6.1 样例目标

假设我们有一份《设备运维手册》PDF，大概80页，包含文字章节、操作步骤列表、参数表格和几张架构图。我们要做一个内部问答系统，能回答“设备启动失败应该检查什么”“某型号的额定功率是多少”这类实际问题。

6.2 全流程走一遍

整体流程是：解析PDF为文本 → 识别标题和表格结构 → 生成结构化chunk → 向量化入库 → 查询时召回 + Rerank → 交给LLM生成回答。

doc = parse_pdf("设备运维手册.pdf") pages = extract_text_with_coordinates(doc) # L1 文本层 struct = analyze_structure(pages) # L2 结构层：标题、段落、表格 chunks = build_chunks_from_struct(struct) # L3 应用层：结构感知切块 + 元数据 embeddings = encode(chunks) # 向量化 insert_to_pgvector(chunks, embeddings) # 入库 # 查询时 question = "设备启动失败应该检查什么" candidates = vector_search(question, top_k=20) # 向量召回 ranked = rerank(question, candidates, top_k=5) # 精排 answer = llm.generate(question, ranked) # 生成

这只是一个核心流程骨架，生产环境还要考虑增量更新、文档权限过滤、日志追踪等。但核心思想是一样的：先把文档处理成“有结构的半成品”，再去做检索，不要指望直接拿原始PDF交给模型去读。

6.3 效果对比：同一份PDF，两种方案的差距

我在一个内部项目上做过对比，同一份PDF、同一个问题集，用“直接全文转字符串 + 固定长度切块”和“三层解析 + 结构感知切块”跑出来的效果差距很大。最典型的一组数据是：

具体数值跟文档类型、问题难度都有关系，但趋势是一致的：解析做得好，RAG整体效果才有保证。尤其是表格类和多级标题类问题，三层解析的优势非常明显。

6.4 这套思路的扩展方向

如果你已经跑通了这套三层管道，后面可以做很多扩展。比如在L2层接入版面分析模型，自动识别扫描版PDF中的表格、图片、标题区域；在L3层接入GraphRAG，把实体关系和文档结构存入图数据库，做结构化知识问答；还可以把PDF解析做成异步任务，接入消息队列，让文档上传、解析、索引全流程自动化。这些方向都在我后续的实战计划里，感兴趣的朋友可以先从这一篇的三层基础开始搭。

最后说一句我个人最大的体会：做RAG，很多人把精力全花在选模型、调prompt、换框架上，效果不好就再换一个框架，换来换去问题还在。其实数据入口的质量决定了整个系统的上限。PDF解析这件事，看起来只是整个链路前面那块垫脚石，实际上是把“文档理解能力”前置到数据链路里最值得投入的一环。先把这三层跑通，再去调那些花哨的组件，你会发现很多以前查不出来的问题，根本不需要换模型就能解决。