里小咸1. 从分块策略看Embedding技术的演进
在构建基于大语言模型（LLM）的智能系统时，我们常常会遇到一个关键矛盾：模型需要处理海量知识，但其上下文窗口却有限。这就好比让一个记忆力超群的学者参加开卷考试，却只允许他每次翻阅几页资料。检索增强生成（RAG）技术通过将外部知识库与LLM结合，成为解决这一矛盾的银弹方案。而在RAG的整个技术栈中，文本分块（Chunking）作为连接原始文档与向量数据库的桥梁，其重要性往往被严重低估。
我曾在多个企业级知识库项目中，亲眼见证分块策略如何直接影响系统表现：同样的文档、相同的模型，仅因分块方式不同，问答准确率可以相差20%以上。这促使我深入探究不同分块策略的技术本质，特别是传统朴素分块（Naive Chunking）与新兴后期分块（Late Chunking）的根本差异。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 朴素分块：简单高效但暗藏陷阱
2.1 基本工作原理
朴素分块的操作流程如同工业流水线般直观：
- 文本预处理：清洗原始文档（去除无关字符、标准化格式等）
- 机械分割：按固定token数（如512）或字符数切割文本
- 独立编码：每个文本块单独输入embedding模型生成向量
python复制# 典型朴素分块代码示例
from langchain.text_splitter import CharacterTextSplitter
text_splitter = CharacterTextSplitter(
chunk_size=500,
chunk_overlap=50
)
chunks = text_splitter.split_text(long_document)
2.2 优势与适用场景
这种方法的优势显而易见：
- 计算效率高：各分块可并行处理
- 实现简单：主流框架（如LangChain）内置支持
- 内存友好：避免长上下文带来的显存压力
在以下场景表现尚可：
- 文档结构规整（如技术文档）
- 语义边界明确（如问答对集合）
- 对召回率要求不高的简单检索
2.3 致命缺陷：上下文断裂
但问题在于，自然语言本质上具有上下文依赖性。我在金融知识库项目中遇到过典型案例：
原文："苹果公司2023年营收下降5%。(段落分隔)这主要源于iPhone15系列在中国市场的销售疲软。"
朴素分块后：
- Chunk1向量编码了"苹果公司营收下降"
- Chunk2向量编码了"iPhone15销售疲软"
当用户查询"苹果业绩下滑原因"时，系统可能只召回Chunk1，完全丢失关键因果信息。更糟糕的是代词指代问题：
"张勇宣布阿里新战略。(段落分隔)他特别强调云计算优先。"
分块后"他"的指代关系完全丢失，生成的embedding无法反映语义关联。
3. 后期分块：让每个分块拥有全局视野
3.1 技术实现原理
后期分块颠覆了传统流程：
- 整体编码：将完整文档（或最大上下文窗口内的部分）输入模型
- 注意力计算：通过Transformer的自注意力机制建立全局关联
- 延迟分块：在获得token级embedding后，按需聚合分块
python复制# 后期分块伪代码实现
def late_chunking(doc, model, chunk_size):
# 获取完整文档的token embeddings
outputs = model(doc, output_hidden_states=True)
token_embeddings = outputs.last_hidden_state
# 按语义边界划分chunk（非固定长度）
chunks = []
current_chunk = []
for i, token in enumerate(doc.tokens):
current_chunk.append(token_embeddings[i])
if is_chunk_boundary(token) or len(current_chunk) >= chunk_size:
chunks.append(pooling(current_chunk))
current_chunk = []
return chunks
3.2 关键技术突破
这种方式的革命性在于：
- 条件嵌入（Conditional Embedding）：每个token的表示包含全文上下文信息
- 动态分块：可根据标点、段落等语义边界灵活划分
- 跨块关联：通过注意力机制保留远程依赖关系
3.3 性能优化实践
虽然后期分块对显存要求较高，但通过以下技巧可大幅降低资源消耗：
- 滑动窗口法：对超长文档采用重叠窗口处理
- 层次化分块：先粗粒度分大段，再细粒度分小块
- 梯度检查点：减少训练时的内存占用
实测数据：在NVIDIA A100上处理10k token文档时，采用滑动窗口（窗口大小2048，步长1024）可使显存占用从48GB降至28GB，而检索准确率仅下降2.3%。
4. 关键对比：技术参数与业务场景
4.1 技术指标对比
| 维度 | 朴素分块 | 后期分块 |
|---|---|---|
| 上下文感知 | ❌ 仅局部 | ✅ 全局 |
| 处理速度 | ⚡️ 快(并行) | 🐢 慢(串行) |
| 显存占用 | ✅ 低 | ❗️ 高 |
| 代词解析能力 | ❌ 差 | ✅ 优 |
| 实现复杂度 | ⭐️ 简单 | ⭐️⭐️⭐️ 复杂 |
4.2 场景选择指南
根据项目经验，建议如下决策框架：
选择朴素分块当：
- 处理技术文档/结构化数据
- 硬件资源有限
- 追求高吞吐量（如实时处理）
- 文档内上下文关联较弱
选择后期分块当：
- 处理文学/法律等强上下文文本
- 需要精确的指代消解
- 具备高性能GPU资源
- 问答系统要求高准确率
5. 实战中的进阶技巧
5.1 混合分块策略
在实际项目中，我常采用分层处理方案：
- 第一层：用朴素分块快速过滤无关文档
- 第二层：对候选文档用后期分块精细处理
这种方案在保证召回率的同时，将处理耗时控制在合理范围。
5.2 动态分块大小
固定分块大小往往不是最优解。智能分块算法应考虑：
- 段落/章节边界
- 标点密度（句号/分号等）
- 实体出现频率
例如在医疗文本中，可将每个"诊断-治疗"段落作为独立分块。
5.3 嵌入后处理
即使采用后期分块，仍可通过以下方法提升效果：
- 跨块注意力：在向量数据库查询时引入相邻块信息
- 重排序机制：用小型NN模型对召回结果二次评分
- 动态加权：根据查询词调整不同分块的权重
6. 避坑指南与性能调优
6.1 常见陷阱
- 重叠不足：分块间无重叠会导致边界信息丢失（建议10-15%重叠）
- 硬分割符号：盲目按Markdown标题分割可能破坏语义连贯性
- 忽略文档结构：技术文档中的代码块需要特殊处理
6.2 性能优化
- 批处理技巧：将多个短文档拼接后统一处理
- 量化压缩：使用int8量化降低embedding存储开销
- 缓存机制：对静态文档预计算embedding
案例：某金融知识库系统通过实施后期分块+缓存策略，使问答准确率从68%提升至83%，同时维持<2秒的响应延迟。
7. 未来展望
随着Transformer模型的持续进化，分块技术也在不断创新：
- 递归分块：构建层次化语义树状结构
- 动态上下文窗口：根据内容复杂度自适应调整分块大小
- 多模态分块：统一处理文本、表格、图像等混合内容
在本地化部署场景下，建议关注以下技术组合：
- LangChain + FastEmbed：轻量级高效解决方案
- LlamaIndex + 后期分块：追求精度的选择
- ColBERT + 动态分块：平衡性能与准确率