هوش مصنوعی رو مثل وبسرویس مانیتور نکن
هوش مصنوعیخلاصهٔ کاملتر
به گفتهٔ Aurimas Griciūnas تو خبرنامهٔ SwirlAI، خیلی از سیستمهای AI هنوز درست مثل وبسرویسهای کنارشون مانیتور میشن: گیتوی API آمار uptime، نرخ خطا و درصدهای latency میده و داشبوردها هم مجانی با زیرساخت میان. ولی هیچکدوم این اعداد بهت نمیگن که کاربر چهار ثانیه به صفحهٔ خالی زل زده تا اولین توکن بیاد، یا هزینهٔ توکن هر تسک از آخرین تغییر پرامپت دو برابر شده، یا مدل شروع کرده به ساختن جواب دور کانتکست بازیابیشده بهجای از روی اون.
نویسنده میگه این شکاف به این خاطره که LLM فرضهای مانیتورینگ وب رو میشکنه: جواب توکنبهتوکن تولید میشه، پس «latency» دستکم سه عدد متفاوته؛ هزینه با توکن مقیاس میگیره نه با تعداد request؛ و مخربترین خرابیها بیصدان — افت کیفیت خطای ۵۰۰ نمیده، یه متن مطمئن با استتوس ۲۰۰ برمیگردونه. راهحل پیشنهادیش گروهبندی متریکها بر اساس پنج سؤاله: سریعه؟ مقیاسپذیره؟ درسته؟ دووم میاره؟ و وقتی ایجنت وسطه، چطور رفتار میکنه؟
برای سرعت، هر متریک یه نقطه روی تایملاین درخواسته. TTFT (زمان تا اولین توکن) همون چیزیه که کاربر تو UI استریمی حس میکنه و با طول پرامپت زیاد میشه، برای همین سیستمهای RAG که کانتکست بزرگ تو پرامپت میچپونن، بابتش سرعت ادراکی از دست میدن. ITL (فاصلهٔ بین توکنها) روونبودن استریم رو تعیین میکنه و latency سرتاسری هم باید per use case ردیابی بشه، چون یه p95 سراسری میانگین کالهای ۵۰ توکنی و گزارشهای ۲۰۰۰ توکنیه و عملاً بیمعنیه. برای ایجنتها هم بودجهٔ latency رو در سطح تسک بذار.
برای مقیاس و هزینه، تعادل بین توکنبرثانیهی هر کاربر و throughput کل سیستم مهمه (بچ بزرگتر throughput کل رو بالا میبره ولی هر استریم رو کند میکنه). cache hit rate یکی از بزرگترین اهرمهای کاهش هزینهست، ولی چون کش پیشوند پرامپت رو بایتبهبایت مچ میکنه، یه timestamp یا ترتیب عوضشدهٔ ابزارها کش رو باطل میکنه. مهمتر از همه، هزینهبهازای تسک موفق رو اندازه بگیر نه هزینهٔ هر request؛ این عددیه که هر سه بُعد latency و هزینه و کیفیت رو بههم وصل میکنه.
برای درستی، هیچچی تو استک سروکردن، صحت رو منتشر نمیکنه؛ همهش رو باید خودت بسازی: نرخ موفقیت تسک روی یه eval set برچسبخورده (بهعنوان سوییت رگرسیون سیستم)، groundedness برای RAG (جواب از کانتکسته یا دور اون ساخته شده)، precision و recall @k برای بازیابی (جنریشن نمیتونه چیزی که بازیابی هیچوقت نیاورده رو جبران کنه)، امتیاز LLM-as-judge کالیبرهشده با برچسب انسانی، و سیگنالهای بازخورد مثل نرخ regenerate و میزان ویرایش خروجی که صادقتر از لایک/دیسلایکان.
برای پایداری، نرخ خطا/تایماوت/rate-limit رو بهتفکیک provider ببین، نرخ retry و fallback رو ردیابی کن (چون افتادن روی مدل پشتیبان کیفیت رو بیصدا عوض میکنه) و نرخ تریگر گاردریل و refusal رو هم لاگ کن. برای رفتار ایجنت هم نرخ خطای tool-call بهتفکیک علت (خطای اسکیما یعنی توضیح ابزار، خطای اجرا یعنی کد تو)، تعداد step و توکن هر تسک، میزان استفاده از context window و تشخیص loop (تکرار یه tool-call با آرگومان یکسان که فقط توکن میسوزونه) رو رصد کن. جمعبندی نویسنده: latency و reliability از روز اول مجانی از زیرساخت میان، ولی کیفیت و هزینهبهازایتسک و متریکهای ایجنت رو باید بسازی — پس هزینهٔ instrumentation رو از همون برآورد اولیهٔ ساخت فیچر ببین، نه تو یه بازبینی بعدی.
نکات کلیدی:
- مانیتورینگ وب خرابیهای بیصدای LLM رو نمیگیره؛ افت کیفیت با کد ۲۰۰ و متن مطمئن برمیگرده
- متریکها رو با پنج سؤال گروه کن: سریعه، مقیاسپذیره، درسته، دووم میاره، ایجنت چطور رفتار میکنه
- latency رو بهعنوان نقاط روی تایملاین ببین: TTFT برای سرعت ادراکی، ITL برای روونی، e2e بهتفکیک use case
- «هزینهبهازای تسک موفق» عددیه که latency و هزینه و کیفیت رو بههم وصل میکنه
- کیفیت، هزینهبهازایتسک و رفتار ایجنت بهطور پیشفرض منتشر نمیشن و باید instrumentationشون رو خودت بسازی
