mirror of
https://github.com/trustgraph-ai/trustgraph.git
synced 2026-07-09 21:32:10 +02:00
101 lines
No EOL
8.2 KiB
Markdown
101 lines
No EOL
8.2 KiB
Markdown
# מפרט טכני לאופטימיזציה של ביצועים של 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. מדיניות
|
||
- מדיניות שאילתה תאפשר גבולות כדי לשפר את הביצועים. |