واژه «agent» در حال از دست دادن معنای خود است. اکنون هر اعلان محصولی را که مرور کنید، هر ویژگی هوش مصنوعی ادعا میکند که یک agent است. یک ویجت دوستانه که پیشنویس ایمیل تولید میکند؟ Agent. یک بات پشتیبانی که پایگاه دانش شما را میخواند؟ Agent. اسکریپتی که یک API را فراخوانی کرده و JSON برمیگرداند؟ آن هم یک agent است. این فقط یک بازاریابی بیدقت نیست؛ بلکه یک طراحی خطرناک است. وقتی همه چیز را agent مینامید، دیگر درک نمیکنید که واقعاً در حال ساخت چه چیزی هستید. پیش از آنکه وظیفه را تعریف کنید، به سراغ معماریهای پیچیده میروید. نتیجه، کدهای شکننده، هزینههای سرسامآور توکن و سیستمهایی است که به روشهایی رفتار میکنند که نمیتوانید توضیح دهید یا بازتولید کنید.
چتباتها منتظر میمانند، آنها عمل نمیکنند
چتباتها سادهترین سطح را اشغال میکنند. آنها واکنشی هستند. کاربر سوالی را تایپ میکند، مدل پاسخی تولید میکند و گفتگو در همانجا تمام میشود، مگر اینکه پرامپت انسانی دیگری برسد. این سیستمها تصمیم نمیگیرند که تقویم شما را چک کنند، یک رکورد پایگاه داده را بهروزرسانی کنند یا برای شفافسازی مکث کنند. یک ویجت کمکِ تعبیهشده در صفحه قیمتگذاری یک SaaS را در نظر بگیرید. این ویجت به سوالات مربوط به چرخههای صورتحساب و محدودیتهای ویژگیها پاسخ میدهد. اما مبلغی را به مشتری مسترد نمیکند، طرحی را ارتقا نمیدهد یا حساب مشکوکی را علامتگذاری نمیکند. این سیستم هیچ ابزاری ندارد، هیچ وضعیت پایداری فراتر از پنجره چت ندارد و هیچ هدفی جز تولید یک جمله مرتبط ندارد. این یک چتبات است. او پاسخ میدهد؛ اما عمل نمیکند.
دستیارها در محدوده یک پنجره کمک میکنند
دستیارها بدون افزودن «عاملیت» (agency)، پیچیدگی را افزایش میدهند. آنها از سیستم پرامپتها برای اتخاذ یک شخصیت استفاده میکنند. آنها بافت (context) را در طول گفتگوهای طولانیتر حفظ میکنند. آنها ممکن است سندی را که آپلود کردهاید خلاصه کنند یا پاراگراف شما را با لحنی متفاوت بازنویسی کنند. یک دستیار نویسنده که گرامر شما را بررسی میکند و عبارتهای شفافتر را پیشنهاد میدهد، مفید است. او به خاطر میآورد که شما املای بریتانیایی را ترجیح میدهید. اما او به نیابت از شما اقدامی انجام نمیدهد. او تصمیم نمیگیرد که به ویرایشگر شما ایمیل بزند، ضربالاجلی تعیین کند یا بدون درخواست، در وب جستجو کند. او در همان پنجرهای که شما فراهم کردهاید کمک میکند. او رانندگی نمیکند؛ بلکه در حالی که شما دستهایتان را روی فرمان نگه داشتهاید، مسیر بهتری را پیشنهاد میدهد.
گردشهای کاری از نقشهای که ترسیم کردهاید پیروی میکنند
گردشهای کاری (Workflows) در محدوده میانی قرار دارند، جایی که اکثر سیستمهای هوش مصنوعی عملیاتی واقعاً متعلق به آن هستند. در اینجا، شما مسیر را تعریف میکنید. شما مجموعهای از مراحل را میسازید: استخراج تاریخ فاکتور، جستجوی شناسه فروشنده، مقایسه مبلغ با سفارش خرید، بهروزرسانی صفحه گسترده حسابداری، و ارسال اعلان به بخش مالی در صورت عدم تطابق اعداد. مدل ممکن است فاکتور را بخواند یا یک اختلاف را طبقهبندی کند، اما از گراف شما پیروی میکند. شما دقیقاً میدانید چه اتفاقی خواهد افتاد زیرا نقشه را خودتان ترسیم کردهاید.
تست کردن گردشهای کاری آسانتر است. شما میتوانید هر مرحله را به صورت مجزا تست واحد (unit-test) کنید. میتوانید ورودیها و خروجیها را در هر گره (node) ثبت کنید. وقتی چیزی خراب میشود، بدون جستجو در یک زنجیره فکری مبهم، میدانید کدام شاخه با شکست مواجه شده است. مشاهدهپذیری (Observability) مستقیم است زیرا سیستم با تغییر مسیرهای غیرمنتظره شما را غافلگیر نمیکند. اگر فرآیند کسبوکار شما قوانین روشن و استثناهای مشخصی دارد، معمولاً یک گردش کار برنده است. شما سرعت، قابلیت اطمینان و هزینههای کمتر را بدون تظاهر به اینکه ماشین دارای نیت و قصد است، به دست میآورید.
عاملها مسیر را انتخاب میکنند
عاملها (Agents) متفاوت هستند. آنها پویا هستند. شما به آنها یک هدف میدهید و آنها راه رسیدن به آن را پیدا میکنند. یک عامل وظیفهای را دریافت میکند، تحلیل میکند که چه چیزی باید اتفاق بیفتد، ابزارها را انتخاب میکند، اجرا میکند، نتیجه را مشاهده میکند و سپس تصمیم میگیرد که مرحله بعدی چیست. آن حلقه — استدلال، عمل، مشاهده، و دوباره استدلال — همان چیزی است که یک عامل را از سایر دستهها متمایز میکند.
سیستمی را در نظر بگیرید که درخواستهای بازپرداخت را مدیریت میکند. یک گردش کار ممکن است سه شرط را بررسی کند و بر اساس قوانین ثابت، درخواست را تایید یا رد کند. یک عامل، با داشتن هدفِ «این بازپرداخت را به شکلی منصفانه و همزمان با بررسی تقلب پردازش کن»، ممکن است تاریخچه خرید مشتری را پرسوجو کند، سیاست مرجوعی را برای آن دسته از محصولات بررسی کند، فعالیتهای اخیر حساب را جستجو کند، اگر الگو غیرعادی به نظر رسید یک تیکت پشتیبانی برای بررسی دستی ایجاد کند و سپس پیشنویس ایمیلی برای توضیح تصمیم خود بنویسد. او بر اساس جزئیات مورد، انتخاب کرد که از کدام ابزارها و با چه ترتیبی استفاده کند.
یک عامل یک سیستم است، نه فقط یک مدل
یک عامل، مدلی نیست که در یک پنجره چت اجرا شود. بلکه یک سیستم کامل است. این سیستم ترکیبی از موارد زیر است:
- مدلها برای استدلال و تولید زبان
- دستورالعملها که فضای عملیاتی آن را محدود میکنند
- ابزارها با طرحوارههای (schemas) دقیق برای تعامل با دنیای خارج
- زمینه درباره وظیفه و محیط فعلی
- وضعیت تا بداند در یک فرآیند چند مرحلهای در کجا قرار دارد
- اعتبارسنجیها برای بررسی ورودیها قبل از ورود به یک ابزار و بررسی خروجیها قبل از رسیدن به کاربر
- محدودیتها در بودجه، مراحل یا محدوده برای جلوگیری از رفتارهای خارج از کنترل
- مشاهدهپذیری تا بتوانید بازسازی کنید که چرا مسیر A را به جای مسیر B انتخاب کرده است
اگر سیستم شما فاقد اکثر این موارد باشد، شما یک عامل (agent) ندارید؛ بلکه فقط یک مدل با فراخوانیهای اضافی API دارید.
خودمختاری بدون کنترل، فقط ریسک است
اگر عامل شما بتواند پایگاه داده عملیاتی شما را پرسوجو کند، در CRM شما رکورد ایجاد کند یا به کاربران پیام بفرستد، میتواند دادهها را نیز خراب کند، ورودیهای تکراری ایجاد کند یا به مشتریان اسپم بفرستد. یک معماری خوب برای عامل، احتمال خطا را پیشفرض میگیرد. قبل از اقدامات مخرب، اجازه میگیرد. قبل از ثبت نتایج، اعتبارسنجیها را اجرا میکند. استدلال خود را آشکار میکند تا زمانی که هزینهها یا مخاطرات بالا میرود، یک انسان بتواند مداخله کند.
اگر این محدودیتها را نادیده بگیرید چون دمو هیجانانگیز به نظر میرسید، آخر هفتههای خود را صرف عیبیابی این خواهید کرد که چرا عامل در طول شب چهارصد تیکت پشتیبانی ایجاد کرده یا سفارشی را که نباید به آن دست میزد، مسترد کرده است. غیرقابلپیشبینی بودنی که در سیستمهای جعبهسیاه از آن میترسیدید، دقیقاً همان لحظهای واقعی میشود که هم یک هدف و هم مجموعهای از ابزارهای بدون نظارت را به هوش مصنوعی میسپارید.
با مسئله شروع کنید، نه با فناوری
با عامل شروع نکنید. با درد (مشکل) شروع کنید. گاهی اوقات راه حل، یک پرامپت بهتر است. گاهی اوقات یک تابع قطعی در بکاند موجود شماست. گاهی اوقات یک گردش کار با یک مرحله هوش مصنوعی و پنج فراخوانی API سنتی است.
تنها زمانی به سراغ عاملها بروید که وظیفه واقعاً نیازمند موارد زیر باشد:
- مراحل متعددی که به یکدیگر وابسته هستند
- تصمیمگیری پویا بین آن مراحل
- تعامل با ابزارهای خارجی
- استدلال بر روی نتایج میانی که نمیتوانید از قبل بهطور کامل آنها را ترسیم کنید
اگر مسیر مشخص است، یک گردش کار بسازید. اگر تعامل ساده است، یک چتبات یا دستیار بسازید. صرفاً به این دلیل که کلمه «عامل» مدرن به نظر میرسد، به آن قابلیت عاملیت اضافه نکنید.
بلوغ بسازید، نه پیچیدگی
وقتی یک عامل واقعاً گزینه مناسبی است، آن را در لایهها بسازید. با یک ابزار واحد و یک تصمیم از پیش تعیینشده شروع کنید. تستهایی اضافه کنید که تأیید کنند ابزار با آرگومانهای صحیح فراخوانی میشود. لاگگذاری اضافه کنید تا بتوانید ردپای کامل را ببینید. مدیریت وضعیت اضافه کنید تا سیستم بداند از کجا متوقف شده بود. در هر مرز، اعتبارسنجی اضافه کنید. داشبوردهای مشاهدهپذیری اضافه کنید تا تیم شما بتواند رفتار سیستم را بهصورت لحظهای نظارت کند. در نهایت، با دقت خودمختاری را اضافه کنید—یعنی آزادی انتخاب بین گزینهها. این کار را برعکس انجام ندهید. لایهبندی خودمختاری روی آشفتگی، منجر به حوادث پرهزینه میشود.
نکته اصلی
کلمات به سیستمها شکل میدهند. اصطلاح «عامل» را برای معماریهایی رزرو کنید که شایسته آن هستند: هدفگرا، ابزار-محور و بهطور پویا تطبیقپذیر، اما محصور در محدودیتهای سختگیرانه و نظارت انسانی. هر چیز دیگری یک چتبات، یک دستیار یا یک گردش کار است. سادهترین چیزی را که مشکل را حل میکند بسازید. لاگهای عملیاتی، تیم مالی و خودِ آیندهتان از شما سپاسگزار خواهند بود.
منبع: https://dev.to/leandrolayerle/no-todo-chatbot-es-un-agente-de-ia-3oec
به جامعه یادگیری GyaanSetu بپیوندید: https://t.me/GyaanSetuAi