Graph RAG: פיתוח על גרפי ידע לחיפוש רב-שלבי מדויק

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

Graph RAG: מדוע חיפוש רגיל נשבר על שרשראות שאלות ארוכות

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

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

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

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

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

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

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

מה נותן גרף ידע: דיוק ויציבות של תשובות

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

שיעור התשובות הנכונות בשאלות מורכבות

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

שרשרת חשיבה ניתנת לבדיקה

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

נפח הקונטקסט לשאילתה אחת

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

יציבות התוצאות

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

דרכים לקשר עובדות: גרף, וקטורים או היבריד

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

כיצד המצבים מתנהגים על נתונים אמיתיים

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

מה קובע את בחירת הסכמה

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

בפועל בחירת הסכמה לעתים רחוקות היא "או-או" חד-משמעית: ההיבריד סוגר את שני סוגי השאילתות, אבל משלם על כך בסנכרון אינדקסים בכל עדכון נתונים.

כיצד אנחנו בונים גרף ידע: שלבי עבודת הנדסה

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

  1. ביקורת מקורות. מאחדים תקנות, טיקטים, בסיס ידע וטבלאות למפה אחת: נפח, כפילויות, הרשאות גישה, תדירות שינויים. כאן גם מגדירים את השדות שלפיהם הישויות נתפרות זו לזו.
  2. תכנון הסכמה. קובעים סוגי צמתים וקשתות, מאפיינים חובה, כיוון הקשרים וכללי מיזוג כפילויות. הסכמה מאושרת לפני הטעינה הראשונה: אחרת חילוץ הישויות מניב סוגים לא תואמים.
  3. חילוץ ישויות וקשרים. כללים סוגרים שדות צפויים, מודל שפה — ניסוחים בטקסט. לאחר פתרון הישויות, אובייקט אמיתי אחד מקבל צומת אחד, ולא שלושה דומים.
  4. הרכבת הגרף. טוענים צמתים וקשתות למאגר, מוסיפים היררכיית מדורים, משקלות קשרים והפניות הפוכות למקטע המקורי — לפיהם נבדק כל ציטוט.
  5. סט בקרה. לוקחים שאלות אמיתיות של עובדים עם שרשראות תשובות אמת מידה. עליהן מודדים שלמות חילוץ ודיוק שאילתות רב-שלביות, בנפרד — על החלק שאינו גלוי בעת הכיול.
  6. מסירה לצוות. מוסרים סכמה, תקנון עדכון, אינדוקס מחדש בעת שינוי מקור ולוח בקרה: שיעור השרשראות הנכונות וזמן התגובה.

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

סכמת הגרף, מדיניות גישה ומסירת תיעוד

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

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

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

מקרה בוחן: כיצד גדל הדיוק של תשובות לשאלות קשורות

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

מה הראו המדידות לפני

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

מה שינו

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

מה קרה על אותו סט

שיעור התשובות הנכונות עלה ל-88%, אובדן הקשרים הצטמצם ל-4%, זמן הכנת התוצאה — ל-0.9 שניות. בדיקה ידנית גורפת הוחלפה בבדיקה מדגמית: המהנדס בודק תשובה אחת מעשר במקום כל אחת. על סט שאלות מורחב המדדים מחזיקים מעמד — הגרף מתמלא יחד עם התיעוד, ולא מדרדר ככל שהבסיס גדל.

במה Graph RAG שונה מחיפוש וקטורי רגיל

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

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

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

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

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

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

ספקות טכניים: נתונים, איכות, תחזוקה

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

מה אם המקורות סותרים זה את זה?

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

כיצד מתעדכן הגרף עם תיקונים במסמכים?

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

האם אפשר לפרוס את הפתרון בקונטור סגור?

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

לפי אילו קריטריונים מתקבלת האיכות?

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

נדון במשימה ונחזור עם תוכנית עבודה

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

מה נדרש מכם בניתוח המשימה הראשון:

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

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

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

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