第１章 ルールエンジン
1.1.ルールエンジンとは何か
1.1.1.イントロダクションと背景
人工知能(AI)は、「人間のように考えるコンピュータを作る」ことを目的とした非常に幅広い研究領域を表し、ニューラル・ネットワークや遺伝的アルゴリズム、決定木、フレームシステム、エキスパートシステムのような分野を含みます。そのうちの一つ知識表現は、知識がどのように表現され、取り扱われるかということを研究します。エキスパートシステムでは、知識を推論を行うのに用いる知識ベースの形式へとコード化しやすくするために、知識表現を用います。われわれは、この知識ベースを用いることによって、データを操作し結論を推論することができるようになるのです。エキスパートシステムは、知識ベースシステムとか知識ベースエキスパートシステムという呼び名でも知られ、応用人工知能と考えられており、エキスパートシステムを開発するプロセスのことを知識工学と呼びます。EMYCINは、エキスパートシステム向けの最初の”シェル”の一つで、医療診断エキスパートシステムMYCINから作られたものです。初期のエキスパートシステムではハードコーディングしていたロジックを、”シェル”として、システムから分離したことで、ユーザ入力の環境が使いやすくなりました。Droolsは、エキスパートシステムを実装するためにルールベースアプローチを用いたルールエンジンであり、より正確には、プロダクションルールシステムに分類されます。
プロダクションルールは、形式文法にその起源を持っています。形式文法は、形式言語を正確に表現する抽象的な構造として記述されます。これはつまり、(通常有限個の)アルファベット上の(通常無限個の)有限長文字列の集合を生成する規則の集合を表します(wikipedia)。
ビジネスルールマネジメントシステムは、ルールマネジメント、ルールの配備(deploy)、共同(collaborate)、分析、ビジネスユーザ向けのエンドユーザ用ツールを提供しているルールエンジンの上に成り立っています。これに加え、「ビジネスルールアプローチ」は、企業におけるルールエンジンの役割に形を与えるのに役立つ、現在急速に発展し、人気を得ている方法論です。
ルールエンジンという言葉は、とてもあいまいです。データに対してルールを適用し、結果を得るというようなシステムであれば、どんな形であれ、どんなものでもルールエンジンとなってしまいます。たとえばフォームにおけるチェックや動的な計算エンジンのような簡単なシステムも含まれてしまいます。Malcolm Chisholmによる”How to Build a Business Rules Engine (2004)”は、このあいまいさを例証しています。この本は、実のところ、どのようにして整合性のルールを維持しながらデータベーススキーマを作り変更していくかを示すやり方、そして、これらデータ入力をチェックする検証ルールからどのようにしてVBコードを生成してくるかを示しているだけです。これはある人にとっては、とても有効で役に立つトピックである一方、このことは、その時には、ルールエンジンの微妙な違いに気づかず、Droolsのエンジンを改善するのに役立つ隠された秘密を見出そうと望んでいたこの本の著者に驚きを与えました。jBPMはディシジョンノードにおいて式と代理人を使います。代理人は、ワークフローの中の遷移を制御するものです。それぞれのノードで執り行われる遷移を命令するルールを評価します。これもルールエンジンです。プロダクションルールシステムは、ルールエンジンの一種であると同時に、エキスパートシステムでもあります。しかし一方、先に述べた検証と式の評価を行うルールエンジンは、エキスパートシステムではありません。
プロダクションルールシステムは、命題論理、１階述語論理を、簡潔であいまいでない宣言的な方法で表現しようとする知識表現に焦点をおいたチューリング完全なシステムです。
プロダクションルールシステムの頭脳は推論エンジンであり、たくさんのルールやファクトを持ったシステムにスケールアップしていくことができます。推論エンジンは、ファクト、データをプロダクションルール(プロダクションとか単にルールとか呼ばれることもあります)にマッチさせ、アクションに終わる結論を導き出します。プロダクションルールは、知識表現形式としての１階述語論理を用いて、２つの部分を持った構造をしています。
when
<条件>
then
<アクション>
プロダクションルールに対して、新しいファクトや既存のファクトをマッチングさせるプロセスをパターンマッチングと呼び、推論エンジンによって実行されます。推論エンジンがパターンマッチングに用いるアルゴリズムには、多くの種類、たとえば
Linear
Rete
Treat
Leaps
があります。
Droolsは、ReteとLeapsの両方の実装を持っています。ただし、Leapsはごく最近のもので、まだ実験的な実装と考えています。DroolsのReteの実装は、ReteOOと呼ばれ、Droolsがオブジェクト指向のシステム向けのアルゴリズムで、Reteの性能をさらにアップし、最適化した実装を持っていることを意味しています。他のReteベースのエンジンも、Reteへの独自仕様の拡張に対して、RetePlusやRete IIIなどといった、マーケティング用の用語を持っています。ここで重要なことは、Rete IIIのような名前は、オリジナルとして公開されたReteアルゴリズムとは違い、純粋にマーケティング用のもので、実装の詳細については公開されていません。したがって「DroolsはRete IIIを実装していますか？」という質問をするのは意味がありません。もっとも一般的なReteの拡張は、Robert B. Doorenbos.による”Production Matching for Large Learning Systems (Rete/UL)” (1995)でカバーされています。
ルールは、プロダクションメモリに記録され、推論エンジンがマッチさせるファクトは、ワーキングメモリに記録されます。ファクトは、ワーキングメモリに登録され、そこで、変更を受けたり、削除されたりします。たくさんのルールとファクトを持ったシステムは、同じファクトの表明に対して、多くのルールが真になっていると返してくるかもしれません。この場合、これらのルールは競合関係にあると呼ばれます。アジェンダは、競合解消戦略を用いてこれら競合するルールの実行順序を管理します。
Figure 1.1. A Basic Rete network
プロダクションルールシステムの推論エンジンは、状態を維持することができ(stateful)、真理を強制する－真理維持(整合性維持)と呼びます－ようにできます。論理的な関連はアクションによって宣言されます。この意味するところは、アクションの状態が、真理維持の推論に依拠しているということです。すでに真でなくなったとき、論理的依存のアクションはおこなわれなくなります。「正直な政治家」は、真理維持の一つの例で、この機構は、常に、正直な政治家がいる間は、民主主義に対し、希望が存在するということを確証しています。
when
正直な政治家がいる
then
必然的に希望を主張する
when
希望がある
then
print “万歳！ 民主主義は生きている”
when
希望がない
then
print “民主主義は死んだ”
プロダクションルールシステムには、２つの実行方法があります。前向き推論と後ろ向き推論で、その両方を実装したシステムは、ハイブリッドプロダクションルールシステムと呼ばれます。これら２つのモードのオペレーションを理解することが、プロダクションルールシステムがなぜ違っているのか、それらのどちらがベストかを得る方法を理解するキーとなります。前向き推論は、「データ駆動」すなわち反応駆動的 － ファクトがワーキングメモリに登録され、その結果一つかそれ以上のルールが同時に真となり、アジェンダによって実行をスケジューリングされる － で、まずファクトで始まり、それが伝播していき、ひとつの結論に至って終わります。Droolsは、前向き推論エンジンです。
Figure 1.2. Forward Chaining
後ろ向き推論は、「ゴール駆動」になります。結論から始めて、ルールエンジンは、その結論が満たされるかどうかを検証していきます。もし満たされるかどうか直接わからないようであれば、現時点でのゴールに対する未確認の部分を「サブゴール」として定め、その「サブゴール」が満たされるかどうかを調べます。そして、最初の結論が証明されるか、それ以上サブゴールがなくなるまでこのプロセスを続けます。Prologは、後ろ向き推論エンジンの一つの例です。Droolsは、次のメジャーリリースで後ろ向き推論をサポートするることを予定しています。
Figure 1.3. Backward Chaining
(文中、図(Figure)については、ひとまず原文を参照ください)
