למה לא כדאי להחזיק חיבורי DB בזמן קריאות LLM
זמן התגובה (latency) של AI הוא לא רק הזמן שהמודל מקדיש למחשבה. הוא כולל גם את האופן שבו אתם מנהלים את חיבורי מסד הנתונים.
החזקת חיבור DB בזמן המתנה ל-LLM או ל-embedding API עלולה לרוקן את מאגר החיבורים (connection pool) שלכם. קריאות חיצוניות איטיות משאירות סשנים (sessions) פתוחים זמן רב הרבה יותר ממה שנדרש.
חקרתי את ה-repo של Honcho כדי לראות את התיקון שלהם. הם החליפו סשן יחיד ומתמשך בסשנים קצרים וספציפיים למשימה.
תבנית ישנה
- פתיחת סשן DB
- קריאת הגדרות משתמש
- קריאה ל-LLM (איטית)
- קריאה ל-Embedding API (איטית)
- שמירת תוצאות
- סגירת סשן DB
תבנית חדשה
- פתיחת סשן DB לבדיקות מקדימות (pre-flight checks)
- קריאת הערכים הדרושים לתוך משתנים
- סגירת סשן DB
- קריאה ל-LLM ול-Embedding APIs (ללא החזקת חיבור DB)
- פתיחת סשן DB חדש וקצר לשמירת תוצאות
- סגירת סשן DB
המטרה היא לא לנטוש את מסד הנתונים; המטרה היא לשמור על עקביות הטרנזקציה (transaction consistency) בנפרד מהמתנה לרשת.
חמישה שלבים לניהול החיבורים שלכם
- הגדירו את גבולות העקביות שלכם.
- משכו את כל הערכים הנדרשים למשתנים לפני כל קריאת API חיצונית.
- סגרו את ה-scope של מסד הנתונים.
- בצעו את המשימות החיצוניות האיטיות.
- פתחו scope כתיבה חדש וקצר כדי לשמור את התוצאות הסופיות.
הערה: אם אתם משתמשים ב-pgvector, החיפוש מתבצע בתוך מסד הנתונים, לכן עליכם להשאיר את הסשן פתוח במהלך הפעולה הזו.
קיצור חיי הסשן משפר את יכולת ההרחבה (scaling), אך שימו לב לשגיאות של detached-objects ב-ORM שלכם וודאו שהנתונים נשארים עקביים לאורך snapshots של הטרנזקציות.
מקור: https://dev.to/junhyun-dev/neurin-llm-hocul-jung-db-connectioneul-jabji-anhneun-iyu-3abg
קהילת למידה אופציונלית: https://t.me/GyaanSetuAi