3行でいうと

  • 手元のAIには「一度に読める長さ」があり、設定で決まります。初期値は小さいことがあります。
  • 長く入れても、中ほどの情報の扱いが弱くなる、と論文は報告しています。
  • 分けて要約し、その要約をまとめ直す手順は、LlamaIndexの公式文書にも載っています。
  • アプリが自動で検索に切り替えると、文書全体を読んだ要約にはなりません。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書や論文を読んでまとめたものです。手順と計算例は、読んだ資料にもとづく僕らの組み立てで、実際の出来栄えは確かめていません。

先に結論

見立てです。手元で長い文章を要約するときの基本は、次の4点です。

  1. まず、使う設定の「一度に読める長さ」を確かめる。
  2. 文章がそれより十分短いなら、そのまま入れる。
  3. 長いなら、見出しなどの切れ目で分け、1つずつ要約し、要約をまとめ直す。
  4. 大事な数字や固有名詞は、要約を信じ切らずに元の文章と見比べる。

前提：用語

1. 一度に読める長さは、設定で決まる

モデルが対応する最大の長さと、実際に使う長さは別です。

つまり、「256K対応」のモデルでも、初期設定のままだと数千トークンしか読んでいないことがあります。これはOllamaの既定の表からの読み取りで、僕らは実際の動作を確かめていません。

長くするとメモリが増える

僕らの計算です。Qwen3-8Bの設定ファイルから、1トークンあたりのKVキャッシュは147,456バイトです（BF16）。32,768トークンで約4.8GBになります。モデル本体とは別に、これだけ要ります。256K対応のモデルを最後まで使うのは、手元の機械では重い、と見ています。

2. 入れた長さのぶん読めるとは限らない

中ほどが弱くなる

論文「Lost in the Middle」（Liuら、2023年7月、arXiv:2307.03172）は、複数の文書から答えを探す課題などで、必要な情報の位置を変えたときの成績を調べました。要旨によると、成績は情報が入力の最初か最後にあるとき最も高く、長い入力の真ん中にあるときに大きく下がります。長い文脈向けに作られたモデルでも、そうだ、と書かれています。

公称の長さを、そのまま信じない

論文「RULER」（Hsiehら、2024年4月、arXiv:2404.06654）は、17個の長文脈モデルを評価しました。要旨では、探す課題の単純な版ではほぼ満点でも、長さを増やすと、ほとんどのモデルで成績が大きく下がると報告しています。32K以上をうたうモデルのうち、32Kで十分な成績を保てたのは半数だけでした。

見立てです。この2つの論文は、2023〜2024年のモデルが対象です。いまの手元のモデルに同じ数字が当てはまるとは限りません。ただ、「長く入れるほど、細部の取りこぼしが起きやすい」と考えて設計するのは、無難だと思います。

3. アプリが勝手に検索に切り替えることがある

LM Studioの文書によると、文書ファイルを添付したとき、文書がモデルの文脈に収まるなら、内容をそのまま会話に加えます。文書が非常に長いときは、RAG（検索して、関連しそうな部分だけをモデルに渡す方式）を使います。

見立てです。RAGが選んだ部分だけを読むなら、「文書全体の要約」を頼んでも、全体を見た答えにはなりません。「全体を漏れなく」ほしいときは、次の「分けて読ませる」やり方のほうが向くと考えます。

4. 分けて読ませる：分割と統合

論文「Recursively Summarizing Books with Human Feedback」（Wuら、2021年9月、arXiv:2109.10862）は、本1冊の要約で、まず小さな部分を要約し、その要約をさらに要約する再帰的なやり方を使いました。同論文では、人の評価を使って学習したモデルで、この方式を試しています。

LlamaIndexの公式文書にも、同じ考え方の「応答モード」が載っています。

モード 公式文書の説明（要約） 向く用途（文書の記述）
tree_summarize 文章を、収まる大きさにまとめて要約し、その答えをまた束ねて要約する。1つになるまで繰り返す 要約
refine 断片を順に処理し、前の答えと次の断片で答えを更新する。断片ごとにAIを呼ぶ 詳しい答え
simple_summarize 全部を1回のプロンプトに収まるよう切り詰める 手早い要約。切り詰めで細部を失うことがある

どれも、断片が大きすぎるときは重なり（オーバーラップ）を持たせて再分割する、と説明されています。

手順の組み立て

僕らの案です。

  1. 長さを決める。 設定の長さから、質問文と答えの余裕を引いた分が、1つの断片に入れられる量です。
  2. 切れ目で分ける。 見出し、章、段落の区切りで分けます。文の途中では切りません。前後に少し重なりを持たせます。
  3. 各断片を要約する（分担）。 断片ごとに、同じ指示で要約させます。「何ページ目か」「元の言葉をそのまま引用した数字」を残すよう頼みます。
  4. 要約を束ねて統合する。 断片の要約が、まだ長すぎるなら、さらに束ねて要約します（再帰）。
  5. 確かめる。 数字、日付、名前は、元の文章と見比べます。

僕らの計算です。例を作ります。日本語で5万字の文章を、1トークン1文字の目安で5万トークンとします。設定の長さが8,192のとき、断片を5,000トークンにし、10%の重なり（新しい部分は1つあたり4,500トークン）で約12個に分けます。各断片の要約を400トークンにすると、合計は約4,800トークンです。指示と統合後の答えの分を足しても、8,192に収まる計算です。

断片ごとの指示の例（僕らの案です）

断片の要約に使う指示の例です。公式の文書の例ではなく、この記事で考えた文面で、実行して確かめていません。

次の文章は、長い文書の一部（第◯部）です。 重要な事実を、箇条書きで10個以内にまとめてください。 数字・日付・固有名詞は、原文のまま書いてください。 原文にないことは書かないでください。

統合の指示の例です。

以下は、同じ文書を分けて要約したものです。順番どおりです。 重複をまとめ、全体の流れが分かる要約にしてください。 食い違う点があれば、そのまま書き出してください。

「食い違いを書き出させる」のは、統合の段階で、AIが勝手に辻褄を合わせるのを減らすための工夫です。効果は確かめていません。

どの方法を選ぶか（見立てです）

  • 全体の流れをつかみたい：分割して要約し、統合（tree_summarizeの考え方）。
  • 特定の質問に答えさせたい：検索（RAG）のほうが向く。
  • 細かい漏れをなくしたい：断片ごとに順に処理（refineの考え方）。ただし、AIを呼ぶ回数が増え、時間がかかります。

つまずきやすい点

気をつけること

出典

更新履歴