سبز بودن گیت کافی نیست: چگونه تأیید و رد اشتباه را پیدا کنیم؟

یک چراغ سبز می‌تواند در دو جهت اشتباه کند: خروجی خراب را تأیید کند یا خروجی سالم را رد کند. اگر فقط تعداد Passهای موفق را بشمارید، نمی‌توانید بفهمید خود گیت واقعاً قابل‌اعتماد است یا نه.

دو خطا که یک چراغ سبز پنهان می‌کند

گیت‌های خودکار معمولاً با یک سؤال ساخته می‌شوند: خروجی قابل قبول است یا نه؟ اما کیفیت خود گیت نیز باید سنجیده شود. اگر خروجی خراب را Pass کند، false pass داریم؛ اگر خروجی سالم را Fail کند، false fail. هر دو خطا می‌توانند هم‌زمان در یک گیت وجود داشته باشند.

در یک رخداد داخلی TekeraLab، ریشهٔ هر دو جهت خطا در یک گیت دوام پیدا و اصلاح شد. جزئیات سیستم عمومی نیست، اما نتیجه قابل تعمیم است: چند Pass موفق، حساسیت و دقت گیت را ثابت نمی‌کند.

ماتریس ۲×۲ بسازید

برای هر اجرای گیت دو واقعیت دارید: وضعیت واقعی خروجی سالم یا خراب است، و تصمیم گیت Pass یا Fail. ترکیب این دو چهار خانه می‌سازد: true pass، true fail، false pass و false fail.

بدون ground truth مستقل نمی‌توانید بفهمید نتیجه در کدام خانه قرار گرفته است. پیش از تنظیم threshold، یک مجموعهٔ کوچک اما برچسب‌خورده بسازید. نمونه‌های سالم باید از منبعی مستقل تأیید شده باشند و نمونه‌های خراب نقص مشخص و قابل بازتولید داشته باشند.

کنترل مثبت و کنترل منفی

کنترل مثبت یک خروجی سالم و ثابت است که گیت باید همیشه Pass کند. کنترل منفی یک خروجی عمداً خراب است که گیت باید همیشه Fail کند. برای هر قاعدهٔ مهم دست‌کم یک جفت کنترل بسازید؛ مثلاً فایل موجود/غایب، پاسخ 200/500، متن کامل/ناقص یا فراخوانی درست/غلط ابزار.

بعد از هر تغییر در prompt، parser، مدل، منبع داده یا threshold هر دو کنترل را اجرا کنید. اگر فقط مسیر موفق را آزمایش کنید، false pass نامرئی می‌ماند؛ اگر فقط خرابی را آزمایش کنید، false fail را نمی‌بینید.

همهٔ خطاها را در یک امتیاز ادغام نکنید

راهنمای Microsoft Agent Framework معیارهایی مانند task adherence، task completion، tool selection و tool call accuracy را جدا می‌کند. این تفکیک مهم است: Agent ممکن است ابزار درست را انتخاب کند اما ورودی غلط بدهد، یا کار را کامل کند ولی محدودیت کاربر را نقض کند.

برای واقعیت‌های قطعی از تست مکانیکی، برای کیفیت باز از rubric محدود، و برای اقدام پرریسک از بازبینی انسان استفاده کنید. جمع‌کردن همه‌چیز در یک امتیاز مبهم، علت خطا را پنهان می‌کند.

منبع رسمی: https://learn.microsoft.com/en-us/agent-framework/agents/evaluation

گیت دوام باید چه چیزی را تضمین کند؟

Durability یعنی تصمیم گیت در برابر restart، retry، cache قدیمی و اجرای دوباره پایدار باشد. ورودی آزمون باید version داشته باشد، نتیجه به evidence ID وصل شود و retry همان تصمیم را بدون ایجاد side effect تکراری بازتولید کند.

پیش از deploy یک regression suite دوطرفه اجرا کنید و پس از deploy همان مجموعه را در محیط واقعی یا shadow اجرا کنید. اگر نرخ false pass یا false fail از آستانه گذشت، گیت نباید مرجع نهایی انتشار باقی بماند.

چک‌لیست عملی بازبینی گیت

شش سؤال بپرسید:

• آیا منبع حقیقت از سیستم مورد ارزیابی مستقل است؟
• آیا هم کنترل سالم و هم کنترل خراب داریم؟
• آیا دلیل هر Pass یا Fail قابل ردیابی است؟
• آیا تغییر مدل، prompt، parser و threshold نسخه‌گذاری می‌شود؟
• آیا retry و restart همان تصمیم را بازتولید می‌کنند؟
• آیا اقدام پرریسک هنوز تأیید انسانی درست را می‌خواهد؟

اگر پاسخ یکی از این‌ها نامشخص است، چراغ سبز مدرک کافی نیست. خود گیت را مثل یک محصول قابل آزمون ببینید.

پاسخ‌های کوتاه

False pass در گیت AI Agent چیست؟

خروجی واقعاً خراب است اما گیت آن را Pass اعلام می‌کند؛ بنابراین نقص وارد مرحلهٔ بعد می‌شود.

False fail چیست؟

خروجی سالم است اما گیت آن را Fail اعلام می‌کند؛ در نتیجه retry، توقف صف و مداخلهٔ انسانی بی‌دلیل افزایش پیدا می‌کند.

گیت ارزیابی AI Agent را چگونه آزمایش کنیم؟

نمونه‌های سالم و خرابِ مستقل و برچسب‌خورده بسازید، کنترل مثبت و منفی را جفت اجرا کنید و نرخ false pass و false fail را جدا اندازه بگیرید.

جمع‌بندی

اعتماد به گیت از تعداد Passها نمی‌آید؛ از دانستن نرخ و علت هر دو خطای false pass و false fail می‌آید. گیت را با کنترل‌های دوطرفه، ground truth مستقل، مدرک قابل ردیابی و آزمون دوام ارزیابی کنید.