عامل هوش مصنوعی (AI Agent) در اصل یک مدل زبانی است که در یک حلقه کار می‌کند: هدف را می‌خواند، درباره اقدام بعدی تصمیم می‌گیرد، ابزاری را فراخوانی می‌کند، نتیجه را می‌بیند و این چرخه را تکرار می‌کند تا به پاسخ برسد یا ناچار به توقف شود. قدرت این حلقه در آن است که مدل می‌تواند جست‌وجو کند، اقدام انجام دهد و خودش را اصلاح کند. اما بیشترین ریسک هم همین‌جاست، چون هر دور از حلقه فرصتی است برای فراخوانی ابزار اشتباه، برداشت نادرست از یک نتیجه یا دور شدن از وظیفه اصلی. در این مقاله می‌بینیم ساخت ایجنت هوش مصنوعی قابل‌اتکا در عمل چه نیازهایی دارد.
تیم‌هایی که عامل‌های واقعاً مفید عرضه می‌کنند، معمولاً به اصول مشترکی می‌رسند. در این مقاله چهار اصل را بررسی می‌کنیم: طراحی ابزار، حافظه، حفاظ‌ها و ارزیابی.
ساخت ایجنت: محدود شروع کنید و گردش کار را صریح کنید
قابل‌اتکاترین عامل‌ها دستیارهای همه‌کاره نیستند؛ مسئول یک کار مشخص‌اند: حل دسته‌ای از تیکت‌های پشتیبانی، آماده‌سازی پرونده پذیرش مشتری یا تطبیق مجموعه‌ای از تراکنش‌ها. پیش از ساخت، گردش کاری را که یک فرد ماهر دنبال می‌کند، تصمیم‌هایی که می‌گیرد و سامانه‌هایی که با آن‌ها کار می‌کند بنویسید. اغلب می‌بینید بخش بزرگی از کار قطعی است و باید صرفاً با کد معمولی پیاده شود. مدل را جایی به کار بگیرید که قضاوت یا زبان لازم است: فهم درخواست، انتخاب میان گزینه‌ها، خلاصه‌سازی و پیش‌نویس.
یک الگوی ذهنی مفید، طیف است. در یک سر آن پایپ‌لاین‌های ثابتی قرار دارند که در برخی مراحل مدل را صدا می‌زنند و در سر دیگر حلقه‌های باز که مدل همه گام‌ها را انتخاب می‌کند. فقط به اندازه‌ای که کار لازم دارد در این طیف جلو بروید. خودمختاری بیشتر یعنی راه‌های بیشتر برای خطا.
طراحی ابزار، همان طراحی رابط است
مدل یک ابزار را فقط از طریق نام، توضیح و طرح‌واره پارامترهایش می‌شناسد. با این‌ها مانند API عمومی برای یک همکار تازه‌وارد رفتار کنید.
- ابزارهای کم و دقیق.
get_customer_balance(customer_id)را به یکrun_sql(query)عمومی ترجیح دهید. ابزارهای محدود را راحت‌تر می‌توان امن کرد، آزمود و میانشان انتخاب کرد. - توضیح دقیق. بنویسید چه زمانی از ابزار استفاده شود و چه زمانی نه، هر پارامتر چه معنایی دارد، واحد و قالب داده چیست و خطا چه شکلی است.
- طرح‌واره سخت‌گیرانه. از پارامترهای نوع‌دار، فهرست مقادیر مجاز و فیلدهای الزامی استفاده کنید و هر فراخوانی را در سمت سرور اعتبارسنجی کنید. هرگز به آرگومان‌های مدل اعتماد نکنید.
- خروجی مفید. خروجی فشرده و ساختاریافته با شناسه‌های روشن برگردانید. نتایج طولانی را آگاهانه کوتاه کنید و این را اعلام کنید. پیام خطای قابل اقدام بدهید («customer_id یافت نشد؛ با find_customer بر اساس تلفن جست‌وجو کنید») تا مدل بتواند مسیر را اصلاح کند.
- تکرارپذیری و ایمنی. تکرار ابزارهای خواندنی باید بی‌خطر باشد. ابزارهای نوشتنی باید از کلید یکتایی عملیات پشتیبانی کنند و اقدام‌های مخرب یا مالی باید بیرون از مدل، توسط انسان یا موتور سیاست، تأیید شوند.
حافظه: تصمیم بگیرید چه چیزی و چرا به خاطر سپرده شود
«حافظه» چند مفهوم متفاوت را در بر می‌گیرد و درهم‌آمیختن آن‌ها سردرگمی می‌سازد.
- زمینه کاری: گفت‌وگوی جاری، نتایج ابزارها و برنامه. این زمینه به پنجره متنی مدل محدود است؛ پس با پیشرفت کار خروجی‌های قدیمی ابزار را خلاصه یا حذف کنید و شناسه‌ها و تصمیم‌ها را نگه دارید.
- وضعیت وظیفه: پیشرفت ساختاریافته‌ای که بیرون از مدل ذخیره می‌شود، مثلاً کدام گام‌ها انجام شده، چه شناسه‌هایی ساخته شده و چه تأییدهایی گرفته شده. آن را در پایگاه داده نگه دارید، نه در متن آزاد، تا عامل پس از خطا بتواند ادامه دهد.
- دانش بلندمدت: اسناد و دستورالعمل‌هایی که هنگام نیاز از طریق RAG بازیابی می‌شوند.
- حافظه کاربر: ترجیحات و اطلاعات مربوط به یک فرد در جلسه‌های مختلف. آن را صریح و با رضایت ذخیره کنید، به کاربر امکان دیدن و حذفش را بدهید و منشأ و تاریخ هر مورد را ثبت کنید تا اطلاعات کهنه منقضی شود.
قاعده سرانگشتی: هر چیزی که باید دقیق باشد، مانند مبلغ‌ها، شناسه‌ها و وضعیت‌ها، در وضعیت ساختاریافته‌ای نگه داشته می‌شود که عامل از طریق ابزار می‌خواند، نه در آنچه مدل اتفاقاً به خاطر دارد.
حفاظ‌ها: دفاع در عمق
هیچ حفاظی به‌تنهایی کافی نیست؛ پس آن‌ها را لایه‌لایه بچینید.
۱. بررسی ورودی. الگوهای تزریق پرامپت، درخواست‌های خارج از محدوده و داده‌های شخصی‌ای را که نباید پردازش شوند تشخیص دهید. محتوایی که از ابزارها می‌رسد، مانند صفحه وب، ایمیل یا سند، داده غیرقابل‌اعتماد است و هرگز نباید اجازه یابد دستور صادر کند.
۲. حداقل دسترسی. مجوزهای عامل باید فقط همان چیزی را ممکن کند که شغلش لازم دارد و به دسترسی کاربر فعلی محدود باشد. این از هر پرامپتی مهم‌تر است.
۳. سیاست روی اقدام‌ها. لایه‌ای قطعی میان مدل و ابزارهایش محدودیت‌ها را اعمال می‌کند: سقف مبلغ، گیرندگان مجاز، محدودیت نرخ، ساعات کاری و تأیید اجباری انسانی برای اقدام‌های برگشت‌ناپذیر.
۴. بررسی خروجی. خروجی ساختاریافته را با طرح‌واره اعتبارسنجی کنید. برای متن‌هایی که به مشتری می‌رسد، ادعاهای بی‌پشتوانه، توصیه‌های ممنوع (مثلاً توصیه سرمایه‌گذاری شخصی‌سازی‌شده در جایی که مجاز نیست) و نشت داده‌های داخلی را بررسی کنید.
۵. سقف منابع و شرط توقف. تعداد دورها، فراخوانی ابزار، توکن و زمان اجرا را محدود کنید. عاملی که در حلقه گیر کند، یک رخداد عملیاتی است.
۶. ردپای ممیزی. هر پرامپت، فراخوانی ابزار، آرگومان، نتیجه و تصمیم را با شناسه ردیابی ثبت کنید. برای اشکال‌زدایی، انطباق با مقررات و ساخت موارد ارزیابی به آن نیاز دارید.
ارزیابی ایجنت هوش مصنوعی: مسیر را بیازمایید، نه فقط پاسخ را
عامل‌ها به شکل‌هایی خطا می‌کنند که شاخص پاسخ نهایی نمی‌بیند: رسیدن به پاسخ درست با فراخوانی ابزاری ممنوع، یا پرداخت یک بازپرداخت اشتباه و سپس عذرخواهی مؤدبانه. در سه سطح ارزیابی کنید.
- آزمون اجزا. در هر تصمیم انتخاب ابزار، آیا مدل ابزار درست را با آرگومان معتبر انتخاب می‌کند؟ این آزمون‌ها سریع‌اند و به اندازه کافی قطعی‌اند که در CI اجرا شوند.
- آزمون مسیر. سناریوهای از پیش نوشته‌شده با ابزارها و کاربران شبیه‌سازی‌شده، شامل مسیرهای عادی، درخواست‌های مبهم، خطای ابزار، ورودی‌های خصمانه و موارد مرزی سیاست‌ها. روی توالی گام‌ها ادعا (assert) کنید: گام‌های الزامی انجام شده، اقدام‌های ممنوع رخ نداده و پیش از هر نوشتن، تأیید گرفته شده است.
- شاخص‌های نتیجه در محیط عملیاتی. نرخ موفقیت وظیفه، نرخ ارجاع، میانگین گام‌ها و هزینه هر وظیفه، زمان حل مسئله و نرخ مداخله انسانی. هر هفته نمونه‌ای از گفت‌وگوها را بازبینی کنید.
مجموعه سناریوها را از خطاهای واقعی بسازید. هر رخداد عملیاتی باید به آزمونی تبدیل شود که پیش از نسخه بعدی اجرا می‌شود. پرامپت، ابزارها و مدل را با هم نسخه‌گذاری کنید و پیش از استقرار، نسخه جدید را روی همان مجموعه با نسخه فعلی مقایسه کنید. چون خروجی مدل‌ها متغیر است، سناریوهای مهم را چند بار اجرا کنید و نرخ قبولی را بسنجید، نه یک نتیجه منفرد را.
الگوی استقرار
مسیر امن به محیط عملیاتی این است: ابتدا حالت سایه (عامل پیشنهاد می‌دهد و انسان اقدام می‌کند)؛ سپس حالت دستیار (عامل پس از تأیید یک‌کلیکی اقدام می‌کند)؛ و بعد خودمختاری برای اقدام‌های کم‌ریسک همراه با نمونه‌برداری و پایش، در حالی که اقدام‌های پرریسک همچنان به تأیید انسانی نیاز دارند. دامنه را فقط وقتی گسترش دهید که شاخص‌ها پشتیبانش باشند.
سخن پایانی
مدل زبانی پیداترین بخش یک عامل است، اما قابلیت اتکا از مهندسی پیرامون آن می‌آید: ابزارهای محدود با قراردادهای سخت‌گیرانه، وضعیتی که بیرون از مدل نگه داشته می‌شود، حفاظ‌هایی که به خوش‌رفتاری مدل وابسته نیستند و ارزیابی‌ای که رفتار را می‌سنجد. اگر این‌ها درست باشند، عامل به همکاری قابل‌اتکا تبدیل می‌شود، نه یک دموی هوشمندانه.