סקריפט דטרמיניסטי מתאים כשלמשימה יש צורה קבועה, פלט ניתן לאימות ואף אחד לא מתכוון לקרוא שוב את התוצאה; סוכן LLM מתאים רק כשהקלט לא מובנה ואדם נשאר בלולאת הבדיקה. הכתבה החדשה של קייל קינגסברי על Jepsen ו-ParticleDB היא הטיעון המעשי הכי ברור ששמעתי בעד שמירה על הקו הזה חד.
בציטוט שאסף Simon Willison, קינגסברי מתריע שטקסטים של LLM מקלים לזייף את הסימנים שמהנדסים השתמשו בהם פעם כדי לשפוט בגרות של תוכנה: תיעוד מלוטש, הודעות commit בטוחות בעצמן, תיאורי בדיקות שנשמעים הגיוניים. התוצאה היא שחיקת אמון בתיעוד, בתוכנה ובארגונים שמייצרים אותם.
מה זה אומר לאוטומציה של עסק קטן בישראל
החילו את הכלל צומת אחרי צומת בתוך ה-pipeline. שליפת מספר חשבונית מ-PDF, שליחת payload ל-API, העברת שורות בין CRM לגיליון - זה סקריפט, והפלט חייב להיות ניתן לבדיקה בייט מול בייט. קריאת מכרז של 300 עמוד לאיתור קנסות סמויים במשרד עורכי דין, סיווג פנייה של מטופל במרפאה, סיכום פסק דין - שם ה-LLM מצדיק את מקומו, ורק כשה-pipeline מתעד את ההיגיון ומראה לאדם את ההבדלים. בpipeline לניתוח מכרזים שבניתי, OCR, חיתוך לקטעים וניתוב הם קוד דטרמיניסטי; המודל עונה רק על שאלות צרות, וכל סימון סיכון מקושר חזרה לפסקת המקור לבדיקה אנושית.
למה זה חשוב: התייחסו ל-LLM כחלק המטושטש של המחסנית, לא כמחסנית כולה. ככל שהאוטומציה נשענת יותר על טון בטוח של מודל ופחות על קוד שניתן לאמת, כך קשה יותר למישהו, כולל לכם, להבחין מתי משהו נשבר בשקט.
מקור: Simon Willison