جداول الاستدلال لمراقبة وتصحيح النماذج

هام

هذه الميزة في المعاينة العامة.

توضح هذه المقالة جداول الاستدلال لمراقبة النماذج المقدمة. يوضح الرسم التخطيطي التالي سير عمل نموذجيا مع جداول الاستدلال. يلتقط جدول الاستدلال تلقائيا الطلبات الواردة والاستجابات الصادرة لنموذج يخدم نقطة النهاية ويسجلها كجدول دلتا كتالوج Unity. يمكنك استخدام البيانات الموجودة في هذا الجدول لمراقبة نماذج التعلم الآلي وتصحيحها وتحسينها.

ما هي جداول الاستدلال؟

تعد مراقبة أداء النماذج في مهام سير عمل الإنتاج جانبا مهما من دورة حياة نموذج الذكاء الاصطناعي وML. تبسط جداول الاستدلال المراقبة والتشخيصات للنماذج من خلال تسجيل مدخلات واستجابات الطلبات المقدمة باستمرار (التنبؤات) من نقاط نهاية خدمة نموذج الفسيفساء الذكاء الاصطناعي وحفظها في جدول Delta في كتالوج Unity. يمكنك بعد ذلك استخدام جميع قدرات النظام الأساسي Databricks، مثل استعلامات DBSQL ودفاتر الملاحظات ومراقبة Lakehouse لمراقبة نماذجك وتصحيحها وتحسينها.

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

بعض التطبيقات الشائعة لجداول الاستدلال هي ما يلي:

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

المتطلبات

• يجب تمكين كتالوج Unity لمساحة العمل الخاصة بك.
• يجب أن يكون لدى كل من منشئ نقطة النهاية والمعدل إذن Can Manage على نقطة النهاية. راجع قوائم التحكم بالوصول.
• يجب أن يكون لدى كل من منشئ نقطة النهاية والمعدل الأذونات التالية في كتالوج Unity:
  • USE CATALOG أذونات على الكتالوج المحدد.
  • USE SCHEMA أذونات على المخطط المحدد.
  • CREATE TABLE الأذونات في المخطط.

تمكين جداول الاستدلال وتعطيلها

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

مالك جداول الاستدلال هو المستخدم الذي أنشأ نقطة النهاية. تتبع جميع قوائم التحكم بالوصول (ACLs) في الجدول أذونات كتالوج Unity القياسية ويمكن تعديلها من قبل مالك الجدول.

تحذير

قد يصبح جدول الاستدلال تالفة إذا قمت بأي مما يلي:

• تغيير مخطط الجدول.
• تغيير اسم الجدول.
• حذف الجدول.
• فقدان الأذونات إلى كتالوج أو مخطط كتالوج Unity.

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

لتمكين جداول الاستدلال أثناء إنشاء نقطة النهاية، استخدم الخطوات التالية:

1. انقر فوق تقديم في واجهة مستخدم التعلم الآلي Databricks.

2. انقر فوق Create serving endpoint.

3. حدد تمكين جداول الاستدلال.

4. في القوائم المنسدلة، حدد الكتالوج والمخطط المطلوبين حيث تريد أن يكون الجدول موجودا.

   

5. اسم الجدول الافتراضي هو <catalog>.<schema>.<endpoint-name>_payload. إذا رغبت في ذلك، يمكنك إدخال بادئة جدول مخصصة.

6. انقر فوق Create serving endpoint.

يمكنك أيضا تمكين جداول الاستدلال على نقطة نهاية موجودة. لتحرير تكوين نقطة نهاية موجود، قم بما يلي:

1. انتقل إلى صفحة نقطة النهاية.
2. انقر فوق تحرير التكوين.
3. اتبع الإرشادات السابقة، بدءا من الخطوة 3.
4. عند الانتهاء، انقر فوق تحديث نقطة نهاية تقديم الخدمة.

اتبع هذه الإرشادات لتعطيل جداول الاستدلال:

هام

عند تعطيل جداول الاستدلال على نقطة نهاية، لا يمكنك إعادة تمكينها. لمتابعة استخدام جداول الاستدلال، يجب إنشاء نقطة نهاية جديدة وتمكين جداول الاستدلال عليها.

1. انتقل إلى صفحة نقطة النهاية.
2. انقر فوق تحرير التكوين.
3. انقر فوق تمكين جدول الاستدلال لإزالة علامة الاختيار.
4. بمجرد أن تكون راضيا عن مواصفات نقطة النهاية، انقر فوق تحديث.

سير العمل: مراقبة أداء النموذج باستخدام جداول الاستدلال

لمراقبة أداء النموذج باستخدام جداول الاستدلال، اتبع الخطوات التالية:

1. تمكين جداول الاستدلال على نقطة النهاية، إما أثناء إنشاء نقطة النهاية أو عن طريق تحديثها بعد ذلك.
2. جدولة سير عمل لمعالجة حمولات JSON في جدول الاستدلال عن طريق فك حزمها وفقا لمخطط نقطة النهاية.
3. (اختياري) انضم إلى الطلبات والاستجابات غير المحزمة باستخدام تسميات الحقيقة الأساسية للسماح بحساب مقاييس جودة النموذج.
4. إنشاء جهاز عرض عبر جدول Delta الناتج وتحديث المقاييس.

تقوم دفاتر الملاحظات البادئة بتنفيذ سير العمل هذا.

دفتر ملاحظات البدء لمراقبة جدول استدلال

ينفذ دفتر الملاحظات التالي الخطوات الموضحة أعلاه لفك الطلبات من جدول استدلال Lakehouse Monitoring. يمكن تشغيل دفتر الملاحظات عند الطلب، أو على جدول متكرر باستخدام وظائف Databricks.

دفتر ملاحظات بدء تشغيل جدول الاستدلال Lakehouse Monitoring

الحصول على دفتر الملاحظات

دفتر ملاحظات البدء لمراقبة جودة النص من نقاط النهاية التي تخدم LLMs

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

دفتر ملاحظات بدء تشغيل LlM inference table Lakehouse Monitoring

الحصول على دفتر الملاحظات

الاستعلام عن النتائج وتحليلها في جدول الاستدلال

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

لعرض الجدول في واجهة المستخدم: في صفحة نقطة النهاية، انقر فوق اسم جدول الاستدلال لفتح الجدول في مستكشف الكتالوج.

للاستعلام عن الجدول من DBSQL أو دفتر ملاحظات Databricks: يمكنك تشغيل تعليمات برمجية مشابهة للآتي للاستعلام عن جدول الاستدلال.

SELECT * FROM <catalog>.<schema>.<payload_table>

إذا قمت بتمكين جداول الاستدلال باستخدام واجهة المستخدم، payload_table فهو اسم الجدول الذي قمت بتعيينه عند إنشاء نقطة النهاية. إذا قمت بتمكين جداول الاستدلال باستخدام واجهة برمجة التطبيقات، payload_table يتم الإبلاغ عنها في state قسم الاستجابة auto_capture_config . على سبيل المثال، راجع تمكين جداول الاستدلال على نقاط نهاية خدمة النموذج باستخدام واجهة برمجة التطبيقات.

ملاحظة الأداء

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

مخطط جدول استدلال كتالوج Unity

تتم كتابة كل طلب واستجابة يتم تسجيلهما في جدول استدلال إلى جدول Delta بالمخطط التالي:

إشعار

إذا قمت باستدعاء نقطة النهاية مع دفعة من المدخلات، يتم تسجيل الدفعة بأكملها كصف واحد.

اسم العمود	‏‏الوصف	النوع
databricks_request_id	معرف طلب تم إنشاؤه بواسطة Azure Databricks مرفق بجميع طلبات خدمة النموذج.	سلسلة
client_request_id	معرف طلب اختياري أنشأه العميل يمكن تحديده في نص طلب خدمة النموذج. راجع تحديد client_request_id لمزيد من المعلومات.	سلسلة
date	تاريخ تلقي طلب خدمة النموذج بالتوقيت العالمي المتفق عليه.	التاريخ
timestamp_ms	الطابع الزمني في فترة مللي ثانية عند تلقي طلب خدمة النموذج.	LONG
status_code	رمز حالة HTTP الذي تم إرجاعه من النموذج.	Int
sampling_fraction	كسر أخذ العينات المستخدم في حالة أخذ عينة من الطلب. تتراوح هذه القيمة بين 0 و1، حيث تمثل 1 أن 100٪ من الطلبات الواردة قد تم تضمينها.	مزدوج
execution_time_ms	وقت التنفيذ بالمللي ثانية الذي أجرى النموذج استدلال له. لا يتضمن هذا زمن انتقال الشبكة الزائد ويمثل فقط الوقت الذي استغرقه النموذج لإنشاء تنبؤات.	LONG
request	نص JSON للطلب الخام الذي تم إرساله إلى نقطة نهاية خدمة النموذج.	سلسلة
response	نص JSON للاستجابة الأولية التي تم إرجاعها بواسطة نقطة نهاية خدمة النموذج.	سلسلة
request_metadata	خريطة لبيانات التعريف المتعلقة بنقطة نهاية خدمة النموذج المقترنة بالطلب. تحتوي هذه الخريطة على اسم نقطة النهاية واسم النموذج وإصدار النموذج المستخدم لنقطة النهاية.	سلسلة الخريطة<، السلسلة>

تحديد client_request_id

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

{
  "client_request_id": "<user-provided-id>",
  "dataframe_records": [
    {
      "sepal length (cm)": 5.1,
      "sepal width (cm)": 3.5,
      "petal length (cm)": 1.4,
      "petal width (cm)": 0.2
    },
    {
      "sepal length (cm)": 4.9,
      "sepal width (cm)": 3,
      "petal length (cm)": 1.4,
      "petal width (cm)": 0.2
    },
    {
      "sepal length (cm)": 4.7,
      "sepal width (cm)": 3.2,
      "petal length (cm)": 1.3,
      "petal width (cm)": 0.2
    }
  ]
}

client_request_id يمكن استخدام لاحقا لصلات تسمية الحقيقة الأساسية إذا كانت هناك جداول أخرى لها تسميات مقترنة client_request_idب .

القيود

• المفاتيح المدارة من قبل العملاء غير مدعومة.
• بالنسبة لنقاط النهاية التي تستضيف نماذج الأساس، يتم دعم جداول الاستدلال فقط على أحمال عمل معدل النقل المتوفرة.
• جداول الاستدلال غير معتمدة على نقاط النهاية التي تستضيف نماذج خارجية.
• يمكن أن يؤدي جدار حماية Azure إلى فشل إنشاء جدول دلتا كتالوج Unity، لذلك لا يتم دعمه بشكل افتراضي. تواصل مع فريق حساب Databricks لتمكينه.
• عند تمكين جداول الاستدلال، يكون الحد الأقصى لإجمالي التزامن عبر جميع النماذج المقدمة في نقطة نهاية واحدة هو 128. تواصل مع فريق حساب Azure Databricks لطلب زيادة إلى هذا الحد.
• إذا كان جدول الاستدلال يحتوي على أكثر من 500 ألف ملف، فلن يتم تسجيل أي بيانات إضافية. لتجنب تجاوز هذا الحد، قم بتشغيل OPTIMIZE أو إعداد الاستبقاء على الجدول عن طريق حذف البيانات القديمة. للتحقق من عدد الملفات في الجدول، قم بتشغيل DESCRIBE DETAIL <catalog>.<schema>.<payload_table>.

للحصول على قيود نقطة نهاية خدمة النموذج العام، راجع حدود ومناطق خدمة النموذج.