הנדסת Harness היא ללא כתובת קבועה
הנדסת Harness אינה מקום בתוך ה-software stack שלך. היא תכונה של הקוד שלך.
אנשים רבים חושבים שה-harness הוא רק wrapper סביב מודל AI. זה לא נכון. ה-harness הוא מה שהופך מודל לשימושי עבור עסקים אמיתיים.
אני משתמש בנוסחה פשוטה: Agent = Model × Harness.
המודל הוא המנוע. ה-harness הוא ההיגוי, הבלמים ומסילות הבטיחות.
אבל הנה הבעיה. המודל צומח ללא הרף. כל גרסה חדשה של מודל סופגת חלקים מה-harness.
- מודלים של reasoning מטפלים כעת בלוגיקת chain-of-thought.
- מודלים טובים יותר מטפלים בשימוש ב-tools באופן טבעי.
- חלונות context ארוכים מחליפים מערכות זיכרון ישנות.
אם המודל "אוכל" את ה-harness, מה נשאר לך לבנות?
החלקים שיתמוססו הם המכניקה. הלופים (loops), הניסיונות החוזרים (retries) ותפירת הזיכרון (memory stitching) יהפכו למוצרי בסיס (commodities). אל תהמר על הקריירה שלך על בניית "אינסטלציה" (plumbing).
החלקים שיישארו הם ה-specification וה-verification.
- Specification: עליך להגדיר מה ה-agent מורשה לעשות. מודל לא יכול לדעת את מדיניות ההחזרים הספציפית שלך או את רמת הסיכון שלך. זה חי בתוך הקוד שלך.
- Verification: עליך להוכיח שה-agent נשאר בתוך הכללים שלך. מודל לא יכול לשפוט את עצמו באופן אמין. אתה זקוק לשכבה חיצונית שתבדוק את העבודה.
חשבו על agent להחזרים כספיים.
אם תכניסו את מגבלת ההחזר בתוך prompt, משתמש יכול להוליך את המודל שולל. אם תכניסו את המגבלה בתוך if-statement בקוד שלכם, המודל לא יכול להתווכח איתה.
ה-if-statement הזה הוא הנדסת harness.
הנדסת harness עוסקת בשני דברים:
- הגדרת המעטפת (envelope) של ההתנהגות המותרת.
- הוכחה שה-agent נשאר בתוכה.
המודל הוא הצמח שאתם שולטים בו. ה-specification הוא היעד שלכם. ה-harness הוא הבקר (controller). ה-evaluations הם המשוב (feedback).
הכלים והמכניקה ישתנו בכל חודש. המשמעת של specification ו-verification לא תשתנה.
הפסיקו לבנות "אינסטלציה". התחילו לבנות אילוצים (constraints) והוכחות (proofs).
Source: https://dev.to/saurav_bhattacharya/harness-engineering-has-no-fixed-address-2m7a
Optional learning community: https://t.me/GyaanSetuAi