เจาะลึกสี่ไปป์ไลน์การแปลที่ขับเคลื่อน InterMIND

หน้า /product/overview/how-it-works เดิมบน mind.com ล้าหลังไปหลายเวอร์ชันหลักแล้ว หน้านั้นอธิบาย "เอนจินแปลภาษา" ตัวเดียวแบบที่หน้าเว็บของผู้ให้บริการส่วนใหญ่ทำกัน คือมีลูกศรใหญ่เส้นเดียวจาก "คุณพูด" ไปยัง "พวกเขาได้ยิน" ภาพนั้นเป็นการทำให้ง่ายเกินจริงมาตั้งแต่สองปีก่อน และวันนี้ก็ไม่ถูกต้องอีกต่อไป

ความจริงคือ InterMIND ทำงานด้วย ไปป์ไลน์การแปลสี่ตัวที่แยกจากกัน แต่ละตัวแก้ปัญหาต่างกัน ใช้เอนจินต่างกัน มีงบเวลาแฝง (latency) ต่างกัน และมีขอบเขตคุณภาพต่างกัน ทั้งสี่ตัวใช้ตัวเลือกภาษาร่วมกัน แต่ไม่ได้ใช้เอนจินร่วมกัน

บทความนี้คือคำตอบฉบับอัปเดตสำหรับคำถามที่ว่า "ระบบทำงานอย่างไร"

บทความคู่กัน: "InterMIND รองรับกี่ภาษา?" อธิบายว่าแต่ละไปป์ไลน์ รองรับ ภาษาอะไรบ้าง (23 / 23 / 30 / 17) ส่วนบทความนี้อธิบายว่าแต่ละไปป์ไลน์ ทำอะไร และทำไมจึงต้องแยกเป็นอีกส่วนหนึ่งต่างหาก

ทำไม "เอนจินเดียวทำได้ทุกอย่าง" จึงเป็นเรื่องหลอกลวง

แพลตฟอร์มการประชุมสดต้องทำอย่างน้อยสี่งานพร้อมกัน และแต่ละงานดึงไปคนละทิศทาง

1. เสียงแบบเรียลไทม์ — รับเสียงเข้า ส่งเสียงที่แปลแล้วออก ภายในหนึ่งวินาที ให้ผู้ชมทุกคนได้ยินในภาษาของตนเอง ข้อจำกัดสำคัญคือเวลาแฝง
2. ข้อความแชตแบบเรียลไทม์ — ข้อความสั้น ส่งเร็ว โดยต้องรักษาการแก้ไข การอ้างอิง และโครงสร้าง HTML ไว้
3. บันทึกที่ใช้ร่วมกันแบบเรียลไทม์ — การพิมพ์ร่วมกันทีละตัวอักษร พร้อมโครงสร้างลำดับชั้น (รายการ หัวข้อ ช่องทำเครื่องหมาย) ที่ต้องคงอยู่ครบหลังการแปล
4. ไฟล์เอกสารแบบอะซิงโครนัส — ไฟล์ PDF 40 หน้าที่ส่งเข้าแชต ไม่มีงบเวลาแฝง ข้อจำกัดสำคัญคือ ความเที่ยงตรง ของรูปแบบ ตาราง เลขหน้า และฟอนต์

คุณสร้างการเรียก LLM ก้อนใหญ่ครั้งเดียวเพื่อทำทั้งสี่อย่างได้ เราเคยลองแล้ว และผลคือแย่ทั้งสี่อย่าง งบเวลาแฝงของเสียงหมายความว่าโมเดลไม่มีเวลาคิด ส่วนงบความเที่ยงตรงของเอกสารหมายความว่าโมเดลจำเป็นต้องคิด การแก้ไขข้อความแชตต้องการ diff ในภาษาของผู้ชม ส่วน PDF 40 หน้าต้องการการรักษารูปแบบที่โมเดลแบบสตรีมโทเค็นไม่สามารถให้ได้

เราจึงใช้สี่ไปป์ไลน์ ต่อไปนี้คือแต่ละตัว

ไปป์ไลน์ที่ 1: การแปลเสียงแบบเรียลไทม์

ปัญหา: ผู้เข้าร่วมคนหนึ่งพูดภาษาฝรั่งเศส อีกคนเข้าร่วมด้วยภาษาเยอรมัน คนที่สามด้วยภาษาโปรตุเกสแบบบราซิล และคนที่สี่ด้วยภาษาญี่ปุ่น ทุกคนต้องได้ยินผู้พูดในภาษาของตนเอง ในหูของตนเอง โดยมีความหน่วงสั้นพอที่จะยังสบตากันได้

งบเวลา: ไม่ถึงหนึ่งวินาทีตลอดเส้นทาง หากเกินราว 1.2 วินาที การสนทนาจะสะดุด ผู้คนเริ่มพูดทับเสียงแปล และการประชุมก็เริ่มเอนไปทาง "เปลี่ยนไปใช้ภาษาอังกฤษกันเถอะ"

เสียงเดินทางอย่างไรจริงๆ

มีหลายจุดที่ควรบอกให้ชัดเจน

• ASR ทำงานบนมีเดียเซิร์ฟเวอร์ เสียงของผู้พูดเดินทางผ่าน WebRTC ไปยังเอนจินของเราเอง คือ Mind API ที่ OVH ประเทศฝรั่งเศส และถูกรู้จำเสียงที่นั่น บนเซิร์ฟเวอร์เดียวกับที่รับสายสนทนา เบราว์เซอร์ทำหน้าที่ส่งเสียงและรับคำกลับมาเท่านั้น ไม่มีผู้ให้บริการด้านเสียงแยกต่างหาก และไม่มีการส่งต่อเพิ่มก่อนที่การแปลจะเริ่มได้ (ข้อยกเว้นคือข้อความเสียงในแชต ซึ่งการแปลงเสียงเป็นข้อความทำงานบน Azure AI Speech ซึ่งเป็นบริการเสียงของ AI gateway เริ่มต้น)
• การแปลไม่ใช่การกระจายออกทีเดียว เอนจินแปล ตามภาษาปลายทางที่มีอยู่ในห้อง ไม่ใช่ตามผู้ชมแต่ละคน การแปลเป็นภาษาหนึ่งจะเริ่มเมื่อผู้ฟังคนแรกในภาษานั้นขอสตรีมที่แปลแล้ว ผู้เข้าร่วมสามคนที่เลือกภาษาเยอรมันใช้คำแปลภาษาเยอรมันชุดเดียวกัน และหากไม่มีใครฟังเป็นภาษาอาหรับ ก็จะไม่มีการแปลเป็นภาษาอาหรับเลย นี่คือเหตุผลที่การประชุมสี่ภาษามีต้นทุนเท่ากับการประชุมสี่สิบภาษา ในขอบเขตของภาษาที่มีผู้เข้าร่วมจริงๆ เราไม่เคยแปลเป็นภาษาที่ไม่มีผู้เข้าร่วมฟังอยู่
• เสียงสังเคราะห์เป็นรายผู้ชม ผู้เข้าร่วมแต่ละคนได้รับแทร็กเสียงที่แปลแล้วของตนเอง ผสมเข้ากับวิดีโอของผู้พูดต้นฉบับ พวกเขาไม่ได้ดู "การประชุมฉบับแปล" ฉบับเดียว แต่ดู การประชุมเดียวกัน โดยช่องเสียงส่วนตัวของแต่ละคนถูกแปลเป็นภาษาที่เลือก นี่คือเหตุผลที่คนสองคนในห้องจริงห้องเดียวกันสามารถเสียบหูฟังและได้ยินคนละภาษาได้

ทำไมเรื่องนี้สำคัญเมื่อการประชุมเริ่มมีปัญหา

ในการประชุม 60 นาทีที่มีแปดภาษา เหตุขัดข้องเกิดได้หลายแบบ เช่น WebSocket หลุด ASR ถอดเสียงคำนามเฉพาะผิดชั่วคราว หรือเครือข่ายของผู้เข้าร่วมคนหนึ่งสั่นไหว สถาปัตยกรรมข้างต้นช่วยให้เราแยกความล้มเหลวออกจากกันได้ เสียงของผู้ชมคนหนึ่งสะดุดก็ไม่กระทบอีกเจ็ดคน เพราะเอนจินแปลไม่เคยสร้าง "คำแปล" เพียงชุดเดียวตั้งแต่แรก แต่สร้างแปดชุดแบบขนาน และมีเพียงชุดที่ได้รับผลกระทบเท่านั้นที่ต้องกู้คืน

เอนจินนี้เป็นของเราเอง โฮสต์บนโครงสร้างพื้นฐานของเราเอง เราไม่ส่งเสียงแบบเรียลไทม์ผ่าน LLM อเนกประสงค์ของบุคคลที่สาม งบเวลาแฝงตัดตัวเลือกเหล่านั้นออกไป และเรื่องถิ่นที่อยู่ของข้อมูล (data residency) ก็ตัดออกไปสำหรับลูกค้าในอุตสาหกรรมที่มีการกำกับดูแลซึ่งใส่ใจเรื่องนี้จริงๆ

สิ่งที่เราเผยแพร่เกี่ยวกับคุณภาพเสียง: /benchmark รันไปป์ไลน์เสียงที่ใช้งานจริงกับประโยคจาก FLORES-200 สำหรับทุกคู่ภาษาที่เผยแพร่ ทุกเดือน ผู้ตัดสินระบุชื่อชัดเจน (Gemini 3.7 Flash เป็นตัวหลัก, Claude Sonnet 5 เป็นตัวสำรอง) การกระจายทั้งหมด ได้แก่ ค่ามัธยฐาน p10 p90 ค่าต่ำสุด ค่าสูงสุด และขนาดตัวอย่าง อยู่ในหน้านั้น ดูวิธีวิทยาเพื่อทำความเข้าใจว่าตัวเลขเหล่านั้นวัดอะไรและไม่ได้วัดอะไร

ไปป์ไลน์ที่ 2: การแปลแชตแบบเรียลไทม์

ปัญหา: ทุกข้อความแชตในการประชุมต้องถูกแปลให้ผู้เข้าร่วมทุกคนในภาษาของตนเองทันทีที่ส่ง รวมถึงการแก้ไขข้อความ ซึ่งต้องดูเป็นการแก้ไข ไม่ใช่การแปลใหม่ทั้งหมด

งบเวลา: เร็ว แต่ไม่ต้องถึงระดับต่ำกว่าหนึ่งวินาที ข้อความแชตใช้เวลาครึ่งวินาทีกว่าจะปรากฏในอีกภาษาหนึ่งโดยไม่มีใครสนใจ สิ่งที่ผู้คนสนใจคือคำแปล ถูกต้อง หรือไม่ และการแก้ไขสมเหตุสมผลหรือไม่

ไปป์ไลน์แชตทำอะไรจริงๆ

ทุกข้อความผ่านเอนจินแปลตัวเดียวกับที่ไปป์ไลน์เสียงใช้ แต่มีการประมวลผลก่อนและหลังที่ต่างกัน

• รักษาโครงสร้าง HTML แชตรองรับริชเท็กซ์ (ย่อหน้า รายการ การอ้างอิง ตัวหนา ตัวเอียง) เราแปลงเป็นข้อความธรรมดาให้โมเดล แปล แล้วห่อผลลัพธ์กลับด้วยแท็กเดิม โมเดลไม่เคยเห็น HTML เห็นเพียงข้อความร้อยแก้วที่สะอาด
• แปลการอ้างอิงแยกต่างหาก หากคุณตอบข้อความและอ้างอิงข้อความนั้น บล็อก [QUOTE]…[/QUOTE] กับเนื้อหาใหม่จะถูกแปลเป็นหน่วยแยกกัน เพื่อไม่ให้โมเดลสับสนระหว่างสองส่วนนี้
• ข้อความยาวถูกแบ่งเป็นช่วง เราแบ่งตามขอบเขตย่อหน้าที่ 1,000 ตัวอักษรต่อช่วง แต่ละช่วงเป็นการเรียกแปลของตัวเอง เราจะ ไม่ ป้อนข้อความยาว 4,000 ตัวอักษรให้โมเดลในครั้งเดียว เพราะความล้มเหลวที่อาจเกิดขึ้น (ข้อความถูกตัด ย่อหน้าหาย ประโยคขาดกลางคัน) แย่เกินไป
• การแปลเป็นแบบ lazy เราใช้ IntersectionObserver โดยข้อความจะถูกแปลก็ต่อเมื่อเลื่อนเข้ามาในวิวพอร์ตของผู้ชมเท่านั้น เดิมการสลับภาษาในช่องที่ใช้งานมานานจะเรียก API แปลซ้ำทุกครั้งสำหรับประวัติทั้งหมด ตอนนี้ไม่เป็นเช่นนั้นแล้ว

ส่วนที่น่าสนใจ: การแก้ไขในรูปแบบ diff

ใน v1.2 เราเปลี่ยนพฤติกรรมการแก้ไขแชตสำหรับผู้ชมที่ใช้อีกภาษาหนึ่ง พฤติกรรมเดิมคือเมื่อมีคนแก้ไขข้อความ เราจะแปลใหม่ทั้งข้อความ คุณเห็นย่อหน้าใหม่และต้องหาเองว่าตรงไหนเปลี่ยน

พฤติกรรมใหม่:

1. ข้อความต้นฉบับถูกแปลเป็นภาษาของคุณไว้แล้ว
2. เมื่อผู้ส่งแก้ไข เราแปลเวอร์ชัน ใหม่ อีกครั้ง
3. เราคำนวณ diff ระหว่าง คำแปลก่อนหน้าของคุณ กับ คำแปลใหม่ของคุณ ในภาษาของคุณ
4. เราแสดง diff นั้นแบบอินไลน์ เหมือนที่ Git แสดงสิ่งที่เปลี่ยนไป

ดังนั้นเมื่อ "review by Tuesday" กลายเป็น "review by Thursday" ในภาษาอังกฤษ เพื่อนร่วมงานของคุณที่อ่านภาษาสเปนจะเห็น martes → jueves ถูกไฮไลต์ ไม่ใช่ย่อหน้าที่แปลใหม่ซึ่งต้องอ่านซ้ำทั้งหมด

เรื่องนี้ทำให้เราต้องมองไปป์ไลน์แชตเป็นแคช แบบมีสถานะ รายผู้ชม ไม่ใช่เอนด์พอยต์แปลตามคำขอแบบไม่มีสถานะ เอกสารและเสียงไม่ต้องการสิ่งนี้ แต่แชตต้องการ

ไปป์ไลน์ที่ 3: การแปลบันทึกที่ใช้ร่วมกันแบบเรียลไทม์

ปัญหา: โฮสต์เปิดแผงบันทึกที่ใช้ร่วมกันและเริ่มพิมพ์ ผู้เข้าร่วมทุกคนเห็นบันทึกในภาษาของตนเองทีละตัวอักษร โดยโครงสร้างของเอกสาร ทั้งหัวข้อ รายการซ้อน เช็กลิสต์ และบล็อกโค้ด ยังคงครบถ้วน

งบเวลา: เท่ากับแชต (ราวครึ่งวินาที) แต่มีข้อจำกัดเพิ่มอีกสองข้อ

• สิ่งที่กำลังแปลเปลี่ยนไปกลางคัน โฮสต์ยังคงพิมพ์อยู่ ระบบแบบตรงไปตรงมาที่แปล "ทั้งเอกสาร" ทุกครั้งที่กดแป้นจะทำให้เกิดอาการกะพริบและเผางบ API เราจึงแปลในระดับ หน่วยที่เปลี่ยนแปลง ไม่ใช่ทั้งเอกสาร
• โครงสร้างต้องคงอยู่ หากคุณให้โมเดลแปลก้อน markdown ที่มีรายการซ้อนสามชั้น คุณจะได้สิ่งที่ ดูเหมือน ต้นฉบับ แต่ลำดับชั้นถูกทำให้แบนลงเล็กน้อย รายการถูกเรียงเลขใหม่ หรือการเยื้องย้ายที่ เราจึงไม่ให้โมเดลเห็นก้อนทั้งหมด

ไปป์ไลน์บันทึกต่างจากแชตอย่างไร

เรื่องหลักคือการรักษาโครงสร้าง เราแปล แต่ละรายการแยกกัน แทนที่จะแปลเป็นเอกสารเดียว โมเดลเห็นว่า:

"Compliance review — Q2 deliverables"

— ไม่ใช่:

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

เอกสารที่ห่อหุ้มอยู่ ทั้ง <ul> หัวข้อ และการเยื้อง ถูกสร้างขึ้นใหม่ฝั่งไคลเอนต์โดยใช้โครงสร้างเดียวกับเอกสารต้นฉบับ แล้วสลับแต่ละโหนดใบด้วยคำแปลของมัน โมเดลไม่มีโอกาส "ปรับปรุง" ลำดับชั้นเลย

บันทึกยังใช้โมเดล diff รายผู้ชมแบบเดียวกับการแก้ไขแชตด้วย หากโฮสต์เปลี่ยนบรรทัดหนึ่ง ผู้ชมในภาษาอื่นจะเห็นคำที่เปลี่ยนถูกไฮไลต์ ไม่ใช่ย่อหน้าใหม่

ไปป์ไลน์ที่ 4: การแปลเอกสารแบบอะซิงโครนัส

ปัญหา: มีคนส่ง PDF 40 หน้า เอกสาร Word สไลด์ PowerPoint หรือชีต Excel เข้าแชต ผู้เข้าร่วมแต่ละคนขอสำเนาในภาษาของตนเองได้ ไฟล์ที่แปลแล้วต้องดูเหมือนต้นฉบับ คือฟอนต์เดียวกัน ตารางเดียวกัน เลขหน้าเดียวกัน ส่วนหัวเดียวกัน และแผนภูมิอยู่ที่เดิม

งบเวลา: ไม่มีข้อจำกัดแบบเรียลไทม์ หนึ่งนาทีก็ได้ สองนาทีก็ได้ ข้อจำกัดคือ ความเที่ยงตรง หาก PDF ที่แปลแล้วดูไม่เหมือนต้นฉบับ ผู้รับก็จะไม่เชื่อถือ

ทำไมไปป์ไลน์นี้จึงไม่ใช้เอนจินร่วมกับเสียง

LLM ทั่วไป ต่อให้เก่งมาก ก็ส่งคืนได้เพียง ข้อความ ที่แปลแล้วของเอกสาร ไม่ใช่ PDF ที่แปลแล้วพร้อมเลย์เอาต์เดิม โมเดลไม่มีแนวคิดเรื่อง "การขึ้นหน้าใหม่ที่ต้องตรงกับต้นฉบับ" หรือ "เซลล์ตารางที่ต้องคงความกว้างคอลัมน์"

สำหรับส่วนนี้ เราใช้ DeepL Document API โดยตรง ซึ่งสร้างมาเพื่อแปล ไฟล์ในฐานะไฟล์ ไม่ใช่ ข้อความร้อยแก้วที่ดึงออกมาจากไฟล์ DeepL รองรับ:

• PDF (พร้อมรักษาเลย์เอาต์)
• DOCX, DOC
• PPTX
• XLSX

เอกสารจะถูกอัปโหลดไปยังไปป์ไลน์ของ DeepL แปลฝั่งเซิร์ฟเวอร์โดยคงรูปแบบไว้ครบ และส่งกลับมาในรูปแบบเดิม จากนั้นเราอัปโหลดผลลัพธ์ไปยังที่เก็บอ็อบเจกต์ของเรา และแสดงกลับในแชตเป็นไฟล์แนบที่ดาวน์โหลดได้

ต้นทุนเท่าไรและทำไมเราไม่ซ่อนเรื่องนี้

DeepL คิดค่าบริการขั้นต่ำ 50,000 ตัวอักษรต่อเอกสาร ประมาณหนึ่งดอลลาร์สหรัฐต่อไฟล์ในระดับ Pro ไม่ว่าเอกสารจะมีหนึ่งหน้าหรือสามสิบหน้า เรารับต้นทุนนี้เองแทนการเรียกเก็บต่อไฟล์ โดยจะปรากฏในการใช้งานการแปลของการประชุมเป็น billed characters ซึ่งแปลงเป็นหน่วยคำให้ตรงกับวิธีที่ส่วนอื่นของผลิตภัณฑ์รายงานกิจกรรมการแปล

เราเลือก 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