function calling agent: ולידציה קפדנית של פרמטרים כדי למנוע תקלות

כשה‑AI מתחיל לקרוא לפונקציות: למה דווקא הפרמטרים הקטנים שוברים את ה־ai agent הגדול

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

בעולם החדש של function calling agent, שבו מודלי שפה יודעים לא רק "לכתוב טקסט" אלא גם להפעיל קוד, שירותים ו־APIים, החוליה החלשה היא כמעט תמיד אותה חוליה ישנה: ולידציה של פרמטרים. מה שפעם היה "נו, נבדוק בצד השרת", הפך היום לקרב חפירות בין המודל, המפתח והמציאות הבלתי צפויה של המשתמשים.

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

המעבר מ־Chatbot ל־ai agent: איך פונקציה אחת הופכת לשער כניסה לעולם אמיתי

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

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

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

הפרדוקס: ככל שה‑ai agent חכם יותר, כך הוא צריך שמירה הדוקה יותר

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

בלי ולידציה קשיחה של פרמטרים לפני שקריאה לפונקציה יוצאת לדרך – הסיכוי לסטייה גובר. הערך "מחר בבוקר" יכול להפוך למחר בתאריך בפורמט לא מוכר; שם משתמש יכול להגיע באותיות בעברית, כשמאחורי הקלעים אתם מצפים ל־slug באנגלית; וסכום "בערך אלף" עלול להתפרש כ־100000. אלו לא דוגמאות תיאורטיות, זה קורה.

מה זה בעצם function calling agent, ואיך הוא חושב על פרמטרים

בשביל להבין למה ולידציה של פרמטרים היא קריטית, צריך רגע להתעכב על איך עובד function calling agent טיפוסי. מתחת לכל השכבה השיווקית, יש תבנית די ברורה: מודל שפה גדול (LLM), הגדרת פונקציות (tools), ומעטפת שמתווכת ביניהם.

רגע, איך נראה היום ai agent טיפוסי בשטח?

בתרחיש סטנדרטי, אתם מגדירים למודל רשימת פונקציות: create_order, get_user_profile, update_subscription – כל אחת עם שם, תיאור וסכמת פרמטרים בפורמט JSON. ה־ai agent מקבל בקשה מהמשתמש, מנתח את הטקסט, מחליט איזו פונקציה רלוונטית ו"מרכיב" עבורה פרמטרים.

לכאורה, הכל מסודר. אתם אפילו מציינים שהשדה amount הוא מסוג number, שהשדה currency הוא string ושהשדה date הוא תאריך ב־ISO. אבל המודל לא באמת "מרגיש" JSON. הוא לא מריץ בדיקות יחידה. הוא פשוט מנפיק טקסט שנראה כמו JSON, בהתאם לדוגמאות שקיבל ולדפוסים שלמד.

איפה מתרחשת הטעות? בדרכים הקטנות

מי שעקב אחרי היישומים הראשונים של ai agentים בישראל מספר על דפוס חוזר: אולי 90% מהקריאות עוברות חלק, אבל ה־10% הנותרים – אלו שמגיעים עם פינות עגולות, עם ניסוח יצירתי או קלט לא צפוי – שם בדיוק המערכת נשברת.

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

ולידציה קפדנית: לא מילה גסה, אלא קו הגנה ראשון

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

שלוש רמות ולידציה שבלי־הן פשוט מסוכן לעבוד

אפשר לדבר על זה בשפה פשוטה: יש שלוש שכבות ולידציה ש־ai agent בריא צריך:

שכבה ראשונה – ולידציה מבוססת סכמות. כלומר, שימוש ב־JSON Schema, ב־Pydantic, או בכל מנגנון מחמיר אחר שמוודא שהטיפוסים, הפורמטים והחובות (required) אכן מיושמים. זה המינימום. המודל יכול לנסות לשלוח לכם "amount": "חמש מאות", אבל הסכמה תעצור את זה.

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

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

ולידציה לא אמורה להרוס את החווייה – אלא להציל אותה

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

מי שעובד היום על ai agent בעולם הפיננסי בארץ, מספר שהמשתמשים דווקא מעריכים את השאלות הבהירות. במיוחד כשמדובר בכסף. השילוב בין פונקציות אוטומטיות לבין ולידציה שמכבדת את המשתמש – זו כבר רמה אחרת של אמון.

המקרה הישראלי: שפה, רגולציה, ומורכבות מקומית ש‑ai agent חייב ללמוד לכבד

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

כשמכניסים ai agent לארגון ישראלי – במיוחד אחד שעושה function calling מול מערכות ליבה – הוורסטיליות הזו הופכת למוקש. המשתמש כותב "תעשה לי העברה לזאב, כמו פעם שעברה, רק הפעם תפרוס את זה". מה זה "תפרוס"? תשלומים? הוראת קבע? הלוואה? המודל מנחש. בלי ולידציה שתעבור על הפרמטרים בפועל, תבדוק מי זה זאב, מה נעשה איתו בעבר, ומה מותר לפי חוק – זה עלול להפוך לשיחת טלפון נזעמת למוקד השירות.

ולידציה מול מציאות עסקית – לא רק מול קוד

אחד ההבדלים בין האופן שבו ai agent עובדים בישראל לבין ארה"ב, למשל, הוא שבארץ הרבה מהעסקים עדיין "חצי דיגיטליים". מערכת אחת בענן, אחת על שרת מקומי, אחת בכלל בקבצי אקסל. כשרוצים לחבר ביניהן דרך function calling, מתגלה עולמה המרתק (או המייאש) של אינטגרציה.

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

דוגמה קטנה מהשטח

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

איך נראית ולידציה "חכמה" בעולם של ai agent?

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

שילוב בין ולידציה דקלרטיבית למודיעין של המודל

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

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

לבדוק שהתאריכים חוקיים, שאין התנגשות עם מגבלות ידועות (למשל, מינימום לילות), ושכל פרמטר חיוני אכן מולא. אם משהו חסר – המודל מקבל חזרה "שגיאה רכה" שמנוסחת בשפה טבעית, ושואל את המשתמש שאלה משלימה. ככה function calling agent הופך לשיחה עם קצב הגיוני, לא לרולטה רוסית.

ולידציה כאובזרבר, לא כשוטר

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

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

שאלות ותשובות: מה כולם שואלים כשמתחילים לעבוד עם ai agent ו־function calling

שאלה: אם המודל כבר מחזיר JSON לפי סכמות, למה בכלל צריך ולידציה נוספת?

לכאורה, זה אמור להספיק. בפועל, מודל שפה "משחק" JSON, הוא לא באמת מריץ טיפוסי נתונים. הוא יכול להחזיר תאריך "2025-13-40" – פורמטית זה נראה תקין, לוגית זה מופרך. סכמות בסיסיות לא יעלו על זה. בנוסף, יש דברים שרק אתם יודעים: מה הערכים המותרים, מי המשתמש הנוכחי, אילו שדות חייבים להיות עקביים.

שאלה: ולידציה קשוחה לא תהרוג את חוויית השיחה עם ה‑ai agent?

תלוי איך מיישמים. אם המערכת פשוט זורקת שגיאות טכניות – כן, זה מתסכל. אם לעומת זאת אתם מתרגמים את כשלי הוולידציה לשאלות טבעיות – המשתמש אפילו ירגיש שהשירות "משקיע בו". "רק מוודא – זה הסכום הסופי, כולל מע"מ?" נשמע הרבה יותר טוב מ-"פרמטר amount אינו תקין".

שאלה: אפשר לסמוך על המודל עצמו שיעשה ולידציה?

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

שאלה: איך מתחילים להכניס ולידציה לארגון שכבר רץ עם function calling בלי?

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

טבלה: סיכום עיקרי ההיבטים של ולידציה ב‑ai agent עם function calling

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

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

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

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

לא עוד "נעשה פיילוט ונראה" – אלא תכנון מודע של גבולות

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

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

מילה לסיום: למה ולידציה היא לא "אנטי‑AI" אלא להפך

לפעמים, בשיחות מסדרון, אתה שומע משפטים כמו "אם כבר הבאנו ai agent, למה צריך כל כך הרבה מגבלות?". זו תפיסה מובנת, אבל גם קצת מסוכנת. ולידציה קפדנית של פרמטרים היא לא אנטי‑AI, היא התנאי לשימוש ב‑AI במקומות אמיתיים, משמעותיים, ולא רק בדף הדמו.

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

אם אתם נמצאים היום בשלב שבו ארגון ישראלי שלכם בוחן ai agent, מתלבט לגבי function calling, או כבר חווה תקלות מוזרות בפרמטרים – זה בדיוק הרגע לעצור ולתכנן שכבת ולידציה רצינית. לא כעוד "טיקט" ב־Jira, אלא כחלק מהארכיטקטורה.

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