RAG – איך בונים עוזר AI על המידע של העסק

מה זה, בשורה אחת

RAG (קיצור של Retrieval-Augmented Generation) היא שיטה שבה המודל מחפש קודם במסמכים שלכם, ורק אז מנסח תשובה — במקום לענות מהזיכרון.

זה ההבדל בין עוזר שיודע דברים כלליים לעוזר שיודע את הדברים שלכם.

למה זה פותר את הבעיה הגדולה

מודל שפה מנבא את המילה הבאה. הוא לא מאגר עובדות, ולכן הוא ייצר תשובה משכנעת גם על נוהל שלא קיים — הסברנו את המכניקה בערך המילון על LLM.

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

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

איך זה עובד, בלי מונחים

שלושה שלבים:

אוספים ומפרקים. כל המסמכים שלכם מפורקים לקטעים קטנים.

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

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

מה באמת נדרש — והחלק שמפתיע

כאן ההבדל בין הדגמה מרשימה למערכת שעובדת.

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

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

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

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

מתי זה שווה, ומתי לא

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

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

והסף המעשי: אם אתם לא יכולים להצביע על עשרה מסמכים קיימים ומעודכנים שהמערכת תעבוד עליהם — זה מוקדם מדי.

קודם תנסו את הגרסה בלי פיתוח

זו ההמלצה שתחסוך לכם הכי הרבה כסף.

לפני שבונים משהו, יש כלים מדף שעושים בדיוק את זה — מעלים אליהם מסמכים והם עונים מתוכם, עם ציטוט מקור. כתבנו על אחד מהם במדריך NotebookLM.

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

כמה זה עולה

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

מה שכן — תשאלו את ארבע השאלות שפירטנו בכמה עולה להטמיע AI: מה כלול באפיון, לאילו מערכות זה מתחבר, מה קורה כשהכלי לא יודע, ומה העלות החודשית אחרי המסירה.

ושימו לב: מערכות כאלה גובות גם לפי שימוש. הצעה עם מחיר חד-פעמי בלבד מסתירה חלק מהעלות.

פרטיות

המידע שלכם עובר למקום כלשהו — זו כל מהות העניין. תבררו לאן, מה נשמר, ומי יכול לגשת.

בענפים מוסדרים זה חמור יותר: תקנות רופאי השיניים אוסרות שימוש במידע שעלול לזהות מטופל אף בהסכמתו. ראו שיווק למרפאות שיניים.

שלוש שאלות שיגידו לכם אם אתם מוכנים

לפני שמדברים עם מישהו על בנייה, תענו על אלה בעצמכם:

איפה המידע נמצא עכשיו? אם התשובה היא "אצל יוסי" — זה לא פרויקט AI, זה פרויקט תיעוד. ושווה לעשות אותו בכל מקרה, כי עסק שתלוי בראש של אדם אחד שביר.

מה השאלה שחוזרת הכי הרבה? אם אתם לא יודעים — תרשמו שבוע. התשובה היא גם מה שהמערכת צריכה לפתור וגם המדד להצלחה שלה.

ומה קורה היום כשאין תשובה? מישהו שואל אתכם. מערכת צריכה לעשות בדיוק את זה — להגיד שהיא לא יודעת ולהעביר — ולא להמציא.

הטעות היקרה ביותר

לבנות מערכת לפני שבודקים שיש בעיה.

עסקים מתלהבים מההדגמה — שואלים שאלה, מקבלים תשובה מהמסמך שלהם, מרשים. ואז מגלים שבפועל השאלה הזו נשאלת פעמיים בחודש, ושעובד ענה עליה בשתי דקות.

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

שאלות נפוצות

זה אומר שהמערכת לא תמציא יותר?

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

כמה מסמכים צריך?

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

אפשר לחבר את זה למערכות שלנו?

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

כמה זמן לוקח לבנות?

גרסת ניסיון עם כלי מדף — ימים. מערכת מותאמת עם חיבורים ובדיקות — חודשיים ומעלה, ורוב הזמן הולך על ארגון המידע ועל בדיקות, לא על קוד.

שורה תחתונה

RAG פותר את הבעיה הנכונה — תשובות מהמידע שלכם ולא מהזיכרון של המודל.

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