شکاف پیش از آنکه یک شکست باشد، یک خطای اندازه‌گیری است
مجوز در یک رویداد خرید صادر می‌شود. مصرف در یک رویداد یکپارچه‌سازی انباشته می‌شود. این دو ساعت با سرعت‌های متفاوت حرکت می‌کنند و تیم‌های متفاوتی آن‌ها را می‌خوانند؛ به همین دلیل نسبت میان‌شان در یک بازبینی فصلی چشمگیر و در یک مرور پس‌نگر پلتفرم عادی به نظر می‌رسد. وقتی یک سازمان از ضریب بزرگی میان صندلی‌های تخصیص‌یافته و نشست‌هایی که کاری را به انجام می‌رسانند گزارش می‌دهد، این عدد معمولاً بر مبنای دو مخرج ناسازگار محاسبه می‌شود: صندلی‌ها یک‌بار و در زمان خرید شمرده می‌شوند، در حالی که نشست‌های معنادار به‌ازای هر واحد کار، هر tool call و هر نوشتن موفق شمرده می‌شوند.
نخستین اصلاح این است که از برخورد با این نسبت به‌عنوان یک معیار احساسی دست برداریم. این نسبت شاهدی بر بی‌میلی کارکنان به استفاده از agentها نیست. شاهدی است بر اینکه مسیر از شروع یک نشست تا تکمیل یک وظیفه از مرزی عبور می‌کند که فرایند خرید هرگز به آن دست نزده است.
داشبوردهای پذیرش رویداد اشتباه را می‌سنجند
بیشتر داشبوردهای داخلی مصرف agent، ورودها، کاربران فعال هفتگی و تعداد پیام‌ها را گزارش می‌کنند. هر سه با نشستی ارضا می‌شوند که باز می‌شود، یک prompt را می‌پذیرد، یک tool call را می‌کوشد، خطای schema یا رد مجوز دریافت می‌کند و پایان می‌یابد. کاربر وارد شده است. کاربر فعال است. کاربر پیامی فرستاده است. وظیفه تکمیل نشده است.
چون این شکست بی‌صدا جذب می‌شود، داشبورد پذیرشی سالم نشان می‌دهد و صف پشتیبانی جریان کندی از شکایات را نشان می‌دهد که هرگز به یک سیگنال تجمیع نمی‌شوند. معیار تجمیعی که این مشکل را آشکار می‌کند — نرخ شکست نخستین tool call به‌ازای هر نشست — تقریباً هرگز اندازه‌گیری نمی‌شود، چون زیر لایه‌ای قرار دارد که تیم پذیرش مالک آن است.
یک تشخیص مفید این است که نشست‌ها را بر اساس حالت پایانی‌شان بشماریم، نه بر اساس فعالیت. نشست‌هایی که پس از یک نوشتن موفق پایان می‌یابند، نشست‌هایی که پس از یک پاسخ فقط‌خواندنی پایان می‌یابند، و نشست‌هایی که در نخستین tool call ناموفق پایان می‌یابند، سه جمعیت متفاوت با سه درمان متفاوت‌اند. فروکاستن آن‌ها به یک عدد کاربر فعال، تنها اطلاعاتی را که اهمیت دارد نابود می‌کند.
شکاف در سراسر حوزه‌ها پایدار است، و این به ساختار اشاره می‌کند
اگر این کمبود ناشی از نقص آموزش بود، با سطح تخصص جمعیت کاربران و کیفیت برنامه توانمندسازی تغییر می‌کرد. در عمل شکل این منحنی در خدمات مالی، لجستیک، مدیریت بهداشت و درمان و عملیات فناوری اطلاعات داخلی مشابه است. اعداد مطلق تفاوت دارند؛ الگوی افت یکسان است.
این پایداری قوی‌ترین شاهد موجود برای این است که علت ساختاری است. متغیری که میان حوزه‌ها تغییر می‌کند، سیستم‌های ثبت‌شده است، نه انسان‌ها. جایی که افت یکسان است، علت نیز احتمالاً یکسان است: رابط میان agent و آن سیستم‌ها.
این با مشاهده گسترده‌تری سازگار است که توانایی agent و سودمندی agent به‌محض ورود سیستم‌های واقعی به‌شدت از هم واگرا می‌شوند؛ نکته‌ای که در بحث‌های متخصصان درباره اقتصاد استقرار agent، مانند آنچه در https://quasa.io گردآوری شده، مکرراً مطرح شده است.
نشست‌ها در واقع کجا می‌میرند
schemaهای ابزاری که آینه APIهای داخلی‌اند
وقتی یک سطح ابزار با آشکارسازی endpointهای سرویس موجود تولید می‌شود، مدل شکل سازمان را به ارث می‌برد، نه شکل وظیفه را. یک کنش تجاری واحد — تغییر رزرو یک محموله — به دنباله‌ای از فراخوانی‌ها به سرویس مشتری، سرویس سفارش، سرویس موجودی و سرویس قیمت‌گذاری تبدیل می‌شود، که هرکدام قراردادهای شناسه و تصور خود را از زمان مجاز یک گذار وضعیت دارند.
سپس از مدل خواسته می‌شود منطق تجاری را از نام endpointها مهندسی معکوس کند. گاهی موفق می‌شود. وقتی شکست می‌خورد، شکست به استدلال نسبت داده می‌شود، اما علت واقعی این است که پیش‌شرط فراخوانی دوم هیچ‌جا به شکل قابل‌خواندن برای ماشین بیان نشده بود.
نبود idempotency
یک فراخوانی دوباره‌کوشی‌شده تنها زمانی ایمن است که سیستم گیرنده بتواند آن را به‌عنوان یک تلاش دوباره تشخیص دهد. جایی که endpointهای نوشتن کلید idempotency ندارند، یک timeout فراخوان را ناتوان می‌گذارد از تشخیص میان فراخوانی‌ای که شکست خورده و فراخوانی‌ای که موفق شده اما پاسخش گم شده است. اپراتورها این را سریع یاد می‌گیرند و تلاش‌های دوباره خودکار را غیرفعال می‌کنند. سپس agent در نخستین خطای گذرا متوقف می‌شود، چون تنها کنش ایمن در دسترسش توقف و پرسیدن از انسان است.
این یک نقص لوله‌کشی است، نه نقص مدل. همچنین در ارزیابی‌هایی که روی endpointهای sandbox اجرا می‌شوند و هرگز timeout نمی‌خورند، نامرئی است.
مسیرهای نوشتن پشت تأییدیه‌های غیرقابل‌نمایش
مسیرهای خواندن معمولاً بازند، چون خواندن کم‌ریسک است و مدل دسترسی ساده است. مسیرهای نوشتن دروازه‌دارند، و این دروازه معمولاً یک تأیید انسانی است که در یک سیستم تیکت، یک رشته گفتگو یا یک سند سیاست بیان می‌شود. هیچ‌یک از این‌ها نمایش قابل‌خواندن برای ماشین از این ندارند که چه چیزی، تحت چه شرایطی و با چه انقضایی تأیید می‌شود.
بنابراین agent می‌تواند پیشنهاد بدهد اما نمی‌تواند عمل کند، و پیشنهاد مقصد ساختاریافته‌ای ندارد. در صفی فرود می‌آید که یک انسان آن را می‌خواند و دستی دوباره وارد می‌کند، و این یک خودکارسازی را به یک سیستم اطلاع‌رسانی با چند مرحله اضافه تبدیل می‌کند.
طراحی برای هفته دوم
هفته اول هر استقرار agent تحت سلطه تازگی و آسان‌ترین وظایف است. هفته دوم جایی است که سطح یکپارچه‌سازی سرنوشت را تعیین می‌کند. سه رویه این
نرخ شکست نخستین tool call در یک نشست را معیار اصلی پذیرش بدانید. این نخستین نقطه‌ای است که سطح یکپارچه‌سازی می‌تواند agent را رد کند، و نقطه‌ای است که بیشترین همبستگی را با ادامه‌یافتن یا نیافتن نشست دارد. نام ابزار، خطای اعتبارسنجی، تصمیم مجوز و زمان سپری‌شده را ثبت کنید. بر اساس ابزار تجمیع کنید، نه بر اساس کاربر، چون درمان تقریباً همیشه یک تغییر schema است، نه یک مداخله آموزشی.
یک سطح ابزار نوع‌دار با قراردادهای صریح منتشر کنید
تعریف یک ابزار باید پیش‌شرط‌ها، اثرات جانبی و حالت‌های شکستش را به شکلی بیان کند که مدل بتواند مصرف کند و بازبین بتواند حسابرسی کند. به‌طور مشخص، یک ابزار نوشتن باید اعلام کند:
- شناسه‌هایی که نیاز دارد و اینکه از کجا می‌آیند؛
- گذارهای وضعیتی که انجام می‌دهد؛
- اینکه آیا idempotent است، و اگر چنین است تحت کدام کلید؛
- کلاس‌های خطایی که می‌تواند برگرداند، و اینکه کدام‌یک قابل تلاش دوباره است؛
- معناشناسی تأییدیه، در صورت وجود، متصل به عملیات.
این سطح را مانند هر وابستگی دیگری نسخه‌بندی کنید. schema یک ابزار یک رابط با مصرف‌کنندگانی است که انسان نیستند، و اگر بدون مرز نسخه تغییر کند، آن‌ها را بی‌صدا می‌شکند.
به نوشتن‌ها یک وضعیت پیشنهاد بدهید
به‌جای اعطای اختیار تأیید به agent یا سلب کامل آن، یک نوشتن را به‌عنوان عملیاتی دو مرحله‌ای مدل کنید. agent یک پیشنهاد تولید می‌کند: یک شیء نوع‌دار و امضاشده شامل گذار مورد نظر، شواهدی که بر آن تکیه کرده و یک انقضا. یک موتور سیاست یا یک انسان پیشنهاد را تأیید می‌کند، و یک اجراکننده جداگانه آن را اعمال می‌کند.
این به agent مقصدی قابل‌خواندن برای ماشین برای قصدش می‌دهد و به سازمان جایی برای اتصال سیاست. این بده‌بستان واقعی است: وضعیت پیشنهاد به هر نوشتن latency اضافه می‌کند و مستلزم آن است که اجراکننده واقعاً idempotent باشد، چون شکاف میان پیشنهاد و اجرا جایی است که ارسال‌های تکراری ظاهر می‌شوند. تیم‌هایی که برای حفظ latency این مرحله را حذف می‌کنند، معمولاً همان صف انسانی را که می‌خواستند حذف کنند دوباره وارد می‌کنند.
چه کارهایی را باید متوقف کنید
خرید صندلی برای حل یک مشکل لوله‌کشی را متوقف کنید. مجوزهای بیشتر تعداد نشست‌هایی را افزایش می‌دهند که در نخستین tool call ناموفق پایان می‌یابند؛ تعداد نشست‌هایی که تکمیل می‌شوند را افزایش نمی‌دهند. بازده نهایی یک صندلی زمانی که سطح یکپارچه‌سازی قید محدودکننده است، نزدیک به صفر است.
سنجش ساعت‌های صرفه‌جویی‌شده در وظایفی که هرگز تکمیل نشدند را متوقف کنید. برآورد صرفه‌جویی زمان که در برابر وظیفه‌ای محاسبه شود که agent نمی‌تواند تمام کند، پیش‌بینی نیست، محصول جانبی روش برآورد است. نخست تکمیل را بسنجید؛ عدد زمان تنها به‌شرط آن معنادار است.
برخورد با فریم‌ورک agent به‌عنوان لایه یکپارچه‌سازی را متوقف کنید. فریم‌ورک فراخوان است. تصمیم می‌گیرد چه زمانی یک ابزار را فراخوانی کند و نتیجه را چگونه تفسیر کند. این adapter نیست، و نمی‌تواند کمبود سطح ابزاری را که منطق تجاری مورد درخواست را بیان نمی‌کند جبران کند. adapterها، قراردادها و idempotency متعلق به سیستم‌های ثبت‌شده و تیم پلتفرمی است که مالک آن‌هاست.
شکاف میان مجوزها و مصرف زمانی بسته می‌شود که سطح ابزار دیگر یک فکر پس از کار نباشد. آن کار بی‌جلوه است، نسخه‌بندی می‌شود، و همان محصول واقعی است.