ایجنت هوش مصنوعی چیست؟ تفاوت ایجنت، چتبات و ورکفلو
وقتی می‌خواهیم یک کار را با هوش مصنوعی انجام بدهیم، سه پرسش از نام ابزار مهم‌ترند: چه کسی گام بعدی را انتخاب میکند، نرم‌افزار به چه ابزارهایی دسترسی دارد و از کجا می‌فهمیم کار تمام شده است؟ پاسخ این پرسش‌ها کمک میکند میان یک گفت‌وگوی ساده، یک ورکفلو و یک ایجنت تفاوت بگذاریم.
ایجنت را با نحوهٔ تصمیم‌گیری بشناسیم
در این نوشته، ایجنت هوش مصنوعی به سامانه‌ای گفته می‌شود که مدل در آن، با توجه به هدف و نتیجهٔ گام‌های قبلی، اقدام بعدی یا ابزار مناسب را انتخاب میکند. این تعریف، بر معماری و رفتار سامانه تکیه دارد؛ نام «ایجنت» روی یک محصول به‌تنهایی نشان نمی‌دهد که واقعاً چنین اختیاری دارد.
چتبات و ورکفلو چه تفاوتی دارند؟
چتبات یک شکل تعامل است: کاربر پیام می‌دهد و سامانه پاسخ می‌دهد. پشت این رابط ممکن است فقط یک فراخوانی مدل، یک مسیر ثابت یا حتی یک ایجنت قرار داشته باشد. بنابراین رابط گفت‌وگویی را نمی‌توان به‌تنهایی معیار معماری دانست.
در یک ورک‌فلوی از پیش تعریف‌شده، برنامه‌نویس ترتیب کارها و شرط‌های جابه‌جایی را تعیین میکند. مدل می‌تواند در یکی از مرحله‌ها متن را خلاصه یا داده را استخراج کند، اما مسیر اجرا همچنان تابع قواعد برنامه است. در تعریف این مقاله، وقتی مدل خودش مسیر و استفاده از ابزار را هدایت میکند، به معماری ایجنت نزدیک می‌شویم.
یک مثال آموزشی: بررسی درخواست پروژه
فرض کنید فرم درخواست پروژه شامل توضیح و چند فایل است. یک مسیر ثابت می‌تواند ابتدا کامل‌بودن فرم را بررسی کند، سپس توضیح را خلاصه کند و نتیجه را برای بازبینی آماده بگذارد. اگر ترتیب مراحل از قبل روشن باشد، برای این کار الزاماً به تصمیم‌گیری بازِ یک ایجنت نیاز نداریم.
حالا مسئله را تغییر بدهیم: سامانه باید تشخیص دهد چه اطلاعاتی کم است، از میان ابزارهای مجاز یکی را انتخاب کند و پس از دیدن نتیجه تصمیم بگیرد ادامه بدهد یا درخواست توضیح کند. این رفتار به ایجنت نزدیک‌تر است. این مثال صرفاً آموزشی است و گزارش یک محصول یا پروژهٔ انجام‌شدهٔ تیم نیست.
پیش از دادن ابزار، قرارداد اجرا را روشن کنیم
هدف و معیار پایان را جدا بنویسیم. «بررسی درخواست» مبهم است؛ «آماده‌کردن خلاصه و فهرست اطلاعات ناقص برای بازبینی انسان» خروجی روشن‌تری دارد. سپس مشخص کنیم چه فایل‌هایی قابل خواندن‌اند، کدام ابزارها مجازند و چه اقدام‌هایی به تأیید انسان نیاز دارند. انتخاب ابزار توسط مدل، جایگزین کنترل دسترسی در کد نیست.
برای هر اجرا سقف گام، زمان یا هزینه تعیین کنیم و نتیجهٔ ابزارها را ثبت کنیم. اگر مدل چند بار به همان وضعیت برگشت یا اطلاعات لازم در دسترس نبود، توقف و اعلام مسئله از ادامه‌دادن بی‌پایان مفیدتر است. بازبینی خروجی هم باید نتیجهٔ واقعی ابزارها را بسنجد، نه فقط توضیحی را که مدل دربارهٔ موفقیت خود نوشته است.
از کجا بفهمیم انتخاب مناسبی کرده‌ایم؟
پیش از اجرا، چند ورودی نماینده تعریف کنیم: درخواست کامل، درخواست ناقص، فایل نامعتبر و نتیجهٔ متناقض. خروجی مورد انتظار و اقدام ممنوع را برای هر کدام مشخص کنیم. در مقایسهٔ مسیر ثابت و ایجنت، کیفیت نتیجه، نیاز به اصلاح انسانی، زمان و هزینه را روی همان ورودیها ثبت کنیم. بدون چنین آزمونی، ادعای سریع‌تر یا بهتر بودن معنا و پشتوانهٔ کافی ندارد.
اگر مسئله با قواعد روشن حل می‌شود، از همان راه ساده شروع کنیم. پیچیدگی بیشتر زمانی ارزش بررسی دارد که نیاز مشخصی را پاسخ بدهد. این نوشته یک چارچوب تصمیم‌گیری است؛ نتیجهٔ مناسب هر کاربرد به داده‌ها، ابزارها و سطح اختیاری که می‌دهیم وابسته است.
منبع و مطالعهٔ تکمیلی
تعریف معماری ایجنت و ورکفلو در این نوشته با تفکیک ارائه‌شده در راهنمای Anthropic سازگار است. مثال درخواست پروژه و پیشنهادهای آزمون، توضیح آموزشی این مقاله‌اند.
پرسش و پاسخ
آیا هر چتبات یک ایجنت است؟
خیر. چتبات شکل تعامل را توصیف میکند. برای تشخیص ایجنت باید بررسی کنیم چه چیزی مسیر اجرا و استفاده از ابزارها را هدایت میکند.
آیا ایجنت همیشه از ورکفلو بهتر است؟
خیر. انتخاب به مسئله، قابلیت پیشبینی مسیر، کیفیت موردنیاز و هزینه بستگی دارد. مقایسه باید با ورودیها و معیارهای مشخص انجام شود.