سجل تصحيح أخطاء عدم دعم نموذج OpenRouter gpt-oss-120b لطلبات اللغة الصينية

عند استخدام واجهة برمجة تطبيقات النماذج المجانية التي تقدمها OpenRouter، واجهت مشكلة محيرة. نفس هيكل الطلب، فقط بتعديل لغة الموجه (Prompt)، سيؤدي إلى نتائج مختلفة تمامًا.

إعادة إنتاج المشكلة

استخدمت النموذج openai/gpt-oss-120b:free للاختبار، والفرق الوحيد بين الطلبين هو لغة الموجه. الطلب الأول يستخدم موجهًا باللغة الصينية:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-or-v1-xxxxxxxxxxxxxxxxxxxxxx" \
  -d '{
  "model": "openai/gpt-oss-120b:free",
  "messages": [
    {
      "role": "user",
      "content": "你是一个专业的本地化翻译专家"
    }
  ]
}'

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

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-or-v1-xxxxxxxxxxxxxxxxxxxxxx" \
  -d '{
  "model": "openai/gpt-oss-120b:free",
  "messages": [
    {
      "role": "user",
      "content": "You are a professional localization translation expert"
    }
  ]
}'

الطلب يستجيب بشكل طبيعي ويعيد مخرجات النموذج المتوقعة.

عملية تصحيح الأخطاء

هذا السلوك غير المتسق مربك. عادةً ما يعني خطأ 429 حدًا للسرعة (Rate Limit)، لكن المشكلة تكمن في أن الطلبين أُرسلا في وقت متقارب تقريبًا، لذا لا يجب أن تكون هناك مشكلة في حد السرعة. لذا بدأت في التحقيق بشكل منهجي في الأسباب المحتملة.

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

عند طلب المساعدة من نماذج ذكاء اصطناعي أقوى، استشرت Opus 4.6 Max و GPT-5.2 Extra High. وعلى الرغم من كونها من أحدث نماذج اللغة المتاحة، إلا أنها فشلت في تحديد السبب الجذري لهذا الخلل (bug) بوضوح. يشير هذا إلى أن بعض الحالات الحدية أو القيود الخاصة قد لا تكتشف إلا من خلال الاختبار الفعلي.

التحقق اليدوي

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

تشير هذه الظاهرة إلى استنتاج واضح: النموذج openai/gpt-oss-120b:free لا يدعم الطلبات الصينية. قد يؤدي معالجة النموذج للمحتوى الصيني إلى تشغيل آلية قيود غير موثقة، مما يؤدي إلى إرجاع واجهة برمجة التطبيقات (API) لخطأ 429 مباشرة بدلاً من رسالة خطأ أكثر ودية.

ملخص الخبرة

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

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

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

أدوات ذات صلة

عند التعامل مع ترجمة المحتوى متعدد اللغات، قمت بتطوير ملحق VS Code Project Translator، المخصص لمسار العمل (workflow) للتوطين متعدد اللغات للمشاريع. يمكنه تحديد الملفات التي تحتاج إلى ترجمة تلقائيًا، ودمج خدمات ترجمة متعددة، والحفاظ على اتساق سياق الترجمة.

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

خاتمة

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

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

• ←السابق
• التالي→