בניית playground לסוכן AI לפני מעבר לסביבת ייצור (Production)

סוכן קוד הריץ פעם סקריפט ניקוי על מה שחשב שהוא מסד נתונים של סביבת בדיקות (staging). למעשה, זה היה מסד נתונים של סביבת ייצור (production). הסוכן מחק ארבעה חודשי הזמנות לקוחות כי הוא עשה בדיוק את מה שנאמר לו, אך עם הרשאות שגויות.

הכישלון הזה אינו סיבה להימנע מסוכנים. הוא סיבה לבנות playground.

לא הייתם נותנים למהנדס חדש גישה למסד נתונים של סביבת ייצור ביום הראשון שלו. אתם נותנים לו סביבת staging, גישה לקריאה בלבד, ומשימות תחת פיקוח. סוכנים זקוקים לאותו תהליך קליטה (onboarding). הם יכולים לבצע אלף פעולות בדקה, לכן המחיר של דילוג על playground הוא גבוה פי אלף.

playground אמיתי חייב לבצע שלושה דברים:

  • לאפשר לסוכן להריץ את לולאת קבלת ההחלטות המלאה שלו.
  • למנוע מכל ההשפעות המשניות (side effects) להגיע למערכות אמיתיות.
  • לתעד הכל לצורך בדיקה.

אל תבדקו רק את ה-prompt. בדיקת prompt היא שאילת שאלה וקריאת תשובה. ההתנהגות של סוכן היא רצף של קריאות לכלים (tool calls). הכישלונות האמיתיים קורים באמצע לולאה, כאשר כלי מחזיר נתונים לא צפויים.

אתם לא צריכים לבצע sandboxing למודל. אתם צריכים לבצע sandboxing למבצע (executor).

צרו נקודת הפרדה (seam) במקום שבו קריאות לכלים הופכות לפעולות. השתמשו ב-playground executor שמשתמש ב-mocks במקום ב-executor חי. לולאת הסוכן לא צריכה להבחין בהבדל. אם הסוכן שלכם קורא ישירות ללקוח מסד נתונים (database client), אין לכם נקודת הפרדה ואין לכם בטיחות.

בדקו שלושה תחומים ספציפיים:

  • התנהגות: האם הסוכן בוחר בכלי הנכון ובסדר הנכון?
  • קריאות לכלים: האם הארגומנטים נכונים ונמצאים בטווח בטוח?
  • מצבי כישלון: מה קורה כש-API חווה timeout או מחזיר נתונים לא תקינים (garbage)?

mock שתמיד מצליח לא מלמד את הסוכן דבר. ה-playground שלכם חייב לאפשר לכם להזריק כישלונות כמו network timeouts או נתונים לא תקינים. כך תוכלו לראות אם הסוכן מנסה שוב בצורה הגיונית או מתחיל להזות (hallucinating).

אם הסוכן שלכם מריץ קוד, אתם זקוקים לבידוד חזק. השתמשו ב-microVMs עבור קוד לא מהימן. אל תתחילו עם containers פשוטים רק בגלל שהם קלים לשימוש. הגדרה קלה עלולה להוביל לתקרית אבטחה מאסיבית.

זכרו שסוכנים הם לא דטרמיניסטיים. בדיקה שעוברת פעם אחת לא אומרת שהסוכן אמין. עליכם להריץ את אותה משימה מספר פעמים. אם סוכן עובר 7 מתוך 10 פעמים, הוא ייכשל בערך עבור 30% מהמשתמשים האמיתיים שלכם. עקביות היא המדד החשוב ביותר שלכם.

לבסוף, הגנו מפני פלטי כלים עוינים (adversarial tool outputs). סוכן מתייחס לנתוני הכלים כהוראות. משתמש זדוני יכול להזריק לתוך מסד נתונים prompt injection כדי להטות את הסוכן. בדקו את הסוכן שלכם על ידי הזנת payloads עוינים בתוך ה-playground.

בנו מסלול התקדמות, לא כפתור השקה:

  • התחילו עם mocks ו-sandboxing מלא.
  • בדקו עקביות לאורך הרצות רבות.
  • בדקו מול קלטים עוינים.
  • עברו למצב dry-run מול נתונים דמויי סביבת ייצור.
  • רק אז העניקו גישה מוגבלת (scoped), מבוקרת (gated) ומנוטרת.

תנו לסוכן שלכם מקום לטעות בו בזול. כך הוא יוכל להיות צודק במקומות שבהם זה באמת חשוב.

Source: https://dev.to/nazar_boyko/building-an-ai-agent-playground-before-giving-it-production-access-4glh

Optional learning community: https://t.me/GyaanSetuAi