这期我们将聚焦在文档预处理管道（Ingestion Pipeline） 这一核心模块，逐项拆解其四个关键子任务：

1.数据收集与清洗

2.文本分割

3.元数据提取

4.格式转换

不仅说明怎么做，还结合企业实际场景，指出“谁来做”、“用什么工具做”、“遇到什么问题如何解决”。 Ingestion Pipeline是RAG系统的地基。地基不牢，上层再强也会幻觉频出。初期可投入30%-40% 的精力打磨这一环节——它决定了你整个系统的准确率上限。

一、数据收集与清洗

1 数据从哪里来？（企业常见来源）

在企业环境中，知识型文档通常分散在多个系统中：

来源类型示例特点

文件系统—共享盘、NAS、本地服务器的Word/PDF/Excel–非结构化，需解析

内部Wiki / Confluence–产品文档、运维手册、FAQ–半结构化，有标题层级

CRM / ERP系统—客户沟通记录、工单、合同—结构化或半结构化

数据库–MySQL、PostgreSQL 中的业务表（如知识库表）—结构化，易提取

邮件系统–Outlook、企业邮箱中的历史邮件—需去重、过滤签名

SaaS平台—钉钉文档、飞书知识库、Notion API–可接入

建议做法：建立一个统一的数据接入层，通过脚本或ETL 工具（如Apache NiFi、Airbyte、自研调度器）定期拉取各源数据。

2 谁来参与？

业务部门（产品、客服、法务等）：提供原始文档，确认哪些内容可纳入知识库；

数据工程师：负责搭建采集管道，编写解析脚本；

合规/法务团队：审核敏感信息（如客户身份证号、合同金额）是否脱敏；

AI/算法团队：定义清洗规则（如“去掉页眉页脚”、“保留表格”）。

3 清洗做什么？

清洗的目标是提升文本质量+ 降低噪声，典型操作包括：

去除无关内容：页眉页脚、水印、页码、广告语、重复段落；

脱敏处理：用正则或NER 模型识别并替换手机号、身份证、银行卡号（如138****1234）；

编码统一：转为UTF-8，避免乱码；

语言过滤：若只支持中文，可过滤英文或混合语种文档；

空文档/低质量文档剔除：如PDF 扫描件无OCR 文字、Word 仅含图片。

4常用工具：

PDF解析：PyPDF2（简单）、pdfplumber（保留表格）、Unstructured.io（企业级）Office解析：python-docx、openpyxl

通用清洗：BeautifulSoup（HTML）、正则表达式、spaCy/NLTK（语言处理）

二、文本分割（Text Chunking）

1 为什么需要分割？

当前主流开源LLM 的上下文窗口（context window）有限：

模型最大Token 数实际可用（留空间给prompt + output）

Llama-3-8B8,192     ≈6,000

Qwen-Max 32,768   ≈25,000

Claude 3 Sonnet 200,000 ≈150,000（但私有部署难）

开源模型（如ChatGLM3-6B）  8,192     ≈6,000

⚠️注意：1 token ≈ 0.75 个汉字。所以6,000 tokens ≈ 4,500 汉字。如果一篇年报有5 万字，必须切分成多个块。

2 如何切分？——不是简单按字数！

错误做法：每500 字一刀切→ 可能切断句子、表格、段落逻辑。

正确策略：语义感知分块（Semantic-aware Chunking）

方法说明适用场景

RecursiveCharacterTextSplitter（LangChain 默认）按\n\n → \n →   → ” 优先级递归切分通用，平衡效率与语义

MarkdownHeaderTextSplitter 按# 标题 层级切分      Wiki、技术文档

基于句子边界（Sentence Splitter）用spaCy 或Stanza 切句，再组合成块高精度问答

滑动窗口（Overlap）相邻块重叠50~100 字防止关键信息被切碎

推荐配置示例（中文场景）：

python编辑from langchain.text_splitter import RecursiveCharacterTextSplittersplitter = RecursiveCharacterTextSplitter(chunk_size=500,        # 目标块大小（字符数，非token）chunk_overlap=50,      # 重叠部分separators=["\n\n", "\n", "。", "；", " ", ""])

进阶技巧：

对表格、代码块单独处理，不与其他文本混切；使用LLM 自动摘要长段落后再切分（成本高但效果好）。

三、元数据提取（Metadata Extraction）

1 为什么要元数据？

RAG不只是“找相似文本”，还要支持：

权限控制：用户A 不能看到财务机密；

时效过滤：只检索2024 年后的政策；

来源追溯：回答时附带“来自《员工手册v3.2》第15 页”。

2 提取哪些元数据？

元数据类型示例用途

Source–https://wiki.example.com/hr/policy–引用来源

title–2024年差旅报销标准—提升检索相关性

author–HR部门—权限/可信度判断

created_at / updated_at–2024-05-01–时效过滤

department–finance, legal–权限隔离

doc_type–contract, manual, email–路由不同处理流程

3 如何提取？

结构化来源（如数据库）：直接映射字段；

非结构化文档（如PDF）：

从文件名/路径推断（如/finance/2024/Q2_report.pdf → department=finance）；

用正则匹配文档开头（如“发文单位：XXX”）；

用小型NER 模型抽取日期、机构名；

人工标注模板（适用于高频文档类型）。

4使用工具：

LangChain的Document 对象天然支持metadata 字典；

自研pipeline 可用JSON/YAML 存储元数据。

四、格式转换（Format Normalization）

1 转换成什么格式？

最终目标格式：纯文本（Plain Text）+ 结构化元数据（JSON）

原因：所有Embedding 模型都吃纯文本；

纯文本易于分块、清洗、索引；元数据单独存储，不影响向量化。

2 转换流程示例

输入：一份PDF 合同

↓

[PDF解析] → 提取文字+ 表格（用pdfplumber）

↓

[清洗] → 去页眉“机密★三年”、脱敏身份证号

↓

[元数据提取] → source=file:///contracts/2024/abc.pdf, type=contract, party=A公司

↓

[分块] → 切成500 字/块，每块带相同元数据

↓

输出：List[Document(text=”…”, metadata={…})]

最佳实践：

保留原始文件哈希值（如SHA256），用于去重；记录处理时间戳，支持增量更新；对无法解析的文件（如加密PDF）打标并告警。

五、总结：谁来做？用什么做？产出什么？

任务主要参与者推荐工具交付物

数据收集—数据工程师+业务方–Airbyte, 自研爬虫, API SDK–原始文档集合

清洗与脱敏—数据工程师+合规团队–Unstructured, spaCy, 正则—干净文本

分块–AI工程师–LangChain, LlamaIndex–分块列表（带overlap）

元数据提取–AI工程师+业务专家—规则引擎+小模型metadata–字典

格式标准化—全流程自动化–JSON + Plain Text–统一输入格式供向量化

查看该公众号全部文章，点击屏幕左下方+关注按钮，可获得从0到1的全部教程和上手资料。