هوش مصنوعی تقریباً رایگان شد، حالا چه؟ سیستمهای داده برای ایجنتها، از ایجنتها و توسط ایجنتها
«… حکومتی از مردم، توسط مردم، برای مردم …»
— آبراهام لینکلن، سخنرانی گتیسبرگ (۱۸۶۳)
هزینه هوش مصنوعی با سرعتی باورنکردنی در حال کاهش است. قابلیتهای کلاس GPT-4 که در اوایل سال ۲۰۲۳ حدود ۳۰ دلار به ازای هر میلیون توکن هزینه داشتند، امروز با قیمتی کمتر از ۱ دلار ارائه میشوند و برخی از ارائهدهندگان حتی این هزینه را به زیر ۰.۱۰ دلار رساندهاند. در بنچمارکهای مختلف، قیمت استنتاج (Inference) سالانه بین ۹ تا ۹۰۰ برابر کاهش یافته که میانه این افت قیمت نزدیک به ۵۰ برابر است. حتی مدلهای پیشرو (Frontier Models) نیز در هر نسل به شکل چشمگیری ارزانتر میشوند و مدلهای متنباز هم با فاصله کمی همین مسیر را دنبال میکنند. نکته کلیدی این است که اگرچه هنوز به هوش مصنوعی در سطح «نوابغ برنده جایزه نوبل» نرسیدهایم، اما هوشی که برای انجام بخش اعظم کارهای دانشی (Knowledge Work) کافی باشد، همین امروز در دسترس است و ماه به ماه ارزانتر میشود. با این روند، بهزودی وارد عصر «هوش تقریباً رایگان» میشویم؛ هوشی که برای کارهای روزمره بیش از حد نیاز کافی است.
توضیح نویسندگان: این مقاله چشماندازی است به رهبری آدیتیا پارامسواران (Aditya G. Parameswaran) – دانشیار علوم کامپیوتر و برق و هممدیر آزمایشگاه EPIC Data در دانشگاه برکلی – به همراه همکارانش. این نوشتار بخشی پیمایش زیستبوم و بخشی ارائه دیدگاه است و چندین مسیر تحقیقاتی مطرحشده در آن (از جمله گمانهزنی ایجنتی، حافظه ساختاریافته و سنتز سیستمهای داده اختصاصی از صفر) بر اساس تحقیقات در حال انجام خود نویسندگان است.
اما این عصر جدید «هوش تقریباً رایگان» برای سیستمهای داده به چه معناست؟ ما معتقدیم سه چالش و فرصت جدید از هزینههای نزدیک به صفر استنتاج ناشی میشود:
- سیستمهای داده برای ایجنتها (Data Systems For Agents): ایجنتها (Agent / عاملهای هوشمند) بهزودی به بار کاری اصلی (Workload) سیستمهای داده تبدیل خواهند شد و در پاسخ به هر درخواست کاربر، دستهای از ایجنتها فعال میشوند. با توجه به تفاوت ویژگیهای ایجنتها با انسانها، چگونه باید سیستمهای داده را برای این کاربران ایجنتی از نو طراحی کنیم؟
- سیستمهای داده از ایجنتها (Data Systems Of Agents): با عهدهدار شدن بخش عمده کارهای دانشی توسط ایجنتها، به بستر جدیدی نیاز است تا هزاران ایجنت بتوانند وضعیت (State) را در وظایف طولانیمدت مدیریت کنند، به هماهنگی و اجماع برسند و با خطاها مواجه شوند. سیستمهای دادهای که بهطور مطمئن و کارآمد دستههای ایجنت را اجرا و مدیریت میکنند چه شکلی خواهند بود؟
- سیستمهای داده توسط ایجنتها (Data Systems By Agents): ایجنتها بهسرعت در حال کسب توانایی سنتز و ساخت کامل سیستمهای داده در یک مرحله هستند؛ به این معنی که میتوانیم برای هر بار کاری جدید، سیستمهای اختصاصی از نو بسازیم. راستیآزمایی تطابق این سیستمها با رفتار مورد نظر یک چالش است. چه الزامات و شرایطی نیاز است تا اجازه دهیم ایجنتها سیستمهای دادهای بسازند که واقعاً بتوانیم به آنها اعتماد کنیم؟
سیستمهای داده برای ایجنتها
پرسوجوی یک ایجنت از پایگاه داده مانند یک انسان یا یک ابزار هوش تجاری (BI) نیست. ایجنت رفتاری انجام میدهد که ما آن را گمانهزنی ایجنتی (Agentic Speculation) مینامیم: جریانی ناهمگون و پرحجم از کارهای شامل بازرسی اسکما (Schema Introspection)، کاوش ستونی، و فرمولبندی جزئی و سپس کامل پرسوجوها (Query). با کاوش بخشی از فضای فرضیات توسط ایجنتهای متعدد، هر درخواست کاربر میتواند به هزاران پرسوجوی مجزای SQL تبدیل شود. اکنون کاربران میتوانند وظایف دادهای سطح بالا (مانند تحلیل علت ریشهای: «چرا فروش قهوه در برکلی امسال کاهش یافت؟» یا تحلیل کاوشی گروهی: «کدام بخش از کاربران در فصل آینده احتمال ریزش بیشتری دارند؟») صادر کنند که هرکدام شامل فضایی ترکیبی از ترکیبهای پیوند (Join)، تجمیع (Aggregation) و فیلتر است.
درخواستهای این ایجنتها فرصتهای مختلفی برای بهینهسازی فراهم میکند. به عنوان مثال، در یک بنچمارک Text-to-SQL که چندین ایجنت برای انجام هر وظیفه تلاش میکردند، تنها ۱۰ تا ۲۰ درصد زیرطرحها (Sub-plans) متفاوت بودند؛ به این معنی که ۸۰ تا ۹۰ درصد زیرپرسوجوها کار تکراری انجام میدادند. همین آزمایشها نشان میدهد که نرخ موفقیت وظایف با تلاشهای ایجنتی بیشتر بهطور چشمگیری افزایش مییابد؛ بنابراین این همپوشانی و تکرار در واقع مفید است، اما از منظر سیستم داده، یک کار به هدر رفته محسوب میشود.
یک سیستم داده «ایجنت-محور» میتواند از این ویژگیها برای کمک به پیشرفت سریعتر ایجنتها استفاده کند. چنین سیستمی میتواند نتایج را در زیرطرحهای همپوشان مجدداً استفاده کند (با بهرهگیری از ادبیات چنددههای بهینهسازی چندپرسوجویی یا Multi-query Optimization و اسکنهای مشترک). یا سیستم داده میتواند با ارائهپاسخهای تقریبی که برای پیشرفت ایجنتها به اندازه کافی خوب هستند، پاسخگویی کند (با استفاده از تکنیکهای AQP یا پردازش تقریبی پرسوجو) یا نتایج عملگرهای نهایی یا میانی را استریم کند تا به ایجنتها کمک کند تصمیم بگیرند آیا دیدن بقیه دادهها ضروری یا مفید است یا خیر.
فرصت دیگر در اینجا، بازاندیشی کامل در رابط پرسوجو (Query Interface) است: به جای اینکه ایجنتها در هر لحظه یک پرسوجوی SQL صادر کنند، میتوانند دستهای از پرسوجوها را صادر کنند که هر کدام الزامات تقریبی خود را دارند. از آنجایی که پیمایش یک فضای جستجوی نمایی استفاده خوبی از قدرت استدلال ایجنتی نیست، شاید سیستمهای داده باید از دستورات و عملگرهای اولیه سطح بالاتر پشتیبانی کنند. یک ایده در اینجا استفاده از ماکروهای Jinja به سبک DBT است تا دستورات حلقهای برای تعامل ایجنتها با سیستمهای داده فراهم شود.
آخرین فرصت در این بخش، دست کشیدن از نگاه به سیستمهای داده به عنوان مجریان منفعل پرسوجوهاست. سیستمهای داده میتوانند پیشفعال (Proactive) باشند، زیرا درک دقیقتری از دادهها و ویژگیهای سیستم دارند که ایجنتها ممکن است پیشفرض از آن بیخبر باشند. سیستم داده میتواند ایجنتها را به مسیرهای مختلف هدایت کند، نتایج پرسوجوهای مرتبط را ارائه دهد و بازخورد سطح عملکرد فراهم کند (مثلاً به جای اجرای یک پرسوجوی سنگین، ابتدا تخمین زمان تاخیر را به ایجنت بدهد). دلیل اینکه اکنون میتوانیم این کار را انجام دهیم این است که ایجنتها میتوانند هر فرمی از بازخورد متنی را بپذیرند و صرفاً منتظر یک نتیجه دقیق SQL نیستند.
سیستمهای داده از ایجنتها
در بخش قبل بر نحوه تعامل ایجنتها با سیستمهای داده تمرکز کردیم. اکنون تمام موارد دیگری را بررسی میکنیم که ایجنتها برای ادامه کار به آن نیاز دارند: محل استقرار، نحوه به یاد آوردن، نحوه هماهنگی با یکدیگر و نحوه برخورد با خطاهای یکدیگر. این بستر ایجنتی (Agentic Substrate) از پشته استنتاج (Inference Stack) که هوش خام را تامین میکند مجزاست. امروزه بستر ایجنتی از طریق ابزارهایی مانند Claude Code و Codex به همراه مکانیسمهای مختلف ذخیرهسازی و بازیابی حافظه مدیریت میشود.
در زمینه حافظه، باور فعلی این است که «فایلها تنها چیزی هستند که نیاز دارید»؛ ایجنتها در فایلهای غیرساختاریافته مارکداون (MD) مینویسند که سپس با استفاده از grep یا بازیابی مبتنی بر امبدینگ (Embedding) جستجو میشوند. بسیاری استدلال میکنند که راهکار یادگیری مداوم این است که ایجنتها اطلاعات زیادی (کدبیس، اسلک، ویکیهای شرکت) را مصرف کرده و یادگیریهای خود را در فایلهای MD بنویسند. اما در مقیاس بزرگ، زمانی که ایجنتها بخش اعظم کارهای دانشی را انجام میدهند، این روش دیگر کارآمد نخواهد بود.
با توجه به محدودیت پنجره بافت (Context Window)، بازیابی تمام قطعات فایلهای MD مرتبط و گنجاندن آنها در بافت در نقطهای شکست خواهد خورد. حتی اگر پنجرههای بافت رشد کنند، عدم قرار دادن همه اطلاعات در بافت مزایای تاخیری (Latency) دارد و در سناریوهای واقعی امکان سریالسازی تمام دادههای مرتبط در بافت وجود ندارد.
میتوان از نمایه گراف دانش (Knowledge Graph) استفاده کرد، اما گرافهای دانش نیز به دلیل فقدان جستجوی ساختاریافته از همان محدودیتهای حافظه غیرساختاریافته رنج میبرند. آنچه نیاز است، توانایی بازیابی تنها آن بخش از حافظه است که به وظیفه مربوط میشود. به عنوان مثال، ایجنتی که در حال دیباگ یک تست ناپایدار است، باید بتواند تنها حافظههایی را فراخوانی کند که با ماژول، زبان، فریمورک و حالت خطای مربوطه برچسبگذاری شدهاند.
ما اخیراً مفهوم **حافظه ساختاریافته (Structured Memory)** را مورد بررسی قرار دادیم که در آن حافظه را حول ویژگیهای مختلف سازماندهی میکنیم. برای یک ایجنت داده، این ابعاد میتواند شامل ستونها، جداول، نوع عملیات و دستورالعملهای اصلاحی متنی باشد. بنابراین میتوان حافظهای داشت که فقط برای نوع خاصی از عملیات اعمال شود (مثلاً: «هنگام انجام عملیات تاریخ و زمان، از سال مالی استفاده کن»). چالش باز موجود، تعریف حافظه ساختاریافته اختصاصی برنامه (یا مدلهای جهان برای حافظه) است. ما معتقدیم این شبیه به تعریف یک اسکما (Schema) برای هر برنامه است و شاید خود ایجنتها بتوانند به ما در تعریف و بهبود آن کمک کنند.
چالش دیگر پشتیبانی از ویرایشهای همزمان در حافظه مشترک است، بهویژه زمانی که هزاران ایجنت در حال تغییر وضعیت هستند. تکنیکهایی مانند تعاملات چندنسخهای (Multiversioning) یا Copy-on-write ممکن است برای همزمانی هزاران ایجنت کافی نباشند. ساختارهای دادهای بدون تعارض (CRDTs) و دگرگونی عملیاتی (Operational Transformation) در اینجا مطرح میشوند. برای بهروزرسانی مکانیسمهای فازی مانند حافظه، میتوان یکپارچگی (Consistency) مطلق را فدای کاهش تاخیر کرد. چالش اصلی جلوگیری از وضعیت «قفل زنده» (Livelock) است، جایی که اقدامات جبرانی مداوم ایجنتها مانع از پیشرفت واقعی میشود.
علاوه بر وضعیت مشترک، مسائل دیگری مانند نحوه ارتباط ایجنتها با یکدیگر (مستقیم یا از طریق وضعیت مشترک) و نحوه مواجهه با ایجنتهای کند مطرح است. راهکارهایی مانند Temporal برای اجرای بادوام چندایجنت ایجاد شدهاند، اما مشخص نیست که آیا در مقیاس هزاران ایجنت پاسخگو خواهند بود یا خیر. در موضوع ارتباطات، ما به مکانیسمهایی نیاز داریم که ایجنتها بتوانند با یکدیگر مذاکره کنند؛ برای مثال چهار ایجنت توسعهدهنده که میخواهند روی یک اسکمای مشترک به اجماع برسند.