Watcher Eye: تحليل ملفات ECU بمساعدة عدة وكلاء ذكاء اصطناعي
فتح ملف ECU داخل محرر Hex سهل. المشكلة تبدأ بعد ذلك: أي جزء يمثل كوداً؟ أين توجد بيانات المعايرة؟ هل الملف قراءة كاملة أم جزء من الذاكرة؟ وهل النمط الذي يبدو كخريطة هو فعلاً جدول معايرة أم مجرد مصادفة رقمية؟
هذه الأسئلة هي نقطة انطلاق Watcher Eye. الفكرة ليست وضع نموذج لغوي أمام ملف BIN وانتظار إجابة واثقة. الهدف هو بناء مسار تحليل يجمع أدوات حتمية، ووكلاء ذكاء اصطناعي لكل منهم مهمة محددة، ومراجعاً بشرياً يملك القرار النهائي.
أريد للنظام أن يقول: هذه حقيقة وجدتها، وهذه فرضية تدعمها أدلة، وهذا جزء لا أستطيع تفسيره بعد. هذا الفصل أهم من أي واجهة مبهرة.
لماذا لا يشرح ملف BIN نفسه؟
ملف BIN هو تسلسل من البايتات. لا يحمل بالضرورة أسماء المتغيرات أو الوحدات أو وصف المحاور أو الغرض الوظيفي من كل عنوان. المعنى يعتمد على معلومات خارج الملف، مثل:
- نوع وحدة التحكم والمعالج.
- رقم البرنامج وإصدار العتاد.
- ترتيب البايتات وطريقة تنظيم الذاكرة.
- هل القراءة كاملة أم جزئية.
- مناطق الكود والمعايرة والبيانات الثابتة.
- الضغط أو التشفير أو التوقيع عند وجوده.
- خوارزميات التحقق من السلامة.
- ملفات الوصف المتاحة مثل A2L أو DAMOS.
معيار ASAM MCD-2 MC يوضح سبب أهمية ملف A2L. فهو يصف أنواع البيانات، والأبعاد، وتخطيط السجلات، ومواقع المتغيرات في الذاكرة، وطريقة تحويل القيم الخام إلى وحدات مفهومة. عند توفر هذا الوصف يصبح الوصول إلى المتغير أكثر دقة. عند غيابه يتحول جزء كبير من العمل إلى استدلال يحتاج دليلاً واختباراً.
لذلك يجب ألا يكتب Watcher Eye اسم خريطة أو وحدتها لمجرد أن شكل الأرقام يشبه مثالاً رآه من قبل. التشابه بداية بحث، وليس إثباتاً.
ما المقصود بعدة وكلاء ذكاء اصطناعي؟
التعبير لا يعني أن الخلايا العصبية الرقمية تعقد جلسة عصف ذهني. في التطبيق العملي، الوكيل مكون له دور ومدخلات وأدوات ومخرجات متوقعة. يتولى المنسق توزيع العمل، ثم يجمع النتائج ويمررها إلى وكيل آخر يحاول نقدها.
هذا قريب من نمط الأنظمة متعددة الوكلاء الذي تعرضه أبحاث Microsoft AutoGen. يمكن للوكلاء استخدام نماذج لغوية أو كود أو أدوات تحليل، ويمكن إدخال الإنسان ضمن الحوار. لكن وجود عدة وكلاء لا يجعل النتيجة صحيحة تلقائياً. إذا اعتمدوا جميعاً على الافتراض نفسه، فقد يكررون الخطأ بصيغ مختلفة.
التقسيم المفيد في Watcher Eye يمكن أن يكون كالتالي:
| الوكيل | مهمته | ما لا يسمح له بفعله |
|---|---|---|
| وكيل الاستقبال | تسجيل المصدر، وحساب البصمة، والتحقق من الحجم والنسخة | تعديل الملف الأصلي |
| وكيل البنية | تحديد المناطق والأنماط والسلاسل النصية والحدود المحتملة | تسمية وظيفة بلا دليل |
| وكيل مرشحات الخرائط | البحث عن جداول ومحاور وعلاقات رقمية محتملة | اعتبار كل مصفوفة خريطة معايرة |
| وكيل ملفات الوصف | ربط A2L أو البيانات الموثقة بالعناوين والأنواع والوحدات | تعويض ملف وصف مفقود بتخمين |
| وكيل النقد | محاولة إسقاط الفرضيات والبحث عن تفسير بديل | تغيير الأدلة الأصلية |
| وكيل التقرير | إخراج الحقائق والفرضيات والأسئلة المفتوحة | إخفاء درجة الثقة أو مصدر النتيجة |
القيمة هنا ليست في كثرة الوكلاء. القيمة في فصل المسؤوليات ومنع الوكيل الذي اقترح الفرضية من اعتمادها وحده.
مسار تحليل يمكن مراجعته
1. تثبيت مصدر الملف
قبل أي تحليل، يحتاج النظام إلى سجل واضح:
- من سلّم الملف؟
- هل توجد صلاحية قانونية وفنية لتحليله؟
- ما المركبة أو منصة الاختبار المرتبطة به؟
- ما أداة القراءة وطريقتها؟
- ما رقم ECU ورقم البرنامج إن كانا متاحين؟
- هل توجد قراءة أصلية أخرى للمقارنة؟
ثم يحسب النظام بصمة مثل SHA-256 ويحفظ الملف الأصلي للقراءة فقط. كل نتيجة لاحقة ترتبط بهذه البصمة. إذا تغير بايت واحد، فهذا ملف آخر ويجب ألا يرث نتائج النسخة السابقة.
2. جمع السياق قبل التخمين
المقاس وحده لا يكفي لمعرفة نوع الملف. يحتاج Watcher Eye إلى مقارنة المعلومات التي أدخلها المستخدم بما يستطيع استخراجه حتمياً، مثل السلاسل المقروءة، وقيم رؤوس معروفة عندما تكون موجودة، وتوزيع البايتات، والمناطق المتكررة أو الفارغة.
إذا تعارضت بيانات المستخدم مع الملف، يجب أن يتوقف المسار ويعرض التعارض. مثال: المستخدم اختار إصدار برنامج معين، بينما السلسلة الموجودة داخل الملف تشير إلى إصدار آخر. الاستمرار بصمت قد يجعل النظام يطبق تعريفات غير مناسبة.
3. تشغيل الأدوات الحتمية أولاً
قبل سؤال أي نموذج ذكاء اصطناعي، يمكن للكود تنفيذ أعمال أدق وأرخص:
- حساب البصمة والحجم.
- استخراج السلاسل النصية وعناوينها.
- قياس entropy على نوافذ ثابتة لاكتشاف تغير طبيعة المناطق.
- البحث عن تتابعات رقمية منتظمة.
- تجربة تفسيرات معروفة للأنواع الصحيحة والعائمة وترتيب البايتات.
- مقارنة الملف بقراءة مرجعية على مستوى العنوان.
- تطبيق parser لملف A2L إذا كان متاحاً.
دور الذكاء الاصطناعي يبدأ بعد إنتاج هذه القياسات. لا يجب أن يحسب النموذج ما يستطيع برنامج صغير حسابه بدقة وإعادة إنتاجه.
4. بناء فرضيات مرتبطة بأدلة
يمكن لوكيل مرشحات الخرائط أن يقترح أن منطقة معينة تبدو كجدول ثنائي الأبعاد. لكنه يحتاج إلى تسجيل سبب الاقتراح:
- توجد قيم محور أحادية الاتجاه قبل المنطقة.
- أبعاد المصفوفة المحتملة تتفق مع طول المحورين.
- القيم تتغير بسلاسة بدلاً من الضوضاء العشوائية.
- عنوان المنطقة يتطابق مع تعريف معروف في A2L، إن وجد.
- النمط يظهر في نسخة أخرى من البرنامج مع اختلافات محدودة.
غياب هذه الأدلة لا يمنع عرض المرشح، لكنه يخفض درجة الثقة ويمنع تحويله إلى حقيقة.
5. تكليف وكيل آخر بالنقد
وكيل النقد لا يعيد صياغة النتيجة. عليه أن يبحث عن سبب لرفضها:
- هل يمكن تفسير المنطقة كسلسلة تعليمات أو جدول بحث غير متعلق بالمعايرة؟
- هل اختير ترتيب بايتات يعطي شكلاً جميلاً فقط؟
- هل المحور المفترض يحوي قفزات لا تناسب التفسير؟
- هل توجد بيانات مفقودة تجعل الأبعاد غير مكتملة؟
- هل انتقلت المنطقة في إصدار برنامج آخر؟
- هل اتفق الوكلاء لأنهم استخدموا النموذج نفسه والمثال نفسه؟
إذا لم يستطع النظام وصف الاختبار الذي قد يُسقط الفرضية، فدرجة الثقة أعلى مما ينبغي.
6. عرض تقرير بطبقات واضحة
التقرير الجيد لا يدفن الشك داخل فقرة طويلة. يمكن تقسيم النتيجة إلى ثلاث طبقات:
- حقائق قابلة لإعادة الإنتاج، مثل الحجم والبصمة والسلاسل والعناوين الموصوفة في A2L.
- فرضيات مدعومة، مع الأدلة ودرجة الثقة والبدائل.
- أسئلة مفتوحة تحتاج ملفاً إضافياً أو خبيراً أو اختباراً معزولاً.
هذا مثال افتراضي على سجل نتيجة:
| النتيجة | الدليل | الثقة | الخطوة التالية |
|---|---|---|---|
| المنطقة بين عنوانين مرشح جدول | انتظام القيم ووجود محورين محتملين | متوسطة | مقارنتها بملف A2L أو إصدار معروف |
| السلسلة تمثل رقم البرنامج | نص مقروء في موضع ثابت داخل نسختين | مرتفعة | التحقق من سجل أداة القراءة |
| ترتيب البايتات المحتمل Little Endian | تفسير عدة قيم ضمن نطاق متسق | متوسطة | اختباره على حقول موثقة أخرى |
| الملف مضغوط | entropy مرتفع في أغلب المنطقة | منخفضة | اختبار signatures وأداة المورد، دون محاولة فك عشوائي |
كلمة منخفضة هنا مفيدة. هي تمنع المستخدم من اتخاذ قرار كبير فوق إشارة ضعيفة.
7. إبقاء الكتابة خارج المسار الأول
النسخة الأولى من Watcher Eye يجب أن تحلل وتشرح وتقارن. لا ينبغي أن تكتب تلقائياً إلى ECU أو تنتج ملفاً جاهزاً للبرمجة من دون مراجعة مستقلة.
معيار ASAM MCD-1 XCP يصف الوصول إلى متغيرات القياس والمعايرة عبر عناوين الذاكرة، ويعتمد على A2L لفهم خصائص هذه البيانات. هذا يوضح أن القراءة والكتابة ليستا مجرد تعديل رقم داخل جدول. العنوان، والنوع، وطريقة الوصول، وسياق النظام كلها أجزاء من العملية.
أي مسار كتابة مستقبلي يحتاج صلاحيات منفصلة، ونسخة أصلية، وتحقق سلامة، وبيئة اختبار، وخطة استرجاع، وموافقة بشرية صريحة. السيارة المستخدمة على الطريق ليست مكاناً لتجربة فرضية صنعها نموذج.
أين يمكن للشبكات العصبية أن تفيد؟
تفيد الشبكات العصبية عندما توجد بيانات تدريب جيدة ومشكلة قابلة للقياس. أمثلة محتملة:
- قياس التشابه بين مناطق من إصدارات مختلفة.
- ترتيب مرشحات الخرائط حسب أنماط تعلمها النموذج من ملفات موثقة.
- كشف منطقة شاذة مقارنة بعائلة برامج معروفة.
- تصنيف أجزاء الملف إلى فئات واسعة، مثل كود أو بيانات أو مساحة فارغة، مع إبقاء النتيجة احتمالية.
- اقتراح نسخة مرجعية أقرب لملف جديد.
لكن النموذج لا يستطيع استنتاج اسم دقيق ووحدة صحيحة ومجال آمن لخريطة مجهولة من الشكل البصري وحده. يحتاج ذلك إلى labels موثوقة، وتغطية لإصدارات مختلفة، وفصل بين بيانات التدريب والاختبار، وقياس للأخطاء الخطيرة لا لمتوسط الدقة فقط.
إذا دُرّب النموذج على عائلة محدودة من الوحدات، يجب أن يعرف النظام متى خرج الملف الجديد عن هذا النطاق. إجابة unknown أفضل من اسم مقنع وخاطئ.
الاتفاق بين الوكلاء ليس دليلاً
يمكن لثلاثة وكلاء أن يتفقوا لأنهم يستخدمون النموذج نفسه أو مرجعاً ناقصاً واحداً. لذلك لا أقيس الجودة بعدد الأصوات. أقيسها بهذه الأسئلة:
- هل جاءت النتيجة من أداة قابلة لإعادة التشغيل؟
- هل يوجد مصدر مستقل يدعمها؟
- هل حاول مراجع آخر إسقاطها؟
- هل تغيرت النتيجة عند تغيير الافتراضات؟
- هل يستطيع النظام تحديد ما لا يعرفه؟
النظام متعدد الوكلاء يصبح مفيداً عندما يخلق اختلافاً حقيقياً في الأدوار والأدلة. عدة نوافذ دردشة تكرر الجواب نفسه لا تضيف طبقة تحقق.
الخصوصية والملكية الفكرية
ملفات ECU قد تحتوي برنامجاً مملوكاً، أو معرفات، أو بيانات معايرة حساسة. رفعها إلى خدمة خارجية من دون فهم شروط الاحتفاظ والتدريب والوصول قرار غير مسؤول.
يحتاج Watcher Eye منذ البداية إلى:
- تشغيل محلي أو بيئة خاصة للحالات الحساسة.
- تشفير الملفات أثناء النقل والتخزين.
- صلاحيات حسب المشروع والدور.
- سجل يوضح من فتح الملف ومتى.
- سياسة حذف واحتفاظ قابلة للتطبيق.
- منع ظهور البايتات أو المفاتيح أو البيانات الحساسة في السجلات العامة.
- فصل ملفات العملاء وعدم استخدامها للتدريب من دون موافقة صريحة.
إطار NIST AI RMF مفيد هنا لأنه يعامل إدارة مخاطر الذكاء الاصطناعي كعمل مستمر يشمل التصميم والاستخدام والاختبار والتقييم، لا كرسالة تنبيه توضع أسفل الشاشة.
ما الذي يجعل النسخة الأولى قابلة للقبول؟
بدلاً من وعد عام بأن النظام يفهم ECU، يمكن وضع شروط قبول قابلة للاختبار:
- لا يعدل الملف الأصلي أبداً.
- يربط كل تقرير ببصمة الملف وإصدار أداة التحليل.
- يعيد الأدوات الحتمية النتيجة نفسها عند تشغيل المدخل نفسه.
- يعرض مصدر كل معلومة، سواء كانت parser أو A2L أو مقارنة أو نموذجاً.
- يفصل الحقائق عن الفرضيات داخل البيانات والواجهة.
- يتيح للمراجع رفض النتيجة وكتابة السبب من دون حذف سجلها.
- يقبل A2L ويربط العناوين والأنواع والوحدات عندما تكون متاحة.
- يختبر ملفات سليمة، وناقصة، وغير معروفة، ومضللة عمداً.
- يقيس false positives في اكتشاف الخرائط، لا عدد المرشحات فقط.
- يمنع التصدير أو الكتابة التلقائية في المرحلة الأولى.
يمكن أن يكون شكل المخرج الداخلي بسيطاً وواضحاً:
{
"file_hash": "sha256:...",
"finding": "candidate_calibration_table",
"offset": "0x001A4000",
"status": "hypothesis",
"confidence": 0.62,
"evidence": [
"two_monotonic_axis_candidates",
"stable_shape_across_reference_version"
],
"contradictions": [
"no_matching_a2l_entry"
],
"next_action": "request_matching_a2l_or_verified_map_pack"
}هذا السجل لا يبدو مثيراً مثل عبارة عقل رقمي يفكر معك، لكنه أكثر فائدة للمطور والخبير والمراجع. يمكن تتبعه واختباره والاعتراض عليه.
الشكل الذي أريده لـ Watcher Eye
أرى Watcher Eye كمساعد تحقيق تقني. يبدأ بالملف وسياقه، يشغل أدوات يمكن التحقق منها، يقترح فرضيات، يطلب من وكيل آخر نقدها، ثم يقدم تقريراً يعرف حدوده.
إذا نجح، فلن تكون ميزته أنه يعطي إجابة سريعة عن كل شيء. ستكون ميزته أنه يقلل الوقت الضائع بين أدوات منفصلة، ويحفظ أثر التفكير، ويمنع التخمين من الظهور في صورة حقيقة.
البداية الصحيحة ليست تدريب أكبر شبكة ممكنة. البداية هي مجموعة بيانات موثقة، ومسار تحليل حتمي، وصيغة أدلة واضحة، واختبارات تكشف متى يجب على النظام أن يتوقف ويقول: لا توجد معلومات كافية بعد.