ReviewScope يبحث عن الحالات الشاذة في التقييمات عبر التمثيلات المتجهية والرسوم البيانية على 21 ألف نص

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

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

البنية والبيانات

وكانت النتيجة أداة ReviewScope — أداة مفتوحة المصدر لتحليل التقييمات، والبحث عن الحالات الشاذة والنصوص المتكررة، واستكشاف سجل أصحاب التقييمات. الرابط على GitHub: https://github.com/zinverno/reviewscope، والنسخة التجريبية: https://reviewscope-demo.streamlit.app/.

لا تقوم الأداة بجمع التقييمات تلقائيًا من خرائط Yandex. فالتحليل يتطلب ملفًا جاهزًا بصيغة CSV أو JSON. يقوم التطبيق بتوحيد البيانات وتخزينها في DuckDB — وكل ذلك يعمل محليًا دون حاجة إلى خادم مستقل. يتضمن التقييم الواحد الحقول التالية: review_id، place_id، place_name، place_category، reviewer_id، reviewer_name، rating، text، published_at، city، region، country، latitude، longitude. وليست جميع الحقول إلزامية. تعرض واجهة Streamlit علامة N/A عند نقص البيانات.

مسار المعالجة هو: CSV/JSON ← التوحيد ← DuckDB ← محرك التحليل (AnalysisEngine) ← واجهة Streamlit. ويتضمن محرك التحليل أربع وحدات.

أربع طبقات لتحليل الحالات الشاذة

رصد الطفرات (burst detection). يتلقى المخبز عادة تقييمًا أو تقييمين في الأسبوع. فإذا وصل 30 تقييمًا في يوم واحد، وكانت أغلبها خمس نجوم، فهذا أمر غريب. لكن بالنسبة لمطعم يستقبل أصلًا 50 تقييمًا يوميًا، فإن نفس الثلاثين تقييمًا لا يعني شيئًا. والحل هو: الوسيط المتحرك + MAD (الانحراف المطلق الوسيط). ويقيس MAD مدى تباعد القيم المعتادة عن القيمة النموذجية. فتأثير يوم واحد متطرف على هذا المقياس يكون ضعيفًا جدًا، على عكس المتوسط والانحراف المعياري اللذين ينزلقان بسهولة بسبب القيم الشاذة. وقد حُدِّد عتبة z-score المعدّل عند 3.5، ونافذة البيانات التاريخية عند 30 يومًا.

حالات شاذة في تحولات التقييم (rating shift). عُثر على يوم فيه عدد تقييمات غير معتاد. فهل كانت كلها خمس نجوم؟ أم كانت نجمة واحدة؟ للإجابة على ذلك، أضاف التطبيق تباعد جنسن-شانون (Jensen-Shannon divergence)، وهو وسيلة لقياس الفرق بين توزيعين احتماليين. تتم مقارنة نسب التقييمات من نجمة واحدة إلى خمس نجوم خلال الفترة التاريخية ومحيط الحادثة. وتكشف الخوارزمية الطفرات الإيجابية والسلبية على حدٍّ سواء.

رصد التكرارات — عبر أربعة مستويات من التطابق: Exact (نصوص موحّدة متطابقة تمامًا)، Fuzzy (تشابه لفظي قريب عبر RapidFuzz)، Near (تشابه لفظي قوي عبر MinHash/LSH)، Semantic (تشابه في المعنى عبر التمثيلات المتجهية). بدت المستويات الثلاثة الأولى كافية، لكن إذا أعاد صاحب التقييم صياغة الجملة بالكامل، تفشل الطرق اللفظية. وقد حلّت التمثيلات المتجهية هذه المسألة.

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

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