AWS تعرض Text-to-SQL على Amazon Bedrock لترجمة أسئلة الأعمال إلى SQL

أصدرت AWS تحليلاً مفصلاً لحل Text-to-SQL على Amazon Bedrock، والذي يترجم أسئلة الأعمال باللغة الطبيعية إلى استعلامات SQL ويعيد الإجابة فوراً بشكل مفهوم. هذا ليس منتجاً جديداً منفصلاً، بل هو معمارية عملية للشركات التي تمتلك البيانات لكنها تفتقر إلى إجابات سريعة على أسئلة الأعمال.

لماذا ذكاء الأعمال ناقص

تشرح AWS المشكلة ببساطة: حتى في الشركات التي تتمتع بتحليلات قوية، يواجه المستخدمون اختناقات في الانتظار من أجل المحللين أو يتعاملون مع قيود لوحات المعلومات المُعدة مسبقاً. إذا تجاوز السؤال تقرير مُجمع مسبقاً، فأنت تحتاج إلى عمليات دمج وشرائح زمنية ومقاييس محسوبة ومعرفة بالمنطق الداخلي للجداول. بالنسبة للمبيعات والتمويل أو العمليات، هذا يعني فقدان ساعات أو حتى أيام في استعلام لمرة واحدة لا يبرر تطويراً منفصلاً بحد ذاته.

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

كيفية عمل خط الأنابيب

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

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

للسياق، تستخدم AWS مزيجاً من Amazon Neptune و OpenSearch: يخزن الرسم البياني العلاقات بين الجداول والأعمدة والمقاييس والمصطلحات والهياكل الهرمية داخل الشركة. بعد ذلك، يقوم النظام بإجراء بحث متجه عبر الأوصاف والقيم، ويعبر علاقات الرسم البياني، ويزود النموذج فقط بالجداول والحقول ومسارات الدمج والقواعد التجارية ذات الصلة. للأسئلة المعقدة، يمكن للمعمارية تشغيل عدة وكلاء بالتوازي واختيار النتيجة الأكثر موثوقية عن طريق التصويت بالأغلبية.

الإنتاج والتحكم

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

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

للحفاظ على التفاعل، توصي AWS بتوازي المهام الفرعية، وتوفير الرموز، وعدم تضخيم سياق الوكيل. بالتوازي، تتضمن المعمارية فوراً مرشحات Row-Level Security حتى لا يرى المستخدمون إلا الصفوف التي لديهم بالفعل إمكانية الوصول إليها وفقاً للقواعد المؤسسية.

ما يعنيه هذا

تظهر AWS بشكل فعال أن Text-to-SQL لا تعود عرضة توضيحية في وضع الحماية بل تصبح نمطاً هندسياً لسيناريوهات ذكاء الأعمال الحقيقية. الاستنتاج الرئيسي ليس أن LLM يستطيع كتابة SQL، بل أن النظام الفعال يتطلب رسم بياني للمعرفة والفحوصات والتنسيق والتحكم في الوصول. بالنسبة للفرق التي تريد إعطاء الأعمال واجهة دردشة للبيانات، هذه نقطة مرجعية جيدة: أقل سحراً، أكثر بنية تحتية وقواعد.