2025-11-13T13:52:10.448421

Safe, Untrusted, "Proof-Carrying" AI Agents: toward the agentic lakehouse

Tagliabue, Greco
Data lakehouses run sensitive workloads, where AI-driven automation raises concerns about trust, correctness, and governance. We argue that API-first, programmable lakehouses provide the right abstractions for safe-by-design, agentic workflows. Using Bauplan as a case study, we show how data branching and declarative environments extend naturally to agents, enabling reproducibility and observability while reducing the attack surface. We present a proof-of-concept in which agents repair data pipelines using correctness checks inspired by proof-carrying code. Our prototype demonstrates that untrusted AI agents can operate safely on production data and outlines a path toward a fully agentic lakehouse.
academic

وكلاء ذكاء اصطناعي آمنة وغير موثوقة و"تحمل الإثبات": نحو بحيرة البيانات الوكيلة

المعلومات الأساسية

  • معرّف الورقة: 2510.09567
  • العنوان: وكلاء ذكاء اصطناعي آمنة وغير موثوقة و"تحمل الإثبات": نحو بحيرة البيانات الوكيلة
  • المؤلفون: جاكوبو تاجليابوي (Bauplan Labs)، سيرو جريكو (Bauplan Labs)
  • التصنيف: cs.AI cs.DB
  • تاريخ النشر: 10 أكتوبر 2025 (نسخة أولية من arXiv)
  • رابط الورقة: https://arxiv.org/abs/2510.09567

الملخص

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

الخلفية البحثية والدافع

تعريف المشكلة

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

دافع البحث

  • القيمة العملية: تغطي خطوط الأنابيب معظم أحمال عمل بحيرات البيانات (بقياس وقت التطوير والحجم الحسابي الإجمالي)
  • التحدي التقني: اختبار قدرات الوكلاء على الاختراق في السيناريوهات عالية المخاطر
  • متطلبات النظام: الحاجة إلى واجهة موحدة لربط الوكلاء والأنظمة السحابية والمراقبين البشريين

المساهمات الأساسية

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

شرح الطريقة

معمارية بحيرة البيانات القابلة للبرمجة

تعريف خطوط الأنابيب

يتم تعريف خطوط الأنابيب كرسم بياني موجه غير دوري (DAG) للتحويلات، بالخصائص التالية:

@bauplan.model(materialization="REPLACE", name="A")
@bauplan.python("3.10", pip={"pandas": "2.0"})
def join_and_filter(
    trips=bauplan.Model("taxi_trips"),
    zones=bauplan.Model("taxi_zones")
):
    return trips.join(zones).do_something()

الخيارات التصميمية الرئيسية:

  1. تجريد FaaS: يتم التعبير عن المنطق التجاري كدوال بسيطة Table(s) → Table
  2. الإدخال/الإخراج الإعلاني: الدوال معزولة بالكامل، مع تحديد بيئة Python بشكل إعلاني

تنفيذ خطوط الأنابيب

يستخدم التنفيذ نمطاً معاملاتياً، يجمع بين مفاهيم Git:

$ pip install bauplan
$ bauplan run --project_dir P_folder

الضمانات المعاملاتية:

  • نمط الفرع والدمج: ينتقل التنفيذ تلقائياً إلى فرع نسخ عند الكتابة
  • العمليات الذرية: فقط التشغيلات الناجحة يتم دمجها في الفرع الرئيسي
  • الكتابة في الحماية: القراءة من الإنتاج لكن الكتابة معزولة، مما يتجنب القراءات المتسخة

تصميم آليات الأمان

قائمة التحقق الأمنية رباعية الأبعاد

نقطة الاهتمامالنمطآلية التجريد
ثقة البياناتالوصول إلى البياناتالإدخال/الإخراج الإعلاني
ثقة الكودتنفيذ الكودوقت تشغيل FaaS
صحة البياناتسلامة البياناتالتشغيل المعاملاتي
صحة الكودجودة الكودالتحقق قبل الدمج

تدابير الأمان المحددة

  1. ثقة البيانات:
    • يتم توسيط الإدخال/الإخراج دائماً بواسطة المنصة
    • لا يمكن للوكلاء الوصول إلى طبقة البيانات الفيزيائية (S3)
    • يوفر التحكم في الوصول القائم على الأدوار (RBAC) المستند إلى مفاتيح واجهة برمجية أذونات دقيقة
  2. ثقة الكود:
    • تعمل الدوال كعمليات مستقلة، معزولة عن المضيف والدوال الأخرى
    • لا يوجد وصول إلى الإنترنت
    • يدعم بناء الجملة الإعلاني فحص قائمة بيضاء للحزم
  3. صحة البيانات:
    • خطوط الأنابيب غير المكتملة لا تؤثر على الأنظمة النهائية
    • يمكن للمراجعة اليدوية التحكم في الأذونات للدمج في الفرع الرئيسي
    • يمكن استخدام السجل التاريخي لاستعادة الجداول في أي وقت
  4. صحة الكود:
    • اعتماد بروتوكول "الكود الذي يحمل الإثبات"
    • دالة المدقق Branch → bool تسمح بدمج فرع الوكيل
    • الاستفادة من عملية طلب السحب في Git-for-Data

معمارية تنفيذ الوكيل

مكونات النظام

  • Bauplan: منصة بحيرة البيانات القابلة للبرمجة
  • Bauplan MCP: يكشف واجهة برمجية بحيرة البيانات كأدوات
  • smolagents: إطار عمل ReAct، يتعامل مع الحلقات واستدعاءات الأدوات والسجلات
  • دعم LLM متعدد: يدعم OpenAI و Anthropic و TogetherAI من خلال واجهة LiteLLM
  • المدقق: خطوة "فحص الإثبات" قبل الدمج

قدرات الأدوات

  • الملاحظة: الحصول على الوظائف الفاشلة وسجلاتها
  • استكشاف البيانات: الاستعلام عن الجداول والتحقق من الأنواع
  • التحكم في التنفيذ: إنشاء فروع وبدء التشغيلات

إعداد التجربة

سيناريو التجربة

محاكاة الأعطال: بناءً على التقارير الصناعية والخبرة، محاكاة مشاكل عدم تطابق الحزم حول إصدار NumPy 2.0، مما يؤدي إلى انهيار الحاويات التي تستخدم pandas 2.0.

مكدس التكنولوجيا

  • نموذج الاستدلال: نماذج متقدمة مثل Claude Sonnet 4.5
  • الإطار: smolagents (ReAct قائم على Python)
  • المنصة: بحيرة بيانات Bauplan
  • مجموعة البيانات: مجموعة بيانات سيارات الأجرة في مدينة نيويورك

أبعاد التقييم

  • معدل النجاح: نسبة خطوط الأنابيب التي يصلحها الوكيل بنجاح
  • استخدام الرموز: موارد الحوسبة المطلوبة لإكمال المهمة
  • عدد استدعاءات الأدوات: تكرار تفاعل الوكيل مع النظام
  • الأمان: استقرار النظام عند فشل الوكيل

نتائج التجربة

النتائج الرئيسية

  1. الفروقات في أداء النموذج كبيرة:
    • تظهر النماذج المتقدمة (مثل Sonnet 4.5) اختلافات كبيرة في معدل النجاح واستخدام الرموز وعدد استدعاءات الأدوات
    • حتى عند فشل النموذج (مثل GPT-4-mini)، لم تحدث انقطاعات أو سلوكيات غير آمنة في بحيرة البيانات
  2. قيود الأنظمة التقليدية:
    • لا تدعم مكدسات التكنولوجيا التقليدية الرائدة في الصناعة (مثل Snowflake + dbt) إصلاح الوكيل
    • حتى لو كان لديها خوادم MCP وتخدم حالات استخدام متداخلة
    • MCP ضروري لكن غير كافٍ للأتمتة
  3. مرونة النظام:
    • يتطلب تبديل النموذج تغييراً واحداً فقط في التكوين
    • يدعم اختيار النموذج المرتبط بالخطوات في سيناريوهات قيود الميزانية
    • يدعم فروع البيانات التحكم المتزامن على نطاق واسع

التحقق من الأمان

  • لا انقطاع في الإنتاج: لم يحدث تلف لبيانات الإنتاج في أي من التجارب
  • التحكم في الأذونات فعال: تعمل آليات RBAC ومفاتيح واجهة برمجية بشكل صحيح
  • الضمانات المعاملاتية: لم تؤثر محاولات الإصلاح الفاشلة على الأنظمة النهائية

الأعمال ذات الصلة

تطور بحيرات البيانات

  • بحيرات البيانات هي المعمارية القياسية الفعلية للتحليلات السحابية وأحمال عمل الذكاء الاصطناعي
  • الاستفادة من فصل التخزين والحوسبة والدعم متعدد اللغات والدلالات الموحدة للجداول

استخدام أدوات وكيل الذكاء الاصطناعي

  • التحسينات في الاستدلال واستخدام الأدوات من نماذج اللغة الكبيرة تدفع القدرات على اتخاذ قرارات مستقلة
  • تركز وكلاء البنية التحتية الموجودة على مهام محددة، وتفتقر إلى دعم دورة الحياة الكاملة

الكود الذي يحمل الإثبات

  • الاستفادة من "وكلاء آمنة وغير موثوقة باستخدام الكود الذي يحمل الإثبات" من Necula و Lee
  • التكيف مع بيئات البيانات، مع التركيز على السياق التجاري بدلاً من الخصائص الرسمية

الخلاصة والمناقشة

الاستنتاجات الرئيسية

  1. بحيرات البيانات القابلة للبرمجة مناسبة بشكل طبيعي للوكلاء: يعتبر الرسم البياني الموجه غير الدوري الإعلاني وإدارة البيانات الشبيهة بـ Git مناسباً جداً لدعم استخدام الوكلاء المصمم بأمان
  2. يمكن ضمان الأمان: من خلال التجريدات المناسبة وآليات التحقق، يمكن لوكلاء الذكاء الاصطناعي غير الموثوقين العمل بأمان على بيانات الإنتاج
  3. تم التحقق من العملية: أثبت النموذج الأولي بنجاح القدرة على إصلاح خطوط أنابيب البيانات في سيناريوهات حقيقية

القيود

  1. نطاق التجربة محدود: لم يتناول النموذج الأولي الحالي المعالجة المتوازية على نطاق واسع
  2. الاعتماد على النموذج: الأداء تعتمد بشكل كبير على قدرات نموذج اللغة الكبيرة الأساسي
  3. خصوصية السيناريو: يركز بشكل أساسي على إصلاح خطوط الأنابيب، وتتطلب حالات الاستخدام الأخرى مزيداً من التحقق

الاتجاهات المستقبلية

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

التقييم المتعمق

المميزات

  1. النهج المنظم: أول معالجة منظمة للتحدي المفتوح لإصلاح خطوط أنابيب السحابة
  2. قيمة عملية عالية: حل نقاط الألم الفعلية لمهندسي البيانات
  3. تصميم أمني شامل: إطار عمل أمني شامل يأخذ في الاعتبار المخاطر متعددة الأبعاد
  4. مساهمة مفتوحة المصدر: توفير كود عامل كامل لتسهيل إعادة الإنتاج والتحسين من قبل المجتمع
  5. أساس نظري قوي: الاستفادة من نظريات ناضجة مثل الكود الذي يحمل الإثبات

أوجه القصور

  1. التقييم غير شامل بما فيه الكفاية: نقص التقييم المنظم على نطاق واسع وسيناريوهات متنوعة
  2. الاعتماد على المنصة: اعتماد كبير على منصة Bauplan، مع عدم التأكد من قابلية النقل
  3. تحليل التكلفة مفقود: لم يتم توفير تحليل تفصيلي للتكلفة والفائدة
  4. آليات معالجة الأخطاء: وصف غير كافٍ لآليات التعامل مع سيناريوهات الأخطاء المعقدة

التأثير

  1. المساهمة الأكاديمية: توفير اتجاه بحثي جديد لتطبيق وكلاء الذكاء الاصطناعي في البنية التحتية للبيانات
  2. القيمة الصناعية: توفير حل عملي وقابل للتطبيق لأتمتة هندسة البيانات
  3. الدفع التكنولوجي: تعزيز تطور البنية التحتية للبيانات القابلة للبرمجة

السيناريوهات المناسبة

  1. فرق البيانات في المؤسسات: مناسبة للمؤسسات التي تحتاج إلى أتمتة صيانة خطوط أنابيب البيانات
  2. المعمارية الأصلية السحابية: مناسبة بشكل خاص للمنظمات التي اعتمدت بالفعل معمارية موجهة بواسطة واجهات برمجية
  3. ثقافة DevOps: مناسبة للفرق ذات ثقافة DevOps قوية وسير عمل Git

المراجع

تستشهد الورقة بـ 24 مرجعاً ذا صلة، تغطي بشكل أساسي:

  • معمارية بحيرات البيانات (Zaharia وآخرون، 2021)
  • استخدام أدوات وكيل الذكاء الاصطناعي (Shen، 2024)
  • الكود الذي يحمل الإثبات (Necula و Lee، 1998)
  • تحديات هندسة البيانات (Data World، 2021)
  • البنية التحتية القابلة للبرمجة (Tagliabue وآخرون، 2024)

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