Chunking技巧 告别传统的文档切块！JinaAI提出Late

当天给大家分享JinaAI提出的一个新的技巧。

反常在解决大规模数据建索引的时刻，普通咱们须要先对文档启动分块，建设向量索引。 而这个分块大小，设置的都是比拟短的，比如512。 一方面是早期bert的解决长度的限度，另一个方面是假设文本太长，蕴含的消息就越多，那么或者比拟难用一个向量来表征进去。

关于前者，假设继续关注向量模型的同窗可以发现，无论是开源的BGE系列，还是闭源的API，都在往一个较长的高低文靠齐（比如说8192）。那这就有一些矛盾了，假设工业界只有要512的高低文的向量模型，为什么还要往更长的8192模型开展呢？

关于传统的分块，相似于固定长度的分块。带来的一个比拟大的疑问是，高低文缺失。就像下图一样，一个句子的主语在段落扫尾，前面的段落/句子中，有一些代词比如 It's， The city等等来示意主语。这种状况下确实主语的句子基本上就变得比拟断章取义了~

与先分块后向量化不同，JinaAI最新提出的“Late Chunking”方法是一个同样的步骤，首先将整个文本或尽或者多的文本输入到嵌入模型中。在输入层会为每个token生成一个向量示意，其中蕴含整个文本的文本消息。而后咱们可以依照须要的块大小对对向量启动聚合获取每个chunk的embedding。这样的长处是，充沛应用长高低文模型的长处，同时又不会让每个块的消息过多，搅扰向量表征。

在测试中，在一切状况下，与惯例的分块相比，Late Chunking提高了召回ndcg@10。在某些状况下，它的功能也优于将整个文档编码为单个嵌入。并且，文档越长，Late Chunking战略就越有效。

开源的试验代码：​ ​​ ​

本文转载自​​，作者：