理由は二つあります。ひとつは、AIが一度に扱える量に上限があること。二百ページの手引きをそのまま渡すことはできません（A-02-1 トークンと文脈の窓）。
もうひとつは、探す精度です。一冊まるごとを一つの塊として保管すると、「この一冊は関係がありそうです」までしか分かりません。知りたいのは、その中のどの段落かです。ですから、あらかじめ切って保管します。
一つの塊が大きいと、探し当てたときに余分が大量に付いてきます。関係のある三行のために、関係のない三ページも一緒に渡ることになる。するとAIは余分のほうに引っ張られます。
出典を示すときにも困ります。「この一冊のどこかに書いてあります」では、確かめる手間が減りません。
逆に細かく刻みすぎると、主語が消えます。「税抜です」という一行だけを取り出しても、何の話か分かりません。数字だけが残って、条件が別の塊に行ってしまう。これはもっともらしい嘘の材料になります。
表も同じです。行だけを切り出すと、項目名がどこかへ消えます。「30,000」という数字だけが残っても、それが制作費なのか月々の保守料なのかは分かりません。数字は、単位と条件と一緒でなければ意味を持ちません。
1. 見出しの単位で切る ── 文字数で機械的に切らず、話の区切りで切ります。
2. 前後を少し重ねる ── 隣と数行だけ重ねておくと、境目で意味が切れません。
3. 出どころを貼る ── どの資料の、どの見出しか、いつのものか。塊ごとに持たせます。
切り分けの考え方は Google Cloud の解説にも整理されています。Google Cloud「RAG Engine の概要」↗
三つめが、あとで効きます。出どころが付いていない塊は、出典を示せません。出典を示せない答えは、確かめるのに元の資料を探すことになり、結局は人の時間を使います。
大きさの目安をよく聞かれます。当社は、見出しひとつぶん（おおむね数百字）を一件として扱い、それより長い節はさらに分けています。重ねるのは二、三行で足ります。ただし、目安より先に確かめるべきことがあります。入れ終えたあとで、実際にいくつか質問を投げ、狙った塊が返ってくるかを見る。切り方の良し悪しは、机の上では決まりません。
料金表や仕様表を、文章と同じやり方で切ると、まず壊れます。当社は表を文章に書き換えてから保管します。「A案は月額○円、含まれるものは○と○」という形に開いておくと、探せるようになります。
画像の中に文字がある資料（紙の書類を撮ったもの、図として貼られた表）は、そのままでは読めません。先に文字にする工程が必要です。ここを飛ばした状態で「入れたのに出てこない」となる例が多いところです。
いちばん起きやすい事故がこれです。料金を改定したときに、新しい資料を足しただけで古い資料を消さない。すると古い金額と新しい金額の両方が保管され、AIはどちらかを引きます。
ですから、更新は入れ替えとして扱います。古い塊を消してから、新しい塊を入れる。残す必要があるなら「○年○月まで有効」と書き添えて、いま有効なものと区別できる形にします。
差し替えるのか、履歴として残すのか。資料の種類ごとに、先に決めておきます。
料金・仕様・手順 ── 差し替え。古いものは残しません。
議事録・報告 ── 履歴として残す。日付が意味を持つためです。
当社が自社で使っている記憶は 11,239件 で、全件が検索できる状態にあります。件数が増えても困らないのは、一件が小さく、出どころが付いているからです。数え方は「AIの中身」に開いています。
切り分けができたら、次は探し方です。意味で探す検索と、語で探す検索。片方だけでは外れます。
章と記事の全体は図書館の見取り図で一枚にまとめています。