החלק הקשה ביותר בסוכן AI הוא ה-Unhappy Path
רוב ההדגמות של סוכני AI מציגות תרחיש מושלם. שאלה ברורה מובילה לתשובה מסודרת. כולם מוחאים כפיים.
הנדסה אמיתית קורה כשדברים נשברים.
מה קורה כש-API קורס? מה קורה כשסוכן נכנס ללולאה אינסופית ומרוקן לך את כרטיס האשראי? מה קורה כשאין לסוכן נתונים, אך הוא בכל זאת כותב דוח שנראה אמיתי?
בניתי את BioAgent כדי לפתור את הבעיות הללו בתחום הגנומיקה. זהו אנליסט אוטונומי ששואב נתונים, מחפש ב-PubMed וכותב דוחות קליניים.
השתמשתי ב-LangGraph וב-Claude כדי לבנות אותו. הנה מה שלמדתי על בנייה מתוך התמודדות עם כשלים.
הגבילו כל לולאה לסוכן חייב להיות מכסה ניסיונות חוזרים (retry limit) קשיח. אם הסוכן שלכם קורא ל-APIs בתשלום, לולאה היא סיכון פיננסי. הגבלה עובדת רק אם אתם מגדילים את המונה בכל שלב. אם תשכחו את שורת הקוד האחת הזו, הסוכן ימשיך בלולאה עד שהמערכת תקרוס.
בדקו את הכשל, לא את ההצלחה ה-Happy Path תמיד עובד במהלך הפיתוח. עליכם לאלץ את התלויות (dependencies) שלכם להיכשל במהלך הבדיקות. כתבו בדיקות שמוודאות שהסוכן מפגין התדרדרות הדרגתית (degrades gracefully) במקום להיכנס ללולאה כאשר API אינו זמין.
מנעו שטויות בביטחון עצמי הסכנה הגדולה ביותר היא לא קריסה. הסכנה היא דוח שנראה מקצועי אך מכיל נתונים מזויפים. אל תסתמכו על הנחיות ב-prompt כדי לעצור הזיות (hallucinations). השתמשו בבדיקות כדי להבטיח שהסוכן לעולם לא ימציא מדדים.
הבטיחו שהתוצאות מבוססות על עובדות (Grounding) שליפה (Retrieval) היא שימושית רק אם הטקסט מגיע לכותב. גיליתי שמעבר של מזהים (IDs) בלבד במקום תקצירים (abstracts) מלאים גרם למודל להמציא רלוונטיות. עליכם להעביר את הטקסט הממשי למודל כדי להבטיח שהדוח יישאר מבוסס על עובדות.
כלל ב-prompt הוא רק תקווה. כלל בבדיקה הוא הבטחה.
בנו עבור ה-Unhappy Path. זה החלק שבאמת קובע.
מקור: https://dev.to/gbadedata/the-hardest-part-of-an-autonomous-ai-agent-is-the-unhappy-path-3p2c
קהילת למידה אופציונלית: https://t.me/GyaanSetuAi