Michael Johnsonاعتبارًا من 5 نوفمبر، أصبح بإمكان الفرق التي تستخدم GitHub Copilot Code Review الاطلاع في تقارير واجهة API على الملاحظات التي اتخذ المطورون إجراءات بشأنها. وفي اليوم نفسه، أضافت GitHub حقولًا تساعد المسؤولين على اكتشاف الثغرات في بيانات القياس عن بُعد والإصدارات القديمة من المحررات. وتمنح هذه التحديثات المديرين ومالكي المؤسسات طريقة أكثر تحديدًا للتحقق من أداء مراجعة الذكاء الاصطناعي ومدى اكتمال بيانات استخدام Copilot.
كيفية قياس الاستجابة لملاحظات الذكاء الاصطناعي
أُضيف الكائن `copilot_code_review` إلى السطر اليومي للتقرير الخاص بالمستودع `repos-1-day`. ومن حقوله `total_comments_evaluated`، وهو عدد الملاحظات التي جرى تقييمها، و`total_comments_addressed`، وهو عدد الملاحظات التي استجاب لها المطور. ولحساب نسبة الملاحظات التي عولجت في مستودع ما، يُقسَم الرقم الثاني على الأول. وترد الحقول الجديدة في تحديث واجهة Copilot usage metrics API.
تحتسب GitHub الإجراء إذا طبّق المطور الإصلاح المقترح، أو طلب من Copilot تنفيذه، أو عدّل الشفرة بنفسه، أو ردّ بأن الإصلاح سيُدرج في طلب السحب التالي. ويصنّف التقرير التعليقات أيضًا بحسب مستوى الخطورة ومستوى المراجعة ونوع الملاحظة، وما إذا كانت هناك تعليمات أو أدوات إضافية. ويتيح ذلك للفريق دراسة أمور مثل اختلاف الاستجابة لتعليقات الأمان عن الاستجابة للملاحظات الأخرى، أو الفئات التي تتطلب مزيدًا من العمل اليدوي.
يقيس هذا المؤشر الإجراء المسجّل، لا الجودة المؤكدة للإصلاح. لذلك من المفيد قراءته إلى جانب مراجعة الشفرة وحالة طلب السحب: فارتفاع نسبة التعليقات التي عولجت يعني أن الملاحظات لاقت استجابة، لكنه لا يثبت بحد ذاته أن كل التغييرات صحيحة أو ضرورية. وثمة نقطة أخرى مهمة: تُحتسب التعليقات في يوم دمج طلب السحب، لا في يوم نشر Copilot لها.
لماذا يختلف مؤشر الإجراءات عن قبول الاقتراحات
كانت الحقول السابقة تحتسب مرات تشغيل Copilot Code Review والحالات التي نقر فيها المستخدم زر تطبيق اقتراح جاهز. أما المؤشر الجديد فيشمل طرقًا أكثر للاستجابة: إذ يمكن للمطور تنفيذ الإصلاح بنفسه، أو طلب ذلك من Copilot، أو تأجيل التغيير إلى طلب السحب التالي. لذلك يجيب `total_comments_addressed` عن سؤال الإجراءات المتخذة بشأن الملاحظات، بينما يقتصر `total_copilot_applied_suggestions` على قبول الاقتراحات التي يمكن تطبيقها بإجراء واحد.
ويضم التقرير أيضًا `total_merged_no_human_change_request_after_review`، وهو عدد طلبات السحب المدمجة التي راجعها Copilot ولم يطلب أي شخص تعديلها بعد المراجعة الأولى. وتصف هذه المؤشرات مراحل مختلفة من العمل، لذا من الأفضل الاطلاع عليها معًا: يعكس الأول الاستجابة للتعليقات، والثاني مسار المراجعة حتى الدمج.
تُظهر الحقول الجديدة أسباب نقص التقارير
يضيف تحديث منفصل صدر في 5 نوفمبر معلومات عن بيانات القياس عن بُعد من جهة العميل وإصدارات الأدوات. يبيّن الحقل `client_telemetry_present` ما إذا كانت أحداث محرر المستخدم قد وصلت في يوم معين، فيما يحدد `usage_metrics_requirements` ما إذا كانت بيئة التطوير المتكاملة والملحقات تستوفي الحد الأدنى من الإصدارات اللازمة للمقاييس. ويحصل المسؤولون أيضًا على أعداد يومية للمستخدمين الذين لا تتوفر عنهم بيانات قياس عن بُعد، وللمستخدمين الذين لديهم مكوّن واحد على الأقل بإصدار قديم. وترد التفاصيل في ملاحظة الثغرات في بيانات Copilot.
يساعد ذلك على التمييز بين نشاط المستخدم واكتمال إعداد التقارير. وتوضح GitHub أن المستخدم قد يُحتسب نشطًا حتى إذا لم تصل الأحداث من المحرر؛ وفي هذه الحالة يفقد التقرير تفاصيل مثل توزيع الاستخدام بحسب الميزات والنماذج. وقد تشمل الأسباب استخدام إصدار قديم من بيئة التطوير المتكاملة أو الملحقات، أو تعطيل القياس عن بُعد في المحرر، أو حظر الأحداث بواسطة وكيل وسيط أو جدار حماية للشبكة.
لا ينبغي جمع عدّادي الثغرات باعتبارهما عددًا للمستخدمين الفريدين، إذ قد يظهر الشخص نفسه في كلتا المجموعتين. كذلك، لا يضمن استخدام إصدار سليم من المحرر وصول بيانات القياس عن بُعد؛ فقد تستمر القيود الشبكية، مثلًا. وإذا كانت القيمة مفقودة أو تساوي `null`، فإن GitHub تشير إلى أن البيانات غير متاحة، لا إلى أنها صفر أو أن المشكلة غير موجودة.
ما الذي يتغير للفرق
تتيح هذه التحسينات استبدال مقياس Copilot العام للنشاط بفحصين أكثر ارتباطًا بالعمل: ما يحدث لملاحظات Code Review، ومدى موثوقية البيانات التي يستند إليها التقرير الداخلي. ويمكن لقادة الفرق الهندسية مقارنة أنواع التعليقات والمستودعات، فيما يستطيع المسؤولون تحديد المستخدمين الذين يحتاجون إلى تحديث بيئة التطوير المتكاملة أو الملحقات، أو إلى التحقق من إعدادات الشبكة.
تتوفر التقارير على مستوى المؤسسة والشركة للمستخدمين الذين يملكون أذونات عرض مقاييس Copilot المناسبة، شريطة تفعيل سياسة Copilot usage metrics. وتوجد بيانات Code Review في صفوف `repos-1-day`، بينما ترد حقول القياس عن بُعد والإصدارات في تقارير المستخدمين لفترتي يوم واحد و28 يومًا. وهذا يجعل التحديث مفيدًا خصوصًا للمؤسسات التي تدير Copilot مركزيًا بالفعل: إذ أصبح بإمكانها فحص ليس فقط استخدام المساعد، بل أيضًا الاستجابة لمراجعته وأسباب نقص القياسات.
