ربط الذكاء الاصطناعي بما لديكم فعلًا

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

أما عندكم فالبيانات المفيدة في صندوق لا يُصدّر شيئًا، وفي ملف يصدّره أحدهم يوم الاثنين، وفي برنامج لم يعد ناشره يجيب. وهناك تموت هذه المشاريع، وهذا معروف قبل صرف أي دينار.

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

ثمّة ثلاث حالات وكلفتها ليست واحدة. الأولى: البرنامج يعرض واجهة برمجية موثَّقة. وهي الحالة المريحة، فالبيانات متاحة عند الطلب ومحدَّثة، ويُبنى التكامل في مواجهة عقد مستقر.

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

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

يستحق الحالة الثانية تدقيقًا يغيّر القرار غالبًا: فوتيرة التصدير ليست دائمًا التي يقترحها البرنامج. فكثير من التطبيقات التي تصدّر مرة في اليوم تستطيع التصدير عند الطلب إن أطلق أحد الأمر، وتتكفّل مهمة مبرمَجة بالباقي. والفارق بين «مرة في اليوم» و«كل ساعة» يكفي لجعل استعمال بدا مستبعَدًا مقبولًا.

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

ويستغرق هذا الاختبار نصف يوم ويحوّل وعدًا معماريًا إلى واقعة معايَنة. وإن رُفض أو أُجّل إلى لاحق فالتجريد موجود على الورق على الأرجح لا في الشيفرة.

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

يلزم مكان يُتحقَّق فيه من تعديل قبل أن يمسّ الإنتاج، ببيانات تشبه بياناتكم. وبدونه يصير كل تطوير مراهنة على نظام حيّ، والمراهنات تُخسَر يوم يكون هناك ناس.

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

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

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

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

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

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