Progress Corticon
BRMSコンサルタントが語る ~超高速開発だけがメリットではない~ Vol.2
ルールエンジンのアルゴリズム
ここのところBRMS(ルールエンジン)を使ったシステム開発が以前に比べだいぶ増えてきましたが、まだまだ人口に膾炙するといったところではないようで、ルールエンジンの動き等に関連していろいろ質問されることが多々あります。
例えば、以下のようなものがあります。
- ルールエンジンのプログラムって、if-Thenのルールが並んでいるけれども、上から順にやっていくの?
- (上記に関連して)通常のプログラムの(単体)テストだと全部のパスを通るようにテストするけれども、ルールの場合のテストでは、全部のパスを通す…ってどのように考えればよい?
- ルールエンジンのメモリ使用量は何に依存してきまるのでしょうか?ルール数?
- 同じようにルールエンジンの処理速度は何できまる?
多くのルールエンジンは、一般的なプログラミング言語の実行方法(手続き的)と動きの原理が違い、またif-thenルールはコンパイル時にネットワークの形に最適化されると同時に、実行時にデータの重複評価をしないように判断結果をキャッシュしたりもします。
ここではまず、ルールエンジンの動きを見ていきましょう。このルールエンジン、もともとは人工知能や認知心理学の研究をルーツとするもので、人間が長期記憶にあたる「ルール」を使って、認識した外界の状況(短期記憶に保持される)に合わせて判断を行うという行動がモデルとなっています。
これをルールエンジンの動きとして翻訳してみると、以下のようになります。
- 1.データの集合に対して、たくさんあるルールの条件部分をひとつひとつデータとマッチングさせて、マッチしたルールとデータのカップルを列挙しておく。
- 2.カップルの中からひとつを選んで実行する。
- 3.実行によってデータが書き換えられる場合もあるので、再度1のカップリングを行う。
- 4.1~3を繰り返してマッチするルールがなくなったところで実行が終了する。
この動きをみるとわかるように、ルールエンジンでは、すべてのデータに対して、すべてのルールの条件部のマッチングを試し、そののちにルールを実行します。したがってルールの実行順序は必ずしも上から順などといったことではありません。
ルールエンジンにも現実的には実行順の規則はあるのですが、そもそもルールによるプログラミングそのものが、実行の順番ではなくルールの条件に合ったものから実行するという考え方なので、実行順に過度に依存するようなルールの書き方はルールによるプログラミングのお作法に反するものと言えましょう。
特に最近ルールエンジンがよく使われている入力データのチェックなどは、(チェックそのものだけでいえば)別に順番などはどうでもよく、条件に合うか合わないかで正しくエラーが出ればそれでよいのであって、上記のようなルールエンジンの動きはこの「チェック」という作業に対して非常に親和性の高いもののように思います。
もっとも、入力データのチェックなどは、ルールのパターンマッチの側面こそ利用していますが、一方でルールの実行中に入力データが変わっていくわけではないので、先に挙げたルールの実行サイクルを何度も回して結果を出すという特徴的なところはあまり利用していないとも言えます。
では、よりルールエンジンの動きの特徴が表れている例というとどんな例があげられるでしょうか。思うに、たとえば質問に対して答えていき最後に結果を出すといったコンサルティングというか、レコメンドというか…といったシステムの例はそのひとつではないでしょうか。
この動きをルールエンジンの実行サイクルに合わせて見てみましょう。
- 1.システムは利用者に対して最初の質問を投げます。
- 2.利用者は質問に対する回答を行いその回答はデータとして(短期)記憶領域に書かれます。
- 3.システムはこの回答に合ったルールを選び出し、次の質問を利用者に投げます。
- 4.利用者はさらに回答を行い結果は記憶領域に書かれます。
- 5.システムは今までに出した質問の結果と今回の質問の結果を合わせて条件に合うルールを選び出し、さらに質問を繰り返していきます…。
- 6.そして最後に十分に絞り込まれた結果が得られそれ以上尋ねる質問がなくなった(マッチするルールがなくなった)ところで利用者に結果を返します。
これだけではあまりに抽象的なので、もう少しかみくだいた例として、たとえば、料理に合うワインをおすすめするといった場合を考えてみましょう(この具体的な実装は、Clipsというツールの例としてあげられています)。
まず質問の例としては、以下が挙げられます。
- 1.料理は肉、魚、鳥料理のうちのどれですか?
- 2.料理にはソースがかかっていますか?
- 3.ソースは、スパイシー、甘口、クリーム、トマトのうちのどれですか?
- 4.料理の味は、繊細、ふつう、強めのうちのどれですか?
- 5.ワインとしてお好きなのは赤と白とどちらですか?
これら質問をルールとして保持し、ルールの実行部分で質問の回答を記憶領域に書くようにしておきます。
さて、まず最初に1の質問のルールが動き、質問に対して「肉」という回答をすると、(短期)記憶領域に
・「料理は肉」
と書かれます。次に2の質問に、「ソースがかかっていない」という回答をすると、記憶領域に
・「料理にはソースがかかっていない」
という事実が追加されます。
次に3の質問。これは本来、料理にソースがかかっていなければ意味のない質問です。したがって、3の質問を行うルールの条件部分には「料理にはソースがかかっている」という前提条件を加えておきます。そうすると、現在の記憶領域の状態
・「料理は肉」
・「料理にはソースがかかっていない」
に3の質問ルールはマッチしないので、ルールは実行されません。一方、2でソースがかかっていると回答すると自然に3のルールもマッチしてきます。
このように、質問を行う各ルールの前提条件をきちんと書いておけば、意味のない質問をすることもなく、効率的に結果を求めることができましょう。
さて、実は上の議論では少々ゴマカシがあるのですが、お気づきでしょうか。上の議論では、1から順に実行することが前提となっているような書き方になっていますが、ルールエンジンの一般的な動きでは上から順に動くという保証はありません。順番に関して何も指定していない(*1)と、上記のルールのうち1,2,4,5のどのルールが最初に動くかの保証は何もありません。まあ、論理的には最初に1,2,4,5のどの質問から聞いても結果は同じなのですが、ワインの好みに対して聞く4,5の順番はともかく、1,2は気持ちとしては、1の次に2を聞くのが普通かと。こんなときには、
A. 2の前提条件に料理の種類が決まっている条件。具体的には、「料理は○○」という事実があるという条件を加える。
B.ルールに優先度をつけて、1が2よりも先に動くようにする。
というような解決方法があります。まあ、ルールの一般的なお作法としては、A.のほうが推奨ですが、ケースバイケースで一概にどちらがいいというわけでもありません。さらに質問のかたまり間で順番をつけたいという場合に、たとえば料理に関する質問のルール、ワインの好みに関する質問のルールといったかたまりの間での順番をつけたいというときには、ルールのかたまりとその順番を定義するという仕組みがたいていのルールエンジンに標準的に装備されています(Droolsでは、アジェンダグループとか、ルールフローとか、またCorticonで言えばルールシートがこれにあたるでしょう)。
-
※1実は、ルールが動く順番は全くのランダムというわけではなく、たいていの場合何らかの規則にしたがって、実行されるルールが選ばれます。この規則を競合解消戦略といって、考え方としては、「最新の情報を優先する」、「一般的な条件のルールと、より特殊な条件のルールと両方にマッチした場合は、特殊な条件のルールを優先する」などといった基準があります。
ルールベースAI(BRMS)についてもっと知る
-
※
本コラムは、http://blog.iluminado.jp/
の記事から一部を改修したものを掲載しています。
著者プロフィール
|
BRMSコンサルタント。 |
関連記事
- 2022.11.16
アシスト、DXに欠かせないルールべースAI「Progress Corticon」の新バージョン6.3を提供開始
- 2022.4.7
アシストがProgress社製品の販売活動において「Progress Accelerate Partner Distributor」を受賞
- 2022.2.16
生命保険エコシステム リリース第2弾 「生命保険給付金支払いプラットフォーム」採用2社目
- 2021.11.17
生命保険エコシステム リリース第1弾 「生命保険給付金支払いプラットフォーム」始動
- 2021.9.6
アシスト、「GOLD Cloud Platformコンピテンシー」取得で、Microsoft Azure上での業務自動化を強力に支援