この動画は、AI導入における最も重要でありながら軽視されがちなチャンク化技術について詳しく解説している。企業のRAG（検索拡張生成）システムにおいて、不適切なチャンク化が如何に深刻な問題を引き起こすかを実例とともに示し、効果的なチャンク化のための5つの基本原則を体系的に説明している。コード、Excel、法律文書など異なるデータ型に応じたチャンク化戦略の重要性を強調し、企業がAIの真価を発揮するために必要な基盤技術として位置づけている。
チャンク化がもたらした契約トラブル
わしがな、ある金融技術会社の話をしたるわ。その会社、チャンク化をちゃんとせんかったせいで、大きな契約をほぼ失いそうになった話や。チャンク化って何やねん？って思うやろ。チャンク化っちゅうのは、効率的な文脈エンジニアリングやAIでのデータ作業の基盤中の基盤やねん。
つまらん話に聞こえるかもしれんけど、一緒に見ていこうな。チャンク化と埋め込みの重要な原則を説明して、なんでそれが大事なんかを説明するわ。
これな、わしがよう聞かれる一番の質問やねん。人々がデータをAI用に準備せなあかんってことを理解したとたんに言うてくるんや。「よっしゃ、何か必要やな。たぶんRAG、検索拡張生成システムやろな。せやけど、それからどないするんや？」って。
ここでチャンク化が登場するんや。チャンク化って何やねん？テキストを適切なサイズのチャンクに切り分けることができへんかったら、えらい目に遭うで。詳しく説明していくから、しっかり聞いてくれや。
その金融技術会社のAIチャットボット、秘密保持契約の免責条項について聞かれたんや。契約書には「当事者Aが当事者Bを免責する」って一つのチャンクに書いてあって、「第何条で規定される場合を除く」って次のチャンクに書いてあったんや。文の途中で切れてもうたんは、トークン数で機械的にチャンク化してたからや。
それでAIは最初のチャンクだけを取得して、自信満々に「当事者Aが当事者Bを完全に免責する」って答えたんや。これは間違いやったんやけど、これを修正するのにえらい時間とお金がかかったんや。
これな、モデルの知能の問題やないねん。わしは何回もこんなことを見てきた。間違った回答が出ると、人々はChatGPT-5が出たら直るやろって思い込むんや。でも直らへんで、なぜなら文脈エンジニアリングの問題やからや。
データを正しくチャンク化してへんから問題が起きるんや。重要なことやで。わしはRAGを導入する多くの会社にコンサルしてきたけど、これが一番の質問やねん。どの埋め込みモデルを使うべきかやなくて、どうやってデータをチャンク化すべきかっちゅう質問や。それが大事なんや。
幻覚を防ぐにはどうしたらええかっちゅう質問やないねん。実はそれもチャンク化の問題やけど、みんなそう聞き方を知らんだけや。
RAGシステムにおけるチャンク化の役割
チャンク化が全ての基盤やとしたら、全体のパイプラインの中でどう考えたらええんやろか？まず、RAGと検索拡張生成、そしてAIがチャンク化と一緒にどう動いて答えを出すかを簡単に理解しよう。
誰かがAIに質問すると、3つから5つのチャンクが返ってきて、システムはそれを使って答えを組み立てるんや。そのチャンクは、クエリとの意味的な適合度で取得されるんや。もし正しい答えが複数のチャンクに分かれてて、その一部がその3つから5つのチャンクセットから抜けてたら、さっき説明したみたいに正しい答えは得られへん。モデルがどんなに賢くてもあかんねん。
チャンク化はコストにも直接影響するで。悪いチャンク化っちゅうのは、必要な情報を得るために必要以上のチャンクを取得することになる。チャンクを多く取得するっちゅうことは、トークンを多く取得して、コンテキストウィンドウにより多く読み込むことになって、システムを圧迫してしまう。皮肉なことに、意味のないコンテキストがたくさん入ってるせいで、より不正確な回答を生み出すことになるんや。
チャンク化を正しくやることで、企業は主要なモデルメーカーへの請求を大幅に、二桁のパーセンテージで削減できるんや。
もう一回言うで。チャンク化は、モデルの幻覚に対する最初の防衛線の一つやねん。モデルが幻覚を起こすのは、モデル自体が悪いからやと思うやろ。でも実際は、不完全な情報が入った悪いチャンクを与えられた時に、モデルは他に何をしたらええねん？AIが穴を埋めるんや。
それが幻覚の原因やねん。それは本当にチャンク化をちゃんとしてへんあんたらの責任や。
エージェント検索との比較
この時点で手を挙げて「Nate、エージェント検索っちゅうもんを聞いたことがあるで。AIエージェントを使うから、かっこええに違いない。なんでチャンク化せなあかんねん？」って言う人がおるやろな。それは妥当な質問や。
エージェント検索は別の技術やねん。AIエージェントは反復的に検索して、読んで、推論して、また検索することができるんや。チャンク化を完全に回避できるように見えるな。特定の使用例では、それは正しいで。複雑な使用例があって、複数のタイプのデータを同時に推論する場合、エージェント検索は本当に効果的やねん。
探索的なクエリに最適やし、複雑な課題を答えるのにも最適や。例えば「第3四半期のマーケティングキャンペーンの全チャネルでの総合的な影響は何か？」みたいなクエリやな。このようなクエリでは、複数のテーブルを見て、推論して、合計して、数学をして、答えを持って帰らなあかん。その一文にはたくさんのことが含まれてるんや。
RAGはより基盤的で、チャンク化はより基盤的やねん。RAGは高速で経済的な検索の問題を解決するのが得意で、チャンク化はその検索を正確にする方法やねん。チャンク化は野菜を食べるようなもんや。人々はそれを超すごいセクシーな技術やとは思わへんけど、そんなん関係ないねん。
正確な検索と低い幻覚を経済的な価格で実現するか、高い値段を払って遅いエージェント検索を使うかや。どっちも段階的な違いやねん。エージェント検索は良いRAG検索より10倍以上遅くなることがあるし、10倍以上高くなることもあるんや。
エージェント検索を使って埋め込みとチャンク化の難しい会話を回避するために、本当に費用を10倍にしたいんか？実際に数字を計算して座って検討すると、ほとんどの企業はそうしたくないねん。
ここでRAGが勝つんや。RAGは一貫した応答が必要で、それが高速で経済的で、質問が特定の情報に比較的きれいにマップされる場合に勝つんや。答えを検索できる場合、規模でのクエリあたりのコストが重要な場合、予測可能な動作が必要な場合、クエリがしばしば意味関連の検索である場合、これらは全て良いチャンク化戦略が勝つケースやねん。
チャンク化の5つの原則
検索拡張生成システムを構築する時、文書全体をAIに投げ込んで「神のご加護を、頑張れ」って言うわけやないねん。ベクターデータベースに保存されるチャンクに分割せなあかん。
AIはオープンブック試験を受けてるようなもんやな。誰かがその本をページごとに小さなチャンクに破らなあかん。間違って破ったら、AIは文の半分を読むことになるんや。それが頭の中に持っておくべき絵や。AIに本を渡してるけど、それを断片で渡してるんや。
答えを得るために正しい断片を取得させなあかん。悪いチャンク化は大量のRAG失敗の原因やし、現実的な本番パイプラインで何週間も何ヶ月もかかることがあるんや。チームがチャンク化戦略を考え出すのに何ヶ月も費やして、クエリの全ての意味を取得しようと反復に反復を重ねてきたのを見てきたで。
それをあんたらには簡単にしたるわ。わしが始めた時よりもチャンク化の専門家にしたる。わしが何度も何度も機能するのを見てきた効果的なチャンク化の5つの原則を説明するで。
第1原則：文脈の一貫性
チャンク化する時は文脈エンジニアリングをしてるんや。意味を分割したらあかん。AIは取得したチャンクに入ってるもんでしか動けへんねん。「被告は損害を支払わねばならない」を一つのチャンクに分割して、「重大な過失が証明されない限り」を別のチャンクに分割したら、起こるのを待ってる幻覚を作ったことになるんや。
自然な境界を尊重せえ。契約なら、それはセクションとサブセクションやろな。コードなら、関数とクラスかもしれん。コードについてはもうちょっと話すで。コードは面白いケースやねん。会話なら、通常は話者の交代やな。時間窓かもしれん。すべてのデータ型には意味的境界があるんや。時間をかけてそれを見つけて使うんや。
第2原則：3つのレバーを理解する
チャンク化で制御できる3つのレバーがあって、それらの使い方を知っておくんや。境界、サイズ、重複や。
境界は切る場所や。文ごと、段落ごと、セクションごと、意味的に意味のあるものなら何でもええねん。サイズは各チャンクの大きさや。任意のトークン数やない。完全な意味の単位であるべきやねん。重複は保険やねん。AIが契約を幻覚するリスクを避けるために、チャンクに10、15、20%の重複を持たせることがよくあるんや。
ほとんどの人はサイズのことしか考えへん。何千トークンかに設定して終わりにしてまう。そんな世界に住んだらあかんで。そうすると、想像してるAIが読む本のページを単純に破り取ってるだけで、章の区切りやセクションの区切りで破ってへんから、AIは変なところで破られた本を読んで本当に混乱することになるんや。
レバーを知るんや。境界も、サイズも、重複も。全部使って、第1原則の文脈の一貫性を尊重する方法で使うんや。
第3原則：データ型が戦略を決める
法律契約とソースコードでは、チャンク化の仕方が違う。みんなそれは当然やと思うやろうけど、そう考える人は少ないんや。法律契約ではセクションマーカーで分割できるし、それは通常きれいにラベル付けされてるんや。契約の完全な階層をメタデータに含めて、読みやすく理解しやすくしたいねん。
金融テーブルは複雑になることがあるで。テーブルは直交関係を持つ傾向があるんや。行は列に関連し、セルは他のセルを参照し、数式は範囲に依存する。単純な行ごとのチャンクは機能せえへん。
ソースコードについても話そう。わしにとって、これが部屋の中の一番大きな象やねん。実際のコードを使って、すべての依存関係を見て、良いチャンク化で意味的に意味のあるRAGシステムを構築しようとするんか？どうやってやるんや？
実際には、本当にきれいなコード（ほとんどの人は持ってへん）があって、関数が純粋で自己完結してるなら、コードを取得して実際に操作できる非常に有用な意味的チャンク化が可能やねん。
しばしば、本当に雑然とした依存関係ツリー全体で情報を取得する必要がある場所にいなあかん。関数が他の3つの関数を呼び出すかもしれん。ローカルやないクラス変数を参照し、インポートされたモジュールを使い、何でもありや。コードには副作用がある。みんなのにはあるんや。
コードのチャンク化から価値を見つけて使おうと思うなら、時間をかけて依存関係グラフを構築するんや。呼び出されるすべての関数をメタデータに含める時間をかけるんや。関数とそれが呼び出すすべてを一つのチャンクに含める近隣チャンク化のようなものを検討するんや。
コードが本当に密結合してるなら、クラス全体やコードのモジュール全体を一緒にチャンク化する必要があるかもしれん。本当にきれいで意味的に意味のあるコードが欲しいなら、最良の戦略は時々それをリファクタリングすることや。ちなみに、AIはそれが得意やねん。それは別の会話やけど、AIはそれがかなり得意やねん。
悪いコードアーキテクチャは、チャンクで大量の困難につながるんや。ちなみに、それがコードをAIに取り込もうとしてる多くの組織がエージェント検索を採用してる理由やねん。エージェント検索により、悪いコードをすぐにリファクタリングする必要がなくなり、代わりにトークンを燃やして、大きくて雑然としたコードベース全体でエージェント検索に推論させることになるんや。完璧か？違う。高いか？そうや。チャンク化がここで難しいことを知ってるから、彼らが前進する方法かもしれへんか？そうでもある。
Excelデータの特殊な取り扱い
Excelについてもうちょっと詳しく見てみよう。ここで多くの災害を見てきたから、独自のセクションに値すると思うんや。Excelデータは単なる行と列やない。基本的に関係のウェブを保存してるんや。
マーケティングダッシュボードには水平に走る時系列と垂直に走るカテゴリ、様々な範囲を参照する数式などがあるかもしれん。行ごとにチャンク化して機能することを期待したらあかん。
人々がこれにアプローチするいくつかの方法がある。一つは、また、エージェント検索に戻ることができる。時々それが起こるねん。または、本当に有用な意味的意味が欲しいなら、自然な意味的チャンクについて考えるんや。特定の時間窓を取って、それをチャンク化し、すべてのカテゴリを含めるんや。2024年第3四半期のようにな。
数式の多いシートの場合、依存関係を追跡し、マップを構築し、計算可能な単位を一緒にチャンク化したいかもしれん。セルA1からA10がB15の要約に供給される場合、それらはすべて同じチャンクになるやろな。これも作業が必要やねん。
また、AIは私たちをより清潔なコードとより清潔なスプレッドシートに向けて標準化し、押し進めてるんや。それは絶対に職場のトレンドになるやろな。ピボットテーブルや要約を使ってるなら、各チャンクで要約を複製するか、詳細なチャンクが要約チャンクを参照できる非常に明確な階層を作成したいねん。
それぞれが何をするかについて、また明確にしたいねん。本当に意味的意味が欲しいなら、ピボットテーブルやExcelシートが何であれ、それを自然言語に抽出して変換する必要がある場合があるんや。それはあんまり頻繁には見いひんな。それがそんなに悪くなったら、ほとんどの人はエージェント検索に戻るねん。少なくとも雑然としたデータで少しは機能するからや。
そうであっても、複雑な金融データがたくさんある状況を扱ってるなら、金融データの意味的境界と意味を見ることをお勧めするで。最初に話したように、エージェント検索は万能薬やないねん。効果的にものを取得するために良いチャンク化戦略があるなら、それでもそれが必要やねん。
ゴルディロックス効果を狙ったサイズ調整
第4原則や。ゴルディロックス効果を狙ったサイズにするんや。チャンクが小さすぎて文脈が不足してたら、AIはせいぜい「よく分からん」って言うやろな。大きすぎたら、トークンを大量に無駄にする。答えが本当に焦点が合わへんし、より多く支払うことになるんや。
データの意味的意味と欲しい自然言語の答えの両方を反映する sweet spot について考えたいねん。法的条項なら750トークン、500から1000の間のどこか、そんな感じかもしれん。技術文書なら、より長くて複雑やから、皮肉やけど技術文書が法的文書より複雑かもしれへんな。
だから常に1000に近いかもしれん。結合されたコードの場合、クラス全体やモジュール全体がそこにあるような本当に大きなチャンクを持つことができるんや。数千トークンになることがあるで。時系列データ、すべてのコンテキストで完全な期間を引っ張ってるなら、また、それはある程度の大きさのコンテキストの断片になることがあるんや。1000トークンを超えることがあるで。
重要なのは、Nateがそれは X トークンになるって言ったから、それを使うっちゅうことやない。ビデオ全体で言ってきたけど、任意のトークン境界を使ったらあかん。意味的意味を目指すんや。評価セットを構築して、機能するものを見つけるまで、様々なチャンク化戦略に対してこれらの評価質問をテストしたいねん。
第5原則：重複を忘れるな
重複は十分に活用されてへんねん。重複っちゅうのは、チャンクAの終わりがチャンクBの始まりに現れることや。重要な情報が時々境界をまたぐ可能性があるから、これが重要なんや。意味的分割がどんなに良くても、完璧やないかもしれん。十分に大きなデータセットがあるなら、すべての分割を手でチェックできへんかもしれん。だから保険として重複を持たなあかん。
キャッチの一つは、スプレッドシートのような直交データがある場合、どちらの方向に重複させるんや？時系列なら、前の期間からの要約を含むような時間的重複かもしれん。カテゴリデータなら、カテゴリ重複か？詳細に入ると、ちょっと複雑になることの一つやねん。
これがこのビデオを作ってる理由やねん。これらの会話を表面化し、日光に当てて、みんながこの議論をしてることを知ってもらいたいからや。大きな質問やし、AIコミュニティとして持つ方が簡単やから、実際に効果的にレビューできるんや。
現状の監査と改善点
もしあんたがチャンク化で苦労してて、どこから始めたらええか分からんなら、現在の戦略について少し監査をしてもらいたいねん。平坦なトークンと文字分割を使ってるか？チャンク間に重複がないか？すべてのデータ型に同じ戦略を使ってるか？メタデータを保存してへんか？文書構造を無視する方法で分割してるか？これらは全て一般的な問題やねん。
金融データが関係保存を考慮せずにチャンク化されてるか？修正は簡単やない。データ自体の構造と、それがどのように意味的意味を表現するかと格闘してるんや。簡単な解決策やと偽るつもりはないけど、本当に変革的なAI検索への道筋やねん。
AIが大きな雑然としたデータの山を見る時になんとなく意味を成すか、それとも「うわあ、それは的確で正確や、いつも使ってる」かの違いやねん。後者の世界が欲しいなら、チャンク化を後回しにしたらあかん。それがAIパフォーマンスの基盤やねん。
大きなデータセットがあるなら、悪いチャンク化はRAGパフォーマンスやプロンプトエンジニアリング、モデルアップグレード、さらにはエージェント検索まで、下流のすべてを毒するんや。最も価値が高くて最も問題のあるデータ型から始めて、その痛みに突っ込んで、そのデータのスパゲッティのような性質に突っ込んで、それをマップアウトして、チャンク化側をどう扱うかを考えて修正するんや。
これらの5つの原則を適用して修正するんや。時々、本当に格闘してるのは、取り消すのが非常に困難なデータアーキテクチャの決定をしたという事実やねん。だからAI用にデータセットを再構築する必要があるかもしれん。企業がそれをする意欲があることを見てるで。AIの利益を見てるからや。
クラウドのためにはしようとせんかった。SaaS企業とそのSaaSツールのためにはしようとせんかった。AIのためにはするし、利益を見てるからAIのためにするんや。データアーキテクチャを正しくすることが重要やねん。データアーキテクチャのスペシャリスト、良いデータアーキテクチャを設計する人なら、今は甘い仕事を持ってるで。人々があんたの専門知識を必要としてるんや。
本当にデータを価値の段階的変化を生み出す方法でAIに取り込みたいなら、LinkedInのみんながよく自慢してるようなやつや。LinkedInのみんなが実際に真実を言ってるわけやないけど、みんな価値が実際にそこにあることを知ってるんや。ハードワークを投入した時にだけそこにあるんや。
ちなみに、この会話全体、このビデオを作らなあかんという事実が、企業にソリューションをスタンプアウトするのがなんでそんなに難しいかの理由やねん。
結論：原則の重要性
企業はみんな、異なる味の痛いデータを持ってるんや。みんな異なる混乱を持ってる。すべてのデータセットはそれぞれの方法で痛いんや。だから、これらの原則を取って、あんたのデータ環境でどのチャンク化戦略が意味を成すかを考え出す必要があるんや。
それが原則にこれだけ頼ってる理由やねん。最終的には、本当に複雑な企業データセット全体で実際に拡張する唯一のものやと思うからや。たくさん見てきたけど、これらが際立ち続けるものやねん。
文脈の一貫性を維持せなあかん。境界、サイズ、重複の3つのレバーを意識せなあかん。第3に、データ型が戦略を決定してることを認識すべきやねん。Excelについて話した。コードについて話した。法的なことについて少し話した。データ型について考えるんや。会話についても少し話したな。
そして、実際にサイズを正しく取得してることを確認するんや。ゴルディロックス効果を狙ったサイズや。それが第4原則やねん。大きすぎて曖昧な答えになったらあかん。小さすぎて焦点の合わへん、幻覚的な答えになったらあかん。
そして第5原則、重複を忘れるな。重複を忘れるな。重複を忘れるな。
そこやで。これが原則やねん。それが埋め込みが重要な理由やねん。これから離れて、便利な万能薬の代替案があると思ったらあかん。チャンク化は重要やし、十分に話されてへんねん。
コメント