第4部／全8部 — RAG 記事シリーズ
チャンキングは設計上の判断である
第3部では、取り込み（ingestion）が埋め込み（embedding）を行う前にドキュメントをチャンクに分割することを示しました。ほとんどのチュートリアルは「チャンクサイズ」—512トークンがよく使われます—を選んで先に進みます。これは、すべてのドキュメントが同じ見た目である場合にうまく機能します。TechNovaのドキュメントは同じ見た目ではありません。そしてその違いこそが、チャンク分割の判断が重要になり始めるポイントです。
ファームウェアの変更履歴は、バージョン項目のフラットなリストです。トラブルシューティングガイドは、セクション見出しの下に番号付きの手順があります。製品仕様ページには比較表があります。各ドキュメントは内部構造が異なり、同じチャンク分割戦略でも壊れ方（分割結果の破綻の仕方）が異なります。チャンク分割はオン／オフできる設定ではありません。ドキュメントが実際にどのように見えるかに依存します。これらのファイルはコンパニオンリポジトリで確認できます—第5部で各ファイルを詳細に説明します。
固定サイズ、再帰的、セマンティックなチャンク分割
固定サイズのチャンク分割は、コンテンツに関係なく常にNトークンごとに分割します。高速で予測可能で、デバッグも容易です。一方で、構造に目がありません。TechNovaのBluetoothペアリング手順が、トークン数がその位置に落ちることでステップ3とステップ4の間で切れてしまうかもしれません。チャンク境界は「手順を分割している」ことを理解していません。
以下は、TechNovaのトラブルシューティングガイドにあるその手順です（完全なファイルはコンパニオンリポジトリの data/troubleshooting-guide.md にあります）：
- 端末で設定（Settings）→Bluetoothを開きます。
- 保存済みのデバイスから「WH-1000」を削除します。
- WH-1000の電源ボタンを7秒間押し、LEDが青く点滅するまで待ちます。
- 端末のBluetooth一覧に「WH-1000」が表示されたら選択します。
- 音声を再生する前に「接続済み（Connected）」の確認を待ちます。
512トークンのチャンク分割は、この5つのステップが一まとまりになっていることを知りません。トークンのストリームを見て、サイズで切ります。サイズの境界がステップ3の後に来ると、一つのチャンクにはステップ1〜3（設定を開く、デバイスを削除する、ペアリングモードに入る）が入り、もう一つにはステップ4〜5（デバイスを選択する、接続を確認する）が入ります。ステップ1〜3はヘッドホンを切断します。ステップ4〜5は再接続します。「Bluetoothが切断されるのをどう直せばいい？」と質問するユーザーには、最初のチャンクだけが返される可能性があります。つまり「Bluetooth接続をどう解体するか」は分かるが、「どう復元するか」は一切分からない答えです。
固定サイズのチャンク分割が最もうまく機能するのは、構造が一貫して均一なドキュメントです。たとえばファームウェアの変更履歴のように、各項目が自己完結したバージョンノートになっている場合です。
再帰的なチャンク分割は、ドキュメントの構造で分割します。まずセクションで分け、次に段落で分け、セクションがまだ長すぎる場合は文で分けます。ドキュメントがもともと持っている境界を尊重します。TechNovaのトラブルシューティングガイドは、H2見出しと番号付きのステップがあるため、セクション境界に沿ってきれいに分割されます。各チャンクは、完全な手順、または完全なトピックになります。これは多くのチームにとって実務上のデフォルトです。なぜなら、多くのドキュメントには見出し、段落、リストの境界といった何らかの構造上の目印があり、再帰的な分割はそれらを活用できるからです。
セマンティックなチャンク分割は、埋め込みを使ってトピックの切り替わりを検出します。構造上の目印に頼る代わりに、連続する文の類似度を測り、意味が変わるところで切ります。構造上の目印が本当に存在しないドキュメント—見出しやセクション区切りがない長い非構造のトランスクリプトで、パラグラフの途中でトピックが切り替わるようなケース—では役に立つことがあります。しかし、形式が混在しているドキュメントがある場合に、最初に到達すべき手段ではありません。TechNovaの製品仕様（コンパニオンリポジトリの data/product-specs.html を参照）には表と文章があります—これはチャンク分割の問題というより解析（パース）の問題です。生のHTMLをテキストスプリッタに渡すと、表の行が列見出しから分離されてしまい、チャンクが「8時間」を含んでいても、それがどの商品・どの仕様を指すのか分からなくなることがあります。構造に対応したパーサーで処理したうえで、再帰的なチャンク分割を行うのが通常の解決策です。セマンティックなチャンク分割は、よりコストが高く、デバッグが難しく、結果が一貫しないことがあります。再帰的なチャンク分割だけでは十分でないと分かった場合のエスカレーションとして扱い、「複雑そうに見えるものなら何でも」デフォルトにするべきではありません。
まずシンプルに始めましょう。チャンク分割戦略のことを考える前に、ドキュメントをうまくパースすることです—表、見出し、リストを先に扱います。次に、再帰的なチャンク分割をデフォルトとして使います。もしチャンク境界が手順を分割したり、事実から文脈を切り離してしまうなら、オーバーラップ（重なり）を追加します。セマンティックなチャンク分割は、そのドキュメントが本当に構造上の目印を欠いており、さらに評価の結果、再帰的分割が十分に機能していないことが示されたときにのみ検討してください。
追加のチャンク分割パターン—階層的（親／子）チャンク分割、コンテキスト付きチャンク分割など—は、ベースとなるパイプラインが動き始めてから関係してきます。これらは第8部で扱います。
レイト・チャンク（後ろ倒しチャンク）：異なる順序
知っておく価値のある新しいアプローチがあります。各チャンクを先に分割してからそれぞれを埋め込むのではなく、レイト・チャンク（late chunking）は順序を反転します。まず全文を埋め込みます—つまり、周囲の文脈が各トークンに行き渡るようにしたうえで—その後で分割します。各チャンクは、ドキュメント内の他の場所を指していた指示語、見出し、参照を覚えています。
2025年の研究ではトレードオフが見つかりました。コンテキスト付きのリトリーバルは、より多くのセマンティックな一貫性を保てる一方で計算コストが高くなります。レイト・チャンクはその逆で安価ですが、関連性をいくらか失う可能性があります。最適化の前に理解すべきベースラインが必要になるため、まず標準のチャンク分割を説明します。レイト・チャンクは、ベースラインが機能していることが確認できてから評価するものです—最初に始めるものではありません。
オーバーラップの問題
オーバーラップのないチャンクは、境界で情報を失います。先ほどのBluetooth手順がそのコストを示しています。あるチャンクのステップ1〜3と、次のチャンクのステップ4〜5です。どちらのチャンクにも手順全体が含まれていません。リトリーバ（retriever）はそのうちのどちらかを返し、モデルは不完全な回答を生成してしまいます。
オーバーラップとは、次のチャンクの先頭で、各チャンクの末尾2〜3文を繰り返すことです。これで両方のチャンクがステップ3を含むため、リトリーバがどちらを返しても、手順の残りとつなげるのに十分な文脈が揃います。トレードオフは確かに存在しますが、管理可能です。保存量が増えることに加え、オーバーラップしている2つのチャンクが両方とも取得される可能性があり、その結果としてほぼ同一の文脈が得られるかもしれません。実務では、2文のオーバーラップは妥当なデフォルトであり、多くのチームがまず採用し、ほとんど変更する必要がありません。
これは、このシリーズ全体を通して目にするパターンに接続します。RAGシステムが曖昧または言い回しをぼかした回答を生成するとき――たとえば「返品ポリシーは商品の種類によって異なる可能性があります」のように、具体的な数値ではなく――それは通常、チャンク分割（chunking）の問題です。チャンクが広すぎる、一般的すぎる、あるいは必要な特定の事実が薄まるような分割になっているためです。出力に症状は見えますが、修正は取り込み（ingestion）パイプラインの上流側で行う必要があります。第7部では、このような症状を中心に完全な診断フレームワークを構築します。
検索（Retrieval）— キーワード、セマンティック、またはハイブリッド
チャンク分割は、リトリーバーが何を見つけられるかを決めます。検索アプローチは、どのように検索するかを決めます。選択肢は3つあり、それぞれ強みが異なります。
用語ベースの検索（Term-Based Retrieval：BM25）
BM25は厳密な用語に一致します。ユーザーが「WH-1000 返品ポリシー」と尋ねると、BM25はその言葉を含むすべてのチャンクを見つけ、コーパス内でそれらの用語がどれだけ特徴的かに基づいてスコア付けします。高速で、埋め込みモデルを必要とせず、ユーザーが適切な語彙を知っている精密で具体的な問い合わせに特に強力です。
ユーザーがドキュメントと同じ言葉を使わないと失敗します。「ヘッドホンを返品できますか？」には「return」も「policy」も含まれていません。BM25は有用な結果を返しません。情報はインデックスに存在します。ただ、クエリが用語として一致していないだけです。
埋め込みベースの検索（Embedding-Based Retrieval）
埋め込みベースの検索は、用語ではなく意味で一致します。「ヘッドホンを返品できますか？」と「返品ポリシー：納品日から15日間」は、重要な語が共通していないかもしれませんが、意味としては似ています。埋め込みモデルがその類似性を捉えるため、リトリーバーは適切なチャンクを見つけます。
弱点は反対側にあります。「WH-1000 のバッテリー寿命」と「WH-500 のバッテリー寿命」は、埋め込みモデルが両方を「ヘッドホン製品のバッテリー寿命」として扱うため、ほぼ同一に近いベクトルになる可能性があります。モデルが、WH-1000とWH-500が仕様の異なる別製品だと理解していないと、誤った製品のチャンクを返してしまうことがあります。セマンティック検索は柔軟ですが、厳密な区別における精度を失いがちです。
ハイブリッド検索と相互順位統合（Reciprocal Rank Fusion）
両方を実行します。BM25とベクトル検索は同じクエリに対して並行して動作し、それぞれが順位付きのリストを生成します。相互順位統合（Reciprocal Rank Fusion）は、生のスコアではなく順位位置によって2つのリストを統合するため、両アプローチが同じように寄与します。
結果として、「WH-1000 返品ポリシー」はBM25が厳密な用語を拾うのでうまく取得できます。「ヘッドホンを返品できますか？」はベクトル検索が意味を拾うのでうまく取得できます。どちらか一方だけでは両方のクエリを扱えません。組み合わせることで、お互いの不足を補います。
ハイブリッド検索は、生産環境のRAGシステムにおける実用的なデフォルトです。 実装の複雑さが増えます（1回ではなく2回の検索パスを実行するため）が、最も一般的な検索失敗を解消します。ベクトル検索だけで始めた多くのチームは、完全一致（厳密な用語一致）が見つけていたケースを目の当たりにすると、ハイブリッドへ移行します。
1つの質問、3つの設定
なぜこれらの判断が重要なのかを理解するために、TechNovaのトラブルシューティングガイドに対する1つの質問を考えてみます：「私のWH-1000がBluetoothから切断され続けます。どうすればいいですか？」
設定A：固定サイズのチャンク分割（512トークン）、ベクトルのみで検索。 トラブルシューティングガイドのBluetoothセクションには番号付きの手順が5つあります。512トークンの境界は、手順3と手順4の間にあります。リトリーバーは手順1〜3を含むチャンクを返します。モデルは手順を開始しますが途中で止まる回答を生成します：「まず、設定に行ってデバイスを忘れてください。次にBluetoothを再度有効にして…」。回答は途切れるか、モデルがもっともらしいが誤った次の手順を補完します。読者には、完結して見えるものの不完全な手順が提示されます。
設定B：オーバーラップ付きの再帰的チャンク分割、ベクトルのみで検索。 再帰的チャンクャーは、5つすべての手順を1つのチャンクに収めます。モデルは完全な回答を生成します。しかしクエリは「Bluetooth troubleshooting（Bluetoothのトラブルシューティング）」ではなく「切断され続ける」と言っています。さらに、ベクトルのみのリトリーバーは、ときにBluetoothの安定性改善に関するファームウェアの変更履歴エントリを返してしまいます――埋め込みが十分近いために混乱させられるのです。
設定C：オーバーラップ付きの再帰的チャンク分割、ハイブリッド検索（BM25 + ベクトル + RRF）。 チャンクは設定Bと同じです。しかし今回はBM25も実行され、「WH-1000」や「Bluetooth」を厳密な用語として拾うため、検索が正しい製品のトラブルシューティングセクションに固定されます。ファームウェアの変更履歴エントリは、トラブルシューティング手順ではなく「修正」を扱っているため、順位が落ちます。モデルは正しい完全な手順を受け取り、完全な回答を生成します。
同じ質問です。3つの設定。3つの異なる回答。モデルは毎回同じでした。変わったのは、モデルがクエリを見る前に行われたチャンク分割と検索（retrieval）の判断です。
リランキング（Reranking）— 意味のある2回目のパス
最初の検索パス――BM25でもベクトル検索でもハイブリッドでも――は速度の最適化が優先されます。候補を素早く返しますが、「最も類似している」が「常に最も関連性が高い」とは限りません。WH-1000のBluetooth仕様に関するチャンクは、Bluetoothのペアリング問題についての質問では、用語や概念の重なりのために高順位になる可能性があります。しかしユーザーが必要としているのは仕様書ではなく、トラブルシューティングの手順です。
リランキングャーはクロスエンコーダモデルで、各候補チャンクを元のクエリと一緒に読み込み、そのチャンクが実際にどれだけ質問に答えているかをスコア付けします。最初のパスよりも遅く、コストも高いので、インデックス全体ではなく上位10〜20件の候補に対してのみ実行します。最初のパスでは候補を素早く集めます。2回目のパスで、実際の関連性に基づいてそれらを並べ替えます。組み合わせることで、どちらか単独よりも良い結果が得られます。
いつリランキングを追加するか：検索結果が適切な近傍（right neighborhood）には入っているのに、正しい順序になっていないときです。正しいチャンクは上位10件には入っていることが多いものの、1位に来ることは稀です。リランキングャーは最良の回答を上位に押し上げます。初期の構築後にチームが行う改善の中でも、価値が高く、手間が比較的小さいものの1つです。
最適化する前に評価する
あるチームは、汎用の埋め込みモデルからドメイン固有のモデルへ切り替え、検索が改善すると期待しました。デプロイします。すると顧客満足度が下がります。問題の追跡には2週間かかりました。新しいモデルはTechNovaの製品コードを別の方法で埋め込み、WH-1000に関するクエリが今ではときどきWH-500のコンテンツを取得するようになっていたのです。モデル変更によって検索が悪化したにもかかわらず、変更前後の測定は誰も行っていませんでした。
検索品質を測定できないなら、改善はできません。 この記事にあるあらゆる判断――チャンク分割戦略、検索アプローチ、リランキング――は実験です。測定なしでは、当て推量になります。
この段階で最も重要なのは2つの指標です。コンテキストの精度（Context precision）： 取得したチャンクのうち、どれだけが実際に質問に関連していたか？ 返ってきた5つのチャンクのうち3つが役に立つなら、精度は60%です。コンテキストの再現率（Context recall）： 知識ベース内の関連するチャンクすべてのうち、どれだけを取得できたか？ 答えに2つのチャンクが必要で、その両方を見つけられたなら、再現率は100%です。精度は、取得に含まれるノイズがどれくらいかを示します。再現率は、取りこぼしているシグナルがどれくらいあるかを示します。
小さく始めましょう。正しい答えが分かっている20〜50件のクエリと、取得されるべきチャンクを用意します。取得を実行し、精度と再現率を測定し、変更の前後で比較します。第7部では、この土台の上に完全な診断用フレームワークを構築します。
もう1つ知っておくべきレバーがあります。製品ID、ドキュメントタイプ、バージョン番号などのメタデータをチャンクにタグ付けすることで、取得（リトリーバル）の前にフィルタリングできるため、リトリーバはインデックスの関連する一部だけを検索します。この内容は第8部で、生産（プロダクション）上の懸念事項を取り上げる際に再度触れます。
Three Takeaways
チャンク分割は、ドキュメントに左右される設計判断であり、固定のデフォルトではありません。 ドキュメントによって異なる失敗パターンが生まれます。再帰的チャンク分割から始め、評価で必要だと分かったときだけ段階的にエスカレートしてください。
ハイブリッド検索（キーワード + セマンティック）は、本番システムにおける実用的なデフォルトです。 BM25は厳密な用語を拾います。埋め込み（Embeddings）は意味を捉えます。両者を組み合わせることで、お互いの不足を補えます。
取得品質を測定できないなら、改善もできません。まず評価してください。 変更の前後で必ず測定します。第7部ではその方法を示します。
エンジニアリング上の判断は明確です。あとは作り始めるだけです。第3部で扱ったパイプラインモデルと、この記事の意思決定フレームワークがあります。第5部ではそれらをまとめます。TechNovaのドキュメントを使い、ゼロから構築する実働のRAGシステムです。
次：ゼロからRAGシステムを構築（第5部/全8部）—近日公開。
