Uber QueryGPT: لغة طبيعية إلى SQL — من 10 دقائق إلى 3

• QueryGPT — Natural Language to SQL at Uber — Uber Engineering Blog, 2024-09-19
• A Deep Dive into QueryGPT: Uber's AI-Powered SQL Generator — Sequel (независимый разбор), 2024

السياق

أوبر هي شركة موجهة بالبيانات بالمعنى الحرفي للكلمة: التسعير والتوجيه ودفع السائقين وموازنة الطلب تعمل جميعها على منصة بيانات تتعامل مع حوالي 1.2 مليون استعلام SQL تفاعلي شهريًا. أكبر مستهلك هو منظمة العمليات، حيث تساهم بحوالي 36% من جميع الاستعلامات. أي آلاف الموظفين الذين يحتاجون إلى بيانات يوميًا لكن SQL ليست مهنتهم الأساسية.

تعتمد التحليلات الداخلية في أوبر على آلاف مجموعات البيانات، وقد نمت الجداول الرئيسية (من المستوى الأول) لتحتوي على أكثر من 200 عمود لكل منها. كتابة الاستعلام ليست مجرد بناء جملة: يجب عليك العثور على الجداول الصحيحة من بين آلاف الجداول وفهم المخطط والمنطق التجاري للحقول — كيفية حساب التواريخ في مجال معين، أو ما تعنيه علامة معينة.

ولدت QueryGPT من الأسفل للأعلى، وليس بمرسوم تنفيذي: تم اقتراح الفكرة في hackathon Generative AI Hackdays الداخلي في مايو 2023، عندما كانت أوبر تبحث بشكل منهجي عن تطبيقات LLM في جميع أنحاء الشركة. من نموذج hackathon الأولي إلى خدمة الإنتاج الموصوفة في مدونة الهندسة لسبتمبر 2024، مرت فريق Data Platform بأكثر من 20 تكرار معماري.

الحالة ذات قيمة بالضبط لأمانتها الهندسية: نشرت أوبر ليس إعلانًا تسويقيًا بل تحليلًا مفصلاً مع تطور الإصدار ومقاييس التقييم والمشاكل غير المحلولة — بما في ذلك الهلوسة وعدم حتمية التقييم. تم توقيع المقالة من قبل فريق من ثمانية مهندسي Data Platform — من مهندس رئيسي إلى المطورين الذين يركزون على إنتاجية LLM؛ إنه منتج منظمة هندسية وليس مختبر ذكاء اصطناعي. بالنسبة لأي شخص يبني text-to-SQL لشركته الخاصة، فهو واحد من أكثر المستندات العامة المفيدة في الصناعة.

المشكلة

استغرق متوسط الاستعلام حوالي 10 دقائق من مؤلفه. تشريح تلك الدقائق: العثور على الجداول الصحيحة من بين آلاف مجموعات البيانات، فهم مخطط من مائتي عمود، تذكر اتفاقيات المجال (كيفية تصفية أوامر الاختبار، أي منطقة زمنية التواريخ بها) — وفقط بعد ذلك كتابة SQL نفسه. على مقياس مئات الآلاف من الاستعلامات شهريًا هذا ضريبة إنتاجية ضخمة: قضت فرق العمليات الوقت على ميكانيكا الاستعلام بدلاً من التحليل والقرارات.

واجه النهج الساذج — 'فقط أعطِ LLM المخطط والسؤال' — حدودًا أساسية. استهلك مخطط جدول واحد كبير 40–60 ألف رمز، بينما نوافذ السياق للنماذج قبل عصر 128K كانت 32 ألف. غالبًا ما تربط الاستعلامات عدة جداول: لم يناسب المخطط فعليًا النموذج، ناهيك عن تكلفة وكمون هذه الاستدعاءات.

المشكلة الثانية كانت الناس. تتراوح الأوامر الفعلية للمستخدمين من الصيغ المفصلة الغنية بالكلمات الرئيسية إلى أسئلة من خمس كلمات بها أخطاء إملائية. ينهار خط أنابيب ساذج يتوقع مدخلات منظمة على حركة مرور مباشرة: سؤال قصير خالٍ من السياق ينقل إشارة قليلة جدًا إما لاختيار الجدول أو لإنشاء SQL صحيح.

والثالث: تكلفة الخطأ. SQL المولد الذي يبدو معقولاً ولكن يستخدم عمودًا غير موجود أو منطق عمل خاطئ أسوأ من عدم وجود إجابة — إما أنه يفشل أو، والأخطر، يُرجع أرقامًا خاطئة يتم اتخاذ قرارات بناءً عليها. يحمل المستخدمون، كما تقول الفريق، معيارًا عاليًا: يجب أن تعمل الاستعلامات 'ببساطة'.

الحل

كان الإصدار الأول، المجمع في hackathon، عبارة عن RAG كلاسيكي: بحث متجه k-nearest-neighbor على مجموعة صغيرة من 7 جداول من المستوى الأول و 20 استعلام SQL مرجعي، تم سحب 3 جداول و 7 عينات منها إلى الأمر، بالإضافة إلى تعليمات مع اتفاقيات خاصة بـ أوبر (معالجة التاريخ، شروط العمل). أثبت النموذج الأولي الطلب، لكن الدقة انخفضت على التنوع الفعلي للأسئلة والجداول — والتكرارات الإضافية التي تزيد عن عشرين حولت 'أمر واحد مع RAG' إلى خط أنابيب من الوكلاء المتخصصين.

كانت الخطوة الهيكلية الأولى 'مساحات العمل': مجموعات منسقة من الجداول وعينات SQL لمجال عمل معين. تشغل الإنتاج أكثر من 12 مساحة عمل نظام (Mobility و Core Services و Platform Engineering و IT و Ads وآخرين)، بالإضافة إلى مساحات عمل مخصصة لحالات الاستخدام الضيقة. المراجعة عمل يدوي من قبل خبراء المجال، وهي — وليس النموذج — توفر معظم كسب الدقة: يعمل البحث ليس عبر منصة كاملة بل ضمن مجموعة فرعية معالجة مسبقًا.

ثم يمر السؤال عبر خط الأنابيب. يصنف Intent Agent الاستعلام إلى مجالات عمل ويختار مساحة عمل، مما يقلل نطاق بحث RAG. يختار Table Agent جداول محددة — ويعرض القائمة للمستخدم، الذي يمكنه تأكيدها أو تحريرها: أضافت الفريق هذه الخطوة من التفاعل البشري بعد شكاوى حول اختيار جدول خاطئ. يزيل Column Prune Agent الأعمدة غير ذات الصلة من المخططات — حل هذا مشكلة الرمز: حتى مع نافذة GPT-4 Turbo بسعة 128K (النموذج 1106)، كانت المخططات الكاملة مكلفة وبطيئة، وقلص التقليم الكمون وتكاليف المكالمات بشكل كبير. يثري 'محسّن الأمر' المنفصل صيغ المستخدم الموجزة بسياق قبل الإنشاء.

ضد الهلوسة (الجداول والأعمدة غير الموجودة هي الوضع الفاشل الرئيسي) تستخدم الفريق وضع دردشة تكراري حيث يقوم المستخدم بتحسين الاستعلام، والتجريب مع وكيل التحقق الذي يجد بشكل متكرر ويصحح الأخطاء في SQL المُنشأ.

يستحق نظام التقييم اهتمامًا خاصًا. جمع الفريق مجموعة 'ذهبية' من أزواج السؤال→SQL من السجلات الفعلية للخدمة عبر المجالات وتشغيلها في وضعين: Vanilla (المسار الكامل من السؤال إلى SQL) و Decoupled (النية والجداول معينة مسبقًا، لقياس المكونات في معزل). الإشارات: دقة النية، تداخل الجداول المختارة مع المرجع (0–1)، نجاح تنفيذ الاستعلام، إرجاع نتائج غير فارغة، ودرجة التشابه القائمة على LLM مقابل SQL المرجعي. اكتشاف منفصل: تشغيل التقييم غير حتمي، مع اختلاف يصل إلى ~5% بين التشغيلات بدون تغييرات في الكود — لذا تتابع الفريق أنماط الخطأ على فترات طويلة بدلاً من الاستجابة لتقلبات المقاييس.

النتيجة

تنتج QueryGPT استعلامات موثوقة بدرجة كافية في حوالي 3 دقائق مقابل ~10 دقائق من التأليف اليدوي — ما يقرب من 70% من الوقت الموفر لكل استعلام. في الإصدار المحدود تبلغ الخدمة متوسط حوالي 300 مستخدم نشط يوميًا، 78% منهم يقولون أن الاستعلامات المولدة تقلل الوقت الذي كانوا سينفقونه على الكتابة يدويًا. على مقياس منصة 1.2 مليون استعلام شهريًا، يكون إمكانية التوسع واضحة — لكن الفريق يتعمد التطبيق التدريجي، وفي دروسه المنشورة يسمي بشكل صريح اختيار الجمهور الأولي الصحيح (personas) كدرس بحد ذاته: ابدأ حيث تكون الفائدة أعلى وتكون احتياجات SQL روتينية — مع فرق العمليات وليس مع مهندسي البيانات، الذين يحتاجون إلى مسودة LLM الأقل على الإطلاق.

تأخذ الدروس المنشورة للفريق نفس الأهمية. أولاً: تعمل LLMs بشكل ممتاز كمصنفات على المهام الضيقة — خط أنابيب من الوكلاء المتخصصين (النية → الجداول → الأعمدة) يتفوق باستمرار على أمر كبير واحد. ثانيًا: سؤال المستخدم وحده غير كافٍ كمدخل للإنشاء؛ يجب إثراؤه بسياق قبل استدعاء النموذج. ثالثًا: تعددية الإجابة (يتم حل نفس السؤال بشكل صحيح باستخدام جداول وأنماط SQL مختلفة) تجعل التقييم الآلي غامضًا بطبيعته — ومن ثم حكم LLM ومقارنة بصرية مقابل المرجع بدلاً من المطابقة الثنائية/عدم المطابقة.

إطار الأرقام بشكل صحيح: 10 و 3 دقائق هي تقديرات فريق أوبر؛ 78% هو تقرير ذاتي من المستخدم وليس قياس ساعة إيقاف؛ كانت الخدمة في إصدار محدود عند النشر. لا تنشر أوبر لا نسبة دقة الإنشاء ولا تأثيرًا ماليًا — وفي رأينا، هذا أكثر صدقًا من استقراءات المدونة التابعة لجهات خارجية التي ترسم الحالة بمئات الآلاف من الساعات الموفرة.

في رأينا، الدرس الرئيسي القابل للنقل في QueryGPT هو أن text-to-SQL الإنتاج هو 20% نموذج و 80% هندسة السياق: مساحات العمل المنسقة للمجال، تقليم المخطط، إثراء الأمر، وانضباط التقييم على مجموعة ذهبية. كل هذا ينتقل إلى أي شركة لديها منصة بيانات كبيرة — ولا يتطلب نموذجك الخاص ولا مقياس أوبر. الدرس الثاني هو الوتيرة: من hackathon إلى الإنتاج استغرق أكثر من سنة و 20+ تكرار. الفرق التي تتوقع text-to-SQL أن 'تعمل في شهر واحد' تقلل من شأن الذيل الطويل بالضبط للضبط الخاص بالمجال، وليس صعوبة LLMs.

الدروس المستفادة

1. text-to-SQL الإنتاج هو خط أنابيب من الوكلاء المتخصصين (النية → الجداول → الأعمدة)، وليس أمر كبير واحد: LLMs هي الأكثر موثوقية كمصنفات على المهام الضيقة.
2. مساحات العمل المنسقة مع عينات SQL لكل مجال تتفوق على تغذية النموذج بالمخطط بأكمله: الاستثمار الرئيسي هو المراجعة اليدوية من قبل خبراء المجال.
3. تقليم المخطط (Column Prune) يتعلق بالدقة والتكلفة: عدد أقل من الرموز — أرخص وأسرع وأفضل؛ حتى نافذة 128K لا تلغي اقتصاد السياق.
4. لا يمكن إدخال المستخدم أن يدخل النموذج كما هو: تتراوح الأسئلة الحقيقية من الإطناب إلى خمس كلمات بها أخطاء إملائية، و 'محسّن الأمر' قبل الإنشاء إلزامي.
5. التفاعل البشري في المكان الصحيح: تم إضافة تأكيد المستخدم لاختيار الجدول بعد شكاوى حقيقية — خطوة رخيصة تزيل أعلى مصدر خطأ.
6. تقييم على مجموعة 'ذهبية' مبنية من السجلات الفعلية، قياس المكونات في معزل؛ وانتبه لعدم حتمية تقييم LLM (~5% بين التشغيلات) — تتبع أنماط الخطأ، وليس تقلبات المقاييس.
7. إطار الجودة الصادق هو 'مسودة موثوقة بدرجة كافية في 3 دقائق'، وليس 'SQL مثالي': يبقى الإنسان كمراجع — شرط من شروط الثقة وليس ضعف المنتج.

الأسئلة الشائعة