نظرة داخلية على أربع خطوط أنابيب الترجمة التي تُشغّل InterMIND

الصفحة القديمة /product/overview/how-it-works على mind.com أصبحت متأخرة بعدة إصدارات رئيسية. فهي تصف "محرك ترجمة" واحدًا بالطريقة التي تصف بها معظم صفحات المزوّدين ذلك — سهم كبير واحد من "أنت تتحدث" إلى "هم يسمعون". كانت هذه الصورة تبسيطًا مفرطًا حتى قبل عامين. واليوم أصبحت خاطئة.

الحقيقة هي أن InterMIND تُشغّل أربع خطوط أنابيب ترجمة مستقلة، يحل كل منها مشكلة مختلفة بمحرك مختلف، وميزانية زمن استجابة مختلفة، ونطاق جودة مختلف. تتشارك هذه الخطوط في أداة اختيار اللغة، ولا تتشارك في المحرك.

هذه هي الإجابة المُحدَّثة على سؤال "كيف يعمل ذلك".

مقالة مصاحبة: "كم عدد اللغات التي تدعمونها؟" تتناول ما يغطيه كل خط أنابيب (23 / 23 / 30 / 17). أما هذا المقال فيتناول ما يقوم به كل خط أنابيب — ولماذا يُعدّ كل واحد منها كيانًا مستقلًا بذاته.

لماذا فكرة "محرك واحد لكل شيء" هي وهم

منصة الاجتماعات المباشرة عليها أداء أربع مهام على الأقل في الوقت نفسه، وهذه المهام تتجه في اتجاهات متعارضة:

1. الصوت في الوقت الفعلي — صوت يدخل، وصوت مُترجَم يخرج، في أقل من ثانية واحدة، وكل مشاهد يسمعه بلغته الخاصة. القيد الصارم هنا هو زمن الاستجابة.
2. نص الدردشة في الوقت الفعلي — رسائل قصيرة، سريعة، مع الحفاظ على التعديلات والاقتباسات وبنية HTML.
3. الملاحظات المشتركة في الوقت الفعلي — كتابة تعاونية حرفًا بحرف، مع تسلسل هرمي بنيوي (قوائم، عناوين، خانات اختيار) يجب أن يبقى سليمًا بعد الترجمة.
4. ملفات المستندات غير المتزامنة — ملف PDF من 40 صفحة يُرفَق في الدردشة. لا توجد ميزانية زمن استجابة هنا. القيد الصارم هو الدقة — التنسيق، الجداول، أرقام الصفحات، الخط.

يمكنك بناء استدعاء واحد ضخم لنموذج LLM يحاول القيام بالمهام الأربع جميعًا. جرّبنا ذلك. والنتيجة سيئة في المهام الأربع كلها. ميزانية زمن الاستجابة الخاصة بالصوت تعني أن النموذج لا يملك وقتًا للتفكير؛ في حين أن ميزانية الدقة الخاصة بالمستندات تفرض عليه أن يفكّر. تعديل رسالة دردشة يحتاج إلى فَرق (diff) بلغة المشاهد؛ وملف PDF من 40 صفحة يحتاج إلى الحفاظ على التنسيق وهو أمر لا يقدمه أي نموذج يعمل ببث الرموز (tokens).

لذلك نُشغّل أربعة خطوط أنابيب. وفيما يلي كل واحد منها.

خط الأنابيب الأول: ترجمة الصوت في الوقت الفعلي

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

الميزانية: أقل من ثانية واحدة من طرف إلى طرف. أي تأخير يتجاوز حوالي 1.2 ثانية يُخلّ بسير المحادثة — يبدأ الأشخاص بالتحدث فوق الترجمة، ويتجه الاجتماع نحو "لنتحدث بالإنجليزية فقط".

كيف ينتقل الصوت فعليًا

بعض النقاط التي تستحق الذكر بوضوح:

• يعمل التعرّف على الكلام (ASR) في متصفح المتحدث، وليس على خادم مركزي. نستخدم Mind SDK محليًا؛ وهذا يوفّر رحلة ذهاب وعودة كاملة، ويمنحنا النص المكتوب باللغة المصدر بأقل تأخير ممكن قبل أن تبدأ الترجمة أساسًا.
• الترجمة ليست عملية توزيع واحدة. نحتفظ بمجموعة من اتصالات WebSocket إلى محرك ترجمتنا، اتصال واحد لكل لغة هدف موجودة في الغرفة. فإذا اختار ثلاثة مشاركين اللغة الألمانية، تتشارك هذه اللغة اتصالًا واحدًا. وإذا لم يختر أحد اللغة العربية، لا يُفتح أي اتصال لها. تُغلق المجموعة الاتصالات الخاملة بعد خمس دقائق. لهذا السبب فإن كلفة اجتماع بأربع لغات تساوي كلفة اجتماع بأربعين لغة، بحسب من حضر فعليًا — فنحن لا نترجم أبدًا إلى لغات لا يستمع إليها أي مشارك.
• الكلام المُصنَّع صوتيًا خاص بكل مشاهد. يحصل كل مشارك على مسار صوتي مُترجَم خاص به، يُمزَج مع فيديو المتحدث الأصلي. فهم لا يشاهدون نسخة رئيسية واحدة من "الاجتماع المترجَم" — بل يشاهدون الاجتماع نفسه، مع قناة صوت شخصية مُترجَمة إلى اللغة التي اختاروها. لهذا السبب يمكن لشخصين في الغرفة الفعلية نفسها أن يوصّل كل منهما سماعات ويسمع لغة مختلفة.

لماذا يهم هذا عندما يسوء سير الاجتماع

في مكالمة تدوم 60 دقيقة بثماني لغات، تحدث أعطال بطرق تستحق الاهتمام: اتصالات WebSocket تنقطع، ونظام ASR يخطئ مؤقتًا في تدوين اسم علم، وشبكة أحد المشاركين تصبح غير مستقرة. البنية المذكورة أعلاه هي ما يتيح لنا عزل الأعطال: فتعطّل صوت مشاهد واحد لا يؤثر على السبعة الآخرين، لأن محرك الترجمة لم يُنتج "الترجمة" كنسخة واحدة منذ البداية — بل أنتج ثماني نسخ بالتوازي، ولا تحتاج إلى التعافي إلا النسخة المتأثرة.

المحرك نفسه من تطويرنا، ومُستضاف على بنيتنا التحتية الخاصة. فنحن لا نُمرّر الصوت في الوقت الفعلي عبر نماذج LLM عامة تابعة لجهات خارجية. ميزانية زمن الاستجابة تستثنيها من الأساس؛ وقصة إقامة البيانات تستثنيها أيضًا في نظر العملاء الخاضعين للتنظيم الذين يهتمون بهذا الأمر بالفعل.

ما ننشره حول جودة الصوت: تُشغّل صفحة /benchmark خط أنابيب الصوت الإنتاجي مقابل جُمل FLORES-200 لكل زوج لغوي منشور، بشكل شهري. الحكم مُحدَّد بالاسم (Gemini 3.7 Flash أساسيًا، وClaude Sonnet 5 كخيار احتياطي). التوزيع الكامل — الوسيط، p10، p90، الحد الأدنى، الحد الأعلى، حجم العينة — متوفر على الصفحة. راجع منهجية القياس لمعرفة ما تقيسه هذه الأرقام وما لا تقيسه.

خط الأنابيب الثاني: ترجمة الدردشة في الوقت الفعلي

المشكلة: كل رسالة دردشة في الاجتماع تُترجَم لكل مشارك بلغته الخاصة، لحظة إرسالها. بالإضافة إلى التعديلات — التي يجب أن تبدو كتعديلات، لا كترجمات جديدة بالكامل.

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

ما الذي يقوم به خط أنابيب الدردشة فعليًا

تمرّ كل رسالة عبر محرك الترجمة نفسه الذي يستخدمه خط أنابيب الصوت — لكن بمعالجة مسبقة ولاحقة مختلفة:

• بنية HTML محفوظة. تدعم الدردشة النصوص المنسّقة (فقرات، قوائم، اقتباسات، خط عريض، خط مائل). نقوم بتحويلها إلى نص عادي للنموذج، ثم نترجمها، ثم نعيد تغليف النتيجة بالوسوم (tags) الأصلية. النموذج لا يرى وسوم HTML مطلقًا — بل يرى نصًا نثريًا نظيفًا.
• الاقتباسات تُترجَم بشكل مستقل. إذا رددت على رسالة واقتبستها، تُترجَم كتلة [QUOTE]…[/QUOTE] والمحتوى الجديد كوحدتين منفصلتين، حتى لا يخلط النموذج بينهما.
• الرسائل الطويلة تُقسَّم إلى أجزاء. نُقسّمها عند حدود الفقرات بحد أقصى 1000 حرف لكل جزء. كل جزء يمثّل استدعاء ترجمة مستقلًا بذاته. فنحن لا نُغذّي النموذج بروايات من 4000 حرف في طلب واحد — لأن أنماط الفشل الناتجة (اقتطاع النص، ضياع فقرات، توقف في وسط الجملة) قبيحة جدًا.
• الترجمة كسولة (lazy). نستخدم IntersectionObserver: لا تُترجَم الرسالة إلا عندما تدخل ضمن نطاق رؤية المشاهد عبر التمرير. تبديل اللغة في قناة نشطة منذ وقت طويل كان يعيد تنفيذ كل استدعاء ترجمة من السجل التاريخي بالكامل. أما الآن فلم يعد الأمر كذلك.

الجزء المثير للاهتمام: التعديلات كفروقات (diffs)

في الإصدار v1.2 غيّرنا طريقة سلوك تعديلات الدردشة بالنسبة للمشاهدين بلغة أخرى. كان السلوك القديم كالتالي: يُعدّل أحدهم رسالة، فنُعيد ترجمة النص كاملًا، وتظهر لك فقرة جديدة ويتوجب عليك أن تكتشف بنفسك ما الذي تغيّر.

السلوك الجديد:

1. الرسالة الأصلية كانت مُترجَمة مسبقًا إلى لغتك.
2. عندما يُعدّل المُرسل الرسالة، نُعيد ترجمة النسخة الجديدة فقط.
3. نحسب الفرق (diff) بين ترجمتك السابقة وترجمتك الجديدة، بلغتك.
4. نعرض هذا الفرق مباشرة داخل النص — بالطريقة نفسها التي يعرض بها Git ما تغيّر.

فعندما تتحول عبارة "review by Tuesday" إلى "review by Thursday" في الإنجليزية، يرى زميلك الذي يقرأ الإسبانية العبارة martes → jueves مُظلّلة، بدلًا من فقرة مُترجَمة من جديد يتوجب عليه إعادة قراءتها بالكامل.

تطلّب ذلك التعامل مع خط أنابيب الدردشة كذاكرة تخزين مؤقت (cache) ذات حالة خاصة بكل مشاهد، لا كنقطة نهاية عديمة الحالة تُترجم عند الطلب فقط. المستندات والصوت لا يحتاجان إلى ذلك. أما الدردشة فتحتاجه.

خط الأنابيب الثالث: ترجمة الملاحظات المشتركة في الوقت الفعلي

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

الميزانية: مثل الدردشة (~نصف ثانية)، لكن مع قيدين إضافيين:

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

كيف يختلف خط أنابيب الملاحظات عن الدردشة

الحفاظ على البنية هو الأمر الجوهري هنا. نحن نترجم كل عنصر من القائمة بشكل مستقل بدلًا من ترجمته كمستند واحد. ما يراه النموذج هو:

"مراجعة الامتثال — مخرجات الربع الثاني"

— وليس:

"# مخطط المشروع\n## الربع\n- مراجعة الامتثال — مخرجات الربع الثاني\n- تصنيف المورّدين\n - موردو الفئة 1..."

يُعاد بناء المستند المُغلِّف — أي وسم <ul>، والعناوين، والمسافات البادئة — على جهة العميل (client side) باستخدام البنية نفسها التي كانت في المستند الأصلي، مع تبديل كل عقدة ورقية (leaf node) بترجمتها. النموذج لا يحصل مطلقًا على فرصة "تحسين" التسلسل الهرمي.

تستخدم الملاحظات أيضًا نموذج الفروقات (diff) نفسه الخاص بكل مشاهد المُستخدَم في تعديلات الدردشة: إذا غيّر المستضيف سطرًا، يرى المشاهدون بلغات أخرى الكلمات المتغيّرة مُظلّلة، لا فقرة جديدة بالكامل.

خط الأنابيب الرابع: ترجمة المستندات غير المتزامنة

المشكلة: يُرفق أحد المشاركين ملف PDF من 40 صفحة، أو مستند Word، أو عرض PowerPoint، أو ورقة Excel في الدردشة. يمكن لكل مشارك طلب نسخة بلغته الخاصة. يجب أن يبدو الملف المُترجَم مثل الأصل تمامًا — نفس الخطوط، نفس الجداول، نفس أرقام الصفحات، نفس الرؤوس، ونفس الرسوم البيانية في مواضعها.

الميزانية: لا يوجد قيد زمن فعلي هنا. دقيقة واحدة مقبولة. دقيقتان مقبولتان أيضًا. القيد هنا هو الدقة — فإذا لم يبدُ ملف PDF المُترجَم مثل الأصل، لن يثق به المُستلِم.

لماذا لا يتشارك هذا خط الأنابيب في المحرك مع الصوت

أي نموذج LLM عام، حتى إن كان جيدًا جدًا، سيُعيد إليك نصًا مُترجَمًا من المستند. لكنه لن يُعيد إليك ملف PDF مُترجَم بنفس التخطيط. فالنموذج لا يملك مفهومًا عن "فاصل صفحات يجب أن يتماشى مع المصدر" أو "خلية جدول يجب أن تحافظ على عرض عمودها".

لهذا السياق نستخدم DeepL Document API مباشرة. فهو مصمَّم خصيصًا لترجمة الملفات كملفات، لا النصوص المستخرجة من الملفات. يتعامل DeepL مع:

• PDF (مع الحفاظ على التخطيط)
• DOCX، DOC
• PPTX
• XLSX

يُرفَع المستند إلى خط أنابيب DeepL، ويُترجَم من جهة الخادم (server-side) مع الحفاظ على التنسيق سليمًا، ويُعاد بالصيغة نفسها. ثم نرفع النتيجة إلى تخزين الكائنات (object storage) الخاص بنا ونُظهرها مرة أخرى في الدردشة كمرفق قابل للتنزيل.

ما تكلفة ذلك ولماذا لا نُخفيها

تفرض DeepL رسومًا بحد أدنى 50,000 حرف لكل مستند — أي ما يقارب دولارًا أمريكيًا واحدًا لكل ملف في باقة Pro، بصرف النظر عن كون المستند صفحة واحدة أو ثلاثين صفحة. نحن نستوعب هذه التكلفة بدلًا من فرضها على أساس كل ملف؛ وتظهر هذه التكلفة في استخدام الترجمة الخاص بالاجتماع كـ أحرف مُفوترة (billed characters)، تُحوَّل إلى وحدات كلمات تتوافق مع الطريقة التي يُقرّر بها باقي المنتج نشاط الترجمة.

اختَرنا DeepL لهذا السياق لأن ترجمة الملفات كملفات هي تمامًا المهمة التي صُمِّم من أجلها — ولم نحاول بناء نسخة أفضل منه. لكن العكس غير صحيح — فـ DeepL لا يُشغّل خط أنابيب صوت مباشر من النوع الذي بنيناه للاجتماعات. مشكلات مختلفة؛ أدوات مختلفة. النسخة الصادقة من سؤال "ما الذي يُشغّل ترجمة InterMIND" هي "المحرك المناسب لكل خط أنابيب" — وليست "محركنا، في كل مكان".

اللغات التي يغطيها هذا خط الأنابيب ولا يغطيها الصوت

يصل خط أنابيب المستندات إلى 30 لغة، مقارنة بـ 23 لغة للصوت. تشمل اللغات الإضافية: البلغارية، اليونانية، الإستونية، الإندونيسية، الليتوانية، اللاتفية، السلوفاكية، السلوفينية. (العربية أيضًا موجودة في هذه القائمة، وهي من ضمن اللغات الإضافية: فقد سُحبت من أداة اختيار اللغة في الوقت الفعلي لأن جودتها الصوتية لا تزال دون المستوى الذي نعتمده، وتبقى درجاتها الخاصة بكل زوج لغوي منشورة علنًا على /benchmark — وهذا الرقم هو ما سيعيدها إلى الواجهة. أما التفاوت في الاتجاه المعاكس فيخص الهندية — متوفرة على الصوت مباشرة، ولكن ليس بعد على الملفات.)

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

أين تتقاطع خطوط الأنابيب

لا تعمل الأربع خطوط أنابيب بشكل منعزل. غرفة الاجتماع هي المكان الذي تتلامس فيه، وهذه نقاط التقاء تهم:

• رسالة دردشة مع مرفق مستند تُفعّل خط أنابيب الدردشة للنص وخط أنابيب المستندات للملف. يرى المشارك بلغة أخرى الرسالة مُترجَمة فورًا، بينما تصل ترجمة المرفق بشكل غير متزامن كملف قابل للتنزيل.
• ملاحظة مشتركة تقتبس سطرًا من النص المكتوب للاجتماع تعبر بين الملاحظات ↔ الصوت. النص المكتوب هو ما أنتجه خط أنابيب الصوت بلغة المُرسل؛ وترجمة الملاحظة تُنتج نسخة خاصة بكل مشاهد من ذلك الاقتباس بلغة كل الآخرين، مع الحفاظ على نسب المصدر.
• نص مكتوب يُصدَّر بعد الاجتماع يُشغّل خط أنابيب النص من نوع الدردشة على المحادثة الكاملة، مُنتِجًا ملفًا لكل لغة يمكن للمشاركين تنزيله. هذا هو مسار الكود نفسه المُستخدَم في ترجمة الدردشة، لكن على شكل دُفعات (batched).

أداة اختيار اللغة هي عنصر واحد من واجهة المستخدم. لكن البنية التحتية تحتها هي أربعة خطوط أنابيب، تتحدث فيما بينها.

ما لا نحاول القيام به عمدًا

• لا "نموذج ترجمة موحّد". نحن لا نبني نموذجًا واحدًا يتولى الصوت والدردشة والملاحظات والمستندات. المفاضلة بين زمن الاستجابة والدقة ليس لها فائز واحد. نستخدم المحرك المناسب لكل سياق.
• لا إعادة توجيه صامتة. إذا لم يستطع خط أنابيب الملفات اليوم الترجمة إلى الهندية، فلن نتراجع بصمت إلى محرك الصوت ونتظاهر أن الأمر نجح — بل تُشير أداة اختيار الملف إلى هذه الثغرة بدلًا من إخفائها.
• لا "نترجم إلى 200 لغة". محركنا يُنتج 24 لغة. الواجهات المباشرة تدعم 23 لغة، والمستندات 30 — وبدلًا من رقم واحد جذاب تسويقيًا، تُنشر جودة كل زوج لغوي، وهي الجودة التي يجب أن تصمد أمام مُدقّق، على /benchmark، بما في ذلك الأزواج الأضعف.

جرّبه بنفسك

• جرّب العرض التجريبي المباشر — يُشغّل خط أنابيب الصوت المباشر على صوتك، بأي من 23 لغة يدعمها المنتج. وهو خط الأنابيب نفسه الذي يُقيَّم في /benchmark.
• شاهد صفحة القياس — جودة كل زوج لغوي، شهريًا، على حركة بيانات فعلية. كل زوج موجود في أداة الاختيار، قويًا كان أو ضعيفًا، وقابل للربط المباشر.
• اقرأ منهجية القياس — ما هي هذه الأرقام، وما لا تعنيه، ومن هو الحكم.

أربعة خطوط أنابيب، وأربعة محركات، وغرفة اجتماع واحدة. هذا هو البديل الصادق للصفحة القديمة how-it-works.

— فريق Mind.com

المصادر: DeepL — اللغات المدعومة، DeepL — عدد الاستخدام والفوترة (الحد الأدنى 50,000 حرف لكل ملف)، FLORES-200؛ تم التحقق من حقائق خطوط الأنابيب الداخلية مقارنة بالكود المنشور فعليًا، وتم التحقق منها في أغسطس 2026.