Architecture
LLMs in production for Arabic-first products
{"ar": "تتعامل النماذج الحدوديّة مع العربيّة جيّداً الآن — جيّداً بما يكفي للإطلاق. لكنّ ذلك لا يعني أنّ ميزة LLM عربيّة نسخةٌ من الإنجليزيّة. التشكيل، واللهجة، والتواريخ الهجريّة تُغيّر ما تعنيه كلمة "جيّد".", "en": "The frontier models handle Arabic well now — well enough to ship. That does not mean an Arabic-first LLM feature is a copy-paste of the English one. Diacritics, dialect, and Hijri dates all change what \"good\" looks like."}
{"ar": "<p>قبل عامَين، كان إطلاقُ ميزة LLM بالعربيّة يعني الاعتذار للمستخدم عن الاستجابة التي تصل أحياناً بلهجةٍ خاطئة، أو بلغةٍ خاطئةٍ بالكامل. اليوم، على النماذج الحدوديّة، هذا الصنف من المشكلات قريبٌ من الحلّ. الصنف التالي أهدأ.</p><h2>التشكيل والمطابقة</h2><p>تفشل طبقات البحث والمطابقة العربيّة بانتظامٍ عند عدم تطابق التشكيل. يكتب المستخدم محمد، وقاعدة البيانات فيها مُحَمَّد، وتُعامِلهما الطبقةُ الدلاليّة بوصفهما متطابقَين، بينما لا تفعل طبقةُ SQL. لفّ دوالّ المطابقة بمُطبِّعٍ، أو سيُشير الـLLM بثقةٍ إلى سجلٍّ لا يستطيع بقيّة النظام إيجاده.</p><h2>اللهجات مقابل الفصحى</h2><p>يكتب المستخدمون بلهجاتهم. مطالباتك، والمحتوى المستدعى، والإجابات المُوَلَّدة، تعيش بالفصحى. الجسر بين الاثنَين سطحٌ هندسيٌّ حقيقيّ، لا تعديلٌ في المطالبة. لأغلب المنتجات، طبِّع مدخل المستخدم إلى الفصحى وقت الاستعلام، وولِّد الإجابة بالفصحى. حيث تستطيع، ولِّد باللهجة التي كتب بها المستخدم — لكن ادفع تكلفة التقييم.</p><h2>التواريخ والألقاب والسِجِلّ الاجتماعيّ</h2><p>نموذجٌ يُولِّد "مرحبا" لعميلٍ مؤسّسيٍّ صحيحٌ في الحقائق وخاطئٌ بالكامل. يهمّ السِجِلّ في العربيّة أكثر ممّا تتوقّعه فرق المنتج في البداية. اجعله جزءاً من مطالبة النظام، وقيّم انحراف السِجِلّ كما تقيّم انحراف الحقائق.</p>\n<p>يجب أن تكون التواريخ الهجريّة عنصراً من الدرجة الأولى في المطالبة إن كان مستخدموك يعملون بها. لا تعتمد على النموذج في التحويل؛ زوّده بالاثنَين.</p><h2>والجزءُ الصادق</h2><p>كلٌّ ممّا سبق قرارٌ، لا إعداد. تعيش ميزاتُ LLM في المنتجات العربيّة أو تموت بحسب كم من هذه القرارات مستعدٌّ الفريقُ لاتّخاذها صراحةً — وكم يتركها للنموذج بالمصادفة.</p>", "en": "<p>Two years ago, shipping an Arabic LLM feature meant explaining to the user why the response would occasionally arrive in the wrong dialect or the wrong language altogether. Today, on the frontier models, that class of problem is close to solved. The next class of problems is quieter.</p><h2>Diacritics and matching</h2><p>Arabic search and matching layers regularly fail on diacritic mismatches. A user types محمد, the database has مُحَمَّد, and the semantic layer treats them as identical while the SQL layer does not. Wrap your matching functions in a normaliser or the LLM confidently references a record the rest of the system cannot find.</p><h2>Dialects vs. Modern Standard Arabic</h2><p>Users type in dialect. Your prompts, retrieved content, and generated responses live in MSA. Bridging the two is a real engineering surface, not a prompt tweak. For most products, normalise user input to MSA at query time, and generate output in MSA. Where you can afford it, generate in the dialect the user typed in — but budget for the eval cost.</p><h2>Dates, honorifics, and social register</h2><p>A model that generates "مرحبا" to a corporate customer is factually correct and completely wrong. Register matters more in Arabic than most product teams appreciate at first. Bake it into your system prompt, and evaluate for register drift the same way you would evaluate for factuality.</p>\n<p>Hijri dates need to be a first-class citizen in the prompt if your users work in Hijri. Do not rely on the model to convert; feed it both.</p><h2>And the honest part</h2><p>Every one of these is a decision, not a config. LLM features in Arabic products live or die by how many of these decisions the team is willing to make explicitly — and how many they let the model handle by accident.</p>"}
About the author
H
Hani Yousif
CTO & Co-founder · Solutions Architect
Related
Architecture
The case for modular ERP in Saudi enterprise
Architecture
Building Arabic-first, not English-translated
Architecture