文档处理流程
构建高质量 检索增强生成 RAG 系统的基石是严谨、高效的文档处理流程。这一流程通常被称为“索引管道 (Indexing Pipeline)”，其目的是将非结构化的原始文档（如 PDF, HTML, DOCX）转换为经过优化的、可供模型检索的知识片段。
整个流程可分为以下几个关键阶段：
1. 文档加载 (Loading)
这是处理流程的第一步，目标是从各种数据源中提取纯文本内容和元数据。
- 数据源类型：
- 文件系统：本地或网络驱动器上的 PDF, Word, Excel, Markdown, PPT 等文件。
- 数据库：SQL 或 NoSQL 数据库中的记录。
- API：如 Notion, Slack, Confluence 等协作工具的 API 接口。
- 网页：抓取公开网站或内部 wiki 页面的 HTML 内容。
- 常用工具：LlamaIndex 和 LangChain 提供了丰富的
Readers或Loaders来简化这一过程，能够处理上百种不同的数据源。 - 关键考量：
- 内容提取质量：能否准确无误地从复杂格式（如多栏 PDF、带表格的 Word）中提取文本。
- 元数据保留：是否能一并提取文件名、创建日期、作者、章节标题等元数据，这些信息在后续的检索过滤中至关重要。
2. 文档切分 (Splitting / Chunking)
由于语言模型存在上下文窗口长度的限制，并且为了提升检索的相关性，必须将长文档切分为更小的、语义完整的片段 (Chunks)。
- 切分策略：
- 固定长度切分 (Fixed-size Chunking)：最简单的方法，按固定字符数（如 1000 个字符）切分，并设置重叠部分 (overlap) 以免语义在边界处被割裂。
- 基于分隔符切分 (Separator-based Splitting)：按自然语言的边界（如段落
\n\n、句子、项目符号）进行切分，是更常用的方法。 - 语义切分 (Semantic Chunking)：利用语言模型或 NLP 技术识别文本中的语义边界，确保每个片段都包含一个完整、独立的主题。这是最先进但计算成本也更高的方法。
- 切块大小 (Chunk Size) 的选择：
- 较小的切块：包含更具体、更集中的信息，有利于提升检索的信噪比，但可能丢失全局上下文。
- 较大的切块：能保留更多上下文，但可能引入噪声，降低与特定查询的匹配精度。
- 选择最佳切块大小通常需要在具体任务上进行实验和评估。
3. 文本向量化 (Embedding)
切分完成后，需要将每个文本片段转换为一个数值向量，即“词嵌入”或“文本嵌入”。这个向量能够捕捉文本的语义信息。
- 核心组件：文本向量化技术，它将文本映射到高维向量空间。
- 过程：将每个文本块输入到预训练的嵌入模型中，生成一个固定维度的向量（例如，768 或 1024 维）。
- 关键选择：选择一个性能优异且与应用场景匹配的嵌入模型至关重要，它直接决定了后续检索的质量上限。
4. 数据存储 (Storing)
最后一步是将处理好的文本片段及其向量存储起来，以便快速检索。
- 存储方案：
- 向量数据库 (Vector Database)：专门为高效存储和检索大规模向量数据而设计的数据库，如 Pinecone, Weaviate, Milvus, ChromaDB 等。它们提供了优化的 向量索引与检索 算法。
- 传统数据库 + 向量插件：一些传统数据库（如 PostgreSQL 通过
pgvector）也提供了向量搜索能力。
- 存储内容：
- 文本片段 (Chunk)：原始的文本内容。
- 向量嵌入 (Embedding)：由嵌入模型生成的向量。
- 元数据 (Metadata)：如文档来源、章节、日期等，用于在检索后进行过滤或提供额外信息。
通过这个流程，原始文档被转化为一个结构化的、可随时被 RAG 系统调用的知识库。