معماری عامل، یک مسئله تخصیص محاسبات است
سه گروه مستقل اخیراً به نتیجهی یکسانی در مورد طراحی عاملهای هوش مصنوعی (AI agent) رسیدهاند.
Anthropic یک پست وبلاگ درباره استراتژی مشاور (advisor strategy) منتشر کرد. آنها از یک مدل ارزان برای اجرای حلقه اصلی استفاده میکنند و تنها زمانی یک مدل گرانقیمت را فراخوانی میکنند که مدل ارزان به بنبست برسد. این تنظیمات در BrowseComp به دقت ۴۱.۲٪ رسید، در حالی که تنها ۱۵٪ از هزینهی استفاده از یک مدل سطح بالا (top-tier) برای همه کارها را داشت.
Tobi Lutke از Shopify تنظیمات مشابهی را در X به اشتراک گذاشت. او یک مدل محلی را برای تحقیق اجرا میکند و از یک مدل پیشرو (frontier model) به عنوان مشاور استفاده میکند. توسعهدهندگان نسخههای متنباز این روش را ظرف چند ساعت ساختند.
HazyResearch مقالهای درباره یک چارچوب فشردهساز-پیشبین (compressor-predictor framework) منتشر کرد. یک مدل کوچک، زمینه (context) را برای یک مدل بزرگ خلاصه میکند تا مدل بزرگ بتواند روی آن استدلال کند. سیستم آنها ۹۹٪ دقت را با تنها ۲۶٪ هزینه بازیابی کرد.
این همگرایی تصادفی نیست؛ بلکه از یک قانون طراحی خاص پیروی میکند: چارچوب منحنی هزینه (cost-curve frame).
من در این مجموعه، این چارچوب را در سه لایه مورد بحث قرار دادهام:
- لایه ۱ (بازیابی/Retrieval): چرا حلقههای ابزار (tool-loops) در اکثر وظایف کدنویسی بر RAG برتری دارند.
- لایه ۲ (ذخیرهسازی/Storage): چرا SQLite در گرافهای نمادین از پایگاههای داده برداری (vector databases) بهتر است.
- لایه ۳ (هماهنگسازی/Orchestration): چرا استراتژی مشاور در انتخاب مدل برنده است.
منطق یکی است. اکثر وظایف عاملها شامل عملیاتهای بسیار زیاد با ارزش پایین و تصمیمات معدود با ارزش بالا هستند.
اگر برای هر توکن از یک مدل گرانقیمت استفاده کنید، پول خود را صرف کارهای روتین مانند خواندن زمینه یا قالببندی متن میکنید. استراتژی مشاور این مسیرها را از هم جدا میکند. شما از یک مجری (executor) ارزان برای کارهای اصلی و از یک مشاور گرانقیمت فقط برای نقاط تصمیمگیری حیاتی استفاده میکنید.
اگر در حال ساخت عامل هستید، مراقب این سه چالش مهندسی باشید:
- خروج داده (Data Egress): ارسال زمینه به یک مشاور از راه دور میتواند باعث نشت دادههای حساس شود. از یک لایه حذف اطلاعات حساس (redaction layer) استفاده کنید.
- سیاست ارتقا (Escalation Policy): تصمیمگیری در مورد زمان فراخوانی مشاور دشوار است. فراخوانی خیلی زود باعث هدر رفت پول میشود و فراخوانی خیلی دیر باعث هدر رفت زمان میشود.
- طراحی انتقال مسئولیت (Handoff Design): مشاور باید یک برنامه کوتاه ارائه دهد، نه یک راه حل کامل.
این الگو واقعی است چون کارآمد است. از پرداخت نرخ مدلهای پیشرو برای توکنهایی که به آنها نیازی ندارند، دست بردارید.
Optional learning community: https://t.me/GyaanSetuAi