向量化策略

原文分块向量化

这是 RAG 中最基础且高效的策略，通过滑动窗口机制切割文本：设置固定分块大小（如 512 字符）和重叠比例（如 10%），让相邻文本块保留部分重复内容。例如，将一篇长文档切成多个段落，每个段落首尾包含前一块的结尾和后一块的开头，像拼图一样覆盖全文。这样一来，每个块都能包含足够的上下文信息，同时也能保持足够的特异性，方便后续的搜索和处理。

适用场景

1. 结构化文档处理：
   • 技术手册、法律条文等逻辑清晰的文本，分块后能保留完整上下文。
2. 快速落地场景：
   • 无需复杂预处理，适合对时效性要求高的项目（如新闻摘要）。
3. 通用知识库：
   • 当文档主题分散、无明确重点时（如百科条目），均匀分块可避免遗漏信息。

为什么有效？

• 防信息割裂：重叠部分避免关键信息被切分到不同块中（如专有名词跨块）。
• 平衡效率与精度：小块利于快速检索，重叠设计弥补上下文的连续性。
• 低门槛适配：仅需调整分块大小和重叠比例即可适配多数场景，无需领域知识。

💡 经验提示：重叠比例建议 10%-20%的分块大小。

父子分块向量化

多个业界论文研究表明，RAG 分块的大小通常在 256 至 512 个 token 之间往往能够获得最佳的命中效果。所以通常我们会尽量把文本块切得小一点，这样更容易找到我们需要的内容，同时也能保证搜索的质量。但问题是，光看最匹配的那句话可能还不够，有时候它的上下文信息才是帮助我们给出正确答案的关键。如何平衡检索命中和更多上下问信息之间的关系？这时候就可以使用 父子分块向量化 策略。

核心原理

将文档分层切割：

1. 父分块（1024-2048 token）：保留完整逻辑段落（如技术文档的一章或产品说明的一个功能模块）。
2. 子分块（256-512 token）：从父分块中提取关键句子或数据片段（如操作步骤、参数定义）。

向量化时仅处理子分块，但检索命中后返回对应的父分块全文作为上下文。

为何有效？

• 子分块的高精度：小片段更容易精准匹配用户问题中的细节（如特定参数、缩写）。
• 父分块的上下文：避免因切割丢失关键背景（例如："该配置仅适用于Linux系统" 可能存在于父分块首段）。
• 效率优化：存储和检索小分块，运行时仅需召回父分块一次。

适用场景

1. 技术文档问答
   • 用户问："max_connections参数的默认值是多少？"
   • 子分块精准命中参数定义 → 父分块返回包含配置示例、使用限制的完整章节。
2. 法律条款解析
   • 用户问："违约赔偿计算方式？"
   • 子分块匹配条款编号 → 父分块返回连带责任说明、例外情况等关联段落。
3. 长文本知识库
   • 研究报告中的某个数据表（子分块）被命中 → 返回包含数据解读、实验方法的完整章节（父分块）。

示例

文档父分块：

数据库配置指南（节选）
在MySQL 8.0中，max_connections控制最大并发连接数，默认值为151。注意：修改此值需同步调整thread_cache_size，否则可能导致内存溢出（详见第4.2节）。建议生产环境设置为800-1000。

子分块切割：

1. "max_connections默认值为151"
2. "修改需同步调整thread_cache_size"
3. "生产环境建议800-1000"

用户提问：

"我把max_connections改成1000后服务器崩溃，可能是什么原因？"

运行过程：

1. 子分块1因含"max_connections"被高相似度命中。
2. 系统返回父分块全文，其中明确提示需同步调整相关参数，并指引到具体章节。

分块总结向量化

有时候文档的内容质量不是很高，文档分块里的真正有价值的信息比较少，充斥着许多“水分”。或者另一种情况是文档的关键信息被简写或者代词所引用，比如 “MJ被认为是历史上最著名的摇滚歌手”，“MJ是篮球史上最佳的球员”。这两个 “MJ” 在这里就代表了不同的人物：迈克杰克逊 和 迈克乔丹。如果直接把这种文档进行向量化保存到向量空间里，后续进行检索时效果也不会很好。这个时候就可以使用 分块总结向量化 的策略。

核心原理

在向量化前，先用大语言模型（LLM）对原始分块进行“信息提纯”：

1. 去冗余：删除重复描述、广告性文字等非核心内容。
2. 消歧义：将代词（如"其"、"该设备"）替换为具体对象，展开缩写（如"LLM→大语言模型"）。
3. 结构化：提取核心事实、因果关系、数据结论，形成简洁的总结句。

仅对总结后的文本进行向量化存储，而非原始分块。

为什么有效？

• 信息密度提升：避免无效文本稀释关键内容的语义权重。
• 语义明确化：解决"一词多义"（如"MJ"）和"指代模糊"（如"上述方法"）导致的检索偏差。
• 适配用户语言：总结内容更接近用户提问的自然表达方式。

适用场景

1. 口语化/非正式文档
   • 会议记录、用户评论、社交媒体内容。
2. 专业领域文档
   • 技术手册中的缩写（如"K8s→Kubernetes"）、论文中的变量简写（如"CNN→卷积神经网络"）。
3. 跨领域多义词
   • "苹果"可能指公司、水果或电影，"Java"可能指编程语言或咖啡产地。

示例

原始分块：

"MJ在1984年发布的专辑创下历史纪录，销量突破7000万张。其舞台表演风格至今被广泛模仿，但部分动作因健康风险已被行业禁止。"

问题：

• "MJ"指代模糊
• "其"指代对象不明
• "行业"未说明具体领域

LLM总结后：

"迈克尔·杰克逊（Michael Jackson）1984年专辑销量达7000万张，创音乐史纪录。他标志性的舞台动作（如45度倾斜）因容易导致脊椎损伤，已被音乐演出行业限制使用。"

检索效果对比：

用户提问	原始分块命中率	总结分块命中率
"迈克尔·杰克逊哪些舞蹈动作被禁了？"	低（原文未提"迈克尔·杰克逊"）	高（总结中明确关联人名与动作）
"音乐史上销量最高的专辑是谁的？"	中（依赖"历史纪录"模糊匹配）	高（直接包含"音乐史纪录"关键词）

假设问题向量化

这种策略的核心是 “以问题为导向”。它通过大语言模型主动分析文档内容，生成该分块可能回答的潜在问题（例如：“MJ在音乐领域的成就有哪些？”），再将这些问题（而非原文）转化为向量存储。当用户实际提问时，系统会优先匹配最接近的“假设问题”，从而精准定位对应的文档片段。将文档从被动等待匹配转变为主动预测需求，如同给知识库装上"提问预判雷达"。这种策略特别适合解决“我知道答案就在文档里，但不知道怎么问才能找到它”的典型困境。

为什么有效？

• 语义翻译器：对齐用户与文档的语言差异。
• 信息显式化：通过生成问题，可主动补全文档未明说的上下文。
• 一答对多问：单个文档片段可生成多个假设问题，形成问题矩阵。

适用场景：

• 当文档包含大量专业术语或隐式信息时（例如技术手册中的缩写“LLM”对应“大语言模型”），用户可能用更口语化的方式提问。
• 解决用户提问方式与文档表述差异的问题（例如用户问“如何缓解失眠”，而文档写的是“改善睡眠质量的方法”）。

示例：

若文档片段提到“MJ在1984年凭借《Thriller》专辑打破多项销量纪录”，模型可生成假设问题：“迈克尔·杰克逊有哪些破纪录的音乐作品？”，从而覆盖用户可能的多样化问法。