מדריך: כך בונים בסיס ידע RAG בעברית לעסק שלכם ב-2026

כמעט כל עסק ישראלי יושב על הר של ידע: נהלים, חוזים, מיילים, מסמכי מוצר ותכתובות עם לקוחות. הבעיה היא שרוב הידע הזה כתוב בעברית, מפוזר בין קבצי Word, PDF ו-Google Drive, ואף מודל שפה לא מכיר אותו. מערכת RAG (Retrieval-Augmented Generation) פותרת בדיוק את זה: היא מאפשרת לצ'אטבוט לענות על שאלות מתוך המסמכים שלכם, בעברית, בלי לאמן שום מודל. במדריך הזה נבנה אחת כזאת מאפס.

01מה זה RAG ולמה לא פשוט fine-tuning

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

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

02שלב 1: הכנת המסמכים וחיתוך נכון לעברית

האיכות של מערכת RAG נקבעת עוד לפני שנוגעים במודל, בשלב ה-chunking: חיתוך המסמכים לקטעים שיאונדקסו. חיתוך גס מדי (עמוד שלם) מטביע את התשובה ברעש; חיתוך דק מדי (משפט בודד) מאבד הקשר. נקודת פתיחה טובה למסמכים עסקיים בעברית היא קטעים של 300 עד 500 טוקנים עם חפיפה של כ-15 אחוז בין קטעים סמוכים.

• המירו הכול לטקסט נקי: PDF סרוקים דורשים OCR שתומך בעברית, ובדקו ידנית שהכיווניות (RTL) לא התהפכה בהמרה.
• חתכו לפי מבנה לוגי, כותרות וסעיפים, ולא לפי מספר תווים שרירותי. ספריות כמו LangChain ו-LlamaIndex תומכות ב-splitters מבוססי כותרות.
• צרפו לכל chunk מטא-דאטה: שם המסמך, תאריך עדכון, מחלקה. זה קריטי לסינון ולציטוט מקורות בתשובה.
• נקו טבלאות מורכבות או המירו אותן לטקסט מובנה; טבלה שנשברה באמצע היא מתכון לתשובות שגויות.
• הסירו מראש מידע רגיש שאסור שיגיע לבוט: תעודות זהות, שכר, פרטים רפואיים.

03שלב 2: embeddings שבאמת מבינים עברית

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

אל תסתמכו על מוניטין: בנו סט בדיקה קטן של 30 עד 50 שאלות אמיתיות מהעסק שלכם, עם הקטע ה"נכון" שאמור להישלף לכל שאלה, והריצו עליו כמה מודלי embeddings. מדד פשוט כמו recall@5 (האם הקטע הנכון בין חמשת הראשונים) יגלה לכם תוך שעה איזה מודל מתאים לעברית שלכם.

04שלב 3: בסיס נתונים וקטורי וקוד עובד

לרוב העסקים בישראל אין צורך בתשתית ייעודית יקרה. אם אתם כבר על PostgreSQL, ההרחבה pgvector נותנת חיפוש וקטורי מהיר בלי שירות נוסף. חלופות פופולריות: Qdrant ו-Chroma בקוד פתוח, או Pinecone כשירות מנוהל. עד כמה מאות אלפי קטעים, pgvector עם אינדקס HNSW יספיק בשקט.

טיפ ששווה זהב בעברית: חיפוש היברידי. שלבו חיפוש וקטורי עם חיפוש מילות מפתח (BM25 או full-text של Postgres), כי שמות מוצרים, מספרי דגם וראשי תיבות בעברית נוטים ללכת לאיבוד בחיפוש סמנטי טהור. שכבת reranking על עשרים התוצאות הראשונות משפרת עוד את הדיוק. כך נראית ליבת השליפה בפייתון:

# שליפה היברידית בסיסית עם pgvector
query_vec = embed(question)  # אותו מודל embeddings של האינדוקס

rows = db.execute("""
    SELECT chunk_text, source, updated_at,
           1 - (embedding <=> %s) AS score
    FROM chunks
    WHERE department = %s
    ORDER BY embedding <=> %s
    LIMIT 20
""", (query_vec, dept, query_vec))

context = "\n---\n".join(r.chunk_text for r in rerank(question, rows)[:5])
answer = llm.chat(
    system="ענה בעברית אך ורק על סמך ההקשר. אם התשובה לא בהקשר, אמור זאת וציין את המקור.",
    user=f"הקשר:\n{context}\n\nשאלה: {question}"
)

05שלב 4: חיבור למודל, בדיקות והרצה בייצור

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

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

06השורה התחתונה לעסק הישראלי

פרויקט RAG בסיסי בעברית הוא עניין של ימים בודדים למפתח אחד, לא רבעון של צוות. ההשקעה המשתלמת ביותר היא לא במודל הכי חדש אלא בשלושה דברים משעממים: חיתוך מסמכים נכון, בדיקת embeddings על עברית אמיתית שלכם, וסט בדיקה שרץ בכל שינוי. מי שיעשה את זה נכון יקבל עובד ידע שזמין 24/7, עונה בעברית רהוטה, ותמיד מצטט את המקור.