文本分块:超越基础 RAG
在 RAG 中,将文本分割成块是提高检索效率的关键。但分割方法不止一种。有些方法快速且…

在 RAG 中,将文本分割成块是提高检索效率的关键。但分割方法不止一种。有些方法快速粗糙;其他方法则更深入地保留文本含义。
本文将探讨为何分割很重要,分解从基本的字符切割到AI驱动分割的不同技术,并提供实际示例,帮助你理解。
为何需要分割?
直接对长文本进行模型推理存在一些明显的局限性
- 有限的上下文大小:模型有最大输入大小限制。
- 随大小增加而下降的准确性:即使是长上下文模型,当输入过长时也可能表现不佳。
- 黑盒检索:直接推理更难控制“检索”的内容;你依赖于模型的判断。
- 成本:重复处理大量文本可能会变得昂贵,特别是当多个问题需要相同上下文时。
分割将数据分解成块,使你能够在馈送大型语言模型之前只检索所需的内容。这种方法更经济、更高效,并且可以完全控制检索的信息。
分割技术:如何选择?
好的,我们确实需要分割,但也知道不同的技术有不同的优势。这里快速介绍其中一些技术
基于字符的分割:快速简单。你设置一个字符限制进行切分。适用于粗略、快速的分割,但可能打断句子。例如,每十个字符或在找到的每个句号 .
处进行分割。
递归字符分割:首先在较大的边界(段落、句子)处分割,然后深入。保持块的可读性和连贯性。逐步使用较小的分隔符,如 \n
,然后是 .
,再是 ;
。
语义分割:使用嵌入(embeddings)基于含义进行分割,将相关内容保持在一起。它使用基于语义/结构假设的聚类技术——例如,同一块内的部分应比不同块内的部分更相似。
基于正则表达式的分割:基于日期或特定关键词等模式进行分割,非常适用于结构化数据。
基于 LLM 的分割:一个经过提示的 AI 模型根据内容流动态决定在哪里进行分割。
💡 如需深入了解,这里推荐 Greg Kamradt (Data Indy) 的一个视频:文本分割用于检索的 5 个级别
重叠
在不同块之间进行文本重叠有助于保持连续性,通过在连续的块之间提供一个共享的参照点。这种重叠确保模型在读取每个新块时,都与前一个块有直接联系,从而有助于传递重要的细节和上下文。
- 平滑过渡:重复的部分将关键信息从一个块带到下一个块,因此模型可以理解过渡,而不会丢失当前主题的线索。
- 避免信息丢失:如果一个关键细节恰好位于块的边界,重叠可以确保该细节出现在两个块中,从而避免被忽略或遗忘。
跳出固有思维
分割可以根据你的用例而独特。使用任何适合你数据的功能、模式或结构。目标是创建连贯且有意义的段落,以最大限度地提高检索的准确性和效率。
例如,HTML 内容可以按 <h1>
或 <h2>
等标签进行分割,这有助于保留网页结构以便检索。
<h1>Introduction</h1><p>This is the first paragraph.
</p><h2>Section 1</h2><p>Content under section 1.</p>
- Chunk 1:
<h1>Introduction</h1><p>This is the first paragraph.</p>
- Chunk 2:
<h2>Section 1</h2><p>Content under section 1.</p>
这使得每个 HTML 部分保持完整,对于网页摘要或将内容提取到 JSON 等结构化数据格式非常有用。
或者,如果你处理音频转录,你可能希望按说话人进行分割,以捕获对话的不同部分(例如,“说话人 1:”或“说话人 2:”),并在说话人每次变化时进行分割。
Speaker 1: I think we should proceed with the project.
Speaker 2: I agree, but we need to check the budget.
Speaker 1: Budget shouldn't be an issue.
- Chunk 1:
Speaker 1: I think we should proceed with the project.
- Chunk 2:
Speaker 2: I agree, but we need to check the budget.
- Chunk 3:
Speaker 1: Budget shouldn’t be an issue.
这保留了对话结构,当你需要特定的对话部分时,可以进行更好的上下文检索。注意,在这里,我们可以根据应用决定是否保留分隔符。
平衡检索和摄取成本
在设计 RAG 流水线时,请记住,在大多数情况下,摄取(ingestion)只发生一次,而检索(retrieval)则发生多次。在摄取过程中花费更多时间和资源可能意味着在检索过程中获得更高的准确性和效率。
但这之间有一条微妙的界限——过度投入摄取(例如使用先进的语义模型或 LLMs 分割每个文档)可能会导致不必要的成本,如果检索频率较低,或者即使使用场景足够简单。
从简单开始
不要过度设计。从基本方法开始,比如基于字符或特定于文档的分割,只有在能带来明显价值时才转向高级技术。保持简单意味着更快的原型开发和更容易的调试。
在 Langflow,我们正在构建从 RAG 原型到生产的最快路径。它是开源的,并提供免费的云服务!请访问 https://github.com/langflow-ai/langflow 查看 ✨