لا يخطئ عملاء الذكاء الاصطناعي بشكل مؤكد بسبب السياق السيئ، بل إنهم مخطئون بسبب سوء هندسة البيانات

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

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

الفشل الذي لا يبدو فاشلا

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

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

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

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

لماذا هذه مشكلة هندسة البيانات

الفرق التي تصاب بهذا الفشل تميل إلى تشخيصه بشكل خاطئ، وتميل إلى القيام بذلك مرتين.

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

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

• دخلت AWS للتو "طبقة السياق" تسابق مع الرسم البياني المعرفي الذي يتعلم من استخدام الوكيل.

• يستهدف Horizon context وCortex Sense الجديدان من Snowflake الأعراض الدقيقة التي افتتحت بها هذه القطعة: الوكلاء الذين يقدمون إجابات خاطئة واثقة لأنه لا يوجد شيء يحكم منطق العمل الذي يكمن وراءهم.

كلاهما استجابات حقيقية لمشكلة حقيقية، لكنهما يقعان فوقها بطبقة واحدة؛ لا يزال الرسم البياني المعرفي يعتمد على ما يغذيه.

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

ما هو مفقود بالفعل: إمكانية ملاحظة البيانات

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

قامت شركة أوبر ببناء منصة مخصصة لجودة البيانات وإمكانية المراقبة قبل فترة طويلة من وجود الجيل المعزز للاسترجاع. تدعم منصة جودة البيانات الموحدة الخاصة بهم أكثر من 2000 مجموعة بيانات مهمة وتكتشف حوالي 90% من حوادث جودة البيانات قبل أن تصل إلى المستهلكين النهائيين.

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

فيما بينهم، تغطي Uber وNetflix اثنين من الأشياء الأربعة التي تستحق البناء من أجلها. ومن الناحية العملية، أفكر في الأمر على أنه أربعة أبعاد، كل منها قابل للقياس بشروطه الخاصة.

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

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

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

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

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

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

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

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

ماذا تفعل صباح الاثنين

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

• هل يتم التحقق من صحة البيانات الأساسية وفقًا للمعايير المطلوبة من قبل المستهلكين؟

• ما هو أقدم جزء من المحتوى الذي يتم تقديمه حاليًا بثقة عالية؟

• هل سيختلف قطعتان من نفس المصدر مع بعضهما البعض في نفس نتيجة الاسترجاع؟

• هل يمكنك تتبع مصدرها إذا تبين أنها خاطئة؟

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

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