אינטגרציה של OpenAI Function Calling: סכמות, קריאות מקבילות, Pydantic

OpenAI function calling: מדוע הקריאות נכשלות בסביבת הייצור

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

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

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

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

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

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

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

מה נותנת אינטגרציה מנוהלת של function calling

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

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

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

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

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

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

סכמות קריאה לכלים: אילו גישות לבחור

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

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

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

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

כיצד אנו מיישמים את האינטגרציה: שלבי העבודה ההנדסית

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

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

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

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

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

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

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

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

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

מה שינינו

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

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

מה יצא

כל הקריאות עוברות דרך מנגנון function calling של OpenAI עם סכמות קבועות. שיעור כשלי הקריאות ירד מ-18% ל-3% — פי שישה פחות. העומס על הנציגים הצטמצם מ-21% מהשיחות ל-5%, וזמן התגובה ירד מ-6 ל-2.5 שניות בזכות הקריאות המקבילות.

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

במה נבדלת סכמה קפדנית מפענוח חופשי של התשובה

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

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

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

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

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

ספקות טכניים נפוצים לפני האינטגרציה

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

מה אם המודל ישלח ארגומנטים לא תקינים?

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

כלי חדש — האם צריך לכתוב מחדש את האינטגרציה?

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

הספק משנה את התנהגות המודל — מה אז?

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

בואו נדון במשימה: מה נדרש להערכת האינטגרציה

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

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

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