منحنی هزینه‌ای که هیچ‌کس پیش از عرضه مدل نمی‌کند
یک سرویس متعارف تله‌متری را تقریباً به نسبت درخواست‌هایی که سرویس می‌دهد منتشر می‌کند. یک عامل این‌گونه نیست. یک درخواست کاربر به یک مرحلهٔ برنامه‌ریزی، دنباله‌ای از فراخوانی ابزار، یک مرحلهٔ اعتبارسنجی، یکی دو تلاش مجدد و یک ترکیب نهایی منشعب می‌شود. هر یک از این مراحل یک span است؛ هر span ویژگی‌ها، رویدادها و اغلب یک payload حمل می‌کند. این ضرب ساختاری است، نه اتفاقی.
گزارش‌های صنعتی شروع به نام‌گذاری این الگو کرده‌اند. پوشش راهنمای نظارت‌پذیری Splunk، تفسیر گسترده‌تر در Network World، و مطالب تله‌متری Cisco همگی یک شکل را توصیف می‌کنند: بارهای کاری مبتنی بر عامل و LLM حجم نظارت‌پذیری را سریع‌تر از نرخ درخواست زیربنایی بالا می‌برند، و بخش زیادی از هزینهٔ حاصل پنهان است زیرا در ذخیره‌سازی، دریافت و مجوزهای به‌ازای هر کاربر انباشته می‌شود نه در یک قلم قابل مشاهده. پوشش مرتبط با Splunk، بحث Network World و نوشته‌های نظارت‌پذیری Cisco را برای روند کلی ببینید.
مشاهدهٔ ناراحت‌کننده این است که بیشتر این داده هرگز خوانده نمی‌شود. نگهداری می‌شود زیرا نگهداری پیش‌فرض است: SDK ردیابی همه‌چیز را صادر می‌کند، بک‌اند آن را برای پنجرهٔ پیکربندی‌شده نگه می‌دارد، و هیچ‌کس سیاست را بازبینی نمی‌کند زیرا سیاستی وجود ندارد. صورت‌حساب بعداً می‌آید، جدا از تصمیمی که آن را ایجاد کرده است.
آنچه عامل‌ها منتشر می‌کنند و سرویس‌ها نمی‌کنند
تله‌متری درخواست سنتی کوچک و ساختاریافته است: یک مسیر، یک کد وضعیت، یک مدت‌زمان. تله‌متری عامل بزرگ و معنایی است. چهار دسته بر حجم غالب‌اند.
payloadهای prompt و completion. هر فراخوانی مدل می‌تواند زمینهٔ کامل ورودی و خروجی کامل تولیدشده را حمل کند. این‌ها مفیدترین رکوردها برای اشکال‌زدایی و گران‌ترین برای ذخیره‌سازی هستند، زیرا با تعداد توکن مقیاس می‌گیرند نه با تعداد درخواست.
آرگومان‌ها و نتایج ابزار. یک span فراخوانی ابزار ارزان است؛ ویژگی‌های آن نه. آرگومان‌ها می‌توانند اشیاء ساختاریافتهٔ بزرگ باشند، و نتایج می‌توانند کل اسناد باشند. وقتی یک ابزار در یک حلقه فراخوانی می‌شود، همان شکل مکرراً منتشر می‌شود.
مراحل استدلال میانی. ردهای برنامه‌ریزی، محتوای scratchpad و مراحل خودنقدی به ازای هر مرحله منتشر می‌شوند. وقتی یک مسیر اشتباه می‌رود واقعاً ارزشمندند و وقتی درست می‌رود تقریباً بی‌ارزش.
تقویت تلاش مجدد. طوفان تلاش مجدد بدترین حالت برای نسبت هزینه به اطلاعات است: همان عملیات منطقی بارها ردیابی می‌شود، هر تلاش spanها، رویدادها و ویژگی‌های خطا اضافه می‌کند. تعداد span بالا می‌رود در حالی که اطلاعات حاشیه‌ای به صفر نزدیک می‌شود، زیرا واقعیت جالب این است که یک حلقهٔ تلاش مجدد رخ داده، نه محتوای تلاش چهاردهم.
یک لایهٔ فراداده نیز وجود دارد — تعداد توکن، شناسه‌های مدل، تأخیر فراخوانی، پرچم‌های برخورد کش — که به ازای هر رکورد ارزان و در مجموع مفید است. با وفاداری کامل در هر span، خودش به یک قلم ذخیره‌سازی قابل‌توجه تبدیل می‌شود.
سیاست نمونه‌برداری متصل به نقاط تصمیم
انتزاع مفید نه سرویس است و نه نوع span. تصمیم است. هر مرحلهٔ عامل یا وضعیت را می‌خواند، یا وضعیت را تغییر می‌دهد، یا تصمیم می‌گیرد下一步 چه کند. نمونه‌برداری باید از این طبقه‌بندی پیروی کند.
- ردهای کامل را برای فراخوانی ابزارهایی که وضعیت را تغییر می‌دهند نگه دارید. نوشتن‌ها، حذف‌ها، پرداخت‌ها، پیام‌های خروجی، تغییرات فایل. این‌ها فراخوانی‌هایی هستند که بازبینی حادثه به آرگومان‌های دقیق و نتیجهٔ دقیق نیاز خواهد داشت، و جایی که یک رد حسابرسی ارزشی فراتر از اشکال‌زدایی دارد.
- خواندن‌ها را تهاجمی نمونه‌برداری کنید. بازیابی، جستجوها و فراخوانی‌های API فقط-خواندنی را می‌توان با نرخ پایین با نمونه‌برداری مبتنی بر سر در ریشهٔ رد، یا نمونه‌برداری مبتنی بر دنباله کلیدخورده بر وضعیت خطا نمونه‌برداری کرد. اطلاعات از دست رفته کم است زیرا خواندن‌ها بازتولیدپذیرند.
- خلاصه‌های ساختاریافته را در سطح مسیر نگه دارید. برای هر مسیر تکمیل‌شده، یک رکورد فشرده ذخیره کنید: برنامه، فهرست مرتب نام ابزارها، نتیجه، مجموع توکن‌ها، تفکیک تأخیر. این شکل آنچه رخ داده را بدون payloadها حفظ می‌کند.
- payloadهای خام را فقط در صورت شکست نگه دارید. وقتی یک مسیر به خطا، برخورد guardrail یا شکست قابل مشاهده برای کاربر می‌رسد، رد کامل را به ذخیره‌سازی پایدار ارتقا دهید. این یک قاعدهٔ مبتنی بر دنباله است و تک‌تنها بالاترین اهرم را در سیاست دارد.
- نگهداری را بر اساس کلاس تصمیم تنظیم کنید، نه بر اساس سرویس. یک فراخوانی تغییردهنده ممکن است پنجرهٔ طولانی را توجیه کند؛ یک span خواندن ممکن است ساعت‌ها را توجیه کند. بیان نگهداری به‌عنوان ویژگی کلاس تصمیم، سیاست را خوانا نگه می‌دارد و آن را هنگام تغییر رفتار عامل قابل بازبینی می‌کند.
یک مکانیسم مشخص: هر span را در زمان انتشار با یک ویژگی کلاس تصمیم حاشیه‌نویسی کنید — read، mutate، decide — که توسط پوشش ابزار تنظیم می‌شود نه توسط فراخوان. سپس جمع‌کننده بر اساس آن ویژگی مسیریابی می‌کند. spanهای تغییردهنده به ذخیره‌سازی با وفاداری کامل و پنجرهٔ طولانی می‌روند؛ spanهای خواندن به یک جریان نمونه‌برداری‌شده با پنجرهٔ کوتاه؛ spanهای تصمیم ویژگی‌ها را نگه می‌دارند اما payloadها را حذف می‌کنند. ارتقای شکست توسط پردازشگر دنبالهٔ جمع‌کننده انجام می‌شود، که یک رد را به‌طور مختصر بافر می‌کند و وقتی span ریشه وضعیت خطا دارد کل آن را ارسال می‌کند. کد عامل تغییر نمی‌کند؛ سیاست در پوشش و پیکربندی جمع‌کننده زندگی می‌کند، و هر دو با عامل نسخه‌بندی می‌شوند.
معامله، صادقانه بیان شده
نمونه‌برداری شواهد موجود برای بازبینی حادثه را کاهش می‌دهد. این هزینه است، و واقعی است. خواندنی که نمونه‌برداری شده قابل بازسازی پس از واقعه نیست، و شکستی که معلوم می‌شود مهم است ممکن است همان شکستی نباشد که قاعدهٔ دنباله برای آن تنظیم شده است.
راه کاهش، نمونه‌برداری بر اساس ریسک تصمیم است نه به‌طور یکنواخت. نمونه‌برداری یکنواخت هر تحقیقی را به یک اندازه تخریب می‌کند؛ نمونه‌برداری وزن‌دار بر اساس ریسک، شواهد باقی‌مانده را در جایی متمرکز می‌کند که تحقیق بیشترین احتمال نیاز را دارد. ردهایی که مهم‌اند با وفاداری کامل زنده می‌مانند، آنهایی که نیستند با خلاصه‌ها نمایش داده می‌شوند، و لایهٔ فراداده تجمیعی به اندازهٔ کافی کامل می‌ماند برای تحلیل ظرفیت و هزینه.
این باید پیش از عرضهٔ عامل تصمیم‌گیری شود. اعمال یک سیاست نمونه‌برداری بر یک عامل در حال اجرا به معنای از دست دادن خط پایه است: هیچ مقایسهٔ تمیزی بین دورهٔ وفاداری کامل قدیم و دورهٔ نمونه‌برداری‌شدهٔ جدید وجود ندارد، و اولین حادثه پس از تغییر در برابر مجموعه شواهدی متفاوت از آخرین حادثه پیش از آن تشخیص داده می‌شود. طراحی سیاست در کنار عامل — همان‌طور که طرح‌واره‌های ابزار و guardrailها طراحی می‌شوند — یک خط پایهٔ پایدار از روز اول و یک وضعیت نگهداری می‌دهد که می‌تواند به‌طور عمدی تنظیم شود نه اینکه در یک صورت‌حساب کشف شود.
هزینهٔ تله‌متری یک ویژگی از طراحی عامل است. با آن به‌عنوان یکی رفتار کنید.
