今天給大家分享JinaAI提出的一個新的技巧。

正常在處理大規模數據建索引的時候，一般我們需要先對文檔進行分塊，建立向量索引。 而這個分塊大小，設置的都是比較短的，比如512。 一方面是早期bert的處理長度的限制，另一個方面是如果文本太長，包含的信息就越多，那么可能比較難用一個向量來表征出來。

圖片

對于前者，如果持續關注向量模型的同學可以發現，無論是開源的BGE系列，還是閉源的API，都在往一個較長的上下文靠齊（比如說8192）。那這就有一些矛盾了，如果工業界只需要512的上下文的向量模型，為什么還要往更長的8192模型發展呢？

對于傳統的分塊，類似于固定長度的分塊。帶來的一個比較大的問題是，上下文缺失。就像下圖一樣，一個句子的主語在段落開頭，后面的段落/句子中，有一些代詞比如 It's， The city等等來表示主語。這種情況下確實主語的句子基本上就變得比較斷章取義了~

圖片

與先分塊后向量化不同，JinaAI最新提出的“Late Chunking”方法是一個相反的步驟，首先將整個文本或盡可能多的文本輸入到嵌入模型中。在輸出層會為每個token生成一個向量表示，其中包含整個文本的文本信息。然后我們可以按照需要的塊大小對對向量進行聚合得到每個chunk的embedding。這樣的優勢是，充分利用長上下文模型的優勢，同時又不會讓每個塊的信息過多，干擾向量表征。

圖片

在測試中，在所有情況下，與常規的分塊相比，Late Chunking提高了召回ndcg@10。在某些情況下，它的性能也優于將整個文檔編碼為單個嵌入。并且，文檔越長，Late Chunking策略就越有效。

圖片

開源的實驗代碼：??https://colab.research.google.com/drive/15vNZb6AsU7byjYoaEtXuNu567JWNzXOz?usp=sharing&ref=jina-ai-gmbh.ghost.io??

本文轉載自 ??探索AGI??，作者： 獼猴桃