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 एस्टोनियाई में माँग सकता है, भले ही वह मीटिंग को एस्टोनियाई में सुन नहीं सकता। हम इसे एक ही संख्या के पीछे छिपाने के बजाय पिकर में चिह्नित करते हैं। इसका तर्क भाषा-गणना वाले लेख में है।

जहाँ पाइपलाइनें मिलती हैं

चारों पाइपलाइनें अलग-थलग नहीं चलतीं। मीटिंग रूम वह जगह है जहाँ वे एक-दूसरे को छूती हैं, और ये जोड़ मायने रखते हैं:

• दस्तावेज़ अटैचमेंट वाला चैट संदेश टेक्स्ट के लिए चैट पाइपलाइन और फ़ाइल के लिए दस्तावेज़ पाइपलाइन चलाता है। दूसरी भाषा का प्रतिभागी संदेश को तुरंत अनुवादित देखता है, और अटैचमेंट का अनुवाद बाद में डाउनलोड योग्य फ़ाइल के रूप में आता है।
• ट्रांसक्रिप्ट की किसी पंक्ति को कोट करने वाला शेयर्ड नोट नोट्स ↔ वॉइस को पार करता है। ट्रांसक्रिप्ट वही है जो वॉइस पाइपलाइन ने भेजने वाले की भाषा के लिए बनाया। नोट का अनुवाद उस कोट की प्रति-दर्शक प्रति बाकी सबकी भाषा में बनाता है, और उसका स्रोत-उल्लेख सुरक्षित रहता है।
• मीटिंग के बाद एक्सपोर्ट किया गया ट्रांसक्रिप्ट पूरी बातचीत पर चैट-शैली की टेक्स्ट पाइपलाइन चलाता है और प्रति-भाषा फ़ाइल बनाता है जिसे प्रतिभागी डाउनलोड कर सकते हैं। यह वही कोड पाथ है जो चैट ट्रांसलेशन का है, बस बैच में।

भाषा पिकर UI का एक ही हिस्सा है। उसके नीचे का इंफ्रास्ट्रक्चर चार पाइपलाइनें हैं जो आपस में बात करती हैं।

हम जानबूझकर क्या नहीं आज़माते

• कोई "एकीकृत ट्रांसलेशन मॉडल" नहीं। हम ऐसा एक मॉडल नहीं बना रहे जो वॉइस, चैट, नोट्स और दस्तावेज़, सब करे। लेटेंसी बनाम फ़िडेलिटी के समझौते में कोई स्पष्ट विजेता नहीं है। हम हर सर्फ़ेस के लिए सही इंजन इस्तेमाल करते हैं।
• कोई चुपचाप री-रूटिंग नहीं। अगर फ़ाइल पाइपलाइन आज हिंदी में अनुवाद नहीं कर सकती, तो हम चुपचाप वॉइस इंजन पर नहीं लौट जाते और दिखावा नहीं करते कि यह काम कर गया। फ़ाइल पिकर कमी को छिपाने के बजाय चिह्नित करता है।
• कोई "हम 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 में जाँचे गए।