MASしMAS

Transcript

1. MASしMAS ３⽇あればめんどいことやってくれるものができる 10/18 ⼤LT
2. MAS •マルチエージェントシステムの頭⽂字 •複数のエージェントを動かして単体よりもいい処 理をしようという考え⽅ 今回はエージェントたくさん動かしたい時に やったをまとめました
3. ⾃⼰紹介 名前：ナツ 趣味：DJ,複雑系（フラクタルとか） ↑学祭の写真
4. やりたいこと いちいちプロンプト作って打つのめんどいな… せや！AIの命令をAIにしてもらお
5. やってみた
6. このモデルでは指⽰を出して各⾃が実⾏する とすぐ破綻する ちなみに個⼈がvibe codingしても似たような 現象が起こる(n敗) タスク分解して指⽰出してもうまくいかない
7. 課題 前回のLTで上司と部下のエージェントを作成して タスクをさせようとした ->とある段階で •プログラムの⼀貫性がなくなる •ディレクトリ構造が複雑化し、ファイルが散乱す る（デバック困難）
8. 並列化モデル（報告してくれるやつ） 優れている⽅の案を選択してみよう
9. ⼀応できたが… • これって⼀つのタスクに対して競合しているだけでは？ • 私がしたいのは協調の⽅だった • エージェント同⼠が通信してない
10. 部下に直接議論させ れば良いのでは？ （天才か？）
11. 協調強調するエージェント ワイ：きっとお互いの意⾒を汲み取って 建設的な話し合いをするんやろな〜w とりあえず異なる感性を持った⼆体の エージェントを議論させたろ( ^ω^ ) 議題：今⽇の晩御飯何にするか
12. [正命題- Worker1]: 晩餐とは単なる栄養補給ではな く、⼈間が世界と交感し⾃らの 感性を更新する儀式である―― これが私の正命題です。 - 美的価値は、⾆と⽬と⼼を同時に呼び覚ます多層的な快楽をもたらし、⾷卓を「時間の彫刻」へと変容させます。 器や盛り付け、⾹りの余韻が織りなす総体が、⽇常を超えた感覚の劇場を構築し、⼈間存在を豊かに証⾔します。 - 創造性は、惰性化する⾷⽣活に断裂を⽣み、他者と世界への想像⼒を取り戻す⾏為です。既成のレシピを超え、 ⽣素材との対話から新たな意味を⾒出すことこそ、⼈間が⾷を通じて⾃らを再発明する道なのです。 - 今宵の提案は三品。第⼀に「秋霧の森」と題した炭⾹を纏う舞茸と栗のタルトタタン：逆転した⽢⾹と⼟の気配 で、森を⽫上に再構成します。第⼆に「⽉光の⽔鏡」――柚⼦と⽩胡⿇で⾹りを⽴てた鱒の昆布締めを、薄氷状 の葛ジュレに沈め、光をすくうように供します。第三に「紅葉の余⽩」：ビーツと柿、⼭⽺乳チーズを折り紙の ように重ね、胡桃の燻煙を纏わせたサラダ。いずれも五感が季節と交わる瞬間をデザインします。 - 実⽤性を優位に置く発想は、⼈間を営養消費者へと還元し、⾷卓の象徴性を否認します。ヘーゲル的に⾔えば、 料理は⾃然と精神の媒介であり、単なる有⽤性は「即⾃」に留まる未完成の段階です。芸術性によってのみ、 我々は⾷を「対⾃」へと昇華し、最終的な「即且対⾃」の⾃⼰同⼀を経験できる。ゆえに実⽤主義は否応なく超 克されねばなりません。
13. [反命題- Worker2]: ヘーゲル的対置の観 点から、あなたの正 命題を批判的に受け ⽌めたうえで次の反 命題を提⽰します。 芸術性より実⽤性を優先すべき合理的根拠 ヘーゲル的弁証法においても、概念はまず現実性（Wirklichkeit）に根ざす必要があります。健康を損ねれば精神の⾃由は萎 縮し、創造性も持続不能になる。芸術性は⽣存の可謬性を忘却しがちで、栄養⽋損・過剰摂取・時間資源の浪費を招く危険 がある。合理的意志は⾃⼰維持を通じてのみ⾃由を勝ち取るのであり、実⽤性の軽視は⾃⼰否定的態度です。⾷卓を劇場化 する前に、⾝体という舞台装置を保全しなければ、感性の発露は⼀過性で終わります。 以上の反命題によって、晩餐を「精神と⾃然の媒介」と⾒る視点⾃体は尊重しつつも、まず⽣命維持と社会的制約に応答す る現実的基盤を確⽴することが不可⽋であると主張します。あなたの提案が過剰に象徴性へ傾き、普遍的実践性を⽋く点を 批判し、実⽤と健康を重視した代替案を⽰しました。これを起点にさらなる統合解を模索しましょう。
14. オチ Worker2には、この共鳴代謝マトリクスを実装した場合の家計簿・体調ログ・満⾜度の変化を評価し、実証データで議論を進めることを求める。特に、余⽩指数が継続率とQOLにどう響くかを測る協働が不可⽋だ。 - また、あなたの合理主義が感性の再⽣産をどう担保するのか、具体的な⼼理指標で答えてほしい。数値のみに依拠する姿勢は、精神の⾃由を萎縮させるままではないか。 共鳴代謝こそが創造性と実⽤性を超えた新たな価値軸であり、弁証法を⾼次に進める道筋だと確信する。とはいえ、未だ双⽅の真理が完全に融和したとは認めない。さらに深い対話を望む。 10. [⾼次統合検証-Worker2]: 実⽤性に⽴脚して応じます。Worker1の「共鳴代謝マトリクス」は理念として⾯⽩いものの、現実運⽤では次の重⼤なボトルネックがあります。 正反合のために対⽴する議論をさせた →結果はお互いの主張をし、どちらも妥協案をのまなかった （哲学に⾏き着くみたい） ちなみに： ⽂字数は 36738⽂字 トークン爆⾷いする割に何も意思決定が⽣まれない ↑supervisorの”審判” ↑worker1を批判するworker2の図
15. 司会（Mediator） • 議論の進⾏ • 意⾒の調整 • 複数の案の統合
16. 会話ログ＃１ 管理者: Mediator、Worker1とWorker2の晩御飯候補の議論を監督し、 合意案をまとめて報告してください。 Mediator: 承知しました。両名とも今晩の晩御飯案をそれぞれ提案し、 互いの希望を調整しましょう。 Worker1: 今⽇は和⾷が⾷べたいので、鮭の塩焼き定⾷を提案します。 ヘルシーで準備も簡単です。 Worker2: 私は疲れているので、できれば調理が楽なものがいいです。 テイクアウトで寿司の盛り合わせに しませんか？ Mediator: ありがとうございます。Worker1、外⾷やテイクアウトで も⼤丈夫でしょうか？Worker2、寿司以外に軽めの候補はあります か？
17. 会話ログ＃２ Worker1: はい、テイクアウトでも問題ありません。⿂なら満⾜です。 Worker2: 軽めだと、例えば海鮮丼なら⽚付けも楽でいいと思います。 Mediator: ⿂料理で⼿間が少ない点では、海鮮丼は両者の希望に合いそうで す。Worker1、どうでしょう？ Worker1: 海鮮丼なら鮮⿂も⾷べられるので⼤丈夫です。賛成します。 Mediator: Worker2も賛成でよろしいですか？ Worker2: はい、海鮮丼で決めましょう。 Mediator: 合意案は「テイクアウトの海鮮丼」です。管理者の承認をお願い します。 管理者: 合意案「テイクアウトの海鮮丼」を承認します。良い晩御飯を。
18. 議論モジュール化
19. まとめ • 議論してその案を統合することができた • ⼀つの議論ごとに３回の意⾒交換がある。 （まとまらなければmidiatorがその時点で最終ジャッジ） • この時点で単体のLLMに何か質問するより 少なくとも回答の量は多いものを作れた
20. 10分枠なので もう少し これって ⽊構造=再帰に 強いんじゃね？ (私は⽊構造が好きです) 議論していたものをモジュール化 （上を以降ConsensusUnitと呼称）
21. 再帰構造のため中間層を追加 Integrator（統合）: 上がってきた⼆つの案を統合するもの 中継ハブみたいなもの Q：さっきのMediatorとは何が違うの？ A：Mediatorは議論を円滑に進めるのが ⽬的だが、Integartorは案を統合する役割 をする
22. 多様性は⼤事 価値観を増やすことで案の質が上がる IntegratorがMetaConsensusUnitになっているのは気分で名前変えてるからです、申し訳ない
23. 会議の流れログ 1.晩御飯決定の指令が出る 2.複数の案が提⽰される（冷やし茶碗蒸し、鶏むね丼など） 3.コスパ・栄養・季節感で評価・統合 4.鶏むね＋秋野菜のあんかけ飯で第1合意 5.別チームで鮭レモン蒸し案が登場 6.⼿軽さ・栄養バランスで最適化議論 7.鮭レモン蒸し献⽴で第2合意 8.2案を統合して最終合意へ 9. 最終献⽴：鶏むねあんかけ＋雑穀ご飯＋蒸しブロッコリー＋味噌汁
24. 課題 いろんな⾓度から案だしてくれる ただ、案を合わせただけであまり知的とは⾔えない（こじつけ） ただ制御⾯から⾒てフィードバック機能ないのは不味くね？
25. フィードバック 役割： • Integratorの案を評価する • 論理的妥当性、計画性、当初 の⽬標と合っているかを確認 • もしこれを満たさなければ、 みんなが好きなRejectを⾏う • 指摘をintegratorに送るため、 次にintegratorから送られて くる内容はマシになってる
26. ⾃⼰相似的構造 なので feedbackerを案を 上に送信する 位置に配置
27. ここから先あまり理解できてないの で専⾨⽤語使わざるを得ない…
28. これまでやってきたことを理解したい 以下の要素 •複雑系 •システム開発⽅法 •主に⼈の管理
29. 複雑系について軽く説明 単純なものが複雑な振る舞いをするもの （↑⼤体こんな感じ）
30. • 複雑系は決して珍しいシステムというわけではなく、実 際に⼈間にとって興味深く有⽤な多くの系が複雑系であ る。系の複雑性を研究するモデルとしての複雑系には、 蟻の巣、⼈間経済・社会、気象現象、神経系、細胞、⼈ 間を含む⽣物などや現代的なエネルギーインフラや通信 インフラなどが挙げられる。 • 相互に関連する複数の要因が合わさって全体としてなん らかの性質（あるいはそういった性質から導かれる振る 舞い）を⾒せる系であって、しかしその全体としての挙 動は個々の要因や部分からは明らかでないようなものを いう [https://ja.wikipedia.org/wiki/%E8%A4%87%E9%9B%91%E7%B3%BB）
31. ⾃⼰組織化と再帰構造について ⽬的： 創発現象を作ること ⼈間のひらめきやアイディアのようなもの
32. ⾮組織的複雑性と組織的複雑性（複雑系） 複数の要素の相互作⽤からなる現象が意味のあるものになるには、 複雑化に対抗できるだけの⾃⼰組織化が必要になる ⾮組織的複雑性を持つ 議論モジュール ちゃんと仕事(会議) させるためには、 協調性が必要かぁ
33. 再帰的に作ることで⾃⼰相似性を作る 複雑性は階層化された ブラックボックスで ⾒えなくなる ＝モジュール化 ⾃⼰相似性は フラクタルとして 好きだからそうしてる
34. 単純な法則から複雑な模様が⽣まれる ちなみにこのような現象は割とどこにでも現れる 普遍的なもの
35. エージェントの内部 ⾯⽩いことにMASの中のエージェントも 似たような構造を内包している また、エージェントの核となる LLMについても同様に⾔える
36. 結合の強弱によって 複雑性を表現してる 引⽤元：https://www.gifu-nct.ac.jp/elec/deguchi/sotsuron ちなみに、 ニューラルネットワークのように 組織を作れたら理想だが、 計算量的に難しい そのため中継地点を作って ⼊出⼒を整備する必要がある 例：蝶形オークション形式 階層型ニューラルネットワーク
37. トップダウン↓ と ボトムアップ↑
38. トップダウン 上のレベルの指令によって下のレベルの振る舞 いは決められる（右） ボトムアップ 下の要素の相互作⽤によって 上のレベルが⽣成される（左）
39. フィードバック機構 トップダウン、ボトムアップの両⽅は、 ⾃⼰組織化されると系全体の状態は固定化される （⼀⽅通⾏は良くないよね） フィードバック機構を⼊れることで、 ⼀つ上のレベルの現象（創発現象）が発⽣する 例： ある蟻がフェロモンを出すと他の多数の蟻がフェロモンを出すという 正のフィードバックによてエサに⾄るフェロモンの道が形成される ちなみにエサのルートの道を作っては消すことが可能（柔軟！）
40. ⾃⼰組織化とフィードバック 複雑性のために必要な要素 • 下のレベルの各要素は⾃発的な運動を起こす • 各要素の関係⾃体が変動しうる これらの複雑性を内包できる設計にする必要がある。 ちなみに再帰構造が有効な理由であるカオスの持つ ミクロとマクロの分離不可能⽣が帰結的に説明できる どこを⾒ても同じ構造をする（フラクタル的性質） 何いってんだこいつ 抽象的すぎやろ… ？？？
41. 双⽅向に動作する Hierarchical / Modular Multi-Agent System 個⼈的には各要素が振動すると表現するがややこしいため略 トップダウンの指⽰が下のレベルの振る舞いを決め、 ボトムアップの提案が情報を形成して組み上げていく 両者の流れを双⽅向にすることで創発を誘発している
42. 基本的な階層型モジュール式MAS ある程度汎⽤的なものが作れる 要件定義から詳細設計を作成するのは このモデルで⼤体できる 下から上：提案 上から下：詳細設計
43. 終わりに（時間余らなかったら） 計算処理というよりかはマネジメントみたい な感覚で設計できて楽しかった ⾃動化とか機械と話すのが 好きな⼈におすすめです！
44. 時間余らないと思うけど余った時⽤
45. 本当のやろうとしてたこと（余談） ？ 間接通信型のタスク共有⽅式（⿊板形式とも⾔う）をやろう としてた
46. 課題 • 各エージェントや横のつなが りで作業を進めるため、通信 の理解が必須だった • 間接通信⽅式では⾃⼰組織化 する要素がなかった ->例えばオークション形式の 蝶形のマーケットを作成する 必要があった • 直接命令する時と⽐べて、 エージェントに⾃律性を持た せないと組織としての維持が 難しい
47. ⼯夫したこと マイクを取り付けて⽂章化され ない背景情報（コンテキスト） をテキスト化する コーディングより上流の設計段階でそもそも破綻 してるのでは？ これはまでは実装速度が遅かったためなんとか なったが、今となっては実装速度に対して要件定 義のような⼊⼒が不⾜しているのでは？
48. ⼯夫したこと • Gemini • Codex • Claude これらをAPIで叩くのではなく、 ラップをして擬似API化させたり、 プログラム内で関数として扱えるようにした Geminiの学⽣無料のやつや chagtpt課⾦している⼈は 実質無料で使えるのでおすすめです
49. これからやりたいこと 部⾨レベルで動くようにしてそれぞれの分化された仕事に特化さ せたい。 ⺠間会社の組織構造を真似したい ちなみにこれまでやってきた構造は軍が近い
50. 参考⽂献（ティール組織、複雑系進化シナリ オ、エージェント技術）のちに追加予定