فرض الاصطلاحات على اكتشاف عناصر المخططات الهيكلية

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

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

كما أوضحنا في هذا المقال السابق، نسعى إلى استخدام الذكاء الاصطناعي (AI) والتعلم الآلي (ML) في مواضع مختلفة من منصتنا. ومع ذلك، نعلم أن التعلم الآلي لا يستطيع حل كل مشكلة، على الأقل في الوقت الراهن. تُعد واجهة برمجة تطبيقات الرؤية جزءًا من منظومة أكبر، وتقتصر مهمتها على اكتشاف المربعات المحيطة. وبعد ذلك، يجب تحويل هذه المربعات المحيطة الخام إلى تمثيل بلغة تعريف واجهة المستخدم (UIDL). ثم تتولى مولدات الشيفرة لدينا، إلى جانب بعض طبقات اتخاذ القرار الخاصة بنا، إنشاء الشيفرة.

لقطة شاشة ومخطط هيكلي لموقع Stackoverflow.com

الحاجة إلى البيانات#

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

بعض المخططات الهيكلية التي عثرنا عليها على الويب

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

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

إرشاداتنا الحالية لرسم المخططات الهيكلية

كان لدينا X، لكننا ما زلنا بحاجة إلى Y#

أبسط تصور للتعلّم الآلي هو أن الحاسوب يتعلم بنفسه دالةً تتنبأ بـ Y انطلاقًا من X، وذلك من خلال الاطلاع على عدد كبير من الأمثلة. في تلك المرحلة، كنا قد جمعنا بضع مئات من الصور، أي إن X أصبح لدينا. وعرفنا أن ذلك سيكون كافيًا لإثبات المفهوم، فانتقلنا إلى الخطوة التالية: إضافة التعليقات التوضيحية للحصول على Y.

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

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

الحاجة إلى بيانات متسقة#

بعد أن حصلنا على القيمتين X وY، تمكّنا أخيرًا من بدء الجزء الممتع: تدريب النموذج. استغرق ذلك وقتًا أقل بكثير من جمع البيانات، وكانت الخلاصة، بالطبع، أننا بحاجة إلى مزيد من البيانات!

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

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

• هل هو صورة أم زر؟
• هل هو عنوان أم فقرة؟
• هل هو حقل إدخال نص أم زر؟

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

مخطط هيكلي رفعه أحد المستخدمين على اليسار، وإلى جانبه مخطط هيكلي من مجموعة بيانات التدريب لدينا على اليمين

الحاجة إلى إرشادات أكثر صرامة#

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

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

إرشاداتنا المستقبلية لرسم المخططات الهيكلية

كان اتخاذ هذا القرار صعبًا، لكننا نعتقد بشدة أن القيود التي أضفناها ستجلب فوائد مهمة تفوق ما تفرضه من محدوديات، مثل:

• هل هو حقل إدخال نص أم زر؟
• هل هو صورة أم زر؟
• اجعل التعليق التوضيحي واضحًا لا لبس فيه

الخلاصة#

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