Embeddings: המדריך הטכני — איך משמעות הופכת לווקטורים

מאת צוות מדיה דיל · 09.08.2026 · AI · 9 דק׳

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

צוות פיתוח בונה מערכת חיפוש פנימית, ומגלה שחיפוש על "בעיית התחברות" לא מוצא מסמכים שמדברים על "כשל באימות משתמש" - למרות שמדובר באותה בעיה בדיוק, רק בניסוח שונה. חיפוש מילות מפתח קלאסי לא יכול לפתור את זה מעצם טבעו: הוא משווה מחרוזות, לא משמעות. הפתרון שהפך לתקן דה-פקטו בשנים האחרונות הוא Embeddings - ייצוג מספרי של טקסט (או תמונה, קול, כל סוג מידע) כווקטור במרחב רב-ממדי, שבו מרחק גיאומטרי בין נקודות משקף קרבה במשמעות. זה הרכיב הבסיסי ביותר שעליו נבנות כל מערכות ה-RAG וה-Vector Search המודרניות, אבל רוב הצוותים משתמשים בו כקופסה שחורה בלי להבין מה קורה בפנים - ומשלמים על זה בבאגים עדינים שקשה לאבחן.

איך מודל הופך משפט לרשימת מספרים

מודל Embeddings הוא בבסיסו רשת נוירונים (בדרך כלל מבוססת Transformer) שאומנה לקרוא טקסט ולהפיק ממנו וקטור - מערך של מספרים ממשיים באורך קבוע, למשל 1536 או 3072 מספרים. האימון לא מתבצע על "הגדרת משמעות" באופן מפורש, אלא על משימות עקיפות: לדוגמה, לחזות אילו משפטים נוטים להופיע קרוב זה לזה בטקסט, או להבחין בין זוגות משפטים דומים לזוגות שונים (contrastive learning). התוצאה של תהליך כזה היא שהמודל "לומד" לבנות מרחב שבו קרבה גיאומטרית מתאמת עם קרבה סמנטית - לא כי מישהו תכנת את זה במפורש, אלא כי זו הדרך הטובה ביותר להפחית את שגיאת האימון.

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

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

Cosine Similarity מול Dot Product - ההבדל שקובע התנהגות

המדד הנפוץ ביותר להשוואת שני וקטורים הוא Cosine Similarity - מדידת הזווית ביניהם, בלי להתחשב באורך (magnitude) של כל וקטור. שני וקטורים שמצביעים לאותו כיוון בדיוק יקבלו ציון 1, גם אם אחד "ארוך" מהשני משמעותית. זה שימושי כי אורך הווקטור לרוב לא נושא מידע סמנטי משמעותי - הוא יכול להיות תוצר לוואי של אורך הטקסט המקורי או של תדירות מילים, לא בהכרח של המשמעות עצמה.

לעומת זאת, Dot Product (מכפלה סקלרית) כן מושפע מאורך הווקטורים, וכשמשתמשים במודלים שמיוצרים ווקטורים מנורמלים מראש (אורך יחידה), Dot Product ו-Cosine Similarity הופכים למעשה לזהים מבחינה מתמטית - אבל Dot Product זול יותר חישובית כי הוא חוסך את שלב הנרמול בזמן שאילתה. זו הסיבה שהרבה Vector Database ממליצים באופן פעיל לנרמל וקטורים בזמן האינדוקס (Indexing), ואז להשתמש ב-Dot Product לחיפוש - התוצאה זהה ל-Cosine Similarity, אבל מהירה יותר בקנה מידה גדול.

הבחירה בין המדדים היא לא רק עניין ביצועים - היא צריכה להתאים למה שהמודל אומן עליו. מודלי embedding רבים מפורשים במסמכי התיעוד שלהם באיזה מדד השתמשו במהלך האימון (contrastive loss מבוסס לרוב על cosine או dot product מנורמל), ושימוש במדד אחר בזמן ההרצה עלול לתת תוצאות פחות מדויקות ממה שהמודל מסוגל לספק בפועל. טעות נפוצה היא לבחור מדד "כי זה מה שהספרייה תומכת בברירת מחדל" בלי לבדוק מה המודל בפועל ציפה לו.

Euclidean Distance - מתי בכל זאת רלוונטי

מדד שלישי, פחות נפוץ בעולם הטקסט אבל עדיין קיים, הוא Euclidean Distance - מרחק "פשוט" במרחב הרב-ממדי, כמו מרחק בין שתי נקודות במרחב תלת-ממדי רגיל. הוא נפוץ יותר בעולמות embeddings של תמונות או נתונים מספריים, שבהם אורך הווקטור כן נושא מידע רלוונטי. ברוב מקרי השימוש הטקסטואליים, Cosine או Dot Product עדיפים, אבל שווה לדעת שהאופציה קיימת ולבדוק מה מודל ה-embedding הספציפי ממליץ עליו.

ממדיות: כמה מספרים באמת צריך

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

טכניקה שהופכת נפוצה יותר היא Matryoshka Embeddings - מודלים שאומנו כך שהממדים הראשונים בווקטור (למשל 256 הראשונים מתוך 1536) כבר מכילים ייצוג שימושי בפני עצמו, ולא רק "חלק" משהו גדול יותר. זה מאפשר לקצץ (truncate) וקטור לממד קטן יותר בזמן ריצה בלי לאמן מודל נפרד, ולקבל טרייד-אוף גמיש בין דיוק למהירות - למשל להריץ שלב שליפה ראשוני מהיר על ממד מקוצץ, ואז לדייק את התוצאות הסופיות עם הווקטור המלא.

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

Chunking - למה הטקסט שנכנס למודל קובע הכל

Embedding לא נעשה על מסמכים שלמים - הוא נעשה על יחידות טקסט קטנות יחסית (chunks), ואיכות החלוקה הזו משפיעה על איכות התוצאה יותר מכל פרמטר אחר במערכת. chunk ארוך מדי "מדלל" את הווקטור - הוא מכיל כמה נושאים שונים, והממוצע הסמנטי שלהם לא מייצג טוב אף אחד מהם לבדו. chunk קצר מדי מאבד הקשר - משפט בודד שנתלש מהפסקה שלו עלול להיות דו-משמעי או חסר מובן בלי הסביבה שלו.

גישות מתקדמות יותר, כמו Semantic Chunking, מנסות לחלק טקסט לפי גבולות משמעות טבעיים במקום לפי מספר תווים קבוע - זיהוי היכן נושא אחד מסתיים והבא מתחיל, ולא רק ספירת אורך גולמי. זה משפר משמעותית את איכות ה-embeddings שנוצרים, כי כל chunk מייצג באמת יחידת משמעות אחת קוהרנטית ולא קטע שרירותי.

מודל Sparse מול Dense - למה שילוב עובד הכי טוב

ה-embeddings שתוארו עד כה הם Dense Embeddings - כל ממד בווקטור נושא ערך, וכל הממדים יחד מייצגים משמעות מכווצת. יש גישה חלופית, Sparse Embeddings, שבה רוב הממדים הם אפס וכל ממד תופס בדרך כלל מילה או מונח ספציפי - זה בעצם גרסה מתוחכמת יותר של חיפוש מילות מפתח, אבל עם משקלים נלמדים במקום ספירה סטטיסטית פשוטה כמו ב-BM25.

לכל גישה יש חוזקה משלימה: Dense תופס דמיון סמנטי גם כשאין חפיפה מילולית ישירה; Sparse מדויק יותר במונחים נדירים ומזהים ספציפיים - בדיוק כמו ההבדל שמתואר במדריך Hybrid Search. מערכות פרודקשן רבות משלבות בין השניים ולא בוחרות אחד על חשבון השני, כי הכשלים של כל גישה לבד שונים באופן מהותי מהכשלים של הגישה השנייה.

Latency ועלות בזמן אינדוקס מול זמן שאילתה

יש נטייה לחשוב על עלות embeddings כעלות אחידה, אבל בפועל יש שני פרופילי עומס שונים לגמרי. בזמן אינדוקס (Indexing) - העברת מאגר שלם דרך מודל ה-embedding פעם אחת - העלות נמדדת בסך הטוקנים שמעובדים, וניתן להריץ אותה ב-batch גדולים במקביל בלי רגישות ל-latency בודד. בזמן שאילתה (Query time) - הפיכת שאלת המשתמש לווקטור בזמן אמת - כל מילישנייה נחשבת, כי היא מתווספת ישירות לזמן התגובה שהמשתמש חווה.

ההשלכה המעשית: כדאי לבחור מודל embedding שמספק latency נמוך לקריאה בודדת (query-time), גם אם זה אומר להשתמש במודל "כבד" יותר, איטי יותר ב-batch, לצורך האינדוקס החד-פעמי. חלק מהצוותים אפילו משתמשים בשני מודלים שונים - אחד לאינדוקס האיטי אך המדויק, אחר קליל יותר לשאילתות בזמן אמת - אבל זה דורש זהירות רבה כי שני המודלים חייבים לחלוק את אותו מרחב גיאומטרי, מה שכמעט אף פעם לא קורה בפועל בין מודלים שונים. ברוב המקרים, פשוט יותר ובטוח יותר להשתמש באותו מודל בשני הכיוונים ולהשקיע בתשתית cache במקום.

טעויות נפוצות בעבודה עם Embeddings

• ערבוב מודלים במאגר אחד - החלפת מודל embedding בלי לחשב מחדש (re-embed) את כל המסמכים הקיימים גורמת לכך שווקטורים חדשים וישנים "חיים" במרחבים גיאומטריים שונים לגמרי, ומרחקים בין השניים חסרי משמעות.
• אי-נרמול לפני Dot Product - שימוש ב-Dot Product בלי לוודא שהוקטורים מנורמלים לאורך יחידה נותן תוצאות מוטות לטובת וקטורים "ארוכים" יותר, לא בהכרח דומים יותר מבחינה סמנטית.
• הזנחת בדיקת התאמת שפה - לא כל מודל embedding מתפקד באותה רמה בכל שפה; מודל שאומן בעיקר על אנגלית עלול לתת תוצאות פחות מדויקות בעברית גם אם הוא "תומך" בה טכנית.
• הזנחת עדכון embeddings לתוכן שמשתנה - מסמכים שמתעדכנים דורשים re-embedding; חיפוש כנגד embedding ישן של תוכן שכבר השתנה מחזיר תוצאות שגויות בלי שגיאה גלויה.

דוגמה מהשטח - מערכת תמיכה שחיפשה בשפה הלא נכונה

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

שאלות נפוצות

האם אפשר להשוות embeddings ממודלים שונים?

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

מה קורה כשמשנים מודל embedding במערכת קיימת?

נדרש re-embedding מלא של כל המאגר - אין דרך "להתאים" וקטורים ישנים למודל חדש, וניסיון להשתמש בהם יחד ייתן תוצאות שגויות.

האם ממד גבוה יותר תמיד עדיף?

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

מה ההבדל בין Embeddings ל-Fine-tuning?

Embeddings מייצרים ייצוג מספרי לחיפוש ודמיון; Fine-tuning משנה את התנהגות מודל שפה עצמו. שתי טכניקות שונות לגמרי שפותרות בעיות שונות.

איך embeddings מתקשרים ל-Vector Database?

Vector Database הוא התשתית שמאחסנת embeddings ומאפשרת חיפוש דמיון יעיל עליהם בקנה מידה - embeddings הם הנתונים, Vector Database הוא המנוע שמריץ עליהם חיפוש.

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

תגיות: Embeddings · Vector Search · Cosine Similarity · RAG · Semantic Search · NLP · Vector Database

← חזרה לבלוג · צור קשר