RAG: איך מחברים AI לדאטה של החברה בלי להשאיר אותו בחוץ
AI שלא יודע מה קורה בחברה שלך — חסר ערך. RAG פותר את זה. הנה איך עושים את זה נכון, צעד אחר צעד.
RAG: איך מחברים AI לדאטה של החברה בלי להשאיר אותו בחוץ
AI שלא יודע מה קורה בחברה שלך — חסר ערך לגמרי.
תשובה ישירה: RAG (Retrieval-Augmented Generation) מאפשר לכל מודל AI לענות על שאלות על בסיס המסמכים, הנהלים והמידע הפנימי שלך — בלי לאמן מודל מחדש. זמן הטמעה: 2–6 שבועות. עלות: 8,000–35,000 ₪ תלוי בהיקף. החזר: מדיד כבר בחודש הראשון.
הבעיה: GPT חכם, אבל לא יודע כלום על החברה שלך
כשלקוח שואל "מה מדיניות ההחזרות שלנו?" — GPT יסתמך על ניחוש כללי. כשעובד חדש שואל "מה התהליך לאישור הצעת מחיר?" — הוא יקבל תשובה גנרית ולא רלוונטית.
הסיבה: מודלי AI אומנו על מידע כללי מהאינטרנט. הם לא קראו את הנהלים שלך, לא ראו את חוזי הלקוחות שלך, לא יודעים איך הצוות שלך עובד.
RAG פותר את זה — לא על ידי אימון מחדש, אלא על ידי חיבור חכם בין השאלה לבין מסמכי החברה.
שלב 1: אוספים ומארגנים את מאגר המידע
לפני שנוגעים בקוד, צריך להחליט מה ה-AI יקרא.
בלקוחות שלי אני מתחיל עם שלושה מקורות: נהלים פנימיים, שאלות נפוצות שצוות השירות מקבל, ומסמכי מוצר או מחירון. לא מנסים לאכול את הפיל בבת אחת.
הפלט של השלב הזה: תיקייה עם קבצים נקיים ב-PDF, Word או Markdown — ממספר עשרות ועד כמה מאות מסמכים.
טעות נפוצה: להוסיף כל דבר שנמצא בחברה. מסמכים ישנים, כפולים, או סותרים — יורידו את איכות התשובות.
שלב 2: הופכים מסמכים לווקטורים (Embeddings)
זה החלק ה"קסמי" של RAG.
כל מסמך מפוצל לקטעים קטנים (chunks) של כ-300–500 מילים. כל קטע עובר דרך מודל המרה שהופך אותו למערך מספרי — ווקטור. הווקטורים נשמרים במסד נתונים ייעודי (vector database) כמו Pinecone, Weaviate, או pgvector על PostgreSQL רגיל.
כשמשתמש שואל שאלה, השאלה עצמה הופכת לווקטור — והמערכת מוצאת את הקטעים הכי קרובים משמעותית.
בישראל אני עובד בעיקר עם OpenAI Embeddings לצד Pinecone. עלות חודשית למאגר של כמה אלפי מסמכים: כ-200–800 ₪.
שלב 3: בונים את שרשרת השליפה-יצירה
הנה הלוגיקה בפועל:
- משתמש שואל שאלה
- השאלה הופכת לווקטור
- המערכת מוצאת 3–5 קטעים רלוונטיים מהמאגר
- שולחים לGPT: "ענה על השאלה הזו רק על בסיס הקטעים האלה"
- GPT מנסח תשובה טבעית — עם מקורות
ה-prompt שמגדיר את ההתנהגות קריטי. בלי הגבלה ברורה, המודל ימציא מידע שלא קיים במסמכים.
שלב 4: ממשק וחיבור לכלי העבודה הקיימים
ה-RAG הוא ליבה טכנולוגית — לא מוצר. צריך לעטוף אותה:
- צ'אט פנימי לעובדים — ממשק פשוט דרך Slack, Teams, או דף אינטרנט פנימי
- בוט שירות לקוחות — מחובר לאתר או לוואטסאפ
- כלי חיפוש פנימי — לאנשי מכירות שמחפשים מידע על מוצרים במהירות
בפרויקט אחרון עם חברת ביטוח בת 40 עובדים: בנינו RAG על מאגר של 180 נהלים. עובדים שבעבר בזבזו 15–20 דקות לחיפוש תשובה לסוכן — מוצאים אותה תוך 40 שניות. חיסכון של כ-3 שעות עבודה ביום בצוות שלם.
שלב 5: מדידה ושיפור מתמשך
RAG לא גמור ביום ההשקה — הוא מתחיל ביום ההשקה.
מה צריך למדוד:
- אחוז תשובות עם מקור (target: מעל 85%)
- שאלות שהמערכת לא ידעה לענות — אלה פערים במאגר
- פידבק משתמשים — אגודל למעלה/למטה מספיק כנקודת התחלה
כל חודש מוסיפים מסמכים חדשים, מסירים ישנים, ומעדכנים את ה-chunks בהתאם.
מה RAG לא מחליף
RAG מצוין לשאלות עובדתיות על מידע קיים. הוא לא מחליף שיפוט אנושי, לא מתאים להחלטות רגישות, ולא יעיל כשהמסמכים עצמם לא מעודכנים.
בחברה שהמידע הפנימי שלה מפוזר, סותר, וישן — RAG ייצור בלגן חכם יותר. לפני שבונים, צריך לנקות.
אם אתם רוצים להבין מה נכון לבנות אצלכם — ובאיזה תקציב — קבעו שיחת ייעוץ של 30 דקות חינם. אני אעבור איתכם על המידע שיש לכם, ואגיד לכם ישר מה RAG יפתור ומה לא.
צריכים עזרה ליישם את זה בעסק?
Alpha MF מתמחה באוטומציה, AI, ואינטגרציות. שיחת ייעוץ ראשונה — 30 דקות חינם.
דברו איתנו ←