تصور کنید مهندس On-call شما ساعت ۳ صبح بیدار شود، اما متوجه شود هشدار بحرانی سیستم، تنها یک نویز ساده بوده است. این کابوس عملیاتی اکنون با یک خط لوله تأیید چندمرحله‌ای در Oxlo.ai به حداقل می‌رسد تا هشدارهای نامنظم و بدون ساختار به امتیازات دقیقی از شدت حادثه تبدیل شوند. این رویکرد با اعمال اعتبارسنجی سخت‌گیرانه طرحواره (Schema) و قضاوت مبتنی بر مدل، «نویزی» را که اغلب مهندسان را برای مسائل غیربحرانی بیدار می‌کند، حذف می‌کند.
اتوماسیون قابل‌اعتماد در مهندسی قابلیت اطمینان سایت (SRE) سال‌هاست که با پیش‌بینی‌ناپذیری خروجی‌های مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — دست‌وپنجه نرم می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی تبدیل مدل‌های بینایی به طبقه‌بندی‌کننده اشاره کردیم، این گردش‌کار اکنون تمرکز را به استدلال متنی و داده‌های ساختاریافته منتقل کرده است. برای اکثر مهندسان، این یعنی تفاوت بین یک هشدار مبهم «مشکلی وجود دارد» و یک اعلان عینی و مشخص مانند «خطای استقرار P2 در منطقه eu-west-1».
به نقل از راهنمای فنی منتشر شده در ۲۶ سپتامبر ۲۰۲۶، این معماری بر سه ستون فنی اصلی استوار است:
۱. اجبار به ساختار داده‌ای
سیستم از Pydantic برای قفل کردن شکل خروجی استفاده می‌کند. با تعریف مدل TriageResult، عامل مجبور است سطح شدت (P0-P4)، میکروسرویس‌های affected، دسته‌بندی علت ریشه و یک امتیاز اطمینان بین ۰.۰ تا ۱.۰ ارائه دهد. این کار مانع از توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — یا تولید جملات پرکننده و گفتگوهای اضافی می‌شود.
الزامات خاص در این طرحواره عبارتند از:
- Severity Enum: مجموعه‌ای سخت‌گیرانه از مقادیر از P0 تا P4.
- Root Cause Category: باید دقیقاً یکی از موارد زیر باشد: زیرساخت (infrastructure)، استقرار (deployment)، وابستگی (dependency)، داده (data) یا ناشناخته (unknown).
- Remediation: یک دستور یا گام عملیاتی و عینی به‌جای توصیه‌های کلی و مبهم.
- Reasoning: یک فیلد زنجیره تفکر (Chain-of-Thought) — مثل وقتی شاگرد ریاضی پای تخته بلند بلند فکر می‌کند تا به جواب برسد — که مدل را مجبور می‌کند قبل از انتخاب شدت، گام‌به‌گام فکر کند.
۲. رای‌گیری برای سازگاری داخلی
برای جلوگیری از خطاهای تصادفی در یک نمونه واحد (unlucky samples)، خط لوله سه استخراج مستقل را با استفاده از مدل Qwen 3 32B اجرا می‌کند. سپس سیستم روی سطح شدت رای‌گیری اکثریت می‌گیرد. امتیاز اطمینان نهایی بر اساس میزان توافق بین سه کاندیدا تنظیم می‌شود تا تضمین گردد که تنها نتایجی با اجماع بالا بدون نیاز به بررسی بیشتر عبور کنند.
این سازوکار از قیمت‌گذاری ثابت هر درخواست در Oxlo.ai بهره می‌برد. چون هزینه‌ها بر اساس تعداد درخواست است و نه طول متن (log length)، اجرای سه فراخوانی حتی هنگام پردازش دامپ‌های حجیم لاگ، پیش‌بینی‌پذیر باقی می‌ماند. این بهینه‌سازی در مدیریت منابع، در راستای تلاش‌های گسترده‌تر این پلتفرم است که با بهینه‌سازی تنظیمات GPU از اتلاف منابع محاسباتی جلوگیری می‌کند تا کارایی مدل‌ها در مقیاس بالا حفظ شود. در این فرآیند از Temperature (دمای مدل) ۰.۲ و بذرهای (seeds) منحصربه‌فرد برای هر یک از سه تکرار استفاده می‌شود تا تنوع در نمونه‌ها تضمین شود.
۳. تأیید توسط داور
زمانی که اطمینان رای‌گیری به زیر ۰.۸ می‌رسد، سیستم پرونده را به Kimi K2.6 ارجاع می‌دهد. این مدل پیشرفته‌تر به‌عنوان یک داور ارشد SRE عمل کرده و طبقه‌بندی پیشنهادی را در برابر هشدار اصلی نقد می‌کند و در صورت بروز خطا توسط عامل اولیه، شدت یا علت ریشه را اصلاح می‌نماید.
داور بر اساس مجموعه‌ای از قوانین اثرات تجاری (business-impact rules) خاص عمل می‌کند:
- P0: قطعی اثرگذار بر درآمد که همه کاربران را می‌پذیرد و هیچ راهکار جایگزینی (workaround) ندارد.
- P1: افت عملکرد ویژگی اصلی برای بسیاری از کاربران؛ راهکار جایگزین وجود دارد اما دشوار و دردناک است.
- P2: افت جزئی یا اثر بر مشتریان محدود و ایزوله؛ راهکار جایگزین آسان است.
- P3: باگ جزئی یا مشکل ظاهری (cosmetic) بدون اثر بر کاربر.
- P4: نویز، مصنوعات مانیتورینگ یا لاگ‌های اطلاع‌رسانی.
این رویکرد لایه‌ای، این فرض بنیادی را که یک پرامپت واحد می‌تواند طبقه‌بندی در سطح تولید (production-grade) را مدیریت کند، تغییر می‌دهد. با جداسازی «کارگر» (Qwen 3) از «داور» (Kimi K2.6)، سیستم فرآیند بازبینی همتای انسانی (peer-review) را شبیه‌سازی می‌کند. این استراتژی ریسک طبقه‌بندی اشتباه یک قطعی P0 به‌عنوان نویز P4 را به‌شدت کاهش می‌دهد.
جزئیات پیاده‌سازی
بر اساس مستندات، توسعه‌دهندگان برای ساخت این عامل به پایتون ۳.۱۰ یا جدیدتر، SDK شرکت OpenAI و Pydantic نیاز دارند. از آنجا که Oxlo.ai کاملاً با SDK شرکت OpenAI سازگار است، انتقال تنها با تغییر URL پایه به https://api.oxlo.ai/v1 و ارائه کلید API امکان‌پذیر است.
پرامپت سیستمی (System Prompt) بیشترین اهرم بهینه‌سازی است. این پرامپت صراحتاً زبان مبهم را ممنوع کرده و می‌طلبد که affected_services حتماً نام‌های دقیق میکروسرویس باشند و در صورت نبود داده، به صورت پیش‌فرض ["unknown"] قرار گیرند. خط لوله از response_format={"type": "json_object"} برای اجبار به رعایت ساختار در سطح API استفاده می‌کند.
به‌عنوان مثال، یک هشدار نامنظم درباره افزایش تأخیر p95 به ۸۹۰ میلی‌ثانیه در منطقه eu-west-1 برای user-auth-api (که ۴۵ دقیقه پس از یک استقرار رخ داده) به این صورت پردازش می‌شود:
- طبقه‌بندی اولیه: Qwen 3 همبستگی بین حادثه و استقرار را شناسایی می‌کند.
- رای‌گیری: سه نمونه، شدت P2 را به‌دلیل کندی منطقه‌ای (و نه شکست کامل سیستم) تأیید می‌کنند.
- تأیید: اگر اطمینان پایین باشد، Kimi K2.6 منطق را بررسی کرده و نقدی مانند «موافقم. همبستگی با استقرار قوی است» را اضافه می‌کند.
- خروجی نهایی: یک شیء JSON ساختاریافته با امتیاز اطمینان (مثلاً ۰.۸۵) و راهکار مشخص مانند «بررسی بازگشت (Rollback) نسخه v1.4.2 از user-auth-api».
برای متخصصان، این به معنای گذار از مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — به سمت مهندسی خط لوله (pipeline engineering) است. ارزش دیگر در یافتن «پرامپت کامل» نیست، بلکه در طراحی حلقه تأیید است. این معماری به تیم‌ها اجازه می‌دهد مانیتورینگ خود را بدون افزایش خطی فشار ذهنی (cognitive load) روی مهندسان انسانی مقیاس کنند.
برای پیاده‌سازی این سیستم، توسعه‌دهندگان می‌توانند خط لوله را با وب‌هوک‌های PagerDuty یا Opsgenie ادغام کنند. گام بعدی برای بهینه‌سازی، ایجاد یک حلقه بازخورد است که در آن اصلاحات انجام شده توسط داور در یک مجموعه داده ذخیره شود تا پرامپت سیستمی به‌صورت هفتگی بازبینی و اصلاح گردد.
گام بعدی شما
- ادغام این خط لوله با وب‌هوک‌های PagerDuty یا Opsgenie برای اتوماسیون واقعی.
- ایجاد یک حلقه بازخورد که در آن اصلاحات داور در یک مجموعه داده ذخیره شود تا پرامپت سیستمی هفتگی بهینه گردد.
- تست مدل‌های کوچک‌تر (SLM) در جایگاه کارگر برای کاهش بیشتر هزینه استنتاج.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو