親ドキュメントと大規模な検索

固定サイズのチャンク化ではトレードオフが必要になります。小さな塊、たとえば数文は、シャープな埋め込みを生成します。ベクトルは 1 つのアイデアを表すため、そのアイデアに関するクエリはそれによく一致します。しかし、2 文のチャンクには、モデルが適切に応答するのに十分なコンテキストが含まれていることはほとんどありません。 3 段落前の定義や次の文の例外を省略することもできます。大きなチャンクにはそのコンテキストが含まれますが、その埋め込みによっていくつかのアイデアがぼやけてしまうため、検索の精度が低下し、関連する文章が単に主題に沿ったチャンクによって優先される可能性があります。大規模な取得から小規模の取得まで、2 つのジョブが分割されます。システムは検索用に小さな子チャンクにインデックスを付け、各子はより大きな親 (セクション、ページ、または文書全体) へのポインターを保持します。クエリ時に最適な子を見つけて、その親を検索して返します。複数の子が 1 つの親を共有する場合、親は 1 回送信され、重複も削除されます。 LangChain の ParentDocumentRetriever は、子のベクトル ストアと親の別のドキュメント ストアを使用してこれを実装します。 LlamaIndex は、関連するパターンを提供します。文ウィンドウ検索は、一致した文と一定数の隣接する文を返します。自動マージ検索は、取得した多くのリーフ チャンクが一致した場合に共有の親ノードに置き換えます。このアプローチは、意味が周囲のセクションに依存する、マニュアル、契約書、ポリシー、教科書などの構造化文書の固定サイズのチャンク化に勝る傾向があります。ドキュメントがすでに短い場合、または親が大きすぎて一部のドキュメントがコンテキスト ウィンドウからはみ出したり、回答が無関係なテキストに埋もれたりする場合には、あまり役に立ちません。よくある誤解は、これは単により大きなチャンクを使用しているだけであるということです。そうではありません。検索ユニットと生成ユニットのサイズが意図的に異なるため、コンテキストのモデルを枯渇させることなく正確な一致を維持できます。