أبيانت

هندسة التكامل القائمة على الذكاء الاصطناعي مع كلود كود: جلسة تصحيح أخطاء حقيقية

شرحٌ كاملٌ لهندسة التكامل القائمة على الذكاء الاصطناعي، مع التعليمات الفعلية.

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

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

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

الإعداد

هذا المنتج هو أحد منتجات التكامل مع CRMConnect الخاصة بنا، من Mindbody إلى HubSpotأبلغ أحد العملاء عن وجود خلل في مزامنة المبيعات المدفوعة بأكثر من طريقة دفع. فقد ظهرت عملية بيع بقيمة 8400 دولار أمريكي، موزعة على ثلاث طرق دفع، في نظام HubSpot كصفقة واحدة بقيمة 400 دولار أمريكي فقط، بينما اختفت قيمة الـ 8000 دولار أمريكي المتبقية من مسار المبيعات.

نتابع أعمال الهندسة في قسم المشكلات على GitHub. وتُحفظ محادثات العملاء في HubSpot Service Hub. بدأت الجلسة بتوجيه المُنشئ للذكاء الاصطناعي نحو العمل المطلوب.

اِسْتَدْعَى: "انظر إلى مسألة الدفع"

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

اِسْتَدْعَى: "ماذا يفعل المنطق وما هي الأتمتة / الإجراءات؟"

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

مفيد. لكن المقاول كان متقدماً بالفعل بفارق أكبر.

التلميح الذي غيّر كل شيء

اِسْتَدْعَى: "قارن هذا المعرّف الفريد للصفقة بالطريقة التي نستخدمها في مشروع crmconnect-mindbody-zoho. كنت أعتقد أننا حللنا المشكلة هناك. قم بإجراء مقارنة دقيقة للغاية."

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

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

وقد عادت بمقارنة مركزة. لقد حلّ تكامل Zoho هذه المشكلة بالفعل، ولكن ببنية مختلفة:

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

لوحتا منتج متجاورتان. عند ربط Mindbody بـ HubSpot، يتم إنشاء مربع صفقة واحد مسطح؛ وعند ربط Mindbody بـ Zoho، يتم إنشاء عملية شراء رئيسية بالإضافة إلى بنود وخيارات الدفع. يربط سهم منحني بينهما بعنوان "اقرأ التكامل الشقيق".

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

يقوم البنّاء بسحب المنظار للخلف

هنا كان الإنسان هو من يُبقي الأمور واقعية.

اِسْتَدْعَى: "لسنا مستعدين للإصدار 4.0 بعد. سنؤجله لوقت لاحق، فنحن الآن بحاجة إلى إصلاح المشكلات المتعلقة بالصفقات المفقودة التي أبلغ عنها العميل."

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

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

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

الحدس

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

لم يكن لدى البنّاء مرجع برمجي ليجادل فيه. كان لديه ذاكرة.

اِسْتَدْعَى: أظن أنني أضفت التاريخ لأنه كان مطلوبًا (دفعتان في نفس المعاملة، أو شيء غريب من هذا القبيل)؟

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

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

ابتداءً من يناير 2022:

تمت إضافة EPOCH MILLIS إلى معرف الصفقة المحفوظ في قاعدة البيانات للحفاظ على فرادته عند إجراء دفعات متعددة على نفس المنتج.

ابتداءً من فبراير 2022:

تمت إضافة تاريخ البيع إلى خاصية البحث عن الصفقات حسب العقار المخصص، بحيث تتم معالجة المدفوعات المتعلقة بالمبيعات السابقة.

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

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

وكان رد الذكاء الاصطناعي هو التراجع عن توصيته على الفور والتصريح بذلك بوضوح:

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

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

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

الجزء غير الجذاب: البناء، التشغيل، قراءة التتبع، الإصلاح

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

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

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

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

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

ما يعنيه هذا بالنسبة للبناة

إذا تجاهلنا السرد، فإليكم النموذج العملي:

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

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

هذا هو سير العمل الذي يستحق السعي إليه.