Grab: تصنيف البيانات باستخدام LLM — 20,000+ كيان في الشهر الأول وتوفير 360 يوم عمل سنويًا

• LLM-powered data classification for data entities at scale — Grab Engineering Blog (Caspian & Data Governance), 2023-10
• Metasense V2: Enhancing, improving and productionisation of LLM powered data governance — Grab Engineering Blog (Buhrer, Parbat, Zeng), 2024-11-14
• Grab: LLM-Powered Data Classification System for Enterprise-Scale Metadata Generation (сторонний разбор) — ZenML LLMOps Database

السياق

Grab هي التطبيق الفائق الرائد في جنوب شرق آسيا: الركوب بالطلب وتوصيل الطعام والخدمات المالية في تطبيق واحد. يعني نموذج التطبيق الفائق بيانات التطبيق الفائق: تدير الشركة بيئة بحجم البيتابايت - آلاف جداول قواعد البيانات ومخططات رسائل Kafka التي يتم إنشاؤها وتعديلها بشكل مستمر من قبل عشرات فرق المنتجات.

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

تم التعامل مع المشكلة من قبل فريقي Caspian (هندسة البيانات) وحوكمة البيانات. في أكتوبر 2023 وصفوا على مدونة الهندسة كيفية انتقالهم من عملية تصنيف البيانات اليدوية إلى LLMs - وهي واحدة من أولى الحالات المنشورة لتطبيق النماذج التوليدية على حوكمة البيانات. تفصيل معبّر: خدمة التنسيق التي تدمج LLM في منصات البيانات تسمى Gemini - لا علاقة لها بنموذج Google بالاسم نفسه، حيث أن المنشور يسبق الإعلان عنه. في نوفمبر 2024 نشر الفريق تتمة - Metasense V2 - حول ترقية النظام لتغطية بحيرة البيانات بأكملها، مما يجعل هذا مثالًا نادرًا موثقًا لنظام LLM يتطور عبر جيلين.

المشكلة

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

كانت البدائل المتاحة للفريق غير كاملة. الاستكشافات الثابتة (التعبيرات العادية على أسماء الأعمدة) لا تفهم الدلالات: عمود user_note يمكن أن يحتوي على أي شيء من تعليق تقني إلى عنوان ورقم هاتف. الخدمة المتخصصة في التصنيف التي قيّمها الفريق بالتوازي مع LLMs تطلبت قواعد محددة مسبقًا وكافحت مع دلالات الأعمدة في سياق أعمال Grab. سيعني تدريب نموذج ML داخلي أولاً تجميع مجموعة بيانات كبيرة موسومة - أي حل نفس مشكلة الوسم، مع البنية الأساسية للتعلم الآلي في الأعلى.

قدمت النماذج التوليدية مسارًا ثالثًا: LLM لديه معرفة عامة كافية للتمييز من خلال أسماء الأعمدة والوصفات فيما إذا كان يتعامل مع رقم هاتف أو عنوان أو معرف جهاز، ويمكن التعبير عن متطلبات التصنيف في نص الطلب العادي - لا رمز، لا تدريب النموذج. لكن هذا المسار جاء مع قيود الهندسة: سياق GPT-3.5 مجرد 4,000 رمز (تقريبًا 3,000 كلمة)، والحصة Azure OpenAI هي 240K رمز في الدقيقة المشتركة عبر جميع نشر الشركة.

الحل

قام الفريق بتوصيل GPT-3.5 إلى Gemini - خدمة تنسيق تأخذ طلبات التصنيف من منصات البيانات. تم بناء البنية المعمارية للحصص والنطاق: يتم تجميع الطلبات في قوائم انتظار الرسائل، ومحدد معدل على مستوى سير العمل يحافظ على التدفق ضمن حد Azure OpenAI (240K رمز في الدقيقة)، وبيانات الكيان - أسماء الأعمدة والوصفات - يتم ضغطها في موجه ضمن سياق 4,000 رمز؛ الجداول العريضة جدًا تتم معالجتها على أجزاء. بالتوازي مع LLM، كان مصنف تابع يعمل خلال فترة التقييم - مقارنة محرك مباشرة على نفس تدفق البيانات.

تم تحقيق الجودة من خلال هندسة الطلب، بدون تدريب نموذج مخصص: متطلبات واضحة لكل علامة، عينات قليلة، إخراج مقيد بمخطط صارم عبر تعريفات DTO، وتفصيل مهم - علامة <None> افتراضية للحالات غير المؤكدة حتى لا يفرض النموذج تصنيفات مريبة. وصف الفريق الدقة الناتجة بأنها 'دقيقة بشكل مفاجئ'. تتدفق النتائج إلى منصات البيانات عبر Kafka، ويتلقى مالكو البيانات إشعارات التحقق الأسبوعية لتأكيد أو تصحيح العلامات المقترحة. ظل الإنسان في الحلقة، لكن الدور تغير من مسمي إلى مدقق.

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

الجيل الثاني من النظام - Metasense V2 (نوفمبر 2024) - أصلح نقاط الضعف الموجودة في حركة المرور المباشرة: كان النموذج مرتبكًا من خلال العينات المختلطة الكبيرة حيث اختبأت البيانات الشخصية بين البيانات غير الشخصية (رسائل البريد الإلكتروني التجارية بالأسماء القانونية، JSON المتداخلة، اتصالات الركاب). الإصلاحات جديرة بالملاحظة بسبب بساطتها: تم تقسيم نموذج واحد إلى اثنين - علامات PII بشكل منفصل عن البقية؛ تم تقليل عدد علامات PII من 21 إلى 8؛ تم تقليص الطلب من 1,254 إلى 737 كلمة؛ الجداول الأعرض من 150 عمودًا تنقسم إلى أجزاء. للتجريب السريع للطلبات، اعتمد الفريق LangChain و LangSmith، وقام بإعداد تنبيهات آلية على عتبات التصنيف الخاطئ في حالة تدهور الجودة.

النتيجة

في الشهر الأول بعد التطبيق، قام النظام بفحص أكثر من 20,000 كيان بيانات - بمتوسط 300-400 في اليوم، وهو معدل مستحيل بدنيًا بالنسبة لعملية يدوية. في استطلاع سبتمبر 2023، قال 80% من مالكي البيانات أن العملية الجديدة ساعدتهم في وسم كياناتهم، وللجداول المعترف بها غيّر المستخدمون أقل من علامة واحدة في المتوسط - مما يعني أن الغالبية العظمى من اقتراحات النموذج تم قبولها دون تغيير. عند دقيقتين من التصنيف اليدوي لكل كيان، توفر الأتمتة تقريبًا 360 يوم عمل سنويًا. بحلول V2، غطى النظام بحيرة البيانات بأكملها في Grab بما يسميه الفريق معدلات خطأ في التصنيف منخفضة بشكل استثنائي - على الرغم من أن الشركة لا تنشر نسبًا دقيقة، وجميع أرقام الحالة موثقة ذاتيًا بدون تدقيق خارجي.

في رأينا، هذه الحالة نموذج لاختيار المهام الرصين ل LLMs. تصنيف البيانات الوصفية هو سيناريو يكون فيه النموذج التوليدي مثاليًا تقريبًا: المدخل مضغوط (أسماء الأعمدة والوصفات)، والإخراج منظم (علامات من تصنيف ثابت)، وتكلفة خطأ واحد محدودة (مدقق بشري وإشعارات أسبوعية)، والبديل ليس 'نموذج آخر' بل آلاف ساعات العمل اليدوي. يتم حساب الاقتصاد بحذر وبوضوح: دقيقتان × 20,000+ كيان شهريًا هي حسابية سيقبلها أي مسؤول تنفيذي - على عكس النسب المئوية 'الإنتاجية' المجردة.

ملاحظتنا الثانية: التاريخ V1→V2 يُظهر بصراحة أن نظام LLM ليس 'اضبط وتجاهل'. كان الإصدار الأول، 'دقيق بشكل مفاجئ' في 2023، يراكم قائمة ضعف على حركة المرور المباشرة - وتم علاجها ليس بنموذج أقوى بل بتحليل المهام، وتقليص الطلب إلى النصف، والقابلية للملاحظة (LangSmith، تنبيهات الحد الأدنى). قد يكون هذا هو أكثر درس قابل للنقل في الحالة: في أنظمة LLM الإنتاجية، تهم الهندسة حول النموذج - التنسيق، والحصص، وأنماط الإخراج، وإصدار الطلب، والمراقبة - أكثر من اختيار النموذج نفسه.

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

1. حوكمة البيانات هي حالة استخدام LLM مقدرة بأقل من قيمتها: تصنيف الحساسية من البيانات الوصفية لم يحتاج إلى نماذج مخصصة - GPT-3.5 بالإضافة إلى هندسة الطلب كان كافيًا.
2. احسب التأثير بأيام العمل: دقيقتان لكل كيان × 20,000+ كيان شهريًا = حوالي 360 يوم عمل سنويًا - حسابية يفهمها أي مسؤول تنفيذي.
3. احتفظ بإنسان في الحلقة كمدقق: يؤكد مالكو البيانات على العلامات، ومقياس 'أقل من تصحيح واحد لكل جدول' يظهر نضج النظام.
4. صمّم للحصص على API من اليوم الأول: حدود Azure OpenAI (240K رمز/دقيقة) وسياق 4K رمز هي قيود معمارية صارمة، وليست نصوص دقيقة - ومن هنا قوائم Gemini والمحددات.
5. أعط النموذج الحق في قول 'لا أعرف': علامة <None> افتراضية للحالات غير المؤكدة توفر الحماية من التصنيفات المفروضة بشكل أفضل من المطالبة بإجابة.
6. نسخ الطلبات مثل الرمز: خطوط أنابيب التحليلات التي تسجل كل إصدار طلب، بالإضافة إلى LangSmith في V2، هي أساس تطور نظام LLM المنضبط.
7. يحتاج نظام LLM إلى تكرار ثان: أصلحت V2 نقاط ضعف V1 الحقيقية من خلال تحليل المهام (PII/non-PII)، وتقليص الطلب من 1,254 إلى 737 كلمة، وتنبيهات التصنيف الخاطئ - وليس بنموذج أكبر.

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