מה בעצם עושה מהנדס AI במודל forward-deployed?
Forward-deployed זה לעבוד בתוך הריפו ובסטאק שלכם, לא מערוץ Slack חיצוני. אני כותב ושולח את הקוד שסוגר את הפער בין דמו עובד לבין מערכת שאפשר להשאיר רצה. רוב הזמן זה retrieval grounding, כיסוי evals, גבולות של כלים ומסלול rollback. מה שמתקבל בסוף - commits ו-runbooks, לא מצגות.
מתי תזמור מולטי-אייג׳נט באמת נחוץ ומתי הוא over-engineering?
שווה כשמשימה חוצה כמה משטחי כלים, ארוכה מקונטקסט אחד של מודל או דורשת audit trail חתום לכל צעד. over-engineering כשסוכן יחיד מוקפד עם גבולות כלים נוקשים כבר מספיק. Bernstein בנוי לתרחיש הראשון. אם ה-workflow שלכם הוא פרומפט אחד וכלי אחד, אתם לא צריכים אורקסטרטור, אתם צריכים evals טובים יותר.
למה retrieval grounding נופל בפרודקשן גם כשבדמו הכל נראה תקין?
שאילתות דמו ידידותיות, תעבורת פרודקשן לא. ה-retriever מחזיר בשקט קונטקסט שנשמע סביר אבל שגוי, המודל כותב סביבו טקסט בטוח, ושום דבר בסטאק לא תופס את זה. מה שאני בדרך כלל מתקן: hybrid retrieval, תבנית תשובה עם ציטוטים ברמת עמוד, ו-eval set עם שאילתות יריב שמקבע את המצבים שבאמת נופלים אצלכם.
מתי תזמור סוכנים on-prem באמת קריטי?
כשהעומס נוגע במידע רגולטורי, ברשת סגורה או בשער LLM בצד הלקוח שלא אפשר לעקוף. Bernstein מחזיק state בקבצים, scheduling דטרמיניסטי וסקופ הרשאות לכל סוכן - הכל בתוך הפרימטר שלכם. אין קריאות יוצאות שלא אישרתם. אותו אורקסטרטור רץ על לפטופ, ב-CI וב-VM מוקשח - וזה מה ש-compliance בדרך כלל רוצה לראות.
איך נראית eval-driven delivery בפועל?
כל שינוי נשלח עם gold set של קלטים, judge דטרמיניסטי ו-gate שנופל סגור ב-CI. מצבי כשל חדשים נתפסים כ-eval cases לפני שהתיקון נכנס, כך שהרגרסיה לא חוזרת בשקט. האורקסטרטור מתעד כל צעד של הסוכן, וכשמטריקה זזה אפשר לשחזר את הריצה המדויקת שהזיזה אותה. בלי releases לפי תחושה.