למה הפסקתי להסתמך על ספק AI אחד
בניתי צ'אטבוט בזמן אמת עבור פורום קהילתי. חשבתי ששימוש ב-API אחד יספיק. טעיתי.
אחרי שלושה שבועות, נתקלתי בשגיאת 5xx בשעות השיא. הצ'אטבוט שלי הפסיק לעבוד. המשתמשים היו מתוסכלים. הבנתי שאני לא יכול לסמוך על ספק אחד עבור אפליקציות פרודקשן.
השתמשתי ב-GPT-4. זה עבד טוב עד שזה הפסיק לעבוד. נתקלתי במגבלות קצב (rate limits), פקיעת זמן (timeouts) והשבתות מוחלטות. לשלם על מסלולים גבוהים יותר הרגיש כמו טיפול בסימפטום במקום בבעיה עצמה.
ניסיתי ספקים אחרים, אבל לכולם היו פורמטים ושיטות אימות (auth) שונות. הקוד שלי הפך לבלגן של הצהרות switch-case. הייתי צריך מערכת שמאפשרת:
- להסתיר את ההבדלים בין הספקים.
- לעבור לספק גיבוי במקרה של תקלה.
- לשמור תגובות ב-cache.
- להימנע מנעילת ספק (vendor lock-in).
נמנעתי מספריות צד-שלישי כי הן היו מורכבות מדי והתקלקלו בקלות. במקום זאת, בניתי router פשוט.
ראשית, הגדרתי interface משותף לכל הספקים. כל ספק מממש מתודה של generate ובדיקת תקינות (health check).
לאחר מכן, בניתי מחלקת router. היא מנסה ספקים בסדר מסוים. היא משתמשת ב-exponential backoff וב-cache פשוט. אם הספק הראשון נכשל, המערכת ממתינה ומנסה את הבא בתור.
המערכת הזו הצילה לי את סופי השבוע במהלך שלוש השבתות שונות. היא שומרת על האפליקציה שלי פועלת גם כשספק מרכזי קורס.
אם אתם בונים את זה, קחו את הנקודות הבאות בחשבון:
- השתמשו ב-Redis עבור caching ב-production במקום במילון (dictionary) מקומי.
- בדיקות תקינות (health checks) אינן מבטיחות הצלחה. ספק עשוי לעבור בדיקה אך להיכשל בבקשה אמיתית.
- נתחו (Parse) כותרות Retry-After כדי לטפל במגבלות קצב בצורה נכונה.
- הוסיפו logging לשימוש בטוקנים כדי לעקוב אחר עלויות.
- השתמשו ב-asyncio לביצועים גבוהים יותר.
אם הפרויקט שלכם קטן, אל תעשו over-engineering. אם אתם זקוקים ל-streaming, התבנית הזו מוסיפה latency. בחרו את הכלי הנכון עבור קנה המידה שלכם.
איך אתם מטפלים באמינות של ספקים? אתם נצמדים לספק אחד או בונים שכבת fallback?
מקור: https://dev.to/__c1b9e06dc90a7e0a676b/why-i-stopped-relying-on-a-single-ai-provider-and-built