לקרוא לכלים הפסיק להרשים אי שם באמצע 2024. השאלה האמיתית עכשיו היא אם המערכת עושה את זה באופן צפוי, משאירה ראיות ויודעת לעצור.
הערה
לבנות מערכות Agentic שמחזיקות מעמד
עקרונות מעשיים לחוזי כלים, הנדסת הקשר, evals, אישורים וטלמטריה במערכות agentic.
הערה
עקרונות מעשיים לחוזי כלים, הנדסת הקשר, evals, אישורים וטלמטריה במערכות agentic.
לקרוא לכלים הפסיק להרשים אי שם באמצע 2024. השאלה האמיתית עכשיו היא אם המערכת עושה את זה באופן צפוי, משאירה ראיות ויודעת לעצור.
הדרך הכי מהירה לבנות מערכת שבירה היא להתחיל מ-planner משוטט רק כי זה מרגיש מתקדם. צוותים יודעים את זה. בכל זאת מתחילים ככה.
אם הרצף ידוע ברובו, workflow נותן כמעט בחינם דיבאג נקי, latency ועלות שאפשר להסביר, ושטח כשל קטן יותר כשהמודל טועה. Agent אוטונומי שווה רק אחרי שהגרסה מבוססת ה-workflow כבר נוקשה מדי באמת. לפני זה אוטונומיה היא עוד שטח פנים שאפשר לקלקל.
תיעוד ה-Agents של OpenAI עובד כי הוא לא מרומנטז את הכלים. web search, file search, connectors, computer use, shell. כל אלה משטחי ביצוע רגילים. רף האיכות זהה לכל אינטגרציה אחרת.
חוזה שאני סומך עליו: סכמת קלט צרה, מצבי כשל ברורים, הרשאות מפורשות, עיבוד המשך דטרמיניסטי. החוזה הוא מה שסוגר דרכים להיות חכם ברגע הלא נכון. עצם היכולת של מודל לקרוא לכלי לא הופכת אותו לבטוח לקריאה.
הרבה כשלים של agents הם כשלים של retrieval בתחפושת של reasoning.
מערכות עם עוגן במקורות עובדות טוב יותר כשמתייחסים ל-retrieval כשכבת שליטה: מביאים רק את מה שהשלב הנוכחי צריך, מבצעים rerank או סינון לפני generation, שומרים על זהות המסמך לאורך כל הריצה, מאפשרים abstain כשהתמיכה דקה. ב-loop agentic retrieval חלש בתחילת הריצה מרעיל את כל מה שבא אחריו.
שערי אישור לא צריכים להיות בכל מקום. הם צריכים להופיע איפה שהמערכת חוצה גבול שמישהו ייאלץ להתעסק איתו אחר כך.
הרשימה הכנה:
את כל השאר עדיף לאוטומט, ללוג, ולשמור הפיך ככל האפשר.
צוותים רבים אומרים שהם צריכים memory כשבפועל צריכים thread יציב של state וראיות. זה מגיע ממצב הריצה הנוכחי, מהעדפות מתמשכות ששווה למחזר, ומ-artifacts שאפשר לשלוף לפי הצורך (receipts, סיכומים, פלטים קודמים).
המשימה לא לצבור עוד טקסט. אלא להחליט איזה context חי בלולאה כל הזמן, מה נשלף לפי דרישה, מה פג ב-TTL, מה חייב להישאר inspectable.
Blob של שיחה קודמת שאי אפשר לבדוק הופך תוך רבעון למיתולוגיה. אם אי אפשר לבדוק, לפוג או לשחזר אותו מהמקור, הוא כבר מיתולוגיה.
כשמערכת חיה בכמה צעדים, נוגעת בכלים ומסתעפת תחת אי-ודאות, evals הם השכבה שמאפשרת לישון.
החבילה שאני סומך עליה: בדיקות הצלחה למשימה, נכונות קריאות כלים, grounding במקורות, refusals ו-escalations, תקציבי latency ועלות, trace grading כשהאמצע חשוב כמו הסוף. Agent בלי evals הוא workflow שבחרתם לא למדוד.
לוגים של כשלים יש לכולם. פחות מאוד צוותים לוגים את התשובה לשאלה החשובה יותר: למה המערכת חשבה שמותר לה.
מינימום: הכלי שנבחר, הארגומנטים, המסמכים שנשלפו, אירועי policy או guardrails, בקשות לאישור אנושי, צורת התשובה ו-posture. בלי זה דיבאג של incident שבוע אחרי הופך לניחושים עם לוגים בקצוות.
ה-trace שאני רוצה מאפשר למהנדס אחר לענות על שאלה אחת פשוטה:
למה המערכת חשבה שמותר לה לעשות את זה?
צנוע, פחות או יותר בסדר הזה: מסווגים את המשימה, טוענים רק context רלוונטי, בוחרים מתוך סט כלים תחום, מבצעים עם receipts, מריצים checks, עונים, נמנעים או מסלימים.
זאת רוב הסיבה שזה עובד.