ブログ
「作品全体を読むAI」は、なぜ重くならないのか
作品全体を読みに行くAIには、当然の代償があるはずです。長い原稿を毎回読ませれば、費用も待ち時間もふくらむ。それでも長編で成り立つのは、モデルに全文ではなく要約を渡し、全文は必要な章だけ取りに行かせているからです。
前回の記事「「貼る」AIと「読みに行く」AI」で、AIが自分で原稿を読みに行く使い方を紹介しました。ただ、この「読みに行く」には、当然の代償がついて回ります。
AIに一度に渡せる分量には上限があり、渡す量が増えるほど、返事にかかる時間も費用もふくらみます。作品全体を読みに行くというのは、長い原稿を丸ごと読ませるということです。素朴に作れば、十万字の長編を相手にした瞬間、遅く、そして高くつきすぎて、使いものになりません。それでも、長編の整合性を一度で尋ねられる。この二つは、本来なら両立しないはずのものです。
ここでは小説を例にとりますが、論文でも、ノンフィクションでも、仕組みは変わりません。
「全部読む」の限界
いちばん素朴なやり方は、相談のたびに原稿を全部モデルに読ませることです。これなら全体を踏まえた答えは返ります。けれど長い作品では続きません。十万字を毎回読み込ませれば一回の相談が重くなり、何度かやり取りするうちに、渡せる分量の上限にぶつかります。
手がかりは、ほとんどの相談で全文までは要らない、という点にあります。「妹は第3章で亡くなっている」という整合性を確かめるのに要るのは、その一行の事実であって、第3章の全文ではありません。丸ごとの本文がどうしても要る場面は、実際にはごく一部です。
要約と全文の二段構え
そこでCoreは、ファイルごとに要約を持たせます。登場人物、設定、時系列、張られた伏線といった、どの相談でも効いてくる情報です。
モデルに毎回渡すのは、この要約のほうです。要約だけでも、作品全体のかたちはつかめます。そのうえで、ある章の実際の文面まで踏み込む必要が出たときにだけ、モデルはその章の全文を取りに行きます。
全体は要約で押さえ、細部は必要なぶんだけ開く。作品全体を見渡すことと、安く速くあることが両立するのは、いつも全部を読んでいるわけではないからです。
矛盾チェックの実際
第3章で亡くなったはずの妹が、第9章で口をきいている。この食い違いを確かめるとき、AIはまず各章の要約を見渡し、妹に関わる章に当たりをつけます。全文を開くのは、そのうち食い違いが疑われる第3章と第9章だけです。
残りの章は、要約のまま素通りします。全部を読み返さずに矛盾が見つかるのは、全体を要約で見渡したうえで、怪しい二か所だけを深く読んでいるからです。読む範囲を絞れているからこそ、長い原稿でも一度の相談で答えが返ります。
原稿の外の資料
同じ「必要なときに取りに行く」やり方は、原稿の外にも向きます。作中の事実に裏づけが要るとき、Coreは国立国会図書館のデジタルコレクションやWebを自分で検索し、実在の資料に当たってから答えます。記憶からそれらしい書名をひねり出すのではなく、実物を見にいくので、ありもしない文献をでっち上げにくくなります。
執筆の作業の型
こうした読み分けができるのは、Coreのエージェントが執筆の作業の型を持っているからです。調べもの、批評、構成の検討、下書きづくりといった手つきを場面で使い分け、作品の文体も読み取って合わせます。汎用の物知りに全文を渡して考えさせるのとは、構えが違います。
使いやすさは、読まない部分で決まる
「読みに行くAI」の使いやすさは、何を読むかではなく、何を読まずに済ませるかで決まります。全体を要約で持ち、必要なところだけ全文に降りる。原稿の外の資料も、要るときだけ取りに行く。この設計があるから、原稿が長くなるほど効く道具になります。
短いうちは、その差は見えません。差が現れるのは、全部を読んでいては立ち行かなくなる長さまで、作品が育ってからです。
私が作っている Core は、この「全体は要約で押さえ、必要な全文だけを読みに行く」仕組みで、長い原稿の相談を成り立たせています。macOS向け、14日間の無料トライアル付きです。→ corewrite.app