מבט מבפנים על ארבעת צינורות התרגום שמפעילים את InterMIND

הדף הישן /product/overview/how-it-works ב-mind.com מיושן בכמה גרסאות מרכזיות. הוא מתאר "מנוע תרגום" יחיד, כמו רוב דפי הספקים: חץ גדול אחד מ"אתם מדברים" אל "הם שומעים". כבר לפני שנתיים התמונה הזו הייתה פישוט. כיום היא פשוט שגויה.

האמת היא ש-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 המוגדר כברירת מחדל.)
• התרגום אינו פיזור יחיד. המנוע מתרגם לפי שפת יעד הנמצאת בחדר, לא לפי צופה: התרגום לשפה מתחיל כשהמאזין הראשון בה מבקש זרם מתורגם, שלושה משתתפים שבחרו גרמנית חולקים תרגום גרמני אחד, ואם אף אחד לא מאזין בערבית, שום דבר לא מתורגם לערבית. לכן פגישה בארבע שפות עולה אותו דבר כמו פגישה בארבעים שפות, עד כדי מי שהגיע בפועל: אנחנו אף פעם לא מתרגמים לשפות שאף משתתף לא מאזין בהן.
• הדיבור המסונתז הוא לכל צופה. כל משתתף מקבל רצועת אודיו מתורגמת משלו, מעורבבת מול הווידאו של הדובר המקורי. הוא לא צופה ב"פגישה מתורגמת" מאסטר, אלא באותה פגישה, כשערוץ האודיו האישי שלו מתורגם לשפה שבחר. לכן שני אנשים באותו חדר פיזי יכולים לחבר אוזניות ולשמוע שפות שונות.

למה זה חשוב כשפגישה יוצאת משליטה

בשיחה של 60 דקות בשמונה שפות דברים נשברים בדרכים מעניינות: WebSockets מתנתקים, ה-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 לתרגום מההיסטוריה. עכשיו כבר לא.

החלק המעניין: עריכות כ-diff

בגרסה 1.2 שינינו את התנהגות עריכות הצ'אט עבור צופים בשפה אחרת. ההתנהגות הישנה הייתה: מישהו עורך הודעה, אנחנו מתרגמים מחדש את כולה, ואתם רואים פסקה חדשה וצריכים לגלות מה השתנה.

ההתנהגות החדשה:

1. ההודעה המקורית כבר תורגמה לשפתכם.
2. כשהשולח עורך, אנחנו מתרגמים מחדש את הגרסה החדשה.
3. אנחנו מחשבים את ה-diff בין התרגום הקודם שלכם לתרגום החדש שלכם, בשפתכם.
4. אנחנו מציגים את ה-diff בתוך הטקסט, באותו אופן שבו Git מראה מה השתנה.

כך, כש-"review by Tuesday" הופך ל-"review by Thursday" באנגלית, עמיתכם הקורא ספרדית רואה martes → jueves מודגש, ולא פסקה מתורגמת מחדש שהוא צריך לקרוא שוב.

זה דרש להתייחס לצינור הצ'אט כאל מטמון עם מצב לכל צופה, ולא כנקודת קצה חסרת מצב שמתרגמת לפי בקשה. מסמכים וקול לא צריכים את זה. צ'אט כן.

צינור 3: תרגום הערות משותפות בזמן אמת

הבעיה: המארח פותח חלונית הערות משותפות ומתחיל להקליד. כל משתתף רואה את ההערות בשפתו, תו אחר תו, כשמבנה המסמך — כותרות, רשימות מקוננות, רשימות סימון, בלוקי קוד — נשאר שלם.

התקציב: כמו בצ'אט (כחצי שנייה), אבל עם שני אילוצים נוספים:

• הדבר המתורגם משתנה תוך כדי התרגום. המארח עדיין מקליד. מערכת נאיבית שמתרגמת את "כל המסמך" בכל הקשה יוצרת הבהובים וצורכת את תקציב ה-API. אנחנו מתרגמים ברמת היחידה ששונתה, לא ברמת המסמך כולו.
• המבנה חייב לשרוד. אם מבקשים ממודל תרגום לתרגם גוש markdown עם שלוש רשימות מקוננות, מקבלים משהו שנראה כמו המקור אבל עם היררכיה שטוחה בעדינות, פריטים ממוספרים מחדש או הזחה שזזה. אנחנו לא נותנים למודל לראות את הגוש כולו.

במה צינור ההערות שונה מהצ'אט

שימור המבנה הוא העיקר. אנחנו מתרגמים כל פריט ברשימה בנפרד ולא כמסמך אחד. המודל רואה:

"סקירת ציות — תוצרי Q2"

ולא:

"# תוכנית פרויקט\n## רבעון\n- סקירת ציות — תוצרי Q2\n- דירוג ספקים\n - ספקי דרג 1..."

המסמך העוטף — ה-<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, בלי קשר לשאלה אם המסמך הוא עמוד אחד או שלושים. אנחנו סופגים את העלות הזו במקום לגבות לפי קובץ. היא מופיעה בשימוש התרגום של הפגישה כתווים מחויבים, מומרים ליחידות מילים שתואמות את האופן שבו שאר המוצר מדווח על פעילות תרגום.

בחרנו ב-DeepL עבור המשטח הזה כי תרגום קבצים כקבצים הוא בדיוק מה שהיא נבנתה לעשות, ולא ניסינו לבנות משהו טוב ממנה. ההפך אינו נכון: DeepL לא מפעילה צינור קול חי מהסוג שבנינו לפגישות. בעיות שונות, כלים שונים. הגרסה הכנה של "מה מפעיל את התרגום של InterMIND" היא "המנוע הנכון לכל צינור", ולא "המנוע שלנו, בכל מקום".

שפות שהצינור הזה מכסה והקול לא

צינור המסמכים מגיע ל-30 שפות, לעומת 23 בקול. בין התוספות: בולגרית, יוונית, אסטונית, אינדונזית, ליטאית, לטבית, סלובקית, סלובנית. (ערבית נמצאת גם היא ברשימה הזו והיא אחת התוספות: היא הוסרה מבורר הזמן אמת כל עוד איכות הקול שלה מתחת לרף שלנו, והציונים לפי צמדי שפות שלה נשארים פומביים ב-/benchmark, והמספר הזה הוא מה שיחזיר אותה. האסימטריה פועלת בכיוון ההפוך עבור הינדי: זמינה בקול, עדיין לא בקבצים.)

האסימטריה הזו אמיתית. היא אומרת שמשתתף צרפתי בפגישה יכול לבקש את חוזה ה-PDF באסטונית, אף על פי שהוא לא יכול להאזין לפגישה באסטונית. אנחנו מסמנים זאת בבורר ולא מחליקים את זה במספר יחיד. ההנמקה מופיעה בפוסט על ספירת השפות.

איפה הצינורות נפגשים

ארבעת הצינורות לא פועלים בבידוד. חדר פגישה הוא המקום שבו הם נוגעים זה בזה, והמפגשים האלה חשובים:

• הודעת צ'אט עם קובץ מצורף מפעילה את צינור הצ'אט עבור הטקסט ואת צינור המסמכים עבור הקובץ. המשתתף בשפה אחרת רואה את ההודעה מתורגמת מיד, ואת תרגום הקובץ מגיע בהמשך באופן אסינכרוני כקובץ להורדה.
• הערה משותפת שמצטטת שורת תמלול חוצה הערות ↔ קול. התמלול הוא מה שצינור הקול הפיק בשפת השולח, ותרגום ההערה מפיק עותק לכל צופה של הציטוט הזה בשפתם של כל השאר, כשייחוס המקור נשמר.
• תמלול שמיוצא אחרי הפגישה מריץ את צינור הטקסט בסגנון הצ'אט על כל השיחה, ומפיק קובץ לכל שפה שהמשתתפים יכולים להוריד. זה אותו נתיב קוד כמו תרגום צ'אט, רק באצוות.

בורר השפות הוא רכיב ממשק אחד. התשתית שמתחתיו היא ארבעה צינורות שמדברים זה עם זה.

מה אנחנו בכוונה לא מנסים

• אין "מודל תרגום מאוחד". אנחנו לא בונים מודל אחד שעושה קול, צ'אט, הערות ומסמכים. לפשרה בין השהיה לנאמנות אין מנצח. אנחנו משתמשים במנוע הנכון לכל משטח.
• אין ניתוב מחדש שקט. אם צינור הקבצים לא יכול לתרגם להינדי היום, אנחנו לא חוזרים בשקט למנוע הקול ומעמידים פני שזה עבד. בורר הקבצים מסמן את הפער במקום להסתיר אותו.
• אין "אנחנו מתרגמים ל-200 שפות". המנוע שלנו מפיק 24. המשטחים החיים תומכים ב-23, המסמכים ב-30. ובמקום מספר אחד ידידותי לשיווק, האיכות לפי צמד שפות, זו שצריכה לעמוד מול מבקר, מפורסמת ב-/benchmark, כולל הצמדים החלשים יותר.

נסו בעצמכם

• נסו את הדמו החי — מריץ את צינור הקול החי על האודיו שלכם, בכל אחת מ-23 שפות המוצר. זה אותו צינור שמקבל ציון ב-/benchmark.
• עיינו בבנצ'מרק — איכות לפי צמד ולפי חודש על תעבורה אמיתית. כל צמד בבורר, חזק או חלש, עם קישור ישיר.
• קראו את המתודולוגיה — מה המספרים, מה הם לא, ומי השופט.

ארבעה צינורות, ארבעה מנועים, חדר פגישה אחד. זו ההחלפה הכנה לדף how-it-works הישן.

— צוות Mind.com

מקורות: DeepL — שפות נתמכות, DeepL — ספירת שימוש וחיוב (המינימום של 50,000 תווים לקובץ), FLORES-200; עובדות על הצינורות הנוגעות לפנימיות המערכת אומתו מול הקוד שנשלח לייצור, נבדקו באוגוסט 2026.