告別傳統(tǒng)的文檔切塊！JinaAI提出Late Chunking技巧
今天給大家分享JinaAI提出的一個新的技巧。
正常在處理大規(guī)模數(shù)據(jù)建索引的時候，一般我們需要先對文檔進(jìn)行分塊，建立向量索引。 而這個分塊大小，設(shè)置的都是比較短的，比如512。 一方面是早期bert的處理長度的限制，另一個方面是如果文本太長，包含的信息就越多，那么可能比較難用一個向量來表征出來。
圖片
對于前者，如果持續(xù)關(guān)注向量模型的同學(xué)可以發(fā)現(xiàn)，無論是開源的BGE系列，還是閉源的API，都在往一個較長的上下文靠齊（比如說8192）。那這就有一些矛盾了，如果工業(yè)界只需要512的上下文的向量模型，為什么還要往更長的8192模型發(fā)展呢？
對于傳統(tǒng)的分塊，類似于固定長度的分塊。帶來的一個比較大的問題是，上下文缺失。就像下圖一樣，一個句子的主語在段落開頭，后面的段落/句子中，有一些代詞比如 It's， The city等等來表示主語。這種情況下確實主語的句子基本上就變得比較斷章取義了~
圖片
與先分塊后向量化不同，JinaAI最新提出的“Late Chunking”方法是一個相反的步驟，首先將整個文本或盡可能多的文本輸入到嵌入模型中。在輸出層會為每個token生成一個向量表示，其中包含整個文本的文本信息。然后我們可以按照需要的塊大小對對向量進(jìn)行聚合得到每個chunk的embedding。這樣的優(yōu)勢是，充分利用長上下文模型的優(yōu)勢，同時又不會讓每個塊的信息過多，干擾向量表征。
圖片
在測試中，在所有情況下，與常規(guī)的分塊相比，Late Chunking提高了召回ndcg@10。在某些情況下，它的性能也優(yōu)于將整個文檔編碼為單個嵌入。并且，文檔越長，Late Chunking策略就越有效。
圖片
本文轉(zhuǎn)載自 ??探索AGI??，作者： 獼猴桃
