تصور کنید در یک سیستم مالی مربوط به صنعت گیمینگ، یک نمای On-call نشان می‌دهد که ۱۸٬۴۲۰ فاکتور تأمین‌کننده دریافت شده است، اما تنها ۱۸٬۴۱۷ ردیف در پایگاه داده نوشته شده‌اند. این سه رکورد گمشده — که پس از شکست‌های مکرر در اعتبارسنجی گیر کرده‌اند — تفاوت بین یک بسته‌بندی مالی موفق و یک شکست سیستمی است. برای تیم‌هایی که از OpenAI، Claude یا Gemini برای برچسب‌گذاری فاکتورها استفاده می‌کنند، معیار واقعی موفقیت سرعت توکن‌ها نیست، بلکه نرخ رکوردهایی است که هم از فیلتر ساختاری و هم از فیلتر صحت معنایی عبور می‌کنند. یک کد ارز گمشده یا یک کلاس هزینه ابداعی توسط مدل، می‌تواند فرآیند بستن حساب‌های مالی را به همان اندازه یک سرور از کار افتاده، مسدود کند.
این چالش عملیاتی دقیقاً زمانی رخ می‌دهد که سازمان‌ها از رابط‌های سادهٔ چت به سمت خط‌لوله‌های (Pipelines) دادهٔ سخت‌گیرانه حرکت می‌کنند. همان‌طور که در تحلیل قبلی ما درباره‌ی لایه‌های ارکستراسیون در Claude Code اشاره کردیم، تمرکز اکنون از «نحوه تفکر عامل‌ها» به «پایداری خروجی داده‌ها» تغییر کرده است تا پایگاه‌های داده قدیمی بتوانند آن‌ها را جذب کنند. قانون عملیاتی در اینجا صریح و بی‌رحمانه است: هر خروجی بدشکل (Malformed)، یک شغل شکست‌خورده است، حتی اگر مدل متنی بسیار روان و خوش‌ساخت تولید کرده باشد. این تضاد بین روانی متن و دقت ساختاری، یادآور خطاهای زیرساختی است که اغلب در بنچمارک‌های کدنویسی نادیده گرفته می‌شوند و باعث ایجاد تصویری خوش‌بینانه اما گمراه‌کننده از توانایی مدل‌ها می‌شوند.
به نقل از راهنمای عملی منتشر شده در ۱۱ اکتبر ۲۰۲۶، نویسنده استدلال می‌کند که اکثر تیم‌ها هزینهٔ هوش مصنوعی خود را اشتباه محاسبه می‌کنند چون «زوال» (Decay) بودجهٔ خطا را نادیده می‌گیرند. هشدار خروجی اغلب دیر صادر می‌شود زیرا سیستم تنها ضرب‌الاجل نهایی را رصد می‌کند، نه زوالی که بودجه را بلعیده است. وقتی یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — متنی روان تولید می‌کند که با طرحواره JSON (JSON Schema) سازگار نیست، کل فرآیند شکست می‌خورد، فارغ از اینکه پاسخ چقدر «هوشمندانه» به نظر برسد.
معماری اعتبارسنجی
برای جلوگیری از شکست در محیط عملیاتی، این راهنما یک ردیابی چهار مرحله‌ای (Four-stage trace) برای هر فاکتور پیشنهاد می‌کند. این روش اجازه می‌دهد تیم‌ها به این سؤال پاسخ دهند که «کدام قرارداد شکست خورده است؟» بدون اینکه فضای ذخیره‌سازی Observability را به یک آرشیو دوم برای فاکتورها تبدیل کنند. برای حفظ امنیت، تیم‌ها نباید متن فاکتور را لاگ کنند، بلکه باید شناسه‌ها، نسخه‌ها، نتایج و زمان‌بندی‌ها را ثبت نمایند و اسناد خام تأمین‌کنندگان را پشت کنترل‌های دسترسی موجود نگه دارند. این رویکرد لایه‌بندی شده، شباهت زیادی به معماری‌های چهار-دروازه‌ای برای تعدیل محتوا در حجم بالا دارد که در آن هر مرحله وظیفه‌ای خاص برای فیلتر کردن داده‌های نامعتبر بر عهده دارد.
- invoice_received: ثبت یک شناسه پایدار سند (Document ID) و شناسه تأمین‌کننده.
- classification_attempted: ثبت مدل انتخابی، نسخه پرامپت، نسخه طرحواره و شماره تلاش.
- classification_validated: بررسی صحت ساختاری و اینکه آیا هر برچسب متعلق به تاکسونومی (Taxonomy) تأیید شده است یا خیر.
- invoice_committed: استفاده از همان شناسه پایدار سند برای تضمین تکرارناپذیری (Idempotency) تا تلاش‌های مجدد باعث ثبت تکراری رکوردهای مالی نشود.
تعریف قرارداد داده
قبل از انتخاب ارائه‌دهنده، تیم‌ها باید مرز محصول را تعریف کنند. برای یک گردش کار فاکتور، طرحواره خروجی معمولاً به فیلدهایی مانند supplier_id (شناسه تأمین‌کننده)، invoice_number (شماره فاکتور)، currency (ارز)، expense_class (کلاس هزینه) و needs_review (نیاز به بررسی) نیاز دارد.
تیم‌ها باید فیلدهای اجباری، مقادیر شمارشی (Enums) و رفتار در زمان رد کردن داده را از پیش تعیین کنند. پس از تعریف، آن‌ها باید دو ویژگی مجزا را امتیازدهی کنند: انطباق با طرحواره JSON (صحت نحوی) و صحت فیلدها (دقت معنایی) در برابر یک مجموعه پاسخ‌های بازبینی شده. فاکتوری که از نظر نحوی بی‌نقص است اما برچسب اشتباه دارد، همچنان یک شکست محسوب می‌شود. در واقع، برای جلوگیری از چنین خطاهای ظریفی، استفاده از یک چک‌لیست بازبینی سریع می‌تواند مانع از آن شود که خروجی‌های متقاعدکننده اما غلط، به عنوان داده‌های صحیح پذیرفته شوند.
اندازه‌گیری هزینهٔ مؤثر
مقایسه مدل‌ها بر اساس نرخ توکن‌های اعلام شده توسط شرکت‌ها یک تلهٔ رایج است. حجم زیاد پرامپت‌ها (Verbosity)، تکرار متن اسناد و تلاش‌های مکرر برای اصلاح خطاها می‌تواند مزیت ظاهری نرخ پایین یک مدل را کاملاً از بین ببرد. نویسنده مفهوم «هزینهٔ مؤثر» (Effective Cost) را معرفی می‌کند که مجموع موارد زیر است:
- فراخوانی‌های مدل
- تلاش‌های مجدد (Retries)
- شکست‌های اعتبارسنجی
- زمان بررسی انسانی
- عملیات آداپتور (Adapter operations)
- اصلاحات پایین‌دستی
بر اساس بررسی منابع متعدد، نمونه‌های کوچک اغلب گمراه‌کننده هستند. یک تست روی ۱۰۰ سند (Smoke Test) ممکن است یک طرحواره شکسته را شناسایی کند، اما نمی‌تواند «رفتار دمی» (Tail Behavior) یک جمعیت از تأمین‌کنندگان با هزاران قالب مختلف را پیش‌بینی کند. تیم‌ها باید از یک مجموعه دادهٔ منجمد (Frozen Corpus) شامل موارد «زشت» استفاده کنند: شماره‌های فاکتور تکراری، ارزهای غایب، توصیفات چندزبانه، یادداشت‌های اعتباری (Credit Notes) و اختصارات خاص هر تأمین‌کننده. مجموعه‌های بازپخش (Replay sets) باید تا حدی افزایش یابند که زبان‌ها و انواع فاکتورهایی را که واقعاً باعث ایجاد نیاز به بررسی انسانی می‌شوند، نمایندگی کنند و به جای یک درصد گرد شده، بازه‌های اطمینان (Confidence Intervals) را گزارش دهند.
مرز یکپارچه‌سازی
اتصال مستقیم به OpenAI، Anthropic یا Google باعث ایجاد سیلوهای وابسته به فروشنده می‌شود. هر مسیر کلاینت اضافی، به نقطه دیگری برای نرمال‌سازی احراز هویت، خطاها، تله‌متری و اعتبارسنجی پاسخ تبدیل می‌شود. برای حل این مشکل، استفاده از یک محیط اجرای چندمدلی مثل Infrai پیشنهاد می‌شود.
Infrai یک سطح سازگار با OpenAI فراهم می‌کند که اجازه می‌دهد مدل پشتیبان را بدون تغییر در کد برنامه عوض کنید. این ابزار انتخاب مدل را در فیلد استاندارد مدل نگه می‌دارد، به این معنی که قرارداد برنامه ثابت می‌ماناند در حالی که ارائه‌دهنده تغییر می‌کند. این سیستم متادیتای هر فراخوانی شامل هزینه، فروشنده و تأخیر را از طریق نقطه انتهایی /v1/ai/models ارائه می‌دهد. برای تخمین‌های اولیه، این Runtime نقطه انتهایی /v1/ai/tokens/count را نیز در اختیار قرار می‌دهد.
با این حال، نویسنده به یک محدودیت خاص اشاره می‌کند: Infrai فاقد یک نقطه انتهایی اختصاصی برای نظارت بر محتوا (Moderation) است، به این معنی که هر سیاست ایمنی متنی باید از طریق خروجی‌های محدود شدهٔ چت بیان و بررسی شود.
کارت امتیاز انتخاب مدل
تیم‌ها باید بر اساس یک مجموعه داده منجمد و طرحواره سخت‌گیرانه، مدل‌ها را بسنجند:
- OpenAI (مستقیم): بهترین گزینه برای تیم‌هایی که رابطه مستقیم با فروشنده می‌خواهند و یکپارچه‌سازی وابسته به فروشنده را می‌پذیرند. تست روی نرخ اعتبار طرحواره، دقت برچسب‌ها و رفتار در تلاش‌های مجدد.
- Anthropic Claude (مستقیم): برای تیم‌هایی که آماده‌اند یک آداپتور مجزا برای کلود و قرارداد عملیاتی آن را مدیریت کنند. تست با همان مجموعه داده منجمد.
- Google Gemini (مستقیم): برای سازمان‌هایی که در حال حاضر با اکوسیستم جمینای راحت هستند. تست با همان مجموعه داده منجمد.
- Runtime چندمدلی (Infrai): برای تیم‌هایی که انعطاف در تعویض مدل بدون بازنویسی کد فراخوانی برچسب‌گذاری را اولویت می‌دهند. تست صحت هر مدل به علاوه رفتار مسیریابی و متادیتا.
پیاده‌سازی Worker
برای توسعه‌دهندگان زبان Go، پیشنهاد می‌شود Worker-ی ساخته شود که قبل از ثبت نهایی، اعتبارسنجی کند. این فرآیند باید شامل موارد زیر باشد:
۱. ارسال درخواست محدود با یک json_schema سخت‌گیرانه (مثلاً با استفاده از additionalProperties: false).
۲. رد کردن پاسخ‌های غیرموفق.
۳. پیاده‌سازی عقب‌نشینی نمایی (Exponential Backoff) برای خطاهای HTTP 429 (محدودیت نرخ) در حالی که به هدر Retry-After احترام گذاشته می‌شود.
در این معماری، شناسه فاکتور کلید تکرارناپذیری برای ثبت نهایی در دفتر کل (Ledger) است؛ تلاش‌های مجدد برای استنتاج (Inference) — یعنی لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی و نه دوره آموزش آشپز — چیزی را ثبت نمی‌کنند. Worker باید محتوای بازگردانده شده توسط دستیار را به یک Struct تایپ‌شده تبدیل کرده و دوباره تاکسونومی را قبل از ثبت نهایی اعتبارسنجی کند. نسخه‌های مدل و پرامپت باید به عنوان برچسب‌های متریک محدود نگه داشته شوند تا از حوادث مربوط به تعداد زیاد مقادیر (Cardinality incidents) در ابزارهای Observability جلوگیری شود.
هشدارها و SLOها
هشدارهای مربوط به عمق صف (Queue-depth) کافی نیستند چون نمی‌توانند ترافیک عادی پایان ماه را از «رکوردهای سمی» (Poison records) که در حلقه تکرار Worker گیر کرده‌اند تشخیص دهند. در عوض، هشدارها باید بر اساس نسبت فاکتورهای تأیید شده به تلاش‌های صورت گرفته در یک بازه زمانی متحرک (Rolling window)، همراه با شمارش برچسب‌های ناشناخته و فاکتورهایی که به حد نصاب تلاش‌های مجدد نزدیک شده‌اند، فعال شوند.
یک تله خاص، «عدم تطابق قرارداد قطعی» (Deterministic contract mismatch) است؛ جایی که مدل یک فیلد معتبر را با برچسبی برمی‌گرداند که دیگر در تاکسونومی وجود ندارد. تکرار پرامپت یکسان این مشکل را حل نمی‌کند. تیم‌ها باید نسخه تاکسونومی را مدیریت کرده، برچسب‌های ناشناخته را جداگانه بشمارند و این رکوردها را به بررسی انسانی ارجاع دهند.
مهندسان On-call تنها زمانی باید هشدار دریافت کنند که نرخ سوخت بودجه (Burn rate)، هدف پردازشی را تهدید کند یا تلاش‌های مجدد نهایی (Terminal retries) شروع به انباشت کنند. هشدارها باید شامل نسخه مدل، پرامپت و طرحواره باشند تا تیم بتواند بدون خواندن داده‌های حساس و خام فاکتورها، به آخرین نسخه سالم (Last-known-good) بازگردد. آستانه‌ها باید با ترافیک واقعی تست شوند؛ برای مثال، یک هشدار باید هم به حداقل تعداد تلاش‌ها و هم به نقض پایدار نرخ اعتبارسنجی نیاز داشته باشد تا از مثبت‌های کاذب در بازه‌های کم‌حجم جلوگیری شود.
این رویکرد تمرکز را از «هوش» مدل به «پایداری» خط‌لوله تغییر می‌دهد. برنده نهایی در رقابت مدل‌ها، مدلی نیست که بالاترین نمره بنچمارک را دارد، بلکه مدلی است که مجموع هزینه اصلاح را به حداقل می‌رساند.
گام بعدی شما
- مجموعه داده‌های «زشت» (Edge Cases) خود را شناسایی و در یک Corpus منجمد برای تست مدل‌ها ذخیره کنید.
- محاسبه هزینه AI خود را از «نرخ توکن» به «هزینه مؤثر» (شامل زمان بررسی انسانی و Retries) تغییر دهید.
- برای جلوگیری از وابستگی به یک فروشنده، لایه‌ای مانند Infrai را برای مدیریت مدل‌ها بررسی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو