تصور کنید یک برنامهنویس در تیمی کوچک است که هر شب با گزارشهای متناقض کاربران از توهمات مدل بیدار میشود. در دنیای عاملهای هوش مصنوعی، تنها حقیقتی که اهمیت دارد، شکست در محیط عملیاتی است؛ اما اکثر تیمها هنوز برای حل این بحران به گزارشهای دستی و تستهای واحد (Unit Tests) شکننده تکیه میکنند.
Tracely-ai با تبدیل خودکار ردپاهای (Traces) زنده در محیط عملیاتی به تستهای رگرسیون (Regression Tests) هرمتیک، این شکاف را پر میکند. این سیستم اجازه نمیدهد کد جدید مستقر شود مگر اینکه ثابت شود خطای قبلی واقعاً رفع شده است.
همانطور که در تحلیل قبلی ما دربارهی پروتکل Agent2Agent اشاره کردیم، صنعت اکنون از اتصال سادهی مدلها به سمت قابلیت اطمینان سختگیرانه حرکت میکند. برای اکثر توسعهدهندگان، استقرار فعلی مدلها شبیه به قمار است. شما یک پرامپت را ارسال میکنید، تستهای اولیه سبز میشوند، اما ساعتها بعد کاربران گزارش میدهند که مدل دچار توهم (Hallucination) — مثل دوستی که خاطرهای را با اطمینان اما اشتباه تعریف میکند — شده یا APIها کرش کردهاند.
این مشکل به این دلیل رخ میدهد که مدلهای زبانی بزرگ (LLM) — شبیه کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — ماهیتی احتمالی (Stochastic) دارند. وقتی پاسخ یک ابزار تغییر میکند یا ساختار یک API بالادستی عوض میشود، تستهای استاتیک روی پرامپتهای سیستمی بیفایده میشوند و توسعهدهنده عملاً در حال تعقیب ارواح در لاگهای اسلک است.
بستر شکستهای عاملمحور
طبق گزارشهای فنی، بررسیهای سنتی CI/CD به محض مواجهه با واقعیت شکست میخورند. شکستها اغلب از تغییرات ناگهانی در پاسخ ابزارها یا ورود عاملها به حالتهای پیشبینینشده ناشی میشوند. دادههای استاتیک این خطاها را نمیبینند چون این باگها فقط تحت فشار واقعی و توزیعشده ظاهر میشوند. این چالشها نشان میدهند که ارزیابیهای سنتی دیگر کافی نیستند و باید به سراغ رویکردهای جدیدتری برای سنجش پایداری و تزریق خطا در عاملهای هوشمند رفت تا نقاط ضعف سیستم پیش از رسیدن به کاربر شناسایی شوند.
اکثر تیمها در حال حاضر به برچسبگذاری دستی و اسکریپتهای «هشدار در صورت خطا» متکی هستند. این مدل با گسترش سرویسها فرو میپاشد. وقتی توسعهدهندگان خطاها را دستی بررسی میکنند، رگرسیونها بهطور اجتنابناپذیری به محیط عملیاتی میرسند، زیرا هیچ حلقه بازخورتی که توسط انسان مدیریت شود، قابلیت مقیاسپذیری ندارد.
سازوکار انجماد خطا
Tracely-ai این فرآیند دستی را با یک قرارداد کد-محور جایگزین میکند. این سیستم از یک چرخه «ضبط و انجماد» خاص پیروی میکند:
- ضبط کامل ردپا: میانافزار تمام ورودیها، گامهای مدل و جفتهای «فراخوانی ابزار-نتیجه» را ثبت میکند.
- خوشهبندی خطاها: خطاهای مشابه را حذف میکند تا بهجای بمباران توسعهدهنده با لاگهای تکراری، رگرسیونهای منحصربهفرد را نمایش دهد.
- مهروموم هرمتیک: پاسخهای ابزار و دادههای پویا مهروموم میشوند. تست دیگر API زنده را فراخوانی نمیکند، بلکه دقیقاً همان دادهای را بازپخش میکند که باعث کرش اولیه شده بود.
- یکپارچگی با CI: این آرتیفکتهای JSON به خط لوله CI تزریق میشوند. اگر تغییر در کد دوباره باعث بروز همان خطا شود، بیلد (Build) شکست میخورد.
جزئیات فنی: از ردپا تا تست
به نقل از مستندات Tracely-ai، وقتی یک ردپای عملیاتی شکست میخورد — چه یک فراخوانی اشتباه ابزار باشد و چه یک کرش غیرقابلتکرار — سیستم آن را به عنوان یک آرتیفکت تست حداقلی سریالسازی میکند.
برای مثال، شکست در جستوجوی پرواز به صورت یک شیء JSON شامل موارد زیر ثبت میشود:
- شناسه مورد و برچسب زمانی: مثلاً
ab12cd34در تاریخ ۱۲ ژوئن ۲۰۲۴. - ورودی کاربر: «ارزانترین پرواز نیویورک به سانفرانسیسکو برای سهشنبه آینده را پیدا کن».
- فراخوانی ابزار: ثبت درخواست
FlightAPIو خطایUpstream 500: Rate limit exceeded. - نوع شکست: برچسب
UncaughtExternalErrorبا یادداشت: «باید جریان تلاش مجدد را نمایش دهد، نه عذرخواهی از کاربر».
سپس با استفاده از یک FlightAPIStub که دادههای مهرومومشده را دارد، تست اجرا میشود. اگر مدل بهجای مدیریت خطا، صرفاً از کاربر عذرخواهی کند، CI استقرار را مسدود میکند.
اثر واقعی: مورد تغییر ساختار (Schema Drift)
توسعهدهندگان برای اثبات کارایی، موردی از یک سرویس بزرگ سفر را مثال میزنند. در ۸ ژوئن ۲۰۲۴، یک سرویس بکاند بهطور بیصدا ساختار خطای خود را تغییر داد. فرمت قدیمی یک رشته ساده بود، اما فرمت جدید به کد خطا و پیام مجزا تغییر کرد.
تستهای محلی چون از دادههای قدیمی استفاده میکردند، پاس شدند. اما Tracely-ai فوراً صدها شکست عملیاتی با ساختار جدید را شناسایی کرد. با انجماد اولین مورد از این ساختار جدید در یک تست رگرسیون، تیم توانست ادغام کدی که باعث شکست سیستم میشد را قبل از انتشار گسترده متوقف کند.
لاگهای سایه نشان داد که بیش از ۱,۳۰۰ جلسه کاربری در ۲۴ ساعت با این خطا مواجه میشدند. پیش از این، چنین تغییراتی باعث افت نرخ تبدیل در تعطیلات آخر هفته میشد، اما اکنون اثر این حادثه به نزدیک صفر رسید.
چرا هرمتیک بودن حیاتی است؟
بسیاری از تیمها سعی میکنند «ردپاها» را ضبط کنند، اما چون تستها هرمتیک نیستند شکست میخورند. اگر تست به یک API زنده وابسته باشد، ممکن است امروز پاس شود چون API سالم است، در حالی که منطق عامل هنوز خراب است. این یک اثر «پلاسیبو» ایجاد میکند که در آن CI سبز است اما محیط عملیاتی میسوزد.
Tracely-ai با جایگزینی هر فراخوانی ابزار با یک استاب (Stub)، از این مشکل جلوگیری میکند. این یعنی تست، آینهای دقیق از شرایط شکست است، فارغ از اینکه دنیای بیرون در چه حالتی است.
تغییر پارادایم توسعه عاملها
این رویکرد فرض بنیادی توسعه عاملها را تغییر میدهد. بهجای تلاش برای پیشبینی تمام حالتهای شکست از طریق ارزیابیهای مصنوعی، توسعهدهندگان اکنون محیط عملیاتی را به عنوان منبع اصلی حقیقت میپذیرند.
برای متخصصان، این به معنای پایان چرخه «تغییر پرامپت و دعا برای جواب دادن» است. هر گزارش باگ به یک دارایی دائمی در کد تبدیل میشود. دیگر نمیپرسیم که آیا عامل «باهوشتر» شده است یا خیر؛ بلکه میپرسیم آیا هنوز در همان مورد خاصی که سهشنبه گذشته باعث ضرر مالی شرکت شد، شکست میخورد یا نه.
با تجهیز پشتههای عاملمحور به این چرخه ضبط و بازپخش، تیمها حلقهای را میبندند که CI/CD در اصل برای تضمین آن طراحی شده بود. هر خطای عملیاتی به یک تست تبدیل میشود و هر تست پاسشده، گواهی است بر اینکه آخرین باگ واقعی حذف شده است.
گام بعدی شما
- مخزن متنباز Tracely-ai در گیتهاب را بررسی کنید تا نحوه ادغام میانافزار ضبطکننده را در گردشکارهای خود بیاموزید.
- لیست خطاهای تکراری محیط عملیاتی خود را استخراج کرده و آنها را به تستهای هرمتیک تبدیل کنید.
- استراتژی تستهای خود را از «تستهای واحد استاتیک» به «تستهای رگرسیون مبتنی بر ردپا» تغییر دهید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو