节前，我们组织了一场算法岗技术&面试讨论会，邀请了一些互联网大厂朋友、今年参加社招和校招面试的同学。

针对大模型技术趋势、算法项目落地经验分享、新手如何入门算法岗、该如何准备面试攻略、面试常考点等热门话题进行了深入的讨论。

总结链接如下：

《大模型面试宝典》(2024版) 发布！

本文介绍LLM知识问答中文本分块的相关内容。

一、字符切分

Langchain的CharacterTextSplitter，直接按给定的chunk_size（块内最大字符数量）去生硬切分文本块，不考虑文本结构，为了保证文本块之间的上下文联系，基于chunk_overlap（块重叠字符数量）去控制文本块之间的重叠字数，注意，在英文里是按字母数考虑字符数量。当然，也能设置分隔符separator去分割。

图：字符切分

二、句子切分

Llama_index的SentenceSplitter，针对句子层面切分文本块，并且还提供父子节点关系。

三、递归字符切分

Langchain的RecursiveCharacterTextSplitter，默认分割符：[“\n\n”, “\n”, " ", “”]（分别代表段落分隔符、换行符、空格、字符），拆分器首先查找两个换行符（段落分隔符）。一旦段落被分割，它就会查看块的大小，如果块太大，那么它会被下一个分隔符分割。如果块仍然太大，那么它将移动到下一个块上，以此类推。因为某些书写系统没有单词边界，例如中文、日语和泰语等，所以可以增加以下分隔符：[‘\n\n’, ‘\n’, ’ ', ‘.’, ‘,’, ‘\u200b’, ‘，’, ‘、’, ‘．’, ‘。’, ‘’]。

图：递归字符切分

四、按文件风格切分

除了简单的平文本文档，对于其他不同格式的文件（比如HTML, Markdown, PDF等），采用不同的方式切分。比如：

- Markdown： 可以按照#来判断标题级别进行切分，也可以标题块下叠加字符切块；

- Python等代码文件： 可以按照class、def等切分出不同块；

- PDF： 用Unstructured库解析PDF文件，除文本外，表格也能很好抽取出来，由于表格向量化不具备较好的语义信息，一般开发者会将抽取出的表格先做总结，将表格总结向量化加入检索池中，若检索到该表格，则将原始表格喂入LLM内。

- 图片： 有好多做法，比如如果图片具有文本信息，可以直接OCR识别后的文字作为该图片的文本块。如果该图片不具备文本信息，可以用多模态大模型对图片生成图片描述或总结，当然也能用图片embedding，如CLIP。这里不太属于文本分块的讨论范畴，后面会再做分享；

- HTML： 按元素级别拆分文本，并给每个文本块添加元素级别的元数据，能将具有相同元数据的元素组合再一起。

五、语义切分

1、基于Embedding

Langchain的SemanticChunker，由Greg Kamradt提出[1]，有2种方式：

（1）具有位置奖励的层次聚类： Greg想看句子嵌入的层次聚类会如何。但由于发现他选择按句子进行拆分时，有时会在长句子之后出现短小句子。这些尾随的短小句子可能可以改变一个块的含义，所以他添加了一个位置奖励，如果它们是彼此相邻的句子，则更有可能形成聚类。最终结果还不错，但调整参数很慢且不理想；

（2）在连续句子之间找到语义断点： 这是一种遍历方法。先从第一个句子开始，得到向量，然后将其与句子2进行比较，然后比较2和3等等。如果出现向量距离大的断点，如果它高于阈值，那么认为它是一个新语义部分的开始。最初Greg尝试对每个句子进行向量化，但结果发现噪音太大。所以最终选取了3个句子的组（一个窗口），然后得到一个嵌入，然后删除第一个句子，并添加下一个句子。这样效果会好一点。

作者推崇的第二种办法，我总结其主要步骤如下：

1）按分隔符切分出句子sentence；

2）对每个句子，把其前后的句子一起合并成一个窗口的句子组合（即上下文关联，单个句子扩充至3个句子combined_sentence）；

3）将combined_sentence向量化，得到combined_sentence_embedding；

4）计算位置i和位置i+1之间的combined_sentence_embedding的余弦距离distance_to_next，

5）根据余弦距离的分布设置分割阈值，获取断点；

6）基于断点合并句子进文本块中。

图：基于embedding的语义切分

但实际使用还是小心，因为阈值设置不当，容易发送块内字数过多的问题，对后续LLM检索和回答很不利，建议可以根据文档字数，计算number_of_chunks，然后用此参数去调整语义断点的阈值。

2、基于模型

可以用下一句预测（Next Sentence Prediction, NSP）二分类任务的BERT模型，输入前后两个句子，预测句子彼此之间相邻的可能性，若分数低于阈值，说明语义不太相关，可以分割。我们也知道BERT的预训练目标就是MLM（掩码语言建模）和NSP（下一句预测），其中NSP是用[CLS]做二分类预测，所以我们可以直接调用Google的BERT模型 [4]完成基于模型的语义切分方案。

关于利用BERT做文本分割（Text Segmentation）还有很多其他研究，比如：

（1）2020年Google Research提出的《Text segmentation by cross segment attention》：用BERT获取句子表征，然后再输入BiLSTM或Transformer预测每个句子是否为分割边界；

图：《Text segmentation by cross segment attention》

（2）2021年阿里语音实验室在提出的SeqModel模型《Sequence Model with Self-Adaptive Sliding Window for Efficient Spoken Document Segmentation》： 如下图所示，先分句，然后对句子分词，获取token、segment、position embedding后做element-wise求和，再加上发音embedding后喂入BERT编码器，对输出做平均池化，接入softmax输出分类判断每个句子是否为段落边界。为什么加入发音embedding？因为该模型提出的出发点是解决对长会议ASR生成的文本缺乏段落结构的问题。像ASR会出现写转写错误，比如发音相似但含义不同的声学混淆词等。所以把字的发音信息（通过中文发音表查）来增强文本分割模型输入的表征向量（即phone embedding）。

同时，提出了自适应滑窗提升推理速度，就是基于模型预测的段落分割点，去滑动窗口，如下图所示。

图：《Sequence Model with Self-Adaptive Sliding Window for Efficient Spoken Document Segmentation》

以上阿里的SeqModel开源了，我用过SeqModel，说实话一些细节上的体验不是很好，比如带小数点的数字会被误切分。

六、Agent 式切分

我用可以尝试使用LLM做语义切分，其中被讨论最多是腾讯AI Lab在2023年提出的Propositionizer [2]，它好处在于能解决文本中指代消解的问题，比如"it", “he”, “she”, “they”, “this”, "that”指代的实体全称是什么，而且分解成比句子还更细粒度且信息稠密的命题（Proposition），加入文本分块。效果如下图所示：

图：在Wikipedia文本上，三种不同细粒度的检索单元（其中，a）段落块不超过100个字，句子by句子的添加进段落块，确保句子不被强行字符分割，最后一个块少于50字，会和历史句子合并，避免过于小的段落块。b）句子块用Python的SpacCy en_core_web_lg模型做分句，c）命题块则使用Propositionizer模型）

作者实现Propositionizer的步骤如下：

1）从英文Wikipedia拉取2021-10-13至今的数据；

2）对GPT-4做指令微调（Proposition定义和1-shot展示），将段落块作为输入，要求LLM输出一系列命题；

3）将获取并过滤后的4.3万对”段落-to-命题“，作为种子集微调Flan-T5-large模型。

可惜的是，开源的Propositionizer受限于训练语料，仅支持英文。

七、其他文本块优化点

在实践中，我们常发现一些问题，比如：

（1）上下文的关联信息跨度大或信息稀疏，导致文本块内信息密度低。 举例：聊天记录，或某文章分点记录各内容时，用户向该文章提问有哪些分点内容或层次结构。

（2）标题信息过短，导致文本块向量化后，标题语义信息被文本块内其他内容给模糊了。 具体：某文本块内包含标题5个字，标题下内容有300字。

（3）用户提问内容涉及跨多个文件做检索和整合回答时，大多数文本分块方法不具备跨文件关联。

为了解决以上问题，也有对应一些优化手段。

1、摘要增强

用较大chunk_size去字符切分文本，然后对大文本块用LLM做总结，作为摘要块加入向量数据库中。能在一定程度解决前面提到的问题1。

2、标题增强

将标题下的相应文本块，都加入标题前缀，并且重复多几次标题。如：block = concat(’#’.join([title]*3), content_under_title)。能解决前面提到的问题2。

3、假设性问题生成

基于给定的文本块，生成假设性问题，将生成的问题和对应文本块加入检索内容中。Langchain有个Hypothetical Queries方法[3]可调用。能解决前面提到问题1中的聊天记录场景下的信息稀疏问题。其实说直白了，不就是QA对的生成吗？往往好的QA对比文本块更容易被检索到。想要往这方面深入扩展，可以参考Ragas的TestsetGenerator（一套用LLM生成QA的Prompts工程）。

4、父文档检索器

其实父文档检索器简单理解是利用不同chunk_size去分块，先将原始文档拆分成较大块，再对较大块拆分成较小块，然后对较小块进行索引向量检索，最后返回的是相似度高的较小块下的父文本较大块。这样的好处是：较小块语义含义更精准，其父文本块又能保留到足够长的上下文信息。能解决前面提到的问题1。Langchain有ParentDocumentRetriever，llama_index有HierarchicalNodeParser。

5、知识图谱

如果你的数据具有丰富的实体和实体间的关系，建议转换成知识图谱。如果不想手动整理图谱，可以用Langchain的LLMGraphTransformer，利用LLM解析和分类文本中的实体和实体间的关系。能解决前面提到的问题3。

参考资料

[1] 5_Levels_Of_Text_Splitting - Greg Kamradt, 代码：https://github.com/FullStackRetrieval-com/RetrievalTutorials/blob/main/tutorials/LevelsOfTextSplitting/5_Levels_Of_Text_Splitting.ipynb

[2] Dense X Retrieval: What Retrieval Granularity Should We Use? 论文: [2312.06648] Dense X Retrieval: What Retrieval Granularity Should We Use? (arxiv.org)，代码：https://github.com/chentong0/factoid-wiki

[3] Hypothetical Queries, 文档：MultiVector Retriever | 🦜️🔗 LangChain

[4] Bert - Google, 代码：google-bert/bert-base-uncased ·拥抱脸 (huggingface.co)