Manticore Searchが長文書のベクトル検索を改善、チャンク化を自動処理
Better Vector Search for Long Documents: Chunking Inside Manticore Search
Manticore Searchは、ベクトル列の定義にchunk_strategyを追加するだけで、長文書を自動的にチャンク分割し、各チャンクを個別に埋め込み、検索時に文書単位で結果を返す機能を導入した。truncate、mean、fixed、recursive、sentenceの5戦略を用意。マニュアルでの測定では、モデルの入力窓を超える内容のrecall@5が55.1%から83.3%に向上し、MRRも0.44から0.70に改善。ただしRAMは約2.5倍、取り込み時間は約4倍になる。
モデルは最初の380語を読み、残りの3,600語を捨てた。その地点より後の文書内容は決して取得できず、どこにもそのことが知らされなかった。
HNでの議論
11- entrope
記事の多くは、512トークンの入力制限によって引き起こされる問題に焦点を当てています。例えば、そんなに小さな入力だと、特にオーバーラップがある場合、はるかに多くのチャンクが必要になります。一部の埋め込みモデルには確かにそれほど小さな入力コンテキストを持つものがあることは認識していますが、8Kや32Kはかなり広くサポートされており、チャンク化に関連する問題を減らします。
英語のような言語では、テキスト内に通常多くの冗長性があるため、512トークンではコンテキストを明確に示せないかもしれません。多くのドキュメントには似たような導入部（例えば「#include <foo.h>\n」など）があり、短いコンテキストと切り捨てが特に有害になります。
また、「その地点より後のドキュメント内の何も決して取得できず、どこにもそのことは伝えられなかった」というのは、ユーザーに優しくない動作です。たとえ自動埋め込みサポートが貧弱だったことをユーザーに認めたくなかったとしても。
最後に、切り捨てが「すでに持っているもの」であるという後の段落は、ベンダーがユーザーに話しているようではなく、Claudeが開発者に話しているように読めます。しかし確かに、これはページタイトル、チャットログ、Xeetsを検索するデータベースにとっては良いデフォルトかもしれませんね？
- hn45e7pbij
より大きなコンテキストウィンドウは役立ちますが、チャンク化の必要性をなくすわけではありません。8Kトークンを1つのベクトルに埋め込むとすべてがぼやけ、何も切り捨てられなくても検索品質が低下します。
- Chance-Device
かなり興味深いですね、独自のRAGを構築している人にはきっと役立つでしょう。