文档分块：让AI知识库真正“读得懂”的关键

在搭建基于大模型的知识库应用时，有一个容易被忽略却至关重要的技术挑战：如何有效处理那些动辄数百页的复杂文档？最近在开发AI测试助手的实践中，这个问题确实给我带来了不少困扰。

直接将全文抛给大模型？这往往会遇到两个硬性问题。其一，模型的上下文窗口存在限制，超出容量范围就会失效；其二，即使某些声称支持“超长上下文”的模型勉强能处理全文，大量无关信息的涌入也会严重降低模型的理解能力，导致生成效果不尽人意。就像你想询问同事某个具体组件的参数，却先递给他整套产品手册让他读完再回答——效率和准确性都无法保证。

那么，这个看似棘手的问题，有没有系统性的解决方案？

文档分块：让AI知识库真正“读得懂”的核心技术

答案是被称为“文档分块”（Chunking）的技术。其核心理念并不复杂：将大型文档切分成一个个语义连贯、逻辑独立的小单元。但这绝不只是简单粗暴地按固定字数从头切到尾。真正有价值的分块，必须充分尊重文本的语义边界，确保每个块内包含一个能独立存在的完整概念或信息段落。接下来，我将拆解五种主流的实践思路，并基于LlamaIndex框架提供可运行的代码示例，覆盖从入门到高阶的各类场景。

五种主流分块方法：各自擅长什么，又存在哪些短板？

1. 固定长度分块：上手最快的“万金油”

原理
预先设定固定数量的token或字符数，按此阈值进行切分。为了让上下文不完全割裂，相邻两个块之间会保留少量重叠部分。

评估
实现成本极低，处理速度极快，是快速搭建原型的首选方案。但缺点也很明显：很可能将一个完整的句子甚至概念拦腰斩断。对于结构复杂的文档，这种简单策略的误差率偏高。

from llama_index.core.node_parser import SimpleNodeParser

parser = SimpleNodeParser.from_defaults(
    chunk_size=512,   # 中文文档建议384 tokens左右
    chunk_overlap=64  # 重叠区域，保证上下文连贯性
)
nodes = parser.get_nodes_from_documents(documents)

2. 结构感知分块：尊重文档“原生基因”

原理
先识别文档的内在结构标记（如Markdown的标题层级、HTML标签），然后严格按这种逻辑组织方式进行切分。

评估
能最大程度保留原始文档的逻辑骨架——同一标题下的相关段落不会被拆分到不同块中。但局限性也很突出：仅在文档自带明确结构标记时有效，对纯文本几乎无能为力。

Markdown文档

from llama_index.core.node_parser import MarkdownNodeParser

parser = MarkdownNodeParser()
nodes = parser.get_nodes_from_documents(markdown_docs)

HTML文档

from llama_index.core.node_parser import HTMLNodeParser

parser = HTMLNodeParser(tags=["p", "h1"])  # 指定需要提取的标签
nodes = parser.get_nodes_from_documents(html_docs)

3. 滑动窗口分块：保持上下文的连贯流动

原理
通过一个固定大小的窗口，在文本上逐句（或逐段）滑动。每次窗口捕获一组相邻的句子，形成彼此高度重叠的文本片段。

评估
非常有效地缓解信息断层问题，对对话记录、访谈稿等连续性数据流尤其适用。代价是会产生大量重叠内容，存储效率不高；并且窗口参数（如每侧包含的句子数）一旦设置不当，会直接影响后续检索质量。

import nltk
from llama_index.core.node_parser import SentenceWindowNodeParser

node_parser = SentenceWindowNodeParser.from_defaults(
    window_size=3,  # 每侧包含的句子数
    window_metadata_key="window",
    original_text_metadata_key="original_sentence",
)

4. 语义嵌入分块：让相似度决定断点

原理
引入嵌入模型计算句子间的语义相似度，在相似度低于设定阈值的“主题转换点”处自动切分。

评估
能最大程度保证同一块中的句子在主题上归属同一框架，避免从“技术说明”跳到“应用案例”的语义割裂。但计算资源消耗较大，处理大型文本时性能开销较高，且阈值参数通常需要多次实验才能找到最优值。

from llama_index.core.node_parser import SemanticSplitterNodeParser
from llama_index.embeddings.openai import OpenAIEmbedding

embed_model = OpenAIEmbedding()
splitter = SemanticSplitterNodeParser(
    buffer_size=1,
    breakpoint_percentile_threshold=95,
    embed_model=embed_model
)

5. LLM动态分块：把决策权交给大模型

原理
直接让大型语言模型（LLM）自主分析文本内容，并返回它认为最优的分块策略和边界。

评估
语义理解能力无疑是所有方案中最强的，能捕捉复杂的概念关联并执行多维度、多层次的分块。然而，每次调用都会带来API成本，处理速度也相对较慢，不适合对实时性要求高的场景。

from llama_index.core.llms import OpenAI
import json

def llm_chunking(text):
    llm = OpenAI(model="gpt-4-turbo")
    prompt = f"""将以下技术文档划分为逻辑单元，每个单元包含完整的技术概念:
    {text}
    返回JSON格式: [{{"title":"单元标题","content":"文本内容"}}]"""
    
    response = llm.complete(prompt)
    try:
        return json.loads(response.text)
    except json.JSONDecodeError:
        raise ValueError("LLM响应格式错误")

五种方法速览对比

实战复盘：AI测试助手的分块策略

在AI测试助手这个具体项目中，我最终选择了语义分块方案，并搭配了百炼平台的嵌入模型。选择原因在于：测试需求文档中充满精细的技术参数和因果关系，语义完整性一旦被破坏，后续的测试理解就会频繁出错，得不偿失。

Settings.embed_model = dashscope_embed_model()
# 语义分块配置
Settings.node_parser = SemanticSplitterNodeParser(
    buffer_size=128,  # 保留128 tokens重叠区域
    breakpoint_percentile_threshold=95,  # 95%阈值自动寻找最佳分割点
    embed_model = dashscope_embed_model()
)

技术反思

语义分块在保持概念完整性上确实表现突出，但计算资源消耗也不小，并且无法主动利用文档自身已有的结构特征（比如Markdown标题）。因此，我正在规划一个混合分块策略：对于Markdown/HTML等结构清晰的文档，使用结构感知分块；对于纯文本，继续采用语义分块；资源紧张或场景简单时，则用固定长度分块兜底。这套混合方案具体能带来多少性能提升，后续会拿出实际数据单独分析。

结语

文档分块技术，表面上看不过是RAG（检索增强生成）系统构建流程中一个不起眼的预处理环节，但它在很大程度上决定着整个系统的检索效果和生成质量。选对分块策略，远不只是对着对照表挑一个最高分选项，而是需要认真审视自己的应用场景、文档属性和资源约束后，做出的一连串权衡与取舍。可以说，把分块这件事真正想透，AI知识库就成功了一半。