Rule-based আর expert system — forward ও backward chaining

আগের দুটি পর্বে যুক্তির ভাষা তৈরি হয়েছে: পর্ব ৪৫-এ propositional logic আর Horn clause (A ∧ B → C, মানে “A এবং B হলে C”; ∧ চিহ্নের অর্থ “এবং”, → চিহ্নের অর্থ “হলে”), আর পর্ব ৪৬-এ first-order logic আর unification. এই পর্বে সেই ভাষাকে একটি কাজের যন্ত্রে পরিণত করা হবে: এমন একটি প্রোগ্রাম, যা বাজারঘরের (এই কোর্সের কাল্পনিক অনলাইন দোকান) ফেরত-নীতি জানে, একজন ক্রেতার তথ্য দেখে সিদ্ধান্ত দেয়, আর জিজ্ঞেস করলে বলে কেন। এমন প্রোগ্রামকেই বলা হয় expert system. এর ইতিহাস সংক্ষেপে পর্ব ২-এ আর নিয়মভিত্তিক পথের পরিচয় পর্ব ৩-এ আছে।

১ · Production rule আর একটি expert system-এর গঠন

একটি production rule-এর দুটি অংশ: বাঁ দিকে শর্ত (condition, একে antecedent বা LHS-ও বলে), ডান দিকে কাজ বা সিদ্ধান্ত (action বা conclusion, RHS). বাজারঘরের একটি নিয়ম:

IF পণ্যটি খাবার AND প্যাকেট খোলা THEN পণ্যটি স্বাস্থ্যবিধির কারণে ফেরতযোগ্য নয়

কোডে আমরা লিখব R1: cat=food & opened -> hygiene_item. এখানে & মানে “এবং”। শর্তে শুধু “এবং” থাকে আর ডানে একটি সিদ্ধান্ত, তাই প্রতিটি নিয়ম আসলে একটি Horn clause. “অথবা” লাগলে দুটি আলাদা নিয়ম লেখা হয় (যেমন R1 খাবারের জন্য, R2 প্রসাধনীর জন্য)। পর্ব ১-এর reflex agent-এর condition–action rule-ও একই ছাঁচের, তবে সেখানে একবার মিলিয়ে কাজ হতো; এখানে এক নিয়মের সিদ্ধান্ত পরের নিয়মের শর্ত হয়ে শিকল তৈরি করে।

পাঁচটি অংশ

এই আলাদা রাখার একটি বড় সুবিধা আছে। সাধারণ প্রোগ্রামে নীতি ছড়িয়ে থাকে if-else-এর ভেতরে, আর নীতি বদলাতে প্রোগ্রামারকে খুঁজে খুঁজে কোড বদলাতে হয়। Rule-based system-এ নীতিটি এক জায়গায়, পড়ার মতো আকারে। নীতির মালিক (যেমন বাজারঘরের কাস্টমার-সার্ভিস প্রধান) নিয়মগুলো পড়ে বলতে পারেন কোনটি ভুল। তবে এর মানে এই নয় যে নিয়ম লেখা সহজ; অংশ ৮-এ দেখবেন কেন এটিই সবচেয়ে কঠিন কাজ।

২ · বাজারঘরের ফেরত-নীতি — ২০টি নিয়মের একটি expert system

নিচের নীতিটি এই কোর্সের জন্য বানানো; কোনো বাস্তব প্রতিষ্ঠানের নীতি নয়। ইনপুট পাঁচটি: পণ্যের ধরন (cat: food, cosmetics, electronics, clothing, book), ডেলিভারির পর কত দিন (days), প্যাকেট খোলা না সিল করা (opened বা sealed), ক্রেতা ক্ষতি জানিয়েছেন কি না (damage), আর টাকা কীভাবে দেওয়া (pay: cod মানে ক্যাশ অন ডেলিভারি, wallet মানে মোবাইল ওয়ালেট, card).

পুরো rule base, ঠিক যেভাবে নিচের কোড ব্লকগুলো পড়ে (ফাইলের নাম rules.txt):

# Bazarghar return policy (invented for this course)
R1: cat=food & opened -> hygiene_item
R2: cat=cosmetics & opened -> hygiene_item
R3: damage & days<=7 -> defect_claim
R4: cat=electronics & days<=7 -> in_window
R5: cat=clothing & days<=14 -> in_window
R6: cat=book & days<=10 -> in_window
R7: cat=cosmetics & days<=3 -> in_window
R8: in_window & sealed -> return_ok
R9: in_window & opened & cat=clothing -> return_ok
R10: defect_claim -> return_ok
R11: in_window & opened & cat=electronics -> exchange_only
R12: return_ok -> refund_allowed
R13: refund_allowed & pay=card -> refund_to_card
R14: refund_allowed & pay=cod -> refund_to_wallet
R15: refund_allowed & pay=wallet -> refund_to_wallet
R16: hygiene_item -> decision=reject
R17: exchange_only -> decision=exchange
R18: refund_allowed & defect_claim -> decision=full_refund
R19: refund_allowed & sealed -> decision=full_refund
R20: refund_allowed -> decision=refund_minus_fee

তিনটি জিনিস লক্ষ করুন। এক, days<=7 কোনো fact নয়, একটি পরীক্ষা: engine ইনপুটের দিনের সংখ্যা দেখে সত্য-মিথ্যা বলে। দুই, R18 আর R20 দুটিই refund_allowed হলে খাটে; একটি বেশি নির্দিষ্ট (ত্রুটি থাকলে পুরো টাকা), অন্যটি সাধারণ। তিন, R16 (স্বাস্থ্যবিধির পণ্য = বাতিল) আর R18 (ত্রুটি = পুরো টাকা) একই ক্রেতার ক্ষেত্রে একসঙ্গে খাটতে পারে: পচা খাবার পাঠানো হলে কোনটি জিতবে? এই প্রশ্নটি অংশ ৫ আর ৭-এর মূল বিষয়।

৩ · Forward chaining — match, select, act

Forward chaining তথ্য থেকে শুরু করে (data-driven): জানা fact দিয়ে কোন কোন নিয়মের সব শর্ত মেলে তা দেখে, একটি বেছে চালায়, নতুন fact যোগ করে, আবার দেখে। এই তিন ধাপের চক্রটিকে বলে recognize–act cycle:

1. Match: যেসব নিয়মের সব শর্ত এখন সত্য আর যেগুলো আগে চলেনি, তাদের তালিকা বানানো। এই তালিকাকে বলে conflict set.
2. Select: conflict set থেকে একটি নিয়ম বাছাই। আপাতত সবচেয়ে সরল নিয়ম: তালিকায় যেটি আগে (rule order).
3. Act: নিয়মটির সিদ্ধান্ত working memory-তে যোগ। নিয়মটিকে “চলেছে” চিহ্ন দেওয়া, যাতে আবার না চলে; একে বলে refraction.

কখন থামবে? যখন conflict set খালি, মানে নতুন কিছু বের করার নেই; একে বলে quiescence. আমাদের নিয়মে নতুন fact শুধু যোগ হয়, মোছে না, আর মোট সম্ভাব্য fact সীমিত; তাই চক্র সর্বোচ্চ ২০ বার চলে, তারপর থামতেই হবে। নিয়ম যদি fact মুছতে বা বদলাতে পারত, তবে চিরকাল ঘোরার ঝুঁকি থাকত।

নিচের stepper প্রথম ক্রেতার ঘটনা হাতে trace করে: একটি সিল করা ইলেকট্রনিকস পণ্য, ডেলিভারির ৫ দিন পর, ক্যাশ অন ডেলিভারিতে কেনা।

1cs = matching rules2if not cs: stop3r = cs[0]   # rule order4wm.add(r.then)

এবার একই কাজ কোডে। নিচের ব্লক rules.txt পড়ে নিয়মগুলো বানায়, তারপর তিনজন ক্রেতার জন্য forward chaining চালিয়ে প্রতিটি চক্রের conflict set আর বাছাই ছাপায়। শুধু Python-এর মৌলিক অংশ; প্রথমবার চালালে ব্রাউজারে Python নামতে কয়েক সেকেন্ড লাগতে পারে। এই পর্বের চারটি ব্লক একই namespace ভাগ করে (data-shared), তাই পরের ব্লকগুলো এখানের RULES, holds আর forward সরাসরি ব্যবহার করে।

RULES = []                                     # (name, [conditions], conclusion)
for line in open("rules.txt", encoding="utf-8"):
    if "->" in line:
        name, body = line.split(":", 1)
        lhs, rhs = body.split("->")
        RULES.append((name.strip(), [c.strip() for c in lhs.split("&")], rhs.strip()))
def holds(c, wm):                              # one condition against working memory
    if c.startswith("days<="):
        return wm["days"] <= int(c[6:])
    return c in wm
def forward(case, pick=lambda cs, wm: cs[0], show=True):
    wm = {f: 0 for f in case.split()}          # fact -> cycle it was added
    wm["days"] = int(case.split("days=")[1].split()[0])
    fired, cycle = [], 0
    while True:
        decided = any(f.startswith("decision=") for f in wm)
        cs = [r for r in RULES if r[0] not in fired and r[2] not in wm      # match
              and not (decided and r[2].startswith("decision="))
              and all(holds(c, wm) for c in r[1])]
        if not cs:
            break                              # quiescence: nothing left to fire
        cycle += 1
        r = pick(cs, wm)                         # select (conflict resolution)
        wm[r[2]] = cycle                       # act: add the conclusion
        fired.append(r[0])                     # refraction: never fire twice
        if show:
            print(f"  {cycle}: {{{' '.join(x[0] for x in cs)}}} -> {r[0]}: {r[2]}")
    return wm, fired
for case in ["cat=electronics sealed pay=cod days=5",
             "cat=clothing opened pay=wallet days=12",
             "cat=book opened damage pay=card days=20"]:
    print(case)
    wm, fired = forward(case)
    print("  =>", [f for f in wm if f.startswith("decision")] or "manual review")

cat=electronics sealed pay=cod days=5
  1: {R4} -> R4: in_window
  2: {R8} -> R8: return_ok
  3: {R12} -> R12: refund_allowed
  4: {R14 R19 R20} -> R14: refund_to_wallet
  5: {R19 R20} -> R19: decision=full_refund
  => ['decision=full_refund']
cat=clothing opened pay=wallet days=12
  1: {R5} -> R5: in_window
  2: {R9} -> R9: return_ok
  3: {R12} -> R12: refund_allowed
  4: {R15 R20} -> R15: refund_to_wallet
  5: {R20} -> R20: decision=refund_minus_fee
  => ['decision=refund_minus_fee']
cat=book opened damage pay=card days=20
  => manual review

৪ · Backward chaining — লক্ষ্য থেকে উপ-লক্ষ্য

এবার প্রশ্নটি উল্টো দিক থেকে। কাস্টমার-সার্ভিস কর্মী জানতে চান শুধু একটি কথা: “এই ক্রেতা কি টাকা ফেরত পাবেন?” মানে লক্ষ্য refund_allowed. Backward chaining (goal-driven) লক্ষ্য থেকে শুরু করে:

1. লক্ষ্যটি যদি সরাসরি জানা fact বা ইনপুটের পরীক্ষা হয়, দেখে নিন (বা ক্রেতাকে জিজ্ঞেস করুন)।
2. নইলে যেসব নিয়মের ডানে এই লক্ষ্য, সেগুলো একে একে নিন। একটি নিয়মের প্রতিটি শর্তকে নতুন উপ-লক্ষ্য বানিয়ে একই পদ্ধতিতে প্রমাণ করুন।
3. কোনো শর্ত ব্যর্থ হলে সেই নিয়ম বাদ, পরের নিয়ম চেষ্টা (backtracking). সব নিয়ম ব্যর্থ হলে লক্ষ্য ব্যর্থ।

এটি আসলে একটি depth-first search: লক্ষ্যের গাছে একটি শাখা ধরে গভীরে যাওয়া, আটকে গেলে ফিরে আসা। গাছটিকে বলে AND-OR tree: একটি নিয়মের সব শর্ত লাগবে (AND), কিন্তু লক্ষ্যের জন্য যেকোনো একটি নিয়ম যথেষ্ট (OR). পর্ব ৪৬-এর Prolog ভাষা ঠিক এভাবে, নিয়মের ক্রমে, বাঁ থেকে ডানে চলে।

1prove(goal): rules for goal2  condition = sub-goal3  base fact? look up / ask4  fails: try next rule5all proved: goal proved

কোডে prove function নিজেকেই ডাকে (recursion). প্রতিটি base fact দেখার সময় এটি ছাপায় কেন প্রশ্নটি করা হলো: কোন নিয়মের জন্য, সেটি আবার কোন নিয়মের জন্য। এটিই expert system-এর বিখ্যাত “why” উত্তর, আর পুরো ছাপানো গাছটি “how” উত্তর, মানে proof tree.

def prove(goal, wm, why=(), depth=0, memo=None):
    memo = {} if memo is None else memo
    pad = "   " * depth
    if goal in memo:                           # already proved or refuted
        print(f"{pad}{goal}: {'yes' if memo[goal] else 'no'} (remembered)")
        return memo[goal]
    rules = [r for r in RULES if r[2] == goal]
    if not rules:                              # a base fact: look it up (or ask)
        ok = holds(goal, wm)
        print(f"{pad}{goal}? {'yes' if ok else 'no'}  [why: {' > '.join(why[::-1])}]")
        return ok
    for name, conds, _ in rules:               # try each rule that concludes goal
        print(f"{pad}{goal} <= {name}: {' & '.join(conds)}")
        if all(prove(c, wm, why + (name,), depth + 1, memo) for c in conds):
            print(f"{pad}{goal}: PROVED by {name}")
            memo[goal] = True
            return True
    print(f"{pad}{goal}: FAILED (no rule works)")
    memo[goal] = False
    return False

case = "cat=electronics opened damage pay=card days=4"
wm = {f: 0 for f in case.split()}
wm["days"] = 4
print("goal: refund_allowed |", case)
print("answer:", prove("refund_allowed", wm))

goal: refund_allowed | cat=electronics opened damage pay=card days=4
refund_allowed <= R12: return_ok
   return_ok <= R8: in_window & sealed
      in_window <= R4: cat=electronics & days<=7
         cat=electronics? yes  [why: R4 > R8 > R12]
         days<=7? yes  [why: R4 > R8 > R12]
      in_window: PROVED by R4
      sealed? no  [why: R8 > R12]
   return_ok <= R9: in_window & opened & cat=clothing
      in_window: yes (remembered)
      opened? yes  [why: R9 > R12]
      cat=clothing? no  [why: R9 > R12]
   return_ok <= R10: defect_claim
      defect_claim <= R3: damage & days<=7
         damage? yes  [why: R3 > R10 > R12]
         days<=7? yes  [why: R3 > R10 > R12]
      defect_claim: PROVED by R3
   return_ok: PROVED by R10
refund_allowed: PROVED by R12
answer: True

কোনটি কখন

বাস্তবে দুটি মেশানো হয়: অর্ডার এলে forward chaining দিয়ে সব সতর্কতা, আর কর্মী একটি নির্দিষ্ট প্রশ্ন করলে backward chaining. Horn clause-এর জন্য দুটি পদ্ধতিই sound (যা প্রমাণ করে তা সত্যিই নিয়ম থেকে আসে) আর complete (যা আসে তা প্রমাণ করতে পারে); forward chaining-এর সময় fact আর নিয়মের মোট আকারের প্রায় সমানুপাতিক (রৈখিক) করা যায়, এ বিষয়ে বিস্তারিত পর্ব ৪৫-এ।

৫ · Conflict resolution — একই তথ্যে ভিন্ন সিদ্ধান্ত

অংশ ৩-এর প্রথম ক্রেতার ক্ষেত্রে নির্দিষ্ট নিয়ম R19 তালিকায় আগে ছিল বলে উত্তর ঠিক এসেছিল। এবার একটি কঠিন ঘটনা: একজন ক্রেতা ডেলিভারির দিনই জানালেন খাবারের প্যাকেট খুলে দেখেন ভেতরে নষ্ট (cat=food opened damage pay=cod days=1). R16 বলছে স্বাস্থ্যবিধির পণ্য, বাতিল; R18 বলছে ত্রুটি, পুরো টাকা ফেরত। দোকানের নীতি স্পষ্টতই দ্বিতীয়টি চায়: নষ্ট খাবার পাঠিয়ে টাকা না ফেরানো অন্যায়। কিন্তু engine কোনটি নেবে, তা ঠিক করে conflict resolution কৌশল।

নিচের stepper নষ্ট খাবারের ঘটনার ষষ্ঠ চক্রে থামে, যখন working memory-তে এসেছে hygiene_item (চক্র ১), defect_claim (২), return_ok (৩), refund_allowed (৪) আর refund_to_wallet (৫)। Conflict set-এ তিনটি সিদ্ধান্ত-নিয়ম। প্রতিটি কৌশল কোনটি বাছে, দেখুন।

1R16: hygiene_item -> reject2R18: refund_allowed & defect_claim -> full_refund3R20: refund_allowed -> refund_minus_fee

SALIENCE = {"R16": -2, "R17": -2, "R18": -1, "R19": -1, "R20": -3}  # decide last
STRATEGIES = {
    "rule order":  lambda cs, wm: cs[0],
    "specificity": lambda cs, wm: max(cs, key=lambda r: len(r[1])),
    "recency":     lambda cs, wm: max(cs, key=lambda r: max(wm.get(c, 0) for c in r[1])),
    "salience":    lambda cs, wm: max(cs, key=lambda r: SALIENCE.get(r[0], 0)),
}
for case in ["cat=food opened damage pay=cod days=1",
             "cat=electronics opened damage pay=card days=3"]:
    print(case)
    for name, pick in STRATEGIES.items():
        wm, fired = forward(case, pick, show=False)
        d = [f for f in wm if f.startswith("decision")]
        print(f"  {name:12} {' '.join(fired):38} {d[0][9:]}")

cat=food opened damage pay=cod days=1
  rule order   R1 R3 R10 R12 R14 R16                  reject
  specificity  R1 R3 R10 R12 R14 R18                  full_refund
  recency      R1 R16 R3 R10 R12 R14                  reject
  salience     R1 R3 R10 R12 R14 R18                  full_refund
cat=electronics opened damage pay=card days=3
  rule order   R3 R4 R10 R11 R12 R13 R17              exchange
  specificity  R3 R4 R11 R10 R12 R13 R18              full_refund
  recency      R3 R10 R12 R13 R18 R4 R11              full_refund
  salience     R3 R4 R10 R11 R12 R13 R18              full_refund

এর সমাধান হিসেবে প্রচলিত তিনটি অভ্যাস: (১) সিদ্ধান্ত-নিয়মগুলোকে আলাদা ধাপে রাখা, যাতে সব তথ্য বের হওয়ার পরেই সিদ্ধান্ত হয় (salience বা CLIPS-এর module দিয়ে); (২) ব্যতিক্রমকে সাধারণ নিয়মের শর্তে স্পষ্ট লেখা, যেমন R16-এ “এবং ত্রুটি নেই” যোগ করা; (৩) অংশ ৭-এর মতো কোড দিয়ে পরস্পরবিরোধী নিয়ম খুঁজে বের করা। অংশ ৯-এ একটি সত্যিকারের engine, CLIPS, ঠিক এই ঘটনায় কী করে, তা দেখবেন।

৬ · Rete — প্রতি চক্রে সব কিছু আবার না মেলানো

অংশ ৩-এর সতর্কতাটি মনে করুন: সরল engine প্রতিটি চক্রে সব নিয়মের সব শর্ত আবার পরীক্ষা করে। কিন্তু একটি চক্রে working memory-র বেশিরভাগই অপরিবর্তিত থাকে। Rete algorithm-এর মূল ভাবনা: মিলের ফল মনে রাখুন, আর প্রতি চক্রে শুধু পরিবর্তনটুকু (নতুন বা মোছা fact) network-এর ভেতর দিয়ে পাঠান। Charles Forgy এটি Carnegie Mellon-এ তাঁর ১৯৭৯ সালের PhD থিসিসে দেন, আর ১৯৮২ সালে “Artificial Intelligence” জার্নালের একটি প্রবন্ধে প্রকাশ করেন। “Rete” লাতিন শব্দ, অর্থ জাল। তাঁর OPS5 ভাষা এর ওপর চলত, আর XCON লেখা হয়েছিল OPS-পরিবারের ভাষায়।

দুটি কৌশল এর গতি আনে। এক, ভাগাভাগি: opened শর্তটি আমাদের চারটি নিয়মে আছে, কিন্তু network-এ একটিই node. দুই, আংশিক মিল মনে রাখা: cat=food আগেই মিলেছে, এবার opened এলে শুধু join node-এ নতুন জোড়টি তৈরি হয়, পুরোনো কাজ আবার হয় না। দাম হলো মেমরি: সব আংশিক মিল জমা রাখতে হয়। আমাদের ২০টি নিয়মের propositional উদাহরণে লাভ সামান্য; লাভ বিশাল হয় যখন নিয়মে variable থাকে (“যেকোনো অর্ডার ?o যার গ্রাহক ?c …”) আর হাজার হাজার fact-এর জোড় মেলাতে হয়। পরে Rete-এর অনেক রূপ এসেছে (Forgy-র নিজের Rete II, TREAT, LEAPS); Drools তার docs অনুযায়ী Rete থেকে আসা Phreak নামের একটি পদ্ধতি ব্যবহার করে। এখানে implementation নয়, শুধু ধারণা: বিস্তারিত Forgy-র মূল প্রবন্ধে।

৭ · ব্যাখ্যা আর যাচাই — why, how আর rule base-এর test

Rule-based system-এর সবচেয়ে বড় শক্তি explainability: প্রতিটি সিদ্ধান্তের পেছনে একটি নির্দিষ্ট নিয়মের শিকল আছে, যা ছাপানো যায়। ক্রেতা প্রশ্ন করলে কর্মী বলতে পারেন “আপনার পণ্য খোলা কাপড়, ১৪ দিনের সময়সীমার মধ্যে, তাই ফেরত চলে, তবে নীতি অনুযায়ী ১০% চার্জ”। একটি neural network-এর সিদ্ধান্ত এভাবে নিয়মের ভাষায় পড়া যায় না; তার ব্যাখ্যার কৌশল আলাদা আর আনুমানিক (পরে machine learning-এর অংশে)।

কিন্তু ব্যাখ্যাযোগ্য মানে নির্ভুল নয়। অংশ ৫ দেখিয়েছে, প্রতিটি নিয়ম আলাদাভাবে যুক্তিসঙ্গত হলেও একসঙ্গে ভুল ফল দিতে পারে। তাই rule base-কেও কোডের মতো test করতে হয়। নিচের ব্লক তিনটি কাজ করে:

• সব ইনপুট মিশ্রণ চালানো: ৫টি ধরন × খোলা/সিল × ক্ষতি আছে/নেই × ৩টি পেমেন্ট × ৭টি দিন = ৪২০টি ঘটনা। দিনের মানগুলো (1, 3, 5, 7, 10, 14, 20) প্রতিটি সীমার দুই পাশে পড়ে; এ কৌশলের নাম boundary value analysis (Software Engineering কোর্সের test design পর্ব)।
• Rule coverage: কোন নিয়ম কোনো ঘটনাতেই চলেনি। এর জন্য একটি নতুন নিয়ম যোগ করা হয়েছে, যা একজন কর্মী প্রস্তাব করলেন: R21, “বদলযোগ্য আর সিল করা হলে বদল”।
• বিরোধ খোঁজা: একই ঘটনায় ভিন্ন সিদ্ধান্তের দুটি নিয়ম মিললে, যদি একটির শর্ত অন্যটির শর্তের অংশ না হয় (মানে specificity দিয়ে মীমাংসা হয় না), তবে সেটি সত্যিকারের বিরোধ।

শেষে দ্বিতীয় ক্রেতার সিদ্ধান্তের একটি “how” ব্যাখ্যা, forward chaining-এর trace থেকে।

from itertools import product, combinations
RULES[:] = [r for r in RULES if r[0] != "R21"] + [        # add a new rule R21
    ("R21", ["exchange_only", "sealed"], "decision=exchange")]
R = {r[0]: r for r in RULES}
def closure(case):                             # every rule that could fire
    wm, matched, grew = {f: 0 for f in case.split()}, set(), True
    wm["days"] = int(case.split("days=")[1])
    while grew:
        grew = False
        for name, conds, then in RULES:
            if name not in matched and all(holds(c, wm) for c in conds):
                matched.add(name); wm[then] = 1; grew = True
    return matched
used, clash, n = set(), {}, 0
for cat, box, dmg, pay, d in product(["food", "cosmetics", "electronics", "clothing",
        "book"], ["opened", "sealed"], [" damage", ""], ["cod", "wallet", "card"],
        [1, 3, 5, 7, 10, 14, 20]):
    case, n = f"cat={cat} {box}{dmg} pay={pay} days={d}", n + 1
    m = closure(case)
    used |= m
    dec = sorted(x for x in m if R[x][2].startswith("decision="))
    for a, b in combinations(dec, 2):          # different verdict, neither is
        A, B = set(R[a][1]), set(R[b][1])      # a special case of the other
        if R[a][2] != R[b][2] and not (A <= B or B <= A):
            clash.setdefault((a, b), case)
print(n, "cases | never fired:", [r[0] for r in RULES if r[0] not in used])
for (a, b), case in clash.items():
    print(f"  clash {a} {R[a][2][9:]} vs {b} {R[b][2][9:]} | e.g. {case}")
wm, fired = forward("cat=clothing opened pay=wallet days=12", show=False)
def how(fact, depth=0):                        # "how" explanation of a fact
    r = next((R[x] for x in fired if R[x][2] == fact), None)
    print("   " * depth + fact, f"<- {r[0]}" if r else "(given)" if fact in wm else "(test)")
    for c in (r[1] if r else []):
        how(c, depth + 1)
how("decision=refund_minus_fee")

420 cases | never fired: ['R21']
  clash R16 reject vs R18 full_refund | e.g. cat=food opened damage pay=cod days=1
  clash R16 reject vs R20 refund_minus_fee | e.g. cat=food opened damage pay=cod days=1
  clash R17 exchange vs R18 full_refund | e.g. cat=electronics opened damage pay=cod days=1
  clash R17 exchange vs R20 refund_minus_fee | e.g. cat=electronics opened damage pay=cod days=1
decision=refund_minus_fee <- R20
   refund_allowed <- R12
      return_ok <- R9
         in_window <- R5
            cat=clothing (given)
            days<=14 (test)
         opened (given)
         cat=clothing (given)

এই চেকার একটি বড় সত্য দেখায়: সব মিশ্রণ চালানো এখানে সম্ভব কারণ ইনপুটের জগৎ ছোট (৪২০টি)। ইনপুট বাড়লে মিশ্রণের সংখ্যা বিস্ফোরিত হয় (পর্ব ৪৩-এর combinatorial explosion), তখন নিয়মের শর্তগুলোকে logic-এর সূত্রে রূপান্তর করে SAT solver দিয়ে প্রশ্ন করা হয়: “এমন কোনো ইনপুট কি আছে যাতে R16 আর R18 দুটিই সত্য?” (পর্ব ৪৫)। বাস্তবের rule base-এ এর সঙ্গে থাকে প্রতিটি নিয়মের অন্তত একটি unit test, নিয়মের ইতিহাস (কে, কবে, কেন বদলালেন), আর নিয়ম বদলের আগে পুরোনো সব ঘটনা আবার চালিয়ে দেখা কোন সিদ্ধান্ত বদলাল।

৮ · অনিশ্চয়তা আর expert system-এর যুগ — MYCIN থেকে XCON

বাজারঘরের নীতিতে সব হ্যাঁ-না। কিন্তু ডাক্তারের রোগনির্ণয়ে “জ্বর থাকলে টাইফয়েড” নিশ্চিত নয়, সম্ভাব্য। ১৯৭০-এর দশকে Stanford-এ Edward Shortliffe-এর PhD কাজ হিসেবে তৈরি MYCIN রক্তের সংক্রমণে কোন জীবাণু দায়ী আর কোন antibiotic দেওয়া উচিত, তা নিয়ে পরামর্শ দিত। এটি backward chaining-এ চলত: “জীবাণুটি কি E. coli?” লক্ষ্য থেকে শুরু করে ডাক্তারকে প্রশ্ন করত, আর ডাক্তার “why” টাইপ করলে বলত কোন নিয়মের জন্য প্রশ্নটি। এর জ্ঞান ছিল কয়েকশো নিয়মে (প্রকাশিত বিবরণে সংখ্যাটি সংস্করণভেদে আলাদা)।

অনিশ্চয়তার জন্য MYCIN ব্যবহার করত certainty factor (CF): −1 (নিশ্চিতভাবে মিথ্যা) থেকে +1 (নিশ্চিতভাবে সত্য), ০ মানে জানা নেই। Shortliffe আর Bruce Buchanan ১৯৭৫ সালের দিকের একটি প্রবন্ধে এই মডেল দেন। দুটি সূত্র (দুটি CF-ই ধনাত্মক ধরে):

CF(সিদ্ধান্ত) = CF(নিয়ম) × min(শর্তগুলোর CF)
দুটি নিয়ম একই সিদ্ধান্ত দিলে: CF = CF₁ + CF₂ × (1 − CF₁)

উদাহরণ: একটি নিয়মের CF 0.7, তার দুটি শর্তের CF 0.8 আর 0.6. সিদ্ধান্তের CF = 0.7 × 0.6 = 0.42. আরেকটি নিয়ম একই সিদ্ধান্ত 0.5 CF-এ দিলে মিলিত CF = 0.42 + 0.5 × 0.58 = 0.42 + 0.29 = 0.71. খেয়াল করুন, দুটি প্রমাণ একসঙ্গে বিশ্বাস বাড়ায়, কিন্তু কখনো 1 ছাড়ায় না।

কেন যুগটি ফিকে হলো

• Knowledge acquisition bottleneck: বিশেষজ্ঞ নিজেও অনেক সময় জানেন না তিনি কোন নিয়ম মানেন; একজন knowledge engineer-কে মাসের পর মাস সাক্ষাৎকার নিয়ে নিয়ম বের করতে হতো। অংশ ৭-এর R21 এর ক্ষুদ্র রূপ: কর্মী যা বোঝাতে চেয়েছিলেন, নিয়মে তা আসেনি।
• Brittleness: নিয়মের বাইরের ঘটনায় system ধীরে খারাপ হয় না, হঠাৎ পুরো ভুল বা নীরব। অংশ ৩-এর ২০ দিনের বই কোনো উত্তরই পায়নি। MYCIN-এর মতো system জানত না কোন প্রশ্ন তার জ্ঞানের বাইরে।
• রক্ষণাবেক্ষণ: নিয়ম বাড়লে একটি বদলালে কোথায় কী ভাঙে বলা কঠিন; অংশ ৫-এর ক্রম-নির্ভরতা হাজার নিয়মে দুঃস্বপ্ন। XCON-এর রক্ষণাবেক্ষণের জন্য একটি স্থায়ী দল লাগত বলে প্রকাশিত বিবরণে আছে।
• অনিশ্চয়তা: CF সহজ, কিন্তু পরে দেখানো হয় (যেমন David Heckerman-এর ১৯৮০-এর দশকের মাঝামাঝির কাজে) যে এর সূত্রগুলো সম্ভাবনার নিয়মের সঙ্গে মেলে শুধু কিছু কঠোর স্বাধীনতার অনুমানে, যা বাস্তবে প্রায়ই ভাঙে; একই প্রমাণ দুই পথে এলে দুবার গোনা হয়। Judea Pearl-এর ১৯৮৮ সালের বই Bayesian network-কে পরিচিত করে, আর সম্ভাবনাভিত্তিক পদ্ধতি এই জায়গা নেয়। তার শুরু পর্ব ৫০-এ, Bayes-এর উপপাদ্য দিয়ে।

৯ · আজ নিয়ম কোথায় — business rules থেকে LLM-এর guardrail

“Expert system” নামটি আর জনপ্রিয় নয়, কিন্তু নিয়ম কোথাও যায়নি। Symbolic AI আর machine learning প্রতিদ্বন্দ্বী নয়; অনেক বাস্তব system-এ দুটি পাশাপাশি চলে।

• Business rules engine: ছাড়, ফেরত, বিমা বা ঋণের নীতি কোড থেকে আলাদা রাখা হয়, যাতে নীতি বদলালে নিয়ম বদলায়। Drools (Java, open source) একটি পরিচিত উদাহরণ।
• Decision table: শর্তের প্রতিটি মিশ্রণ এক সারিতে, সিদ্ধান্ত পাশে। OMG-র DMN (Decision Model and Notation) মান এ ধরনের টেবিল লেখার একটি সাধারণ ভাষা দেয়। বাজারঘরের নীতিকে টেবিলে লিখলে অংশ ৭-এর ফাঁক আর বিরোধ চোখেই পড়ে।
• জালিয়াতি আর compliance যাচাই: সাধারণত একটি ML model ঝুঁকির স্কোর দেয়, আর নিয়ম বলে “স্কোর বেশি আর টাকা বড় হলে লেনদেন আটকানো হবে”, “নিষেধাজ্ঞার তালিকায় নাম থাকলে থামানো হবে”। নিয়ম নিরীক্ষকের কাছে ব্যাখ্যা করা যায়, তাই নিয়ন্ত্রিত খাতে নিয়মের ভূমিকা বড় থাকে।
• Form validation: ফোন নম্বর ১১ অঙ্কের, ডেলিভারির তারিখ ভবিষ্যতে, এসবই ছোট নিয়ম (data validation).
• ML আর LLM-এর চারপাশে guardrail: একটি LLM-ভিত্তিক সহকারী ক্রেতার কথা বুঝে ফেরতের অনুরোধ লিখতে পারে, কিন্তু টাকা ফেরতের সিদ্ধান্ত নেবে নিয়ম: “১০,০০০ টাকার বেশি হলে মানুষের অনুমোদন”। নিয়ম নির্দিষ্ট আর পরীক্ষা করা যায়; তবে LLM-এর লেখা ভাষার ওপর শব্দভিত্তিক নিয়ম সহজেই এড়ানো যায় (প্রতিশব্দ, অন্য ভাষা), তাই guardrail একাধিক স্তরে লাগে।

সত্যিকারের Python library — কোনটি চলে

লেখার সময়ে (Python 3.14.4, Windows-এর একটি ল্যাপটপে, প্রতিটি package আলাদা venv-এ) চারটি library পরখ করা হয়েছে। PyPI-র তথ্য অনুযায়ী:

~/bazarghar-rules$ python -c "import experta"
…
  File ".../frozendict/__init__.py", line 16, in <module>
    class frozendict(collections.Mapping):
                     ^^^^^^^^^^^^^^^^^^^
AttributeError: module 'collections' has no attribute 'Mapping'

CLIPS ১৯৮০-এর দশকের মাঝামাঝি NASA-র Johnson Space Center-এ শুরু হয়, আর লেখার সময়েও এর নতুন সংস্করণ বের হয় (clipspy-তে CLIPS 6.42), বিনামূল্যে; এটি forward chaining আর Rete-ধাঁচের matching ব্যবহার করে। নিচে অংশ ৫-এর নষ্ট খাবারের ঘটনার জন্য পাঁচটি নিয়ম, CLIPS-এর নিজের ভাষায়। (not (decision)) আমাদের “একটিই সিদ্ধান্ত” শর্ত।

; Bazarghar return policy (invented) - a few rules in CLIPS
(deftemplate order (slot cat) (slot box) (slot damage) (slot days) (slot pay))
(deftemplate fact (slot name))
(deftemplate decision (slot value) (slot by))

(defrule hygiene-item
  (order (cat food|cosmetics) (box opened))
  => (assert (fact (name hygiene_item))))
(defrule defect-claim
  (order (damage yes) (days ?d&:(<= ?d 7)))
  => (assert (fact (name defect_claim))))
(defrule return-ok-defect
  (fact (name defect_claim))
  => (assert (fact (name refund_allowed))))

(defrule reject-hygiene (declare (salience -20))
  (fact (name hygiene_item))
  (not (decision))
  => (assert (decision (value reject) (by reject-hygiene))))
(defrule full-refund-defect (declare (salience -10))
  (fact (name refund_allowed))
  (fact (name defect_claim))
  (not (decision))
  => (assert (decision (value full_refund) (by full-refund-defect))))

Python থেকে চালানো হলো তিনভাবে: salience ছাড়া CLIPS-এর default কৌশল DEPTH (নতুন জাগা নিয়ম আগে), salience ছাড়া COMPLEXITY (বেশি জটিল শর্ত আগে, specificity-র কাছাকাছি), আর salience সহ। প্রতি ধাপে agenda (CLIPS-এ conflict set-এর নাম) ছাপানো হয়েছে। সত্যিকারের run:

~/bazarghar-rules$ python run_clips.py
Python 3.14.4 | clipspy 1.0.6
--- no salience, strategy=DEPTH
  fire hygiene-item         agenda: hygiene-item(0), defect-claim(0)
  fire reject-hygiene       agenda: reject-hygiene(0), defect-claim(0)
  fire defect-claim         agenda: defect-claim(0)
  fire return-ok-defect     agenda: return-ok-defect(0)
  => reject by reject-hygiene
--- no salience, strategy=COMPLEXITY
  fire hygiene-item         agenda: hygiene-item(0), defect-claim(0)
  fire defect-claim         agenda: defect-claim(0), reject-hygiene(0)
  fire reject-hygiene       agenda: reject-hygiene(0), return-ok-defect(0)
  fire return-ok-defect     agenda: return-ok-defect(0)
  => reject by reject-hygiene
--- with salience, strategy=DEPTH
  fire hygiene-item         agenda: hygiene-item(0), defect-claim(0)
  fire defect-claim         agenda: defect-claim(0), reject-hygiene(-20)
  fire return-ok-defect     agenda: return-ok-defect(0), reject-hygiene(-20)
  fire full-refund-defect   agenda: full-refund-defect(-10), reject-hygiene(-20)
  => full_refund by full-refund-defect

ছোট business rule বা form validation-এর জন্য rule-engine হালকা বিকল্প: নিয়ম একটি লেখা (string), আর তা dict-এর ওপর মেলানো হয়। সত্যিকারের run:

from importlib.metadata import version
import rule_engine

orders = [
    {"id": "BG-101", "cat": "electronics", "days": 5, "box": "sealed", "amount": 18500},
    {"id": "BG-102", "cat": "clothing", "days": 16, "box": "opened", "amount": 1200},
    {"id": "BG-103", "cat": "book", "days": 4, "box": "opened", "amount": 450},
]
in_window = rule_engine.Rule(
    '(cat == "electronics" and days <= 7) or (cat == "clothing" and days <= 14)'
    ' or (cat == "book" and days <= 10)')
needs_review = rule_engine.Rule('amount > 10000 and box == "sealed"')
print("rule-engine", version("rule-engine"))
for o in orders:
    print(o["id"], "in_window:", in_window.matches(o), "| manual review:", needs_review.matches(o))
print([o["id"] for o in in_window.filter(orders)])
try:
    rule_engine.Rule('amount > ')
except rule_engine.errors.RuleSyntaxError as e:
    print("syntax error caught:", e.message)

~/bazarghar-rules$ python run_re.py
rule-engine 5.2.0
BG-101 in_window: True | manual review: True
BG-102 in_window: False | manual review: False
BG-103 in_window: True | manual review: False
['BG-101', 'BG-103']
syntax error caught: syntax error at: EOF

শেষ লাইনটি গুরুত্বপূর্ণ: ভুল লেখা নিয়ম (amount >) চালানোর সময় নয়, নিয়ম তৈরির সময়েই ধরা পড়েছে। নীতির নিয়ম যখন কর্মীরা নিজেরা লেখেন, তখন এই যাচাই অপরিহার্য।

১০ · AI-এর যুগে — AI সহকারী দিয়ে rule base লেখা

দোকানের ফেরত-নীতির একটি rule engine চাইলে AI সহকারী দ্রুত কোড দেবে। কিন্তু নিয়মের ভুল নীরব: প্রতিটি নিয়ম পড়তে যুক্তিসঙ্গত লাগে, অথচ একসঙ্গে ভুল সিদ্ধান্ত দেয়। এ ধরনের কাজে AI সহকারীরা প্রায়ই যা করে:

• অচল library সুপারিশ: experta বা durable-rules-এর কোড দেয়, যা লেখার সময়ে বর্তমান Python-এ চলেইনি (অংশ ৯); অথবা এদের বানানো API লেখে।
• ক্রমের ওপর নীরব নির্ভরতা: সাধারণ নিয়ম আগে, ব্যতিক্রম পরে লিখে if-elif-এর শিকল; অংশ ৫-এর নষ্ট খাবারের ভুল।
• default না রাখা: কোনো নিয়ম না খাটলে কী হবে, তা ভাবে না; অথবা চুপচাপ “reject” ধরে নেয়।
• শুধু সুখের পথের test: সীমার মান (৭ দিন, ৮ দিন), পরস্পরবিরোধী শর্ত আর অপ্রাপ্য নিয়ম পরীক্ষা করে না।
• নীতি বানিয়ে ফেলা: আপনি বলেননি এমন সময়সীমা বা চার্জ বসিয়ে দেয়; প্রতিটি সংখ্যা নীতির মালিকের সঙ্গে মেলানো দরকার।

AI-এর লেখা rule base হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি নিয়ম নীতির কোন বাক্য থেকে এসেছে, মিলিয়েছি; বানানো সময়সীমা বা চার্জ নেই
• নিয়মের ক্রম উল্টে দিয়েও একই সিদ্ধান্ত আসে কি না, চালিয়ে দেখেছি
• সীমার দুই পাশের মান (৭ আর ৮ দিন) সহ সব ইনপুট মিশ্রণ চালিয়ে rule coverage আর বিরোধ দেখেছি
• কোনো নিয়ম না খাটলে কী হয়, তা দেখেছি; default মানুষের কাছে যায়
• সুপারিশ করা library PyPI-তে কবে সর্বশেষ বের হয়েছে আর আমার Python-এ চলে কি না, নিজে install করে দেখেছি
• আসল ক্রেতার নাম, ফোন বা অর্ডারের তথ্য AI-তে পেস্ট করিনি; বানানো উদাহরণ দিয়েছি