InterMIND যে চারটি অনুবাদ পাইপলাইনে চলে, তার ভেতরের কথা

mind.com-এর পুরোনো /product/overview/how-it-works পৃষ্ঠাটি এখন কয়েকটি বড় রিলিজ পিছিয়ে আছে। বেশিরভাগ ভেন্ডর পৃষ্ঠার মতো এটিও একটিমাত্র "অনুবাদ ইঞ্জিন"-এর কথা বলে: "আপনি বলছেন" থেকে "তারা শুনছেন" পর্যন্ত একটাই বড় তীর। দুই বছর আগেই ছবিটা অতিসরলীকৃত ছিল। আজ এটি ভুল।

আসল কথা হলো, InterMIND চালায় চারটি আলাদা অনুবাদ পাইপলাইন। প্রতিটি আলাদা সমস্যা সমাধান করে, আলাদা ইঞ্জিন, আলাদা লেটেন্সি বাজেট আর আলাদা মানের পরিসীমা নিয়ে। ভাষা বাছাইয়ের ইন্টারফেসটি এদের এক, কিন্তু ইঞ্জিন এক নয়।

"এটি কীভাবে কাজ করে" প্রশ্নের এটাই হালনাগাদ উত্তর।

সঙ্গী লেখা: "আপনারা কতগুলো ভাষা সমর্থন করেন?" লেখাটি বলে প্রতিটি পাইপলাইন কী কভার করে (23 / 23 / 30 / 17)। এই লেখাটি বলে প্রতিটি পাইপলাইন কী করে, এবং কেন সেটি আলাদা একটি জিনিস।

"সবকিছুর জন্য একটাই ইঞ্জিন" কেন একটি ভুল ধারণা

একটি লাইভ মিটিং প্ল্যাটফর্মকে একই সঙ্গে অন্তত চারটি কাজ করতে হয়, এবং কাজগুলো পরস্পরের উল্টো দিকে টানে:

1. রিয়েল-টাইম ভয়েস: অডিও ঢোকে, অনুবাদিত অডিও বেরোয়, এক সেকেন্ডের মধ্যে, প্রতিটি দর্শক নিজের ভাষায়। এখানে প্রধান বাধা লেটেন্সি।
2. রিয়েল-টাইম চ্যাট টেক্সট: ছোট বার্তা, দ্রুত, এডিট, কোট এবং HTML কাঠামো অক্ষুণ্ণ রেখে।
3. রিয়েল-টাইম শেয়ার্ড নোটস: অক্ষর ধরে ধরে সহযোগিতামূলক টাইপিং, যেখানে কাঠামোগত শ্রেণিবিন্যাস (তালিকা, শিরোনাম, চেকবক্স) অনুবাদের পরেও টিকে থাকতে হয়।
4. অ্যাসিনক্রোনাস ডকুমেন্ট ফাইল: চ্যাটে ফেলে দেওয়া 40 পৃষ্ঠার একটি PDF। এখানে লেটেন্সির কোনো বাজেট নেই। প্রধান বাধা বিশ্বস্ততা: ফরম্যাটিং, টেবিল, পৃষ্ঠা নম্বর, ফন্ট।

চারটি কাজই করতে চায় এমন একটি বিশাল LLM কল বানানো যায়। আমরা চেষ্টা করেছি। চারটিতেই সেটি খারাপ। ভয়েসের লেটেন্সি বাজেটের মানে মডেল ভাবার সময় পায় না, আর ডকুমেন্টের বিশ্বস্ততার বাজেটের মানে মডেলকে ভাবতেই হয়। চ্যাট এডিটের জন্য দরকার দর্শকের ভাষায় একটি ডিফ; 40 পৃষ্ঠার PDF-এর জন্য দরকার এমন ফরম্যাট সংরক্ষণ, যা কোনো টোকেন-স্ট্রিমিং মডেল দেয় না।

তাই আমরা চারটি চালাই। প্রতিটির বিবরণ নিচে।

পাইপলাইন 1: রিয়েল-টাইম ভয়েস অনুবাদ

সমস্যা: একজন অংশগ্রহণকারী ফরাসি ভাষায় কথা বলছেন। আরেকজন যোগ দিয়েছেন জার্মান ভাষায়, তৃতীয়জন ব্রাজিলিয়ান পর্তুগিজে, চতুর্থজন জাপানিতে। প্রত্যেককে বক্তার কথা নিজের ভাষায়, নিজের কানে শুনতে হবে, এমন বিলম্বে যাতে চোখে চোখ রেখে কথা বলা সম্ভব থাকে।

বাজেট: শুরু থেকে শেষ পর্যন্ত এক সেকেন্ডের কম। ~1.2 সেকেন্ড পেরোলেই কথোপকথন ভেঙে যায়। মানুষ অনুবাদের ওপর দিয়েই কথা বলতে শুরু করে, আর মিটিং "চলুন ইংরেজিতেই ফিরে যাই"-এর দিকে গড়ায়।

অডিও আসলে কীভাবে চলাচল করে

কয়েকটি বিষয় আলাদা করে বলার মতো:

• ASR চলে মিডিয়া সার্ভারে। বক্তার অডিও WebRTC-র মাধ্যমে আমাদের নিজস্ব ইঞ্জিনে, অর্থাৎ ফ্রান্সের OVH-এর Mind API-তে যায় এবং কলটি যে সার্ভারে চলছে সেখানেই শনাক্ত হয়। ব্রাউজার শুধু অডিও পাঠায় আর শব্দগুলো ফেরত পায়। আলাদা কোনো স্পিচ ভেন্ডর নেই, অনুবাদ শুরুর আগে বাড়তি কোনো হপও নেই। (চ্যাটের ভয়েস নোট এর ব্যতিক্রম: সেগুলোর স্পিচ-টু-টেক্সট চলে Azure AI Speech-এ, যা ডিফল্ট AI গেটওয়ের স্পিচ সার্ভিস।)
• অনুবাদ কোনো একক ফ্যান-আউট নয়। ইঞ্জিন অনুবাদ করে ঘরে উপস্থিত প্রতিটি লক্ষ্য ভাষার জন্য, প্রতিটি দর্শকের জন্য নয়। কোনো ভাষায় অনুবাদ শুরু হয় যখন সেই ভাষার প্রথম শ্রোতা অনুবাদিত স্ট্রিম চান। জার্মান বেছে নেওয়া তিনজন অংশগ্রহণকারী একটি জার্মান অনুবাদই ভাগ করে নেন, আর কেউ আরবিতে না শুনলে আরবিতে কিছুই অনুবাদ হয় না। তাই চার ভাষার মিটিং আর চল্লিশ ভাষার মিটিংয়ের খরচ একই থাকে, যতক্ষণ না দেখা যায় আসলে কারা উপস্থিত হয়েছেন। যে ভাষায় কেউ শুনছেন না, সেখানে আমরা কখনো অনুবাদ করি না।
• সিন্থেসাইজড স্পিচ প্রতি দর্শকের জন্য আলাদা। প্রতিটি অংশগ্রহণকারী নিজের অনুবাদিত অডিও ট্র্যাক পান, যা মূল বক্তার ভিডিওর সঙ্গে মিশিয়ে দেওয়া হয়। তারা কোনো একটি "অনুবাদিত মিটিং" দেখছেন না। তারা দেখছেন একই মিটিং, শুধু তাদের ব্যক্তিগত অডিও চ্যানেলটি তাদের বেছে নেওয়া ভাষায় অনুবাদিত। এ কারণেই একই ঘরে বসা দুজন হেডফোন লাগিয়ে আলাদা আলাদা ভাষা শুনতে পারেন।

মিটিং এলোমেলো হয়ে গেলে এটি কেন গুরুত্বপূর্ণ

আট ভাষার 60 মিনিটের একটি কলে মজার মজার উপায়ে জিনিস ভেঙে পড়ে: WebSocket বিচ্ছিন্ন হয়, ASR কোনো নামবাচক বিশেষ্য সাময়িকভাবে ভুল লেখে, একজন অংশগ্রহণকারীর নেটওয়ার্ক অস্থির হয়ে ওঠে। উপরের স্থাপত্যই আমাদের ত্রুটিকে আলাদা করে রাখতে দেয়। একজন দর্শকের অডিওতে সমস্যা হলে বাকি সাতজনের কিছু হয় না, কারণ অনুবাদ ইঞ্জিন কখনো "একটি অনুবাদ" তৈরিই করেনি। সে সমান্তরালে আটটি তৈরি করেছে, আর শুধু ক্ষতিগ্রস্তটিকেই সেরে উঠতে হয়।

ইঞ্জিনটি আমাদের নিজস্ব, আমাদের নিজেদের অবকাঠামোতে হোস্ট করা। আমরা রিয়েল-টাইম ভয়েস কোনো তৃতীয় পক্ষের সাধারণ-উদ্দেশ্যের LLM-এর মধ্য দিয়ে পাঠাই না। লেটেন্সি বাজেট সেগুলোকে বাদ দেয়; আর ডেটা রেসিডেন্সির প্রশ্নে যেসব নিয়ন্ত্রিত গ্রাহক সত্যিই সচেতন, তাদের ক্ষেত্রেও সেগুলো বাদ পড়ে।

ভয়েস মান নিয়ে আমরা যা প্রকাশ করি: /benchmark প্রতি মাসে প্রতিটি প্রকাশিত ভাষা-জোড়ার জন্য প্রোডাকশন ভয়েস পাইপলাইনকে FLORES-200 বাক্যের বিরুদ্ধে চালায়। বিচারকের নাম প্রকাশিত (প্রাথমিক Gemini 3.7 Flash, বিকল্প Claude Sonnet 5)। পূর্ণ বিন্যাস, অর্থাৎ মধ্যমা, p10, p90, সর্বনিম্ন, সর্বোচ্চ ও নমুনার আকার, পৃষ্ঠাটিতেই আছে। ওই সংখ্যাগুলো কী পরিমাপ করে আর কী করে না, তা জানতে দেখুন পদ্ধতি।

পাইপলাইন 2: রিয়েল-টাইম চ্যাট অনুবাদ

সমস্যা: মিটিংয়ের প্রতিটি চ্যাট বার্তা পাঠানোর সঙ্গে সঙ্গে প্রতিটি অংশগ্রহণকারীর নিজের ভাষায় অনুবাদ হওয়া চাই। সঙ্গে এডিটও, আর এডিটকে দেখতে হবে এডিটের মতো, নতুন করে অনুবাদের মতো নয়।

বাজেট: দ্রুত, তবে এক সেকেন্ডের কম নয়। একটি চ্যাট বার্তা অন্য ভাষায় ফুটে উঠতে আধা সেকেন্ড লাগলে কেউ খেয়াল করে না। মানুষ খেয়াল করে অনুবাদটি সঠিক কি না এবং এডিটগুলো অর্থবহ কি না।

চ্যাট পাইপলাইন আসলে কী করে

প্রতিটি বার্তা সেই একই অনুবাদ ইঞ্জিনের মধ্য দিয়ে যায় যেটি ভয়েস পাইপলাইন ব্যবহার করে, তবে প্রি- ও পোস্ট-প্রসেসিং আলাদা:

• HTML কাঠামো সংরক্ষিত থাকে। চ্যাট রিচ টেক্সট সমর্থন করে (অনুচ্ছেদ, তালিকা, কোট, বোল্ড, ইটালিক)। আমরা মডেলের জন্য সাদা টেক্সটে রূপান্তর করি, অনুবাদ করি, তারপর ফলাফলটি আবার মূল ট্যাগে মুড়ে দিই। মডেল কখনো HTML দেখে না, সে দেখে পরিষ্কার গদ্য।
• কোট আলাদাভাবে অনুবাদ হয়। আপনি কোনো বার্তার উত্তর দিয়ে সেটি কোট করলে [QUOTE]…[/QUOTE] ব্লক এবং নতুন বিষয়বস্তু আলাদা একক হিসেবে অনুবাদ হয়, যাতে মডেল দুটিকে গুলিয়ে ফেলতে না পারে।
• দীর্ঘ বার্তা খণ্ডে ভাগ হয়। আমরা অনুচ্ছেদের সীমানায় প্রতি খণ্ডে 1,000 অক্ষরে ভাগ করি। প্রতিটি খণ্ড আলাদা অনুবাদ কল। আমরা 4,000 অক্ষরের "উপন্যাস" একবারে মডেলকে খাওয়াই না, কারণ ব্যর্থতার ধরনগুলো (ছেঁটে যাওয়া, হারিয়ে যাওয়া অনুচ্ছেদ, বাক্যের মাঝখানে কেটে যাওয়া) বড়ই কুৎসিত।
• অনুবাদ লেজি। আমরা IntersectionObserver ব্যবহার করি: কোনো বার্তা তখনই অনুবাদ হয় যখন সেটি দর্শকের ভিউপোর্টে স্ক্রল করে আসে। আগে দীর্ঘদিনের চ্যানেলে ভাষা বদলালে ইতিহাসের প্রতিটি অনুবাদ API কল আবার চলত। এখন আর চলে না।

মজার অংশ: ডিফ হিসেবে এডিট

v1.2-এ আমরা অন্য ভাষার দর্শকদের জন্য চ্যাট এডিটের আচরণ বদলেছি। আগের আচরণ ছিল: কেউ বার্তা এডিট করলে আমরা পুরোটা আবার অনুবাদ করতাম, আপনি একটি নতুন অনুচ্ছেদ দেখতেন এবং কী সরেছে তা নিজেকেই খুঁজে নিতে হতো।

নতুন আচরণ:

1. মূল বার্তাটি ইতিমধ্যেই আপনার ভাষায় অনুবাদ হয়ে আছে।
2. প্রেরক এডিট করলে আমরা নতুন সংস্করণটি আবার অনুবাদ করি।
3. আপনার ভাষায় আপনার আগের অনুবাদ এবং আপনার নতুন অনুবাদের মধ্যে ডিফ গণনা করি।
4. সেই ডিফ ইনলাইনে দেখাই, ঠিক যেভাবে Git দেখায় কী বদলেছে।

তাই ইংরেজিতে "review by Tuesday" যখন "review by Thursday" হয়ে যায়, আপনার স্প্যানিশ-পড়ুয়া সহকর্মী নতুন করে অনুবাদ হওয়া অনুচ্ছেদ আবার পড়ার বদলে হাইলাইট করা martes → jueves দেখেন।

এর জন্য চ্যাট পাইপলাইনকে প্রতি-দর্শকের স্টেটফুল ক্যাশ হিসেবে ভাবতে হয়েছে, অনুরোধ-মাফিক অনুবাদ করা স্টেটলেস এন্ডপয়েন্ট হিসেবে নয়। ডকুমেন্ট ও ভয়েসের এটি দরকার হয় না। চ্যাটের হয়।

পাইপলাইন 3: রিয়েল-টাইম শেয়ার্ড-নোটস অনুবাদ

সমস্যা: হোস্ট একটি শেয়ার্ড-নোটস প্যান খুলে টাইপ করতে শুরু করেন। প্রতিটি অংশগ্রহণকারী নোটগুলো নিজের ভাষায় দেখেন, অক্ষর ধরে ধরে, আর ডকুমেন্টের কাঠামো (শিরোনাম, নেস্টেড তালিকা, চেকলিস্ট, কোড ব্লক) অটুট থাকে।

বাজেট: চ্যাটের মতোই (~আধা সেকেন্ড), তবে দুটি বাড়তি শর্তসহ:

• অনুবাদ চলাকালেই অনুবাদ্য বিষয় বদলাচ্ছে। হোস্ট তখনও টাইপ করছেন। প্রতিটি কি-স্ট্রোকে "পুরো ডকুমেন্ট" অনুবাদ করা সরল ব্যবস্থা ঝিলিক তৈরি করে আর API বাজেট পুড়িয়ে ফেলে। আমরা অনুবাদ করি বদলে যাওয়া এককের স্তরে, পুরো ডকুমেন্টের নয়।
• কাঠামো টিকে থাকতে হবে। তিনটি নেস্টেড তালিকাসহ একটি মার্কডাউন ব্লব অনুবাদ করতে বললে আপনি এমন কিছু ফেরত পান যা মূলটির মতো দেখায়, কিন্তু শ্রেণিবিন্যাস সূক্ষ্মভাবে চ্যাপ্টা হয়ে গেছে, আইটেমের ক্রমিক নম্বর বদলেছে বা ইনডেন্টেশন সরে গেছে। আমরা মডেলকে পুরো ব্লব দেখতে দিই না।

নোটস পাইপলাইন চ্যাট থেকে কীভাবে আলাদা

কাঠামো সংরক্ষণই এখানে মূল ব্যাপার। আমরা প্রতিটি তালিকা আইটেম আলাদাভাবে অনুবাদ করি, একটি ডকুমেন্ট হিসেবে নয়। মডেল দেখে:

"Compliance review — Q2 deliverables"

এটি নয়:

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

আবরণী ডকুমেন্ট, অর্থাৎ <ul>, শিরোনাম ও ইনডেন্টেশন, ক্লায়েন্ট-সাইডে পুনর্গঠিত হয় মূল ডকুমেন্টের কাঠামো ব্যবহার করেই, প্রতিটি পাতা-নোড তার অনুবাদ দিয়ে বদলে। মডেল কখনো শ্রেণিবিন্যাসকে "উন্নত" করার সুযোগ পায় না।

নোটসও চ্যাট এডিটের মতো একই প্রতি-দর্শক ডিফ মডেল ব্যবহার করে: হোস্ট কোনো লাইন বদলালে অন্য ভাষার দর্শকেরা নতুন অনুচ্ছেদ নয়, বদলে যাওয়া শব্দগুলো হাইলাইট করা দেখেন।

পাইপলাইন 4: অ্যাসিনক্রোনাস ডকুমেন্ট অনুবাদ

সমস্যা: কেউ চ্যাটে 40 পৃষ্ঠার একটি PDF, Word ডক, PowerPoint ডেক বা Excel শিট ফেলে দেন। প্রতিটি অংশগ্রহণকারী নিজের ভাষায় একটি কপি চাইতে পারেন। অনুবাদিত ফাইলটি দেখতে মূলটির মতোই হতে হবে: একই ফন্ট, একই টেবিল, একই পৃষ্ঠা নম্বর, একই হেডার, চার্টগুলো একই জায়গায়।

বাজেট: রিয়েল-টাইমের কোনো বাধ্যবাধকতা নেই। এক মিনিট চলবে, দুই মিনিটও চলবে। শর্ত হলো বিশ্বস্ততা: অনুবাদিত PDF মূলটির মতো না দেখালে প্রাপক সেটিকে বিশ্বাস করবেন না।

কেন এই পাইপলাইন ভয়েসের সঙ্গে ইঞ্জিন ভাগ করে না

একটি সাধারণ LLM, যত ভালোই হোক, আপনাকে ডকুমেন্টের অনুবাদিত টেক্সট ফিরিয়ে দেবে। একই লেআউটসহ অনুবাদিত PDF সে ফিরিয়ে দেবে না। মডেলের কাছে "উৎসের সঙ্গে মিলিয়ে রাখতে হবে এমন পৃষ্ঠা-বিরতি" বা "কলামের প্রস্থ ধরে রাখতে হবে এমন টেবিল সেল"-এর কোনো ধারণাই নেই।

এই সারফেসের জন্য আমরা সরাসরি DeepL Document API ব্যবহার করি। এটি বিশেষভাবে বানানো ফাইলকে ফাইল হিসেবে অনুবাদের জন্য, ফাইল থেকে বের করা গদ্য অনুবাদের জন্য নয়। DeepL সামলায়:

• PDF (লেআউট সংরক্ষণসহ)
• DOCX, DOC
• PPTX
• XLSX

ডকুমেন্টটি DeepL-এর পাইপলাইনে আপলোড হয়, সার্ভার-সাইডে ফরম্যাটিং অক্ষুণ্ণ রেখে অনুবাদ হয় এবং একই ফরম্যাটে ফেরত আসে। এরপর আমরা ফলাফলটি আমাদের অবজেক্ট স্টোরেজে আপলোড করি এবং চ্যাটে ডাউনলোডযোগ্য সংযুক্তি হিসেবে ফিরিয়ে আনি।

এর খরচ কত, এবং কেন আমরা তা লুকাই না

DeepL প্রতি ডকুমেন্টে ন্যূনতম 50,000 অক্ষরের বিল করে। Pro টিয়ারে তা ফাইলপ্রতি প্রায় এক মার্কিন ডলার, ডকুমেন্টটি এক পৃষ্ঠার হোক বা ত্রিশ পৃষ্ঠার। আমরা ফাইলপ্রতি চার্জ না করে এই খরচ নিজেরা বহন করি। এটি মিটিংয়ের অনুবাদ ব্যবহারে বিলড ক্যারেক্টার হিসেবে দেখা যায়, যা শব্দ-ইউনিটে রূপান্তরিত হয় যাতে পণ্যের বাকি অংশ অনুবাদ কার্যকলাপ যেভাবে রিপোর্ট করে, তার সঙ্গে মেলে।

এই সারফেসের জন্য আমরা DeepL বেছে নিয়েছি, কারণ ফাইলকে ফাইল হিসেবে অনুবাদ করাই ঠিক সেই কাজ যার জন্য এটি বানানো। আমরা এর চেয়ে ভালো কিছু বানানোর চেষ্টা করিনি। উল্টো দিকে কথাটা খাটে না: মিটিংয়ের জন্য আমরা যে ধরনের লাইভ-ভয়েস পাইপলাইন বানিয়েছি, DeepL তা চালায় না। সমস্যা আলাদা, টুলও আলাদা। "InterMIND-এর অনুবাদ কীসে চলে" প্রশ্নের সৎ উত্তর হলো "প্রতিটি পাইপলাইনের জন্য সঠিক ইঞ্জিন", "সবখানে আমাদের ইঞ্জিন" নয়।

যেসব ভাষা এই পাইপলাইন কভার করে কিন্তু ভয়েস করে না

ডকুমেন্ট পাইপলাইন পৌঁছায় 30টি ভাষায়, ভয়েসের 23-এর বিপরীতে। বাড়তি ভাষাগুলোর মধ্যে আছে: বুলগেরিয়ান, গ্রিক, এস্তোনিয়ান, ইন্দোনেশিয়ান, লিথুয়ানিয়ান, লাটভিয়ান, স্লোভাক, স্লোভেনিয়ান। (আরবিও এই তালিকায় আছে এবং বাড়তি ভাষাগুলোর একটি: ভয়েসের মান আমাদের মানদণ্ডের নিচে থাকায় এটি রিয়েল-টাইম পিকার থেকে সরানো হয়েছে, আর এর প্রতি-জোড়া স্কোর /benchmark-এ প্রকাশ্যই থাকে। সেই সংখ্যাটিই একে ফিরিয়ে আনবে। হিন্দির ক্ষেত্রে অসামঞ্জস্যটি উল্টো দিকে: ভয়েসে চালু, ফাইলে এখনো নয়।)

এই অসামঞ্জস্য বাস্তব। এর মানে একজন ফরাসি অংশগ্রহণকারী মিটিংটি এস্তোনিয়ান ভাষায় শুনতে না পারলেও চুক্তির PDF এস্তোনিয়ান ভাষায় চাইতে পারেন। আমরা এটি একটি মাত্র সংখ্যা দিয়ে মসৃণ না করে পিকারে চিহ্নিত করে দিই। যুক্তিটি আছে ভাষা-সংখ্যা নিয়ে লেখায়।

যেখানে পাইপলাইনগুলো মেলে

চারটি পাইপলাইন বিচ্ছিন্নভাবে চলে না। মিটিং রুম হলো সেই জায়গা যেখানে এরা একে অপরকে স্পর্শ করে, আর জোড়গুলো গুরুত্বপূর্ণ:

• ডকুমেন্ট সংযুক্তিসহ একটি চ্যাট বার্তা টেক্সটের জন্য চ্যাট পাইপলাইন এবং ফাইলের জন্য ডকুমেন্ট পাইপলাইন চালু করে। অন্য ভাষার অংশগ্রহণকারী বার্তাটি সঙ্গে সঙ্গে অনুবাদিত দেখেন, আর সংযুক্তির অনুবাদ অ্যাসিনক্রোনাসভাবে ডাউনলোডযোগ্য ফাইল হিসেবে এসে পৌঁছায়।
• ট্রান্সক্রিপ্টের কোনো লাইন কোট করা শেয়ার্ড নোট নোটস ↔ ভয়েস সীমানা পার করে। ট্রান্সক্রিপ্ট হলো প্রেরকের ভাষায় ভয়েস পাইপলাইন যা তৈরি করেছে; নোটের অনুবাদ বাকি সবার ভাষায় ওই কোটের একটি প্রতি-দর্শক কপি তৈরি করে, উৎস উল্লেখ অক্ষুণ্ণ রেখে।
• মিটিংয়ের পরে এক্সপোর্ট করা ট্রান্সক্রিপ্ট পুরো কথোপকথনের ওপর চ্যাট-স্টাইল টেক্সট পাইপলাইন চালায় এবং প্রতিটি ভাষার জন্য একটি করে ফাইল তৈরি করে, যা অংশগ্রহণকারীরা ডাউনলোড করতে পারেন। এটি চ্যাট অনুবাদেরই একই কোড পাথ, শুধু ব্যাচ করে চালানো।

ভাষা পিকার ইউআইয়ের একটি অংশ। এর নিচের অবকাঠামো চারটি পাইপলাইন, যারা পরস্পরের সঙ্গে কথা বলে।

যা আমরা ইচ্ছাকৃতভাবেই চেষ্টা করি না

• কোনো "ইউনিফায়েড অনুবাদ মডেল" নেই। আমরা এমন একটি মডেল বানাচ্ছি না যা ভয়েস, চ্যাট, নোটস ও ডকুমেন্ট সবই করে। লেটেন্সি বনাম বিশ্বস্ততার এই দ্বন্দ্বে কোনো বিজয়ী নেই। আমরা প্রতিটি সারফেসের জন্য সঠিক ইঞ্জিন ব্যবহার করি।
• কোনো নীরব রিরুটিং নেই। ফাইল পাইপলাইন আজ হিন্দিতে অনুবাদ করতে না পারলে আমরা চুপচাপ ভয়েস ইঞ্জিনে ফিরে গিয়ে কাজ হয়েছে বলে ভান করি না। ফাইল পিকার ফাঁকটি লুকিয়ে না রেখে চিহ্নিত করে দেয়।
• "আমরা 200 ভাষায় অনুবাদ করি" জাতীয় দাবি নেই। আমাদের ইঞ্জিন 24টি ভাষা দেয়। লাইভ সারফেসে 23টি, ডকুমেন্টে 30টি। আর বিপণনবান্ধব একটি সংখ্যার বদলে, নিরীক্ষকের সামনে যে প্রতি-জোড়া মান দাঁড়াতে হবে তা /benchmark-এ প্রকাশিত, দুর্বলতর জোড়াগুলোসহ।

নিজে চেষ্টা করে দেখুন

• লাইভ ডেমো চেষ্টা করুন — আপনার অডিওর ওপর লাইভ ভয়েস পাইপলাইন চালায়, পণ্যের 23টি ভাষার যেকোনোটিতে। এটি সেই একই পাইপলাইন যা /benchmark-এ স্কোর করা হয়।
• বেঞ্চমার্ক দেখুন — বাস্তব ট্রাফিকে প্রতি-জোড়া, প্রতি-মাসের মান। পিকারের প্রতিটি জোড়া, শক্ত হোক বা দুর্বল, সরাসরি লিংক করা যায়।
• পদ্ধতি পড়ুন — সংখ্যাগুলো কী, কী নয়, আর বিচারক কে।

চারটি পাইপলাইন, চারটি ইঞ্জিন, একটি মিটিং রুম। পুরোনো how-it-works পৃষ্ঠার এটাই সৎ প্রতিস্থাপন।

— Mind.com টিম

সূত্র: DeepL — supported languages, DeepL — usage count and billing (ফাইলপ্রতি 50,000 অক্ষরের ন্যূনতম সীমা), FLORES-200; অভ্যন্তরীণ পাইপলাইন তথ্য শিপ করা কোডের সঙ্গে যাচাই করা, আগস্ট 2026-এ পরীক্ষিত।