企业官网建设流程全解析

1. 从原始文本到可处理片段：为什么加载与分块是RAG的第一道坎

很多人学RAG（检索增强生成）的时候，一上来就直奔向量数据库、embedding模型、重排序这些“看起来很有技术含量”的环节，结果做到一半发现效果稀烂——检索回来的内容跟问题对不上，或者答案东拼西凑、逻辑断裂。这时候回头排查，十有八九问题出在最前面那两步：文档加载和文本分块。

我最早做某个知识库问答项目的时候也踩过这个坑。当时我拿到一批PDF和Word文档，想着“加载嘛，不就是读文件嘛”，直接用现成库一把梭，把整个文档当成一个超长字符串丢给embedding接口。结果向量化之后，检索出来的片段有的横跨三个章节、有的在一句话中间被截断，回答质量自然惨不忍睹。后来我才意识到，文档加载和文本分块这两步看似基础，实际上决定了后面所有环节的上限——检索准不准、回答连贯不连贯，在这个阶段就已经被“焊死”了。

这一章要聊的就是这两件事。文档加载解决的是“怎么把不同格式的文件变成干净、可用的文本”，文本分块解决的是“怎么把长文本切成长度合适、语义完整的小片段”。两个步骤环环相扣，如果你现在正好在搭RAG系统，或者准备优化检索质量，这部分值得耐心看完。

2. 文档加载：拆掉格式的墙，把内容“抠”出来

2.1 各类加载器的选型与适用场景

文档加载这件事，本质上是个“格式逆向工程”。PDF有PDF的排版逻辑，Word有Word的段落结构，HTML和Markdown又有各自的标签体系。你不可能指望一个加载器通吃所有格式，所以第一步是搞清楚你手上的数据长什么样，再选对应的加载方案。

以我常用的工具链为例，Python生态里最主流的加载框架是LangChain的文档加载器（Document Loader）体系，但底层真正干活的还是那些专门的解析库。我这里列几个常见场景的搭配：

• PDF文档：如果是以文本为主的电子版PDF，PyPDFLoader或PyMuPDFLoader就够用，速度快、依赖少。如果是扫描件或图片型PDF，就需要配合OCR工具，否则加载出来的全是乱码和空白。
• Word文档：.docx格式直接用Docx2txtLoader或python-docx解析即可。注意老式的.doc格式需要先转换，很多库不支持直接读取。
• HTML网页：BSHTMLLoader可以解析HTML并提取正文，但它对页面结构的假设比较“天真”，遇到复杂的嵌套布局时，最好自己写规则或用Readability类算法先抽取正文。
• Markdown/纯文本：这类格式最省心，TextLoader直接读入即可，几乎不需要额外处理。
• 表格类数据（Excel、CSV）：严格来说这不算“文档”，但如果你要做结构化问答，可以考虑按行或按逻辑块转成文本描述，而不是直接丢给文本加载器。

选加载器的核心原则是：先看格式，再定工具，不要盲目追求功能最全的库。我之前图省事，统一用某个“全能”加载器处理所有PDF，结果那些带复杂表格的文档被解析得七零八落，表格内容全部错位。后来换成针对性的解析方案，问题才解决。

2.2 加载后清洗：让文本“干净”起来

加载器把文件解析成文本之后，工作还没完。真实的文档加载出来往往带着一堆“杂质”——页眉页脚、页码、目录、脚注、表格噪声、多余换行、全角半角混用等等。这些杂质如果不清理，会直接影响后面分块的语义完整性。

我一般会在加载后立刻做一轮清洗，流程大概是这样的：

• 去除页眉页脚和页码：用正则匹配常见模式，比如“第X页 / Page X”“公司名称+日期”这类固定格式。如果不确定，可以先抽样打印几页看看规律。
• 压缩多余空白：把连续多个换行符、空格压缩成一个，避免分块时产生大量空片段。
• 合并被硬换行打断的段落：PDF解析经常出现一行一个换行的情况，这时需要根据行尾是否有标点来判断是否应该拼接。
• 剔除目录和索引区：目录是纯链接性质的文本，混入正文后毫无语义价值，而且会污染向量检索的结果。

注意：清洗规则一定要基于你实际数据的观察，不要套用网上找来的“通杀正则”。不同文档源生成的PDF，页眉格式、换行习惯千差万别，先抽样看三五个文件再动手写规则，效率最高。

2.3 容易被忽视的编码与元数据问题

很多人加载文档时只盯着“能不能读出文本”，却忽略了两个潜伏的问题：编码和元数据。

编码问题在中文场景里尤其突出。某些老旧系统导出的TXT文件是GBK/GB2312编码，直接按UTF-8读取必然乱码。处理办法不复杂，读取时先尝试UTF-8，抛异常就回退到GBK，或者用chardet库自动探测。这个坑属于“踩一次就长记性”的类型，但一旦踩了，排查起来挺费时间。

元数据（Metadata）则是另一个容易被忽略的点。加载文档时，建议同时保留来源文件名、页码、章节标题、文档标题等信息，作为片段元数据一并存入向量库。这样在检索后可以溯源、可以过滤，还能在生成回答时附上引用来源。我之前在做某个企业内部知识库项目时，就是靠元数据里的来源字段，给每个回答都加上了“出处文档+页码”，使用者反馈可信度一下子高了很多。

3. 文本分块：切得好不好，直接决定检索效果

3.1 为什么分块粒度是个“甜蜜点”问题

文本分块的核心矛盾在于：块太大，向量化后语义被稀释，检索时容易把不相关的内容带进来；块太小，单个片段语义不完整，检索时又容易漏掉关键信息，而且embedding模型对短文本的语义捕捉能力也有限。

用个生活化的比喻：你在图书馆找一本关于“如何养猫”的书。如果书名标到“动物-哺乳类-猫科-家猫”这个粒度，太细了，你可能错过其他相关章节；如果书名只标到“自然科学”，又太宽泛，找回来的东西大半没用。分块就是在“够具体”和“别漏掉”之间找平衡。这个平衡点没有绝对标准，跟你的文档类型、embedding模型、以及你期望的回答粒度都有关系。

3.2 按固定大小切：简单但别忽视边界问题

最简单粗暴的方法是按固定字符数或token数切块，比如每500个字符一块、没有重叠。实现起来几行代码的事，但它有两个明显的坑：

• 语义被拦腰截断：一个段落可能在中间被切开，导致两个块都只含半截语义。
• 没有上下文连续性：前后块之间没有关联，检索时只命中其中一块，信息就不完整。

缓解办法是引入重叠（overlap），也就是相邻块之间保留一部分相同的文本。比如每块500字符、重叠50字符，这样被切断的语义信息在下一块开头还能衔接上。我个人的经验是，重叠比例控制在10%~20%比较合理，太小起不到衔接作用，太大又相当于把数据复制了一份，浪费存储和计算资源。

3.3 按结构切：尊重文档的天然边界

比固定大小更优雅的方案，是按文档结构来切。Markdown按标题层级切，HTML按标签层级切，代码按函数或类切，PDF按章节和段落切。这样切出来的每个块，天然对应一个相对完整的语义单元。

以Markdown文档为例，比较理想的做法是：先用Markdown解析器把文档解析成标题树，然后从顶层往下遍历，遇到“够长”的段落或小节就切一刀，保留其所属的标题路径作为前缀。这样做的好处是，每个块自带“上下文锚点”，向量检索命中后，你能清楚地知道这段文字来自哪一章哪一节。

LangChain的MarkdownHeaderTextSplitter就是干这个的，可以自定义一组标题层级作为切割依据。它处理像README、技术文档这类结构清晰的文本非常顺手，但对没有明确标题结构的纯段落文本就无能为力了。

3.4 递归切块：兼顾长度与结构的实用派

前面两种方案各有短板，实际项目里我更常用的是“递归字符文本分割器”（RecursiveCharacterTextSplitter）。它的思路很直白：维护一个分隔符优先级列表，比如先按段落符（\n\n）切，切出来的块还太大，再按单个换行符（\n）切，还不行就按句号、逗号、空格逐步降级，直到每个块都小于设定的大小。

这种“从大到小逐步降级”的切法，能在尽可能尊重语义边界的前提下，满足长度约束。它不是万能的，比如遇到超长表格或代码块时，按字符切还是会破坏结构，但作为通用方案，表现已经相当稳健。我通常在处理混合类型的文档集时，会默认用递归切块，再针对特殊文档单独调参数。

3.5 按语义切：看起来很美，但要算清成本

还有一种更“高级”的思路——按语义切。大致做法是：先对句子做embedding，然后计算相邻句子之间的相似度，相似度低于某个阈值的地方就是语义断层，从那里切开。理论上这能实现“语义完整的块”，实际效果也确实不错。

但代价很明显：计算成本高。每个句子都要过一遍embedding模型，大规模文档集上耗时和费用都会显著增加。此外，阈值怎么定是个经验活，不同领域的文档相似度分布差异很大，A数据集上合适的阈值，搬到B数据集上可能完全失效。我的建议是：如果项目预算充足、对检索质量要求极高，可以一试；但对绝大多数场景来说，结构化分块加合适的重叠已经够用了，没必要为“锦上添花”付出成倍成本。

4. 实操过程与核心环节实现

4.1 分块参数怎么定：一个可落地的计算流程

参数定得好不好，直接决定分块质量的“地基”。我一般按下面这套流程来定：

• 先确认embedding模型支持的最大输入长度。以常见的开源embedding模型为例，有的支持512 token，有的支持1024甚至更多。分块大小必须留出余量，不要把长度顶到模型上限——因为embedding模型本身对长文本的语义捕捉能力会衰减，而且后面可能还要拼检索上下文做二次压缩。
• 把token数换算成字符数。中文场景下，一个token大约对应1~1.5个汉字（不同分词器差异较大）。假设你要把块控制在500 token以内，那字符数大约控制在750~1000字比较稳妥。注意，这里的换算必须拿你实际用的分词器测一下，别拍脑袋——中文和英文的token分布完全不一样。
• 设置重叠比例。我默认取块大小的10%~20%，具体看文档的段落长度分布。如果文档段落普遍较长，重叠可以适当加大；如果段落短，重叠小一点也能衔接得好。
• 跑一轮小规模验证。选几篇有代表性的文档，用不同参数组合切一遍，肉眼检查切出来的块是不是语义完整、有没有特别短的碎片块，然后小批量建立向量库试检索几个问题，对比结果。

我在实际项目中用的参数通常是这样的：块大小768字符（约400~500 token），重叠128字符（约16%）。这个值在多个数据集上都表现不错，但仅供参考，你的场景可能要调。

4.2 完整示例：从加载到分块的核心代码流程

下面给出一段完整的示例代码，演示从加载PDF到分块的全过程。这个例子用我常用的工具栈：LangChain加载、自定义清洗、递归分块。

from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter import re # 1. 加载PDF loader = PyPDFLoader("sample.pdf") documents = loader.load() # 2. 清洗：去除页眉、页码、压缩空行 def clean_text(text: str) -> str: # 去除页码和页眉（根据实际观察调整正则） text = re.sub(r"\n\s*(第?\s*\d+\s*页?|Page\s*\d+)\s*\n", "\n", text) # 压缩连续空行 text = re.sub(r"\n{3,}", "\n\n", text) # 合并被硬换行打断的行（行尾无标点时拼接） lines = text.split("\n") merged = [] for line in lines: if merged and not line.startswith(("#", "-", "*", "|")) and not re.search(r"[。！？；）\]]$", merged[-1]): if re.search(r"[，。；!?）]\s*$", merged[-1]) or merged[-1].strip() == "": merged.append(line) else: merged[-1] = merged[-1] + line else: merged.append(line) return "\n".join(merged) for doc in documents: doc.page_content = clean_text(doc.page_content) # 3. 递归分块 splitter = RecursiveCharacterTextSplitter( chunk_size=768, chunk_overlap=128, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""], length_function=len ) chunks = splitter.split_documents(documents) print(f"原始文档数: {len(documents)}") print(f"分块数: {len(chunks)}") for i, chunk in enumerate(chunks[:3]): print(f"\n--- 块 {i+1} ---") print(chunk.page_content[:200])

这段代码里的清洗函数是我针对常见PDF写的，不一定适配你的数据，但思路可以复用：先观察、再写规则、最后验证效果。

4.3 特殊文档的分块处理方案

不同文档类型，要有不同的“切法”。我遇到过的几类特殊场景，简单分享一下处理方案。

• 表格密集型文档：直接按文本切会把表格行拆得七零八落。我通常先识别表格区域，将每个表格整体转成一段结构化文本（比如用Markdown表格语法），再作为独立块处理，不参与普通文本的递归切分。
• 长代码文件：按函数或类切分。先用解析器提取AST结构，再按函数边界分块，每个块前缀保留“文件名:函数名”。这样检索代码时，命中某个函数就能直接定位。
• 扫描版PDF：先OCR成文本，再走常规清洗和分块流程。OCR的质量直接影响后续所有环节，建议选择高精度OCR模型，并对识别结果的常见错误（比如数字0和字母O混用）做后处理。
• 多语言混合文档：分块前先做语种分段，避免中英文夹在一起导致embedding效果变差。可以按段落检测语种，再分别设置分块参数。

提示：分块之后建议做一次“碎片检查”。如果出现大量长度小于50字符的块，说明切分参数或分隔符优先级设置有问题，需要回头调整。碎片块在向量检索时几乎没什么用，还浪费存储。

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

5.1 加载阶段的高频问题

PDF加载出来全是乱码：大概率是扫描件或者字体编码特殊。先拿一小段文本肉眼确认，如果是扫描件，换OCR方案；如果文字能选中复制但乱码，尝试换解析库。

Word文档加载后缺少部分内容：很多解析库对带文本框、图片标题的文档支持不好，内容被漏掉是正常的。处理方式是先抽几个文件对比人工阅读内容，确认缺失模式后再决定是否需要补充解析模块。

HTML正文夹杂大量导航和广告：直接用加载器提取的效果通常很差。建议先用正文抽取算法（如Readability）提取主内容，再做清洗，而不是直接对整个HTML做分块。

5.2 分块阶段的高频问题

分块后没有保留上下文：问题出在分块方式过于机械，或者没有记录标题路径。两个解法：一是改用结构化分块，二是把章节路径作为元数据，在检索提示词里携带上下文信息。

块与块之间重复内容过多：重叠比例设得太大了。检查一下重叠量占总块长的比例，不超过20%比较合适。另外确认是不是同一个文档被多次加载或重复分块。

检索时命中大量“半句话”：这是最小块的边界切得太碎导致的，常见于分隔符优先级设置不当。把句末标点（句号、感叹号、问号）提到换行符之前，让它优先作为切分边界，能明显改善。

中文语境下块长度和token数对不上：中文的token切分和字符长度不是线性关系，字符数设定的块大小，到embedding阶段可能超限或浪费。准备一个小的分词器测试函数，在不同文本上测出字符数和token数的换算比例，再用这个比例去设置块大小。

5.3 排查顺序建议

如果检索质量出了问题，我一般按这个顺序排查：

1. 先看加载出来的文本干不干净——乱码、页眉、错位文本有没有清干净。
2. 再看分块结果——随机抽20个块，人工读一遍，看语义是否完整、边界是否合理。
3. 然后看元数据——检索回来的是否能溯源、是否便于过滤。
4. 最后才怀疑embedding模型和检索参数——因为前面几步如果有问题，后面再怎么调参数都白搭。

这个排查顺序帮我跳过很多无用功。很多人在embedding和检索阶段反复调参没效果，回头一看，加载阶段就埋了雷。

6. 一些个人体会和扩展思路

文档加载和文本分块这两步，在RAG链路里显得很“不起眼”，但它们决定了整个系统的地基牢不牢。我个人做了几个项目之后的体会是：与其花大量时间调embedding模型和检索参数，不如先把分块质量做扎实。检索效果不好，先回头看看文本是不是真的“干净”、块是不是真的“完整”。

另外，分块策略不是一劳永逸的。随着文档集不断新增，你会发现新文档的格式、长度分布可能和之前不太一样，原来的参数不一定还合适。我现在的习惯是：每新增一批数据，就抽几个样本重新检查一遍分块结果，随时调整参数。

如果你后续想把这块做得更精细，可以往两个方向延伸：一是按语义动态分块，虽然成本高，但在某些专业领域效果确实好；二是加入针对特定文档类型的定制分块器，比如把表格、图表说明和正文用不同策略分开处理。这些都属于“优化型”工作，前提是你已经把基础的分块逻辑吃透了。

最后再分享一个小技巧：做任何分块调整之前，先建立一套“评估集”——固定问20~50个问题，对应人工标注的标准答案。每次改动分块参数，就拿这组问题跑一遍检索，对比命中率和回答质量。有了这套评估集，你就不会再靠“感觉”调参了，每次调整都有数据支撑，效率高得多。