10

私が取り組んでいるアプリケーションは、一種の「コンフィギュレーター」です。これは C# で書かれており、それに合わせてルール エンジンも作成しました。アイデアは、命題論理ステートメントがたくさんあり、ユーザーが選択できるということです。選択した内容に基づいて、他の項目が必須になるか、完全に利用できなくなります。

命題論理ステートメントは、一般に次の形式を取ります。

A => ~X 
ABC => ~(X+Y) 
A+B => Q 
A(~(B+C)) => ~Q A <=> B

シンボル:

=>  -- Implication
<=> -- Material Equivalence
~   -- Not
+   -- Or
Two letters side-by-side -- And

私は Prolog に非常に慣れていませんが、すべての「ルール処理」を処理できるようで、現在のルール エンジンから抜け出すことができるようです (動作しますが、それほど速くも簡単でもありません)。私が望むように維持します）。

さらに、使用可能なオプションはすべて階層化されています。例えば：

Outside
   Color
      Red
      Blue
      Green
   Material
      Wood
      Metal

第 2 レベルの項目 (色などの機能) が暗示されている場合は、第 3 レベルの項目 (赤などのオプション) を選択する必要があります。同様に、機能が false であることがわかっている場合、その下にあるすべてのオプションも false です。

問題は、すべての製品に独自のルールがあることです。これらの演算子を述語として含むナレッジ ベースを設定し、実行時に製品のすべてのルールの構築を開始することは合理的なアプローチですか?

私が想像する方法は、コンポーネント、機能、およびオプションのアイデアを設定することです。次に、それらの間の関係を設定します (たとえば、機能が false の場合、そのオプションはすべて false になります)。実行時に、製品固有のルールを追加します。次に、ユーザーのすべての選択を関数に渡し、どの項目が true でどの項目が false であるかを出力として取得します。

私は Prolog を始めたばかりなので、私が尋ねていることの意味をすべて知っているわけではありませんが、悪い道をたどり、その過程で多くの時間を無駄にしないようにしています.

私が見つけようとしているものをターゲットにするのに役立つかもしれないいくつかの質問：

  1. これは実行可能ですか？
  2. 私は間違った木を吠えていますか？
  3. 実行時にこれらすべてのルールを作成しようとすると、欠点や懸念事項はありますか?
  4. C# アプリ (正確には Silverlight) に詰め込むことができる、この種のより良いシステムはありますか?
  5. 他に検討すべき競合システムはありますか?
  6. この種のことについて何か一般的なアドバイスはありますか?

アドバイスありがとうございます！

4

2 に答える 2

9
  1. 確かに、しかし Prolog には学習曲線があります。
  2. 多くのルールをHorn 句に書き直す必要があるかもしれませんが、ルールベースの推論は Prolog のゲームです。A+B => Q実行可能です（q :- a. q :- b.またはになりq :- (a;b).ます）が、 を含む他の例を書き直す必要がありますA => ~X。
  3. Prolog コンパイラ、特に動的述語のインデックス作成をサポートするかどうかによって異なります。
  4. 「フォワード チェック」、「推論エンジン」、「ビジネス ルール」などの用語を検索してください。さまざまなコミュニティが、この問題に対してさまざまな用語を発明し続けています。
  5. Constraint Handling Rules (CHR)は、Prolog 拡張機能として実装されたロジック プログラミング言語であり、ルールベースの推論/フォワード チェーン/ビジネス ルール エンジンに非常に近いものです。ただし、使いたい場合は、基本的な Prolog を学習する必要があります。
  6. Prolog はプログラミング言語であり、論理的推論の特効薬ではないことに注意してください。物事を効率的に計算できるようにするために、一次論理のいくつかのコーナーをカットします。これが、ホーン句のみを処理する理由です。ホーン句は、プロシージャ/サブルーチンと 1 対 1 でマップできます。
于 2011-07-21T13:40:29.113 に答える
4

DCG を投入して部品表を生成することもできます。大まかに言うと、ターミナルを使用してサブプロダクトを示し、非ターミナルを使用して、最終的な構成可能な製品に到達するまで、サブプロダクトのますます複雑な組み合わせを定義できます。

たとえば、{red, blue, green} の Color と {wood, metal} の Material の 2 つの属性値のペアを考えてみましょう。これらはドアノブを指定する可能性があり、すべての組み合わせが可能なわけではありません:

knob(red,wood)   --> ['100101'].
knob(red,metal)  --> ['100102'].
knob(blue,metal) --> ['100202'].

次に、ドアを次のように定義できます。

door ... --> knob ..., panel ...

興味深いことに、このような製品仕様には論理式は見られず、事実とルールだけが見られ、多くのパラメーターが渡されます。パラメータはナレッジ取得コンポーネントで使用できます。インスタンス化されていない目標を実行するだけで、属性値ペアの可能な値を導き出すことができます。述語 setof/3 は、重複をソートして削除します。

?- setof(Color,Material^Bill^knob(Color,Material,Bill,[]),Values).
Value = [blue, red] 
?- setof(Material,Color^Bill^knob(Color,Material,Bill,[]),Values).
Material = [metal, wood]

属性の範囲がわかったので、エンドユーザーに属性と値を連続して選択させることができます。彼が属性 Color とその値 blue を取得したとします。それに応じて、アトリビュート Material の範囲が縮小します。

?- setof(Material,Bill^knob(blue,Material,Bill,[]),Values).
Material = [metal]

最終的にすべての属性が指定されると、サブプロダクトの商品番号を読み取ることができます。これを価格計算に使用したり、商品番号に関する追加情報を提供するいくつかの事実を追加したり、注文リストなどを生成したりできます..:

?- knob(blue,metal,Bill,[]).
Bill = ['100202']

よろしくお願いします

PS: 製品コンフィギュレーターで使用されている部品表のアイデアは、Clocksin & Mellish に遡るようです。少なくとも、ここに対応するコメントがあります: http://www.amzi.com/manuals/amzi/pro/ref_dcg.htm#DCGBillMaterials

于 2011-07-21T22:10:27.133 に答える