למה עברית היא אתגר מיוחד עבור AI
רוב מודלי ה-AI נבנו על אנגלית. לא קצת, אלא בערך 90% מהדאטה שאימן את המודלים הגדולים הגיע מתוכן באנגלית. כשמגיעים לעברית, המודלים לא פשוט "מתרגמים את עצמם" לשפה חדשה. הם צריכים להתמודד עם מערכת לשונית שונה לחלוטין, עם כללים מורפולוגיים מורכבים, כתיבה מימין לשמאל, וחוסר בתנועות (ניקוד) שמשנה לגמרי את אופן העיבוד.
ב-SysTech אנחנו מפתחים מערכות AI עבור ארגונים ישראליים מאז 2015, ובשנים האחרונות נתקלנו בכל בעיה אפשרית שקשורה לעברית ו-NLP. מוצרי AI שעובדים מעולה באנגלית פתאום מתפקדים בינוני כשמעבירים אותם לעברית, ולקוחות לא מבינים למה. המאמר הזה מכסה את כל מה שצריך לדעת כדי לבנות מוצר AI שבאמת עובד בעברית.
המורפולוגיה של עברית: למה זה כל כך מסובך
שורשים, משקלים ותחיליות
עברית היא שפה שמיית עם מערכת שורשים. המילה "כתבנו" מכילה את השורש כ.ת.ב, תחילית שמציינת עבר, וסיומת שמציינת גוף ראשון רבים. באנגלית "we wrote" זה שתי מילים נפרדות שקל לפרק. בעברית הכל דחוס למילה אחת.
זה יוצר בעיה קריטית בשלב ה-Tokenization. כשמודל שפה שובר טקסט לטוקנים, הוא צריך להבין שהמילה "ושכשהלכתי" זה בעצם "ו-ש-כש-הלכ-תי". ברוב ה-Tokenizers שמבוססים על אנגלית, המילה הזאת תישבר למקטעים שרירותיים שלא מתאימים למבנה המורפולוגי. התוצאה? המודל "מבזבז" טוקנים על עברית יותר מאשר על אנגלית, מה שאומר עלויות גבוהות יותר וביצועים נמוכים יותר.
חוסר ניקוד
בעברית מודרנית לא כותבים תנועות. המילה "דבר" יכולה להיות "davar" (חפץ), "diber" (דיבר), "dever" (מגפה), או "dvar" (דבר של). בלי הקשר, אין שום דרך לדעת מה הכוונה. בני אדם פותרים את זה אוטומטית על בסיס הקשר, אבל מודל AI צריך ללמוד את הרב-משמעיות הזאת ולבחור נכון.
זה משפיע ישירות על כל משימת NLP. ניתוח סנטימנט, חילוץ ישויות (NER), סיווג טקסט, והבנת כוונת משתמש (Intent Detection) בצ'אטבוטים. כל אחד מהם נפגע מחוסר הניקוד.
מגדר דקדוקי
עברית מחייבת התאמת מגדר בפעלים, תארים, וכינויי גוף. "אתה רוצה" מול "את רוצה" מול "אתם רוצים" מול "אתן רוצות". מודלים שאומנו בעיקר על אנגלית נוטים להתבלבל עם ההתאמות האלה, מה שיוצר פלט שנשמע לא טבעי ללקוחות ישראלים.
Tokenization בעברית: הבעיה שכולם מתעלמים ממנה
Tokenization היא השלב הראשון בכל עיבוד טקסט, ובעברית זה בדיוק איפה שהרבה מערכות נכשלות.
איך Tokenizers מתמודדים עם עברית
רוב ה-Tokenizers המודרניים (BPE, SentencePiece, WordPiece) נבנו עם דגש על אנגלית. כשהם מעבדים עברית:
- מילה אחת בעברית יכולה לצרוך 3-5 טוקנים, בעוד באנגלית מילה ממוצעת צורכת 1-2 טוקנים
- תחיליות כמו "וש", "בכ", "מה" נשברות בצורה שרירותית
- אותיות סופיות (ם, ן, ך, ף, ץ) מטופלות לפעמים כתווים נפרדים
בפועל, המשמעות היא שטקסט בעברית עולה יותר לעבד. לא 50% יותר, אלא לפעמים פי 2 ואפילו פי 3 מאנגלית מבחינת צריכת טוקנים. כשמחשבים עלויות API של מודלים כמו GPT-4o או Claude, ההבדל הזה מצטבר מהר.
מה אפשר לעשות
כשאנחנו בונים מערכת AI בעברית ב-SysTech, אנחנו מיישמים כמה אסטרטגיות:
- Pre-processing של הטקסט: ניקוי, נרמול, הסרת תווים מיותרים לפני שליחה למודל
- פרומפטים מעורבים: חלקים קריטיים של הפרומפט באנגלית (הוראות למודל) וחלקי התוכן בעברית
- בחירת מודל שתומך טוב יותר בעברית מבחינת ה-Tokenizer שלו
- Caching חכם לתשובות נפוצות, כדי לחסוך קריאות API מיותרות
RTL: יותר מכיוון כתיבה
בניית ממשק שתומך ב-RTL (Right-to-Left) זה הרבה מעבר להוספת `dir="rtl"` ל-HTML. כשבונים מוצר AI שעובד בעברית, יש אתגרי RTL ברמת ה-UI, ברמת עיבוד הטקסט, וברמת ההצגה של תוצאות.
ערבוב כיוונים (BiDi)
טקסט עברי כולל כמעט תמיד קטעים באנגלית. שמות מותגים, מונחים טכניים, קוד, כתובות URL. הערבוב הזה יוצר בעיות BiDi (Bidirectional text) שקשה לזהות ועוד יותר קשה לתקן. משפט כמו "השתמשנו ב-React Native כדי לבנות את האפליקציה" מכיל שני כיוונים בתוך שורה אחת, ו-CSS לבד לא תמיד פותר את זה נכון.
AI Output ו-RTL
כשמודל AI מייצר טקסט בעברית, הוא לא חושב על כיוון. הוא מייצר רצף של טוקנים. ה-rendering של הטקסט הזה ב-UI חייב לטפל ב:
- סימני פיסוק שקופצים למקום הלא נכון
- מספרים שמוצגים הפוך (במיוחד תאריכים ומספרי טלפון)
- רשימות ממוספרות שהמספר שלהן מופיע בצד הלא נכון
- קוד תכנות שמוטמע בתוך הסבר בעברית
ב-React (שזה ה-framework שאנחנו עובדים איתו) יש פתרונות, אבל צריך ליישם אותם בכוונה. `Intl.Segmenter` ב-JavaScript עוזר לפרק טקסט לפי מילים ומשפטים בצורה שמתחשבת ב-locale, ושימוש ב-CSS Logical Properties (כמו `margin-inline-start` במקום `margin-left`) הוא חובה.
השוואת תמיכת עברית בין מודלי LLM
לא כל המודלים נולדו שווים כשמדובר בעברית. הנה מה שאנחנו רואים בפרויקטים אמיתיים נכון לאפריל 2026:
Claude (Anthropic)
Claude 4 Opus ו-3.5 Sonnet מציגים תמיכה מצוינת בעברית. הבנת הקשר מדויקת, התאמת מגדר סבירה מאוד, וכתיבה שנשמעת טבעית. Claude פחות נוטה לייצר "עברית מתורגמת" מאשר מודלים אחרים. חולשה יחסית: לפעמים מערבב רמות שפה (רשמי מדי או לא רשמי מספיק).
GPT-4o (OpenAI)
שיפור דרמטי לעומת גרסאות קודמות. מטפל טוב ברוב משימות ה-NLP בעברית. יש לו ה-Tokenizer הכי יעיל מבין השלושה בטיפול בעברית (פחות טוקנים למילה). חולשה: לפעמים מייצר משפטים שנשמעים כמו תרגום מאנגלית, ויש בעיות בהתאמת מגדר במשפטים ארוכים.
Gemini 2.0 (Google)
הכי חלש בעברית מבין השלושה, אבל עם שיפור מתמיד. היתרון הגדול שלו הוא חלון ההקשר העצום (2 מיליון טוקנים) שמאפשר לעבד מסמכים ארוכים בעברית בלי לחתוך אותם. חולשה: בעיות תכופות יותר עם מגדר, סלנג, וביטויים ישראליים.
מודלים פתוחים (Llama 3, Mistral)
למודלים הפתוחים יש תמיכה חלשה יחסית בעברית out-of-the-box. אם אתם צריכים מודל מקומי (On-premise) מסיבות של רגולציה או אבטחה, Fine-tuning הוא חובה. Llama 3 עם Fine-tuning על קורפוס עברי יכול להגיע לתוצאות סבירות, אבל מרחק רב מהתוצאות של המודלים הסגורים.
Fine-tuning למודלים בעברית
כש-off-the-shelf לא מספיק טוב, Fine-tuning הוא הצעד הבא. אבל Fine-tuning בעברית הוא לא כמו באנגלית.
איסוף דאטה
הבעיה הראשונה היא דאטה. קורפוסים גדולים ואיכותיים בעברית פשוט נדירים בהשוואה לאנגלית. ויקיפדיה העברית קטנה פי 20 מהאנגלית. אתרי חדשות, פורומים, ומדיה חברתית בעברית קיימים, אבל לנקות ולתייג אותם לוקח זמן.
מה שעובד בפועל:
- יצירת דאטה סינתטי: שימוש במודל חזק (Claude או GPT-4o) כדי לייצר דוגמאות אימון בעברית, ואז בדיקה ידנית
- תרגום ועריכה: תרגום דאטהסטים מאנגלית ועריכה ידנית כדי שהעברית תהיה טבעית
- דאטה ספציפי לדומיין: איסוף מסמכים ושיחות מהלקוח עצמו (עם ההרשאות המתאימות)
אסטרטגיות Fine-tuning
ב-SysTech אנחנו ממליצים על גישה מדורגת:
- קודם כל בודקים אם Prompt Engineering מספיק. הרבה פעמים פרומפט מדויק בעברית + Few-shot examples פותר את הבעיה בלי צורך ב-Fine-tuning
- אם צריך Fine-tuning, מתחילים עם LoRA (Low-Rank Adaptation) שחוסך משאבים ומאפשר אימון על GPU יחיד
- מאמנים על דאטה מעורב: 70% עברית, 30% אנגלית. זה שומר על היכולות הכלליות של המודל תוך שיפור העברית
- מריצים הערכה על בנצ'מארק ייעודי לעברית שכולל משימות מגוונות
בדיקות ואיכות: איך בודקים AI בעברית
בדיקת מערכת AI בעברית דורשת גישה שונה מבדיקות רגילות.
בנצ'מארקים לעברית
אין בנצ'מארק סטנדרטי אחד לעברית כמו שיש MMLU לאנגלית. מה שאנחנו עושים:
- בונים בנצ'מארק מותאם לכל פרויקט, עם 200-500 דוגמאות שמכסות מקרים שונים
- כוללים מקרי קצה: סלנג, שגיאות כתיב נפוצות, ערבוב עברית-אנגלית, קיצורים
- בודקים התאמת מגדר באופן ספציפי (זה תמיד נופל בבדיקות)
- מודדים צריכת טוקנים ולא רק דיוק, כי זה משפיע ישירות על עלות
Human evaluation
בעברית, Human evaluation חשוב אפילו יותר מאשר באנגלית. דובר עברית ילידי יזהה מיד אם התשובה נשמעת "מתורגמת" או לא טבעית, גם אם טכנית היא נכונה. אנחנו עובדים עם צוות בודקים שבודקים מדגם מכל batch של תשובות.
בדיקות RTL
כל בדיקת UI חייבת לכלול:
- בדיקה שסימני פיסוק מוצגים במקום הנכון
- בדיקה שמספרים וטלפונים נכונים
- בדיקה שטקסט מעורב (עברית + אנגלית + קוד) מוצג בסדר הנכון
- בדיקה על דפדפנים שונים, כי כל אחד מטפל ב-BiDi קצת אחרת
טיפים מעשיים: מה שלמדנו מפרויקטים אמיתיים
אחרי עשרות פרויקטים עם AI בעברית, הנה התובנות הכי חשובות:
1. אל תתרגמו פרומפטים מאנגלית
פרומפט שעובד מעולה באנגלית לא בהכרח יעבוד בעברית גם אחרי תרגום. כתבו את הפרומפט ישר בעברית, עם דוגמאות בעברית. מודלים מגיבים טוב יותר כשהפרומפט והתוכן באותה שפה.
2. השתמשו ב-System Prompt באנגלית
זה אולי נשמע סותר, אבל ההוראות הטכניות למודל (ב-System Prompt) עובדות יותר טוב באנגלית. הסיבה פשוטה: המודלים אומנו יותר על הוראות באנגלית. שילוב של System Prompt באנגלית עם User Prompt בעברית נותן את התוצאות הטובות ביותר.
3. שמרו על עקביות מגדרית
אם המוצר שלכם פונה ללקוח, החליטו מראש אם הוא מדבר בזכר, בנקבה, או ברבים. ערבוב של "אתה רוצה" ו"את רוצה" באותה שיחה הורס את החוויה. הכי בטוח: פנייה ברבים ("אתם") או שאילת מגדר בתחילת השיחה.
4. בנו Fallback לאנגלית
כשהמודל לא בטוח בתשובה בעברית (ואפשר לזהות את זה דרך confidence scores או דרך אורך תשובה חריג), עדיף להחזיר תשובה באנגלית מאשר לייצר עברית שגויה. הלקוחות הישראליים שלנו מעדיפים תשובה נכונה באנגלית על תשובה שגויה בעברית.
5. מדדו עלות לכל שפה
כמו שהסברנו, עברית צורכת יותר טוקנים. תתקצבו בהתאם. אם הקצבתם $500 לחודש על סמך חישוב באנגלית, סביר שתצטרכו $800-$1,000 לאותו נפח בעברית.
דוגמאות מהשטח
צ'אטבוט שירות לקוחות
אחד הפרויקטים שלנו היה סוכן AI לחברת שירותים ישראלית. האתגר: הלקוחות כותבים בעברית דיבורית, עם שגיאות כתיב, קיצורים, ואימוג'ים. המודל היה צריך להבין "אפשר לבטל?" באותה מידה כמו "ברצוני לבטל את המנוי שלי לשירות".
הפתרון כלל Pre-processing layer שנרמל את הקלט, Intent Detection שאומן על דוגמאות מהשיחות האמיתיות של החברה, ו-Response generation עם טמפלטים שנכתבו בעברית טבעית ועברו אישור של צוות השירות.
מערכת ניתוח מסמכים
פרויקט אחר כלל ניתוח מסמכים משפטיים בעברית. מסמכים משפטיים בעברית מלאים במונחים ארכאיים, משפטים ארוכים מאוד, ומבנים תחביריים שלא קיימים בעברית יומיומית. היה צריך לחלץ סעיפים ספציפיים, לזהות צדדים, ולסכם הסכמים.
השתמשנו ב-Gemini בגלל חלון ההקשר הגדול (ההסכמים היו מאות עמודים), עם שכבת וולידציה שבדקה שהמידע שחולץ תואם למבנה הצפוי. הצלחנו להגיע לדיוק של 94% בחילוץ סעיפים, שזה מספיק טוב בשביל draft שעובר סקירה אנושית.
הכלים שאנחנו ממליצים
לעיבוד טקסט עברי
- Node.js עם ספריות כמו `compromise` לניתוח טקסט בסיסי, בשילוב עם API של מודל שפה גדול למשימות מורכבות יותר
- HebPipe לסגמנטציה מורפולוגית של עברית (פירוק מילים לרכיבים)
- `Intl.Segmenter` ב-JavaScript לפירוק טקסט מודע locale
לפריסה
- Google Cloud Platform עם Cloud Run לשירותי AI שמתרחבים לפי ביקוש
- Cloud Functions לעיבוד אסינכרוני של טקסט
- Firestore לאחסון שיחות ותוצאות עיבוד
לניטור
- לוגים מפורטים שכוללים את הטקסט המקורי, הפלט, וצריכת הטוקנים
- Dashboard שמראה עלות לכל שפה בנפרד
- Alerting על חריגות בצריכת טוקנים שיכולות להעיד על בעיה
מה הלאה: עברית ו-AI ב-2026 ואחרי
התמיכה בעברית ב-AI משתפרת כל הזמן. כל גרסה חדשה של כל מודל מביאה שיפורים. אבל עברית עדיין שפה "קטנה" מבחינת AI, ותמיד תהיה פער מול אנגלית.
הגישה הנכונה היא לא לחכות שהמודלים ישתפרו לבד. צריך לבנות את השכבות שמפצות על הפערים: Pre-processing טוב, פרומפטים מותאמים, בדיקות ייעודיות, ו-Fine-tuning כשצריך. חברות שמשקיעות בזה עכשיו בונות לעצמן יתרון תחרותי שקשה להשיג אחר כך.
ב-SysTech אנחנו ממשיכים לפתח כלים ומתודולוגיות ספציפיות לעברית, ועוזרים לארגונים ישראליים להטמיע AI שבאמת עובד בשפה שלהם.
שאלות נפוצות
האם מודלי AI תומכים בעברית?
כן, כל המודלים המובילים (GPT-4o, Claude, Gemini) תומכים בעברית. הרמה משתנה: Claude ו-GPT-4o מציגים תמיכה טובה עד מצוינת, Gemini סביר עד טוב. עם זאת, התמיכה בעברית תמיד נמוכה יותר מאנגלית, ונדרשת עבודת התאמה כדי לקבל תוצאות ברמת production.
כמה עולה לבנות מוצר AI בעברית?
העלות תלויה בסוג המוצר, אבל צפו לעלות טוקנים גבוהה ב-50%-100% לעומת אנגלית בגלל ה-Tokenization הפחות יעיל. מעבר לזה, נדרשת השקעה בבניית דאטהסטים בעברית, Fine-tuning, ובדיקות ייעודיות. פנו אלינו לקבלת הערכת עלות מדויקת לפרויקט שלכם.
מה עדיף לצ'אטבוט בעברית, GPT או Claude?
שניהם מתאימים, אבל ההמלצה שלנו תלויה בסוג השימוש. לשירות לקוחות שדורש עקיבה מדויקת אחר הוראות ושמירה על טון עקבי, Claude בדרך כלל מצליח יותר. למשימות שדורשות אינטגרציה עם כלים רבים ואקוסיסטם רחב, GPT-4o יכול להתאים יותר. אנחנו ממליצים לבדוק את שניהם על דוגמאות אמיתיות מהדומיין שלכם.
איך מתמודדים עם RTL בממשק AI?
RTL דורש תכנון מראש. ב-פיתוח תוכנה אנחנו מקפידים על CSS Logical Properties, טיפול ב-BiDi text, ובדיקות ספציפיות לטקסט מעורב עברית-אנגלית. חשוב לא להסתפק בהוספת `dir="rtl"` אלא לבדוק כל רכיב ב-UI שמציג טקסט שנוצר על ידי AI.
האם אפשר לעשות Fine-tuning למודל AI לעברית?
בהחלט. Fine-tuning משפר משמעותית את הביצועים בעברית, במיוחד למשימות ספציפיות כמו סיווג, חילוץ מידע, ושיחה בדומיין מסוים. האתגר המרכזי הוא איסוף דאטה איכותי בעברית. אנחנו משתמשים בשילוב של דאטה אמיתי מהלקוח, דאטה סינתטי שנוצר על ידי מודלים חזקים, ותרגום מדאטהסטים באנגלית עם עריכה ידנית.
רוצים לבנות מוצר AI שעובד בעברית?
אם אתם מתכננים להטמיע AI בארגון שלכם ואתם צריכים שזה יעבוד בעברית ברמה גבוהה, דברו איתנו. ב-SysTech יש לנו את הניסיון, הכלים, והידע כדי לבנות מערכת AI שמתמודדת עם כל האתגרים של עברית, מ-Tokenization ועד RTL, ומספקת חוויה שנשמעת טבעית למשתמשים ישראליים.
