کیشورکومار پتابیرامان، مهندس ارشد معماری آژور، در پستی در وبلاگ معماری آژور چهار معیار عملی پیشنهاد کرده که به تیمها کمک میکند هنگام طراحی سامانههای هوش مصنوعی بین «مهارت» و «زیرعامل» تصمیم درست بگیرند. او تأکید دارد که انتخاب نوع معماری در ابتدا تعیینکننده است و انتخاب نامناسب میتواند انتخاب مدل را بیمعنی کند.
مهارت یا زیرعامل: تفاوت در شیوه اجرا
مهارت در دل یک گفتگوی جاری کار میکند؛ قادر است فایلها را بخواند، پرسش بپرسد، با کاربر تعامل کند و انسان را در چرخه نگه دارد. زیرعامل یک درخواست واحد را دریافت کرده، مستقل اجرا میشود و یک خروجی نهایی تحویل میدهد. هرکدام کاربرد مشخص و محدودیتهای خاص خود را دارند و انتخاب مناسب بر اساس نوع وظیفه تعیین میشود.
چهار بعد اصلی تصمیمگیری
پتابیرامان چهار معیار کلیدی را برای تعیین معماری پیشنهاد میکند:
- مدل تکرار (Iteration model) — آیا نیاز به تعاملهای پیدرپی و اصلاح وجود دارد یا پاسخ یکباره کافی است؟
- وفاداری لحن (Voice fidelity) — آیا خروجی باید دقیقاً با لحن یا سبک مشخصی همخوانی داشته باشد؟
- محل دخالت انسانی — آیا لازم است انسان در میانه فرایند کنترل یا تصمیمگیری کند؟
- میزان تکرار وظیفه — آیا این وظیفه یکبار و پیچیده است یا تکرارشونده و دستهای؟
در میان این معیارها، تکرار معمولاً مرز واضحی میسازد: کارهای تکبارِ دقیق معمولاً به سمت مهارت و کارهای دستهای تکرارشونده به سمت زیرعامل گرایش دارند.
تعادل بین تعامل انسانی و خودکارسازی
تصمیم اغلب ساده بین گفتگوی تعاملی یا تحویل لحظهای نیست. باید هزینه نگهداری انسان در جریانهای مهارتمحور را در برابر ریسک خطاهای مکرر در یک پاسخ یکباره سنجید. پتابیرامان برای هر بُعد، ریسکها و دامهای رایج را توضیح میدهد تا انتخابها عملی و پایدار باشند.
بازخورد و دیدگاه جامعهٔ توسعهدهندگان
بحث مهارت در برابر زیرعامل محدود به وبلاگ آژور نماند؛ در پلتفرمهایی مانند ردیت و Hacker News نیز نظرات متعددی مطرح شد. نکات برجسته عبارتند از:
- کاربر enthusiast_bob اشاره کرده که زیرعاملها معمولاً از زمینهٔ پاک آغاز میشوند و پنجرهٔ زمینه را آلوده نمیکنند، در حالی که مهارتها کل گفتگو را لحاظ میکنند.
- کاربر dan-does-ai میگوید مهارتها قابل استفاده مجدد بین چند عامل یا جریان گفتگو هستند، اما زیرعاملها مناسب زمانیاند که مرحلهای نیاز به زمینهٔ جدا، مجوزهای متفاوت یا منبع دانش متمایز دارد.
- کاربر Ashlesha-msft یادآور شده که در Copilot Studio برنامهریز بهصورت پویا تصمیم میگیرد چه زمانی مهارتها، ابزارها یا زیرعاملها فراخوانی شوند؛ بنابراین یک مهارت لزوماً در هر فرمان مشابه فراخوانی نمیشود.
ارکستراسیون و افزایش عدم قطعیت
زیرعاملها اغلب نیازمند لایهٔ ارکستراسیون هستند که پیچیدگی و عدم قطعیت جدیدی به سیستم اضافه میکند. لایهٔ برنامهریز ممکن است بر اساس توصیفها، زمینه یا تاریخچهٔ گفتگو تصمیم بگیرد که چه مؤلفهای فراخوانی شود؛ این رفتار میتواند نوسان ایجاد کند و باید در معماری و تستهای عملی در نظر گرفته شود.
یک مدل ذهنی ساده برای نقشها
کاربران یک استعارهٔ ساده پیشنهاد کردهاند تا جایگاه هر مفهوم را سریع تشخیص دهند: عامل بهعنوان کارگردان، زیرعامل بهعنوان مدیر، مهارت بهعنوان کارگر تخصصی، ابزار بهعنوان ماشین اختصاصی و MCP بهعنوان سیاستها و قواعد حاکمیتی. این استعارهها در تصمیمگیریهای طراحی روزمره مفید است.
ترکیبپذیری بهعنوان راهحل غالب
پتابیرامان اشاره میکند که جدایی کامل بین مهارت و زیرعامل در عمل اغلب صرفاً ظاهری است. این دو مدل معمولاً در کنار هم کار میکنند؛ میتوان مهارتی را بر پایهٔ یک زیرعامل ساخت تا از مزایای هر دو بهره برد. طراحی لایهای چنین مزایایی در نگهداری و توسعهٔ بلندمدت دارد.
راهنمای عملی برای تصمیمگیرندگان
- برای کارهای تکبار و نیازمند تعامل دقیق با کاربر، مهارت را در نظر بگیرید.
- برای پردازشهای تکرارشونده، دستهای یا نیازمند زمینهٔ جدا و مجوزهای متفاوت، زیرعامل مناسبتر است.
- در صورت نیاز به ترکیب، طراحی لایهای (مهارت روی زیرعامل یا بالعکس) را مدنظر قرار دهید.
- پیامدهای ارکستراسیون و عدم قطعیت را در معیارهای پذیرش و برنامهٔ تست لحاظ کنید.
منابع
برای مطالعهٔ بیشتر میتوانید به صفحات Software agent در ویکیپدیا و Microsoft Azure مراجعه کنید.
انتخاب معماری همان نقطهای است که زمان و هزینههای آینده تعیین میشود. تیمهایی که چهار معیار یادشده را از ابتدا تعریف میکنند، راهحلهای عملیتر و قابل نگهداریتری خواهند ساخت.
