أعلنت Google مؤخرًا عن التوفر العام (GA) لوظائف AlloyDB AI، إلى جانب تقنيتي تسريع تعملان بشكل أساسي على تغيير كيفية تفاعل قواعد البيانات مع نماذج اللغات الكبيرة (LLMs).
وفقًا للاختبار الداخلي الذي أجرته Google، فإن التجميع الذكي يوفر تحسينًا بمقدار 2400 مرة في الإنتاجية مقارنة بمعالجة الصف في كل مرة، بينما تعمل نماذج الوكيل المحسنة على دفع ذلك إلى 23000 مرة مع انخفاض في التكلفة بمقدار 6000 مرة. في حين أن هذه الأرقام الرئيسية تستدعي التدقيق الهندسي، فإن بنية نموذج الوكيل الأساسي هي ما يجب على الممارسين التركيز عليه.
باستخدام وظائف AlloyDB AI، يمكن للمطورين الاتصال بطلاب LLM مباشرة من خلال استعلامات SQL القياسية. يتضمن إصدار GA ai.generate لتوليد النص، ai.if للتصفية الدلالية، ai.rank لإعادة الترتيب الدلالي، ai.forecast للتنبؤ بالسلاسل الزمنية، وثلاث إضافات جديدة:
- ai. تلخيص,
- ai.agg_summarize للملخصات على مستوى المجموعة،
- و ai.analyze_sentiment.
ونظرًا لأن هذه العناصر يتم تنفيذها كعوامل تشغيل SQL قياسية، فيمكن للاستعلام تصفية الصفوف حسب المعنى بدلاً من مطابقات الكلمات الرئيسية الصارمة.
تعد مشكلة استدعاء LLM لكل صف واضحة على نطاق واسع: جدول يحتوي على 100000 منتج يعني 100000 رحلة ذهابًا وإيابًا إلى Vertex AI، كل رحلة تحمل نفس موجه النظام، وكل منها تنتظر استنتاج النموذج، وكل منها تتكبد تكاليف لكل رمز مميز. تعالج طبقتان من التسارع هذا الأمر.
التجميع الذكي، متوفر الآن لـ ai.if و ai.rank، يقوم بتجميع صفوف متعددة في استدعاء نموذج واحد. بدلاً من إرسال مطالبة النظام مع كل صف، ترسلها AlloyDB مرة واحدة وتجميع البيانات. أبلغت Google عن إنتاجية تصل إلى 10000 صف في الثانية في الاختبار الداخلي، وهو تحسن بمقدار 2400 مرة مقارنة بخط الأساس للصف في كل مرة. تتميز التقنية بأنها واضحة ومباشرة، وتكون المكاسب موثوقة بالنسبة لأحمال العمل حيث تكون الحمولة الصافية لكل صف صغيرة بالنسبة إلى الموجه.
نموذج الوكيل هو الخطوة الأكثر أهمية من الناحية المعمارية. ل ai.if الاستعلامات (حاليًا قيد المعاينة)، تقدم AlloyDB سير عمل على مرحلتين:
-- Phase 1: Train the local proxy model using a sample of data and the frontier LLM
PREPARE underwater_suitability_proxy FROM
SELECT description FROM products;
-- Phase 2: Execute the query at database speed using the local proxy model
SELECT * FROM products
WHERE ai.if(description, 'suitable for underwater use deeper than 60 meters')
USING proxy(underwater_suitability_proxy);
أولاً، ترسل عبارة PREPARE عينة من بياناتك إلى نموذج حدودي وتستخدم النتائج لتدريب نموذج محلي خفيف الوزن داخل قاعدة البيانات. بعد ذلك، يقوم EXECUTE بتشغيل الاستعلام باستخدام الوكيل المحلي بدلاً من استدعاء LLM الخارجي. تعود AlloyDB إلى النموذج الحدودي إذا كانت ثقة الوكيل منخفضة للغاية أو في حالة عدم توفر نموذج مدرب. تبلغ Google عن إنتاجية تبلغ 100000 صف في الثانية باستخدام هذا الأسلوب.
يعكس نمط نموذج الوكيل العلاقة المعتادة بين قاعدة البيانات وLLM. بدلاً من أن تكون قاعدة البيانات عميلاً يستدعي نموذجًا خارجيًا لكل قرار، تصبح قاعدة البيانات طالبًا يتعلم حكم النموذج على عينة، ثم يطبق هذا الحكم محليًا بسرعة قاعدة البيانات. يصبح LLM مدرسًا وليس تبعية لوقت التشغيل.
هذا النمط له آثار تتجاوز AlloyDB. تواجه أي قاعدة بيانات تستدعي نماذج خارجية لاتخاذ قرارات لكل صف نفس جدار التكلفة وزمن الوصول. والسؤال هو ما إذا كان المنافسون (Aurora، وAzure SQL، وCockroachDB، وPlanetScale) سيتبنون أساليب مماثلة للتقطير في وقت الاستعلام، أو ما إذا كانوا سيعتمدون على المستخدمين الذين يبنون هذا المنطق في كود التطبيق.
يجب على الممارسين ملاحظة التحذيرات الواردة في إعلان Google الخاص: الأرقام 23000x و6000x تأتي من الاختبار الداخلي، وتنطبق خصيصًا على ai.if في المعاينة، ولا تمثل أداء جميع وظائف الذكاء الاصطناعي بشكل عام. نموذج الوكيل الأمثل ليس GA بعد. يجب على الفرق التي تقوم بتقييم AlloyDB لأحمال عمل الذكاء الاصطناعي للإنتاج قياس الأداء مقارنة بتوزيعات البيانات وأنماط الاستعلام الخاصة بها قبل الالتزام.
قدم رايمونداس جودفالكيس، وهو مهندس معماري في شركة Starburst، إطارًا عمليًا على LinkedIn:
تعامل معها على أنها امتدادات لقاعدة بيانات محكومة، وليست جمل WHERE السحرية.
وأوصى بالبدء بسير عمل المراجعة المكثفة للقراءة قبل كتابة الحقول المشتقة من النموذج مرة أخرى إلى الأنظمة الأساسية، وتتبع تكلفة النموذج بشكل منفصل عن تكلفة الاستعلام.
يتضمن الإصدار أيضًا خادم MCP مُدارًا لـ AlloyDB، مما يسمح لوكلاء الذكاء الاصطناعي بالاستعلام عن محتوى قاعدة البيانات من خلال بروتوكول السياق النموذجي دون قيام الفرق بتشغيل وتوسيع البنية التحتية لـ MCP الخاصة بهم. إلى جانب البحث المتجه الحالي باستخدام فهرس ScaNN من Google (ما يصل إلى 10 مليارات متجه)، تضع AlloyDB نفسها كقاعدة بيانات متوافقة مع PostgreSQL حيث تتعايش الاستعلامات المنظمة والبحث الدلالي والتحليل المدعوم من LLM في نفس طبقة SQL.
تتوفر وظائف AlloyDB AI بشكل عام في مثيلات PostgreSQL 17. التجميع الذكي هو GA لـ ai.if و ai.rank. نموذج الوكيل الأمثل ل ai.if قيد المعاينة. يتطلب تسريع وظيفة الذكاء الاصطناعي تعيين علامة قاعدة بيانات (google_ml_integration.enable_ai_function_acceleration) ولا يتم تمكينه افتراضيًا.
