שערים דטרמיניסטיים במקום שיפוט של מודל
======================================
כתובת העמוד: https://yotamfromm.dev/developer/blog/deterministic-gates/
עודכן: 2026-10-21
גרסת Markdown: https://yotamfromm.dev/developer/blog/deterministic-gates.md
מפת האתר ל-agents: https://yotamfromm.dev/llms.txt

אם שיפוט של agent יכול לשנות את התוצאה, זה לא שער אלא המלצה. ארבעה מקרים שבהם LLM judge, בדיקה חלשה או כלל כתוב החליטו לא נכון, ומה החליף אותם.

אם החלטה ב-workflow שלך נשענת על model, כדאי לבדוק אם היא באמת שער או רק המלצה. הפוסט מביא ארבעה מקרים שבהם model, test חלש או כלל כתוב החליטו לא נכון, ומה החליף אותם.

הכלל שלי: אם צעד יכול להיות סקריפט, hook או קוד יציאה, הוא נכתב כקוד, וה-model יוצא מההחלטה. המבחן פשוט: אם השיפוט של agent יכול לשנות את התוצאה, זה לא שער אלא המלצה. תקרות על לולאות תיקון, שערי איכות בין שלבים, ואיזה model מריץ איזה שלב יושבים בסקריפט ה-orchestrator, כי סקריפט אפשר לקרוא ולבדוק, וב-prompt אפשר רק לקוות. את הניסוח הזה של המבחן לקחתי מדיון של מתרגלים אחרים שלא אימתתי. ארבעת המקרים שלמטה קרו אצלי.

judge שמיישם תקרה בחוסר עקביות

בתחרות עיצוב בין חמישה מסלולים לבניית דף הבית, ביקשתי מ-judge מבוסס model להוריד ציון לכל דף שנופל ל"מראה של בינה מלאכותית": קרם, סריף וטרקוטה. הוא הוריד ל-Opus הפשוט ולא הוריד ל-Stitch, והוריד ל-Claude Design בטעות. מאז ה-judge עונה רק על עובדות של כן ולא לכל צילום מסך, והתקרה מיושמת בקוד. אחרי התיקון Opus פשוט בלי כלי קיבל את הציון המשולב הגבוה ביותר, 8.18.

אותו סוג של judge התבקש לצפות ב-48 צילומי מסך, צפה ב-20 וכתב שהשאר "מניחים שעקביים". עכשיו הוא חייב לדווח כמה תמונות פתח, והקוד דוחה ספירה חסרה.

test שסופר קריאות ולא הצלחות

בניסוי עיצוב אחר, test בשם "הכלי באמת שימש" ספר קריאות ל-Stitch ולא תוצאות מוצלחות. בהרצות שנבדקו, Stitch יצר מסך אחד מתוך 7, אחד מתוך 5, ואפס מתוך 4, ושאר הקריאות פגו בזמן. בהמשך התברר שרוב המסכים כנראה הושלמו בצד של Stitch ופשוט לא היו ניתנים לאחזור, אבל ה-test לא ידע להבדיל. עכשיו היא סופרת תוצאה אחת מוצלחת לכל קריאה.

test מסוג grep שעובר גם כשהשער נמחק

ב-2026-09-08 הוספתי שער שמסרב להריץ את שלב העבודה ואת שלב הבדיקה על אותה משפחת models. כדי לבדוק את ה-tests, החלפתי ידנית את התנאי של השער ב-`if (false)`. חבילת ה-tests ההתנהגותית, שמריצה את הקוד, נכשלה: 97 עברו ו-3 נכשלו. שני tests של grep, שמחפשים בקוד את המחרוזת של השער, נשארו ירוקים, כי ההערה בקוד שרדה.

זו הייתה הפעם השנייה שתפסתי את הצורה הזאת: קודם, שינוי של תקרת הניסיונות החוזרים ושל כלל 2 מתוך 3 השאיר כל מחרוזת שנבדקה בעינה וכל test ירוק. grep מתאים לבדוק שקובץ קיים, שערך מקובע במקומו או שמחרוזת אסורה חסרה. להתנהגות צריך להריץ את הקוד, ולהוכיח שהחבילה יודעת להיכשל. את שני ה-tests של grep השארתי בכוונה, מתועדים כחולשה ידועה, כדי שהקורא הבא לא יחשוב שהם כיסוי.

גם הוכחת הכשל צריכה baseline ירוק. ב-2026-10-22 גיליתי שהרצה של "שבור ותראה שה-test נהיה אדום" חייבת להתחיל בהרצה של אותה פקודה בלי השבירה, אחרת מסנן tests שלא תופס כלום מסתיים בקוד יציאה לא אפסי ועובר כ"אדום". זה קרה פעם אחת, כשכותרת test הכילה נקודתיים במקום רווח.

כלל שכתבתי והוא חזר

ב-2026-10-15 כתבתי כלל: מעלים גרסה בכל שינוי בקבצי ה-plugin. בתוך יום הטעות חזרה. הכלל הפך לבדיקת שחרור ולשורה בבדיקת התקינות, כלומר לקוד ולא לפרוזה.

המדרגה האמצעית

לא כל החלטה היא חישוב. אני מחלק כל נקודת החלטה לשלוש מדרגות, ובוחר את הזולה שיכולה להכריע: סקריפט כשהתשובה ניתנת לחישוב, judge מוקלד (model שעונה כן או לא, אחת מכמה אפשרויות, או דירוג) כשהשיפוט עמום אבל התשובה סגורה, ו-language model רק כשצריך הסקה, סינתזה או טקסט. הבחירה של נתיב המשימה נשארת בקוד. גם כשה-judge המוקלד מחליט, הקוד קובע מה קורה בכל רמת ביטחון: לפעול, לאשר או לחזור למנגנון הקודם. הסף תלוי במחיר של טעות: כ-0.75 לתיוג הפיך, וכ-0.98 או בדיקה אנושית לכסף ולמחיקה. לפני שמקדמים judge כזה, מריצים אותו לצד המנגנון הקיים, ורק אחרי לפחות 100 מקרים שנבדקו מקדמים אותו.

מה אפשר לקחת מזה

1. שאל על כל החלטה: האם שיפוט של agent יכול לשנות את התוצאה? אם כן, זה לא שער אלא המלצה, והמקום שלו בסקריפט ה-orchestrator.
2. ספור הצלחות, לא קריאות. test "הכלי באמת שימש" חייב לספור תוצאה אחת מוצלחת לכל קריאה.
3. בדוק התנהגות בהרצה ושבור כדי להוכיח שה-test יודע להיכשל. התחל בהרצה ירוקה בלי השבירה, ואל תסמוך על grep בשביל התנהגות.
4. בקש מ-judge model עובדות של כן ולא לכל פריט, והחל את התקרות בקוד. דרוש ממנו ספירה של מה שפתח, ודחה ספירה חסרה.
5. חלק החלטות לשלוש מדרגות: סקריפט, judge מוקלד, language model. בחר את הזולה שיכולה להכריע, וקבע את הסף לפי מחיר הטעות.