تحول Entity Resolution إلى بنية تحتية ذكاء اصطناعي، وليس تنظيف البيانات

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

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

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

تغيرت مشكلة التوتر

لمعظم حياتها العملية، كانت “هل هذه السجلات هي نفس الكيان؟” سؤالاً عن تنظيف البيانات. قمت بتشغيله في دفعة، وفقًا لجدول، في مكان ما داخل برنامج إدارة البيانات الرئيسية أو مستودع أو خط أنابيب تحليلي. لم يكن مثاليًا أبدًا، لكنه كان قابلًا للبقاء، لأن الإخراج كان تقريرًا يقرأه شخص ما في الأسبوع التالي. إذا لم يتم دمج سجلين لمورد واحد، خرجت قيمة الإنفاق قليلاً خاطئة، لاحظها المحلل، وتم исправله في الجلسة التالية. كان النظام يحتوي على فجوة زمنية. امتص الزمن الأخطاء.

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

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

مشكلة إحصائية من ستينيات القرن الماضي

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

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

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

لماذا يتحول الوكلاء إلى بنية تحتية

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

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

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

فجوة الجاهزية التي لا يسميها أحد بدقة

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

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

ماذا تتحقق قبل أن تترك وكيلًا يتصرف

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

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

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

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