معماری ایجنت هوش مصنوعی: مدل، ابزار، حافظه و برنامه ریزی

معماری ایجنت هوش مصنوعی زمانی خوب است که بتوان رفتار سامانه را توضیح داد، خطا را تا منشا دنبال کرد و هر بخش را بدون بازنویسی کل محصول تغییر داد. چسباندن یک مدل زبانی به چند API شاید در نمایش اولیه کار کند، اما برای محصول واقعی به مرزبندی روشن نیاز داریم.

لایه هدف و دستور

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

لایه مدل و تصمیم

مدل درخواست، وضعیت فعلی و نتیجه ابزارها را تفسیر می کند. در این بخش باید میان کیفیت، سرعت، هزینه و ظرفیت زمینه تعادل برقرار شود. بعضی معماری ها برای کار ساده از مدل سریع و برای تصمیم سخت از مدل قوی تر استفاده می کنند. این مسیریابی فقط وقتی مفید است که با ارزیابی واقعی پشتیبانی شود.

لایه ابزار

ابزار باید یک قرارداد محدود و قابل فهم داشته باشد. نام دقیق، ورودی ساختارمند، خروجی قابل پیش بینی و خطای روشن، احتمال تصمیم اشتباه را کم می کند. ابزار عمومی با دسترسی وسیع، سطح خطر را بالا می برد. اصل دسترسی حداقلی در اینجا به معنای ساخت ابزارهای کوچک برای عمل مشخص است.

حافظه و وضعیت چه تفاوتی دارند؟

وضعیت، داده لازم برای همین اجرای جاری است؛ مانند هدف، مرحله فعلی و نتیجه آخرین ابزار. حافظه، اطلاعاتی است که ممکن است در اجراهای بعدی هم ارزش داشته باشد. نگهداری همه گفتگوها به عنوان حافظه، هم هزینه را زیاد می کند و هم خطای زمینه می سازد. بهتر است حافظه انتخاب، خلاصه و تاریخ انقضا داشته باشد.

برنامه ریزی و اجرای گام ها

برای کار کوتاه، تصمیم قدم به قدم کافی است. برای کار طولانی، ساخت یک برنامه اولیه و بازبینی آن پس از هر مشاهده مفید است. برنامه نباید قرارداد تغییر ناپذیر باشد؛ نتیجه ابزار می تواند فرض اولیه را رد کند. سقف تعداد گام و زمان از حلقه بی پایان جلوگیری می کند.

گاردریل و سیاست اجرا

گاردریل ورودی نامعتبر را رد می کند، دسترسی ابزار را کنترل می کند و خروجی حساس را پیش از انتشار می سنجد. تایید انسانی، محدودیت نرخ، بودجه و محیط ایزوله نیز بخشی از سیاست اجرا هستند. این لایه باید مستقل از توان مدل عمل کند.

مشاهده پذیری و ثبت تریس

هر اجرا باید شناسه داشته باشد و زمان مدل، ابزار، خطا، هزینه و نتیجه گاردریل را ثبت کند. ثبت متن کامل همیشه لازم نیست؛ برای داده حساس می توان شناسه، متادیتا یا نسخه پالایش شده را نگه داشت. معماری بدون مشاهده پذیری، در زمان خطا به جعبه سیاه تبدیل می شود.

یک جریان نمونه

1. درخواست به هدف و محدودیت تبدیل می شود.
2. وضعیت اولیه و دانش مرتبط گرداوری می شود.
3. مدل پاسخ یا ابزار مناسب را انتخاب می کند.
4. سیاست دسترسی پیش از اجرا تصمیم را کنترل می کند.
5. نتیجه ابزار به وضعیت برمی گردد.
6. ایجنت ادامه، توقف یا ارجاع به انسان را انتخاب می کند.
7. تریس و معیارهای اجرا ذخیره می شوند.