چرا اکثر عامل‌های هوش مصنوعی بیش از حد پیچیده طراحی می‌شوند

عامل‌های هوش مصنوعی همه‌جا هستند. شما شاهد انبوه عامل‌ها (agent swarms)، تیم‌های خودگردان و سیستم‌های خوداصلاح‌گر هستید. هر هفته، یک فریم‌ورک جدید وعده می‌دهد که نسل بعدی هوش مصنوعی را بسازد.

پس از مطالعه جریان‌های کاری (workflows) هوش مصنوعی، به یک نتیجه‌گیری ساده رسیده‌ام. اکثر عامل‌های هوش مصنوعی بیش از حد پیچیده طراحی شده‌اند.

عامل‌ها بی‌فایده نیستند. با این حال، بسیاری از سازندگان، مشکلاتی را با استفاده از عامل‌ها حل می‌کنند در حالی که می‌توانستند از چیز ساده‌تری استفاده کنند.

صنعت عاشق پیچیدگی است

تصور کنید می‌خواهید سیستمی برای خواندن فایل‌های PDF، استخراج داده‌ها و پاسخ به سوالات بسازید. بسیاری از سازندگان یک معماری پیچیده با شش عامل، چندین پرامپت و مدیریت وضعیت (state management) ایجاد می‌کنند. این کار باعث سردرگمی‌های زیادی می‌شود.

همان مشکل اغلب با یک توالی ساده حل می‌شود:

  • PDF به Chunk
  • Chunk به Embed
  • Embed به Vector DB
  • LLM به Response

گاهی اوقات یک جریان کاری کافی است. شما به یک ارتش از عامل‌ها نیاز ندارید.

جریان‌های کاری اکثر مشکلات را حل می‌کنند

اکثر برنامه‌های هوش مصنوعی قطعی (deterministic) هستند. آن‌ها از یک توالی مشخص پیروی می‌کنند. نمونه‌ها عبارتند از:

  • پرسش و پاسخ از اسناد (Document Q&A)
  • پشتیبانی مشتری
  • خلاصه‌سازی جلسات
  • تولید پست وبلاگ
  • بازبینی کد (Code review)

این‌ها جریان‌های کاری هستند، نه سیستم‌های خودگردان. جریان‌های کاری برای عیب‌یابی (debug)، مقیاس‌پذیری، نگهداری و توضیح دادن، آسان‌تر هستند.

عامل‌ها هزینه‌های پنهانی ایجاد می‌کنند

هر عامل جدید مشکلات جدیدی اضافه می‌کند:

  • هزینه‌های بالاتر توکن به دلیل پرامپت‌های بیشتر
  • تأخیر (latency) بیشتر به دلیل مراحل اضافی
  • شانس بیشتر برای توهم (hallucination)
  • عیب‌یابی دشوارتر
  • نیازهای زیرساختی بیشتر

یک برنامه ساده به یک پروژه مهندسی عظیم تبدیل می‌شود.

جایی که عامل‌ها واقعاً می‌درخشند

من مخالف عامل‌ها نیستم. عامل‌ها زمانی مفید هستند که:

  • وظایفی برای مدت طولانی اجرا شوند، مانند تحقیق در چندین وب‌سایت.
  • تصمیم‌گیری بر اساس منطق خاص مورد نیاز باشد.
  • مداخله انسانی بخشی از چرخه باشد.
  • ابزارهای مختلف مانند Slack، GitHub و ایمیل باید با هم همکاری کنند.

قانون من

سازندگان اغلب مستقیماً به سراغ فریم‌ورک‌های پیچیده می‌روند. قبل از انجام این کار، یک سوال بپرسید: آیا یک جریان کاری می‌تواند این مشکل را حل کند؟

اگر پاسخ مثبت است، از همان‌جا شروع کنید. فقط زمانی عامل‌ها را اضافه کنید که پیچیدگی آن را ایجاب کند.

از این اصل پیروی کنید:

  • اول جریان کاری (Workflow).
  • دوم عامل (Agent).
  • و در آخر، چندعاملی (Multi-agent).

پیچیدگی به معنای نوآوری نیست. پیچیدگی یعنی هزینه. کاربران اهمیتی نمی‌دهند که شما از چند عامل استفاده می‌کنید؛ آن‌ها اهمیت می‌دهند که آیا ابزار کار می‌کند یا خیر. سادگی یک ویژگی (feature) است.

منبع: https://dev.to/jaideepparashar/why-i-think-most-ai-agents-are-overengineered-249o