AIは文章を、文字のまま受け取っているわけではありません。まず「トークン」という単位に割ります。よく出てくる言葉はまとめて一つ、珍しい言葉は数個に割れる。この単位で数えているので、上限は「何文字まで」ではなく「何トークンまで」で決まります。
そして日本語は、英語より多くのトークンを使います。同じ内容でも消費が二倍近くになることがあります。「英語の資料は入ったのに、日本語の資料だと入らない」という差は、ここから来ています。
言葉を、AIが扱いやすい大きさに割った単位です。文字とも単語とも一致しません。
短い言葉 ── まとめて一つに収まることが多い。
珍しい言葉・固有名詞 ── 数個に割れる。社名や型番は、かさみやすいところです。
割り方と仕組みの解説は Google のクラッシュコースが簡潔です。Google for Developers「LLM: 大規模言語モデルとは何でしょうか」↗
一度に扱える量のことを「文脈の窓」と呼びます。この窓に入るのは、渡した資料だけではありません。指示文、それまでのやりとり、そしてこれから書く答え。すべてが同じ窓を分け合います。
ですから、資料を詰め込むほど、答えに使える余地が減ります。「途中で文章が切れてしまう」という症状は、たいていこれです。
指示 ── 何をしてほしいか。短いのに、効き方は大きい。
資料 ── 読ませたいもの。ここが一番かさばります。
やりとり ── 前の質問と答え。会話が長いほど積み上がります。
答え ── これから書く分。最後に押し出されるのは、ここです。
上限に収まっていても、渡したものが均等に効くわけではありません。多くの場合、先頭と末尾は強く効き、真ん中は薄くなります。
たとえば、五十ページの手引きを貼って、二十五ページ目に「離島は別料金です」と一行だけ書いてあるとします。この一行は、しばしば効きません。前後がどれだけ整っていても、真ん中の一行は埋もれます。
「全部入れたのに、真ん中に書いた条件を無視された」という出来事は、これで説明がつきます。手当ては単純です。外せない条件は、資料の後ろにもう一度書く。それだけで通り方が変わります。
ここ数年で、扱える量はずいぶん増えました。ですから「窓の大きなものを選べば解決する」と考えたくなります。半分は当たっていて、半分は外れています。
入る量は増えます。けれど、真ん中が薄くなる性質は消えません。そして扱う量が増えるほど、返ってくるまでの時間も、請求も増えます。窓を広げることは、資料を選ばなくてよくなることとは違います。
当社は、窓の大きさを「余裕」として使い、詰め込む枠としては使わない方針にしています。入るかどうかではなく、渡す必要があるかどうかで決めるほうが、結果が安定します。
請求は、扱ったトークンの量で決まります。長い資料を毎回貼れば、毎回その分を払います。同じ資料を十回貼れば、十回分です。「精度は足りているのに、思ったより高い」という場合、原因は貼り方にあることが多いです。
読ませた分と書かせた分で単価が違うのも、押さえておくと役に立ちます。多くの場合、書かせるほうが高くつきます。ですから長く読ませて短く書かせる使い方は、意外に安く収まります。金額の決まり方そのものは第9章 費用に分けて書きました。
1. 必要な所だけ渡す ── 全文ではなく、関係する数か所。
2. 長い作業は分ける ── 途中で要約を残し、次に引き継がせる。
3. 返す形を決める ── 項目と順番を指定すると、答えが短く済みます。
効くのは一つめです。答える前に社内の資料を調べさせるRAGは、精度を上げる仕組みだと説明されることが多いのですが、窓を節約する仕組みでもあります。
二つめは、長い議事録の要約や、何十件かの一括処理で効きます。一度に流すのではなく、区切って、区切りごとに要点を残す。人が長い会議をまとめるときと同じやり方です。
当社が自社で動かしている記憶は 11,239件 あります。窓に全部は入りません。ですから毎回、質問に近いものだけを選んで渡しています。数え方は「AIの中身」に開いています。
制限があること自体は、困ったことではありません。全部を渡さない前提で組めば、費用も速度も落ち着きます。
次の記事は、同じ質問を二度したときの話です。答えが変わるのは、故障なのでしょうか。
章と記事の全体は図書館の見取り図で一枚にまとめています。