تفکیک خطای شبکه از خطای مدل؛ راهکاری برای توقف اصلاحات اشتباه در عامل‌های AI

تصور کنید یک برنامه‌نویس هستید که مدل خود را در محیط محلی تست کرده و نتایج سبز و موفقیت‌آمیزی گرفته است، اما به محض انتقال به سرور، همه چیز قرمز می‌شود. این همان لحظه‌ای است که متوجه می‌شوید «تابلوی امتیازات در حال دروغ گفتن است»، آن هم نه به شکلی نامحسوس. این تجربه برای توسعه‌دهنده‌ای رخ داد که از MonkeyCode استفاده می‌کرد و دریافت ارزیابی محلی «سبز» برای یک عامل فراخوانی ابزار (tool-calling agent)، به محض انتقال به یک سرور راه دور، با وجود استفاده از مدلی کاملاً یکسان، به «قرمز» تبدیل شد.

یک تحلیل فنی فاش کرد که اکثر داشبوردهای ارزیابی عامل‌ها، خطاهای DNS، تایم‌اوت‌های HTTP و خطاهای ۵xx را در یک بیت واحد به نام «شکست» (Fail) ادغام می‌کنند. این یعنی ما در واقع نمرهٔ یک دانش‌آموز را بر اساس این می‌سنجیم که آیا اتوبوسش به موقع به مدرسه رسیده یا نه، نه بر اساس توانایی او در حل مسائل جبر. همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تفکیک لایه‌های زیرساخت از لایه‌های منطقی برای رسیدن به نتایج قابل‌اعتماد ضروری است. این چالش با برخی باورهای غلط رایج در ارزیابی مدل‌ها همسو است که در آن تست‌های سبز لزوماً به معنای عملکرد صحیح مدل نیستند.

این بحران زمانی رخ می‌دهد که توسعه‌دهندگان از نمونه‌های اولیه محلی به خط لوله‌های CI/CD، رانرهای اشتراکی یا سرورهای رایگان راه دور نقل مکان می‌کنند. در محیط محلی، رابط Loopback هرگز «استراحت» نمی‌کند و همیشه در دسترس است، اما در دنیای واقعی، این رابط با شبکه‌های واقعی جایگزین می‌شود. وقتی یک دست‌دادن (Handshake) متوقف می‌شود یا یک سوکت می‌میرد، سیستم آن را به عنوان یک پسرفت (Regression) در مدل ثبت می‌کند. در حالی که در واقعیت، مدل ممکن است هنوز در حال تفکر باشد، اما کلاینت HTTP — مانند httpx — صرفاً پس از ۱۰ ثانیه تسلیم شده و ارتباط را قطع می‌کند.

آلودگی در ارزیابی عامل‌ها

ارزیابی‌های عامل (Agent) — شبیه دستیاری که باید کارهای مختلفی را برای شما انجام دهد — اغلب سه نوع شکست متفاوت را در یک عدد صحیح غم‌انگیز ترکیب می‌کنند. این آلودگی داده‌ها خسته‌کننده است، و دقیقاً به همین دلیل است که در بسیاری از سیستم‌ها رایج شده است. سه سناریوی ممکن عبارتند از: مدل ابزار اشتباه را انتخاب می‌کند، ابزار خروجی نامربوط یا «زباله» برمی‌گرداند، یا لایه انتقال (Transport) ناپدید می‌شود. تنها دو مورد اول باید در نمره کیفیت مدل اثر بگذارند؛ مورد سوم متعلق به ستون «پایداری» (Reliability) است. اگر این تفکیک را نادیده بگیرید، سعی خواهید کرد مدلی را «اصلاح» کنید که هرگز خراب نبوده است. برای مقابله با چنین نویزهایی، استفاده از مطالعات A/A می‌تواند به تیم‌ها کمک کند تا تفاوت بین نویزهای تصادفی و بهبودهای واقعی را تشخیص دهند.

تفکیک سه‌گانه شکست‌ها

برای حل این مشکل، نویسنده یک طبقه‌بندی‌کننده (Classifier) پیشنهاد می‌کند که هر آزمایش را به چهار دسته مجزا تقسیم می‌کند. این کار مانع از آن می‌شود که «نرخ موفقیت» به جای اندازه‌گیری هوش، به معیاری برای سنجش وضعیت هواشناسی شبکه تبدیل شود:

• موفق (Pass): مدل یک فراخوانی ابزار با ساختار درست ارسال کرده که با پارامترهای مورد انتظار مطابقت دارد. در آزمایش ارائه شده، این به معنای فراخوانی ابزار add_two با آرگومان‌های {"a": 17, "b": 25} بود. تکرار حاصل‌جمع در پیام نهایی به عنوان «نمره اضافی» در نظر گرفته می‌شود، نه معیار اصلی نمره.
• شکست مدل (Model Fail): بایت‌ها با موفقیت رسیدند، اما عامل «لغزید»؛ یعنی ابزار اشتباه را انتخاب کرد یا آرگومان‌های غلط ارائه داد (مثلاً ارسال رشته متنی "seventeen" به جای عدد صحیح ۱۷). این یک خطای واقعی در مدل است.
• شکست انتقال (Transport Fail): سیم شبکه چشمک زد و قطع شد. این دسته شامل تایم‌اوت‌ها، مشکلات DNS، خطاهای ۵xx، خطای ۴۰۸ (Request Timeout) یا خطای ۴۲۹ (Too Many Requests) است. این‌ها شکست‌های انتقال هستند زیرا پیش از آنکه منطق مدل حتی تست شود، رخ می‌دهند.
• شکست پروتکل (Protocol Fail): پاسخ رسید اما غیرقابل تجزیه (Unparseable) بود. این شامل بدنه‌های خالی، نبود فیلد choices در JSON، یا آرگومان‌هایی است که JSON معتبری نیستند. این شکست در «شکل» پاسخ است، نه در «مغز» مدل.

آزمایش «سیم» در برابر «مغز»

برای اثبات این ادعا، آزمایشی در مقیاس کوچک با ابزاری به نام add_two طراحی شد که وظیفه‌اش جمع دو عدد صحیح و بازگرداندن حاصل است. تکلیف را عمداً کوچک نگه داشتند: یک نوبت کاربر، یک ابزار مجاز، و پرامپتی که از مدل می‌خواست ۱۷ + ۲۵ را محاسبه کند و «فقط» حاصل را بگوید. هر چیز دیگری شکست مدل محسوب می‌شد؛ اما تایم‌اوت‌ها، DNS، خطاهای ۵xx، بدنه‌های خالی و JSONهایی که هرگز ظاهر نشدند، شکست انتقال بودند.

با متصل کردن همین سیستم ارزیابی به یک استاب محلی (LOCAL_BASE) و یک سرور راه دور (REMOTE_BASE)، تفاوت‌ها کاملاً آشکار شد. نویسنده برای بخش راه دور از MonkeyCode استفاده کرد و دسترسی رایگان به مدل و گزینه سرور آن را به عنوان یک لایه تسهیل‌کننده برای داشتن یک نقطه انتهایی (Endpoint) قابل دسترس و مسیر تولید ارزان در نظر گرفت. این تنظیمات به عنوان یک نقطه دسترسی استفاده شد، نه به عنوان تعهدی درباره سخت‌افزار، سهمیه (Quota)، پایداری یا سرعت.

جزئیات پیاده‌سازی

برای دستیابی به این تفکیک، نویسنده یک سیستم ارزیابی (eval_wire.py) توسعه داد که با «سیم شبکه» به عنوان یک متغیر برخورد می‌کند. این تنظیمات مستلزم ثابت نگه داشتن پرامپت و طرحواره (Schema) ابزار است تا اطمینان حاصل شود که تنها متغیر تغییر یافته، لایه انتقال است.

• طرحواره ابزار: ابزار add_two به عنوان شیئی تعریف شده که به دو عدد صحیح a و b نیاز دارد.
• پرامپت: "Use add_two to compute 17 + 25. Then say only the sum."
• اجرا: سیستم ارزیابی تعداد EVAL_N آزمایش (در مثال ۲۰ مورد) را روی هر دو نقطه انتهایی با استفاده از httpx.Client و یک تایم‌اوت قابل تنظیم EVAL_TIMEOUT_S (تنظیم شده روی ۱۲ ثانیه) اجرا می‌کند.
• منطق طبقه‌بندی: تابع classify ابتدا صراحتاً برای پاسخ‌های timed_out یا None بررسی می‌کند تا transport_fail را فعال کند. سپس کدهای وضعیت >= ۵۰۰، ۴۰۸ یا ۴۲۹ را برای شکست انتقال، و کدهای وضعیت >= ۴۰۰ را برای شکست پروتکل بررسی می‌کند.

طبق گزارش، یک داشبورد تنبل ممکن است دقت سرور راه دور را ۵۵٪ نشان دهد. اما وقتی دسته‌ها تفکیک شوند، داده‌ها داستان متفاوتی را روایت می‌کنند:

• موفق: ۵۵.۰٪
• شکست مدل: ۱۵.۰٪
• شکست انتقال: ۲۵.۰٪
• شکست پروتکل: ۵.۰٪

وقتی دسته‌ها جدا می‌شوند، مشخص می‌شود که یک چهارم درد و رنج توسعه‌دهنده مربوط به «سیم» است. شکست واقعی مدل تنها ۱۵٪ است، که این موضوع بحثی کاملاً متفاوت از ادعای «مدل راه دور بد است» ایجاد می‌کند. این نشان می‌دهد که یک فایل ارزیابی یکسان، با وجود یک «ناظر بالغ» در اتاق، نتیجه‌گیری را کاملاً تغییر می‌دهد.

نقش استاب محلی (Local Stub)

یک بخش حیاتی در این متدولوژی، استفاده از یک استاب محلی (Local Stub) است؛ سروری جعلی (ساخته شده با FastAPI) که همیشه فراخوانی ابزار درست را ارسال می‌کند. این یک «صفحه کنترل» است، نه یک «مغز». از این ابزار برای کالیبره کردن طبقه‌بندی‌کننده استفاده می‌شود، نه برای تست مدل.

اگر نرخ موفقیت محلی در برابر یک استاب کامل حدود ۱۰۰٪ نباشد، باگ در تجزیه‌کننده (Parser) است، نه در مدل. این کالیبراسیون تضمین می‌کند که توسعه‌دهنده به دنبال ارواح در پرامپت نگردد، در حالی که مشکل واقعی یک استخراج‌کننده JSON خراب است. همان‌طور که نویسنده اشاره می‌کند، ارسال یک باگ در پارسر که در نمودارها شبیه به یک مشکل مدل به نظر می‌رسد، اشتباهی است که خودش شخصاً مرتکب شده است. اگر استاب محلی شکست بخورد، توسعه‌دهنده اجازه ندارد آن روز درباره مدل‌ها صحبت کند.

اندازه‌گیری TTFB و تایم‌اوت‌ها

این تحلیل فراتر رفته و بین زمان تا نخستین توکن (TTFB) و زمان کل درخواست تمایز قائل می‌شود. این یک برش حیاتی است که بسیاری از توسعه‌دهندگان نادیده می‌گیرند:

• انفجار TTFB: اگر TTFB به شدت افزایش یابد و بدنه پاسخ هرگز نرسد، این یک فراخوانی ابزار بد نیست. این یک شروع سرد (Cold Start)، یک صف انتظار، یک پروکسی یا مشکلی مربوط به تعطیلات آخر هفته است. این مورد باید در یک تیکت مسیریابی (Routing) ثبت شود.
• خطای منطقی: اگر TTFB مناسب باشد اما آرگومان‌ها به صورت {"a": "seventeen"} باشند، این یک شکست واقعی مدل است و باید در یک Diff پرامپت بررسی شود.

تغییر تنظیمات تایم‌اوت — که نویسنده آن را «چاقو» می‌نامد — نمره را بدون دست زدن به وزن‌های مدل تغییر می‌دهد. نویسنده EVAL_TIMEOUT_S را در لاگ‌ها نگه می‌دارد زیرا یک چاقوی ۱۲ ثانیه‌ای و یک چاقوی ۶۰ ثانیه‌ای، یک میوه یکسان را نمی‌برند. اگر با تغییر تایم‌اوت، نرخ transport_fail جابه‌جا شود اما model_fail ثابت بماند، توسعه‌دهنده صرفاً در حال نگه داشتن یک دماسنج شبکه است.

خطر سرورهای رایگان

در حالی که سرورهای رایگان راه دور برای تست‌های دود (Smoke Tests)، بررسی‌های طرحواره و تست‌های شبانه‌روزی برای یافتن باگ‌های پارسر مفید هستند، اما برای تصمیم‌گیری‌های نهایی عرضه محصول، «دادگاه‌های عالیِ نامعتبر»ی هستند. این سرورها فاقد تضمین‌های p99، تضمین‌های اقامت داده‌ها (Data Residency) یا داستان‌های پایداری هستند.

نویسنده هشدار می‌دهد که دسترسی رایگان به مدل را به عنوان یک «قاضی طلایی پنهان» در نظر نگیرید. تولید ارزان یک هدیه برای تکرار (Iteration) است، اما نباید ساعت ملاک برای تصمیم‌گیری عرضه باشد. اگر توسعه‌دهنده‌ای به مقاله‌ای نیاز دارد که وانمود کند شبکه در اتاق نبوده است، باید مدل را محلی اجرا کند یا روی سروری اجرا کند که می‌تواند به آن SSH بزند. متدولوژی نکته اصلی است؛ منطق این مقاله فارغ از اینکه کدام URL راه دور جایگزین شود، پابرجا می‌ماند.

چارچوبی برای تصمیم‌گیری

این تغییر در دیدگاه، نحوه تکرار و بهبود توسعه‌دهندگان را تغییر می‌دهد. به جای بازنویسی پرامپت به دلیل افت ارزیابی راه دور، آن‌ها می‌توانند از منطق زیر استفاده کنند:

• اگر transport_fail پایین و model_fail پایدار است: مسیر راه دور برای تست‌های دود (Smoke Testing) به اندازه کافی خوب است.
• اگر transport_fail با تغییر تایم‌اوت جابه‌جا می‌شود اما model_fail ثابت می‌ماند: شما در حال اندازه‌گیری شبکه هستید، نه مدل.
• اگر protocol_fail جهش می‌کند: شکل پاسخ اشتباه است و هیچ مقدار «شعر در پرامپت» (Prompt Poetry) کمکی نخواهد کرد.
• اگر استاب محلی پاس تمیزی نمی‌گیرد: باگ در پارسر است و مدل بی‌ربط است.

برای کسانی که این سیستم را پیاده می‌کنند، عادت به استفاده از طبقه‌بندی‌کننده مهم‌تر از سرور مورد استفاده است. چه روی یک لپ‌تاپ اجرا شود و چه روی یک باکس ابری پیشرفته، تفکیک بین سیم، مغز و پارسر تنها راه اجتناب از «تئاتر» در بنچ‌مارک‌های هوش مصنوعی است. اگر این دسته‌ها وجود نداشته باشند، درصدها صرفاً یک «حلقه تغییر رنگ» (Mood Ring) با مقداری YAML اضافی هستند. هدف، داشتن طبقه‌بندی‌کننده‌ای است که بتوان آن را دوشنبه دوباره اجرا کرد بدون اینکه نیاز باشد با یک اسکرین‌شات بحث کرد.

گام بعدی شما

• در داشبوردهای ارزیابی خود، دسته‌بندی «Fail» را به چهار دسته Pass، Model Fail، Transport Fail و Protocol Fail تفکیک کنید.
• پیش از هر تغییر در پرامپت، یک استاب محلی (Local Stub) بسازید تا مطمئن شوید باگ در لایه Parser نیست.
• زمان TTFB را از زمان کل درخواست جدا کنید تا بفهمید مشکل از کندی زیرساخت است یا استدلال مدل.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.