8月7日、n8nが「Methods, Evaluation, and RAG Performance」と題した記事を公開した。RAGパイプラインにおけるセマンティックチャンキングの手法・評価・パフォーマンス改善について詳しく解説した内容で、モデル選定に目が向きがちな実装者に対し「チャンキング設計こそが回答品質の鍵」と訴える内容になっている。
「チャンキングはただの前処理」という認識が品質を下げる
RAG（Retrieval-Augmented Generation）パイプラインを構築する際、モデル選定に注力する一方で、ドキュメントの分割方法（チャンキング）が軽視されがちだ。しかし、チャンキングの設計次第で、何が検索され、LLMにどれだけのコンテキストが渡り、回答の精度がどうなるかが変わる。
ここでいうリトリーバーとは、ユーザーのクエリに対してベクトルDB（埋め込みベクトルを高速検索するためのデータベース）から関連チャンクを取り出すコンポーネントのことだ。リトリーバーが返すチャンクの質が低ければ、どれだけ高性能なLLMを使っても回答は改善しない。
典型的な失敗例として記事が挙げるのが「レート制限の検索」だ。制限値そのものと例外事項が別々のチャンクに格納されると、リトリーバーは答えの半分しか取得できない。このような意味の断絶は、チャンク境界の設計ミスが直接引き起こす問題だ。
5つのチャンキング手法とその使い分け
固定サイズチャンキング
トークン数または文字数で機械的に分割する最もシンプルな手法。実装が容易で処理速度も速い。ただし文や段落の途中で切れることがあり、意味的なまとまりが壊れるリスクがある。構造の一貫したコンテンツに対するベースラインとして有効で、まず動くものを作りたいときの出発点になる。
再帰的文字分割
見出し・段落・文といった自然な区切りを優先してから、チャンクサイズの上限に達した場合により小さな単位にフォールバックする手法。LangChainのRecursiveCharacterTextSplitterがこの実装の代表例として広く知られている。固定サイズよりも境界がきれいになり、複雑さもほどほどに抑えられるため、多くのプロダクション環境で実用的な選択肢として採用されている。
構造認識分割
Markdownファイル・APIドキュメント・技術マニュアルなど、ドキュメント自体が見出しや節で構造を持っている場合に有効。既存の構造をそのままチャンク境界として利用することで、取得後のチャンクが単体で意味を持ちやすくなる。たとえばMarkdownの##見出しを境界として使う場合、各チャンクは必ず一つのセクションに対応する形になる。
埋め込みベースのセマンティックチャンキング
テキストを埋め込みモデル（テキストを数値ベクトルに変換するモデル。OpenAIのtext-embedding-3-smallやCohereのembed-v3等が代表例）でベクトル化し、ベクトル類似度によって意味の転換点を検出して新しいチャンクを開始する手法。非構造化テキストで特に高品質な検索結果をもたらすとされる一方、インデックス作成時に追加の計算コストが発生する。
なお、NAACL 2025の研究（Dunn et al., 2025）では「セマンティックチャンキングの追加計算コストに対して改善幅は限定的であり、シンプルな手法と大差ない場合がある」との指摘があり、記事もこれを引用している。高コストな手法を盲目的に採用する前に、まずシンプルな手法で十分かどうかを検証することが推奨される。
コンテキストチャンキング
隣接セクションとの関係性を保持することで、取得後のチャンクが単体で意味を持てるよう工夫する手法。たとえばあるチャンクに「前後のセクションの要約」をメタデータとして付与することで、リトリーバーが単一チャンクを返した場合でもLLMが十分なコンテキストを得られるように設計する。複雑なドキュメントでの検索精度を高める一方でインデックスの複雑さが増すため、すべてのRAGパイプラインに必須ではなく、シンプルな手法で検索精度が頭打ちになった段階で検討する手法と位置づけられている。
実装で差がつく4つのプラクティス
記事が強調するのは「チャンキング手法の選択」よりも「実装後の反復改善」だ。Pineconeのチャンキングベストプラクティスでも同様の考え方が示されており、業界全体で共通認識になりつつある。
- コンテンツに合わせた手法を選ぶ：技術ドキュメントは構造認識分割、研究論文や長文記事はセマンティック境界が有効。まずドキュメントの構造を観察することから始める。
- チャンクサイズだけを最適化しない：「理想のチャンク長」は存在しない。各チャンクが単体で質問に答えられるかどうかを判断基準にする。
- インデックス速度ではなく検索性能を測る：代表的なクエリで検索結果を比較し、コンテキストの欠落や無関係な一致がないかを評価する。チャンク境界の小さな変更が回答品質に大きく影響することがある。
- ワークフローに組み込む：ドキュメントや埋め込みモデル、検索要件が変化すれば、チャンキング戦略も更新が必要になる。一度設定して終わりではない。
n8nを使った実装例
記事では、社内ドキュメント向けRAGチャットボットの構築例が紹介されている。n8nのワークフローでは以下のような構成が示されている。
- データ取り込みノード：Google DriveノードやDBコネクタでドキュメントを読み込む
- 分割ノード：Markdownドキュメントにはヘッダー区切りを優先した再帰的文字分割を適用し、長文ガイドには幅広い再帰分割（チャンクサイズ大）を使い分ける。n8nの「Text Splitter」ノードでこれらのパラメータを設定できる
- 埋め込み生成ノード：OpenAI EmbeddingsノードやCohereノードで各チャンクのベクトルを生成する
- ベクトルDB格納ノード：PineconeノードやSupabaseノードを使って埋め込みを格納する
- 実行履歴・評価ノード：クエリと取得チャンクの対応をログに残し、チャンキング戦略の継続的な改善に役立てる
ワークフローがモジュール型になっているため、コンテンツや検索要件が変わっても、パイプライン全体を再設計せずに分割ノードの設定だけを変更して対応できる点が特徴として挙げられている。
まとめ
記事が一貫して訴えているのは、「最も高度な手法を盲目的に採用するより、反復改善の方が品質向上への影響は大きい」という点だ。まず自分のコンテンツと要件に合った最もシンプルな手法から始め、実際のクエリで評価し、改善を重ねることが推奨されている。NAACL 2025の研究が示すように、セマンティックチャンキングの計算コストが常に見返りをもたらすわけではなく、シンプルな再帰的文字分割で十分なケースも多い。チャンキングを「一度決めたら終わり」の設定ではなく、継続的に調整するコンポーネントとして扱うことが、RAGパイプラインの品質を長期的に維持する上での要点だといえる。
詳細はMethods, Evaluation, and RAG Performanceを参照していただきたい。
