מה זה RAG? המדריך המעשי לבנייה בעברית, מאפס ועד production

מה זה RAG בעצם, בלי buzzwords

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

הזרימה היא פשוטה. המשתמש שואל שאלה. המערכת ממירה את השאלה לוקטור (embedding, וקטור הקשר). היא מחפשת ב-vector database את המסמכים שהוקטור שלהם הכי קרוב. היא מצרפת את המסמכים האלה ל-prompt, ושולחת ל-LLM של Claude או ChatGPT או Gemini. המודל מנסח תשובה על בסיס הקטעים שקיבל.

זהו. אין כאן קסם. יש כאן הנדסה.

RAG הוא לא feature, הוא architecture. ברגע שמבינים את זה, ההחלטות הקשות נהיות אפשריות.

למה זה חשוב לישראל ספציפית? כי רוב המידע הארגוני בארץ הוא בעברית, ועברית שוברת חצי מהכלים המוכנים בשוק. בניתי מערכת RAG ללקוח בתחום הביטוח באוקטובר 2025, וגיליתי שה-tokenizer של OpenAI ada-002 הופך מסמך פוליסה בן 1,200 מילים ל-3,800 טוקנים. באנגלית אותו אורך מסמך הוא 1,500 טוקנים. ההבדל הזה משנה את העלות פי שניים וחצי, ואת גודל ה-chunks שכדאי לעבוד איתם.

למה לא לתת ל-LLM פשוט הכל בקונטקסט?

שאלה הוגנת. Claude Sonnet 4.5 תומך ב-200,000 טוקנים. Gemini 2.5 Pro תומך ב-מיליון. אז למה לא פשוט לדחוף את כל ה-knowledge base?

שלוש סיבות, מהשטח:

כסף. ב-Claude Sonnet, מיליון טוקנים input עולה כ-$3. אם 1,000 משתמשים שואלים שאלה ביום וכל קריאה דוחפת 100K טוקנים של קונטקסט, זה $90,000 לחודש. Anthropic מציעה prompt caching שמוריד את זה ב-90%, אבל זה עדיין $9,000.

איכות. מחקר של Stanford מ-2023 ('Lost in the Middle') הראה שמודלים מאבדים מידע באמצע קונטקסט ארוך. בבדיקות שלי על Claude Sonnet 4.5 הבעיה הוקטנה אבל לא נעלמה.

זמן תגובה. קריאה עם 100K טוקנים לוקחת 8-15 שניות. עם RAG ו-3K טוקנים זה 1.5 שניות.

בקיצור, אם אתם בונים demo, תזרקו הכל בקונטקסט. אם אתם בונים מוצר, תבנו RAG.

RAG מול חלופות: מה לבחור ומתי

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

גישה	מתי לבחור	חיסרון עיקרי	עלות יחסית
RAG	מידע משתנה, צריך ציטוטים, תקציב מוגבל	איכות הצ'אנקינג קריטית	בינונית
Fine-tuning	סגנון/פורמט קבוע, דומיין צר ויציב	אימון מחדש בכל עדכון מידע	גבוהה
Long context (1M+)	קורפוס קטן (פחות מ-500 מסמכים), שאילתות אד-הוק	עלות לשאילתה גבוהה, latency איטי	גבוהה מאוד
Agentic search	שאילתות מורכבות, מקורות מרובים, צורך בחיפוש איטרטיבי	מורכבות תפעולית, debugging קשה	בינונית-גבוהה

גישה

מתי לבחור

חיסרון עיקרי

עלות יחסית

RAG

מידע משתנה, צריך ציטוטים, תקציב מוגבל

איכות הצ'אנקינג קריטית

בינונית

Fine-tuning

סגנון/פורמט קבוע, דומיין צר ויציב

אימון מחדש בכל עדכון מידע

גבוהה

Long context (1M+)

קורפוס קטן (פחות מ-500 מסמכים), שאילתות אד-הוק

עלות לשאילתה גבוהה, latency איטי

גבוהה מאוד

Agentic search

שאילתות מורכבות, מקורות מרובים, צורך בחיפוש איטרטיבי

מורכבות תפעולית, debugging קשה

בינונית-גבוהה

בפרויקט שהזכרתי בביטוח, שקלנו את ארבעת הגישות ברצינות. fine-tuning נפסל כי הפוליסות התעדכנו פעם ברבעון, ועלות אימון מחדש על מודל Claude Haiku נאמדה ב-$2,400 לאיטרציה. long context נפסל כי ה-corpus כלל 80,000 מסמכים, מה שתרגום לעלות של $4.50 לשאילתה, בלתי קביל. agentic search נדחה לשלב ב' כי הצוות לא היה מוכן בתחזוקה. RAG ניצח בנוקאאוט, ב-43 אגורות לשאילתה.

Prerequisites: מה צריך לפני שמתחילים

לפני שמרימים cluster של Pinecone, תענו על השאלות האלה. ראיתי יותר מדי פרויקטים שדילגו עליהן ושילמו בחודש השלישי.

מקור המידע. PDF? Confluence? PostgreSQL? כל אחד דורש pipeline שונה. אם זה PDF סרוק, אתם צריכים OCR בעברית, וזה כאב ראש בפני עצמו.
תדירות עדכון. סטטי (קטלוג מוצרים), יומי (חדשות פנימיות), real-time (מלאי)?
מבנה השאילתה. שאלות קצרות (FAQ), שיחה פתוחה (chat), או חיפוש (search)?
שפה. עברית טהורה, אנגלית, או מעורב? מעורב הוא הקשה ביותר.
הרשאות. האם משתמש A יכול לראות את המסמכים של משתמש B? אם לא, צריך filter ברמת ה-vector store, ולא כל הפלטפורמות תומכות בזה.

הצעדים, מהקצה לקצה

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

צעד 1: Ingestion

תקראו את המסמכים מהמקור. תנקו metadata. תשמרו את המקור ב-blob storage עם ID יציב. אל תוותרו על ה-ID. בעוד חצי שנה תרצו לבדוק למה תשובה מסוימת הייתה גרועה, ובלי ID לא תמצאו את המסמך.

צעד 2: Chunking

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

הכלל שלי לעברית: 400-600 טוקנים לצ'אנק, עם 80 טוקנים overlap. אל תחתכו באמצע משפט. אל תחתכו באמצע פסקה אם אפשר להימנע. אם המסמך הוא תקנון משפטי, חתכו לפי סעיפים, לא לפי גודל קבוע.

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

צעד 3: Embedding

בחרו מודל embedding. לעברית, שלוש אפשרויות סבירות נכון לגרסאות הנוכחיות (מאי 2026):

מודל	מימדים	מחיר ל-1M tokens	איכות עברית
OpenAI text-embedding-3-large	3,072	$0.13	טובה
Cohere embed-multilingual-v3	1,024	$0.10	טובה מאוד
Voyage voyage-3	1,024	$0.06	בינונית בעברית

בבדיקה שלי על 200 שאילתות בעברית מול corpus של פוליסות ביטוח, Cohere v3 ניצח את OpenAI ב-recall@5 בכ-4 נקודות אחוז. ההפרש לא דרמטי, אבל הוא עקבי.

צעד 4: Vector store

Pinecone, Weaviate, Qdrant, או pgvector. ההמלצה שלי לרוב הצוותים בישראל: pgvector על Postgres קיים. אין צורך בעוד שירות, ההרשאות עובדות, וה-latency סביר עד מיליון וקטורים. מעל זה, עברו ל-Qdrant.

צעד 5: Retrieval

אל תסתפקו ב-similarity search לבד. הוסיפו hybrid search, כלומר שילוב של דמיון וקטורי עם BM25 (מילות מפתח). בעברית זה קריטי, כי שמות פרטיים, מספרי תיקים וקודי מוצר לא משתקפים טוב ב-embeddings.

צעד 6: Re-ranking

תחזירו את ה-top 20 מה-retrieval, ואז תריצו עליהם reranker (למשל Cohere Rerank). תקחו רק את ה-top 5 ל-LLM. זה מוריד hallucinations באופן משמעותי.

צעד 7: Generation

הצעד האחרון. תבנו prompt עם הנחיה ברורה: 'ענה רק על בסיס הקטעים שלהלן. אם התשובה לא מופיעה בהם, אמור שאתה לא יודע'. תדרשו ציטוט של ה-chunk ID. ככה אתם יכולים להציג למשתמש את המקור, וגם לבדוק hallucinations באופן אוטומטי.

איפה זה נשבר בעברית: שלושה pitfalls מהשטח

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

ראשון, ניקוד. חלק מהמסמכים היו מנוקדים. ה-embedding ראה 'בַּיִת' ו-'בית' כשתי מילים שונות. הפתרון: הסרת ניקוד ב-preprocessing.

שני, RTL ו-mixed content. מסמך עם מספרי פוליסה באנגלית בתוך טקסט עברי שובר את ה-chunking של הרבה ספריות. בדקתי, וה-RecursiveCharacterTextSplitter עובד נכון אם מגדירים את ה-separators מפורש.

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

בנצ'מרק: כמה זה עולה באמת

ה-marketing אומר ש-RAG זול. בשטח, התמונה ניואנסית. הנה החישוב למערכת שמטפלת ב-10,000 שאילתות ביום, על corpus של 100,000 מסמכים בעברית:

רכיב	עלות חודשית (USD)	בשקלים (כולל מע"מ)
Embeddings (ingestion חד-פעמי)	$40	כ-150 ש"ח
Embeddings (שאילתות)	$25	כ-95 ש"ח
pgvector (Postgres managed)	$120	כ-450 ש"ח
Cohere Rerank	$60	כ-225 ש"ח
Claude Sonnet 4.5 (generation)	$900	כ-3,380 ש"ח
סה"כ	~$1,145	כ-4,300 ש"ח

זה כ-43 אגורות לשאילתה. סביר לרוב המוצרים. לא סביר לצ'אט-בוט חינמי המוני. השוואה מהירה: לקוח קמעונאי בתל אביב שעבדתי איתו במרץ 2026 שילם 0.72 ש"ח לשאילתה בארכיטקטורת long-context לפני המעבר ל-RAG, ועכשיו הוא משלם 0.41 ש"ח. חיסכון של 43% בחודש הראשון, בלי אובדן באיכות התשובות שנמדדה ב-A/B test על 1,400 שאילתות.

מה זה אומר לך, תלוי איפה אתה יושב

יש לכם שאלה? בונים משהו ולא יודעים להמשיך?

קהילת BestAI בוואטסאפ, מאות יזמים ובעלי עסקים שמשתמשים ב-AI. שואלים, עונים, משתפים.

הצטרפו לקהילה בוואטסאפ ←

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

מהנדס/ת תוכנה. תתחילו עם 200 שורות Python ו-pgvector. אל תרימו cluster מנוהל לפני שיש לכם 50 שאילתות מבחן שעוברות. תייצרו evaluation set ידני, אפילו 100 דוגמאות מספיקות לחודש הראשון. תזכרו: כל החלטה ב-chunking שמסתירים מאחורי framework תחזור לרדוף אתכם בחודש השני. השקיעו זמן בלוגים מפורטים של כל שלב ב-pipeline, כי דיבאג של RAG בלי לוגים הוא סיוט.

מנהל/ת מוצר. דרשו מהצוות מטריקות מדידות לפני release: recall@5, latency p95, ועלות לשאילתה. בלי השלושה האלה, אין לכם אבן בוחן לאיכות. תקציבו חודשיים של איטרציות אחרי ה-launch, לא תקבלו את זה נכון מהפעם הראשונה. הגדירו threshold אוטומטי שעוצר את המערכת אם הדיוק יורד מתחת ל-80% בבדיקה שבועית.

CTO/מנכ"ל טכנולוגי. הסיכון הגדול הוא לא טכנולוגי, הוא משפטי ורגולטורי. אם המערכת מצטטת מסמך פנימי כתשובה ללקוח, האופן בו הציטוט מוצג משנה. דברו עם היועצת המשפטית לפני ה-launch, לא אחרי. הקפידו על audit log של כל שאילתה ותשובה, גם אם זה מוסיף עלות אחסון. בארגונים פיננסיים בישראל, רשות שוק ההון דורשת שמירה של 7 שנים על כל אינטראקציה עם לקוח שמערבת המלצה אוטומטית.

BestAI Take

אחרי ארבע מערכות RAG ב-production בארץ, יש לי דעה ברורה: הצוותים שמצליחים הם אלה שמתייחסים ל-RAG כאל מנוע חיפוש עם UI של AI, לא כאל AI עם תוסף חיפוש. ההבדל סמנטי, אבל הוא משנה איפה משקיעים את הזמן.

אם אתם בונים RAG הראשון שלכם, אל תתחילו עם framework. תכתבו 200 שורות Python שעושות retrieval מ-pgvector ושולחות ל-Claude. רק כשתבינו איפה זה נשבר, תוסיפו LangChain או LlamaIndex. הספריות האלה מצוינות, אבל הן מסתירות את ההחלטות שאתם חייבים להבין. ופה, בעברית, ההחלטות האלה כפול חשובות. תקראו עוד אצלנו ב-מדריך לסוכני AI כדי להבין איך RAG משתלב בארכיטקטורה רחבה יותר.

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

שאלות נפוצות

›מה ההבדל בין RAG ל-fine-tuning?

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

›איזה vector database לבחור עבור פרויקט בעברית?

לרוב הצוותים בישראל ההמלצה היא pgvector. הסיבות: רוב הצוותים כבר מריצים Postgres, ההרשאות עובדות עם המודל הקיים, אין שירות נוסף לתחזק, וה-latency סביר עד כמיליון וקטורים. מעל זה כדאי לעבור ל-Qdrant, שהוא open source, מהיר, ותומך ב-hybrid search מובנה. Pinecone הוא בחירה טובה אם רוצים שירות managed לחלוטין, אבל המחיר עולה מהר. Weaviate חזק מאוד בתכונות אבל מורכב להפעלה. אין הבדל משמעותי באיכות החיפוש לעברית בין הפלטפורמות, כי האיכות נקבעת ע"י מודל ה-embedding ולא ע"י ה-database.

›כמה זמן לוקח לבנות מערכת RAG ראשונה ל-production?

prototype שעובד אפשר להעמיד בשבוע. מערכת production עם ניהול גרסאות, הרשאות, מוניטורינג ועדכון מסמכים אוטומטי דורשת 6-10 שבועות לצוות של שני מהנדסים. ההפתעות הגדולות הן תמיד באיכות הצ'אנקינג ובטיפול ב-edge cases של מסמכים מקוריים (PDF סרוקים, טבלאות, תמונות עם טקסט). מומלץ לא לחבר את המערכת לחזית למשתמשים לפני שיש לפחות 100 שאילתות מבחן עם תשובות ידועות, ושיעור הדיוק עליהן מעל 85%. ללא זה, המערכת תייצר hallucinations בלי שתדעו, ותאבדו את אמון המשתמשים מהר מאוד.

›איך מתמודדים עם hallucinations במערכת RAG?

שלוש שכבות הגנה. ראשית, prompt engineering: הנחו את המודל לענות רק על בסיס הקטעים שסופקו, ואם אין תשובה, להגיד 'לא יודע'. שנית, ציטוט חובה: דרשו מהמודל לציין chunk ID לכל טענה, ובדקו אוטומטית שה-ID קיים בקטעים שסופקו. שלישית, evaluation מתמשך: בנו set של 200 שאילתות עם תשובות מסומנות, והריצו אותו פעם בשבוע. אם הדיוק יורד, יש בעיה. בנוסף, השתמשו ב-reranker אחרי ה-retrieval כדי לוודא שהקטעים שמגיעים ל-LLM באמת רלוונטיים. בבדיקות שלי, reranker הוריד hallucinations ב-30-40% לעומת similarity search לבד.

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

לא מנוקדת. גם אם המסמך המקורי מנוקד, הסירו ניקוד ב-preprocessing לפני שליחה למודל ה-embedding. הסיבה: ה-tokenizer של רוב המודלים מטפל בכל סימן ניקוד כתו נפרד, מה שגורם לאותה מילה להפוך לוקטורים שונים תלוי אם היא מנוקדת או לא. בבדיקה שעשיתי על corpus של 50,000 מסמכים משפטיים, הסרת ניקוד שיפרה את ה-recall@5 בכ-7 נקודות אחוז. שמרו עותק של הטקסט המקורי המנוקד לתצוגה למשתמש, אבל את הגרסה ה-embedded השאירו נקייה. הקפידו גם להסיר תווים מיוחדים, רווחים כפולים, וסימני עימוד שאינם תורמים למשמעות.

›האם RAG מתאים גם לסטארטאפ קטן בלי תקציב ענן גדול?

בהחלט. אפשר להעמיד מערכת RAG בסיסית על שרת יחיד עם PostgreSQL + pgvector, מודל embedding של Cohere בעלות מינימלית, ו-Claude Haiku ל-generation. עבור סטארטאפ עם 500 שאילתות ביום ו-10,000 מסמכים, העלות החודשית סבירה: כ-$80-120 לחודש כולל הכל. אל תתחילו עם Pinecone או Weaviate Cloud, אלה הוצאות שמתאימות לסקייל גדול יותר. סטארטאפ ישראלי שעבדתי איתו ביצע MVP מלא ב-5 שבועות בתקציב של פחות מ-$500 לכל תקופת הפיתוח, כולל ניסויים והדגמות ללקוחות. הסוד הוא להתחיל פשוט ולהוסיף מורכבות רק כשהמטריקות דורשות זאת.