ארכיטקטורת AI · RAG
RAG לא מספיק: RAG בסיסי מול Agentic RAG מול GraphRAG מול היגיון רקורסיבי
RAG לא מת — RAG בסיסי פשוט לא מספיק ל-AI ארגוני רציני. מדריך מעשי לחמש הארכיטקטורות שחברות באמת בוחרות ביניהן: RAG בסיסי, RAG מתקדם, Agentic RAG, GraphRAG והיגיון רקורסיבי — במה כל אחת הכי טובה, היכן כל אחת נשברת, ואיך משלבים אותן בשכבות למערכת ידע AI ארגונית אחת המחוברת למסמכים, CRM, נתונים מובנים, הרשאות, workflows ו-evals.
נכתב על ידי Vladimir Zhemerov
מנהל מוצר בכיר ומומחה AIO/GEOפורסם 2026-06-17
קטגוריה
ארכיטקטורת AI · RAG ארגוני
זמן קריאה
18 דקות קריאה
פורסם
2026-06-17
קהל יעד
מייסדים · תפעול · מקבלי החלטות טכניים
5ארכיטקטורות בהשוואה
RAG בסיסי, מתקדם, Agentic, Graph והיגיון רקורסיבי
בעיות שונות — לא buzzwords ניתנים להחלפה
1מערכת רב-שכבתית
העתיד אינו טכניקה אחת שמחליפה אחרת
אחזור, אורקסטרציה, גרף, היגיון, evals
≠צ׳אטבוט PDF
ידע ארגוני שוכן על פני מערכות, לא בתיקייה אחת
מסמכים, CRM, APIs, דוחות, הרשאות
תשובה ישירה
RAG לא מת — RAG בסיסי פשוט לא מספיק ל-AI ארגוני רציני. RAG בסיסי מאחזר chunks של טקסט ועונה מתוכם, מה שעובד לשאלה-ותשובה פשוטה על מסמכים אבל נשבר בשאלות תפעוליות אמיתיות שמשתרעות על CRM, נתונים מובנים, מקורות סותרים ו-workflows. RAG מתקדם — חיפוש היברידי, סינון metadata, reranking, תעדוף מקורות, ציטוטים, הרשאות והערכה — הוא הבסיס המעשי. Agentic RAG מאפשר למערכת להחליט מה לבדוק ולפעול על פני מערכות. GraphRAG ממדל קשרים בין ישויות. היגיון רקורסיבי מפרק ניתוח גדול ורב-שלבי לתת-שאלות ומסנתז את הממצאים. העתיד אינו טכניקה אחת שמחליפה אחרת; הוא ארכיטקטורה רב-שכבתית: אחזור לראיות, אורקסטרציה agentic לעבודה רב-מערכתית, מבני גרף לקשרים, היגיון רקורסיבי לניתוח עמוק, ו-evals לאמינות.
מה RAG בסיסי באמת עושה
Retrieval-Augmented Generation (RAG) הפך לדרך ברירת המחדל להפוך מודל שפה לשימושי בתוך חברה. במקום לענות מתוך נתוני אימון כלליים, מערכת RAG מאחזרת מידע פנימי רלוונטי ומספקת למודל את הקונטקסט הזה לפני שהוא מגיב.
מערכת בסיסית מפרקת תוכן ארגוני ל-chunks, מאחסנת אותם באינדקס שניתן לחיפוש, ובזמן השאילתה מאחזרת את הקטעים הרלוונטיים ביותר שמהם המודל עונה. הזרימה לינארית: שאלה → חיפוש → אחזור chunks → שליחה למודל → תשובה.
- חיפוש בתיעוד פנימי
- שאלות נפוצות בהשמה ו-HR
- איתור מדיניות
- מאגרי ידע לתמיכה
- תיעוד מוצר
- שאלה-ותשובה פשוטה ומבוקרת על מסמכים
במקרים האלה זה עובד טוב. אבל RAG בסיסי הוא רק השכבה הראשונה — לא מערכת ארגונית מוגמרת.
אינפוגרפיקה 01 — איך RAG בסיסי עובד
pipeline של אחזור-ותשובה
שאלה → תשובה
שאלת משתמש
למשל “מהי מדיניות הנסיעות שלנו?”
Embedding שאילתה / חיפוש
השאלה הופכת לחיפוש
מסד וקטורים / אינדקס מסמכים
chunks של טקסט ארגוני הניתנים לחיפוש
chunks מאוחזרים top-k
הפסקאות הדומות ביותר
מודל שפה
קורא את ה-chunks כקונטקסט
תשובה מבוססת מקור
נוצרת מהטקסט שאוחזר
- הכי טוב לשאלה-ותשובה פשוטה על מסמכים
- מהיר ליישום
- מוגבל בהיגיון חוצה-מערכות
RAG בסיסי מאחזר פסקאות טקסט רלוונטיות ומשתמש בהן כקונטקסט לתשובת המודל. מעבר אחד, סוג מקור אחד.
למה RAG בסיסי נשבר בארגון
RAG בסיסי מתחיל להיכשל ברגע שחברות עוברות מחיפוש מסמכים פשוט לשאלות תפעוליות אמיתיות. הבעיה אינה שהאחזור חסר תועלת — אלא שרוב השאלות העסקיות אינן רק בעיות אחזור.
שאלו “למה גביית התשלומים ירדה ברבעון האחרון?” ומערכת בסיסית תאחזר טקסט שמזכיר “גבייה” או “dunning”. התשובה האמיתית שוכנת על פני שלבי CRM, נתוני מעבד תשלומים, התיישנות חשבוניות, ניסיונות תשלום שנכשלו, שינויים ברצף האימיילים, פניות תמיכה ותנאי חוזה — לא במסמך נקי אחד.
01
מאחזר טקסט, לא אמת תפעולית
הקטע הדומה ביותר סמנטית אינו תמיד המקור הנכון ביותר. מדיניות מיושנת ב-Drive, הערה חדשה יותר ב-Notion, חוזה חתום וחריג CRM ספציפי-ללקוח יכולים כולם להיראות “רלוונטיים” — אבל רק אחד צריך לנצח.
02
חלש בנתונים מובנים
“אילו חשבוניות באיחור של 30+ ימים?” או “אילו חשבונות בסיכון נטישה?” נענות על ידי שאילתה ל-CRM, חיוב ואנליטיקה — סינון, קיבוץ, צירוף, חישוב — לא על ידי אחזור פסקאות.
03
אחזור top-k נאיבי
החזרת חמישה chunks קבועים היא מנגנון, לא אסטרטגיה. הראיה הנכונה עשויה לשבת מחוץ לתוצאות המובילות, להיות מפוצלת על פני מקורות, או לדרוש חיפוש היברידי, פילטרי metadata ו-reranking כדי לצוף.
04
אין פתרון קונפליקטים
חברות מחזיקות ידע סותר מעצם תכנונן. בלי עדיפות מקור, ניהול גרסאות וסמכות, המערכת מתייחסת לטיוטה, להערה ישנה ולחוזה חתום כאל אמינים במידה שווה.
05
אין פעולה
משתמשים לרוב רוצים את הצעד הבא — ליצור את משימות המעקב, לעדכן את ה-CRM, להודיע לאחראי — לא רק תשובה. RAG בסיסי מתאר; הוא לא מבצע.
ההבדל המהותי: RAG בסיסי מאחזר מידע; AI ארגוני חייב לחקור את הקונטקסט העסקי.
אינפוגרפיקה 02 — למה RAG בסיסי לא מספיק
שאלה אחת, מערכות רבות
“למה גביית התשלומים ירדה ברבעון האחרון?”
RAG בסיסי רק מאחזר טקסט דומה. שאלות ארגוניות דורשות חקירה על פני מסמכים, נתונים מובנים, היסטוריית workflow ומערכות עסקיות.
RAG מתקדם: המינימום האמיתי לשימוש עסקי
האמירה הכנה אינה “RAG מת”. היא “RAG נאיבי לא מספיק.” שכבת אחזור בפרודקשן היא הרבה יותר ממסד וקטורים מאחורי חלון צ׳אט — היא משפרת את הראיות עוד לפני שהמודל מייצר תשובה.
אם שכבת האחזור מוסרת למודל קונטקסט מיושן, חלקי או לא מורשה, התשובה אינה אמינה לא משנה כמה המודל חזק.
חיפוש היברידי
שילוב וקטורים סמנטיים עם חיפוש מילות מפתח כדי שמזהים מדויקים — שמות לקוחות, מספרי חוזה, חשבונית 10482, “סעיף 7.3” — יימצאו לצד התאמות מושגיות.
סינון metadata
סינון לפי גרסה, סטטוס, לקוח, אזור, אחראי, רמת גישה ומצב אישור, כדי שהמערכת תאחזר את המדיניות הנכונה, לא רק מדיניות דומה.
Reranking
משיכת מערך מועמדים רחב (top 50–100), ואז סידור מחדש לפי רלוונטיות וסמכות אמיתיות לפני בחירת הראיות הסופיות.
תעדוף מקורות
הגדרת אילו מקורות מנצחים: חוזה חתום > מדיניות מאושרת > שדה CRM רשמי > הערה פנימית > טיוטה.
דחיסת קונטקסט
הסרת כפילויות, חילוץ הסעיפים הרלוונטיים, קיבוץ לפי מקור והצפת קונפליקטים — לתת למודל את הקונטקסט הנכון, לא יותר קונטקסט.
ציטוטים וביסוס
תשובות צריכות להיות ניתנות למעקב למקטע מקור אמיתי, לא רק להישמע נכון. ציטוט שגוי גרוע יותר מהיעדר ציטוט.
RAG מתקדם הוא הבסיס המעשי לשימוש עסקי רציני — ראיות טובות יותר פנימה, תשובות אמינות יותר החוצה.
אינפוגרפיקה 03 — מה RAG מתקדם מוסיף
שכבת אחזור בין השאלה לתשובה
מה זה קונה
- רלוונטיות טובה יותר
- מקורות עדכניים יותר
- אמון גבוה יותר
- סיכון הזיה נמוך יותר
- תשובות אמינות יותר
RAG מתקדם משפר את הראיות לפני היצירה — כך שהמודל עונה מתוך קונטקסט טוב יותר.
Agentic RAG: מחיפוש פסיבי לחקירה
RAG בסיסי הולך במסלול קבוע: שאלה → אחזור → תשובה. Agentic RAG מאפשר למערכת להחליט מה לעשות — לחפש במסמכים, לשאול את ה-CRM, לבדוק גיליון אלקטרוני, לקרוא ל-API, להשוות מקורות, לשאול שאלת הבהרה, או להפעיל פעולת workflow.
שאלו “אילו לקוחות צפויים לנטוש החודש, ומה כדאי לעשות הלאה?” עוזר בסיסי מחפש מסמכי נטישה. מערכת agentic בודקת סטטוס חשבון, תאריכי חידוש, שימוש, היסטוריית תשלומים, פניות תמיכה ופעילות אחרונה — ואז מחזירה סיכון מדורג, ראיות תומכות ופעולות מומלצות.
היכן זה מתאים
- עוזרים מחוברי-CRM ו-copilots למכירות
- כשירות והפניית לידים
- אוטומציית גבייה ו-dunning
- ניתוח סיכון בהצלחת לקוח
- מעקב פיננסים וחשבוניות
- סוכני דיווח ואבחון
- תהליכי חקירת ציות
היכן זה משתבש
- קריאה ליותר מדי כלים — תשובות איטיות ויקרות
- פעולה ללא ביטחון מספק
- גישה לנתונים שהמשתמש לא אמור לראות
- פעולות workflow רועשות וכשלי כלים שקטים
Agentic RAG מצדיק את עצמו רק עם guardrails: הרשאות כלים מחמירות, בקרת גישה, שלבי אישור לפעולות רגישות, לוגים ו-evals.
אינפוגרפיקה 04 — איך Agentic RAG עובד
תהליך החלטה, לא קו ישר
“אילו לקוחות צפויים לנטוש החודש?”
מחליט מה לבדוק
פעולת workflow אופציונלית
Agentic RAG מאפשר למערכת להחליט אילו מקורות וכלים נדרשים לפני שהיא עונה — או פועלת.
GraphRAG: כשהקשרים חשובים יותר מהפסקאות
חלק גדול מהידע הארגוני הוא יחסי: לקוחות מקושרים לחוזים, חוזים למחויבויות, מחויבויות למועדים, סיכונים למדיניות, ספקים למחלקות, אירועים למערכות. GraphRAG ממדל את הקשרים האלה במקום להתייחס לידע כערימת פסקאות.
שאלו “אילו ספקים, מחלקות, חוזים ומדיניות מקושרים לסוגיית הציות הזו?” זו בעיה של מיפוי קשרים, לא של אחזור מסמכים.
- ניתוח תיקים משפטיים וציות
- מיפוי סיכון ספקים וצדדים שלישיים
- מודיעין תביעות ביטוח
- מודיעין שוק ומחקר ארגוני
- מיפוי רכש ומדיניות / בקרות
- תהליכי חקירה
זה לא טוב יותר אוטומטית. GraphRAG מוסיף חילוץ ישויות, בניית גרף, התאמת ישויות ותחזוקה. המבחן: האם התשובה תלויה בקשרים בין ישויות, או בעיקר במציאת טקסט המקור הנכון? אם הקשרים מרכזיים, זה שווה את המורכבות.
אינפוגרפיקה 05 — איך GraphRAG מארגן ידע
ישויות המחוברות בקשרים
סוגי קשרים
GraphRAG שימושי כשהתשובה תלויה בקשרים בין ישויות, לא ב-chunks מבודדים של מסמכים.
היגיון רקורסיבי: פירוק מה שמעבר אחד לא יכול לענות
חלק מהשאלות גדולות מדי או רב-שלביות מכדי שמעבר אחזור יחיד יענה עליהן. היגיון רקורסיבי מפרק את השאלה לתת-שאלות, מנתח כל אחת, ואז משלב את הממצאים החלקיים לתשובה סופית.
בקשו מהמערכת לסקור 300 מסמכים ולמצוא סתירות בין מדיניות נוכחית, חוזים חתומים ונהלים. זה דורש פירוק, השוואה, שיפוט עדכני-מול-מיושן, סיכומים חלקיים ומסקנה מובנית — לא רק אחזור.
- בדיקת נאותות ו-discovery משפטי
- סינתזת מחקר רב-מסמכי
- זיהוי פערי מדיניות וסתירות
- חקירות וביקורות פנימיות
- דוחות אסטרטגיים ומחקר שוק
- ניתוח מסמכים בקונטקסט ארוך
לעיתים נדון כ“מודלים רקורסיביים של שפה” או היגיון בסגנון RLM — הטרמינולוגיה עדיין לא יציבה, ולכן עדיף לא למכור “RLM” כקטגוריה. היכולת האמיתית מעשית: AI שמנמק על פני קונטקסט גדול, מפוצל ורב-שלבי בצורה מבוקרת. הוא לא מחליף אחזור; מערכות רציניות משתמשות בשניהם.
אינפוגרפיקה 06 — איך היגיון רקורסיבי מטפל בקונטקסט מורכב
פירוק → ניתוח → בדיקה חוזרת → סינתזה
“סקרו 300 מסמכים ומצאו סתירות בין מדיניות, חוזים ונהלים.”
A
השוואת מדיניות מול חוזים
B
זיהוי סתירות
C
מקורות עדכניים מול מיושנים
היגיון רקורסיבי מתאים לניתוח בקונטקסט ארוך, רב-מסמכי ורב-שלבי — הוא לא עונה במכה אחת.
איך חמש הגישות מושוות
הדרך הקלה ביותר לבחור היא להשוות במה כל אחת הכי טובה — והיכן כל אחת נשברת. זהו כלי החלטה, לא דירוג: התשובה הנכונה תלויה בשאלה אם העסק צריך חיפוש, פעולה, מיפוי קשרים או היגיון עמוק.
אינפוגרפיקה 07 — איזו ארכיטקטורה מתאימה לאיזו בעיה?
כלי החלטה של 10 שניות
- RAG בסיסישאלה-ותשובה פשוטה על מסמכיםחלש בהיגיון מורכבגבוהה
- RAG מתקדםאחזור ידע אמיןעדיין ממוקד בעיקר באחזורגבוהה
- Agentic RAGworkflows חוצי-מערכותדורש guardrailsגבוהה / גדלה
- GraphRAGידע עתיר-קשריםמורכב יותר לבנייהבינונית
- היגיון רקורסיביניתוח עמוק בקונטקסט ארוךפחות מתוקנןמתפתחת
- RAG בסיסיגבוהה
הכי טוב ל
שאלה-ותשובה פשוטה על מסמכים
חולשה
חלש בהיגיון מורכב
- RAG מתקדםגבוהה
הכי טוב ל
אחזור ידע אמין
חולשה
עדיין ממוקד בעיקר באחזור
- Agentic RAGגבוהה / גדלה
הכי טוב ל
workflows חוצי-מערכות
חולשה
דורש guardrails
- GraphRAGבינונית
הכי טוב ל
ידע עתיר-קשרים
חולשה
מורכב יותר לבנייה
- היגיון רקורסיבימתפתחת
הכי טוב ל
ניתוח עמוק בקונטקסט ארוך
חולשה
פחות מתוקנן
בעיות שונות, לא buzzwords ניתנים להחלפה. בחרו לפי השאלה, לא לפי המונח.
אילו עסקים זקוקים לאיזו גישה
משרד עורכי דין, צוות גבייה, חברת fintech ועסק שירותים B2B עשויים כולם לבקש “עוזר AI”, אבל הארכיטקטורה מאחוריו לא צריכה להיות זהה. הבחירה הנכונה עוקבת אחר הבעיה העסקית, לא אחר הפופולריות של מונח.
אינפוגרפיקה 08 — מה עסקים שונים בדרך כלל צריכים
הארכיטקטורה עוקבת אחר הבעיה העסקית
- משרדי עורכי דיןחוזים, תיקים, מחויבויות, ציטוטיםRAG מתקדם + GraphRAG
- ביטוחתביעות + מדיניות + workflowsAgentic RAG + נתונים מובנים
- Fintechציות, דיווח, הרשאותRAG מתקדם + Agentic
- שירותי B2BCRM, SOPs, ידע מפוזרRAG מתקדם + סוכן מחובר-CRM
- ייעוץ / מחקרסינתזה על פני מקורות רביםGraphRAG + היגיון רקורסיבי
- תפעול פנימיסטטוס על פני מערכות ותהליכיםAgentic RAG + אוטומציית workflow
- גבייה / dunningנתוני תשלום, workflows של גבייהAgentic RAG + CRM + דיווח
- עתיר-ציותמדיניות, בקרות, מחויבויות, סיכוןRAG מתקדם + GraphRAG + רקורסיבי
- משרדי עורכי דין
בעיית ידע נפוצה
חוזים, תיקים, מחויבויות, ציטוטים
ארכיטקטורה מומלצת
RAG מתקדם + GraphRAG
- ביטוח
בעיית ידע נפוצה
תביעות + מדיניות + workflows
ארכיטקטורה מומלצת
Agentic RAG + נתונים מובנים
- Fintech
בעיית ידע נפוצה
ציות, דיווח, הרשאות
ארכיטקטורה מומלצת
RAG מתקדם + Agentic
- שירותי B2B
בעיית ידע נפוצה
CRM, SOPs, ידע מפוזר
ארכיטקטורה מומלצת
RAG מתקדם + סוכן מחובר-CRM
- ייעוץ / מחקר
בעיית ידע נפוצה
סינתזה על פני מקורות רבים
ארכיטקטורה מומלצת
GraphRAG + היגיון רקורסיבי
- תפעול פנימי
בעיית ידע נפוצה
סטטוס על פני מערכות ותהליכים
ארכיטקטורה מומלצת
Agentic RAG + אוטומציית workflow
- גבייה / dunning
בעיית ידע נפוצה
נתוני תשלום, workflows של גבייה
ארכיטקטורה מומלצת
Agentic RAG + CRM + דיווח
- עתיר-ציות
בעיית ידע נפוצה
מדיניות, בקרות, מחויבויות, סיכון
ארכיטקטורה מומלצת
RAG מתקדם + GraphRAG + רקורסיבי
הארכיטקטורה הנכונה תלויה בבעיה העסקית — לא בפופולריות של מונח טכני.
אמינות היא הנדסה: top-k ו-evals
Top-k הוא מספר ה-chunks שמאוחזרים לכל שאילתה. עבור “מהי מדיניות החזר ההוצאות במשרד?” k קטן מספיק. בשאלות ארגוניות אמיתיות התשובה עשויה לשבת מחוץ לתוצאות המובילות, להיות מפוצלת על פני מקורות, או לשכון בטבלה או במערכת מובנית — ולכן top-k הוא מנגנון, לא אסטרטגיה.
התהליך הטוב יותר: לאחזר מערך מועמדים רחב → reranking → סינון לפי metadata → תעדוף מקורות סמכותיים → דחיסה → תשובה עם ציטוטים. המטרה אינה לאחזר יותר; היא לאחזר טוב יותר.
Evals הם הדרך לשמור על מערכת אמינה אחרי הדמו. בלעדיהם, צוותים שופטים את ה-AI לפי כמה דוגמאות מרשימות ומפספסים רגרסיות שקטות.
01
Retrieval evals
האם המערכת מצאה את המקור הנכון, העדכני והמורשה — והדירה מקורות מיושנים או מוגבלים?
02
Answer evals
האם התשובה הסופית נכונה, או שהמערכת סיכמה את המקור הנכון בצורה שגויה (60 ימים, לא 30)?
03
Citation evals
האם מקטע המקור המצוטט באמת תומך בטענה?
04
Permission evals
האם המערכת מכבדת בקרת גישה — בלי נתוני שכר למשתמש מכירות?
05
Regression evals
האם האיכות ירדה אחרי שינוי prompt, מודל או אחזור (87% → 72%)?
לשימוש רציני, evals אינם מותרות טכנית — הם חלק מהמוצר.
איך נראית באמת מערכת ידע AI ארגונית
כשחברות אומרות שהן רוצות AI ש“מבין את העסק”, הן מתכוונות למשהו מעשי: מערכת שיודעת היכן שוכן הידע, אילו מקורות סמכותיים, אילו עדכניים, מי יכול לגשת למה, איך אובייקטים עסקיים מתחברים, מתי לחפש, מתי לחשב, מתי לשאול, מתי לסרב, ומתי להפעיל workflow.
זה אינו צ׳אטבוט. זוהי שכבה מבוקרת שמחברת ידע ארגוני, מערכות, workflows וקבלת החלטות — בנויה כארכיטקטורה רב-שכבתית.
אינפוגרפיקה 09 — מערכת ידע AI ארגונית
RAG הוא שכבה אחת של מערכת גדולה יותר
מקורות מידע
- מסמכים
- CRM
- גיליונות
- דוחות
- Notion
- Google Drive
- אימייל
- APIs
- דשבורדים
- מסדי נתונים
שכבות אינטליגנציה
- מחברים
- זהות והרשאות
- אינדוקס ו-metadata
- אחזור היברידי
- שכבת גרף אופציונלית
- אורקסטרציה agentic
- כלים / קריאות API
- שכבת היגיון
- ביסוס תשובה וציטוטים
- פעולות workflow
- Evals וניטור
פלטים
- copilot ידע AI
- עוזר דיווח
- עוזר ציות
- עוזר CRM
- אוטומציית workflow
- תמיכת החלטות
RAG הוא רק שכבה אחת. מערכת AI ארגונית רצינית מחברת מקורות מידע, הרשאות, אחזור, היגיון, כלים, workflows והערכה.
אז איזו גישה רוב החברות צריכות לבחור?
אל תתחילו ב“RAG, GraphRAG, Agentic או רקורסיבי?” התחילו ב“איזה סוג של שאלה עסקית המערכת צריכה לענות עליה?” אם זה בעיקר במסמכים, התחילו ב-RAG מתקדם. אם זה תלוי ב-CRM, APIs ומצב workflow, הוסיפו Agentic RAG. אם זה תלוי בקשרים, שקלו GraphRAG. אם זה דורש ניתוח רב-שלבי עמוק, שקלו היגיון רקורסיבי. בפועל, רוב המערכות משלבות כמה.
- שלב 1
RAG בסיסי
עוזר פשוט לשאלה-ותשובה על מסמכים — מדיניות, שאלות נפוצות, השמה, תמיכה. לא מספיק ל-workflows מורכבים או נתונים מובנים.
- שלב 2
RAG מתקדם
גישת ידע אמינה ומבוססת-מקור: חיפוש היברידי, metadata, reranking, ציטוטים, הרשאות, evals. הבסיס האמיתי.
- שלב 3
Agentic RAG
AI שחוקר על פני מערכות ותומך ב-workflows — CRM, תפעול מכירות, הצלחת לקוח, dunning, פיננסים, ציות. כאן הערך המסחרי מזנק.
- שלב 4
GraphRAG
כשקשרים בין ישויות מרכזיים — משפטי, ציות, סיכון, ביטוח, רכש, מחקר.
- שלב 5
היגיון רקורסיבי
כשהמשימה היא ניתוח עמוק ורב-שלבי על פני קונטקסט גדול — בדיקת נאותות, discovery, ניתוח פערי מדיניות. עוצמתי, לא לכל חברה.
הארכיטקטורה הטובה ביותר היא רב-שכבתית: RAG מתקדם לידע אמין, Agentic RAG לעבודה רב-מערכתית ו-workflows, GraphRAG היכן שקשרים חשובים, היגיון רקורסיבי היכן שנדרש ניתוח עמוק, ו-evals כדי לשמור עליה אמינה. RAG לא מת — RAG בסיסי פשוט כבר לא מספיק.
למה Profitec AI
אנחנו בונים מערכות ידע AI ארגוניות, לא צ׳אטבוטים של PDF
אם הידע שלכם מפוזר על פני מסמכים, CRM, גיליונות, דוחות, Notion, Drive, אימייל, דשבורדים ו-APIs, צ׳אטבוט בסיסי לא ייצג איך העסק באמת עובד.
אנחנו מתכננים מערכות AI רב-שכבתיות שמחברות נתונים עסקיים, ידע פנימי, workflows ואוטומציה — מערכות שיכולות לחפש, לנמק, לאמת, לפעול ולהשתפר עם הזמן, עם הרשאות והערכה מובנות.
שאלות נפוצות
האם RAG מת?
לא. מה שנכשל בחברות רבות הוא RAG נאיבי — chunking פשוט, חיפוש וקטורי בסיסי, prompting שטחי, וללא ממשל. אחזור עדיין שכבה חיונית ברוב מערכות ה-AI הארגוניות; הוא פשוט לא המערכת כולה.
מה ההבדל בין RAG בסיסי ל-RAG מתקדם?
RAG בסיסי מאחזר chunks רלוונטיים ושולח אותם למודל שפה. RAG מתקדם משפר את התהליך הזה עם חיפוש היברידי, פילטרי metadata, reranking, תעדוף מקורות, ציטוטים, הרשאות, בקרות עדכניות והערכה, כך שהמודל עונה מתוך ראיות טובות יותר.
מהו Agentic RAG?
Agentic RAG הוא ארכיטקטורת אחזור שבה המערכת מחליטה מה לחפש, באילו כלים להשתמש, אילו מערכות לבדוק, והאם להפעיל פעולת workflow. הוא מתאים לשאלות עסקיות שדורשות חקירה רב-שלבית על פני מסמכים, CRM, APIs, דוחות או מסדי נתונים.
מהו GraphRAG?
GraphRAG הוא גישה מבוססת-גרף שמתמקדת בקשרים בין ישויות — לקוחות, חוזים, מדיניות, מחלקות, סיכונים, ספקים, תיקים, מחויבויות. הוא שימושי כשהתשובה תלויה בידע מחובר ולא ב-chunks מבודדים של טקסט.
מהו היגיון רקורסיבי ב-AI ארגוני?
היגיון רקורסיבי מפרק שאלה מורכבת לתת-שאלות קטנות יותר, מנתח כל חלק, בודק שוב את האזורים הלא ברורים, ומשלב את הממצאים החלקיים לתשובה סופית. הוא שימושי למשימות אנליטיות בקונטקסט ארוך, רב-מסמכיות ורב-שלביות כמו בדיקת נאותות וניתוח פערי מדיניות.
האם RLM טוב יותר מ-RAG?
לא באופן כללי. היגיון רקורסיבי בסגנון RLM שימושי למשימות ניתוח עמוק מסוימות, אבל הוא לא מחליף אחזור. רוב המערכות הארגוניות עדיין צריכות אחזור, גישה לנתונים מובנים, הרשאות, ציטוטים, כלי workflow ו-evals — היגיון רקורסיבי הוא שכבה אחת מתוכם.
מתי RAG בסיסי מספיק?
RAG בסיסי יכול להספיק לשאלה-ותשובה פנימית פשוטה, איתור מדיניות, מדריכי השמה ותיעוד תמיכה — מקרים שבהם התשובה כתובה בבירור במסמכים ואינה דורשת נתונים מובנים או היגיון חוצה-מערכות.
למה RAG נכשל עם CRM וגיליונות?
RAG מתוכנן לאחזר טקסט, בעוד CRM וגיליונות מחזיקים נתונים תפעוליים מובנים. שאלות עסקיות שם לרוב דורשות סינון, קיבוץ, חישוב, השוואת רשומות או קריאה ל-APIs — מה שדורש גישה לנתונים מובנים ואורקסטרציה agentic, לא אחזור מסמכים.
מה המשמעות של top-k ב-RAG?
Top-k הוא מספר ה-chunks המאוחזרים שמוחזרים לשאילתה. אם k = 5, המודל מקבל חמישה chunks. זה יכול להיות מוגבל מדי לשאלות ארגוניות מורכבות שבהן הראיה הנכונה מפוזרת על פני מקורות מרובים או מאוחסנת במערכת מובנית.
מהם evals במערכות RAG?
Evals הם בדיקות מובנות שמודדות האם המערכת מאחזרת את המקורות הנכונים, עונה נכון, מצטטת ראיות כראוי, מכבדת הרשאות, ושומרת על איכות יציבה אחרי שינויים. הם מה שמפריד בין מערכת ארגונית ברמת פרודקשן לבין דמו מרשים.
אילו חברות צריכות Agentic RAG?
חברות בדרך כלל צריכות Agentic RAG כשתשובות תלויות במערכות מרובות או כשה-AI אמור לתמוך בפעולות workflow — תפעול מכירות, הצלחת לקוח, פיננסים, ציות, גבייה, דיווח ותפעול פנימי הם דוגמאות נפוצות.
מהי הארכיטקטורה הטובה ביותר למערכת ידע AI ארגונית?
זה תלוי במקרה השימוש, אבל רוב המערכות הרציניות משלבות אחזור, גישה לנתונים מובנים, הרשאות, ביסוס מקור, שימוש בכלים, לוגיקת workflow, evals וניטור. עבור ארגונים מורכבים זה יכול להיות RAG מתקדם בתוספת Agentic RAG, עם GraphRAG והיגיון רקורסיבי היכן שקשרים וניתוח עמוק מצדיקים את המורכבות.
בנו מערכת, לא דמו
רוב החברות לא צריכות עוד צ׳אטבוט מסמכים. הן צריכות מערכת ידע AI שמחברת את הנתונים, ההיגיון וה-workflows שלהן. ראו איך אנחנו ניגשים להטמעת RAG, או ספרו לנו היכן שוכן הידע שלכם.
קריאה נוספת
מתודולוגיה
סקירה מעשית של דפוסי ארכיטקטורת RAG ארגונית. הדיאגרמות מושגיות — הן ממחישות איך הגישות נבדלות; הן אינן benchmarks. המלצות הארכיטקטורה משקפות ניסיון הטמעה של Profitec AI על פני מסמכים, CRM ונתונים תפעוליים.