Transcript エージェント指向開発の落とし穴

Pitfalls of Agent-Oriented Development
エージェント指向開発の落とし穴
Michael Wooldridge & Nicholas R.Jennings
!?
早大 深澤研究室
修士１年 金子 平祐
はじめに
エージェントシステム開発者は
同じような間違いを起こしている
落とし穴を指摘
どのようにすれば避けられるのか?
「人月の神話」
ソフトウェア開発プロセスの間違いを指摘
当時に比べて…
強力な抽象化
オブジェクト指向プログラミング
エージェント → 複雑な分散システム
問題点
エージェント技術は前途有望
エンジニアリング工程に対する研究の欠如
失敗作に
エキスパートシステム
ロジックプログラミング…
落とし穴を７つに分類
政治的落とし穴
管理上の落とし穴
概念化の落とし穴
分析･設計の落とし穴
ミクロレベルの落とし穴
マクロレベルの落とし穴
実装上の落とし穴
オ
ブ
ジ
ェ
ク
ト
指
向
開
発
の
落
と
し
穴
対象エージェントシステムは?
マルチエージェントシステム
例:工場のコントロールシステム、情報検索…
2.政治的落とし穴
2.1 誇大広告
2.2 エージェント教へ入信
→自分の宗派のみを信じる
2.1 誇大広告
エージェント技術
○複雑な分散アプリケーション
×不可能を可能にする
×高度な知性
エキスパートシステムの轍を踏まぬように!!
2.2 エージェント教へ入信
→自分の宗派のみを信じる
他の開発パラダイムに排他的に
多くの場合、従来の開発手法の方が適切
←管理、理解しやすい
自分たちの定義が絶対的なものと信じる
例：スタティックなエージェントの方が適切なのに
無理やりモバイルエージェントを使う
3.管理上の落とし穴
3.1 なぜエージェントが欲しいのか分からない
3.2 自分のエージェントが何に向いているのか分からない
3.3 一度きりの問題なのに一般的ソリューションを作りたがる
3.4 実際のシステムとプロトタイプをごっちゃにする
3.1 なぜエージェントが欲しいのか
分からない
何故使いたいのか分からぬままプロジェクト開始
成功しているかどうかの判断もできない…
表面上は突然の破局的!!
しっかり理解すること!!
Wh
y?
3.2 自分のエージェントが
何に向いているのか分からない…
見事開発成功!!
適用できるアプリケーションを捜し求める
ミスマッチ、不満の種
自分の技術が何に役立つのか認識
全ての問題に適応しようとはしないこと
everything…
3.3 1度きりの問題なのに
一般的ソリューションを作りたがる
潜在的な要求を満たしたい!!
再利用は難しい…
再利用可能!!という主張には何の根拠も無い
初期のAIを教訓とせよ
再利用、再利用、再利用
3.4 実際のシステムと
プロトタイプをごっちゃにする
プロトタイプを作るのは簡単
頑健で信頼できるシステム構築とのギャップ
難関
•並行性、分散性
•エージェント間のインターフェース
•コンテキストに依存する振る舞い
=
4.概念化の落とし穴
4.1 エージェントが銀の弾丸だと信じこむ
4.2 専門用語と概念をごっちゃにする
4.3 ソフトウェアを開発している事実を忘れる
4.4 分散ソフトウェアを開発している事実を忘れる
4.1エージェントが
銀の弾丸だと信じこむ
銀の弾丸
ソフトウェア開発の偉大なる効率向上技術
ソフトウェア工学の発展=抽象化の歴史
手続き→構造→抽象データ型→オブジェクト
→エージェント ?
4.2 専門用語と概念をごっちゃにする
｢エージェント｣は直感的で分かりやすい
→理解していないのに理解した気になってしまう…
例:
BDI(Berief-Desire-Intention)モデルは
多くのエージェントに引用された結果、
その意味を失ってしまった…
!!
4.3 ソフトウェアを開発している
事実を忘れる
一般的な開発プロセスの忘却
→最悪の結果に
エージェント固有の開発テクニックは未成熟
→OOの技術を使うべき
分析、設計
テスト…
4.4 分散ソフトウェアを開発している
事実を忘れる
マルチエージェントシステムは分散システム
→分散システムの研究結果を活用すること
特に意識すべき点
•同期
•共有リソースへの相互排他
•デッドロック、ライブロック
5.分析･設計の落とし穴
5.1 関連テクノロジー採用しない
5.2 並行処理を意識しないデザイン
5.1 関連テクノロジーを採用しない
ぶどうパン
エ
ー
ジ
ェ
ン
ト
固
有
の
技
術
従来技術
CORBA､DBシステム、エキスパートシステム
5.2 並行処理を意識しないデザイン
並行性を考慮していないシステム
エージェントA
エージェントB
エージェントC
並行性はマルチエージェントシステムの特徴!!
6. ミクロレベルの落とし穴
6.1 自分でエージェントアーキテクチャを作る必要
があると思いこむ
6.2 自分のアーキテクチャが一般的と思いこむ
6.3 過剰なAIの利用
6.4 ちっとも知的じゃないエージェント
6.1 自分でエージェントアーキテクチャ
を作る必要があると思いこむ
エージェントアーキテクチャ
= エージェントたちを構築していくためのデザイン
例：Procedural Reasoning System(PRC)
様々なアーキテクチャを学習
→既成のものを利用すること
6.2 自分で作ったアーキテクチャが
一般的と思い込む
特定問題のために作ったアーキテクチャ
別問題には合うはずがない
特定の問題に効いた理由をしっかり認識
→同じ特徴をもった問題にだけ適用すること
6.3 過剰なAIの利用
実用的ではない高度なAI技術の利用
過負荷
頑健性
必要最小限のAI技術を利用すること
6.4 ちっとも知的じゃないエージェント
マルチエージェントシステムと称する単純な分散システム
あなたのエージェントとして機能するWWWページ
“エージェント”という言葉の意味の消失
期待から失望へ
7.マクロレベルの落とし穴
7.1 どこにでもエージェントを見出してしまう
7.2 沢山のエージェントを使ってしまう
7.3 ほんの少しのエージェントしか使わない
7.4 インフラ整備に時間をかけすぎ
7.5 無政府状態のシステム
7.6 真の並行性とにせものを混同する
7.1 どこにでもエージェントを
見出してしまう
足し算エージェント、引き算エージェント？
階乗計算N!
→n個のエージェントが必要に…
管理、協調→多大なオーバーヘッド
This is Agent
エージェントはある程度
粒度の粗いものにする
That is Agent
and…
7.2 沢山のエージェントを使ってしまう
カオス
中央コントロールの設置
コミュニケーション経路の規制
コミュニケーション方法の単純化
7.3 ほんの少しのエージェントしか使わない
マルチエージェントの価値を理解していない
全ての機能を一つのクラスにまとめたら？ (in OO)
並行性の利用の放棄
7.4 インフラ整備に時間をかけすぎ
エージェントシステム開発のためのプラットフォーム
メッセージ処理、追跡･モニタリング･実行管理
大量の時間、予算がインフラストラクチャー作成に…
AIの研究者が作ったシステム
7.5 無政府状態のシステム
無数のエージェントが無秩序に振舞うシステム
(単なる一例に過ぎない)
大規模システム
共通目的をもったエージェントを
いくつかの社会に分ける
7.6 真の並行性とにせものを混同する
プロトタイプ
分散システム、並行性実現は
非常に難しいことを認識すること
本物
8.実装上の落とし穴
8.1 まっさらな状態から作りこんでしまう
8.2 デファクトスタンダードを無視する
8.1 まっさらな状態から作りこんでしまう
レガシーソフトウェアをどうするか?
→ラッピング
8.2 デファクトスタンダードを無視する
標準規格がない!!
→×異なるシステム間での協調動作
デファクトスタンダードを利用すること
ex.KQML,ACL
まとめ
エージェント技術
複雑な分散システム構築
未成熟
体系だったフレームワークを提供
実践的な問題点を解決