حلقة المنتج، الجزء 2: إيجاد الأخطاء التي لم يُبلَّغ عنها

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

Product Loop هو نظام تشخيص بناه فريق هندسة GoDaddy Airo AI Builder. يربط محادثات العملاء وسجلات الدعم والقياس عن بُعد وتاريخ الكود للعثور على مشاكل لا تظهر أبدًا كأخطاء صريحة، ثم يولّد تذاكر Jira منظمة حتى يتمكن المطورون من التصرف. إنه بالفعل في الإنتاج ويساعدنا على تحسين GoDaddy Airo AI Builder. يركز هذا المنشور على طبقة التشخيص: إيجاد مشاكل العملاء وفهم أسبابها ومساعدة المطورين على إصلاحها.

نموذج ذهني بسيط: حلقات داخل حلقات

فكّر في كيفية عمل مطعم.

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

هذه ثلاثة مستويات مختلفة من التغذية الراجعة:

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

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

عندما لا يفشل شيء، لكن العميل لا يزال يعاني

تخيّل عميلًا يطلب من Airo نقل صورة إلى أعلى الصفحة. يقول الوكيل إنه تم. يرد العميل: "لا، قصدت فوق العنوان." تتبع محاولة أخرى، ثم تصحيح آخر.

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

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

أحيانًا يعني إسعاد العملاء إزالة الشرح الإضافي الذي لم يكن ينبغي لهم تقديمه أبدًا.

كيف نجمع الأدلة

تجمع حلقة المنتج مصادر تكشف كل منها جزءًا مختلفًا من المشكلة:

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

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

من عرض متكرر إلى سبب محتمل

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

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

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

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

تذكرة Jira تمنح المطورين نقطة انطلاق

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

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

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

من التشخيص إلى إصلاح مقترح

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

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

لماذا الإبقاء على إنسان في الحلقة للدمج إذا كان التشخيص جيدًا جدًا؟

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

ما الذي يتغير للفريق والعميل

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

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

الأسئلة الشائعة

ما هي حلقة المنتج؟

حلقة المنتج هي نظام تشخيص طوّره فريق هندسة GoDaddy Airo AI Builder. يربط بيانات محادثات العملاء وسجلات الدعم وسجلات القياس عن بُعد وطلبات سحب GitHub ومشاكل Jira لتحديد المشاكل المتكررة في منتجات الذكاء الاصطناعي الوكيلي، بما في ذلك المشاكل التي لا تُطلق أبدًا خطأً صريحًا.

ما الفرق بين حلقة التنفيذ وحلقة المهمة وحلقة المنتج في الذكاء الاصطناعي الوكيلي؟

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

كيف تجد حلقة المنتج أخطاء لا يُبلّغ عنها العملاء أبدًا؟

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

لماذا لا تزال المراجعة البشرية مطلوبة حتى عندما يقترح وكيل ذكاء اصطناعي إصلاحًا؟

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

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

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

في المنشور التالي، سنرى كيف تساعدنا نفس إشارات الإنتاج في بناء تقييمات حول ما يفعله العملاء فعلًا.

هذا هو الجزء 2 من سلسلة حول بناء وقياس منتجات الذكاء الاصطناعي الوكيلي. اقرأ الجزء 1: عندما يتوقف منتجك عن امتلاك مسار واحد للبدء من البداية.