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 שאילתות.
מה זה אומר לך, תלוי איפה אתה יושב
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 ימשיך לפרסם מדריכים הנדסיים בעברית. זה התחום שהכי חסר אצלנו, וזה התחום שהכי מעניין.