第1回では、idash（アイダッシュ）という名前と、「考えることと決めることは人間がやる」という出発点について書きました。今回はその続きで、AIの側をどう分けたか、という話です。
最初は、一つだった
作りはじめたころは、一つのAIセッション（AIとの一続きの対話）に全部やらせていました。ノートを読んで、要点を整理して、自分の人格や記憶を少しずつ育てて、その流れでこちらと相談もする、という具合でした。相手が一人のほうが文脈が途切れなくていいだろう、という素朴な発想でした。
これが、だんだん回らなくなりました。大きな一括処理を頼んでいる間は対話ができません。対話の途中で一括処理の話に戻ると、さっきまで積み上げていた文脈が薄まります。どちらも中途半端になっていく感覚がありました。
分かりやすく困ったのは、こちらが「この考え方は前にも書いた気がする」と相談しているときに、その相手が同時に数千件のノートを順番に処理している状態でした。話の相手としては、直前のやり取りを覚えていてほしい。処理の担当としては、こちらの話に気を取られず最後まで回り切ってほしい。同じ相手に、逆のことを求めていたわけです。
混ざっていたのは、性質の違う2つの仕事
しばらく考えて気づいたのは、一つの場所に、まったく性質の違う仕事を2種類押し込んでいたということです。
ひとつは、こちらと会話しながら、人格や記憶を少しずつ育てていく仕事。これには文脈が要ります。前に何を言ったか、その言い方がどうだったか、を引きずったまま進む必要があります。量は多くなくていい代わりに、丁寧さが要る仕事です。
もうひとつは、9,623件のノート全体を機械的に舐めて、人名や場所や概念を抜き出し、ノートとノートの関連性を計算する仕事。こちらは丁寧さより量です。同じ処理を淡々と何千回も回せることのほうが大事で、途中で気の利いた判断をされるとかえって困ります。
この2つを同じ場所でやると、片方が片方の邪魔をします。分けるべきだ、というより、もともと別のものだった、という感じでした。
名前を付けたら、判断が速くなった
そこで役割に名前を付けました。
こちらと直接やり取りして、人格と記憶を育てるほうを「秘書」。母艦のノート全体を対象に、エンティティの抽出、ノート間の関連性の計算、索引づくりを黙々とやるほうを「司書」。司書はユーザーと直接会話しません。
技術的には何も変わっていないのに、名前を付けたことの効果が思ったより大きかったです。何か新しい機能を思いついたとき、「これは司書の仕事だ」と一言で言えるようになりました。どちらがやるべきかで迷う時間が、ほとんどなくなりました。役割の名前は、設計というより、自分が迷わないための道具として効いています。
書き込みは、片方に寄せた
分けたうえで、もうひとつ線を引きました。秘書は司書の成果物を読むだけで、書き込まない、という決まりです。
これは技術的な最適化ではなく、揉めないようにするための線引きです。同じデータを2つの主体が別々のタイミングで書くと、どちらが新しいのか、どちらが正しいのかが分からなくなります。片方を書く側、片方を読む側と決めてしまえば、その問いは最初から発生しません。
リポジトリを分けることが、そのまま役割の分離になった
保管場所も分けました。秘書は blankpaper、司書は my-storage-note、画面を担当する作業台は cockpid というリポジトリ（ファイルの保管庫のようなもの）に置いています。
リポジトリを分けると、何がどこにあるかが物理的に決まります。秘書のコードから司書のファイルを触ろうとすると、まず別のリポジトリを見に行くという一手間がかかります。この一手間が、役割の境界を守るブレーキになりました。
ただ、増やしすぎると今度は全体像が分からなくなります。自分でも「あの仕組みはどこに書いたか」を思い出せなくなったので、地図専用のリポジトリを1つ作り、そこに「どこに何があるか」だけを書くようにしました。
結果として、三層になった
こうして流れが三層になりました。原文であるObsidianのノートが9,623件。それを司書が構造化した抽出物が、7,422個のJSONファイル（機械が読みやすい形式のデータ）。そして作業台がそれを表示します。
作業台には「原文の第二のコピーになってはいけない」という制約を、はっきり書いて残しています。放っておくと、表示を速くするために、データをこちら側にも持ちたくなるからです。それを許すと、どちらが本物か分からない場所がまた一つ増えます。書き込みを片方に寄せたのと、同じ理由です。
この三層は、上から下へ一方通行です。下の層が上の層を書き換えることはありません。一方通行だと決めておくと、何かおかしくなったときに、どこを見ればいいかがすぐ分かります。実際、表示がおかしいときの原因は、たいてい表示側ではなく一つ上の層にありました。
—
分けたこと自体は、いまのところ正解だったと思っています。ただ、分けると新しい問題が出てきました。AIどうしが、お互いの仕事を知らないのです。実際に、秘書の側で「ノートから人名や概念を索引化する機能を作ろう」と設計を始めたら、司書の側が同じものをとっくに作り終えていた、ということが起きました。1,600件を超えるエンティティが、すでに揃っていたのです。気づいたのは、たまたま別件でファイルを覗いたときでした。
一人に全部やらせるのをやめたら、今度は連絡の問題が出てきました。当たり前といえば当たり前なのですが、実際にぶつかるまで思い至りませんでした。次回は、そのAIどうしの連絡帳をどう作ったかを書きます。
コメント