פוסט שפורסם ב-11 באוגוסט בבלוג Legal Engineering 101 טוען שצוותים משפטיים רבים מפעילים מודלי שפה בתשלום לפי טוקן גם על שלבים שאין בהם שום הכרעה, ומציע מבחן קצר להבחין ביניהם. הכותבת, אלי מינן (Elly Meenan), קוראת לתופעה "Tokenmaxing": שימוש במודל בכל שלב בתהליך, בלי קשר לשאלה אם השלב באמת דורש חשיבה.
המבחן: האם השלב דטרמיניסטי
לפי הפוסט, לפני שכותבים פרומפט או בונים מערכת של כמה סוכנים, צריך לשאול על כל שלב שלוש שאלות. האם הוא זהה בכל פעם, או תלוי הקשר. האם הוא פועל לפי כללים קבועים, או דורש שיקול דעת. והאם אפשר לשרטט אותו כתרשים זרימה של "אם זה, אז זה", או שמישהו צריך לחשוב.
שלב שעונה על השאלות האלה בצד הקבוע שייך לאוטומציה דטרמיניסטית, כלומר כלים כמו Zapier, Make, n8n או Power Automate: אירוע מסוים מפעיל פעולה מוגדרת, אותו קלט מניב תמיד אותו פלט, והכלי מהיר וזול כי אינו "חושב". שלב שדורש פענוח של טקסט לא מובנה, התמודדות עם עמימות או הכרעה תלוית הקשר, שייך למודל שפה כמו Claude, ChatGPT או Gemini.
מינן משתמשת בשני דימויים: פס ייצור רובוטי לשלבים הקבועים, וחייט שתופר לפי מידה לשלבים שדורשים שיקול דעת. הפעלת מודל על שלב קבוע היא, בלשונה, כמו לשכור חייט כדי שיפעיל מכונת סיכות בפס ייצור.
הדוגמה: מיון חוזים נכנסים
הפוסט מפרק תהליך של קליטת חוזה ספק לשלושה שלבים. בשלב הראשון, בקשה נכנסת דרך טופס ב-Slack, ו-Zapier מעביר את הנתונים למערכת Jira. אין כאן הכרעה, ולכן אין צורך במודל. בשלב השני, Claude בודק את החוזה מול ה-Playbook הפנימי של המחלקה (מסמך העמדות המקובלות במשא ומתן) ומסמן סעיפים חריגים. זה השלב היחיד שבו לדברי הכותבת מוצדק להוציא טוקנים, כי נדרש שיקול דעת. בשלב השלישי, Zapier מחזיר את הסיכום ל-Jira ושולח מייל לבעל העניין העסקי. שוב, בלי מודל.
המסקנה של מינן היא שמתוך שלושת השלבים, רק אחד הוא עבודת מודל. השניים האחרים הם ניתוב נתונים, ואותו ניתוב, לטענתה, נעשה זול ומהיר יותר בכלי אוטומציה בסיסי.
סימני אזהרה
הפוסט מונה כמה דפוסים שמעידים על שימוש מיותר במודל: העברת נתונים פשוטה בין אפליקציות בתגובה לטריגר, למשל עיצוב מחדש של טקסט מ-Jira לפני שליחה ל-Slack; הסתמכות על פרומפט כדי לאכוף בדיקות תקינות שלוגיקה רגילה של טופס יכולה לבצע; ולוחות מחוונים שמדרגים צוותים או עובדים לפי היקף השימוש ב-AI או צריכת הטוקנים.
המסגרת שהכותבת מציעה היא שכבתית: טריגר, בדיקת כן או לא אם השלב קבוע, הפניה לאוטומציה במקרה שכן, הפניה למודל במקרה שלא, ואז חזרה ללוגיקה קבועה לביצוע ולהפצה. ראוי לציין שהפוסט מזכיר גם כלי מסחרי בתמחור לפי משתמש כחלופה לחשבון הטוקנים, ושם מדובר בהמלצה של הכותבת ולא בבדיקה עצמאית.
הקשר רחב יותר
הרעיון אינו חדש לגמרי. כבר בדצמבר 2024 פרסמה Anthropic מדריך בשם Building effective agents, שהמליץ לחפש את הפתרון הפשוט ביותר האפשרי ולהוסיף מורכבות רק כשיש בה צורך. המדריך הבחין בין "workflows", שבהם מודלים וכלים פועלים לאורך מסלולי קוד מוגדרים מראש, לבין סוכנים שמכוונים את עצמם, וציין שמערכות סוכניות מחליפות לעתים קרובות זמן תגובה ועלות בביצועים טובים יותר.
התרומה של הפוסט מ-Legal Engineering 101 היא בתרגום העיקרון לשפה של מחלקה משפטית: מיון, ניתוב והתראות מצד אחד, סקירה מול Playbook מהצד השני. עבור מי שבונה תהליכים במשרד או במחלקה משפטית, המבחן הזה מספק נקודת פתיחה מעשית לשאלה איפה המודל באמת מוסיף ערך, ואיפה מספיק כלל פשוט.