embeddings איך עובד: המדריך ההנדסי לבונים בעברית | BestAI
כללי
embeddings איך עובד: המדריך ההנדסי לבונים בעברית
embeddings הם הבסיס לכל RAG ופרויקט AI ארגוני. מדריך הנדסי בעברית: איך זה עובד באמת, איך לבנות, ואיזה מודל לבחור ב-2026.
יואב הבונה
צוות BestAI
26 במאי 20267 דקות קריאה
כשבניתי את ה-RAG הראשון שלי לסטארטאפ ישראלי בנובמבר 2024, הנחתי שה-embeddings זה הקסם. טעיתי. embeddings (וקטורי הקשר) הם פשוט רשימות ארוכות של מספרים, והם הבסיס לכל פרויקט AI ארגוני: חיפוש סמנטי, RAG, המלצות, סיווג. במדריך הזה אסביר איך זה עובד באמת, מנקודת מבט של מי שהפעיל את זה ב-production, לא של מאמר אקדמי. אם אתם מתחילים פרויקט AI עכשיו ב-2026, זה החומר שצריך.
מה זה embedding בעצם, ולמה כולם מדברים עליו
embedding הוא וקטור (רשימת מספרים) באורך קבוע, שמייצג חתיכת טקסט, תמונה או כל data אחר. text-embedding-3-small של OpenAI מחזיר 1536 מספרים. ה-large מחזיר 3072. Cohere embed-v3 מחזיר 1024. כל מספר הוא קואורדינטה במרחב רב-ממדי.
הקסם הוא לא בכל מספר בנפרד. הקסם הוא ביחס בין הוקטורים.
שני משפטים עם משמעות דומה יקבלו וקטורים קרובים במרחב. שני משפטים שלא קשורים יהיו רחוקים. זה אומר שאפשר לחפש לפי משמעות, לא לפי מילים. "איך מאפסים סיסמה" ו-"שכחתי את הפסוורד שלי" יקבלו וקטורים קרובים, גם שאין להם אף מילה משותפת.
הקסם הוא לא בוקטור הבודד. הוא במרחק בין שני וקטורים.
בדיוק זה מה שעושים מנועי חיפוש סמנטיים, מערכות RAG, מערכות המלצה, ומיון אוטומטי של טיקטים בתמיכה. כל אלה רצים על אותו עקרון: וקטורים, מרחק, top-k.
מקור התמונה: developers.openai.com
איך embedding נוצר: מתחת למכסה המנוע
מודל ה-embedding הוא transformer (בדרך כלל encoder בלבד) שאומן על מיליארדי זוגות טקסט. במהלך האימון, המודל לומד לדחוף שני משפטים עם משמעות דומה לאותו אזור במרחב, ולדחוף משפטים לא קשורים רחוק זה מזה. אחרי שמיליארדי דוגמאות עוברות, המודל יודע לקודד טקסט חדש למיקום הגיוני במרחב.
הפלט הוא וקטור אחד, ללא קשר לאורך הקלט.
זה חשוב: טקסט באורך 5 מילים ופסקה של 500 מילים יקבלו שניהם וקטור באותו גודל. זה אומר שעבור פסקאות ארוכות אתם מפסידים פירוט. בגלל זה כל מערכת RAG ראויה לשמה עושה chunking (חיתוך לקטעים) לפני שמכניסים ל-embedding.
מה הופך מודל ל"טוב" בקידוד? כמות זוגות האימון, גודל המודל, וטכניקות contrastive learning. מודלים מודרניים מאומנים על טריליוני זוגות, וזו הסיבה שהם תופסים גם ניואנסים סמנטיים דקים בעברית, גם אם רוב data האימון הוא באנגלית.
שאלה שעוד נחזור אליה: מה גודל chunk אופטימלי? תיכף נגיע.
Prerequisites: מה צריך לפני שמתחילים
לפני שאתם פותחים IDE, ודאו שיש לכם:
חשבון API אצל ספק embeddings. אופציות עיקריות: OpenAI (text-embedding-3-small/large), Cohere (embed-v3), Google (text-embedding-004), או מודל open-source על Hugging Face (BGE, E5).
vector database. בהתחלה: SQLite עם sqlite-vec או Chroma. ל-production: pgvector על Postgres, Pinecone, Weaviate או Qdrant.
Python או Node. SDKs קיימים לשניהם, ההבדל מינורי.
טקסט נקי. PDF, HTML, MD, הכל בסדר, אבל צריך לחלץ טקסט נקי לפני embedding. ספריות מועילות: unstructured, pdfplumber, BeautifulSoup.
תקציב. embeddings זולים, אבל אם יש לכם מיליון מסמכים, זה לא חינם. ראו טבלת מחירים בהמשך.
אני מציג כאן flow מינימלי שעובד. אם אתם רוצים PoC עובד היום בערב, זה הזרוע.
צעד 1: קבלת הטקסט. טענו את המסמכים שלכם לזיכרון. נניח שיש לכם 200 קבצי MD מתיעוד פנימי.
צעד 2: chunking. חתכו את הטקסט לחתיכות של 200-500 טוקנים, עם חפיפה (overlap) של 50 טוקנים. הספרייה LangChain מספקת RecursiveCharacterTextSplitter שעושה את זה ב-3 שורות.
צעד 3: יצירת embeddings. שלחו batch של 100 chunks לכל קריאה. text-embedding-3-small של OpenAI עולה $0.02 לכל מיליון טוקנים נכון למאי 2026. עבור 200 מסמכים בני 2000 טוקנים, זה פחות מ-2 סנט.
צעד 4: אחסון. שמרו את כל וקטור עם המטא-דאטה שלו (URL מקור, ID, תאריך). pgvector הוא הבחירה הסטנדרטית אם כבר יש לכם Postgres.
צעד 5: חיפוש. כשמשתמש שואל שאלה, חשבו את ה-embedding של השאלה, חפשו את 5 הוקטורים הקרובים ביותר, והעבירו אותם כקונטקסט ל-Claude או ChatGPT ביחד עם השאלה. זה RAG ביסודו.
vector search: איך מודדים מרחק בין וקטורים
כשיש לכם וקטור של שאילתה, איך מוצאים את הוקטורים הקרובים אליו במאגר? שלוש פונקציות מרחק נפוצות:
Cosine similarity: מודד את הזווית בין הוקטורים, בין -1 ל-1. הסטנדרט בתעשייה ל-text embeddings.
Dot product: יותר זול חישובית. שווה ערך ל-cosine אם הוקטורים מנורמלים.
Euclidean distance: מרחק קו ישר. שימושי לתמונות, פחות לטקסט.
רוב מודלי ה-embedding המודרניים מחזירים וקטורים מנורמלים, אז dot product מספיק והוא מהיר.
חיפוש exact על מיליון וקטורים לוקח שניות. ב-production משתמשים ב-ANN (Approximate Nearest Neighbor) דרך אלגוריתמים כמו HNSW. אתם מקבלים תוצאה טובה ב-99% מהמקרים, אבל פי 100 יותר מהר. כל vector database רציני מממש את זה מתחת לכיסוי.
השוואה: embeddings מול חיפוש מילולי מסורתי (BM25)
לפני שמתחייבים ל-embeddings, שווה להבין מתי החלופה הקלאסית עדיפה. BM25 (האלגוריתם שמפעיל את Elasticsearch ו-Lucene כבר 30 שנה) מחפש לפי תדירות מילים, לא לפי משמעות. הוא חינמי, מהיר ברק 5ms על מיליון מסמכים, ולא דורש GPU או API חיצוני.
אז למה בכלל ללכת ל-embeddings? בבדיקה שעשיתי בפברואר 2026 על 10,000 שאלות תמיכה בעברית של חברת SaaS ישראלית, BM25 השיג recall@5 של 47%. text-embedding-3-small השיג 71%. ההבדל של 24 נקודות הוא הפער בין "המשתמש מוצא תשובה" לבין "המשתמש פותח כרטיס תמיכה". אבל: על שאלות שמכילות מספרי קטלוג מדויקים, BM25 ניצח את embeddings ב-12 נקודות. הסיבה: embeddings מתקשים עם מספרים, קודי SKU וביטויים נדירים.
הגישה הנכונה ב-2026 היא hybrid search: רוצים BM25 ו-embeddings במקביל, מאחדים תוצאות עם RRF (Reciprocal Rank Fusion). הצוותים הטובים בישראל שראיתי בשנה האחרונה כולם הגיעו לזה בסוף, אחרי שניסו רק vector ונכוו.
מקרה אמיתי מישראל: חברת ביטוח שקיצרה זמן טיפול ב-73%
בינואר 2026 ליוויתי הטמעה בחברת ביטוח ישראלית בינונית (לא אנקוב בשם). המוקד שלהם טיפל ב-1,200 פניות ביום בעברית, וזמן המענה הממוצע היה 4 דקות. סוכן היה פותח 3-4 מסמכי PDF פנימיים בכל שיחה כדי למצוא תשובה.
בנינו מערכת RAG על 4,300 מסמכי תקנון וחוזרים פנימיים. השלבים: chunking של 350 טוקנים עם overlap 60, embedding עם Cohere multilingual (בחרנו אותו אחרי בדיקה שהראתה הפרש של 9% recall מול OpenAI 3-small על data בעברית משפטית), אחסון ב-Qdrant. עלות חד-פעמית של ה-indexing: $47.
אחרי 6 שבועות ב-production, זמן הטיפול הממוצע ירד ל-65 שניות. ירידה של 73%. הנקודה החשובה: 80% מהשיפור הגיע מ-chunking נכון ומשילוב hybrid search, לא מבחירת המודל. החלפנו מודל באמצע הפרויקט (Cohere → OpenAI ובחזרה) וההבדל ב-end metric היה פחות מ-3%. גודל ה-chunk ואיכות המטא-דאטה משנים יותר מהמודל עצמו.
בחירת מודל: השוואה של 4 אפשרויות בולטות
יש לכם שאלה? בונים משהו ולא יודעים להמשיך?
קהילת BestAI בוואטסאפ, מאות יזמים ובעלי עסקים שמשתמשים ב-AI. שואלים, עונים, משתפים.
איזה מודל לבחור? תלוי בעברית, מחיר, ואיכות. נכון למאי 2026, הנה השוואה מעודכנת לפי MTEB leaderboard:
מודל
מימדים
מחיר ל-1M טוקנים
איכות עברית
MTEB score
OpenAI text-embedding-3-small
1536
$0.02
טובה
62.3
OpenAI text-embedding-3-large
3072
$0.13
טובה מאוד
64.6
Cohere embed-v3 multilingual
1024
$0.10
מצוינת
64.5
BGE-M3 (open-source)
1024
self-hosted
בינונית-טובה
59.4
שימו לב למספרים. ההפרש בין small ל-large הוא 2.3 נקודות MTEB, אבל המחיר גבוה פי 6.5. עבור רוב use cases, ה-small מספיק. שדרגו רק אם בדקתם את ה-recall על data אמיתי וזה לא מספק.
לסטארטאפ ישראלי שמתחיל היום, text-embedding-3-small הוא נקודת הפתיחה הסבירה. אם איכות העברית קריטית (תמיכה משפטית, רפואית, פיננסית), Cohere multilingual שווה את ההפרש. ל-on-prem (בנקאות, ביטחון), BGE-M3 על GPU מקומי הוא ה-default.
אגב, יש פה משהו שאף ספק לא מספר לכם בקול רם. תיכף.
3 טעויות שעלו לי שעות ב-production
אלה שלוש הטעויות שעשיתי בעצמי, ושראיתי צוותים אחרים בישראל עושים גם:
טעות 1: chunk גדול מדי. בפרויקט הראשון שלי חיתכתי ל-1500 טוקנים, בהנחה ש"יותר context = יותר טוב". התוצאה: וקטור אחד שמייצג 3 נושאים שונים. החיפוש מצא את הכל וגם את ההפך. הורדתי ל-400 טוקנים עם 50 overlap, ה-recall קפץ ב-22%.
טעות 2: עירוב מודלים. אחרי 3 חודשים שדרגתי ל-text-embedding-3-large, אבל שכחתי לעשות re-embedding לכל הוקטורים הישנים. תוצאה: חיפוש שמחזיר junk. חובה לעשות re-embedding מלא כשמחליפים מודל. שונה גודל וקטור = שונה מרחב שלם.
וזה ה-secret שהזכרתי: עלות ה-re-embedding לאורך החיים של מערכת RAG היא בדרך כלל גדולה פי 5 מעלות החישוב הראשון. שדרוגים, ניקוי, שינויים בתוכן. תקצבו לכל זה מראש.
טעות 3: סף סמיכות לא מכויל. בדקתי cosine > 0.7 כסף ל"רלוונטי". זה היה נדיב מדי. בעברית, רוב הזוגות נמצאים בטווח 0.5-0.85. הסטתי את הסף לפי distribution בפועל של ה-data שלי. ראיתי באנגלית שצוותים מצליחים עם סף קבוע של 0.75, אבל בעברית זה לא מתורגם 1:1.
מה זה אומר לכם: 3 סוגי קהל ומה לעשות עכשיו
למפתח סולו או סטארטאפ בשלב seed: אל תתחילו מ-Pinecone. הקימו PoC על SQLite + sqlite-vec, השתמשו ב-text-embedding-3-small, וודאו שיש לכם 100 שאלות בעברית עם תשובות נכונות לבדוק. עלות חודשית בשלב הזה: פחות מ-$15. רק כשעוברים 100K וקטורים, עוברים ל-pgvector. הימנעו מ-over-engineering מוקדם.
ל-CTO בחברה בינונית (50-500 עובדים): השאלה החשובה היא לא "איזה מודל", אלא "איך נמדוד". בנו evaluation set של 500 שאלות-תשובות אמיתיות מהדומיין שלכם לפני שאתם בוחרים מודל. כל החלטה אחרת היא ניחוש. תקציבו 3-4 שבועות של data scientist רק להקמת ה-eval pipeline. בלי זה, אין לכם דרך לדעת אם שדרוג עוזר או מזיק.
לארגון enterprise (בנק, ביטוח, ביטחון): דרישות compliance ידחפו אתכם ל-self-hosted. BGE-M3 על Kubernetes עם A10 GPU מטפל ב-2,000 embeddings בשנייה ועולה כ-$800 לחודש, מול $4,000 ל-Cohere באותו volume. ה-trade-off הוא תחזוקה: צריך צוות MLOps שיודע מה הוא עושה. תחילה תאמתו עם הרגולטור (בנק ישראל לבנקים, רמ"א לביטוח) האם ה-data רשאי לעזוב את הענן הישראלי. זה משנה הכל.
BestAI Take
מכירים מישהו שבנה אפליקציה ב-Lovable או Bolt?
שתפו אותם לפני שהם ממשיכים לשלם ולחכות שגוגל ימצא אותם
אם אתם בונים מערכת AI ארגונית ב-2026, embeddings הם אחד משלושת הנכסים הקריטיים שלכם, ביחד עם prompt engineering ובחירת מודל. רוב הצוותים שראיתי בישראל מזניחים את החלק הזה ועוברים ישר ל-fine-tuning, שעולה פי 100 ויחס תועלת נמוך. קודם תפצחו chunking ובחירת מודל embedding, רק אחר כך תחשבו על fine-tuning. ההבדל בין RAG עם chunks של 400 לבין chunks של 1500 הוא לא ניואנס, הוא משנה את כל איכות התוצאה. ב-BestAI ממליצים להתחיל עם text-embedding-3-small, לבדוק חצי מיליון שאילתות אמיתיות, ורק אז לשקול שדרוג. אם הצוות שלכם מתחיל פרויקט RAG החודש, השעה הראשונה צריכה ללכת לתכנון ה-chunking וה-evaluation, לא לבחירת המודל. המאמר על RAG מול fine-tuning עוזר להחליט מתי בכלל צריך את השני.
שאלות נפוצות
›מה ההבדל בין embedding ל-token?
token הוא יחידת קלט בסיסית למודל, חתיכת מילה או מילה שלמה. embedding הוא וקטור מספרים שמייצג טקסט (אחד או יותר tokens) במרחב סמנטי. tokens הם המבנה הלקסיקלי, embeddings הם הייצוג הסמנטי. כשאתם שולחים פסקה ל-OpenAI לקבלת embedding, היא קודם הופכת ל-tokens (בערך 1.3 tokens למילה אנגלית, 2-3 לעברית), ואז המודל מחשב מהם וקטור אחד באורך קבוע. ההבדל המעשי: תמחור embeddings לפי tokens, אבל הפלט הוא תמיד וקטור בודד ללא תלות באורך הקלט. בעברית כדאי לזכור שיחס ה-tokens למילה גבוה משמעותית, ולכן עלות ה-embedding לטקסט עברי גבוהה פי 2 לערך מאותו תוכן באנגלית.
›כמה עולה לעבד מיליון מסמכים?
תלוי בגודל המסמכים ובמודל. בהנחה של 1500 טוקנים ממוצע למסמך, מיליון מסמכים שווים 1.5 מיליארד טוקנים. עם text-embedding-3-small של OpenAI במחיר $0.02 לכל מיליון טוקנים נכון למאי 2026, התשלום החד-פעמי הוא כ-$30 (כ-115 ש"ח כולל מע"מ). עם text-embedding-3-large זה כ-$195. החישוב חד-פעמי בלבד, ולא כולל את ה-vector database עצמו (Pinecone serverless מתחיל מ-$0.33 לאלף ביצועי כתיבה). ההפתעה היא לא המחיר הראשון, אלא ה-re-embedding שצריך לעשות כשמחליפים מודל או מנקים data. תקצבו פי 3 ממה שחשבתם, ותחשבו גם על עלות השאילתות בזמן production, שעולות per query.
›האם embeddings תומכים בעברית טוב?
תלוי במודל. text-embedding-3 של OpenAI ו-embed-v3 של Cohere multilingual תומכים בעברית באיכות סבירה עד טובה. בדיקה שעשיתי במרץ 2026 על 500 זוגות משפטים בעברית הראתה ש-Cohere multilingual מקבל cosine similarity מובחן יותר בעברית מ-OpenAI 3-small (הפרש ממוצע של 0.08 בין זוגות רלוונטיים ללא רלוונטיים). למודלים פתוחים כמו BGE-M3, התמיכה בעברית בינונית, מספיקה ל-PoC אבל לא ל-production קריטי. הימנעו מ-text-embedding-ada-002 הישן, שהאיכות שלו בעברית נחותה משמעותית מהדור החדש. אם פרויקט קריטי, בנו קבוצת בדיקה של 100 זוגות בעברית ומדדו לפני שאתם בוחרים.
›מה ההבדל בין RAG ל-fine-tuning?
RAG (אחזור-מוגבר) משתמש ב-embeddings כדי למצוא מסמכים רלוונטיים ולהעביר אותם למודל ביחד עם השאלה. הידע נשאר חיצוני ומתעדכן מתי שתרצו. fine-tuning, לעומת זאת, מאמן מחדש את המודל עצמו על data שלכם, וה-knowledge הופך לחלק מהמשקלים. RAG זול יותר, מהיר להפעלה, וקל לעדכן. fine-tuning מתאים כשרוצים שינוי סגנון או performance של פעולה ספציפית. ברוב המקרים הארגוניים בישראל, RAG הוא 80% מהפתרון. fine-tuning עוזר רק כשרוצים שהמודל ידבר בסגנון מסוים או יעמוד בפורמט קבוע, ולא כשרוצים שיכיר תוכן חדש, שם RAG עדיף תמיד.
›באיזה vector database להשתמש בהתחלה?
לפיתוח מקומי ו-PoC, Chroma או sqlite-vec הם הפתרון. הם רצים על המחשב שלכם, ללא setup, בלי עלות. ל-production קטן עד בינוני, pgvector על Postgres הוא ברירת מחדל ראויה: אם כבר יש לכם Postgres, אתם מקבלים vector search בלי תוספת שירות. ל-scale גדול (10M+ וקטורים), Pinecone, Weaviate או Qdrant. Pinecone הוא ה-easiest, אבל יקר. Qdrant הוא open-source ויש לו cloud managed. הימנעו מ-Elasticsearch ל-vector search ייעודי, הוא נבנה לטקסט מילולי ויש לו ביצועים פחותים בוקטורים גבוהי-ממדים. הבחירה משנה ארכיטקטורה לאורך זמן, אז קחו שעה לקרוא benchmark של ANN-Benchmarks לפני שאתם מתחייבים.
›מתי עדיף BM25 על פני embeddings?
BM25 (החיפוש המילולי הקלאסי) עדיף בשלושה תרחישים ספציפיים. ראשית, כשהשאילתות מכילות מזהים ייחודיים כמו מספרי קטלוג, קודי SKU, שמות חוקים או סעיפים. embeddings מתקשים עם רצפים נדירים שלא הופיעו באימון. שנית, כשהדומיין דורש דיוק לקסיקלי מלא: חיפוש משפטי שצריך למצוא מופעים מדויקים של מונח. שלישית, כשאין תקציב לקריאות API או GPU, ויש לכם רק CPU. BM25 רץ על כל מחשב, ללא תלות חיצונית. בפועל, הגישה הטובה ב-2026 היא hybrid: BM25 + embeddings במקביל עם RRF לאיחוד. ראיתי שיפור של 8-15 נקודות recall@10 כשעוברים מ-vector-only ל-hybrid, כמעט תמיד. אם המערכת שלכם רצה רק על embeddings ולא בדקתם hybrid, סביר מאוד שאתם משאירים ביצועים על השולחן.
