InterMIND کو چلانے والی چار ترجمہ پائپ لائنز کا اندرونی جائزہ

mind.com پر پرانا /product/overview/how-it-works صفحہ کئی بڑی ریلیزز پیچھے رہ چکا ہے۔ یہ زیادہ تر وینڈر صفحات کی طرح ایک ہی "ترجمہ انجن" بیان کرتا ہے، یعنی "آپ بولتے ہیں" سے "وہ سنتے ہیں" تک ایک بڑا تیر۔ دو سال پہلے بھی یہ تصویر حقیقت کی سادہ شکل تھی۔ آج یہ غلط ہے۔

حقیقت یہ ہے کہ InterMIND چار الگ ترجمہ پائپ لائنز چلاتا ہے۔ ہر ایک مختلف مسئلہ حل کرتی ہے، اور ہر ایک کا انجن، تاخیر کا بجٹ اور معیار کا دائرہ مختلف ہے۔ ان میں زبان منتخب کرنے والا ایک ہی پِکر مشترک ہے۔ انجن مشترک نہیں ہے۔

یہ "یہ کیسے کام کرتا ہے" کا تازہ جواب ہے۔

ایک ساتھی تحریر: "آپ کتنی زبانوں کو سپورٹ کرتے ہیں؟" میں بتایا گیا ہے کہ ہر پائپ لائن کیا کور کرتی ہے (23 / 23 / 30 / 17)۔ یہ تحریر بتاتی ہے کہ ہر پائپ لائن کیا کرتی ہے، اور وہ الگ کیوں ہے۔

"ہر کام کے لیے ایک انجن" کیوں غلط ہے

لائیو میٹنگ پلیٹ فارم کو بیک وقت کم از کم چار کام کرنے ہوتے ہیں، اور یہ ایک دوسرے سے متضاد سمتوں میں کھینچتے ہیں:

1. ریئل ٹائم آواز: آڈیو اندر، ترجمہ شدہ آڈیو باہر، ایک سیکنڈ سے کم میں، اور ہر ناظر اپنی زبان میں سنے۔ یہاں سب سے سخت پابندی تاخیر کی ہے۔
2. ریئل ٹائم چیٹ ٹیکسٹ: مختصر پیغامات، تیزی سے، اور ایڈٹس، کوٹس اور HTML ساخت محفوظ رہیں۔
3. ریئل ٹائم مشترکہ نوٹس: حرف بہ حرف اشتراکی ٹائپنگ، اور ساختی درجہ بندی (فہرستیں، سرخیاں، چیک باکس) جو ترجمے کے بعد بھی برقرار رہنی چاہیے۔
4. غیر ہم وقتی دستاویزی فائلیں: چیٹ میں ڈالی گئی 40 صفحات کی PDF۔ تاخیر کا کوئی بجٹ نہیں۔ یہاں سخت پابندی وفاداری کی ہے، یعنی فارمیٹنگ، ٹیبلز، صفحہ نمبر اور فونٹ۔

آپ ایک بڑی LLM کال بنا سکتے ہیں جو چاروں کام کرنے کی کوشش کرے۔ ہم نے کوشش کی۔ وہ چاروں میں خراب نکلی۔ آواز کے تاخیری بجٹ کا مطلب ہے کہ ماڈل سوچ نہیں سکتا، جبکہ دستاویزات کے وفاداری بجٹ کا مطلب ہے کہ ماڈل کو سوچنا پڑتا ہے۔ چیٹ ایڈٹ کو ناظر کی زبان میں diff چاہیے، اور 40 صفحات کی PDF کو ایسی فارمیٹ حفاظت چاہیے جو ٹوکن اسٹریم کرنے والا کوئی ماڈل نہیں دیتا۔

اس لیے ہم چار چلاتے ہیں۔ ہر ایک کا حال یہ ہے۔

پائپ لائن 1: ریئل ٹائم آواز کا ترجمہ

مسئلہ: ایک شریک فرانسیسی میں بولتا ہے۔ دوسرا جرمن میں شامل ہوا ہے، تیسرا برازیلی پرتگالی میں، اور چوتھا جاپانی میں۔ ہر ایک کو اسپیکر کو اپنی زبان میں، اپنے کان میں، اتنی کم تاخیر کے ساتھ سننا ہے کہ آنکھوں کا رابطہ ممکن رہے۔

بجٹ: سرے سے سرے تک ایک سیکنڈ سے کم۔ تقریباً 1.2 سیکنڈ سے اوپر جاتے ہی گفتگو ٹوٹ جاتی ہے۔ لوگ ترجمے کے اوپر بولنے لگتے ہیں اور میٹنگ "چلیں انگریزی پر آ جاتے ہیں" کی طرف بہہ جاتی ہے۔

آڈیو حقیقت میں کیسے سفر کرتی ہے

چند باتیں صراحت سے بیان کرنے کے لائق ہیں:

• ASR میڈیا سرور پر چلتا ہے۔ اسپیکر کی آڈیو WebRTC کے ذریعے ہمارے اپنے انجن، یعنی OVH، فرانس میں موجود Mind API تک جاتی ہے، اور وہیں اسی سرور پر پہچانی جاتی ہے جو کال چلا رہا ہے۔ براؤزر صرف آڈیو بھیجتا ہے اور الفاظ واپس وصول کرتا ہے۔ کوئی الگ اسپیچ وینڈر نہیں، اور ترجمہ شروع ہونے سے پہلے کوئی اضافی ہاپ نہیں۔ (چیٹ وائس نوٹس اس سے مستثنیٰ ہیں: ان کا speech-to-text Azure AI Speech پر چلتا ہے، جو ڈیفالٹ AI گیٹ وے کی اسپیچ سروس ہے۔)
• ترجمہ ایک ہی fan-out نہیں ہے۔ انجن کمرے میں موجود ہر ہدفی زبان کے حساب سے ترجمہ کرتا ہے، ہر ناظر کے حساب سے نہیں۔ کسی زبان میں ترجمہ تب شروع ہوتا ہے جب اس زبان کا پہلا سامع ترجمہ شدہ اسٹریم مانگتا ہے۔ جرمن چننے والے تین شرکاء ایک ہی جرمن ترجمہ شیئر کرتے ہیں، اور اگر کوئی عربی میں نہیں سن رہا تو عربی میں کچھ ترجمہ نہیں ہوتا۔ اسی لیے چار زبانوں والی میٹنگ کی لاگت چالیس زبانوں والی میٹنگ جتنی ہی ہوتی ہے، بشرطیکہ دیکھا جائے کہ حقیقت میں کون آیا۔ ہم ان زبانوں میں ترجمہ نہیں کرتے جن میں کوئی شریک سن ہی نہیں رہا۔
• مصنوعی آواز ہر ناظر کے لیے الگ ہے۔ ہر شریک کو اپنا ترجمہ شدہ آڈیو ٹریک ملتا ہے، جو اصل اسپیکر کی ویڈیو کے ساتھ ملایا جاتا ہے۔ وہ کوئی ایک "ترجمہ شدہ میٹنگ" نہیں دیکھ رہے ہوتے۔ وہ وہی میٹنگ دیکھ رہے ہوتے ہیں، اور ان کا ذاتی آڈیو چینل ان کی چنی ہوئی زبان میں ترجمہ ہوتا ہے۔ اسی لیے ایک ہی کمرے میں بیٹھے دو افراد الگ الگ ہیڈ فون لگا کر مختلف زبانیں سن سکتے ہیں۔

جب میٹنگ بگڑ جائے تو یہ کیوں اہم ہے

آٹھ زبانوں والی 60 منٹ کی کال میں چیزیں دلچسپ طریقوں سے ٹوٹتی ہیں: WebSockets گر جاتے ہیں، ASR کسی خاص اسم کی عارضی طور پر غلط ٹرانسکرپشن کر دیتا ہے، کسی شریک کا نیٹ ورک لڑکھڑانے لگتا ہے۔ اوپر بیان کردہ ساخت ہی ہمیں ناکامیوں کو الگ تھلگ کرنے دیتی ہے۔ ایک ناظر کی آڈیو میں خلل باقی سات پر اثر نہیں ڈالتا، کیونکہ ترجمہ انجن نے کبھی "وہ ایک ترجمہ" بنایا ہی نہیں تھا۔ اس نے آٹھ بنائے، متوازی طور پر، اور صرف متاثرہ کو بحال ہونا پڑتا ہے۔

انجن خود ہمارا ہے اور ہماری اپنی انفراسٹرکچر پر ہوسٹ ہے۔ ہم ریئل ٹائم آواز کو تھرڈ پارٹی جنرل پرپز LLMs کے ذریعے نہیں گزارتے۔ تاخیر کا بجٹ انہیں خارج کر دیتا ہے، اور ڈیٹا ریزیڈنسی کا معاملہ ان ریگولیٹڈ صارفین کے لیے انہیں خارج کر دیتا ہے جنہیں واقعی اس کی فکر ہے۔

آواز کے معیار کے بارے میں ہم کیا شائع کرتے ہیں: /benchmark ہر شائع شدہ زبان جوڑی کے لیے، ہر ماہ، پروڈکشن وائس پائپ لائن کو FLORES-200 کے جملوں پر چلاتا ہے۔ جج کا نام ظاہر ہے (بنیادی Gemini 3.7 Flash، متبادل Claude Sonnet 5)۔ مکمل تقسیم، یعنی median، p10، p90، min، max اور نمونے کا سائز، صفحے پر موجود ہے۔ یہ دیکھنے کے لیے کہ ان اعداد سے کیا ناپا جاتا ہے اور کیا نہیں، طریقہ کار ملاحظہ کریں۔

پائپ لائن 2: ریئل ٹائم چیٹ کا ترجمہ

مسئلہ: میٹنگ میں ہر چیٹ پیغام کا ہر شریک کے لیے، اس کی اپنی زبان میں، بھیجے جاتے ہی ترجمہ۔ اس کے ساتھ ایڈٹس بھی، اور ایڈٹس کو ایڈٹس جیسا دکھنا چاہیے، دوبارہ ترجمے جیسا نہیں۔

بجٹ: تیز، لیکن ایک سیکنڈ سے کم نہیں۔ چیٹ پیغام کو دوسری زبان میں ظاہر ہونے میں آدھا سیکنڈ لگ جائے تو کسی کو پروا نہیں ہوتی۔ لوگ یہ دیکھتے ہیں کہ ترجمہ درست ہے یا نہیں اور ایڈٹس کا مطلب بنتا ہے یا نہیں۔

چیٹ پائپ لائن حقیقت میں کیا کرتی ہے

ہر پیغام اسی ترجمہ انجن سے گزرتا ہے جو وائس پائپ لائن استعمال کرتی ہے، لیکن پری اور پوسٹ پروسیسنگ مختلف ہوتی ہے:

• HTML ساخت محفوظ رہتی ہے۔ چیٹ رچ ٹیکسٹ سپورٹ کرتی ہے (پیراگراف، فہرستیں، کوٹس، بولڈ، اٹالک)۔ ہم ماڈل کے لیے اسے سادہ ٹیکسٹ میں بدلتے ہیں، ترجمہ کرتے ہیں، پھر نتیجے کو اصل ٹیگز میں دوبارہ لپیٹ دیتے ہیں۔ ماڈل HTML کبھی نہیں دیکھتا، وہ صاف نثر دیکھتا ہے۔
• کوٹس کا ترجمہ الگ الگ ہوتا ہے۔ اگر آپ کسی پیغام کا جواب دیتے ہیں اور اسے کوٹ کرتے ہیں، تو [QUOTE]…[/QUOTE] بلاک اور نیا مواد الگ اکائیوں کے طور پر ترجمہ ہوتے ہیں، تاکہ ماڈل دونوں کو آپس میں خلط ملط نہ کر سکے۔
• لمبے پیغامات ٹکڑوں میں بانٹے جاتے ہیں۔ ہم پیراگراف کی حدود پر فی ٹکڑا 1,000 حروف کے حساب سے تقسیم کرتے ہیں۔ ہر ٹکڑا اپنی الگ ترجمہ کال ہے۔ ہم 4,000 حروف کے ناول ماڈل کو ایک ہی بار میں نہیں دیتے، کیونکہ ناکامی کی صورتیں (کٹ جانا، پیراگراف گم ہونا، جملے کا بیچ میں ٹوٹ جانا) بہت بدنما ہیں۔
• ترجمہ lazy ہے۔ ہم IntersectionObserver استعمال کرتے ہیں: پیغام کا ترجمہ تب ہوتا ہے جب وہ ناظر کے ویو پورٹ میں اسکرول ہو کر آئے۔ پہلے کسی طویل چینل میں زبان بدلنے سے ہسٹری کی ہر ترجمہ API کال دوبارہ چلتی تھی۔ اب ایسا نہیں ہوتا۔

دلچسپ حصہ: diffs کے طور پر ایڈٹس

v1.2 میں ہم نے بدلا کہ دوسری زبان کے ناظرین کے لیے چیٹ ایڈٹس کیسے برتاؤ کرتے ہیں۔ پرانا طریقہ یہ تھا کہ کوئی پیغام ایڈٹ کرتا، ہم پورے کا دوبارہ ترجمہ کرتے، آپ کو نیا پیراگراف نظر آتا اور آپ کو خود ڈھونڈنا پڑتا کہ کیا بدلا۔

نیا طریقہ:

1. اصل پیغام پہلے ہی آپ کی زبان میں ترجمہ ہو چکا ہوتا ہے۔
2. جب بھیجنے والا ایڈٹ کرتا ہے، تو ہم نئے ورژن کا دوبارہ ترجمہ کرتے ہیں۔
3. ہم آپ کے پچھلے ترجمے اور آپ کے نئے ترجمے کے درمیان آپ کی اپنی زبان میں diff نکالتے ہیں۔
4. ہم وہ diff ان لائن دکھاتے ہیں، بالکل اسی طرح جیسے Git دکھاتا ہے کہ کیا بدلا۔

چنانچہ جب انگریزی میں "review by Tuesday" بدل کر "review by Thursday" ہو جاتا ہے، تو آپ کے ہسپانوی پڑھنے والے ساتھی کو martes → jueves نمایاں نظر آتا ہے، کوئی دوبارہ ترجمہ شدہ پیراگراف نہیں جسے اسے پھر سے پڑھنا پڑے۔

اس کے لیے چیٹ پائپ لائن کو stateful فی ناظر کیش کے طور پر برتنا پڑا، نہ کہ بغیر اسٹیٹ کے ترجمہ-بر-درخواست اینڈ پوائنٹ کے طور پر۔ دستاویزات اور آواز کو اس کی ضرورت نہیں۔ چیٹ کو ہے۔

پائپ لائن 3: ریئل ٹائم مشترکہ نوٹس کا ترجمہ

مسئلہ: میزبان مشترکہ نوٹس کا پین کھولتا ہے اور ٹائپ کرنا شروع کرتا ہے۔ ہر شریک نوٹس اپنی زبان میں، حرف بہ حرف دیکھتا ہے، اور دستاویز کی ساخت، یعنی سرخیاں، nested فہرستیں، چیک لسٹس اور کوڈ بلاکس، سلامت رہتی ہے۔

بجٹ: چیٹ جیسا (تقریباً آدھا سیکنڈ)، لیکن دو اضافی پابندیوں کے ساتھ:

• جو چیز ترجمہ ہو رہی ہے وہ ترجمے کے دوران بدل رہی ہے۔ میزبان ابھی ٹائپ کر رہا ہے۔ جو سادہ نظام ہر کی اسٹروک پر "پوری دستاویز" کا ترجمہ کرتا ہے وہ جھلملاہٹ پیدا کرتا ہے اور API بجٹ جلاتا ہے۔ ہم پوری دستاویز کے بجائے تبدیل شدہ اکائی کی سطح پر ترجمہ کرتے ہیں۔
• ساخت کو بچنا ہوگا۔ اگر آپ ترجمہ ماڈل سے تین nested فہرستوں والے markdown بلاب کا ترجمہ کرنے کو کہیں، تو جو واپس آتا ہے وہ اصل جیسا دکھتا ہے لیکن اس میں درجہ بندی ہلکی سی چپٹی ہو چکی ہوتی ہے، آئٹمز کے نمبر بدل جاتے ہیں یا انڈینٹیشن کھسک جاتی ہے۔ ہم ماڈل کو پورا بلاب دیکھنے ہی نہیں دیتے۔

نوٹس پائپ لائن چیٹ سے کیسے مختلف ہے

ساخت کی حفاظت ہی اصل چیز ہے۔ ہم ہر فہرستی آئٹم کا ترجمہ الگ الگ کرتے ہیں، ایک دستاویز کے طور پر نہیں۔ ماڈل یہ دیکھتا ہے:

"کمپلائنس ریویو — Q2 ڈیلیوریبلز"

یہ نہیں:

"# Project plan\n## Quarter\n- Compliance review — Q2 deliverables\n- Vendor scoring\n - Tier 1 vendors..."

اردگرد کی دستاویز، یعنی <ul>، سرخیاں اور انڈینٹیشن، کلائنٹ کی طرف اسی ساخت کے مطابق دوبارہ بنائی جاتی ہے جو اصل دستاویز میں تھی، اور ہر leaf نوڈ کی جگہ اس کا ترجمہ رکھ دیا جاتا ہے۔ ماڈل کو درجہ بندی "بہتر" بنانے کا موقع کبھی نہیں ملتا۔

نوٹس بھی چیٹ ایڈٹس جیسا ہی فی ناظر diff ماڈل استعمال کرتے ہیں: اگر میزبان کوئی سطر بدلتا ہے، تو دوسری زبانوں کے ناظرین کو بدلے ہوئے الفاظ نمایاں نظر آتے ہیں، نیا پیراگراف نہیں۔

پائپ لائن 4: غیر ہم وقتی دستاویزی ترجمہ

مسئلہ: کوئی شخص چیٹ میں 40 صفحات کی PDF، Word دستاویز، PowerPoint ڈیک یا Excel شیٹ ڈالتا ہے۔ ہر شریک اپنی زبان میں ایک کاپی مانگ سکتا ہے۔ ترجمہ شدہ فائل اصل جیسی دکھنی چاہیے: وہی فونٹس، وہی ٹیبلز، وہی صفحہ نمبر، وہی ہیڈرز، اور چارٹس اپنی جگہ پر۔

بجٹ: ریئل ٹائم کی کوئی پابندی نہیں۔ ایک منٹ ٹھیک ہے۔ دو منٹ ٹھیک ہیں۔ پابندی وفاداری کی ہے۔ اگر ترجمہ شدہ PDF اصل جیسی نہ دکھے تو وصول کنندہ اس پر بھروسا نہیں کرے گا۔

یہ پائپ لائن آواز کے ساتھ انجن کیوں شیئر نہیں کرتی

ایک جنرل LLM، چاہے بہت اچھا ہو، آپ کو دستاویز کا ترجمہ شدہ متن واپس دے گا۔ وہ آپ کو اسی لے آؤٹ والی ترجمہ شدہ PDF واپس نہیں دے گا۔ ماڈل کے پاس "ایسے صفحے کے وقفے" کا کوئی تصور نہیں جو ماخذ کے ساتھ ہم آہنگ ہو، یا "ایسے ٹیبل سیل" کا جسے اپنے کالم کی چوڑائی برقرار رکھنی ہو۔

اس سطح کے لیے ہم براہ راست DeepL Document API استعمال کرتے ہیں۔ یہ فائلوں سے نکالی گئی نثر کے بجائے فائلوں کو فائلوں کی طرح ترجمہ کرنے کے لیے بنائی گئی ہے۔ DeepL یہ سنبھالتا ہے:

• PDF (لے آؤٹ کی حفاظت کے ساتھ)
• DOCX، DOC
• PPTX
• XLSX

دستاویز DeepL کی پائپ لائن میں اپ لوڈ ہوتی ہے، فارمیٹنگ برقرار رکھتے ہوئے سرور سائیڈ پر ترجمہ ہوتی ہے، اور اسی فارمیٹ میں واپس آتی ہے۔ پھر ہم نتیجہ اپنے آبجیکٹ اسٹوریج میں اپ لوڈ کرتے ہیں اور اسے چیٹ میں ڈاؤن لوڈ ہونے والے اٹیچمنٹ کے طور پر دوبارہ پیش کرتے ہیں۔

اس کی لاگت کیا ہے اور ہم اسے چھپاتے کیوں نہیں

DeepL فی دستاویز کم از کم 50,000 حروف کا بل بناتا ہے، Pro ٹیر پر تقریباً ایک امریکی ڈالر فی فائل، چاہے دستاویز ایک صفحے کی ہو یا تیس کی۔ ہم یہ لاگت خود برداشت کرتے ہیں، فی فائل چارج نہیں کرتے۔ یہ میٹنگ کے ترجمہ استعمال میں billed characters کے طور پر ظاہر ہوتی ہے، جو word-units میں بدل دیے جاتے ہیں تاکہ پروڈکٹ کے باقی حصے ترجمے کی سرگرمی جس طرح رپورٹ کرتے ہیں اس سے مطابقت رہے۔

ہم نے اس سطح کے لیے DeepL چنا کیونکہ فائلوں کو فائلوں کی طرح ترجمہ کرنا بالکل وہی کام ہے جس کے لیے وہ بنا ہے، اور ہم نے اس سے بہتر بنانے کی کوشش نہیں کی۔ الٹی سمت میں یہ بات درست نہیں: DeepL ایسی لائیو وائس پائپ لائن نہیں چلاتا جیسی ہم نے میٹنگز کے لیے بنائی ہے۔ مسائل مختلف ہیں، اوزار مختلف ہیں۔ "InterMIND کا ترجمہ کس چیز سے چلتا ہے" کا دیانت دار جواب ہے "ہر پائپ لائن کے لیے درست انجن"، نہ کہ "ہر جگہ ہمارا انجن"۔

وہ زبانیں جو یہ پائپ لائن کور کرتی ہے اور آواز نہیں

دستاویزی پائپ لائن 30 زبانوں تک پہنچتی ہے، جبکہ آواز کے لیے 23 ہیں۔ اضافی زبانوں میں شامل ہیں: بلغاری، یونانی، اسٹونین، انڈونیشین، لتھوانین، لیٹوین، سلوواک، سلووینین۔ (عربی بھی اس فہرست میں ہے اور اضافی زبانوں میں سے ایک ہے: اسے ریئل ٹائم پِکر سے ہٹا دیا گیا ہے جب تک اس کی آواز کا معیار ہمارے معیار سے نیچے ہے، اور اس کے فی جوڑی اسکور /benchmark پر عوامی رہتے ہیں۔ وہی عدد اسے واپس لائے گا۔ ہندی کے لیے عدم توازن الٹی سمت میں ہے: آواز پر لائیو، فائلوں پر ابھی نہیں۔)

یہ عدم توازن حقیقی ہے۔ اس کا مطلب ہے کہ میٹنگ میں ایک فرانسیسی شریک کنٹریکٹ PDF اسٹونین میں مانگ سکتا ہے، حالانکہ وہ میٹنگ اسٹونین میں سن نہیں سکتا۔ ہم اسے ایک ہی عدد کے پردے میں چھپانے کے بجائے پِکر میں نشان زد کرتے ہیں۔ اس کا استدلال زبانوں کی تعداد والی تحریر میں ہے۔

جہاں پائپ لائنز ملتی ہیں

چاروں پائپ لائنز الگ تھلگ نہیں چلتیں۔ میٹنگ روم وہ جگہ ہے جہاں وہ ایک دوسرے کو چھوتی ہیں، اور جوڑ اہم ہوتے ہیں:

• دستاویزی اٹیچمنٹ والا چیٹ پیغام متن کے لیے چیٹ پائپ لائن اور فائل کے لیے دستاویزی پائپ لائن کو متحرک کرتا ہے۔ دوسری زبان کا شریک پیغام کا ترجمہ فوراً دیکھتا ہے، اور اٹیچمنٹ کا ترجمہ غیر ہم وقتی طور پر ڈاؤن لوڈ کے قابل فائل کے طور پر آتا ہے۔
• وہ مشترکہ نوٹ جو ٹرانسکرپٹ کی کسی سطر کو کوٹ کرتا ہے نوٹس ↔ آواز کو عبور کرتا ہے۔ ٹرانسکرپٹ وہ ہے جو وائس پائپ لائن نے بھیجنے والے کی زبان کے لیے بنایا؛ نوٹ کا ترجمہ اس کوٹ کی فی ناظر کاپی باقی سب کی زبان میں بناتا ہے، اور اس کا ماخذ حوالہ برقرار رہتا ہے۔
• میٹنگ کے بعد ایکسپورٹ کیا گیا ٹرانسکرپٹ پوری گفتگو پر چیٹ طرز کی ٹیکسٹ پائپ لائن چلاتا ہے اور ہر زبان کے لیے ایک فائل بناتا ہے جو شرکاء ڈاؤن لوڈ کر سکتے ہیں۔ یہ وہی کوڈ پاتھ ہے جو چیٹ ترجمے کا ہے، بس batched۔

زبان کا پِکر UI کا ایک ٹکڑا ہے۔ اس کے نیچے انفراسٹرکچر چار پائپ لائنز ہے جو ایک دوسرے سے بات کرتی ہیں۔

جو ہم جان بوجھ کر نہیں آزماتے

• کوئی "متحد ترجمہ ماڈل" نہیں۔ ہم ایک ایسا ماڈل نہیں بنا رہے جو آواز، چیٹ، نوٹس اور دستاویزات سب کرے۔ تاخیر بمقابلہ وفاداری کے سمجھوتے میں کوئی فاتح نہیں ہے۔ ہم ہر سطح کے لیے درست انجن استعمال کرتے ہیں۔
• کوئی خاموش re-routing نہیں۔ اگر فائل پائپ لائن آج ہندی میں ترجمہ نہیں کر سکتی، تو ہم چپکے سے وائس انجن پر نہیں آ جاتے اور یہ ظاہر نہیں کرتے کہ کام ہو گیا۔ فائل پِکر کمی کو چھپانے کے بجائے نشان زد کرتا ہے۔
• کوئی "ہم 200 زبانوں میں ترجمہ کرتے ہیں" نہیں۔ ہمارا انجن 24 زبانیں نکالتا ہے۔ لائیو سطحیں 23 دیتی ہیں، دستاویزات 30۔ اور مارکیٹنگ کے لیے موزوں ایک عدد کے بجائے، فی جوڑی معیار، جسے آڈیٹر کے سامنے ٹھہرنا ہوتا ہے، /benchmark پر شائع ہے، کمزور جوڑیوں سمیت۔

خود آزما کر دیکھیں

• لائیو ڈیمو آزمائیں — لائیو وائس پائپ لائن کو آپ کی آڈیو پر چلاتا ہے، 23 پروڈکٹ زبانوں میں سے کسی بھی میں۔ یہ وہی پائپ لائن ہے جو /benchmark کو اسکور کرتی ہے۔
• بینچ مارک دیکھیں — حقیقی ٹریفک پر فی جوڑی، فی ماہ معیار۔ پِکر کی ہر جوڑی، مضبوط ہو یا کمزور، براہ راست لنک کے قابل ہے۔
• طریقہ کار پڑھیں — اعداد کیا ہیں، کیا نہیں ہیں، اور جج کون ہے۔

چار پائپ لائنز، چار انجن، ایک میٹنگ روم۔ پرانے how-it-works صفحے کا یہی دیانت دار متبادل ہے۔

— Mind.com ٹیم

ماخذ: DeepL — سپورٹ شدہ زبانیں، DeepL — استعمال کی گنتی اور بلنگ (فی فائل 50,000 حروف کا کم از کم)، FLORES-200؛ پائپ لائن کے اندرونی حقائق شپ شدہ کوڈ کے خلاف تصدیق شدہ، اگست 2026 میں جانچے گئے۔