チャンク化とは、誰もが偶然に行う検索の決定です

すべての検索プロジェクトの早い段階で、誰かが数字を入力する瞬間があります。 500 トークン。千。チュートリアルで使用したものは何でも。パイプラインは機能し、デモは質問に答えますが、その数値が再度検査されることはありません。

チャンク化は前処理の詳細ではないため、これには十分な注意が必要です。どのファクトを一緒に取得できるかを決定するのは決定であり、下流でどれほど賢明なランク付けを行っても、チャンク化によって破壊された関係を回復することはできません。

具体的に何がうまくいかないのか

小さすぎるチャンクは、単一のアイデアを複数の部分に断片化します。回答はコーパス内に存在しますが、個々のチャンクには関連性があると思われるほど十分な回答が含まれていないため、何も高スコアは付けられず、代わりにエージェントが独自の仮定に基づいて回答します。

大きすぎるチャンクは、一致した部分とともに無関係なマテリアルを引きずります。取得は成功したように見えますが、コンテキスト ウィンドウはノイズでいっぱいになり、エージェントは微妙に間違った段落に関する何かを生成します。この失敗は、明らかなギャップではなく、自信のある出力を生成するため、最初の失敗よりも悪いです。

どちらの失敗も外から見ると同じように見えます。エージェントが出した答えは、誰もすぐには説明できないような間違ったものです。

構造はサイズに勝る

チームが行った最も有益な変更は、トークン数で考えるのをやめ、ドキュメント構造で考え始めることです。

ポリシー文書にはセクションがあります。サポート アーカイブには、チケットごとに 1 つの問題があります。 API リファレンスには、エントリごとに 1 つのエンドポイントがあります。これらの境界線は、あなたが境界線を必要としているのと同じ理由で、人によってそこに設定されました。境界線は、あるアイデアがどこで止まり、別のアイデアが始まるかを示すものです。主なルールではなくフォールバックとしてサイズの上限を使用してそれらを分割すると、一貫して長さのみの分割よりも優れたパフォーマンスが得られます。

ドキュメントに使用可能な構造がない場合、重複を軽減するのが安価な緩和策です。 1 つまたは 2 つの文を境界を越えて運ぶには、ストレージにかかるコストはほとんどかかりません。また、重要な文が分割を越えて 1 トークンが到達するという特定のケースを救うことができます。

メタデータは過小評価されている

チャンクは単なるテキストではありません。それはテキストに、その文書が属している文書、その上にあるセクションの見出し、文書が書かれた日付、その文書を所有するチーム、その文書が置き換えられたかどうかなど、その文書の出所についてあなたが知っているすべての情報を加えたものです。

このメタデータにより、エージェントはランク付け前にフィルタリングを行うことができ、通常は埋め込みの変更よりも高い精度が得られます。 「コンプライアンス ハンドブックの現在のバージョンを検索する」は、「すべてを検索して、現在のバージョンのスコアが最も高いことを期待する」よりも基本的に簡単な問題です。

また、間違った出力の後に必ず発生する、「これはどこから来たのか」という疑問に対する答えも得られます。出所を伝えるチャンクにより、デバッグが考古学から検索に変わります。

それについて議論するのではなく、評価しましょう

チャンク戦略は、長い意見と短い証拠を生み出す種類のトピックです。解決策はエージェントの仕事の他の場所と同じです。最初に評価を書きます。

人々が実際にシステムに尋ねる 30 ～ 40 の実際の質問と、それぞれの質問に答える文章をまとめます。次に、そのパッセージがまったく検索されるかどうかを測定します。最終的な答えが適切に読み取れるかどうか、つまり検索と生成が混同されているかどうかではなく、適切な資料がモデルに到達したかどうかが重要です。

これを導入すると、チャンク化は議論ではなく実験になります。戦略を変更し、セットを再実行し、より多くのデータを取得するバージョンを維持します。このハーネスを早期に構築したチームは、安価に解決する方法があるため、まとまった議論を完全に行わなくなる傾向があります。

これが実行中のエージェントにどのように接続されるか

取得品質は、エージェントの操作とは別個の関心事ではありません。すべての呼び出しに 200 トークンを追加する取得の変更はコストの変更であり、再現率を向上させる取得の変更は品質の変更です。どちらも、エージェントが行う他のすべてのことと同じ評価ループに属します。

これが、Oran の eval が動作、構造、レイテンシ、コスト基準をまとめてスコアリングする理由であり、Optimizer がそれらの同じ eval に対して独自の変更を測定する理由です。コストを節約するためにコンテキストをトリミングしても、検索で必要なものがまだ見つかった場合にのみ節約になります。

どこから始めるべきか

すでに運用環境に取得システムがあり、評価セットがない場合は、たとえ大まかな評価セットであっても、最初に評価セットを構築します。 1 か月のチューニングよりも午後 1 日で多くのことがわかります。開発者ドキュメントではメカニズムが説明されており、エージェント オーケストレーション システムのページでは、評価レイヤーとコスト レイヤーがどのように適合するかについて説明されています。