תפסיקו להריץ בדיקות ביצועים (benchmarks) חדשות למודלים ותתחילו לצפות בסוכן שלכם מנסה לבטל מנוי. הפער בין שתי הפעילויות הללו הוא המקום שבו מערכות ייצור (production) קורסות. בדיקה של שלב אחד (single-turn test) יכולה לומר לכם אם התגובה נשמעת נעימה. היא לא יכולה לומר לכם אם הסוכן הרגע זיכה לקוח לא נכון, נכנס ללולאה של ארבע עשרה פעמים מול API של לוח שנה, או החליט לדלג לחלוטין על בדיקת ההונאה. טקסט הוא הדבר הכי פחות מסוכן שהסוכן מייצר. הסיכונים האמיתיים מסתתרים בכלים שהוא נוגע בהם, בנתונים שהוא משנה (mutates), וברגעים שבהם הוא היה צריך לבקש עזרה אך המשיך הלאה.
למה בדיקות ביצועים מבוססות טקסט נכשלות בסביבת ייצור
ציונים גבוהים בבדיקות ביצועים סטנדרטיות הפכו לצורה מטעה של נחמה. סוכן שכותב פרוזה אלגנטית עשוי עדיין להוות סיכון תפעולי. כשמערכת שלכם קובעת תורים, עורכת רשומות במסד נתונים או פותחת פניות תמיכה, הטקסט שנוצר הוא רק המעטפת הנראית לעין של תהליך העבודה (workflow). מתחת לפני השטח, הסוכן מקבל החלטות קונקרטיות לגבי איזה endpoint לפנות, איזה payload לשלוח ומתי לעצור. הוא יכול להגיע לראש טבלת המובילים של הבנת הנקרא, תוך שהוא גורם לכם להפסיד כסף על ידי כפל הזמנות למשאבים, שינוי השורה הלא נכונה או דליפת מצב (state) רגיש לקובץ לוג. אתם צריכים לאמת את המכניקה של העבודה, לא רק את הגימור של הפלט. אם סוכן יכול לקבל ציון גבוה במבחן QA לא מקוון ועדיין לגרום לכשל בתהליך העבודה שלכם על ידי לולאות או שימוש לא נכון בכלי, אז ההערכה שלכם בוחנת את האותות הלא נכונים.
מיפוי חמש התלויות
הצוות ב-Van Data Team מתחיל כל הערכה במיפוי של חמש נקודות בקרה ספציפיות. זה משנה את השאלה לחלוטין. אתם מפסיקים לשאול אם מודל אחד חכם יותר מאחר. אתם מתחילים לשאול אם הסוכן יכול באמת לסיים משימת ייצור תחת האילוצים האמיתיים שלכם.
תוצאות עסקיות. הגדירו מה המשמעות של "בוצע" במונחים של דולרים והשפעה על הלקוח. משימה אינה הושלמה רק כי הסוכן הפיק סיכום. היא הושלמה כאשר רשומת המלאי מדויקת, התור מאושר והלקוח קיבל מספר מעקב תקף.
מצב משתנה (Mutable state). דעו בדיוק למה הסוכן רשאי לשנות. אילו טבלאות, אילו סטטוסים, אילו דגלים בחשבון? אם הסוכן יכול לבצע זיכויים, לשנות מועדי עבודה או לעדכן כתובות לחיוב, אתם צריכים למפות כל שדה שהוא נוגע בו.
הרשאות כלים. היו מפורשים לגבי אילו API endpoints ופונקציות נמצאים במסגרת העבודה. סוכן עם גישה לכלי חיפוש, כלי כתיבה וכלי התראות יערבב ביניהם אם הגבולות יהיו מעור
Install release gates to block bad model upgrades. A new model is only an upgrade if it improves your specific outcomes. If it hallucinates tool arguments more often, increases latency, or introduces new safety risks, it does not ship. The gate keeps production stable even when the base model vendor ships a new version.
Runtime Grading: Watching the Agent Work
Anthropic has been pushing the industry to move beyond offline tests toward runtime grading. Instead of judging a transcript after the fact, runtime grading lets a system judge the agent's work while the task is still in flight. This creates a chance to catch errors before they harden into real problems.
Adding a grader costs tokens and latency. You cannot afford to grade every tiny step. The placement of each grader is a design decision. Put them where the mistakes are expensive. The most valuable checkpoints sit just before committing a state change to a database, just before capturing a payment, and just before sending a message to a customer. These are the moments where a bad decision becomes an irreversible action.
Watch out for a specific blind spot. If the same model performs the work and also grades the work, it may miss the same mistakes. The reasoning that produced an error can easily rationalize that error away during review. For high-impact tasks, keep human review inside the loop. Let people validate the grader's own judgment, especially when money or customer trust is on the line.
The goal here is operational control. Connect your incident data, your task rubrics, and your runtime traces into one feedback cycle. Evaluate the whole path: the plan, the tool use, the recovery behavior, and the final result. Use offline tests to catch known, reproducible errors before release. Use runtime traces to find the new failures you did not anticipate. Use human review to discover where your rubrics are naive and need tightening.
So ask yourself: where would you put a runtime grader in your workflow? Before a tool call, after a tool call, or only before a risky change? Most teams start too broad, grading everything, and then grind to a halt under the cost. Start narrow. Pick the one action that would hurt the most if it went wrong. Put a grader there first.
Start With One Expensive Mistake
Operational evaluation is not a research exercise. It is a way to sleep better once the agent is live. You do not need a perfect framework on day one. You need a single, well-defined workflow, a rubric written in plain business terms, and a grader placed at the exact moment where an error becomes expensive. Get that right, and you have a foundation you can actually trust.
If you want to dig deeper into agent evaluation and runtime grading with a community of practitioners, you can find the GyaanSetu learning community at https://t.me/GyaanSetuAi.