وقتی می‌گیم باید از LLM استفاده کنیم، منظور فقط این نیست که ازش بخوایم فایل‌های YAML کوبرنتیز رو برامون بنویسه یا لاگ یک پاد مشکل‌دار رو براش کپی کنیم و بپرسیم ایراد کجاست.

این کارها مفیدن، اما هنوز استفاده موردی از LLM در یک محیط چت هستن. ما اطلاعات رو جمع می‌کنیم، context رو در اختیار مدل می‌ذاریم و بعد خروجی رو به سیستم برمی‌گردونیم. یعنی تمام ارتباط بین LLM و سیستم همچنان به‌صورت دستی و از طریق ما انجام می‌شه.

یک نمونه خوب از چیزی که باید به سمتش حرکت کنیم، JARVIS در فیلم Iron Man هست.

بعد از اولین آزمایش پرواز، تونی مشکلات لباس در ارتفاع بالا رو توضیح می‌ده و پیشنهاد می‌کنه از آلیاژ طلا و تیتانیوم استفاده بشه. JARVIS طرح جدید رو render می‌کنه، اما نتیجه کاملاً طلاییه. تونی ازش می‌خواد کمی قرمز هم اضافه کنه. نسخه جدید نمایش داده می‌شه و بعد از تأیید تونی، آزمایشگاه ساخت و مونتاژ لباس رو شروع می‌کنه؛ در حالی که خود تونی از اونجا می‌ره.

نکته مهم این صحنه رنگ لباس نیست. JARVIS فقط یک chatbot نیست که درباره طراحی لباس پیشنهاد بده. به نتایج آزمایش، مدل طراحی، نرم‌افزار render و تجهیزات ساخت دسترسی داره. تونی هدف و اصلاحات رو مشخص می‌کنه، نتیجه رو می‌بینه و بعد اجرای کار رو به سیستمی می‌سپاره که می‌تونه بدون حضور دائم اون ادامه بده.

دیدگاه ما به استفاده از LLM هم باید به همین سمت حرکت کنه: از ابزاری که فقط به سؤال‌های موردی جواب می‌ده، به بخشی از سیستم که context و ابزار لازم برای انجام یک workflow واقعی رو در اختیار داره.

مثلاً می‌تونیم سرویسی داخل یا کنار کلاستر داشته باشیم که به metrics، logs، traces، events و تاریخچه deploymentها دسترسی داشته باشه. وقتی مشکلی پیش میاد، این اطلاعات رو کنار هم بذاره، تغییرات اخیر رو بررسی کنه، علت احتمالی رو پیدا کنه و نتیجه رو به ما گزارش بده.

اگر دسترسی محدود و مشخصی هم بهش داده باشیم، می‌تونه بعضی اقدامات از پیش تعریف‌شده مثل restart کردن یک سرویس، rollback کردن یک deployment یا تغییر تعداد replicaها رو انجام بده. البته چنین اقدام‌هایی باید قابل ثبت، قابل بررسی و در صورت نیاز قابل برگشت باشن.

اینجا دیگه LLM فقط ابزاری برای جواب دادن به یک سؤال نیست؛ بخشی از حلقه عملیاتی سیستمه. وضعیت رو می‌بینه، اطلاعات رو از چند منبع کنار هم می‌ذاره و در محدوده‌ای که ما تعیین کردیم واکنش نشون می‌ده.

پروژه‌هایی مثل OpenChoreo نمونه‌ای از همین مسیر هستن. OpenChoreo یک پلتفرم متن‌باز برای کوبرنتیزه که اطلاعاتی مثل لاگ‌ها، متریک‌ها و وضعیت سرویس‌ها رو در اختیار agentها می‌ذاره تا بتونن علت مشکلات رو بررسی کنن، راه‌حل پیشنهاد بدن و در محدوده دسترسی مشخص، بعضی مشکلات رو برطرف کنن.

هدفم از اشاره به OpenChoreo این نیست که همه باید همین ابزار رو نصب کنن. نکته اینه که LLMها رو فقط در حد coding agent یا یک پنجره چت نبینیم. ارزش اصلی اون‌ها زمانی بیشتر می‌شه که به context واقعی، ابزارهای مشخص و workflowهای قابل‌کنترل متصل بشن و به جزئی مهندسی‌شده از خود سیستم تبدیل بشن.