استخدام یک دانشمند همه‌چیزدان برای مرتب کردن نامه‌های پستی، دقیقاً همان پوچیِ استفاده از یک مدل زبانی بزرگ (LLM) غول‌پیکر برای تصمیمات محدود زیرساختی است. این یک زیاده‌روی گران‌قیمت است که نیاز به حفاظ‌های (Guardrails) مداوم دارد تا مدل را متمرکز نگه دارد؛ در حالی که یک مسیریاب لاگ نیازی نیست برای تصمیم‌گیری درباره بحرانی بودن یک خطای سرور، شعر بخواند یا ترانه Bohemian Rhapsody را به زبان کلینگون اجرا کند.
این ناکارآمدی درست زمانی رخ می‌دهد که توسعه‌دهندگان با «میانهٔ آشفتهٔ» خطوط لوله داده دست‌وپنجه نرم می‌کنند. در حالی که ما می‌توانیم به راحتی تعریف کنیم داده‌ها باید به کجا بروند، نوشتن تک‌تک قوانین برای هر تغییر احتمالی در لاگ‌ها، پروژه‌ای است که هرگز به پایان نمی‌رسد. همان‌طور که در تحلیل قبلی ما درباره‌ی دلیل شکست محدودیت‌های نرخ درخواست (Rate Limits) در سرویس‌های SaaS هوش مصنوعی اشاره کردیم، صنعت اکنون به دیواری برخورد کرده است که در آن هزینه و تأخیر مدل‌های عمومی، اتخاذ میلیون‌ها تصمیم کوچک (Micro-decisions) را غیرعملی می‌کند. این چالش با استراتژی‌های طبقه‌بندی قصد کاربر برای بهینه‌سازی توکن‌ها همسو است که نشان می‌دهد چرا پرامپت‌های عمومی در مقیاس تولید شکست می‌خورند.
استدلال برای قضاوت‌های محدود
مدل‌های زبانی عمومی برای وسعت طراحی شده‌اند، اما زیرساخت به دقت نیاز دارد. قابلیت‌هایی که برای حل معادلات ناویر-استوکس (Navier–Stokes) یا تحلیل زوایای تندیس داوود اثر میکل‌آنژ نیاز است، با آنچه برای اولویت‌بندی یک لاگ سرور لازم است، متفاوت است. برای درک عمیق‌تر این تفاوت، کالبدشکافی سازوکار مدل‌های زبانی بزرگ دیدگاه فنی لازم برای مدیریت این ابزارها را فراهم می‌کند. اگرچه داشتن سیستمی که بتواند هر سه مورد را انجام دهد شگفت‌انگیز است، اما هر قطعه از نرم‌افزار نیازی ندارد که هر بار هنگام تصمیم‌گیری، کل این مجموعه توانایی‌ها را به کار بگیرد. در واقع، ابعاد این شغل بسیار کوچک‌تر از ابعاد مدل است.
وقتی یک پیام لاگ می‌گوید «درخواست بارگذاری مجدد توسط بازیگر ناشناس»، توسعه‌دهنده به یک پاراگراف درباره فلسفه پاسخ به حوادث نیاز ندارد. این پیام ممکن است برچسب INFO داشته باشد، اما این موضوع آن را به یک رویداد روتین تبدیل نمی‌کند. هدف این است که سیستمی داشته باشیم که بفهمد چرا یک پیام مهم است، بدون اینکه مجبور باشد هر عبارت احتمالی را پیش‌بینی کند.
زمینه (Context) نیز معنای کلمات را تغییر می‌دهد. یک پیام تکی ممکن است لایق یک نگاه ساده باشد، اما تکرار همان پیام در یک بازه زمانی کوتاه می‌تواند فوراً آن را به یک موضوع فوری تبدیل کند. این همان نوع قضاوت است که به هوش مصنوعی نیاز دارد، اما نتیجه‌ای می‌طلبد که نرم‌افزار بعدی بتواند بلافاصله از آن استفاده کند.
مدل Jev که توسط شرکت TypeSafe توسعه یافته، با تمرکز بر «قضاوت‌های تایپ‌شده» به این مسئله پاسخ می‌دهد. این مدل به‌جای یک رابط چت، موارد زیر را برمی‌گرداند:
- انتخابی از میان گزینه‌های تعریف‌شده
- یک امتیاز عددی
- احتمال بله/خیر
با حذف نیاز مدل به توضیح دادن، اپلیکیشن زمان کمتری را صرف تفسیر خروجی و زمان بیشتری را صرف اقدام می‌کند. اگرچه مدل‌های عمومی هم می‌توانند خروجی‌های ساختاریافته تولید کنند، اما Jev از ابتدا برای این تصمیمات محدود ساخته شده است، به این معنی که موارد کمتری برای پرسش اپلیکیشن و موارد کمتری برای تفسیر پس از آن وجود دارد.
پیاده‌سازی اولویت‌بندی هوشمند
برای اثبات این مفهوم، همکاری بین Expanso و Jev منجر به ایجاد یک خط لوله اولویت‌بندی لاگ شد. جزئیات این پیاده‌سازی در پست Expanso درباره اولویت‌بندی لاگ و یک راهنمای کامل در کانال یوتیوب Expanso آمده است که مسیریابی و یک قطعی شبیه‌سازی شده را در عمل نشان می‌دهد.
در این ساختار، Expanso رکوردهای ورودی و مسیریابی اولیه را مدیریت می‌کند. این فرآیند از یک سلسله‌مراتب مشخص پیروی می‌کند:
- بررسی‌های صریح: رویدادهای روتین شناخته‌شده بدون پرسش از مدل، مستقیماً به آرشیو می‌روند.
- خط لوله زمینه‌ای: برای رویدادهایی که نیاز به قضاوت دارند، خط لوله زمینه‌ای را فراهم می‌کند، از جمله اینکه یک رویداد مشابه چند بار در یک پنجره ۱۰ دقیقه‌ای رخ داده است.
- قضاوت مدل: Jev به سؤالات مشخصی پاسخ می‌دهد: آیا رویداد قابل اقدام است؟ شدت آن چقدر است؟ کدام تیم باید مسئول باشد؟ آیا تکرار آن نگران‌کننده است؟
- مسیریابی عملیاتی: خط لوله آستانه‌هایی (Thresholds) را اعمال می‌کند تا نتیجه را به سمت فراخوانی (Page)، اعلان (Notify)، بررسی (Review) یا آرشیو بفرستد.
این تقسیم کار تضمین می‌کند که سیاست مسیریابی همچنان توسط انسان نوشته شده و قابل بازبینی باشد. اگر پاسخی یافت نشود، Expanso آن را برای تلاش مجدد نگه می‌دارد و در نهایت برای بررسی می‌فرستد تا ترافیک روتین متوقف نشود و نتایج نامطمئن به صورت ایمن مدیریت شوند.
هزینه دقت
یک نکته حیاتی در دموهای Expanso، خطر «نرمال‌سازی بیش از حد» است. برای شمارش رویدادهای تکراری، توسعه‌دهندگان اغلب اعداد را حذف می‌کنند تا پیام‌های مشابه گروه‌بندی شوند. با این حال، نمی‌توان فرض کرد که گروه حاصل، برای نادیده گرفتن امن است. برای مثال، یک بررسی سلامت (Health Check) موفق و یکی شکست‌خورده، پس از حذف کد وضعیت و زمان پاسخ، بسیار شبیه به هم می‌شوند.
این یک مسئولیت خط لوله است، نه قابلیت مدل؛ مدل قدرتمندتر نمی‌تواند جایگزین مسئولیت انسان در تصمیم‌گیری درباره اینکه کدام اطلاعات حفظ شوند یا کدام میان‌برها امن هستند، شود. اینجاست که درک شکست سیستم‌های RAG به دلیل مهندسی بیش از حد عامل‌ها اهمیت می‌یابد، چرا که فاصله میان دموهای جذاب و محیط عملیاتی اغلب در همین جزئیات مدیریتی است. خروجی تایپ‌شده لزوماً به معنای درست بودن قضاوت نیست؛ یک پاسخ غلط در قالب یک JSON بی‌نقص، همچنان غلط است. توسعه‌دهندگان همچنان به نمونه‌هایی از محیط خود و آستانه‌های قابل دفاع نیاز دارند.
استدلال اقتصادی این تغییر بسیار تکان‌دهنده است. TypeSafe هزینه Jev را ۰.۰۴۲ دلار به ازای هر میلیون توکن ورودی اعلام کرده و برای توکن‌های خروجی هزینه‌ای نمی‌گیرد. این قیمت‌گذاری در کنار تأخیر‌های زیر یک ثانیه که توسط فروشنده گزارش شده، تعریف می‌کند که کدام مسائل ارزش حل شدن دارند.
وقتی هزینه یک تصمیم به قدری کم شود که بتوان آن را میلیون‌ها بار تکرار کرد، می‌توان از خلاصه‌سازی‌های دسته‌ای به قضاوت‌های لحظه‌ای رو آورد. در این حالت، هوش مصنوعی از یک «مشاور» که از او خلاصه می‌خواهیم، به یک «قطعه» تبدیل می‌شود که مستقیماً در مسیر بحرانی نرم‌افزار قرار می‌گیرد. با این حال، قبل از قرار دادن این سیستم در مسیر بحرانی، باید تأخیر انتهایی (Tail Latency)، بار پایدار و اشتباهات خاص مدل روی داده‌های واقعی اندازه‌گیری شود.
تغییر به سمت تخصص
این روند نشان‌دهنده آینده‌ای است که در آن مدل‌های کوچک و هدفمند در کنار غول‌های عمومی زندگی می‌کنند. تخصص در اینجا لزوماً در وزن‌های مدل نیست — TypeSafe اشاره می‌کند که مشتریان از همان وزن‌های مدل استفاده می‌کنند و برای هر شرکت تنظیم دقیق (Fine-tuning) جداگانه انجام نمی‌دهند — بلکه تخصص در چیزی است که از مدل خواسته می‌شود تولید کند.
با محدود کردن خروجی به مجموعه‌ای محدود از قضاوت‌ها، توسعه‌دهندگان می‌توانند متن‌های آشفته را به داده‌های ساختاریافته تبدیل کنند که ماشین‌های دیگر بتوانند از آن استفاده کنند. این رویکرد در موارد زیر کاربرد دارد:
- مسیریاب‌های لاگ: تعیین شدت و مالکیت رویدادهای سیستم.
- صف‌های پشتیبانی: دسته‌بندی تیکت‌های ورودی برای مسیریابی.
- بررسی کیفیت داده‌ها: شناسایی ناهنجاری‌ها در جریان داده.
برای توسعه‌دهنده، این یعنی زمان کمتری برای جنگ با پرامپت‌ها جهت جلوگیری از «بیش از حد کمک‌کار بودن» مدل و زمان بیشتری برای ساخت کنترل‌های پیش‌بینی‌پذیر حول سؤالات محدود. ما می‌دانیم رکوردها کجا باید بروند و سیاست را می‌شناسیم؛ ما عمدتاً در تفسیر بخش‌های آشفته وسط راه کمک می‌خواهیم.
زیرساخت ما نیازی به گفتگو ندارد؛ ما به صحت و سرعت نیاز داریم. کارهای زیادی برای مدل‌هایی که درباره دینامیک سیالات و زبان کلینگون بحث می‌کنند باقی می‌ماند، اما برای یک مسیریاب لاگ، ما فقط جواب را می‌خواهیم تا کارمان را پیش ببریم.
گام بعدی شما
- اگر از مدل‌های عمومی برای کارهای طبقه‌بندی (Classification) استفاده می‌کنید، خروجی‌ها را به فرمت JSON محدود کنید تا هزینه پردازش خروجی کاهش یابد.
- در خط لوله‌های داده، ابتدا یک لایه «بررسی صریح» برای رویدادهای تکراری بسازید تا تعداد توکن‌های ارسالی به مدل کاهش یابد.
- تأخیر انتهایی (Tail Latency) را در بارهای کاری شدید اندازه‌گیری کنید تا مطمئن شوید مدل در مسیر بحرانی نرم‌افزار باعث گلوگاه نمی‌شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو