بعد تحقيق شامل، توصلتُ إلى أن ما بدا وكأنه مشكلة ترجمة واحدة هو في الواقع ثلاث مشكلات منفصلة تحدث في وقت واحد، مما خلق ارتباكًا كبيرًا.
شكرًا خاصًا لريتشارد من Communiteq على تواصله وكفاءته، وخاصةً على اقتراحه نهج مستكشف البيانات (Data Explorer) — فقد كان من خلال استعلامات SQL أن تمكنت أخيرًا من تحديد جميع المشكلات الثلاث. تقدير كبير.
المشكلة الأولى: اكتشاف خاطئ للغة بواسطة نموذج الذكاء الاصطناعي (LLM)
النموذج المستخدم لاكتشاف اللغة يصنّف بشكل خاطئ المنشورات المكتوبة باللغة الإنجليزية ولكن تحتوي على أسماء أماكن باللغة البرتغالية.
مثال: المنشور بعنوان “افتتاح معرض WA لفنان هانامارو تشاكي في حصن ساو جواو دو بيكو” مكتوب بالكامل باللغة الإنجليزية. ومع ذلك، صنّف كاشف اللغة المنشور على أنه pt-BR — على الأرجح بسبب الأسماء البرتغالية للأماكن في النص (“حصن ساو جواو دو بيكو”، “دار ثقافة سانتا كروز”).
النتيجة: لأن النظام اعتقد أن المنشور مكتوب بالفعل باللغة البرتغالية، لم يقم بترجمته إلى البرتغالية. بدلاً من ذلك، قام بترجمته إلى الإنجليزية — معتبرًا الإنجليزية اللغة “المفقودة”.
هذه المشكلة خطيرة بشكل خاص في المجتمعات متعددة اللغات حيث تشير المنشورات في لغة ما بشكل متكرر إلى أسماء أماكن أو أسماء علمية بلغة أخرى.
الحل المقترح: استخدام نموذج أكثر قدرة لاكتشاف اللغة (مثل Mistral Large)، والذي يفهم السياق بشكل أفضل ويميز بين لغة النص الأساسي والأسماء العلمية المضمنة فيه.
المشكلة الثانية: أخطاء 503 من واجهة برمجة تطبيقات Mistral تسبب في انهيار مهام الدُفعات في منتصف التنفيذ
تقوم واجهة برمجة تطبيقات Mistral بإرجاع أخطاء 503 unreachable_backend بشكل متقطع. بينما يعيد ملء البيانات (backfill) محاولة بعض هذه الأخطاء في النهاية، فإن مهمة Jobs::LocalizeTopics تنهار أثناء التنفيذ عند مواجهة خطأ 503 — مما يترك الموضوعات المتبقية في الدفعة دون ترجمة حتى تشغيل الجدولة التالي.
يخلق هذا نمطًا غير متوقع من الترجمات المفقودة للغات عشوائية عبر موضوعات عشوائية.
أدلة من السجلات:
DiscourseAi::Translation: Translated 13 topics to de
[crash in localize_topics.rb:57]
قامت المهمة بترجمة 13 موضوعًا، ثم انهارت. لم تتلقَ الموضوعات المتبقية أي ترجمة إلى الألمانية حتى دورة إعادة الملء التالية.
المشكلة الثالثة: فئات الهدف للترجمة بالذكاء الاصطناعي — ملء تلقائي غير متسق للفئات الفرعية
في حالتي، لم أقم أبدًا بإضافة أي فئات يدويًا إلى إعداد “فئات الهدف للترجمة بالذكاء الاصطناعي” — بدت وكأنها تمت إضافتها تلقائيًا. ومع ذلك، لم تتم إضافة فئتين فرعيتين (Viewpoints و Beaches) تلقائيًا، على الرغم من وجودهما واحتوائهما على محتوى.
فرضيتي: يقوم النظام بإضافة فئة فرعية تلقائيًا إلى قائمة الهدف فقط عند إنشاء منشور جديد فيها بعد تمكين الترجمة. نظرًا لأن فئتي Viewpoints و Beaches تم تعبئتهما قبل تشغيل الترجمة، لم تتم إضافتهما تلقائيًا — وبالتالي لم تتم ترجمتهما.
هذا سلوك محير. إذا كانت منطقية الملء التلقائي موجودة، فيجب أن تكون متسقة وتُطبق على البيانات السابقة (retroactive)، أو يجب أن تجعل واجهة المستخدم الأمر أكثر وضوحًا بأن الفئات الفرعية تحتاج إلى إضافة يدوية.
ملخص
حدثت جميع المشكلات الثلاث في وقت واحد، مما جعل التشخيص صعبًا للغاية. قد يكون منشور ما غير مترجم بسبب اكتشاف خاطئ للغة، أو انهيار بسبب خطأ 503، أو ببساطة لأن فئته كانت مفقودة من قائمة الهدف — ولم يكن هناك أي طريقة للتمييز بين هذه الحالات دون تحليل عميق للسجلات واستعلامات SQL.
كان استعلام مستكشف البيانات الذي اقترحه ريتشارد هو المفتاح الذي فتح باب التحقيق. أتمنى أن يكون هذا التفصيل المفصل مفيدًا للفريق. مستعد لتقديم سجلات أو أمثلة إضافية إذا لزم الأمر.
شكرًا للفريق على نشاطهم في هذا الموضوع!
