מערכת מבוססת כללים (Rule-based System)

ידע שנכתב ביד, לא נלמד מנתונים

מערכת מבוססת כללים (Rule-based System) היא, לפי ויקיפדיה, מערכת מחשב שבה הידע על תחום מסוים מיוצג בצורת כללים, ומנגנון היסק כללי משתמש בהם כדי לפתור בעיות בתחום. כלל טיפוסי נראה כך: "אם התנאי מתקיים — אז עשה או הסק משהו". במערכת הקלאסית, שבה עוסק הערך הזה, את הכללים מנסחים בני אדם — ובזה ההבדל העיקרי מלמידת מכונה, שבה המערכת מחלצת דפוסים מתוך דוגמאות.

יש גם הבדל מתכנות אימפרטיבי, שבו כותבים הוראות בסדר ביצוע מפורש, שורה אחר שורה. במערכת כללים מפרידים את הידע מהמנגנון שמפעיל אותו: כותבים את הכללים, והמערכת עצמה מחליטה בכל רגע איזה כלל להפעיל לפי העובדות הקיימות. לפי ויקיפדיה, בשנות ה-70 צמחו בבינה המלאכותית שני סוגים של מערכות כאלה: "מערכות כללי הפקה" (Production Systems), שגוזרות פעולות מתנאים בכללי "אם-אז", ותכנות לוגי — שפות כמו Prolog — שבו הכללים נכתבים כ"מסקנה אם תנאים". מערכת מומחה — למשל מערכת שעוזרת לרופא לבחור אבחנה לפי צירוף של תסמינים — היא הדוגמה הקלאסית לגישה, אבל רחוקה מלהיות היחידה.

ארבעה רכיבים ומחזור אחד

לפי ויקיפדיה, למערכת כללים טיפוסית יש ארבעה רכיבים: מאגר הכללים; מנוע ההסקה, שמפעיל את הכללים; זיכרון עבודה, שהוא מאגר העובדות הנוכחי; וממשק שדרכו נכנס מידע ויוצאות תוצאות. מנוע ההסקה כאן אינו "הסקה" במובן של הרצת מודל מאומן, אלא תוכנה שבודקת אילו כללים מתאימים לעובדות.

במערכת כללי הפקה, המנוע עובד במחזור של שלושה שלבים. בשלב ההתאמה הוא משווה את חלקי ה"אם" של כל הכללים לעובדות בזיכרון, ומקבל את "קבוצת הקונפליקט" — כל הכללים שהתנאי שלהם מתקיים. בשלב יישוב הקונפליקט הוא בוחר אחד מהם, למשל לפי סדר הכתיבה או לפי עדיפויות שנקבעו מראש. בשלב הפעולה הוא מבצע את חלק ה"אז" של הכלל, וזה עשוי לשנות את העובדות בזיכרון — ואז המחזור מתחיל מחדש. במילים אחרות: כלל שהתנאי שלו מתקיים נעשה מועמד לביצוע, ורק כשהוא נבחר הפעולה שלו מתבצעת. אם אף כלל לא מתאים, המערכת נעצרת.

קדימה מהנתונים או אחורה מהמטרה

יש שתי דרכים עיקריות להפעיל כללים, וויקיפדיה מדגימה את שתיהן על חיית מחמד בשם פריץ שמקרקרת ואוכלת זבובים. מאגר הכללים כולל, בין השאר: "אם X מקרקר ואוכל זבובים — X צפרדע", ו"אם X צפרדע — X ירוק".

בשרשור קדימה (Forward Chaining) מתחילים מהעובדות. המנוע רואה שפריץ מקרקר ואוכל זבובים, מסיק שהוא צפרדע, ומשם שהוא ירוק. השיטה "מונעת-נתונים": כל עובדה חדשה יכולה להצית מסקנות חדשות, ולכן היא מתאימה למצבים שמשתנים כל הזמן. בשרשור אחורה (Backward Chaining) מתחילים מהמטרה: האם פריץ ירוק? כדי לדעת, המנוע מחפש כלל שמסקנתו "ירוק", הופך את התנאי שלו — "פריץ צפרדע" — למטרת משנה, וממשיך כך עד שהוא מגיע לעובדות הידועות. השיטה "מונעת-מטרה", ובה משתמשת שפת Prolog. בשני המקרים, הכללים על הקנרית לא הופעלו כלל.

Rete: איך בודקים אלפי כללים מהר

הדרך הנאיבית להריץ מערכת כללים היא לבדוק כל כלל מול כל העובדות, שוב ושוב בכל מחזור. לפי ויקיפדיה, כבר במערכות בגודל בינוני זה איטי מדי. הפתרון המוכר הוא אלגוריתם Rete ("רשת" בלטינית), שתכנן צ'רלס פורגי מאוניברסיטת קרנגי מלון: הוא פורסם לראשונה במסמך עבודה ב-1974, ופותח בעבודת הדוקטורט שלו ב-1979 ובמאמר מ-1982.

במקום לבדוק הכול מחדש, Rete בונה רשת של צמתים, שבה כל צומת מייצג תבנית אחת מתוך תנאי הכללים וזוכר אילו עובדות כבר מתאימות לה. כשעובדה חדשה נכנסת, היא זורמת ברשת ומעדכנת רק את הצמתים הרלוונטיים. המחיר הוא זיכרון: האלגוריתם מקריב זיכרון בתמורה למהירות. Rete שימש לראשונה כמנוע של שפת הכללים OPS5, והפך לבסיס של מנועי כללים רבים, בהם CLIPS, Jess ו-Drools.

XCON: אלפי כללים בעולם האמיתי

אחת ההצלחות המסחריות הגדולות של הגישה הייתה R1, שנקראה בתוך החברה XCON. ג'ון מקדרמוט מאוניברסיטת קרנגי מלון כתב אותה ב-1978 בשפת OPS5, עבור חברת המחשבים DEC. הבעיה הייתה מעשית: לקוח שהזמין מחשב VAX היה צריך להזמין בנפרד כל כבל, חיבור ורכיב תוכנה, ואנשי המכירות לא תמיד ידעו מה מתאים למה. התוצאה הייתה לקוחות עם מדפסות בלי מנהלי ההתקן הנכונים או מעבדים בלי השבב הנדרש.

XCON בחרה את הרכיבים לפי דרישות הלקוח. היא נכנסה לשימוש ב-1980 במפעל של DEC בניו המפשייר, ובסופו של דבר כללה כ-2,500 כללים. לפי ויקיפדיה, עד 1986 עיבדה 80,000 הזמנות בדיוק של 95–98%, וההערכה הייתה שהיא חוסכת ל-DEC כ-25 מיליון דולר בשנה. בהמשך פיתחה החברה מערכות נוספות באותה שיטה, כמו XSEL לאנשי המכירות. הסיפור הרחב של מערכות כאלה, כולל DENDRAL ו-MYCIN, מופיע בערך על מערכת מומחה.

כללים לצד למידת מכונה היום

מערכות כללים לא נעלמו עם עליית למידת המכונה, ולעיתים קרובות הן עובדות לצידה. דוגמה מתועדת היא Stripe Radar, מערכת למניעת הונאות בתשלומים. לפי התיעוד של Stripe, כל עסקה נבדקת מול כללי ברירת מחדל, וחלק מהכללים האלה נשענים על מודלי AI — למשל כלל ששולח לבדיקה ידנית תשלום שהמודל העריך את רמת הסיכון שלו כ"מוגברת". לצד זה, בתוכנית Radar שתומכת בכללים מותאמים, עסק יכול לכתוב כללים משלו: לבקש אימות נוסף (3D Secure) בתשלום של לקוח חדש, כשהתשלום תומך בכך, לחסום תשלומים מכרטיס שהונפק מחוץ למדינה, או לשלוח לבדיקה כל תשלום מעל 1,000 דולר שנעשה בכרטיס נטען (Prepaid). המודל מעריך את הסיכון, והכלל, שאדם כתב ויכול לקרוא, מחליט מה עושים עם ההערכה.

היתרון של כללים הוא שהם צפויים וקריאים: אפשר לראות בדיוק איזה כלל הוביל להחלטה. החיסרון הוא שכאשר מצב חדש אינו מכוסה בכללים הקיימים, צריך להוסיף או לעדכן כללים, ושהמערכת עלולה להיעשות קשה לתכנון. ויקיפדיה מציינת שבמערכות כללי הפקה סדר הכללים יכול להיות "קריטי", ושהיעדר מבנה בקרה מפורש "הופך אותן לקשות לתכנון". בעיה דומה, של מספר כללים שגדל מהר מכדי שצוות יוכל לתחזק אותו, מתוארת בערך על מערכת מומחה כאחת הסיבות לדעיכת הגישה.