trustgraph/docs/tech-specs/graphrag-performance-optimization.he.md
Jenkins, Kenneth Alexander 1f1aaa24ae
second round of translation fixes
Signed-off-by: Jenkins, Kenneth Alexander <kjenkins60@gatech.edu>
2026-04-06 14:50:34 -04:00

8.2 KiB
Raw Blame History

מפרט טכני לאופטימיזציה של ביצועים של GraphRAG

סקירה כללית

מפרט זה מתאר אופטימיזציות מקיפות לביצועים של האלגוריתם GraphRAG (Graph Retrieval-Augmented Generation) ב-TrustGraph. יישום הנוכחי סובל מחסמי ביצועים משמעותיים המגבילים את יכולת ההרחבה וזמני התגובה. מפרט זה מתייחס לארבעה תחומים עיקריים של אופטימיזציה:

  1. אופטימיזציה של מעבר גרפים: הסרת שאילתות מסד נתונים רקורסיביות לא יעילות ויישום חקר גרפים בטעינה.
  2. אופטימיזציה של פתרון תגים: החלפת שליפת תגים רציפה בפעולות מקבילות/בטעינה.
  3. שיפור אסטרטגיית אחסון במטמון: יישום אחסון במטמון חכם עם פינוי LRU ואחזור מראש.
  4. אופטימיזציה של שאילתות: הוספת שמירת תוצאות ואחסון במטמון של הטבעות לשיפור זמני התגובה.

מטרות

  • הפחתת נפח שאילתות מסד נתונים: השגת הפחתה של 50-80% בסך כל שאילתות מסד הנתונים באמצעות טעינה ואחסון במטמון.
  • שיפור זמני תגובה: כוונון ל-3-5 פעמים מהירות יותר בבניית תת-גרף ו-2-3 פעמים מהירות יותר בפתרון תגים.
  • שיפור יכולת הרחבה: תמיכה בגרפי ידע גדולים יותר עם ניהול זיכרון טוב יותר.
  • שימור דיוק: שמירה על הפונקציונליות ואיכות התוצאות של GraphRAG הקיימים.
  • אפשרות לריבוי משימות: שיפור יכולות עיבוד מקבילי עבור בקשות מקבילות מרובות.
  • הפחתת טביעת רגל של זיכרון: יישום מבני נתונים וניהול זיכרון יעילים.
  • הוספת יכולת ניטור: הכללת מדדי ביצועים ויכולות ניטור.
  • הבטחת אמינות: הוספת טיפול שגיאות ומנגנוני זמן קצובים מתאימים.

רקע

יישום ה-GraphRAG הנוכחי ב-trustgraph-flow/trustgraph/retrieval/graph_rag/graph_rag.py מציג מספר בעיות ביצועים קריטיות המשפיעות באופן משמעותי על יכולת ההרחבה של המערכת:

בעיות ביצועים נוכחיות

1. מעבר גרפים לא יעיל (פונקציה follow_edges, שורות 79-127)

  • מבצע 3 שאילתות נפרדות למסד הנתונים עבור כל ישות בכל רמת עומק.
  • תבנית שאילתה: שאילתות מבוססות נושא, שאילתות מבוססות פרידיקט ושאילתות מבוססות אובייקט עבור כל ישות.
  • ללא טעינה: כל שאילתה מעבדת רק ישות אחת בכל פעם.
  • ללא זיהוי מעגלים: ניתן לחזור על צמתים זהים מספר פעמים.
  • יישום רקורסיבי ללא שמירה במטמון מוביל למורכבות אקספוננציאלית.
  • מורכבות זמן: O(entities × max_path_length × triple_limit³)

2. פתרון תגים רציף (פונקציה get_labelgraph, שורות 144-171)

  • מעבד כל מרכיב משולש (נושא, פרידיקט, אובייקט) באופן רציף.
  • כל קריאה ל-maybe_label עלולה לגרום לשאילתת מסד נתונים.
  • ללא ביצוע מקבילי או טעינה של שאילתות תגים.
  • גורם עד ל-3 × קריאות מסד נתונים בודדות עבור גודל תת-גרף.

3. אסטרטגיית אחסון במטמון בסיסית (פונקציה maybe_label, שורות 62-77)

  • מטמון מילון פשוט ללא מגבלות גודל או TTL.
  • מדיניות פינוי מטמון חסרה גורמת לצמיחה בלתי מוגבלת של הזיכרון.
  • אי-הצלחה במטמון גורמת לשאילתות מסד נתונים בודדות.
  • ללא אחזור מראש או חימום מטמון חכם.

4. תבניות שאילתות לא אופטימליות

  • שאילתות דמיון וקטורי של ישויות אינן מאוחסנות במטמון בין בקשות דומות.
  • ללא שמירת תוצאות לשאילתות דומות.
  • אופטימיזציה חסרה של שאילתות לתבניות גישה נפוצות.

5. בעיות קריטיות בתוחלת החיים של אובייקטים (rag.py:96-102)

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

ניתוח השפעה על ביצועים

תרחיש גרוע ביותר נוכחי עבור שאילתה טיפוסית:

  • אחזור ישות: שאילתת דמיון וקטורית אחת.
  • מעבר גרפים: entities × max_path_length × 3 × triple_limit שאילתות.
  • פתרון תגים: subgraph_size × 3 שאילתות תגים בודדות.

עבור פרמטרים ברירת מחדל (50 ישויות, אורך נתיב 2, מגבלת משולש 30, גודל תת-גרף 150):

  • מספר מינימלי של שאילתות: 1 + (50 × 2 × 3 × 30) + (150 × 3) = 9,451 שאילתות למסד נתונים
  • זמן תגובה: 15-30 שניות עבור גרפים בגודל בינוני.
  • שימוש בזיכרון: צמיחה בלתי מוגבלת של המטמון לאורך זמן.
  • יעילות מטמון: 0% - מטמון מאופס בכל בקשה.
  • תקורה של יצירת אובייקטים: אובייקטי GraphRag + Query נוצרים/נהרסים עבור כל בקשה.

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

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

עיצוב טכני

ארכיטקטורה

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

1. שינוי ארכיטקטורת תוחלת החיים של אובייקטים

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

2. טעינה ובקשה

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

3. אחסון במטמון

  • מטמון תגים ישמור תוצאות כדי לשפר את יעילות השאילתה.

4. מדיניות

  • מדיניות שאילתה תאפשר גבולות כדי לשפר את הביצועים.