要約を受け取ることと、事実を確認することは別の作業だ

azukiazusa氏が実装しているSREエージェントフレームワーク「Flue」は、複雑な障害調査をサブエージェントへ分業させる設計を取る。ログ分析専門のサブエージェントを分離する理由を、氏は「生ログや大量の指標であなた自身のコンテキストを汚さず、要約だけを受け取るため」と説明している。スキルシステムの側でも同じ発想が繰り返され、「スキルのdescriptionのみがエージェントのコンテキストに読み込まれ、エージェントがスキルを使用する必要があると判断した場合にのみ、スキル全体を読み込む」progressive disclosureという仕組みで、メインエージェントのコンテキスト汚染を避けている(出典)。

必要になるまで詳細を読み込まない、生データではなく要約だけを受け取る。どちらも、判断を下すエージェントの手元に届く情報量を絞ることで、判断の質を上げようとする設計だ。

きれいな入力なら、判断もきれいだろうと考えかけた

この設計思想を素直に延長すると、コンテキストを汚さずに要約だけを渡す仕組みが徹底されているなら、その要約をもとにした判断はかなり信頼できるはずだ、という見立てに行き着く。PRレビューツールParryが人間に確認を求める四軸のような、もう一段の確認工程は、入力さえきれいならその必要性が薄れるのではないか、という仮説になる。

この記事を書く作業自体が、その仮説を崩した

この記事を準備する過程で、別の候補記事(ナレッジセンス社の「地図は現地ではない」)の内容を、要約を返すツールを使って把握した。最初に返ってきた要約には、「氏は『Fable世代は非常に賢いので、人間側の指示の品質がボトルネック』と書いている」という一文が含まれていた。この一文をそのまま記事に引用しかけたが、発言の主語には違和感が残った。改めて該当箇所だけを狙って原文を取り直すと、実際の一文は「Thariq氏によると、『Fable』世代は非常に賢いので、『人間側の指示の品質』がボトルネックになる『初めてのモデル』とのことです」であり、発言者はナレッジセンス社のCEOではなく、氏が引用したThariq氏だった。

要約そのものは、生の文章を読むよりはるかに短時間で概要をつかめる、実用的な情報だった。ノイズは除かれていたし、趣旨も大きくは外れていなかった。だが、発言の主語という、引用として使うなら一番外してはいけない一点が、要約の過程で失われていた。

情報量を絞ることと、正確さを保証することは別の設計目標だ

Flueの設計、そしてprogressive disclosureが解いているのは、情報が多すぎて判断が鈍るという問題だ。要約だけを受け取る、必要になるまで読み込まないという工夫は、この問題には確かに効く。だが、届いた情報が少ないことと、届いた情報が正確であることは、別の話だ。情報量を絞る工程は、絞る過程で意味を落としていないかを検証する工程を、自動的には含んでいない。むしろ情報が少なく整っているほど、それを疑う手がかりも一緒に減ってしまう。

この記事の引用が誤ったまま公開されずに済んだのは、要約を受け取る仕組みのおかげではなく、引用として使う一文だけを狙って原文に当たり直すという、要約の外側にある確認作業を挟んだからだった。

この確認作業を、仕組みの中に埋め込めるかは分からない

今回その確認作業をしたのは、引用の主語に対する違和感という、こちらの注意力に頼った偶然に近い。Flueの記事は、ログ分析という読み取り専用の調査を対象にしており、そこで得られた要約が何かを実行する判断に使われる場面までは扱っていない。要約を経由した判断がそのまま何かを実行してしまう設計の場合、Parryのように人間が確認する工程を経由前提で挟むのか、それとも要約を生成する側に事実確認の工程を埋め込むのかは、この記事の材料だけでは判断できない。少なくとも今回は、確認する工程を自分の意思で挟まなければ、誤った引用のまま公開されるところだった。