チャンキングとは？テキストを効果的に分割する方法

100 ページの PDF を丸ごと入れても、何も引けない

ここからは Indexing の中身に入ります。手元に社内規程の PDF が 1 本あるとして、これをそのままデータベースに放り込むと何が起きるか、から始めます。

まず入りません。文章を数値に変換する埋め込みモデルには、一度に処理できる長さの上限があります。上限を超えた分は静かに切り捨てられるので、後半が丸ごと消えたことにも気づけません。エラーが出ないぶん、たちの悪い失敗です。しかも残るのは前半、つまり目次や前書きです。それらしく検索できてしまうので、気づくのがさらに遅れます。

仮に入ったとしても、引けません。データベースが持っているのは「規程 1 本」という単位です。有給休暇について質問しても、返ってくるのは規程まるごと 1 本。その中のどこに答えがあるかは、誰も教えてくれません。

そのまま LLM に渡そうとすれば、今度はコンテキストの上限に当たります。運よく収まっても、10 万字の中に埋もれた 3 行を的確に拾ってもらえる保証はありません。

分けた 1 つ 1 つが、検索の単位になる

そこで長い文書を短い断片に切り分けます。この断片をチャンク、切る作業をチャンキングと呼びます。

大事なのは、チャンキングが「LLM に入る大きさに縮める作業」ではなく、「検索で引く単位を決める作業」だという点です。検索は必ずチャンク単位でヒットします。1 つのチャンクを取り出したとき、それだけで意味が通るかどうかが、そのまま回答の質になります。

言い換えると、ここで決めているのは「この資料に対して、どういう粒度の質問に答えられるようにするか」です。規程を章ごとに切れば章の粒度の質問に、条ごとに切れば条の粒度の質問に答えられます。設計の判断であって、機械的な前処理ではありません。

もう 1 つ、実務上の効きめとして料金があります。質問のたびに規程 1 本を丸ごとプロンプトに詰めれば、入力トークンはその分だけ膨らみます。必要な数百文字だけを渡せる状態にしておくと、1 回あたりの費用が桁で変わります。

読みやすい大きさではなく、引きたい大きさで切る

では何文字で切るのか。答えは資料の種類によって違います。判断の基準は、利用者が 1 回の質問で知りたいまとまりは何か、です。

FAQ なら、1 つの問いと答えのペアで 1 チャンクです。無理に半分に割ると、質問文だけのチャンクと回答だけのチャンクができ、どちらも単独では役に立ちません。

手順書なら、1 つの手順、あるいは 1 つの節で切ります。「手順 3 まで」で切れたチャンクを引き当てても、続きが分からないままです。

議事録なら、議題ごとに切ります。発言者の名前で機械的に切ると、話の流れが失われ、誰の発言かは分かるのに何の話かが分からない断片ができます。

どれにも当てはまらない一般的な文書であれば、まず 500 から 800 トークンあたりを起点にしてください。この数字は正解ではなく、動かしながら詰めるための出発点です。

起点を決めたら、切った結果を数十件そのまま並べて読んでみてください。人が読んで意味の分かる断片になっていなければ、検索も同じところでつまずきます。切り方をどう詰めるかは、精度が出なかったときの話としてあらためて扱います。