Bank DWH Studio

يصبح السؤال شيئًا يمكنك فحصه

Bank DWH Studio إثبات مفهوم شخصي لاستكشاف مستودع بيانات مصرفي كبير باللغة الطبيعية. اطرح سؤالًا، واختر إن شئت مجالًا مصرفيًا، وحدّد طريقة الإجابة: وكيل يبحث في الجداول ويختبر استعلامه، أو مسار معالجة يجلب المخطط ويكتب SQL لـ PostgreSQL في خطوة واحدة.

النتيجة أكثر من مجرد كتلة شيفرة عن قصد. فإلى جانب المسودة القابلة للتعديل تظهر الجداول المستخدمة والتفسير والافتراضات وملاحظات المراجعة والفحوص الأساسية، إضافة إلى الصفوف التي تعيدها المسودة من نسخة اصطناعية من المستودع. وعندما تنقص معلومة ضرورية، مثل السنة في طلب عن نهاية أغسطس، يمكن للمساعد أن يطلب توضيحًا.

كيف يعمل

1. اسأل بلغة الحياة اليومية. صِف الإجابة المصرفية التي تحتاج إليها، وضيّق البحث إلى مجال معيّن عند الحاجة، واطرح أسئلة متابعة تبني على الإجابات السابقة.
2. دع الوكيل يبحث. في وضع الوكيل، يبحث النموذج في فهرس للجداول، ويقرأ تعريفات الجداول التي ينوي استخدامها، ويختبر مسودته على المستودع، ويصلح كل ما ترفضه قاعدة البيانات قبل أن يجيب.
3. أو اكتب في خطوة واحدة. في وضع مسار المعالجة، تجلب واجهة خلفية مبنية على Node جزءًا محدودًا من المخطط من Elasticsearch، ويكتب النموذج المسودة بناءً عليه في استدعاء واحد، بينما تتولى قواعد مستندة إلى الفهرس بعض الأسئلة الشائعة.
4. مراجعة قبل الاستخدام. تابع خطوات الوكيل لحظة بلحظة، ثم عدّل المسودة أو انسخها، وتحقق من الصفوف التي تعيدها، وافحص سياقها وافتراضاتها.

ما هو على طاولة العمل

مَقيس لا مفترَض

الأداة التي تكتب SQL لا تفيد إلا بقدر صحة ما تكتبه، لذلك يقيس المستودع ذلك بدل أن يسلّم به.

يطرح مقياس معياري للنماذج 46 سؤالًا صعبًا، كل سؤال ثلاث مرات. تُقيَّم الأسئلة ذات الإجابة الصحيحة الواحدة بتشغيل المسودة على نسخة PostgreSQL مملوءة بالبيانات من المستودع. أما الأسئلة عن بيانات لا يحتويها المستودع، مثل الرواتب أو فقدان العملاء، فينبغي أن يُرد عليها بسؤال. ولا يجوز أن تصل طلبات تعديل البيانات إلى المستخدم أبدًا.

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

يجيب كل نموذج عن الأسئلة نفسها مرتين. في المرة الأولى يستخدم المستودع أسماء وصفية مثل fact_account_balance_daily. وفي الثانية يستخدم أسماء مبهمة مختصرة كما تكتبها مستودعات البنوك القديمة، مثل F_ACCT_BAL_D، مع الإبقاء على أوصاف الأعمدة. وتبقى البيانات والإجابات الصحيحة كما هي.

بأسماء وصفية

• gpt-oss-20b، النموذج الذي يستخدمه التطبيق: 86% إجابات صحيحة، و5 إجابات خاطئة بثقة، ونحو 200 سؤال في الدقيقة على A100 واحد.
• Qwen3.8-27B: 96% إجابات صحيحة دون أي إجابة خاطئة بثقة، لكنه أبطأ بنحو خمس مرات.
• gpt-oss-120b: ليس أدق من 20b، وسرعته أقل من النصف.

طلبت النماذج الثلاثة توضيحًا في كل مرة كان ينبغي لها ذلك، وأوقف فحص SQL كل محاولة كتابة من gpt-oss-20b.

بأسماء مبهمة

خسر كل نموذج مفتوح ما بين 22 و39 نقطة. وكانت الأخطاء الجديدة هي تحديدًا ما كانت الأسماء المقروءة تمنعه: عمود مُخمَّن، أو جدول أُسيء فهمه من اختصاره. ولم يسمح أي نموذج مفتوح بتمرير عملية كتابة.

• gpt-oss-20b: تراجع من 86% إلى 46% إجابات صحيحة، مع 17 إجابة خاطئة بثقة.
• Qwen3.8-27B: أفضل نموذج مفتوح، بنسبة 70% صحيحة و8 إجابات خاطئة بثقة.
• Gemini 3.8 Flash: الأفضل بين الجميع، بنسبة 72% صحيحة وإجابة واحدة فقط خاطئة بثقة، لأنه فضّل السؤال على التخمين.
• Claude Sonnet 5 وGPT-5.5 وGPT-4.1: ما بين 68 و70% صحيحة، لكن مع 9 إلى 18 إجابة خاطئة بثقة.
• GPT-6 Luna: بالغ في الحذر: ردّ بسؤال على 53 من 69 سؤالًا ولم يصب إلا في 22%.

النماذج المغلقة موجودة للمقارنة فقط. فهي لا تستطيع العمل على أجهزة البنك الخاصة، لذلك تُستدعى عبر OpenRouter. أما النماذج مفتوحة الأوزان فتعمل على GPU مستأجر عبر vLLM، يُحذف بعد الانتهاء، عادةً خلال 12 دقيقة على الأكثر وبأقل بكثير من دولار.

وكيل أم مسار معالجة

منذ أكتوبر، صار بإمكان التطبيق أن يجيب بصفته وكيلًا أيضًا، ويشغّل الاختبار الوضعين على الأسئلة والبيانات والنموذج نفسها. ويضيف 17 سؤالًا أصعب، مثل سجل قيد في تاريخ سابق، وتحويل العملات بأسعار يومية، والوسيط، والعملاء النشطين في كل ربع سنة. استخدمت هذه الجولات أسماء مبهمة على A100، وطُرح كل سؤال ثلاث مرات.

يُحصي عمود «خاطئة بثقة» أخطاء الوكيل في الأسئلة الـ23 الأصلية وفي الأسئلة عن بيانات غير موجودة. وزمن الإجابة هو الوسيط. وللمقارنة، سجّلت النماذج المغلقة العاملة بمسار المعالجة على الأسئلة الأصعب: Claude Sonnet 5 بنسبة 71%، وGemini 3.8 Flash بنسبة 69%، وGPT-4.1 mini بنسبة 55%، وGPT-4.1 بنسبة 49%، وGPT-6 Luna بنسبة 22% لأنه يعيد السؤال في معظمها. وتفوّق كل نموذج مفتوح يعمل وكيلًا على كل نموذج مغلق يعمل بمسار المعالجة.

من أين يأتي التحسّن

عند تفكيك الوكيل، مع gpt-oss-20b على الأسئلة الـ23 الأصلية، يتضح ما يضيفه كل جزء.

• البحث في الجداول يجعله آمنًا: تنخفض الإجابات الخاطئة بثقة من 17 إلى 3 أو 4 قبل تنفيذ أي شيء، لأن الوكيل يعثر على جداول لم يُعِدها بحث مسار المعالجة قط.
• اختبار المسودة يجعله صحيحًا: من دون إمكانية تشغيل استعلامه، يفشل نحو نصف المسودات، ومعظمها بسبب أعمدة مخمّنة في جدول التواريخ. وتكفي رسالة الخطأ من قاعدة البيانات لإصلاحها، والتحقق بـ EXPLAIN وحده، دون رؤية صف واحد، يحفظ التحسّن كله تقريبًا.
• قواعد العمل لا تضيف شيئًا ملموسًا: أدّى الوكيل بالجودة نفسها دون القائمة القصيرة من القواعد المصرفية التي يتلقاها.
• الثمن رموز ووقت: يستهلك سؤال الوكيل أضعاف الرموز التي يستهلكها سؤال مسار المعالجة، ويستغرق ضعفين إلى ثلاثة أضعاف الوقت.

في الأسئلة الأصعب، أخطاء gpt-oss-20b مسودات تعمل وتعيد إجابة خاطئة، وهذا ما لا يستطيع الاختبار كشفه.

النتائج الكاملة

تحتفظ علامة التبويب Model tests في التطبيق بكل تشغيل مسجَّل. تأتي هذه الجداول من تقريرها بتاريخ 27 سبتمبر 2026، والأدق أولًا. يمكن للنماذج مفتوحة الأوزان أن تعمل على أجهزة البنك الخاصة، أما النماذج المغلقة فاستُدعيت عبر OpenRouter للمقارنة.

أسماء مبهمة

أسماء وصفية

يُطرح كل سؤال ثلاث مرات. تعني «صحيحة» نسبة الإجابات الصحيحة من 69 إجابة عن أسئلة لها إجابة صحيحة واحدة. وتعدّ «خاطئة بثقة» المسودات التي عملت وأعطت نتيجة خاطئة، إضافة إلى المسودات عن بيانات لا يحتويها المستودع. ويُحسب «رد بسؤال» من 18 إجابة عن أسئلة حول بيانات غير موجودة، وتعدّ «كتابات غير آمنة» عدد ما وصل إلى المستخدم من 15 إجابة عن طلبات تعديل البيانات.

هناك تشغيلان آخران بلا تقييم. فقد دخل Gemma 4 26B في حلقة متكررة مع مخرجات JSON الصارمة، وهو خلل في التشغيل لا مقياس للجودة، أما Devstral Small 2 فلا يعمل على A100 إطلاقًا.

يفصّل التقرير النتائج أيضًا سؤالًا بسؤال، وهناك تظهر كلفة الأسماء المبهمة. فمعها لم يُجب أي نموذج عن خمسة أسئلة أصاب فيها Qwen3.8-27B في كل مرة مع الأسماء الوصفية، مثل عدد القروض المتأخرة أكثر من 90 يومًا.

النموذج نفسه، خوادم مختلفة

يتصل التطبيق بأي نقطة وصول متوافقة مع OpenAI، لذا يبدو الانتقال من مزوّد مستضاف إلى خوادم البنك الخاصة مجرد تغيير في الإعدادات. تتحقق أداة تقييم منفصلة مما إذا كان الأمر كذلك فعلًا. شُغّلت أوزان gpt-oss-20b نفسها لدى مزوّد مستضاف، وعلى CPU، وعلى وحدات GPU مستأجرة عبر llama.cpp وvLLM وSGLang.

اختار كل خادم الجداول الصحيحة. وظهرت الفروق في مواضع أخرى: في عمليات الربط الاختيارية التي أضافتها المسودة، وفي ما إذا كان الطلب المدمّر يُرفض مباشرة أم يوقفه فحص SQL لاحقًا، وتحت الضغط. حافظ vLLM على صيغة JSON الصارمة مع 64 طلبًا متزامنًا، ووصل إلى نحو 270 سؤالًا في الدقيقة على RTX 4090 واحدة. أما SGLang فخالف هذه الصيغة تحت الضغط حتى شُغّل بإعداد أكثر صرامة، وهو خلل لم يظهر قط مع طلب واحد في كل مرة.

أعادت تجربة أخرى كتابة الكتالوج بأسماء مختصرة على طريقة الحواسيب المركزية. ومع الإبقاء على أوصاف الجداول والأعمدة، اجتاز النموذجان جميع الأسئلة الأساسية الاثني عشر. وبعد حذف الأوصاف لم ينجح إلا النصف، وهي إشارة واضحة إلى أن جودة البيانات الوصفية لا تقل أهمية عن النموذج.

معرض الصور

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

ويبقى الإنسان في الحلقة

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

تتحقق الفحوصات الآلية من أن صيغة العبارة مخصصة للقراءة فقط ومن الإشارات إلى الجداول المعروفة. أما صحة بناء SQL ومراجع الأعمدة والمعنى من منظور الأعمال فتظل بحاجة إلى مراجعة بشرية. جميع الأسماء والعلاقات والمقاييس في المستودع مواد اختبار اصطناعية وليست تعريفات مصرفية معتمدة.

تحت غطاء محرك السيارة

يشغّل إثبات المفهوم المنشور واجهة خلفية مبنية على Node وElasticsearch ومستودع PostgreSQL للقراءة فقط في حاويات دون صلاحيات الجذر على خادم Oracle Ampere A1، ويكتب SQL باستخدام gpt-oss-20b عبر مزوّد مستضاف. ويوثّق المستودع أيضًا بنية مستقبلية أوسع، مفصولة بوضوح عن إثبات المفهوم الأصغر المنشور.