JPH0750441B2 - 規則ベース・システム管理装置および方法 - Google Patents

Description

【発明の詳細な説明】 A.産業上の利用分野 本発明は、一般にはコンピュータ・システムに関し、特
に、規則ベースのエキスパート・システムに用いられる
効率管理および拡張用のツールに関する。

B.従来の技術 エキスパート・システムは、汎用コンピュータ上で実行
されるコンピュータ・プログラムであり、ある分野の専
門家の知識を取り入れようとするものである。取り入れ
られた知識は、観測可能なデータを入力することによっ
て、例外的な観測の原因に関する仮説を受け入れること
できるか、または複雑な判断を行う際にアドバイスを受
けることのできる非専門家によって用いられる。代表的
なエキスパート・システムは、事実や相互関係を含めた
データおよび規則を取り入れる。エキスパート・システ
ムによって用いられるデータベースは、知識ベースと呼
ばれることが多い。

エキスパート・システムは、実行されるときには、大量
のCPU資源を使用する。

エキスパート・システムの技術を、主力のデータ処理環
境に組み込む場合、効率化に相当の労力を注ぐのでなけ
れば、第３世代のプログラミング言語を用いた従来の手
続き型の手法と、効率面で競い合うことはできない。

最も普及しているエキスパート・システムは、プロダク
ション・システムと呼ばれる。ユーザは、左辺（LHS）
と右辺（RHS）とから成る規則を作る。規則のLHS条件が
満たされれば、その規則は発火（fire）され、RHSが実
行される。RHSは、ワーキング・メモリの状態を変え
る。ワーキング・メモリは、エキスパート・システムに
よって用いられる事実とデータの構成要素をすべて含
む。規則が発火されると、規則のLHSは、変更されたワ
ーキング・メモリと再照合しなければならない。

第１図は、高度なプロダクション・システム10のブロッ
ク図である。プロダクション・システム10は、一連の規
則12を含み、規則のそれぞれには、左辺14と右辺16とが
ある。プロダクション・システム10には、プロダクショ
ン・システム10にとって“既知”の事実を含むワーキン
グ・メモリ18も含まれる。規則インタープリタ20（推論
エンジンとも呼ばれる）は、規則の左辺14とワーキング
・メモリ18とを照合し、右辺16を実行する。

規則インタープリタ20は、無限ループ（認知−動作サイ
クルという）で実行される。認知−動作サイクルを第２
図に示す。規則インタープリタは、最初に、規則のすべ
ての左辺とワーキング・メモリを照合する（22）。２つ
以上の規則によって照合がとられることがある。規則
は、それ自体の一連の関連事実に対するものであるが、
事実のいずれか一つを処理するために一度に発火できる
規則は一つだけである。規則インタープリタ20は、発火
される規則および事実を、競合の解消によって選択す
る。競合の解消を行う代表的なアルコリズムは、発火を
目的に、優先度の最も高い規則と最も新しい事実を選択
する。規則のいずれか一つが選択されると、対応する右
辺が実行される（26）。これにより、ワーキング・メモ
リが変更される。このサイクルが繰り返されて、規則の
左辺がすべて、更新されたワーキング・メモリ22と再び
符合することになる。

効率のよい規則プログラムを書く技術は、未だ完成の域
に達していない。効率のよい規則を作り上げるための一
般的な指針は、Thomas CooperとNancy Wogrinの「OPS5
を用いた規則ベース・プログラミング（Rule-Based Pro
gramming with OPS5）」（1988）とLee Brownston他の
「OPS5によるエキスパート・システムのプログラミング
（Programming Expert System in OPS5）」（1985）に
みられる。これらの出版物を除けば、プログラムの効率
化に関して、エキスパート・システムの設計者が利用で
きるような専門的な知識を提供しているものはない。

上に挙げた文献に述べられている指針は、エキスパート
・システムのプログラマが自身の経験に基づいて適用す
る目安である。このような目安は、規則インタープリタ
が対象とする方法の知識に基づいている。現在のプロダ
クション・システムの規則インタープリタは、効率を目
的に最適化されているので、一般には、規則のRHSが発
火されるとき、ワーキング・メモリの変更によって直に
影響を受けるLHSだけが、次の照合サイクルで照合され
る。この種の規則インタープリタは、Reteアルゴリズム
を用いることによって照合に制限を加える。このアルゴ
リズムでは、照合の結果を格納するために、多数のデー
タ構造が生成されるので、ワーキング・メモリ内の関連
する要素が変更されていなければ、再照合の必要はな
い。ワーキング・メモリ内の要素が変更されれば、規則
インタープリタによってReteデータ構造が調べられ、ど
の規則のどの部分に影響が及ぶかが判定され、Reteデー
タ構造により、そのような規則だけで照合がとられる。

Reteアルゴリズムは、その性質上、規則の左辺のわずか
な部分によって、規則プログラムの効率がしばしば非常
に低下する。これは、規則と規則との、および規則とデ
ータとの相互作用による。その原因は、ワーキング・メ
モリ内の関連要素が多数、いろいろな組み合わせで相互
に取捨選択（スクリーニング）されたり比較されたりす
ることにある。スクリーニングは、要素内テストによっ
て、比較は、要素間テストによって行われる。テスト仕
様はパターンと呼ばれる。規則とワーキング・メモリの
構造化方法は、パターン・マッチングにかかる時間の長
短に大きく影響する。

エキスパート・システムのプログラマがプログラムの効
率を上げるのに用いる目安は、適用範囲が広く、いつも
簡単に適用できるとは限らない。このような指針の代表
例としては、多数のワーキング・メモリ要素に符合する
条件は避ける、条件のクロス乗積の大きいものは避け
る、符合した条件を頻繁に変更するのは避ける、個々の
条件要素の照合を高速にする、競合集合の大きさを制限
する、などがある。これらの問題の解決法としては、左
辺の条件を並べ替えることで、制限の大きい条件が最初
に現れ、変更頻度の高いワーキング・メモリ要素と符合
する条件が最後にくるようにする方法が代表的である。
現在、規則ベースのエキスパート・システムの効率を監
視し評価するのに適したツールがないため、エキスパー
ト・システムのプログラマは、どの部分で変更が起きる
かについて、推測や直観に頼ることが多くなる。

エキスパート・システムの効率は、データによって大き
く変化する。規則自体を調べるだけで規則プログラムの
効率が評価できるケースはほとんどない。規則が発火さ
れるとき、システムの現在状態、ワーキング・メモリの
データ量、および前の規則の発火履歴に応じて、他の多
くの規則が関係する。パターン・マッチングのときに必
要な処理を予測するのは容易ではない。このように、エ
キスパート・システムの分野では、効率的な規則を作る
ための普遍的な規則は存在しない。

規則プログラムのメリットは、データ処理の大半をLHS
に任せることにある。LHSはコンパクトで宣言的であ
る。いいかえれば、規則のLHSは、評価の機構を指定せ
ずにデータの性質を指定する。規則ベースのアプリケー
ションを書くのは、手続き型言語の手法に比べれば単純
であるが、プログラムが最適化されていないと、効率が
かなり低下することがある。したがって規則ベースのプ
ログラムを最適化あるいは調整するときのコストは、複
雑なアプリケーション用の規則プログラムを書いて得ら
れる生産性と釣り合いのとれたものでなければならな
い。調整コストを抑える効率的な調整機構が肝要であ
る。

そこで、規則プログラムの実行時に効率が最も低下する
原因となる規則の発見に役立つ、データ収集システムが
望まれる。また、かかるシステムは、アプリケーション
の効率を調べ、非効率の原因を突き止めるユーザを支援
するものが望ましい。

C.発明が解決しようとする課題 本発明の目的は、規則ベースのエキスパート・システム
のうち、プログラム実行時の非効率を判定する上で役立
つデータを提供する部分の監視システムを提供すること
にある。

本発明の目的には、アプリケーションの効率化に興味を
持つユーザが理解できるフォーマットで使用可能なデー
タを表現するシステムを提供することも含まれる。

本発明の目的には、エキスパート・システム・アプリケ
ーションのうち効率の低い部分を自動的に選択し、効率
に関係する変更をアプリケーションに加えるために、選
択された小数の候補をユーザに提案するシステムを提供
することも含まれる。

D.課題を解決するための手段 本発明による監視システムは、エキスパート・システム
・アプリケーションが実行されている間に、該アプリケ
ーションを監視する。監視システムは、エキスパート・
システムの動作効率に関連して選択された効率データを
記録し、このデータをデータベースに書き込んでおく。
監視システムは、エキスパート・システムの実行テスト
が終了した後、ユーザが修正の対象とする小数の候補規
則を選択し、候補規則にどのような変更が必要かを判定
するためのデータをユーザに表示する。

E.実施例 ここで述べる監視システムは、Reteの照合アルゴリズム
を用いる規則インタープリタ20との併用に適している。
本発明に適したプロダクション・システムとしては、Di
gital Equipment Corp.のうちOPS5、International Bus
iness MachinesのKnouledge Toolなどがある。

第３図は、エキスパート・システム・アプリケーション
の効率を調整する手続きを示す。最初にエキスパート・
システム・アプリケーションが実行され（30）、アプリ
ケーションの効率が監視される（32）。以下、これにつ
いて詳述する。アプリケーションの効率に興味を持つユ
ーザは、効率が満足のいくものかどうかを判定する（3
4）。満足のいくものであれば、手続きはここで終了す
る。そうでなければ、ステップ32で得られた効率データ
が分析され（36）、アプリケーション内の規則が変更さ
れる（38）。ステップ38で事実とデータの編成方法も変
更すれば、変更結果を、検査されたアプリケーションで
効率の上がる表現に変えることができる。変更されれ
ば、アプリケーションは再実行され、手続きが繰り返さ
れる。

第４図の監視プログラム（モニタ）40は、プロダクショ
ン・システム10の実行時に実行され、データベースに格
納するための各種のデータ（42ないし54）を生成する。
データは、後述するように検索され、プロダクション・
システム10の非効率を分析するときに用いられる。

実行中のプログラムの効率を実際に監視する方法は周知
のとおりである。監視対象の情報が決定されれば、この
ような方法に手を加えてモニタ40を形成することは容易
である。効率監視システムにおいては、データの選択
は、一般に、実際に監視を行うコンピュータ・コードを
書くことよりも、重要かつ創造的な仕事と考えられてい
る。

モニタ40が収集する第１のデータ・セット42はパターン
・マッチング時間である。この時間は、規則インタープ
リタ20が、RHSの発火後に起こる左辺の照合（22）と競
合の解消（24）のステップを実行する時間と定義するの
がよい。パターン・マッチング時間データ42は、各規則
について個々に累積する形で保存される。したがってエ
キスパート・システムの実行が終わる時点では、収集さ
れたデータ・セット42の内容は、規則の各RHSに関し、R
HSが発火されたときにワーキング・メモリに加えられた
変更の結果、パターン・マッチングと競合の解消にかか
った時間の合計である。

収集された第２のデータ・セット44の内容は、RHSの実
行によって起こったワーキング・メモリの動作の回数で
ある。この回数は、ワーキング・メモリ内の要素の各ク
ラスごとに格納し、かつサイクルごとに格納するのが望
ましい。ワーキング・メモリ要素の割り当て、削除、お
よび更新は、個別に表の形にまとめられる。したがって
実行テストが終了した時点では、収集されたデータ・セ
ット44の内容は、前に発火されたRHSによって影響を受
けた各クラスのエントリを、認知−動作サイクルごとに
示したものである。各エントリの内容は、そのサイクル
で当該クラスのメンバに対して実行された割り当て、削
除、および更新の合計回数を表にしたものである。

モニタ40によって収集される第３のデータ・セット46
は、規則のLHSに対する各条件テストの実行が論理的に
必要とされた回数である。RHSが発火された結果として
条件テストが実行されるごとに、当該規則のカウンタが
増分される。実行テストの終了時には、各条件テストの
カウンタは、条件テストが実行された回数を示す。

モニタ40は、成功した条件テスト48の回数も収集する。
各条件テストに第２のカウンタが設けられる。このカウ
ンタは、ある種の条件テストについては、そのテストが
成功したときにのみ増分される。

次にモニタ40によって収集されるデータ・セット50は、
パターンが符合した回数である。各パターンの記録は個
別に維持される。符合回数は、パターンを満足するワー
キング・メモリ要素の組み合わせの数であり、Reteデー
タ構造を走査することによって得られる。パターンにつ
いて生じた符合の最大数だけを保持するのが望ましい。
そこで、パターンを満足するワーキング・メモリ要素の
組み合わせの数は、パターンが照合されるごとに、Rete
データ構造から得られ、当該パターンの前の最大値と比
較される。保持されるのは大きい値だけである。

モニタ40によって次に収集されるデータ・セット52は、
規則のRHSの実行時間である。これは各規則について累
積された値なので、実行終了時には、規則の右辺の実行
に実際にかかった時間は、各規則に適用できる。

モニタ40によって最後に収集されるデータ・セット54
は、エキスパート・システムによって実行される認知−
動作サイクルのそれぞれのエントリである。各エントリ
の内容は、サイクルの照合時間の合計である。これは、
上述のように競合の解消時間を含むものが望ましい。競
合集合の大きさと、発火されてサイクルをスタートさせ
た規則のIDが各エントリに含まれる。競合集合の大きさ
は、発火が認められたすべての規則に関連するワーキン
グ・メモリ要素の組み合わせの数である。また、当該サ
イクルで実行された要素間条件テストと要素内条件テス
トの回数も含まれる。この情報は、実際に実行されたテ
ストを示すものであり、データ・セット46、48に収集さ
れた値は、各パターンについて論理的に必要とされたテ
スト回数を示す。実際のテスト回数は比較的少ない。こ
れは、異なる規則に共通の条件テストは、一度しか実行
されないが、その結果が共有されるためである。その違
いが共有の程度を示す。

モニタ40によって収集されたデータは、データベースに
書き込まれる。各データ・セットのIDは、データベース
に格納するが望ましい。データベース内の格納フォーマ
ットは重要ではない。収集された情報は、扱いやすさを
考えて、第５図とあわせて説明するレポートと同じフォ
ーマットのテキスト・ファイルに格納することができ
る。

第５図のアナライザはユーザ・インタフェース62に接続
される。アナライザ60は、汎用コンピュータ・システム
上で実行され、第４図とあわせて説明したように、モニ
タ40によって作成されたデータベースをアクセスするプ
ログラムが望ましい。アナライザ60は、データベースか
らデータを抽出し、これを数種のレポート（64ないし7
4）の形でユーザ・インタフェース62に引き渡す。

レポート64は、各規則の右辺76に対してエントリを一つ
含む。エントリは、RHSが発火された回数78、およびRHS
に対する規則の発火後のパターン・マッチングにかかっ
たCPU時間80とRHSを実際に実行するのにかかったCPU時
間82の割合を含む。また、規則の発火に影響を受けたク
ラスの全メンバに関するアクティビティ数84も含まれ
る。アクティビティ数は、割り当て、解放、および更新
が起こったクラス・メンバの個数について個別に表にさ
れる。回数（78ないし84）はすべて、監視の全時間にわ
たって累積される。

レポート66は、照合番号86（認知−動作サイクル番号）
とクラス名88の両方で分類されたクラス・メンバ・アク
ティビティを示す。いいかえれば、認知と動作の各サイ
クルについて、レポート66には個別のエントリがあり、
このエントリが、サイクルの番号と、少なくとも一つの
メンバに変更のあったクラスの番号を示す。そこで、た
とえば、一回のRHSの発火によって３種類のクラスのメ
ンバが変更された場合、レポート66には、そのサイクル
について３つのエントリが含まれる。各エントリの内容
は、当該クラスのサイクルで割り当て（90）、解放（9
2）、および更新（94）が起こったワーキング・メモリ
要素の数である。

レポート68は、複数のエントリを含み、エントリはそれ
ぞれ照合すなわちサイクルの番号96、発火されてサイク
ルをスタートさせたRHSのID98、および最も新しい発火
の結果として再照合が必要になった規則の左辺のID100
を含む。影響を受けるHLS100は、各エントリに一つ含ま
れているのが望ましい。その場合、一回のRHSの発火に
よって５つの規則を再照合しなければならないときは、
レポート68には５つのエントリが含まれ、それぞれの照
合番号96と発火されたRHSは同一となる。

レポート70は、各サイクルについて一つのエントリを含
む。各エントリの内容は、サイクルの照合番号102、照
合と競合の解消にかかるCPU時間104、および競合集合の
大きさ106である。また実行された要素間テスト108と要
素内テスト110の回数も含まれる。さらに、サイクルが
スタートする直前に発火されたRHSも含まれる（112）。

レポート72は、エキスパート・システムの各規則に対し
て１エントリを含み、これは規則のLHS114によって識別
される。各エントリの内容は、規則の左辺に含まれたパ
ターンのそれぞれに対応するサブエントリである。第５
図には２つのパターン・サブエントリ116、118を示した
が、規則の各LHS114に対するパターン・サブエントリの
正確な個数は、各規則に含まれるパターン数によって決
まる。

各サブエントリの内容は、規則のLHSの照合に必要な要
素間条件テストの回数120と、成功した該テストの回数1
22である。また、必要になった要素内条件テストの回数
124と成功した該テストの回数126も含まれる。各パター
ンに対応するクラス各128も該当するサブエントリに含
まれる。

レポート74も、各規則の左辺に対するエントリを一つ含
む。各エントリは、規則のLHS130を識別し、レポート72
と同様に、規則内の各パターンに対するサブエントリを
含む。第５図では、第１のパターン・サブエントリ132
と第２のパターン・サブエントリ134しか示していない
が、その個数は上述のように変化する。各サブエントリ
の内容は、パターンに対して存在していた要素間符合の
最大回数138と要素内符合の最大回数138である。これら
は、第４図の収集されたデータ・セット50で得られる値
である。各サブエントリには、クラスのメンバ数140と
クラス名142も含まれる。

ここから明らかなように、レポート64ないし74は、モニ
タ40によって収集されたデータ・セット42ないし54から
直に生成される。たとえばレポート70は、データ・セッ
ト54をリストの形にしただけのものである。規則74は、
データ・セット50から導かれる。他のレポートも同様
に、データ・セット42ないし54から導かれる。

アナライザ60によって生成される各種のレポート64ない
し74は、第６図に示した原因／結果の連鎖が表す原理に
従って定義され表示される。第６図は、規則12、ワーキ
ング・メモリ18、および規則インタープリタ20の相互作
用のうち、非効率の原因となる部分の関係を表す。第５
図のレポートに示される収集されたデータの選択とレイ
アウトは、このような関係の性質を強調して記述するよ
うに行うのが望ましい。

第６図は、認知と動作の各サイクルで生じるイベントの
相互関係を示す。規則の右辺が発火されると（150）、
クラス・メンバの一部が変更される（152）。クラス・
メンバの一部が変更されると（152）、ある規則の左辺
が影響を受ける（154）。Reteアルゴリズムに詳しい当
業者には明らかなように、再照合されるのは、変更され
たクラス・メンバ152によって左辺が影響を受けた規則
だけである。

影響を受けた規則154の再照合により、これらの規則内
の条件テストが再評価される（156）。これにより、パ
ターンの照合がいくつかとられることがある（158）。
影響を受けた規則内のパターンが満足されると、それら
の規則および符合したワーキング・メモリ要素が競合集
合に追加されるか、または競合集合から除外される（16
0）。エキスパート・システム・プログラムが実行され
ている間、テスト条件と照合パターンによってこうして
形成された競合集合160にCPU時間がかかる。

エキスパート・システム・アプリケーションの実行を、
第６図に示した概念に従って分析することは、つまり、
規則の右辺が発火されたときに、次の照合サイクルで規
則インタープリタ20がCPU時間を過度に消費する原因と
なった規則に注意を向けることによって、効率の向上を
図ることである。発火されて、このように時間のかかる
照合をもたらす規則は、被告規則と呼ぶことができる。

ボックス154は、被告規則の発火により、ある規則のLHS
を再照合しなければならないことを示す。このような規
則の照合が、実際にかなりのCPU時間を消費する。した
がって、これらの規則は容疑規則と呼ぶことができ、効
率情報の分析はこれらに焦点をあてて行う必要がある。

次に第７図はアナライザ60の動作を示す。アナライザ60
の動作がスタートするとき、最初のステップは、被告規
則170を選択することである。必要なら、数個の被告規
則を選択して、同時に追跡できるが、第７図では、一度
に選択される被告規則は一つだけとしている。

被告規則の選択（170）は、レポート64の情報に基づい
て行われる。被告規則は、照合にかかったCPU時間80が
最も長くなった規則とするのがよい。

次のステップは、被告規則の発火によって、どのクラス
が変更されたかを判定することである（172）。アナラ
イザ60は、レポート70から、被告規則が、どの認知−動
作サイクル（または照合番号）で発火されたかを判定で
きる。この照合番号のリストは、レポート66から、対応
する照合番号を持つエントリだけを選択するのに用いら
れる。これにより、レポート66のエントリからレポート
が選択され、このレポートから、被告規則の発火によっ
て変更されたクラスだけのクラス名88が得られる。

ユーザは、ステップ172の選択結果を調べれば、容疑規
則の選択に移ることができる（174）。容疑規則は、被
告規則の発火によって左辺が影響を受けた規則である。
この情報は、レポート68から、発火されたRHSの情報98
が被告規則に符合するエントリだけを抽出することによ
って得られる。容疑規則の名前は、ユーザ向けの他のレ
ポートのフィルタとして用いられる（176ないし182）。
容疑規則のリストは、各種のレポートから、容疑規則に
対応するエントリだけを選択するために用いられる。

容疑規則が選択されると、数種のレポート176ないし182
がユーザに提示される。ユーザはこれらを基に、実行の
非効率の原因を突き止めることができる。レポートの提
示順序は任意でよいが、ユーザが希望する順序を選択す
るのが望ましい。普通、何か問題がある場合、有益な情
報を提供するレポートを、そうでないレポートがある。

ユーザは、推論サイクルのアクティビティ・レポート17
6を受け取る。このレポートには、容疑規則を含む推論
サイクルだけが含まれる。これはレポート70から得られ
る。ユーザはまた、容疑規則に関するパターン別のテス
トと符合のレポート178も受け取る。これはレポート72
から得られ、容疑規則のそれぞれのパターンがすべて提
示される。容疑規則に関するパターン別の符合レポート
180は、レポート74から抽出される。サイクルごとの競
合集合の大きさもレポートされる（182）。これはレポ
ート70のエントリから抽出される。

多くの場合、ユーザは、自身の知識と経験を基に、いま
説明したレポートのすべてを見る必要はないと判断す
る。プロセスの始めの方で何らかの例外が明らかになる
ことがあり、ユーザは、これをチェックせずに修正する
ことがある。たとえばステップ174で多くのLHSが影響を
受けることが分かった場合、ユーザは、クラス・メンバ
を変更するか、または類似の規則をいくつか組み合わせ
て一つの規則とし、組み合わせられた規則の右辺で相違
を解消することがある。このとき変更があれば、ユーザ
はアナライザ60を終了して、エキスパート・システム上
で別の実行テストを行うことになる。

上述のレポートがチェックされて、エキスパート・シス
テムに加えられる変更の種類は、当業者には明らかであ
り、ここでは詳述しない。以下、各レポートの使用例に
ついて簡単に説明する。

ステップ176で得られる推論サイクル・アクティビティ
・レポートは、競合集合が大きいために生じる問題の診
断、あるいは規則発火の例外を突き止めるのに使用でき
る。このような診断や確認は、基準から大きくずれた照
合サイクルを捜し出すことによって行われる。ステップ
178で得られるレポートは、LHSの符合回数と手続き型の
検索とのトエードオフを評価したり、LHSの中のパター
ンを並べ替えて余分な要素間テストを減らす必要のある
ことを指示したりするのに使用できる。ステップ180の
レポートは、クロス乗積の効果の大きさを診断したり、
動的記憶の急増が起こり得ることに注意を促したりする
のに使用できる。

後ろ向きの線186、188は、ユーザが、必要に応じて、ア
ナライザ60の手続きを逆にたどって、追加規則の効率に
関するデータを調べることも可能なことを示す。たとえ
ば、ユーザは、必要であれば、ステップ172からステッ
プ170へ戻ることができる。これは、被告規則を新たに
選択することに相当し、その場合、被告規則は、元の被
告規則によって変更されたものと同じクラスにも変更を
加える原因となった規則である。

同様に、ステップ174からステップ172へ戻れば、変更さ
れたクラスを新たに生成できる。これは、元の一連の容
疑規則および元の容疑規則によって実際に変更された規
則に変更を加える原因となったクラスをすべて選択する
ことに相当する。新しい容疑規則がここで選択され、こ
れには、このように拡大されたクラスの集合によってま
た変更が加えられた全容疑規則が含まれる。次に、ステ
ップ176ないし182で作成される各レポートで、このよう
に拡大された一連の容疑規則に対応するエントリがすべ
て選択される。

当業者には明らかなように、上述のシステムは、規則ベ
ースのエキスパート・システムが実行されている間に該
当データを抽出し、システムの効率を高めるために変更
すべき規則やデータを突き止める際に、ユーザのデータ
分析を支援する監視機構を提供するものである。この機
構は、第３図とあわせて説明した効率データの分析（3
6）の効率を大幅に高め、エキスパート・システムの実
行効率を高めるのに必要な時間を大幅に短縮する。

本発明は、特に実施例に照らして説明したが、当業者に
は明らかなように、形式と詳細については、本発明の精
神と適用範囲から逸脱することなく様々な変更が可能で
ある。

【図面の簡単な説明】

第１図は、プロダクション・システムのブロック図であ
る。 第２図は、認知−動作サイクルを示す流れ図である。 第３図は、エキスパート・システムに適用される調整プ
ロセスを示す流れ図である。 第４図は、エキスパート・システム・プログラムの実行
時にデータが収集される様子を示す、監視システムのブ
ロック図である。 第５図は、収集されたデータがアナライザによって用い
られる様子を示すブロック図である。 第６図は、実行中のエキスパート・システムの各部の原
因と結果の関係を示す図である。 第７図は、第５図のアナライザの動作を示す流れ図であ
る。

Claims (4)

【特許請求の範囲】
1. 【請求項１】それぞれが右辺と左辺とを含む複数の規則
   と、複数の要素を含むワーキング・メモリとを有する規
   則ベースのアプリケーションの効率を実行時に監視する
   システムにおいて、 規則の右辺の実行に要する照合時間を累積する第１の累
   積手段と、 上記ワーキング・メモリ内の要素の各クラスに対して実
   行されたワーキング・メモリの動作を計数する第１の計
   数手段と、 条件テストの実行回数を計数する一方で、該条件テスト
   の成功回数を計数する第２の計数手段と、 パターンが照合されるごとに該パターンを満足する上記
   ワーキング・メモリ要素の組み合わせの数を計数する第
   ３の計数手段と、 規則の右辺の実行時間を累積する第２の累積手段と、 上記累積手段と上記計数手段によって該アプリケーショ
   ンの実行時に得られた情報をデータベースに格納する手
   段と、 上記データベースをアクセスして、右辺の実行により、
   照合サイクルの時間が相対的に長くなる被告規則を判定
   する手段と、 上記被告規則の右辺が実行されることによって影響を受
   けたワーキング・メモリのクラスを選択する第１の選択
   手段と、 選択されたクラスの変更によって左辺が影響を受ける規
   則を容疑規則として選択する第２の選択手段と、 上記容疑規則に関係するデータベースから抽出された情
   報を表示する手段を含む、 規則ベース・システム管理装置。
2. 【請求項２】規則ベースのエキスパート・システムの非
   効率の原因に関する情報を提供する装置であって、 上記エキスパート・システムの動作時に生成された規則
   に関する効率データを格納する記憶手段と、 上記記憶手段をアクセスして得られた上記効率データを
   処理して、右辺の実行の結果として照合サイクルに費や
   される時間が相対的に長い被告規則を判定し、該被告規
   則の右辺の実行によって影響を受けたワーキング・メモ
   リのクラスを選択した後、該クラスの変更によって左辺
   が影響を受けた規則を容疑規則として選択する手段と、 上記容疑規則の効率データを表示する手段とを含む、 規則ベース・システム管理装置。
3. 【請求項３】規則ベースのアプリケーションの効率を実
   行時に監視する方法であって、 規則の右辺の実行に要する照合時間を累積するステップ
   と、 上記ワーキング・メモリ内の要素の各クラスに対して実
   行された該ワーキング・メモリの動作を計数するステッ
   プと、 規則の右辺における条件テストの実行回数を計数する一
   方で、該条件テストの成功回数を計数するステップと、 パターンが照合されるときに該パターンを満足する上記
   ワーキング・メモリ要素を計数するステップと、 規則の右辺の実行時間を累積するステップと、 上記の累積ステップと計数ステップとから得られた情報
   をデータベースに格納するステップと、 上記データベースをアクセスするステップと、 アクセスされた上記効率データを処理して、右辺の実行
   の結果として照合サイクルにおいて費やされる時間が相
   対的に長い被告規則を判定するステップと、 上記被告規則の右辺の実行によって影響を受けたワーキ
   ング・メモリのクラスを選択するステップと、 選択されたクラスの変更によって左辺が影響を受けた規
   則を容疑規則として選択するステップと、 上記容疑規則の効率データを表示するステップとを含
   む、 規則ベース・システム管理方法。
4. 【請求項４】規則ベースのエキスパート・システムの非
   効率の原因に関する情報を提供する方法であって、 上記エキスパート・システムの動作時に生成された効率
   データをアクセスするステップと、 アクセスされた上記効率データを処理して、右辺の実行
   の結果として照合サイクルに費やされる時間が相対的に
   長い被告規則を判定するステップと、 上記被告規則の右辺の実行によって影響を受けたワーキ
   ング・メモリのクラスを選択するステップと、 選択されたクラスの変更によって左辺が影響を受けた規
   則を容疑規則として選択するステップと、 上記容疑規則の効率データを表示するステップとを含
   む、 規則ベース・システム管理方法。