אינטגרציה של OpenAI API: GPT-4o, o1, o3 — מתחת למכסה המנוע

אינטגרציה של OpenAI API: מה נשבר במסלול הייצור

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

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

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

חשבונאות של מכסת בקשות מתנהלת בדרך כלל «בעין», במונה אחד לכל התרחישים. כאשר חישוב רקע כבד ובקשה חיה של משתמש חולקים מגבלה אחת, שניהם נכשלים, והשירות נכנס להידרדרות מדורגת (cascading degradation). מאגרים נפרדים עם עדיפויות ותור לעומס יתר משאירים את המסלולים האינטראקטיביים חיים.

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

מה נותנת אינטגרציה מנוהלת של מודלי שפה

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

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

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

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

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

מצבי חיבור: קריאה ישירה, פרוקסי, שער

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

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

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

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

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

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

שלבי ההטמעה: מביקורת תרחישים ועד למסירה

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

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

מה מוסרים לידיים: תצורות ונהלים

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

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

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

מקרה בוחן: כשלים וזמן תגובה לפני ואחרי הארגון מחדש

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

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

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

מדדים לפני ואחרי

שיעור הכשלים — 12% → 0.8%. זמן ההתאוששות — מ-40 דקות של עבודה ידנית למעבר אוטומטי בתוך דקות ספורות. ירידה בתיקונים ידניים: 30% → 6%. האחוזון ה-95 של זמן התגובה הצטמצם בחצי. שעות הנדסיות שהוקדשו לכיבוי כשלים הופנו לפיתוח המוצר.

מה עושים אם חלק מהקריאות כבר יוצאות ישירות?

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

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

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

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

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

שאלות טכניות נפוצות בנוגע לחיבור

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

כיצד לא להיתקל במכסות בקשות?

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

כיצד לדעת שאיכות התשובות לא ירדה?

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

מה עושים בעת כשל של ספק המודל?

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

היכן גבול האחריות?

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

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

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

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

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

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

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