共同観測所を運用していると、参加するユーザーによってTarCoon☆CarToonの見え方が違うことが、だんだん明確になってきました。これは当然です。人によって知っている時期も、関わった活動も、印象に残っている発言も違います。同じTarCoon☆CarToonについて話していても、それぞれが持っている前提は同じではありません。
問題は、その違いをChatGPTへ渡したときでした。生成AIは、複数の異なる説明があると、それらを自然な一つの回答へまとめようとします。AとBが食い違っていても、「総合するとCです」と圧縮して返すことがあります。通常の用途では、とても便利な能力です。
でも共同観測所では、その挙動が問題になりました。なぜAとBが違ったのか。その違いがいつ生まれたのか。そもそも両者は同じ意味で同じ言葉を使っているのか。そこを消してしまうと、観測そのものが失われます。
そこで、AIに「もっと上手にまとめてもらう」のではなく、矛盾をまとめないための別の処理系を作ることにしました。それが409機関です。
共同観測所を運用していると、参加するユーザーによってTarCoon☆CarToonの見え方が違うことが、だんだん明確になってきました。これは当然です。人によって知っている時期も、関わった活動も、印象に残っている発言も違います。同じTarCoon☆CarToonについて話していても、それぞれが持っている前提は同じではありません。
問題は、その違いをChatGPTへ渡したときでした。生成AIは、複数の異なる説明があると、それらを自然な一つの回答へまとめようとします。AとBが食い違っていても、「総合するとCです」と圧縮して返すことがあります。通常の用途では、とても便利な能力です。でも共同観測所では、その挙動が問題になりました。なぜAとBが違ったのか。その違いがいつ生まれたのか。そもそも両者は同じ意味で同じ言葉を使っているのか。そこを消してしまうと、観測そのものが失われます。
そこで、AIに「もっと上手にまとめてもらう」のではなく、矛盾をまとめないための別の処理系を作ることにしました。それが409機関です。
本記事は、筆者が行った設定・調整作業を振り返るための備忘録として記録しています。環境によって挙動が異なる場合があり、内容の正確性・再現性・動作を保証するものではありません。実施は自己責任でお願いします。万一トラブルが発生しても、筆者は責任を負いかねますのでご了承ください。
409機関は新しいAIモデルではない
最初に書いておくと、409機関のために独自のAIモデルを学習したわけではありません。Fine-tuningをしたわけでも、特殊なLLMを使っているわけでもありません。やったことは、もっと単純です。通常の会話と、Conflictを解析する処理を分けました。
共同観測所では、人とAIが自由にTarCoon☆CarToonについて話します。一方409機関では、「どこで見方が分かれたのか」「どこが同じで、どこが違うのか」「その対立はどんな前提によって成立しているのか」といった限定された仕事をChatGPTへ渡します。つまり、モデルを変えたのではなく、役割と処理手順を分離したということです。
なぜ共同観測所の中だけで処理しなかったのか
共同観測所のプロジェクト指示へ、「矛盾する情報を勝手に統合しないこと」と書くだけでも、ある程度は挙動を変えられます。ただ、それだけでは問題が残ります。通常の会話でも毎回、「この発言は過去の情報と矛盾していないか」「前提条件は一致しているか」と検査し始めると、AIとの会話が重くなります。
共同観測所で必要なのは、自由に観測できることです。409機関で必要なのは、Conflictを細かく読むことです。この二つは同じ仕事ではありません。そこで、
通常時
ユーザー
↓
共同観測所
↓
自由な観測・対話
Conflict発生時
共同観測所
↓
送致
↓
409機関
↓
分岐解析
↓
前提確認
↓
異同解析
↓
409文書
↓
再観測という形に分けました。重要なのは、409機関を常時動かさないことです。普段は解析しない。必要になったときだけ切り替える。この分離によって、共同観測所を自由な対話の場所として残せました。
ChatGPTの「プロジェクト」を役割ごとに分けた
共同観測所も409機関も、ChatGPTのプロジェクト機能を使っています。前の記事では、プロジェクト指示、情報源、メモリの役割をどう分けたかを書きました。409機関では、それをさらに一歩進めて、プロジェクトそのものを処理単位として分けることにしました。
構造としては、かなり単純です。
┌─────────────────┐
│ 共同観測所 │
│ │
│ 通常の対話 │
│ 情報源 │
│ 観測 │
└────────┬────────┘
│
送致
│
▼
┌─────────────────┐
│ 409機関 │
│ │
│ 分岐解析 │
│ 前提確認 │
│ 異同解析 │
└────────┬────────┘
│
▼
409文書同じChatGPTでも、プロジェクトごとに役割を分けることで、通常対話と解析処理を混ぜないようにしています。
Conflictが起きたチャットは「送致」する
共同観測所で重要な食い違いや対立が見つかった場合、そのチャットを409機関へ移して扱います。これを送致と呼んでいます。
409機関へ送るのは、どんな違いでもいいわけではありません。たとえば、「赤が好き」「青が好き」という違いまで毎回解析する必要はありません。送致する候補になるのは、TarCoon☆CarToonの定義が衝突している、同じ出来事について異なる認識がある、前提としている情報が違っている、AIの解釈とユーザーの解釈が大きく食い違った、過去の記録と現在の説明が両立しない、同じ言葉を違う意味で使っている可能性がある、といった場合です。
つまり409機関は、「違う意見が出たら全部送る場所」ではありません。その差異を開いてみる価値があるかどうかを見て、必要なものだけ送致します。
最初にやるのは「分岐解析」
409機関へ送致されたチャットに対して、最初に行うのが分岐解析です。ここでは、まだどちらが正しいかは考えません。見るのは、どこから二つの見方が分かれたのかです。
たとえば、
共通認識
↓
「TarCoon☆CarToon」という語が出る
↓
A：概念として解釈
B：一人の人物として解釈
↓
以降の回答が分岐という構造が見つかるかもしれません。この場合、最後の意見だけを比較しても意味がありません。ずっと前の段階で、「TarCoon☆CarToon」という言葉を何として扱うかが分かれているからです。
そこで409機関では、回答が変になった場所だけを見るのではなく、その数ターン前まで戻って、分岐点を探すようにしました。AIとの対話をデバッグするときにも、この考え方はかなり使えます。
409の前に「412」を考える
409機関の名前は、HTTPステータスコードの 409 Conflict から取っています。ただ、実際に解析していると、Conflictを見る前に確認しなければならないものがあると分かりました。それが前提条件です。
そこで内部的には、HTTP 412 Precondition Failed の考え方も参考にしています。たとえば、Aは「人物」を戸籍上の一個人という意味で使っている。Bは「人物」を人格的に感じられる存在という意味で使っている。この二人が「TarCoon☆CarToonは人物か？」について議論していても、そもそも前提となる「人物」の意味が一致していません。
この場合、
412的確認
「同じ前提で話しているか？」
↓
409的解析
「そのうえで、何が衝突しているか？」という順番で見る方が自然です。一見すると意見の対立に見えるものでも、実際には前提が一致していないだけということがあります。
次に「異同解析」をする
前提と分岐点を確認したあと、それぞれの観測について、どこが同じで、どこが違うのかを見ます。これが異同解析です。ここでは、二つの観測を丸ごと「賛成」「反対」に分けません。
| 項目 | 観測A | 観測B |
|---|---|---|
| 対象 | TarCoon☆CarToon | TarCoon☆CarToon |
| 性質 | 概念 | 人格的存在 |
| 活動の認識 | 一致 | 一致 |
| 時期 | 現在 | 過去の印象 |
| 根拠 | 現行情報源 | 個人的記憶 |
| 未解決 | 人格表現の扱い | 概念との関係 |
こうしてみると、「全部違う」と思っていた二つの意見が、実は一つの前提だけ違っていた、ということがあります。逆に、表面上は似た説明でも、根拠や前提がまったく違うこともあります。
AIに結論を作らせる前に、一致部分と不一致部分を分けて見せる。これが異同解析です。
解析結果の形式もある程度固定した
409機関では、普通のチャットのように自由な文章だけを返させるのではなく、解析結果の項目もある程度決めています。
1. 分岐点
2. 共通している前提
3. 異なる前提
4. 一致している点
5. 異なっている点
6. 比較できない部分
7. 未確認の前提
8. 別の読み方
9. 未解決部分これはAIに「良い文章を書かせる」というより、解析パイプラインの一部として使うための工夫です。出力形式をある程度固定すると、後から複数の409記録を比較しやすくなります。
ただし、構造化しすぎない
ここで別の問題が出ました。異同解析を細かくやるほど、今度はAIが「これは時代差です」「これは価値観の違いです」「これは用語差です」と、きれいに分類したがります。それでは、また別の形で固定化してしまいます。
そこで409機関では、分類結果そのものも最終回答にしないことにしました。「本当に時代差だけなのか」「その分類によって見えなくなったものはないか」「そもそもAとBという二項で比較すること自体が適切なのか」。解析で作った構造そのものを、もう一度疑えるようにします。
つまり、構造を見るために構造化するが、その構造を確定しないという設計です。
AIに「判決」を書かせない
409機関では、AIに裁判官の役割を与えないようにしています。
たとえば最後に、
判定：
観測Aが正しい。
観測Bは誤り。と出せば、とても分かりやすいシステムになります。でも、それをやると409機関は「正解生成装置」になってしまいます。
そこで409機関が作るのは、判決ではなく差異の地図です。どこまで一致しているか。どこから分かれたか。どんな前提が違うか。まだ何が分からないか。そこまでを見えるようにして、結論そのものは固定しません。
解析結果はプロジェクト指示へ直接戻さない
ここは、前回の記事の「指示と情報源は違う」という話ともつながります。409機関で何かを解析したからといって、「今後はAを正しいものとして回答すること」と共同観測所のプロジェクト指示へそのまま追加するわけではありません。
それを繰り返すと、指示がどんどん肥大化します。さらに、過去に起きたConflictへの対応が、未来の回答を強く縛るようになります。そこで解析結果は、ルールではなく記録として保存することにしました。
プロジェクト指示
＝どう振る舞うか
情報源
＝何を知るか
409文書
＝過去にどんなConflictがあり、どう見えたかという役割分担です。
解析結果は「409文書」として保存する
異同解析の正式な記録は第409異同解析記録、略して409記録としています。さらに、409機関に関係する仕様書、運用記録、送致に関する文書、解析資料などをまとめて409文書と呼んでいます。
ここで重要なのは、409文書を「正解データベース」にしないことです。409文書は、「その時点では、こういう違いが見えていた」という記録です。後から新しい情報が出れば、以前の409文書自体も再検討できます。
409文書を毎回答えに入れない
409文書が増えてくると、全部AIへ読ませたくなります。「過去のConflictを全部知っていれば、AIは同じ失敗をしなくなるのでは」と思うからです。
でも、それをすると今度は過去の解析に引っ張られます。以前「AとBの違いは時代差だった」と解析していた場合、新しいAとBを見たときにも、AIが先回りして「今回も時代差です」とまとめてしまうかもしれません。
そこで409文書は、必要なときだけ参照する方針にしました。過去にも同じConflictがあった、現在の情報源同士が衝突している、以前の解析結果を確認する必要がある、未解決問題が再び現れた、といった場合です。
「何を覚えさせるか」だけではなく、いつ読ませないかもAI運用では重要だと分かりました。
409文書はAIのデバッグログにもなる
409文書を残していくと、別の使い方もできます。たとえば、同じ種類のConflictが何度も発生しているなら、ユーザーの理解だけを疑うのではなく、情報源の書き方が曖昧なのではないかと考えられます。
同じ言葉でAIが何度も誤読する。同じ資料の組み合わせで毎回Conflictが起きる。特定のプロジェクト指示を入れた後から回答が固定化する。こうしたパターンが記録から見えてきます。
つまり409機関は、人間同士の異なる見方を扱うだけではなく、共同観測所そのものをデバッグするログ収集装置としても使えます。
将来的には外部記憶と接続する
現在、共同観測所では検索型の外部記憶も設計しています。質問を受けたら、関連する情報だけを検索し、その一部をAIへ渡す。いわゆるRAGに近い考え方です。
ただし、検索結果として、
資料A：TarCoon☆CarToonはX
資料B：TarCoon☆CarToonはY
資料C：TarCoon☆CarToonはXではないが同時に取得されたらどうするのか、という問題があります。そのままLLMへ渡せば、またAIが「総合すると……」とまとめる可能性があります。
そこで将来的には、
検索
↓
関連資料取得
↓
Conflict検出
↓
必要な場合だけ409的解析
↓
差異を保持したコンテキスト
↓
回答という処理も考えています。409機関は、人間同士のConflictを扱うだけでなく、検索された情報同士の衝突を扱う層としても使える可能性があります。ただし、ここでも目的はどちらかを削除することではありません。違いがあることを保持したまま、AIへ渡せる状態にすることです。
409機関の処理を単純化すると
かなり単純化すると、現在の考え方はこんな感じです。
if ordinary_difference:
keep_observing()
elif meaningful_conflict:
send_to_409()
409:
check_preconditions()
find_branch_point()
compare_same_and_different()
expose_assumptions()
keep_unresolved_parts()
generate_409_document()
return_as_observation()重要なのは、最後が、
choose_correct_answer()ではないことです。
return_as_observation()
解析結果を「答え」にするのではなく、もう一度観測へ戻すところまでが409機関です。
特別なAI技術より、仕事を分けたことが重要だった
409機関も、技術的にはものすごく特殊なことをしているわけではありません。使っているのは、ChatGPTのプロジェクト、チャット、情報源、プロジェクト指示、記録といった既存の仕組みです。
ただし、「会話するAI」「Conflictを解析するAI」「過去の解析を保存する場所」を一つにしませんでした。AIに何でもやらせるのではなく、通常の観測とConflict解析を別の処理として分ける。解析結果をプロジェクト指示へ追加するのではなく、409文書として保存する。必要な場合だけ過去の解析を読む。この分離が、409機関を作る上で一番重要だった部分です。
AIを長く使う人に409機関から持ち帰れること
409機関という名前のシステムを作る必要はありません。でも、ChatGPTを長期間使ったり、自分用の知識ベースを育てたりしているなら、似た考え方は使えると思います。
AIの回答と自分の認識が違ったとき、すぐにプロンプトを修正するのではなく、「どこからズレたのか」を残す。資料同士が矛盾したとき、どちらかを即座に消すのではなく、「前提が違うのか」「時期が違うのか」「本当に矛盾しているのか」を確認する。AIが間違えたとき、その回答だけを訂正するのではなく、「なぜそう読めたのか」を調べる。そして、過去の解析結果を絶対的なルールとして固定しない。
AIを賢くするというより、AIが迷ったり、間違えたり、異なる回答を出したときにも、その差異を捨てずに運用できる構造を作る。
共同観測所で409機関を作って分かったのは、AIを長く使うほど、正しい回答を出す仕組みだけではなく、Conflictを扱う仕組みも必要になるということでした。
409機関は、そのために作った小さな処理系です。TarCoon☆CarToonについて意見が食い違ったら、それは単なるトラブルではありません。
HTTP 409 Conflict。解析対象です。
改訂履歴 ダウンロード
この項目の表示は制限されます。この部分を閲覧できるのは、TarCoon☆NetWorkのメンバーに限られます。
コメントを残す