گوگل به تازگی از دسترسی عمومی (GA) توابع AlloyDB AI به همراه دو تکنیک شتابدهی خبر داده است که اساساً نحوه تعامل دیتابیسها با مدلهای زبانی بزرگ (LLM) را دگرگون میکند. بر اساس آزمایشهای داخلی گوگل، دستهبندی هوشمند (Smart Batching) بهبود ۲۴۰۰ برابری در توان عملیاتی نسبت به پردازش ردیفبهردیف ایجاد میکند، در حالی که مدلهای پروکسی بهینهشده این رقم را به ۲۳۰۰۰ برابر با کاهش ۶۰۰۰ برابری هزینه میرسانند.
اگرچه این اعداد توجهبرانگیز نیاز به بررسی مهندسی دارند، معماری مدل پروکسی زیربنایی چیزی است که متخصصان باید روی آن تمرکز کنند. با توابع AlloyDB AI، توسعهدهندگان میتوانند مستقیماً درون پرسوجوهای استاندارد SQL با LLMها تماس بگیرند. نسخه GA شامل توابعی مانند ai.generate برای تولید متن، ai.if برای فیلتر معنایی، ai.rank برای مرتبسازی مجدد معنایی، ai.forecast برای پیشبینی سری زمانی، و سه افزوده جدید ai.summarize، ai.agg_summarize و ai.analyze_sentiment است.
از آنجا که این توابع به عنوان عملگرهای استاندارد SQL اجرا میشوند، یک پرسوجو میتواند ردیفها را بر اساس معنا فیلتر کند، نه تطابق دقیق کلمات کلیدی. اما مشکل تماس با LLM به ازای هر ردیف در مقیاس بزرگ آشکار است: یک جدول با ۱۰۰,۰۰۰ محصول یعنی ۱۰۰,۰۰۰ بار رفتوبرگشت به Vertex AI، هر بار با همان پرامپت سیستم و هزینههای هر توکن. دو لایه شتابدهی به این مشکل میپردازند.
دستهبندی هوشمند؛ بهبود ۲۴۰۰ برابری
دستهبندی هوشمند که اکنون برای ai.if و ai.rank در دسترس است، چندین ردیف را در یک تماس مدل گروهبندی میکند. به جای ارسال پرامپت سیستم با هر ردیف، AlloyDB آن را یک بار میفرستد و دادهها را دستهبندی میکند. گوگل گزارش میدهد که در آزمایشهای داخلی توان عملیاتی تا ۱۰,۰۰۰ ردیف در ثانیه دارد که بهبود ۲۴۰۰ برابری نسبت به پردازش ردیفبهردیف است. این تکنیک ساده است و برای بارهای کاری که در آنها بار هر ردیف نسبت به پرامپت کوچک است، دستاوردهای قابل اعتمادی دارد.
معماری مدل پروکسی؛ تحولی در رابطه دیتابیس و LLM
مدل پروکسی حرکت مهمتری از نظر معماری است. برای پرسوجوهای ai.if (که در حال حاضر در پیشنمایش است)، AlloyDB یک گردش کار دو مرحلهای معرفی میکند:
-- مرحله ۱: آموزش مدل پروکسی محلی با استفاده از نمونهای از داده و مدل پیشرو
PREPARE underwater_suitability_proxy FROM
SELECT description FROM products;
-- مرحله ۲: اجرای پرسوجو با سرعت دیتابیس با استفاده از مدل پروکسی محلی
SELECT * FROM products
WHERE ai.if(description, 'مناسب برای استفاده زیر آب عمیقتر از ۶۰ متر')
USING proxy(underwater_suitability_proxy);
ابتدا، یک دستور PREPARE نمونهای از دادههای شما را به یک مدل پیشرو (مانند Gemini) میفرستد و از نتایج برای آموزش یک مدل محلی سبک درون دیتابیس استفاده میکند. سپس، EXECUTE پرسوجو را با استفاده از پروکسی محلی به جای فراخوانی LLM خارجی اجرا میکند. AlloyDB در صورت پایین بودن اطمینان پروکسی یا نبود مدل آموزشدیده، به مدل پیشرو بازگشت میزند (Fallback). گوگل با این روش توان عملیاتی ۱۰۰,۰۰۰ ردیف در ثانیه را گزارش میدهد.
این الگو رابطه معمول دیتابیس به LLM را معکوس میکند. به جای اینکه دیتابیس کلاینت باشد که برای هر تصمیم یک مدل خارجی را فراخوانی کند، دیتابیس به شاگردی تبدیل میشود که قضاوت مدل را روی یک نمونه یاد میگیرد و سپس آن قضاوت را به صورت محلی با سرعت دیتابیس اعمال میکند. LLM به معلم تبدیل میشود نه یک وابستگی زمان اجرا.
پیامدها برای صنعت دیتابیس
این الگو پیامدهایی فراتر از AlloyDB دارد. هر دیتابیسی که برای تصمیمات به ازای هر ردیف مدلهای خارجی را فراخوانی میکند با همان دیوار هزینه و تأخیر روبرو است. سوال این است که آیا رقبایی مانند Aurora، Azure SQL، CockroachDB و PlanetScale رویکردهای مشابه تقطیر در زمان پرسوجو را اتخاذ خواهند کرد یا به کاربران تکیه خواهند کرد تا این منطق را در کد برنامه بسازند.
هشدارها و توصیههای عملی
متخصصان باید به نکات احتیاطی در اعلامیه خود گوگل توجه کنند: اعداد ۲۳۰۰۰ و ۶۰۰۰ برابر از آزمایشهای داخلی به دست آمدهاند، به طور خاص برای ai.if در پیشنمایش اعمال میشوند، و عملکرد همه توابع AI را به طور کلی نشان نمیدهند. مدل پروکسی بهینهشده هنوز به دسترسی عمومی نرسیده است. تیمهایی که AlloyDB را برای بارهای کاری AI تولیدی ارزیابی میکنند، باید قبل از تعهد، با توزیع دادهها و الگوهای پرسوجوی خودشان محک بزنند.
Raimundas Juodvalkis، معمار Starburst، توصیه کرد که این توابع را به عنوان افزونههای دیتابیس تحت حاکمیت در نظر بگیرید، نه جادو. او پیشنهاد داد با گردش کارهای بررسی با خوانش سنگین شروع کنید تا از کارایی و صحت آن مطمئن شوید.
