روش صحیح ساخت یک معماری هوش مصنوعی

قبلاً فکر می‌کردم هوشمندتر کردن دستیار هوش مصنوعی‌ام به معنای اضافه کردن ابزارهای بیشتر به همان حلقه (loop) است. این روش تا مدتی جواب داد. اما بعد، دستیار من مجبور شد وظایف عادی کاربران را انجام دهد؛ کارهایی مثل ادامه دادن یک تسک از طریق چت، پاسخ به سوالی درباره وضعیت (status)، یا به خاطر سپردن یک گردش کار (workflow).

مشکل این نبود که دستیار من چند ابزار می‌تواند فراخوانی کند، بلکه مشکل معماری آن بود. معماری قدیمی ساده بود: پیام کاربر -> حلقه دستیار -> ابزارها -> پاسخ. این برای یک نسخه دموی اولیه خوب است، اما برای یک دستیار همیشگی (resident assistant) مناسب نیست.

یک دستیار همیشگی باید بداند که آیا یک پیام، یک تسک جدید است، یک پیگیری است یا یک لغو کردن. این دستیار باید از تصاحب کنترل دسکتاپ از تسک دیگر جلوگیری کند و بدون استفاده از متن‌های گفتگو (transcripts) قدیمی، مراحل کار را به خاطر بسپارد.

بنابراین، دیگر به دستیارم به عنوان یک عامل (agent) واحد نگاه نکردم و شروع کردم به برخورد با آن به عنوان یک صفحه کنترل محلی (local control plane). اکنون معماری من به این شکل است:

من همچنین یک Observation Plane و یک Memory / Policy Plane دارم. این صفحات به دستیار من کمک می‌کنند تا منطقی عمل کرده و روی وظایف خود متمرکز بماند.

بزرگترین بهبود زمانی حاصل شد که دستیارم را وادار کردم به جای لاگ‌های خام (raw logs)، مشاهدات (observations) را مصرف کند. این کار به دستیار من کمک می‌کند تا به جای خواندن یک متن گفتگوی طولانی، حقایق فشرده‌ای مثل «تسک X در انتظار تایید است» را ببیند.

یاد گرفتم که «به خاطر سپردن» با پر کردن بیش از حد تاریخچه چت در یک پرامپت (prompt) یکی نیست. برای دستیار من، حافظه مبتنی بر فایل و محدود به محدوده (scoped) مشخص است. می‌تواند یک گردش کار، یک حقیقت یا یک مرجع را ذخیره کرده و در صورت نیاز آن را فراخوانی کند.

اگر در حال ساخت عامل‌ها (agents) حول ابزارهای موجود هستید، آیا همه چیز را درون یک حلقه قرار می‌دهید، یا شروع به جداسازی کنترل، اجرا، مشاهده و حافظه کرده‌اید؟

Source: https://dev.to/codekingai/my-ai-assistant-needed-a-control-plane-not-a-bigger-loop-15aa Optional learning community: https://t.me/GyaanSetuAi