تصور کنید در یک حلقهی بیپایان از «هزینههای غرقشده» (Sunk Cost) گیر کردهاید؛ وضعیتی که در آن توسعهدهندگان با این باور مداوم که پرامپت بعدی بالاخره باگ را حل میکند، به تلاش و هزینه ادامه میدهند. برای پایان دادن به این پیشبینیناپذیری و خروج از این چرخه، یکی از توسعهدهندگان studio.almadar.io در ۱۲ سپتامبر ۲۰۲۶ سیستمی به نام «نردبان هوش» (Intelligence Ladder) را پیشنهاد داد. این سیستم بهجای پیروی از استاندارد فعلی صنعت که بر پایه حدس زدن هزینههای تحویل پروژه است، با هوش مصنوعی مانند یک منبع لایهبندیشده و درجهبندیشده برخورد میکند.
مسئله تخمینهای مبهم
در مشاغل سنتی، هزینهها شفاف و مشخص هستند. یک بنا برای بازسازی یک آشپزخانه قیمت دقیقی میدهد یا یک چاپخانه برای چاپ ۵ هزار تراکت نرخ مشخصی را اعلام میکند. اما در صنعت عاملهای کدنویس (Coding Agents)، «پاسخهای مبهم» به یک امر عادی تبدیل شدهاند. طبق گزارش نویسنده، وقتی از یک مدل میخواهید برای ساخت یک پروژه مشخص — مثلاً یک اپلیکیشن چت — تخمین قیمت یا زمان بدهد، مدل با خوشحالی یک عدد را حدس میزند، اما این تخمین اغلب غلط است.
این نبودِ شفافیت، یک تلهی روانشناختی میسازد. کاربران پروژه را شروع میکنند، هزینه میکنند و چنان در آن غرق میشوند که متوقف شدن برایشان سخت میشود؛ در حالی که به خود میگویند پرامپت بعدی نتیجه را میآورد. این وضعیتی خطرناک برای کل صنعت است. ما به تکنولوژیهایی عادت کردهایم که لحظه روشن شدن، کار میکنند. عرضه کردن عاملها به عموم بدون اینکه خریدار راهی برای دانستن هزینههای تحویل داشته باشد، اعتماد کاربران را میسوزاند و در نهایت منجر به یک واکنش شدید و منفی در بازار خواهد شد.
شکاف دسترسی و هزینههای سختافزاری
پیش از انفجار فعلی هوش مصنوعی، یک توسعهدهنده تنها با یک جستوجوی ساده به نرمافزاری دست مییافت که توسط یک مهندس متخصص نوشته شده بود و او تعهدش را عملی میکرد. در آن زمان، اگر توسعهدهندهای شکست میخورد، نقدها تند، بیرحمانه و عمومی بود. در واقع، پاسخگویی وجود داشت و قیمتها ثابت بود. اما اکنون این شکاف در حال عمیقتر شدن است.
نگرانی بزرگی دربارهی این وجود دارد که چه کسی توان مالی استفاده از این ابزارها را دارد. سختافزارهای مورد نیاز برای اجرای مدلهای پیشرو (Frontier Models) بهنظر نمیرسد که کوچکتر شوند؛ بلکه هر ماه گرانتر میشوند. این وضعیت ریسک ایجاد دنیایی را دارد که در آن فقط ثروتمندان میتوانند نرمافزار بسازند؛ تغییری خطرناک نسبت به دهههای گذشته که یک کامپیوتر معمولی برای خلق ابزارهای پیچیده کافی بود. نویسنده این وضعیت را با صنعت بازیهای ویدئویی مقایسه میکند: اگر هر سه ماه برای اجرای بازیها به یک کارت گرافیک جدید نیاز بود، هیچکس آن را نمیپذیرفت. با این حال، ما در هوش مصنوعی این وضعیت را میپذیریم چون تکنولوژی برچسب «تجربی» خورده است و ما پذیرفتهایم که سوژههای آزمایش باشیم.
مکانیسم رفتارها
برای حل این مشکلات، نردبان هوش مفهومی به نام «رفتار» (Behavior) را معرفی میکند. یک رفتار، تکهای ماژولار، مستقل و قابل اشتراک از یک برنامه است؛ مانند یک صفحه واحد با ماشین حالت (State Machine) مخصوص به خود، رویدادهایش و دادههایی که با آنها در تماس است. رفتارها قابلیت ترکیب دارند، به این معنا که یک رفتار را میتوان در هر برنامهای که شرایطش را داشته باشد قرار داد، بدون اینکه نیاز باشد دوباره از صفر نوشته شود.
برای مثال، یک اپلیکیشن چت در این سیستم نه یک تسک غولپیکر و واحد، بلکه مجموعهای از ۵ رفتار مشخص است:
- جریان پیامها (Message streams)
- کانالها (Channels)
- عضویت در کانال (Channel membership)
- کاربران آنلاین (Online users)
- سیاستهای گفتگو (Conversation policies)
این رفتارها از اجزای مشترکی ساخته شدهاند که مختص چت نیستند، مانند پوسته اپلیکیشن (App shell)، لیست مرور (Browse list)، مودال ثبت (Record modal)، پنل جزئیات (Detail panel)، جستوجو، دیالوگ تأیید، لایه اعلانات (Notification overlay) و رشته بحث (Discussion thread). این اجزا یکبار نوشته شده و در اپلیکیشنهای مختلف بازاستفاده میشوند.
در حال حاضر، کتابخانه studio.almadar.io شامل بیش از ۱۰۰۰ رفتار است که به دو دسته تقسیم میشوند:
- اجزای اتمی (Atomic Components): کوچکترین بلوکهای سازنده ممکن (حدود ۶۰۰ مورد در کتابخانه).
- اجزای ارگانیسم (Organism Components): ساختارهای پیچیدهای که از چندین اتم ساخته شدهاند (حدود ۴۵۰ مورد در کتابخانه).
وقتی کاربر درخواستی میدهد، عامل بلافاصله کدنویسی نمیکند. ابتدا درخواست را به رفتارها تجزیه کرده و با استفاده از بردار معنایی (Embedding) — که مانند یک کارت معرفی عددی برای هر واژه است و میگوید این کلمه همسایهی چه کلمات دیگری است — آنها را با کتابخانه تطبیق میدهد. این فرآیند جستوجو از یک کف و حاشیه (Floor and Margin) ثابت استفاده میکند و تصمیمگیری را از یک «حس» در مدل به یک رویداد ثبتشده در لاگ تبدیل میکند.
چهار پله هوش
این سیستم مانند حافظهٔ کش (Cache) یک پردازنده عمل میکند و کارها را در چهار پله متمایز قرار میدهد تا هزینه به حداقل و سرعت به حداکثر برسد:
۱. بازپخش (Replay): نقشه دقیقاً قبلاً ساخته شده است. هر رفتار از کارخانه (Factory) مربوطهاش بازسازی میشود. این مرحله به صفر فراخوانی مدل نیاز دارد، بهصورت محلی روی ماشین کاربر اجرا میشود و هزینهای جز برق ندارد.
۲. تطبیق کامل (Full Hit): درخواست با یک ارگانیسم در کتابخانه بهاندازه کافی نزدیک است. تنها یک فراخوانی کوچک از مدل برای پر کردن تفاوتها — مانند نام فیلدها، برچسبهای مورد نظر یا صفحاتی که خواستهاید — لازم است و بقیه کدها قطعی (Deterministic) هستند. در اینجا یک مدل محلی ارزان کفایت میکند.
۳. تطبیق جزئی (Partial Hit): درخواست به چندین رفتار تقسیم میشود. برخی با کتابخانه تطبیق یافته و از کارخانهها ساخته میشوند؛ برخی دیگر خیر. تنها رفتارهای نو و ناشناخته به پله آخر ارسال میشوند.
۴. عدم تطبیق (Miss): هیچ چیز نزدیکی در کتابخانه نیست. یک زیر-عامل (Sub-agent) رفتار را از صفر مینویسد، آن را اعتبارسنجی میکند و در یک حلقه اصلاح میکند. این تنها پلهای است که به یک مدل پیشرو (Frontier Model) قدرتمند و گرانقیمت نیاز دارد.
کمیسازی هزینهها
هر مرحله از این فرآیند اندازهگیری (Metered) میشود. دادههای حاصل از اجراهای ارزیابی روی ماشینهای محلی (که برای مقایسهپذیری، هزینههای آنها بر اساس نرخهای میزبانی تخمین زده شده) تفاوت فاحشی را در مصرف منابع نشان میدهد:
- ساخت اپلیکیشن فروشگاه الکترونیکی: با استفاده از یک مدل کدنویسی 30B، این کار به ۶۲ فراخوانی مدل و حدود ۱.۱ میلیون توکن (Token) — تکههای کوچکی از متن که مدل پردازش میکند — نیاز داشت. زمان اجرا ۱۳ دقیقه و هزینه تخمینی ۰.۰۸ دلار بود.
- ویرایش یک تنظیم در داشبورد: با استفاده از یک مدل عمومی 27B، این کار به ۱۲ فراخوانی و حدود ۱۴۶ هزار توکن نیاز داشت. زمان اجرا ۴ دقیقه و هزینه ۰.۰۷ دلار بود.
- همان نوع ویرایش با مدل کوچکتر: تنها به ۳ فراخوانی و حدود ۲۰ هزار توکن نیاز داشت. در ۲۱ ثانیه به پایان رسید و هزینه آن کمتر از ۰.۰۱ دلار بود.
این اعداد ثابت میکنند که انتخاب مدل یک واقعیت عددی است، نه یک حس. در مثال فروشگاه، یک رویکرد ۱۶ برابر گرانتر از رویکرد دیگر بود، در حالی که در نهایت هیچ اپلیکیشنی تولید نکرد.
بهبود سیستم از طریق شکست
نویسنده صادقانه میگوید که بسیاری از اجراها در لاگها شکست خوردهاند. مدلهای محلی کوچک مکرراً در حلقههای ابزاری (Tool loops) گیر میکنند. با این حال، نردبان هوش چیزی را فراهم میکند که بقیه صنعت فاقد آن است: دیدهشدن (Visibility). چون سیستم ثبت میکند که هر درخواست در کدام پله قرار گرفته و در کجا متوقف شده است، هر «عدم تطبیق» به عنوان یک «کش-میس» (Cache Miss) شناسایی میشود. سپس هر عدم تطبیق، کاندیدایی برای تبدیل شدن به یک رفتار جدید و اضافه شدن به کتابخانه میشود.
این یک اثر مرکب ایجاد میکند. هرچه رفتارهای بیشتری اضافه و به اشتراک گذاشته شوند، درخواستهای آینده به پلههای پایینتر و ارزانتر منتقل میشوند. اگر کاربر تصمیم بگیرد آنچه ساخته است را به اشتراک بگذارد، هزینه را برای نفر بعدی نیز کاهش میدهد.
برای توسعهدهنده معمولی، این به معنای پایان «شوک صورتحساب» است. شما قبل از شروع ساخت میدانید چه مقدار از اپلیکیشن شما بازپخش است، چه مقدار تطبیق دارد و چه مقدار واقعاً جدید است. تنها بخشهای واقعاً جدید به هوش گرانقیمت نیاز دارند و این به توسعهدهندگان اجازه میدهد ایدههای خود را بدون ترس از یک صورتحساب عظیم امتحان کنند.
این چرخش، صنعت را به سمت مدل پاسخگویی میبرد. با تبدیل هوش مصنوعی از یک «جعبه جادویی» به یک ابزار کاربردی لایهبندیشده، توسعهدهندگان بهجای حدس زدن، تخمین میزنند. این تغییر، عامل هوش مصنوعی را از یک همکار بیثبات به یک ابزار تولید پیشبینیپذیر تبدیل میکند.
برای اینکه ببینید آیا این رویکرد ماژولار با جریان کاری شما سازگار است، میتوانید نسخه بتای studio.almadar.io را بررسی کنید و تست کنید که چه تعداد از الگوهای رایج رابط کاربری (UI) شما را میتوان به رفتارهای اتمی کاهش داد.
گفتگو