هذا المنشور تم تأليفه مع خالد ثابت، ومريم بوغرارا، ومحمد ديسوكي من قسم Property Finder.
فريق الهندسة في Property Finder، تطبيق العقارات الرقمي، اكتشف أن 96.8% من علامات التقييم الخاصة بهم قد تمت الاستفادة منها مباشرة من تنبؤات نموذج واحد، بدلاً من التحقق منها من قبل خبراء بشريين. كانت الحقيقة الأرضية متحيزة بشكل منهجي نحو النموذج الحالي، مما جعل كل الخيارات البديلة تبدو أقل أداءً. كانت العلامات أيضًا تحتوي على أخطاء، لكن التحيز هو ما حال دون مقارنة النماذج الموضوعية. اكتشف الفريق هذا الأمر عند نقل عبء عمل الذكاء الاصطناعي الخاص بهم إلى خيار أكثر كفاءة من حيث التكلفة على Amazon Bedrock.
يقوم برنامج Property Finder بتحليل عشرات الآلاف من صور العقارات يوميًا في الشرق الأوسط وشمال أفريقيا (MENA). يقوم نظامه بتقييم 11 خاصية جودة لكل صورة، وتشمل هذه الخصائص اكتشاف العلامات المائية، تصنيف الغرف، حالة الأثاث، جودة الصور، وعلامات البناء. وهذا يعني آلاف إعلانات عقارات جديدة، حيث يكون متوسط كل إعلان 15 صورة. جميع الإعلانات تحتاج إلى تقييم جودتها قبل أن تُنشر.
كان من الضروري لبرنامج Property Finder خيار أكثر كفاءة من حيث التكلفة. لكن بالنظر إلى تلك العلامات، كان أي بديل في وضع غير مواتٍ.
كان الجزء الأصعب هو عدم إيجاد نموذج أفضل. كان الأمر يتعلق باكتشاف أن منهجية التقييم الخاصة بهم هي العائق الحقيقي.
في هذه المقالة، نشارك كيف حدد برنامج Property Finder التحيز في التقييم، وخلق حقيقة أساسية غير متحيزة، وطبق تحسين التحفيز التطوري لاختيار النموذج المناسب على Amazon Bedrock، مما أدى إلى دقة أعلى بتكلفة أقل بنسبة 86%. نشرح منهجية العملية وأمثلة التكرار، مع دروس يمكنك تطبيقها على عملك الخاص.
يوضح الرسم البياني التالي حلقة تحسين الطلب التي استخدمها برنامج Property Finder وفريق مركز AWS Generative AI Innovation Center لتحسين دقة التصنيف بشكل تكراري على Amazon Bedrock.
الشكل 1: بنية حلقة تحسين الطلب
يعرض الرسم البياني دورة تحسين التحفيز التكراري. يتم معالجة صورة الخصائص بواسطة Amazon Bedrock، الذي ينتج الصفات المتوقعة في صيغة JSON. أثناء التحسين، تُعادل هذه التنبؤات بمقياس Micro F1 مقابل مجموعة التطوير المُشرحها الخبراء من صور 256 صورة. بعد ذلك، تقوم تحليل الأخطاء بفحص الصور التي فشلت وتمييز الأنماط البصرية، مما يساعد على تحديد الإصدار التالي للتحفيز. تم تنفيذ الدورة من v0 إلى v27. ساعدت مساعدات الذكاء الاصطناعي في تحسين الطلبات، واستخدمت النسخ الأخيرة التحسين الآلي.
قد تكون تقييماتك مزيفة
يواجه العديد من الفرق هذا السيناريو. إذا كنت تريد مقارنة نماذج الرؤية، فعليك بناء مجموعة بيانات تقييم. الطريقة الأكثر شيوعًا للحصول على التصنيفات هي تشغيل النموذج الحالي وتعتبر نتائجه كحقيقة أساسية. النموذج يعمل في الإنتاج ولم يشتكِ أحد، لذا يجب أن تكون التصنيفات جيدة بما فيه الكفاية.
لكن هذا يخلق تقييمًا دائريًا، حيث يتم تقييم أي بديل بناءً على مدى تطابقه مع سلوك الشخص الحالي، وليس بناءً على صحة البديل الفعلية.
كانت مجموعة بيانات تقييم برنامج “Property Finder” تعاني من هذه المشكلة بالضبط. من العينات المصنفة لديهم، جاء 96.8% مباشرة من توقعات نموذج اللغة البصرية الحالي (VLM)، وليس من التحقق البشري المستقل. أي نموذج بديل كان ضعيفًا من الناحية الهيكلية قبل حتى معالجة الصورة الواحدة.
تم تأكيد خطأ مخفي، مما يدل على شدة المشكلة. تم تحديد أخطاء على مستوى الأحرف في استخراج نص العلامة المائية، بما في ذلك أسماء العلامات التجارية المختلقة والحروف المفقودة. تم تعميم التصنيف الفوتوغرافي على الصور التي تحتوي على أنواع متعددة من الغرف.
في الـ 3.2% المتبقية من العينات المُميَّزة بواسطة البشر، قام المُعلِّمون بإضافة فئات خارج المواصفات الأصلية، مثل ظهور Office حيث لا يوجد مثل هذا التمييز في التعليمات. تفقد مقارنة النماذج صلاحيتها عندما تم كتابة مفتاح الإجابات من قبل النموذج الذي تحاول استبداله.
بناء الحقيقة الأرضية التي يمكنك الوثوق بها
لكسر الدورة، يجب أن يكون هناك خبراء بشرية ذوو معرفة حقيقية في المجال، يقومون بتدوين التحليلات بشكل مستقل. لا يوجد إشارة إلى نتائج النماذج السابقة. ولا يوجد إمكانية الوصول إلى ما توقعه النماذج الحالية.
نطاق مجموعة البيانات
قام فريق برنامج "Property Finder" بتدوين ملاحظات يدوية على 356 صورة من الإمارات العربية المتحدة وملفة منفصلة من صور مصر. اختار الفريق هذه الصور من قوائم الإنتاج غير الموسومة في قطاعات صناعية مختلفة. تقدم هذه المنشور نتائج المتابعة الخاصة بالصور من الإمارات العربية المتحدة. أما صور مصر فقد استُخدمت كفحص عابر للمناطق على 230 صورة، ولم يتم الإبلاغ عنها هنا. تشكل الصور الأولى الـ 256 من الإمارات العربية المتحدة التي تم تدوينها الملاحظات أصل مجموعة التطوير للتعديل. تم استخدام مجموعة التقييم لمقارنة النموذج النهائي التي تتكون من 356 صورة كاملة، بالإضافة إلى 100 صورة تم تدوينها بعد عملية التطوير. تكفي مجموعة 356 صورة تقريبًا للكشف عن الاختلافات المعتدلة بين النماذج. أما الفئات النادرة داخل الخصائص الفردية، فهي تحتوي على عدد أقل من الأمثلة، لذا قد لا تكون الاختلافات الصغيرة في هذه الخصائص قابلة للكشف.
تحليل الخبير
قام خبير الاستراتيجيات والتحليلات بتصحيح جميع الصور. وقد امتلكوا معرفة متخصصة بمعايير جودة عروض العقارات. وقام فريق مركز الابتكار الرقمي التوليدي لـ AWS بإجراء مراجعات جودية منهجية من خلال جلسات توضيحية متخصصة. وقد ساعدت هذه المراجعات في حل القضايا الغامضة والحفاظ على اتساق التصنيف في مجموعة البيانات.
انتقال العلامات المتعددة
تُظهر صور العقارات غالبًا غرفًا متعددة من خلال مداخل الأبواب أو تُعرض خصائص الجودة المتداخلة. وقد ساعد التحول من التصنيف بالعلامة الواحدة إلى التصنيف بالعلامات المتعددة في التخفيف من مصدر كبير للغموض الاصطناعي.
صورة في الرواق تُظهر غرفة نوم من خلال باب، وهذا حقًا كلا الأمرين معًا. بعد السماح بعدة تعليمات، يتم قياس ما يقوم النموذج بتصحيحه بدلًا من معاقبته على التنبؤات الثانوية المعقولة.
قد يساعد النهج الهجين على تكميل هذه المنهجية: فالنماذج من عائلات مختلفة تكشف عن التسميات المحتملة والخلافات، ويقوم الخبراء البشريون بحكم كل حالة، بحيث لا يتم استخدام نتائج النماذج مباشرة كتسمية. هذا سيقلل من عبء التدوين لاحقًا عند توسيع مجموعة البيانات.
اختيار المقاييس
تم استخدام مقياس F1 الصغير كمعيار رئيسي، لأنه يعطي وزنًا متساويًا لكل توقع، وهو ما يتوافق مع هدف العمل في دقة التصنيف الإجمالي. تم الإبلاغ عن مقياس F1 الكبير بجانبه، لأن مقياس F1 الصغير يهيمن عليه الفئات المتكررة ويمكن أن يخفي الأداء الضعيف في الخصائص النادرة. ساعدت دقة التصنيف لكل نتيجة وتراكب الاسترجاع في تحديد طرق الفشل المحددة. قياس التقاطع بين العينة والاتحاد (IoU) يقيس مدى التقارب بين التصنيفات المتوقعة لكل صورة والتصنيفات التي أخطأها الخبراء. الخصائص التسعة ذات العلامة الواحدة، مثل الدوران أو اكتشاف العلامات المائية، لها إجابة صحيحة واحدة لكل صورة. كما حققت فريق AWS دقة مطابقة دقيقة، وهي نسبة الصور التي تتطابق فيها الإجابة مع العلامة الخبيرة.
تحسين التحفيز كتعلم تعزيز
مع تقييم غير متحيز، يمكنك البدء في التحسين. لا يمكنك التحسين ما لا يمكن قياسه بشكل صحيح.
يتبع التحسين عملية دورة مماثلة للتعلم الإضافي. يمكن اعتبار كل نسخة من الطلب كعامل، والنقاط الصغيرة F1 كإشارة مكافأة، وتحليل الخطأ كتدرج لتحسين الأداء. تشبه الفكرة GEPA (تطور الطلبات البيولوجية-الباريتوية الانعكاسية)، حيث يتم تغيير مكونات الطلب، وتقييم الكفاءة، واختيار الناجين، والتكرار. في هذا الإجراء، قام فريق AWS بتحسين معظم النسخ من خلال تحليل الخطأ، حيث يقوم المساعدون الذكيون بمراجعة الصور الفاشلة ويقترحون التغييرات.
MIPROv2، إطار عمل لتحسين التوجيه الآلي من مكتبة DSPy، وقد دعم هذه العملية اليدوية لمهمة تصنيف الصور في الإصدار v27.
المكان الذي بدأ منه
الدليل الأول (v0) استخدم تعليمات تصنيف عامة، تم تبسيطها هنا للتوضيح:
قم بتصنيف هذه الصورة ضمن أحد الفئات التالية: غرفة المعيشة، المطبخ، غرفة النوم، الحمام…
النموذج المملوك من نوع A، وهو الأساس الإنتاجي لبرنامج Property Finder، حصل على درجة Micro F1 تبلغ 0.55 في مجموعة التطوير المكونة من 256 صورة. استخدم النموذج الإصدار v22، وهو تلقيم مُعد خصيصًا لعائلة النماذج الخاصة به. الدرجات قبل الإصدار v21 استخدمت إعداد العلامة الواحدة السابق، ولا يمكن مقارنتها مباشرة.
بإجراء تكرار تلو الآخر
اختبر فريق AWS النسخ الأولية من عدة نماذج مرشحة، وأضاف تنسيق الإخراج المنظم وتعريفات الخصائص المحددة.
أفضل حل تعليمي جاء من تحليل الأخطاء على مستوى الصور. في النسخة المبكرة ذات العلامة الواحدة، صنف النموذج باستمرار الغرف المرئية من خلال الأبواب كنوع غرف ثانوي. أضاف فريق مركز الابتكار في الذكاء الاصطناعي التوليدي من AWS تعليمات صريحة لتصنيفها بناءً على الغرفة التي تشغل الجزء الأكبر من الإطار. ثم تغير النهج إلى الإخراج متعدد العلامات، حيث ظل الغرفة الرئيسية علامة واحدة، وتم السماح للغرف المرئية من خلال الأبواب كعلامات إضافية.
تحقيق تحسين إضافي ناتج عن التخصيص الإقليمي. في بعض المناطق، تحتوي قوائم الصور على توضيحات عربية زخرفية لا تُعتبر علامات واماكن. وقد أدت قواعد هذه النصوص إلى إزالة فئة كاملة من النتائج الخاطئة.
تم تحويل تصنيف الصور وتصنيف الغرفة إلى ناتج متعدد التسميات في نموذج v21، وأصبح كذلك النموذج الابتدائي المشترك لكل النماذج. وبهذا، حقق تعليمات Llama 4 Maverick 17B من Meta نتيجة Micro F1 قدرها 0.75 على مجموعة التطوير. ومن هنا، قام فريق AWS بتعديل نموذج كل نموذج بشكل منفصل. بالنسبة لهذا النموذج، ركز v24 على تقدير حجم الغرفة بشكل مبالغ فيه، والتعامل مع التسميات المتعددة، وشكل الناتج. ثم جاء v25، وهو نسخة محسنة تلقائيًا، حيث تم التركيز أولاً على المهام الحاسمة. وفي v27، قام MIPROv2 بإعادة تنظيم مهمة تصنيف الصور، ووصلت نتيجة Micro F1 للنموذج في هذه المهمة إلى 0.76.
أين انتهى
التعليمات النهائية، v27_PF، هي v27 مع القواعد التي أضافها Property Finder للعرضات، والصور ذات الحواف أو الإطارات، والممرات. كما في v27، فإنها تحتفظ بالقواعد الخاصة بالنص العربي وقواعد تنسيق الإخراج. يتم التعامل مع الاختلافات المتبقية في التنسيق بعد كل استدعاء للنموذج بخطوة توحيد.
مع v27_PF، حقق لاما 4 مايفريك 17B إنستركت 0.80 في نتيجة Micro F1 على مجموعة التقييم المكونة من 356 صورة، بينما حقق النموذج الخاص A نتيجة 0.56 مع v22. تشمل مجموعة التقييم الصور التطورية الـ 256، وتم تعديل طلبات النموذجين على هذه الصور. لذلك، فإن هذه النتائج متفائلة.
التحول من النموذج المملوك A إلى Llama 4 Maverick 17B Instruct، كل منهما بصيغة تحفيز منفصلة، رفع معدل Micro F1 من 0.55 إلى 0.81 على مجموعة التطوير. وهذا يعادل زيادة نسبية بنسبة 47 بالمئة. وحدها تعديل الصيغ التحفيزية، على نظام Llama 4 Maverick 17B Instruct، رفعها من 0.75 باستخدام صيغة v21 المشتركة إلى 0.81 باستخدام v27.
دروس من النهج الفاشلة
لم ينجح كل شيء. طريقة 2-bucket جعلت خصائص العلامة المائية وخصائص أخرى في دفعتين من استدعاءات API منفصلتين، مما لم تجلب معه أي تحسين ذو معنى في الدقة. كما انخفضت تشخيص الصور المغلفة بشكل حاد. بدون خصائص العلامة المائية في نفس الاستدعاء، اعتقدت النماذج أن طبقات العلامة المائية هي حدود الصورة.
فشلت التعليمات العامة أيضًا بغض النظر عن النموذج الذي تم تشغيلها عليه. تحتوي صور العقارات على الكثير من الخصائص المحددة لكل مجال، مما يجعل التعليمات التي تناسب الجميع غير مناسبة.
النتائج: التكلفة، الدقة، والسرعة
قام فريق مركز الابتكار في الذكاء الاصطناعي التوليدي من AWS بتقييم عدة نماذج على Amazon Bedrock باستخدام إطار التقييم غير المتحيز. بدأت جميع النماذج من التعليمات v21 المشتركة، ثم تم تعديلها لفئة النماذج الخاصة بها على مجموعة التطوير. النموذج المملوك أُجري عليه جولة تعديل واحدة، v22. نموذج Llama 4 Maverick 17B Instruct أُجري عليه عدة جولات من التعديل، v24 إلى v27، بالإضافة إلى قواعد الحالات الحرجة لبرنامج Property Finder، مما جعله يحتاج إلى المزيد من الجهد في التعديل. تم إجراء المقارنة النهائية بين النموذج المملوك A وذلك باستخدام مجموعة التقييم المكونة من 356 صورة. اختار برنامج Property Finder نموذج Llama 4 Maverick 17B Instruct للعملية الإنتاجية بناءً على دقة جميع الصفات الـ11 وكفاءة التكلفة. للحصول على معلومات حول توافر النماذج حسب المنطقة، يُرجى الرجوع إلى النماذج المدعومة حسب منطقة AWS في Amazon Bedrock.
تُظهر الجدول التالي دقة المطابقة الدقيقة التي حققها Llama 4 Maverick 17B Instruct (v27_PF) على كل خاصية بسمة، وذلك في مجموعة تقييم الأصور التي تحتوي على 356 صورة. حصل على نسبة 90% أو أكثر في ستة من التسعة خصائص، وتجاوز النموذج المملوكي A في جميع الخصائص الـ11. في تصنيف الصور، التي يمكن أن تحتوي على عدة بطاقات لكل صورة، حقق الطرفان نفس النتيجة.
| الخاصية | دقة المطابقة الدقيقة |
| كشف الدوران | 100% |
| كشف الأشخاص | 97% |
| كشف الصور المغلفة | 97% |
| كشف التصميم المائي | 94% |
| إنتاج الكشف | 93% |
| حالة التجهيز | 91% |
| الغرفة قيد البناء | 81% |
| حجم الغرفة | 65% |
| استخراج نص العلامة المائية | 55% |
تكلفة كل 1000 صورة
يحسب برنامج Property Finder عشرات الآلاف من الصور يوميًا، لذا فإن تكلفة كل صورة مهمة. لاما 4 Maverick 17B Instruct هو نموذج ذو وزن مفتوح واقتصادي من حيث التكلفة، ويحتوي الماسح الضوئي على جميع الخصائص المتعلقة بالصورة في مرة واحدة.
| النتيجة | القيمة |
| تكلفة التقدير لكل 1000 صورة | $2.35 |
| تقليل التكلفة مقارنةً بالإعداد السابق لبرنامج Property Finder | 86% |
هذه الأرقام هي تقديرات حتى ديسمبر 2025 في منطقة شرق الولايات المتحدة (أوهايو). يفترض رقم Llama 4 Maverick 17B Instruct استخدام 9,000 كلمة إدخال و200 كلمة إخراج لكل صورة، استنادًا إلى تحليل تكلفة الاتصال الثنائي الأصلية. الاتصال الواحد مع التعليمات الإنتاجية يحتوي على حوالي 7,500–8,000 كلمة إدخال، لذا هذه هي تقديرات أعلى. يقارن 86 بالمئة بتقدير تحليل التكلفة للإعداد السابق لبرنامج Property Finder الذي استخدم التعليمات v21. تم استخدام v22 في مقارنة الدقة، والذي تم تعديله من v21، لذا قد يختلف تكلفته. للحصول على الأسعار الحالية، راجع أسعار Amazon Bedrock.
سرعة الاستدلال
تقوم برنامج Property Finder بتشغيل هذه العملية المُحسّنة في البيئة الإنتاجية، حيث تقوم بمعالجة عشرات الآلاف من الصور يوميًا باستخدام Llama 4 Maverick 17B Instruct على Amazon Bedrock. ومن خلال مراقبتها الخاصة، لاحظ برنامج Property Finder انخفاضًا بنسبة 40-60 بالمئة في زمن الانتظار مقارنة بالإعداد السابق.
طبق هذا على أعمالك
ابدأ بفحص علامات التقييم الخاصة بك. إذا كانت هذه العلامات ناتجة عن توقعات النموذج وليس من خبراء بشر، فإنك تواجه نفس مشكلة التحيز التي اكتشفها برنامج Property Finder.
بناء الحقيقة الأساسية الخاصة بمتخصصي النطاقات لعدة مئات من العينات الممثلة، والحفاظ على تقطيع اختبار منفصل لا يتم استخدامه أبدًا للتعديل. اعتماد مقاييس متعددة التسميات حيث تتضمن مهمة التصنيف خصائص متداخلة. ثم التكرار على التعليمات باستخدام تحليل الأخطاء في الصور، مع اعتبار كل تكرار كإنتاج في حلقة التحسين التطوري.
عند تطبيق خطوة إنتاج مثل هذه، أضف ضوابط ذكاء اصطناعي مسؤولة. على سبيل المثال، يمكنك استخدام Amazon Bedrock Guardrails لتنفيذ سياسات المحتوى وتصفية النتائج غير المناسبة للنموذج. تنبؤات الخاصية في هذه الخطوة لا تأتي مع نقاط ثقة معدلة، لذا استخدم إشارة عملية لاختيار الصور لمراجعة بشرية. عدم اتفاق النموذجين هو إشارة من هذا النوع. عندما يعطيان النموذجان إجابات مختلفة لمعيار معين، فإن الصورة غالبًا ما تكون غير واضحة. يضيف وجود نموذج ثاني على كل صورة تكلفة، لذا يمكنك البدء بعينة. تحقق من مدى تكرار اكتشاف الإشارة للأخطاء الحقيقية في مجموعة التطوير الخاصة بك قبل الاعتماد عليها.
الخلاصة
في هذا المنشور، شرحنا كيف حدد برنامج Property Finder التحيز في التقييم، وأسس حقيقة أساسية خالية من التحيز، وطبق تحسين الإعدادات التطورية لتحقيق دقة أفضل بتكلفة أقل من خلال اختيار النموذج على Amazon Bedrock.
ثلاثة عناصر ضرورية للتجمع معًا لتحقيق هذا النتيجة: تقييم غير متحيز لقياس الأمور بصدق، المرونة في التقييم وتغيير بين أسراب الأنظمة دون الحاجة إلى إعادة تنصيب، والإعدادات المطورة بعناية مُصممة خصيصًا للمجال. قدمت Amazon Bedrock الأساس. منحت هذه التطبيقات القدرة على الوصول إلى عدة عائلات من الأنواع، من خلال واجهة برمجة تطبيقات واحدة، كما تمت الاستفادة من ضوابط الحوكمة والأمان في AWS، بالإضافة إلى القدرة على تبني أنواع جديدة بمجرد إتاحتها دون الحاجة إلى تغيير البنية التحتية.
لبدء تقييم واختيار النماذج على Amazon Bedrock، يرجى زيارة وثائق Amazon Bedrock. إذا كنت تعمل على أعمال العملية للرؤية وترغب في الحصول على مساعدة في بناء إطار تقييم غير متحيز، يرجى الاتصال بالـ مركز AWS للتكنولوجيا الذكية التوليدية.
شارك تجاربك في تقييم النموذج وتحسين التعليمات في التعليقات.
شكر وتقدير
تشمل المشاركين الإضافيين من AWS يوسف ألباناي، أمين سهيلي، توماس أوناس، أريس تساكبينيس، رافيك سوليمان، نخيل أولهاس بانديت، وسني شارما.