آیا گیت‌های شواهد محلی می‌توانند هزینه‌های استنتاج عامل‌ها را کنترل کنند؟

یک توهم ساده در تنظیمات زمان‌بندی (Timeout) می‌تواند کل صف پردازش یک سیستم عملیاتی را متوقف کند. اما مکانیزم «بسته‌شدن در صورت شکست» (Fail-Closed) اجازه نمی‌دهد عامل‌های هوش مصنوعی بر اساس حدس و گمان تصمیماتی بگیرند که منجر به چنین فاجعه‌های سیستمی شود. این رویکرد یادآور استفاده از اسکنرهای Fail-Closed برای جلوگیری از تزریق تنظیمات پنهان است که لایه‌ای از امنیت قطعی را به سیستم‌های خودکار اضافه می‌کند.

به گزارش وب‌سایت dev.to در ۹ سپتامبر ۲۰۲۶، اکثر توسعه‌دهندگان حفاظ‌ها (Guardrails) را به شکل پرامپت یا دستیارهای متنی پیاده می‌کنند. اما پرامپت‌ها صرفاً پیشنهاد هستند و مدل‌ها اغلب آن‌ها را نادیده می‌گیرند. همان‌طور که در تحلیل قبلی ما درباره‌ی هزینه‌های استنتاج اشاره کردیم، ۱٪ از اجراهای عامل‌ها ۴۶٪ از کل هزینه‌ها را می‌بلعند؛ به همین دلیل این رویکرد جدید، بار اثبات را از دوش مدل به دوش سیستم فایل محلی منتقل می‌کند.

تصور کنید یک درب امنیتی دارید که به جای رمز عبور، حتماً باید یک کلید فیزیکی در قفل باشد تا درب باز شود. در این معماری، «کلید» همان یک فایل خاص روی دیسک است. اگر فایل نباشد، فراخوانی مدل هرگز اتفاق نمی‌افتد. این سیستم برخلاف دستیارهای متنی، سخت‌گیر است؛ نبودِ مدرک یعنی خروج سیستم با کد خطا ۲. در اینجا عامل هوش مصنوعی هیچ حق رأیی ندارد.

زمینه‌ی شکست

نیاز به این سیستم از یک شکست واقعی متولد شد: عاملی که یک زمان‌بندی ۳۰ ثانیه‌ای را اختراع کرد چون «استاندارد به نظر می‌رسید»، در حالی که توسعه‌دهنده هرگز چنین چیزی تنظیم نکرده بود. این پیش‌فرضِ «مفید»، باعث شد یک کرون‌جاب (Cron Job) با خودش تداخل پیدا کند و تمام صف پردازش را ببلعد.

هدف این بود که فراخوانی مدل تا زمان وجود شواهد مسدود شود. فلسفه اصلی ساده است: بدون مدرک، خبری از فراخوانی مدل نیست. چرا باید یک حدس را به سیستم بدهیم وقتی می‌توانیم یک بررسی فایل ساده انجام دهیم؟

پنج گیت شواهدی ضروری

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

• گیت طرح‌واره (Schema Gate): فایلی به نام input.schema.json که باید به درستی تحلیل شود و ویژگی additionalProperties در آن حتماً false باشد. این کار مانع می‌شود مدل فیلدهای جدید اختراع کند.
• گیت فیلدهای الزامی (Required-Fields Gate): لیستی در required_fields.txt که دقیقاً مشخص می‌کند عامل اجازه استفاده از کدام کلیدها را دارد.
• گیت محدودیت (Bound Gate): فایلی به نام cost_bound.txt که سقف سخت‌گیرانه برای توکن‌ها و زمان تعیین می‌کند (مثلاً حداکثر ۴۰۰۰ توکن و ۲۰ ثانیه).
• گیت بازگشت (Rollback Gate): یک اسکریپت اجرایی rollback.sh که می‌تواند تغییرات را با یک دستور به حالت اول برگرداند.
• گیت نمونه شکست (Failure-Fixture Gate): فایلی به نام failure.json شامل یک خروجی «بد» شناخته‌شده تا سیستم ثابت کند می‌تواند خطاها را تشخیص داده و رد کند.

مکانیزم بررسی

قلب این سیستم یک اسکریپت بررسی (Checker) مبتنی بر پایتون است. این اسکریپت هرگز با یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — ارتباط برقرار نمی‌کند؛ بلکه فقط تصمیم می‌گیرد که آیا اجازه فراخوانی مدل داده شود یا خیر.

اگر اسکریپت خروجی مدل را بررسی کند و ببیند عاملی فیلدی را اضافه کرده که در شواهد تعریف نشده (مثلاً retry_count)، بلافاصله خطای GATE FAIL صادر کرده و فرآیند را متوقف می‌کند. توسعه‌دهنده تأکید می‌کند که نمی‌توان به پرامپت دوم اعتماد کرد تا مدل عادتش را فراموش کند؛ این فایل گیت است که باید پاسخ منفی دهد.

گردش‌کار پیاده‌سازی

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

این زیرساخت با چند دستور ساده mkdir و printf ساخته می‌شود. برای کسانی که از توکن‌های رایگان یا سرورهای متن‌باز مانند MonkeyCode استفاده می‌کنند، این گیتینگ محلی مانع از هدر رفتن منابع محدود در حلقه‌های شکست‌خورده می‌شود. حتی اگر سرورهای MonkeyCode فردا از دسترس خارج شوند، چک‌لیست محلی شما همچنان کار می‌کند و این یک لایه پشتیبان در برابر تغییرات تامین‌کننده است.

چه زمانی این روش را رها کنیم؟

این یک چارچوب ایمنی عمومی نیست. طبق مستندات، استفاده از این روش برای چت‌های مشتری‌محور، قراردادهای سطح خدمات (SLA) حقوقی یا حلقه‌های پیچیده چند-ابزاری توصیه نمی‌شود. این روش مخصوص سازندگانی است که تکالیف تک‌مرحله‌ای CLI را اجرا می‌کنند و هر فیلد گم‌شده در آن یک شکست بحرانی است.

اگر هر یک از شرایط زیر برقرار است، این روش را رها کنید:

• تصمیم گیت نیاز به ارتباط شبکه (Network I/O) داشته باشد.
• به جای کدهای خروج (Exit Codes)، نیاز به یک داشبورد مدیریتی باشد.
• تکلیف مورد نظر به بیش از یک فراخوانی ابزار نیاز داشته باشد.
• محدودیت سخت‌گیرانه additionalProperties: false برای کار شما بیش از حد شدید باشد.

تحلیل: تغییر مدل اعتماد

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

برای یک توسعه‌دهنده عملیاتی، این یعنی هزینه یک اشتباه از «قطعی شدن سیستم تولید» به یک «کد خروج محلی» تغییر می‌کند. در اینجا با عامل هوش مصنوعی نه به عنوان یک همکار، بلکه به عنوان یک تابع ناپایدار برخورد می‌شود که باید در یک قرارداد سخت‌گیرانه محصور شود. این روش مشکل «پیش‌فرض‌های مفید» را حل می‌کند؛ جایی که مدل‌ها پارامترهایی را اختراع می‌کنند که با محیط واقعی سیستم در تضاد است.

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

گام بعدی شما

• برای اولین تکالیف عامل‌محور خود، یک طرح‌واره JSON سخت‌گیرانه بنویسید و فراخوانی API را تا زمان تایید آن روی دیسک مسدود کنید.
• یک پوشه evidence/ بسازید و فایل rollback.sh را برای هر عملیات حساس تعریف کنید تا ریسک تغییرات ناخواسته حذف شود.
• خروجی‌های مدل را با یک اسکریپت پایتون ساده و بدون استفاده از LLM اعتبارسنجی کنید تا نرخ توهمات در محیط تولید به صفر برسد.

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