ルールベース・プロダクションシステム

SONYのエアボードはハードウェア



この営業方法こそ、昔、研究されたルールベース・プロダクションシステムそのもの

エキスパートシステム


人工知能、AI, Artificial Inteligenceの応用のひとつだ・・・


http://www.iluminado.jp/businessruleruleengine/rule-base-etc/16-rule-base/17-production-system-rule-base.html

プロダクションシステム(ルールベースシステム)とは

作者 Administrator

2006年1月10日(火曜日) 20:16

ここでは、ルールベースのプログラム実行について通常のプログラミング言語によるプログラムとの対比によって見ていきます。  　 通常のプログラミング言語(JavaやC#、Visual Basicなど)によるプログラムは、変数と代入、条件分岐、繰り返しなどの一連の命令から構成されており、基本的 には、プログラムの上から逐次的に実行されます。この場合のプ ログラムは、計算を「どのように(howto)」実行していくかを考え、それを逐一プログラム上に記述することで作られます(このプログラミング手法を命 令型プログラミングとか手続き型プログラミングなどと呼びます)。　 　一方、ルールベースのシステムでは、「何を(what)」を記述する ことによりプログラムを作成します。このことでルールベースのシステムでは、通常のプログラミングで結構煩雑な記述となる「どのように」という部分を(あ まり)意識せずにプログラムを作成することができます(この、「何を」をもとにプログラムを記述するプログラミング手法を宣言型プログラミングと呼びま す)。以下では、ルールベースのシステムがどのようにして「どのように」実行するかという部分と、「何を」実行するかという部分を切り離して管理するかと いうところを見ていきましょう。 一般的に、ルールベースのシステム(プロダクションシステム)は、次のような構成要素からなっています。    1. ルール    2. ワーキングメモリ    3. 推論エンジン   ルールベースシステムは、 通常のプログラミング言語によるシステムの構成要素とごく単純に(誤解を恐れず)比較して、たとえてみると、 通常のプログラミング言語 ルールベースシステム   プログラム  ルール＋推論エンジン  変数  ワーキングメモリ と なります。ルールベースシステムにおいては、プログラムは、実行をつかさどる推論エンジンと、「何を(what)」行うかを記述するルール部分とに別れま す。通常、推論エンジンは、いわゆるルールエンジンとして汎用的なものが組み込まれており、「どのように」の部分である実行の順序を一括で管理していま す。したがって、ルールベースシステムにおけるプログラム では、「どのように(howto)」行うかを記述する必要はなく、もし△△であったら××をするというif-ｔｈｅｎ形式のルールを列挙することで「何を (what)」を記述することになります(プログラムの具体的な事例については、別の項で説明します)。 　(もっともルールベースのルールを使って、手続き的な記述を行うこともできるのですが、それはたとえて言うなら、Javaで、一連のプログラムを一つのクラスに押し込めて記述をするようなもので、ルールベースの本来の使い方ではないでしょう。)  ルールベースの実行は、ワーキングメモリに記述されたデータに対して、そのデータとマッチする「もし~であったら」部分を持ったルールを推論エンジンが探 し出し、マッチしたルールに書かれている「~をする」部分の記述にしたがって、ワーキングメモリに新たにデータを書き込むなり、消去するなり、メッセージ を表示するなりして実行されます。これだけですと、一つのルールが実行されるだけですが、推論エンジンは、再び新たな(状態が多少変わったかもしれない) ワーキングメモリのデータに対して、マッチするルールを探してルールを実行していきます。こうしてマッチするルールがなくなった時点でプログラムの実行が 終了します。 (正確に言うと、これは「前向き推論」の場合の推論エンジンの説明)。 この実行方法について、ワーキングメモリに書かれたデータとルールとのマッチングから、ルールの実行までのサイクルのことを認知実行サイクルといいます。  　 上にすでに書いたように、ルールベースの実行の方法－ 認知実行サイクル－では、まず、 ワーキングメモリに書かれた情報と、ルールの ｉｆ 部分(条件部)と照合がなされます。 ここでマッチしたワーキングメモリとルールとの組が、実行の候補となって候補リスト(「アジェンダ」と呼ぶ)にあがってきます。次に、その候補の中から、ある決まった「戦略」にし たがって選択され(競合解消)、実行されます。このサイクルの繰り返しで次々にプログラムの実行が進んで行き、ワーキングメモリの内容とルールの if 部分とでマッチするものがなくなったときにプログラムの実行が終了することとなります。 　(「戦略」については、別途項をあらためて説明します)  ルールベースシステムの適用分野 作者 Yasuhiko Tsushima    2006年2月11日(土曜日) 20:56 　ルールベースシステムで実装するのに適した問題を、一口で言うことは難しいですが、一般的には、 　・複雑な条件判断が組み合わさっている ・仕様が頻繁に変わる ような問題に対しては、ルールベースシステムが適しているといえます。 　ルールベースシステムにおいては、(これ以上分割できないという意味で)アトミックなif-thenルールをルールベースに個別に登録していくことで、プログラムを作って行きます。プログラムの実行については備え付けのルールエンジンが適切に判断してくれるため、競合解消の戦略を上手に使ったり、優先度の仕組みをうまく設計しておくと、後から個々にルールを追加していくだけで仕様の変更ができるルールベースが作れます。 たとえば、通常の場合は一般ルールを使うが、ある特殊な場合には、特殊なルールを使うなどといったときには、競合解消の戦略として、複雑な条件をもったルールを優先するという戦略をとることで、容易にルールセットを書くことができます。具体的には、最初に、 「全国で使用する(＝条件部で特に地域の指定がない)デフォルトの接着剤は△△を用いる」 「寒冷地では(=条件部で寒冷地地域の指定がある)、(寒さにも接着強度の落ちない)接着剤××を用いる」 などというルールのセットがあった場合、後から新たに 「雨量の多い地域では、(防水性が高く経年変化に強い)接着剤□□を用いる」 といった特殊なケースが追加されたとき、ルールの判断順序を気にすることなく、その特殊な場合のルールを追加するだけで、仕様の追加ができます。 (さらに、寒冷地でかつ雨量が多いというようなケースがあった場合は、最初からルールに優先度をつけてしまうか、and条件のルールを書いていくなど、ケースバイケースで適切な対応をとることができます) 以上のように見ていくと、ルールベースの応用システムとして、顧客の属性に応じて、顧客に適した商品を薦めるといったレコメンデーションシステムなどは、確かにルールベースのしくみに合っているといえるでしょう。 　その反面、アルゴリズムが明確に決まっており、複雑な条件分岐もなく、仕様変更もあまり頻繁でないシステムでは、無理にルールベースで書く必要はないでしょう。計算をゴリゴリ行うプログラムなど、実はルールベースで書けなくもないのですが、かなり書きにくいでしょう。 パターンマッチを基にしたルールベースシステムというと、パフォーマンスを気にする方がいらっしゃいます。確かに概念的には、ルールベースのすべてのルールの条件部と、ワーキングメモリのすべてのfactとの間で常にマッチングの検査をして、マッチするものを選び出しています。しかし、内部的にはReteマッチアルゴリズム(とその進化形など)を使って、以前に比較したルールの条件部とfactとの組で、再度同じマッチングをする必要がない場合に重複しないように配慮がされるので、性能面を気にしすぎる必要はないように思います。ミッションクリティカルなスピード重視の場合ならともかく、だいたいの場合それほど問題にはならないと思います。      *** ルールベースの ・複雑な条件判断が組み合わさっている ・仕様が頻繁に変わる といった問題解決に適しているという性質は、その昔、人工知能の応用技術であるエキスパートシステム*1の作成において大いに利用されました(ルールベースのルーツは、人工知能の研究にあります)。エキスパートシステムの構築は、「専門家の知識をヒアリングを通じて引き出しては、その知識をシステムに組み込んで評価する」ということの繰り返しです。構築そのものが要求仕様の変更を前提としているエキスパートシステムが、仕様変更に強いアーキテクチャを必要としたのは当然のことでした。 米国のミニコンメーカで、その昔DEC*2という会社がありました。この会社、実は人工知能の技術にも力を入れていて、VAXというコンピュータの構成を決める実用エキスパートシステムを80年代に稼動させていました。名前をR1/XCONというこのシステム、一度は、従来の手続き的な言語で作成されたのですが、メンテナンスがとてもできないということで、ルールベース言語のOPS5で書き直されました。書き直された後のシステムは、メンテナンスも容易になり、ビジネスの現場で使われるようになって実用的なエキスパートシステムとして最初の成功事例として語られています。 *1　エキスパートシステム：　病気の診断や、故障診断、生産計画などの専門家の知識をシステムに取り込むことによって、専門家の支援を行うことを目的とするシステム。 *2　DEC(Digital Equipment Corporation)：　 昔はミニコンメーカとして一世を風靡したものですが、今はありません。90年代の後半にコンパックに買収され、さらにコンパックはHPに買収されています。 CLIPS超入門１(インストールと起動) 作者 Administrator    2006年1月22日(日曜日) 08:22  CLIPSとは CLIPSは、ルール/オブジェクトベースのエキスパートシステム開発ツールで、そのベー スとなるプロトタイプは 1985年(今から20年以上前！)、アメリカ合衆国のNASA、ジョンソン宇宙センターで開発されました。パブリックドメインのフリーなソフトであり、 C言語で書かれ、他の環境とも統合が比較的容易であったために広く知られるエキスパートシステム開発ツールとなっています。このCLIPS、残念ながら日 本語が使える版は見当たらないのですが(個人的に日本語化している版はあるかもしれませんが、一般的に使われている日本語版は見当たりません)、インス トールが容易でWindowsの対話環境も使用できるので概念を学ぶための学習環境としてはスグレモノだと思います。そこで、ここではルールベースの考え 方を具体的に知るために、CLIPSを用いてみましょう。  CLIPSのインストール(Windows) まず CLIPSのサイトに 行き、ダウンロードエリア(Download Area)から、実行モジュール(executables)－PC版(pc)を選択し、CLIPSWin.zipおよびCLIPS6.hlpをダウンロー ドしてきます。CLIPSWin.zipを解凍し、適当なディレクトリに、CLIPSWin.exe、CLIPS6.hlpを入れて、インストールは完了 です。CLIPSWin.exeのアイコンをダブルクリックすれば、CLIPSが起動します。  CLIPSの起動 CLIPSを起動すると、以下のような画面が表示されます。   この対話環境で、CLIPSをさわってみましょう。CLIPSのプロンプトに続けて、 (+ 1 3)  と打ち込んで見ましょう。すると、 4 と値が返ってきます(同じように－,*,/などもできます。適当に試してみてください)。   CLIPSでは、計算手続きなどを「関数」の形で記述します。CLIPSの関数は、プログラミング言語のLispと同じように、 (<関数名>　<引数1>　・・・　<引数n>)  の形で書きます。 CLIPSの組み込み関数は、メニューからHelpを選択すると(英語ですが)参照できます。ここでは、よく使う関数をあげておきましょう。 (printout　t　　crlf) を標準出力に改行付きで出力する。't'　はterminal、’crlf’　は改行を表す。 それから、対話環境 のコマンドについても (exit) 対話環境を終了する。(メニューのFile-Exitが対応) (load <ファイル名>) <ファイル名>で指定されたルールファイルを読み込む。 ディレクトリのパスを付けないと、CLIPSWinのexeファイルがあるディレクトリがデフォルトとなります。(メニューのFile-Loadが対応) ただし、本稿の目的は、ルールベースの考え方を説明することなので、ここではこれ以上CLIPSの関数、コマンドに深入りしないこととします。以降必要の都度、関数・コマンドを説明していきます。 //////////// http://business.nikkeibp.co.jp/article/tech/20100521/214542/?P=1

営業現場の「見える化」を実現

　iPadの可能性は、シニア端末としての活用だけではない。営業現場を一変させるだろう。営業担当者はプレゼンテーションソフトを使ったセールス活動から、営業を受ける側にとってはこれまでのつい眠くなってしまうプレゼンテーションから、解放されるかもしれない。解放されるかもしれない。営業資料そのものの作り込みを変えていく必要がある。

　ほんの数カ月先の営業現場では、次のようなシーンが垣間見れるようになることだろう。営業担当者は、テーブルの上にiPad端末を置く。まず、iPadという新たなガジェットを使わせてあげるということで、最初のアイスブレークは間違いなく成功する。続いて、「ではここを触れてみてください」と声をかけて、自社製品を宣伝する営業資料アプリを立ち上がらせる。「気になるところは、どんどん触れてみてください」。顧客はついつい気になるところに触れてしまう。直感的に。そうすると、触れた部分に関する宣伝文句をiPadが話し出す。

　営業というものが、営業マンが自社製品の良さをアピールするプレゼンテーションから、顧客のほうから気になるところをどんどんと触れ、勝手に内容を理解していく。そういうスタイルへと変わる。そんな場面に出くわすこともありえないことではない。

　ひとしきり「さわり」終えたところで、画面に4つのボタンが現れる。「今すぐに購入を決める」、「社内で前向きに検討する」、「今はこちらの商品を購入するタイミングではない」、そして「こちらの商品は残念ながらお客様のニーズには答えていない」。

　この画面が出たところで、営業担当者は「いかがでしょうか？」とまた声をかけるのである。

　さて、ここまで来たところで、読者の皆さんはお気づきだろう。こうした営業が繰り返されてくると、次の情報が蓄積されるようになる。しかも自動的に。この商品の営業資料アプリのどこを顧客が触れたのか。どの順番で触れたのか。どの説明を長く聞いたのか。または聞いていないのか。そうした顧客の関心事項と、それに触発された「指の行動」というログデータが蓄積されることとなる。最後の購入意向とともに――。

　今、様々なSFA（Sales Force Automation：営業支援システム）が存在する。営業担当者の営業力というものを底上げするために用いられている場合が多い。ところが、営業現場で何が起こっているのかを、データとして吸い上げるのは難しい。しかし、iPadを活用して上記のような営業資料アプリを作成することで、顧客の現場での「生の反応」というものを蓄積できる可能性を持っているのである。今まで見えていなかったデータの「見える化」が可能となる。新たなビジネスチャンスがここにある。

　ただし、1点気をつける必要がある。カフェテリアなどの外で営業活動を行う場合である。太陽の下で、テーブルに置かれたiPad。光の反射具合で、少し見えにくい場合もあるだろう。iPadを15度ほど傾けて置くスタンドを営業担当者は持ち歩かねばならないだろう。