מדריכים · בעלות על המוצר
מדריכים · בעלות על המוצר
מנוע RAG מעל הנתונים העסקיים שלכם הוא מערכת AI שעונה על שאלה בכך שהיא קודם שולפת את הרשומות הרלוונטיות מתוך המסמכים שלכם, ואז כותבת תשובה שמעוגנת במה שמצאה. RAG הוא ראשי תיבות של retrieval-augmented generation, יצירה מבוססת שליפה. אתם נותנים למודל אינדקס פרטי של החוזים, הנהלים או נתוני המוצר שלכם, ונותנים לו לקרוא את החלקים הנכונים ברגע השאלה. המדריך הזה עובר על מה מנוע RAG עושה, מתי הוא עדיף על fine-tuning, איך בידוד לפי לקוח שומר שהנתונים של לקוח אחד לא ייכנסו לתשובה של אחר, וכמה זה עולה.
מנוע AI מעל נתונים פרטיים הוא החלק שרוב המייסדים מזלזלים בו כשמדובר באירוח עצמי. אם אתם עדיין מחליטים מי מריץ את ה‑stack שלכם, התחילו במדריך המרכזי על מה דורש SaaS בשרת עצמאי בפרודקשן; המדריך הזה מתמקד במנוע שיושב במרכזו.
למנוע RAG יש שני חצאים: retriever ששולף את החלקים הרלוונטיים מהנתונים שלכם, ומודל שכותב מהם תשובה. ה‑retriever מחפש באינדקס פרטי שנבנה מהמסמכים שלכם, והמודל רואה רק את החלקים שנשלפו, בתוספת השאלה עצמה.
הרעיון מגיע מהמאמר מ‑2020 שנתן לו את השם: Lewis ועמיתיו שילבו את משקלי המודל המאומן (זיכרון פרמטרי) עם אינדקס חיצוני שהוא קורא בזמן השאילתה (זיכרון לא‑פרמטרי), וגילו שהשילוב מפיק תשובות ספציפיות ועובדתיות יותר מהמודל לבדו (Lewis et al., 2020). ספקי ענן מתארים את אותה צורה: המודל פונה למאגר ידע מוסמך שמחוץ לנתוני האימון שלו לפני שהוא עונה, וכך הוא יכול לצטט מקור ולהישאר עדכני בלי אימון מחדש (AWS).
הנתונים העסקיים שלכם חיים באינדקס, לא במודל. עדכנתם מסמך, אינדקסתם אותו מחדש, והתשובה הבאה כבר משקפת את השינוי.
RAG מנצח כשהתשובה תלויה בעובדות שמשתנות או שחייבות להיות ניתנות למעקב עד המקור. fine-tuning מנצח כשצריך שהמודל ילמד מיומנות, פורמט או טון שאין לו כבר. אלה בעיות שונות, והתשובה הכנה היא לא פעם שניהם.
ההבדל הוא איפה הידע גר. fine-tuning צורב אותו לתוך המשקלים, אז לעדכן עובדה פירושו לאמן מחדש; RAG שומר אותו באינדקס, אז לעדכן פירושו לערוך מסמך. לנתונים עסקיים שזזים, מחירים, נהלים, מלאי, תיקים, זה מה שמכריע.
| ממד | RAG מעל הנתונים שלכם | fine-tuning |
|---|---|---|
| מה זה משנה | את הנתונים שהמודל יכול לקרוא | את ההתנהגות והסגנון של המודל |
| עדכון עובדה | אינדוקס מחדש של מסמך אחד, דקות | אימון מחדש של המודל |
| ציון מקור | כן, יכול להצביע על הרשומה | לא, התשובה צרובה פנימה |
| מתאים ל | עובדות שמשתנות או חייבות ציטוט | מיומנות, פורמט או טון קבועים |
| כשל כשטועה | שולף את החלק הלא נכון | לומד דפוס לא נכון, קשה יותר לזהות |
רוב השאלות העסקיות נענות בשליפה בלבד. השילוב, fine-tuning פעם אחת לטון ו‑RAG לעובדות החיות, משתלם רק כשבאמת צריך את שניהם.
בידוד לפי לקוח פירושו שנתונים של לקוח אחד לעולם לא יכולים להופיע בתשובה של לקוח אחר, ובמנוע RAG הערובה הזאת חיה ב‑retriever, לא במודל. כל שאילתת שליפה חייבת להיות מוגבלת ללקוח ששואל, לפני שחלק אחד בכלל מגיע למודל.
מצב הכשל שקט. שימו את כל מסמכי הלקוחות באינדקס משותף אחד בלי סינון לפי לקוח, וזה נראה תקין בדמו, ואז יום אחד זה שולף חוזה של מתחרה כי הוא היה ההתאמה הכי קרובה במשמעות. המודל יכתוב ממנו תשובה נקייה. בלי שגיאה, רק דליפה.
אנחנו בונים את הבידוד כמסנן קשיח בזמן השליפה, מפתח לקוח אחד נאכף לכל לקוח, כך ששאילתה יכולה לראות רק את הנתונים של עצמה. במערכת אחת שאנחנו מריצים, כמה ספקי LLM מכסים כל אחד פיצ'ר אחר עם הפרדת נתונים מלאה שנאכפת בשכבת השליפה והניתוב, לא מושארת למודל שיכבד אותה. החורים שנובעים מטעות כאן הם אותם חורים שבאבטחת אפליקציות שנבנו עם AI.
תשובת RAG אמינה כשהיא מעוגנת במקור שנשלף ונבדקת לפני שמישהו פועל לפיה, לא כשהיא סתם נשמעת נכון. כי התשובה מצביעה בחזרה על הרשומה שממנה הגיעה, בודק מאשר את המקור בשניות, ותשובה שאפשר לבדוק עדיפה על תשובה בטוחה שאי אפשר.
מערכת אחת שאנחנו מריצים נשענת על זה חזק. מערכת AI למסמכים משפטיים קוראת את מאגר הראיות של הלקוח ומנסחת מכתבי תגובה בעברית, כשכל אחד מעוגן בחומר הזה ובדין הרלוונטי, וכל טיוטה עוברת כמה שערי אימות לפני שאדם מאשר אותה. השערים קיימים כי תשובה שגויה שנשמעת סבירה, בהקשר הזה, עולה ביוקר. הכלל תקף לכל AI מעל נתונים עסקיים: לשלוף, לעגן, ואז לוודא את העיגון לפני שסומכים על הפלט.
מנוע RAG מעל הנתונים העסקיים שלכם הוא חלק מעבודת פלטפורמת הפרודקשן שאנחנו מתמחרים לפי היקף: ₪35K–60K לפלטפורמה מלאה שכוללת את המנוע, בידוד בין לקוחות, אזור ניהול וגיבויים. קריאות ה‑API של המודל מחויבות לפי צריכה מעל זה, ובלי תוספת אחוזים.
עלות וזמן תגובה מגיעים בעיקר מהשליפה ומקריאת המודל, לא מהאינדקס שיושב על הדיסק. retriever ממוקד שמחזיר כמה חלקים רלוונטיים משאיר את שניהם נמוכים; כזה שדוחס הכול לתוך ה‑prompt מעלה את החשבון ואת ההמתנה בלי תמורה, ולכן הכיוונון הזה הוא המקום שבו בניית RAG מצדיקה את מחירה.
ה‑API של המודל הוא החלק הנמדד במנוע RAG, מחויב לפי צריכה. ה‑retriever הוא המקום שבו העלות מנוצחת או מופסדת: החזירו את שלושת החלקים שעונים על השאלה, לא את השלושים שאולי.
הפירוט המלא לפי רמות נמצא בעמוד התמחור, ברמת Production Platform, ואיפה מנוע RAG משתלב בשאלה הרחבה של מי מחזיק ומריץ את ה‑stack נמצא בשרת עצמאי מול פלטפורמה מנוהלת: השוואה כנה.
מנוע RAG נתקע איפה שהשליפה נתקעת: הוא יכול לענות רק ממה שנמצא באינדקס, והתשובה אף פעם לא טובה יותר מהחלק שנמצא. אם הנתונים חסרים, מבולגנים או מחולקים גרוע, המודל ממלא את החלל בניחוש, ועיגון לא יכול להציל תשובה ששלפה את הדבר הלא נכון. הוא גם לא ילמד את המודל מיומנות חדשה: סגנון חשיבה אחר, פורמט פלט קשיח או טון תחומי שחסר למודל הם עבודה של fine-tuning, לא של שליפה.
המבחן הכנה הוא שאלה אחת: האם התשובה תלויה בנתונים הספציפיים והמשתנים שלכם, והאם מישהו צריך לסמוך עליה? אם כן, RAG מעל הנתונים שלכם הוא המנוע הנכון. אם לא, אתם מוסיפים מכונה לבעיה שאין לכם.
אם אתם רוצים מנוע AI שעונה מהנתונים שלכם ושומר את הרשומות של כל לקוח אצלו, קבלו הצעת מחיר כתובה למנוע RAG מעל הנתונים העסקיים שלכם. היא בתוקף 14 יום, ואומרת מה נבנה, מה נשאר מחויב לפי צריכה, וכמה זה עולה.
מייסד והמפתח הראשי של Zyntari. בונה אפליקציות ופתרונות AI מאז 2024; לפני כן, 12 שנים במכירות וניהול תיקי לקוחות ושותף‑מייסד בשתי חברות. עוד על הצוות · LinkedIn