הבעיה: המידע קיים, אבל אף אחד לא מוצא אותו
בכל ארגון בינוני ומעלה יש מאות ואלפי מסמכים: נהלים, חוזים, פרוטוקולים, מסמכי מוצר, מיילים, מצגות ועוד. המידע קיים, אבל הוא מפוזר בין תיקיות, דרייבים, מערכות פנימיות ותיבות מייל. עובד שצריך תשובה לשאלה ספציפית מבזבז דקות ושעות על חיפוש, או פשוט פונה לקולגה שאולי יודע ואולי לא.
מודלי שפה (LLMs) כמו GPT או Claude יודעים לענות על שאלות בשפה טבעית, אבל הם לא מכירים את המסמכים הפנימיים של הארגון. הם אומנו על מידע כללי מהאינטרנט, לא על הנהלים של חברת הביטוח שלכם או על מפרטי המוצר של היצרן. כאן נכנס לתמונה RAG.
RAG, או Retrieval Augmented Generation, היא ארכיטקטורה שמחברת בין מנוע חיפוש חכם לבין מודל שפה. במקום שהמודל ינסה "לזכור" את התשובה מהאימון שלו, המערכת מחפשת קודם את המידע הרלוונטי במסמכים של הארגון, ואז מזינה אותו למודל כדי שיחולל תשובה מדויקת ומבוססת. התוצאה: מערכת שעונה על שאלות בשפה טבעית, עם הפניות למקור, ובלי הזיות.
SysTech, חברת תוכנה ישראלית עם למעלה מעשר שנות פעילות, מפתחת מערכות RAG מותאמות לארגונים ישראליים. שירותי פיתוח AI של SysTech כוללים בניית מערכות שליפת מידע חכמות מקצה לקצה, כולל התמודדות עם האתגרים הייחודיים של עברית ומסמכים דו-לשוניים.
למה LLM לבד לא מספיק לנתונים ארגוניים
יש פיתוי להגיד "נזין את כל המסמכים שלנו ל-ChatGPT ונסיים עם זה". בפועל, הגישה הזו לא עובדת, ויש לכך כמה סיבות מהותיות:
גודל הקונטקסט מוגבל. גם מודלים עם חלון קונטקסט של 100K או 200K טוקנים לא יכולים להכיל אלפי מסמכים בו-זמנית. ארגון בינוני מחזיק עשרות גיגה-בייט של מסמכי טקסט, הרבה מעבר ליכולת של כל מודל.
דיוק יורד עם נפח. מחקרים מראים שככל שמזינים יותר טקסט לחלון הקונטקסט, היכולת של המודל לאתר מידע ספציפי יורדת. תופעה שנקראת "Lost in the Middle", כשמידע שנמצא באמצע מסמך ארוך פשוט נבלע.
עלויות שוטפות גבוהות. שליחת כל המסמכים בכל שאילתה (Query) עולה הרבה כסף. חיוב ה-API הוא לפי טוקנים, ושליחת 100K טוקנים בכל שאלה תאמיר את העלות פי 50 ומעלה לעומת שליחה ממוקדת של קטעים רלוונטיים.
Fine-tuning אינו פתרון מלא. כוונון עדין (Fine-tuning) של מודל על המסמכים הפנימיים משנה את הסגנון והידע הכללי של המודל, אבל לא מבטיח שהוא יצטט מסמכים ספציפיים בצורה מדויקת. בנוסף, כל פעם שמתווסף מסמך חדש צריך לאמן מחדש, תהליך יקר ואיטי.
RAG פותר את כל הבעיות האלה: המערכת שולפת רק את הקטעים הרלוונטיים ביותר, מזינה אותם למודל, ומקבלת תשובה מדויקת תוך שניות. כשמתווסף מסמך חדש, מספיק להוסיף אותו לאינדקס ללא צורך באימון מחדש.
הצינור המלא: מהמסמך עד התשובה
מערכת RAG מורכבת משני שלבים עיקריים: הכנת המסמכים (Ingestion) ותהליך מענה לשאילתה (Query Pipeline). להלן פירוט של כל שלב:
שלב 1: קליטת מסמכים (Document Ingestion)
התהליך מתחיל באיסוף המסמכים מכל המקורות: Google Drive, SharePoint, מערכת ניהול מסמכים פנימית, מיילים, PDFs, מסמכי Word ומצגות. כל מסמך עובר עיבוד ראשוני (Parsing) שמחלץ ממנו טקסט נקי. לפעמים זה פשוט (קובץ טקסט), ולפעמים מורכב (PDF סרוק שדורש OCR, או מצגת עם תרשימים).
שלב 2: חלוקה לקטעים (Chunking)
מסמך שלם הוא יחידה גדולה מדי לחיפוש יעיל. לכן המסמכים מחולקים לקטעים (Chunks) בגודל אופטימלי, בדרך כלל 200 עד 1,000 טוקנים. אסטרטגיית ה-Chunking היא אחד ההחלטות הקריטיות ביותר בבניית מערכת RAG, ונרחיב עליה בהמשך.
שלב 3: יצירת Embeddings
כל קטע טקסט עובר דרך מודל Embedding שממיר אותו לוקטור מספרי, רצף של מספרים שמייצג את המשמעות הסמנטית של הטקסט. קטעים עם משמעות דומה יקבלו וקטורים קרובים זה לזה במרחב המתמטי. מודלים נפוצים ליצירת Embeddings כוללים את text-embedding-004 של Google ואת ada-002 של OpenAI.
שלב 4: אחסון ב-Vector Database
הוקטורים נשמרים במסד נתונים וקטורי שמאפשר חיפוש מהיר לפי דמיון סמנטי. על האפשרויות העיקריות נרחיב בהמשך.
שלב 5: שליפה (Retrieval)
כשמשתמש שואל שאלה, השאלה עצמה עוברת את אותו תהליך Embedding, והמערכת מחפשת את הקטעים הקרובים ביותר מבחינה סמנטית. בדרך כלל שולפים 3 עד 10 קטעים רלוונטיים.
שלב 6: יצירת תשובה (Generation)
הקטעים שנשלפו מוזנים כהקשר (Context) לפרומפט של מודל השפה, יחד עם השאלה המקורית. המודל מחולל תשובה שמבוססת על המידע שסופק לו, כולל הפניות למקורות.
מסדי נתונים וקטוריים: האפשרויות העיקריות
הבחירה של Vector Database היא החלטה ארכיטקטונית שמשפיעה על ביצועים, עלות ותחזוקה לאורך זמן. הנה שלוש האפשרויות הנפוצות ביותר:
Pinecone
שירות מנוהל (Managed Service) שלא דורש ניהול תשתית. מתאים לצוותים שרוצים להתחיל מהר בלי להתעסק עם Ops. מחיר ההתחלה נגיש (תוכנית חינמית עם 100K וקטורים), אבל העלויות עולות מהר בנפחים גדולים. היתרון המרכזי: פשטות. החיסרון: נעילה לספק (Vendor Lock-in) ופחות שליטה.
Weaviate
מסד נתונים וקטורי קוד פתוח שאפשר להריץ על GCP כ-Container או להשתמש בגרסה המנוהלת שלהם (Weaviate Cloud). תומך בחיפוש היברידי שמשלב חיפוש וקטורי עם חיפוש מילות מפתח קלאסי, מה שמשפר את הדיוק בצורה משמעותית. אופציה מצוינת לארגונים שרוצים שליטה מלאה על הנתונים.
pgvector
הרחבה ל-PostgreSQL שמוסיפה יכולות חיפוש וקטורי למסד נתונים רלציוני קיים. אם הארגון כבר משתמש ב-PostgreSQL (ורבים כן, במיוחד על Cloud SQL של GCP), אפשר להוסיף יכולות וקטוריות בלי להכניס טכנולוגיה חדשה לסטאק. מתאים למערכות עם עד מיליון וקטורים, ומעבר לזה הביצועים פחות תחרותיים.
ב-SysTech, הבחירה בין האפשרויות נעשית לפי מספר קריטריונים: נפח המסמכים, דרישות הביצועים, התשתית הקיימת אצל הלקוח, ורמת השליטה הנדרשת. צוות הפיתוח של SysTech מתמחה בבניית ארכיטקטורות מותאמות על בסיס Node.js ותשתיות GCP, ומתאים את הפתרון לצורך הספציפי.
אסטרטגיות Chunking: איפה רוב המערכות נופלות
Chunking שגוי הוא הסיבה מספר אחת לתוצאות גרועות במערכות RAG. חלוקה גסה מדי גורמת לכך שהשליפה מחזירה קטעים ארוכים שרק חלק קטן מהם רלוונטי. חלוקה דקה מדי גורמת לאובדן הקשר.
חלוקה לפי גודל קבוע (Fixed-size Chunking)
הגישה הפשוטה ביותר: חלוקת הטקסט לקטעים של גודל אחיד, למשל 512 טוקנים, עם חפיפה (Overlap) של 50 עד 100 טוקנים בין קטעים סמוכים. החפיפה מבטיחה שמשפטים שנחתכים באמצע לא יאבדו לגמרי. הגישה עובדת סביר אבל מתעלמת ממבנה המסמך.
חלוקה סמנטית (Semantic Chunking)
גישה מתקדמת יותר שמשתמשת ב-Embeddings כדי לזהות גבולות טבעיים בטקסט. כשהמשמעות הסמנטית משתנה בצורה חדה בין משפטים, המערכת מזהה שמדובר בנושא חדש ומבצעת חלוקה. התוצאה: קטעים שכל אחד מהם עוסק בנושא אחד ברור.
חלוקה לפי מבנה המסמך (Document Structure Chunking)
ניצול מבנה המסמך (כותרות, פסקאות, סעיפים, טבלאות) כבסיס לחלוקה. גישה זו עובדת מצוין עם מסמכים מובנים כמו חוזים, נהלים ומפרטי מוצר, שבהם לכל סעיף יש כותרת ותוכן ברורים. מסמכים לא מובנים (מיילים, פרוטוקולים) דורשים גישות אחרות.
ההמלצה המעשית
ברוב הפרויקטים ב-SysTech, הגישה שמניבה את התוצאות הטובות ביותר היא שילוב: חלוקה ראשונית לפי מבנה המסמך, עם חלוקה משנית לפי גודל לקטעים גדולים מדי, ותוספת מטא-דאטה (שם המסמך, כותרת הסעיף, תאריך) לכל קטע. המטא-דאטה מאפשר סינון מדויק ושיפור איכות התוצאות.
הערכת איכות: איך יודעים שהמערכת עונה נכון
בניית מערכת RAG בלי מנגנון הערכה זה כמו לשגר מערכת לייצור בלי בדיקות. צריך למדוד שני דברים: איכות השליפה ואיכות התשובה.
מדדי שליפה (Retrieval Metrics)
Recall@K: מתוך כל הקטעים הרלוונטיים שקיימים במסד, כמה מהם נכללו ב-K הקטעים שנשלפו? ערך טוב הוא 0.8 ומעלה.
Precision@K: מתוך K הקטעים שנשלפו, כמה מהם באמת רלוונטיים? ערך גבוה מדי על חשבון Recall עלול לפספס מידע חשוב.
MRR (Mean Reciprocal Rank): באיזה מיקום מופיע הקטע הרלוונטי ביותר? אם הוא תמיד ראשון, ה-MRR יהיה 1.0.
מדדי תשובה (Generation Metrics)
Faithfulness: האם התשובה מבוססת אך ורק על הקטעים שסופקו, או שהמודל "המציא" מידע? מדד קריטי למניעת הזיות.
Answer Relevancy: האם התשובה עונה על השאלה שנשאלה? מודל יכול לייצר תשובה נאמנה למקורות אבל לא רלוונטית לשאלה.
כלים למדידה
כלים כמו RAGAS (RAG Assessment) מאפשרים להריץ הערכות אוטומטיות על סט שאלות ותשובות מוכנות מראש. בפרויקט טיפוסי, מכינים 50 עד 200 זוגות של שאלה ותשובה נכונה, ומריצים את המערכת כדי לראות כמה מהתשובות עומדות ברף. ב-SysTech, כל מערכת RAG כוללת סט הערכה מותאם שמשמש גם כמערך בדיקות רגרסיה לאורך זמן.
תרחישי שימוש מעשיים
מאגר ידע פנימי (Internal Knowledge Base)
עובד חדש שמצטרף לחברה שואל "מה מדיניות ימי החופשה?" או "איך פותחים קריאת שירות ל-IT?". במקום לחפש בעשרות מסמכים או לשאול קולגות, המערכת מחזירה תשובה מדויקת עם הפנייה למסמך הנוהל הספציפי. ארגונים שהטמיעו מערכת כזו מדווחים על ירידה של 40% עד 60% בפניות לגורמי תמיכה פנימיים.
חיפוש מסמכים משפטיים
משרד עורכי דין עם אלפי חוזים ותקדימים. עורך הדין שואל "מה הסנקציות על הפרת סעיף סודיות בחוזים שחתמנו מול ספקים ב-2024?" והמערכת סורקת את כל החוזים הרלוונטיים, מחלצת את הסעיפים הספציפיים, ומרכזת את התשובה עם הפניות מדויקות לכל חוזה.
תמיכת לקוחות
חברת SaaS עם אלפי עמודי תיעוד, מדריכים ותשובות לשאלות נפוצות. נציג תמיכה שמקבל פנייה מלקוח שואל את המערכת ומקבל תשובה מדויקת תוך שניות, כולל קישור לעמוד התיעוד הרלוונטי. או לחלופין, הלקוח עצמו משתמש בצ'אט-בוט שמשתמש ב-RAG כדי לענות ישירות, מה שמפחית את העומס על צוות התמיכה.
מערכת Compliance רגולטורי
חברות שנדרשות לעמוד ברגולציות (פיננסיות, רפואיות, הגנת פרטיות) מתמודדות עם מאות עמודי רגולציה שמשתנים תדיר. מערכת RAG מאפשרת לשאול "האם הנוהל שלנו לאיסוף מידע אישי עומד בתקנות הגנת הפרטיות העדכניות?" ולקבל תשובה שמשווה בין הנוהל הפנימי לדרישות הרגולציה.
עלויות וזמני הטמעה
עלויות פיתוח
מערכת RAG בסיסית לארגון (עד 10,000 מסמכים, ממשק צ'אט פשוט): 80,000 עד 180,000 שקל. מערכת RAG מתקדמת (חיפוש היברידי, מספר מקורות מידע, ניהול הרשאות, דשבורד אנליטיקה): 180,000 עד 400,000 שקל.
עלויות שוטפות
עלויות API של מודל השפה: 2,000 עד 15,000 שקל בחודש, תלוי בנפח השימוש. עלויות תשתית GCP (מסד נתונים, חישוב, אחסון): 1,500 עד 8,000 שקל בחודש. עלויות Vector Database מנוהל (אם נבחר): 500 עד 5,000 שקל בחודש.
לוח זמנים
POC (הוכחת היתכנות) על מדגם מסמכים: 2 עד 4 שבועות. מערכת ייצור מלאה עם אינטגרציות: 2 עד 5 חודשים. שלב ייצוב וכוונון איכות: 2 עד 4 שבועות נוספים.
ההמלצה היא להתחיל תמיד עם POC ממוקד על תחום ספציפי (למשל רק מסמכי נהלים, או רק תיעוד מוצר) ולהרחיב בהדרגה. כך אפשר להוכיח ערך מהר ולצבור ביטחון לפני השקעה גדולה.
אתגרים ייחודיים בעברית
בניית מערכת RAG בעברית היא לא פשוט "אותו דבר באנגלית, רק הפוך". יש כמה אתגרים ספציפיים שצריך לקחת בחשבון:
כיווניות טקסט מעורבת (BiDi)
מסמכים עסקיים בישראל מערבבים עברית עם אנגלית, מספרים, שמות מוצרים ומונחים טכניים. תהליך ה-Parsing צריך לטפל נכון בכיווניות הטקסט כדי לא לשבור משפטים שמכילים מילים בשתי השפות.
מורפולוגיה עשירה
עברית היא שפה מורפולוגית עשירה: המילה "שיחפשו" מכילה את "ש" (מילת קישור), "י" (עתיד), "חפש" (שורש), "ו" (רבים). זה אומר שחיפוש מילת מפתח פשוט מפספס הרבה: מי שמחפש "חיפוש" לא בהכרח ימצא מסמך שמכיל "לחפש" או "שיחפשו". חיפוש וקטורי פותר חלק מהבעיה כי הוא עובד ברמה סמנטית, אבל בחיפוש היברידי צריך לקחת את זה בחשבון.
מודלי Embedding לעברית
רוב מודלי ה-Embedding מוכוונים לאנגלית. מודלים רב-לשוניים (Multilingual) כמו Cohere Multilingual או multilingual-e5-large עובדים סביר עם עברית, אבל לפעמים יש צורך בכוונון עדין כדי להגיע לדיוק גבוה. בבדיקות שערך צוות SysTech, ההבדל בין מודל כללי למודל מכוונן לעברית יכול להגיע ל-15% עד 25% בדיוק השליפה.
מסמכים סרוקים ו-OCR
הרבה ארגונים ישראליים עדיין עובדים עם מסמכים סרוקים (PDFs של פקסים, חוזים חתומים, מסמכי רגולציה ישנים). OCR בעברית השתפר מאוד בשנים האחרונות, אבל עדיין דורש בדיקת איכות ולפעמים תיקון ידני, במיוחד במסמכים עם כתב יד או סריקה באיכות נמוכה.
הצעד הבא: פיילוט RAG לארגון שלכם
הדרך הנכונה להתחיל היא עם פיילוט ממוקד. לא צריך לגעת בכל המסמכים של הארגון ביום הראשון. מספיק לבחור תחום אחד, מאגר מסמכים מוגדר, ו-10 עד 20 שאלות לדוגמה שמייצגות את מה שהמשתמשים צריכים.
SysTech מלווה ארגונים בתהליך הזה מהצעד הראשון: בחירת תחום הפיילוט, ניתוח המסמכים הקיימים, בניית ה-Pipeline הטכני על תשתית GCP ו-Node.js, ומדידת איכות התוצאות. הפיילוט לוקח 2 עד 4 שבועות ובסופו הארגון מקבל מערכת עובדת עם מדדים ברורים שמאפשרים להחליט על המשך.
לתיאום פגישת ייעוץ ראשונית ללא עלות, צרו קשר עם SysTech
למידע נוסף על שירותי פיתוח AI של SysTech | שירותי פיתוח תוכנה | אודות החברה
שאלות נפוצות (FAQ)
מה ההבדל בין RAG לבין Fine-tuning של מודל שפה?
Fine-tuning משנה את המודל עצמו על ידי אימון נוסף על נתונים ספציפיים. RAG לא משנה את המודל, אלא מזין לו מידע רלוונטי בזמן אמת. Fine-tuning מתאים לשינוי סגנון או התנהגות של המודל, אבל RAG עדיף כשצריך תשובות מדויקות על בסיס מסמכים ספציפיים, כי הוא מאפשר הפנייה למקור ועדכון מיידי ללא אימון מחדש.
האם RAG מתאים למסמכים סודיים?
כן. מערכת RAG מותאמת רצה על התשתית של הארגון (למשל GCP בפרויקט ייעודי), והמסמכים לא יוצאים מגבולות הארגון. אפשר להגדיר הרשאות ברמת מסמך או ברמת משתמש, כך שכל עובד רואה רק מידע שהוא מורשה לראות. שליחת השאילתות ל-API של מודל השפה מתבצעת ללא חשיפת המסמכים המלאים, רק הקטעים הרלוונטיים.
כמה מסמכים צריך כדי שזה יהיה שווה?
אין סף מינימלי טכני, אבל מבחינה עסקית, הערך המוסף מתחיל להיות משמעותי מאות מסמכים ומעלה, או כשחיפוש רגיל (Full-text Search) כבר לא מספק כי השאלות דורשות הבנה סמנטית. ארגון עם 50 מסמכים עשוי להסתפק בחיפוש טקסט רגיל, אבל ארגון עם 5,000 מסמכים ירוויח משמעותית מ-RAG.
מה קורה כשמתווסף מסמך חדש?
המסמך עובר את תהליך ה-Ingestion (עיבוד, חלוקה, Embedding) ומתווסף לאינדקס הוקטורי. התהליך אוטומטי ולוקח מספר שניות עד דקות, תלוי בגודל המסמך. מרגע שהמסמך נוסף לאינדקס, הוא זמין לשליפה בשאילתות הבאות ללא צורך באימון מחדש.
האם אפשר לדעת מאיפה המערכת לקחה את התשובה?
בהחלט, וזה אחד היתרונות המרכזיים של RAG. כל תשובה כוללת הפניות (Citations) לקטעים הספציפיים שמהם נשלף המידע, כולל שם המסמך, מספר העמוד או הסעיף, ולפעמים גם ציטוט ישיר מהמקור. זה מאפשר למשתמש לאמת את התשובה ולהעמיק בנושא אם צריך.
