دمو عامل شما کار میکند. این همان تله است.
من برای شرکتها عاملهای هوش مصنوعی میسازم. اغلب شاهد الگوی مشابهی هستم. مدل در دمو کار میکند. محصول را عرضه میکنید. سپس در محیط عملیاتی (production)، از هر سه بار، یک بار شکست میخورد. هیچکس نمیداند چرا.
شکاف بین دمو و محیط عملیاتی، ریاضی است. وقتی ریاضیات را درک کنید، متفاوت میسازید.
اگر هر مرحله در عامل شما ۹۵٪ قابل اعتماد باشد، خوب به نظر میرسد. اما عاملها از زنجیرهای از مراحل استفاده میکنند. اگر ده مرحله را به هم متصل کنید، نرخ موفقیت شما به ۶۰٪ کاهش مییابد. اگر از بیست مرحله استفاده کنید، نرخ موفقیت به ۳۶٪ سقوط میکند.
در کار واقعی، مراحل اغلب نرخ خطای ۱۰٪ تا ۲۰٪ دارند. اگر یک عامل دارای هشت مرحله با قابلیت اطمینان ۸۵٪ باشد، در ۷۵٪ مواقع شکست میخورد.
مشکل از مدل نیست. مشکل از احتمال مرکب (Compounding probability) است.
یک دمو تنها یک «مسیر ایدهآل» (happy path) را نشان میدهد. از ورودیهای تمیز و زنجیرههای کوتاه استفاده میکند. محیط عملیاتی از دادههای نامنظمِ صدها کاربر استفاده میکند. از زنجیرههای طولانی شامل مراحل پنهان استفاده میکند.
شکست در عاملها شبیه به یک کرش (crash) نیست؛ بلکه شبیه به یک خطای بیصدا است.
مرحله ۳ یک فیلد را اشتباه میخواند. خروجی همچنان شبیه به یک JSON معتبر به نظر میرسد. مرحله ۴ از آن دادهی غلط برای استدلال استفاده میکند. مراحل ۵ تا ۸ بر پایه آن اشتباه بنا میشوند. پاسخ نهایی غلط است اما باورپذیر به نظر میرسد. هیچ لاگ خطایی وجود ندارد که به شما نشان دهد کجا اشتباه شده است.
دیگر نگویید مدل دچار توهم (hallucination) شده است. مدل فقط همان دادهی غلطی را که دریافت کرده، منتقل کرده است. سیستم شما فاقد یک نقطه بازرسی (checkpoint) برای شناسایی خطا در مرحله ۳ بود.
از برخورد با عامل به عنوان یک پرامپت دست بردارید. آن را به عنوان یک سیستم در نظر بگیرید.
برای ساخت عاملهای قابل اعتماد، این قوانین را دنبال کنید:
وضعیت (state) را خارج از عامل ذخیره کنید. وضعیت را در یک پایگاه داده نگه دارید، نه در مکالمه. اگر فرآیندی در مرحله ۶ شکست خورد، میتوانید از مرحله ۶ از سر بگیرید. مجبور نیستید کل زنجیره را دوباره شروع کنید.
در مرزها اعتبارسنجی کنید. هر ورودی و خروجی را با یک
schemaچک کنید. خطا را در همان مرحلهای که رخ میدهد، شکار کنید. این کار یک معمای گنگ را به یک خطای قابل بازیابی تبدیل میکند.اثرات جانبی را همارز (idempotent) کنید. وقتی مراحل شکست میخورند، باید آنها را دوباره تلاش (retry) کنید. اگر مرحلهای ایمیلی ارسال میکند یا مبلغی را از کارت کسر میکند، از یک
idempotency keyاستفاده کنید. این کار از انجام اقدامات تکراری در طول تلاش مجدد جلوگیری میکند.در CI خود از ارزیابیها (evals) استفاده کنید. رفتار عامل با هر تغییر کوچک تغییر میکند. تغییر یک پرامپت ممکن است یک مورد را اصلاح کند اما پنج مورد دیگر را خراب کند. از یک مجموعه تست استفاده کنید تا این پسرفتها (regressions) را به طور خودکار شناسایی کنید.
گذار از یک دمو به یک محصول واقعی، موضوع مهندسی است. موضوع مدیریت خطا، مدیریت وضعیت و مشاهدهپذیری (observability) است. موضوع پرامپتهای بهتر نیست.
اگر عامل شما در محیط عملیاتی دچار نوسان و خطا شد، به دنبال مدل بزرگتری نگردید. به دنبال مرحلهای بگردید که زنجیره در آن منحرف شده است. بپرسید چرا سیستم شما نتوانست خطا را در آنجا شناسایی کند.
Source: https://dev.to/sagar_jain4010/your-agent-demo-works-thats-the-trap-4joc
Optional learning community: https://t.me/GyaanSetuAi