בוט תמיכה שממציא יתרות חשבון הוא לא רק חסר תועלת בבנק דיגיטלי. הוא מסוכן. שיחות פיננסיות דורשות מספרים מדויקים, מקבלים (payees) מאומתים, ועקבות ביקורת (audit trail) לכל טענה. מודלי שפה גדולים מצטיינים בשיחה, אך הם מייצרים הזיות (hallucinate). כשמשתמש שואל, "כמה נשאר בחשבון שלי?", המודל חייב לפנות למסד נתונים, לא לדמיון. זה בדיוק מה ש-function calling אוכף, וזהו לב המבנה הזה.
Gemma 4 של Google מעניקה למפתחים מודל עוצמתי בעל 31 מיליארד פרמטרים שיכול לעקוב אחר הוראות מורכבות ולנהל דיאלוג טבעי, כולל בניבים אזוריים. בשילוב עם Google AI Studio, הוא הופך לסביבת אב-טיפוס מהירה שבה ניתן להגדיר כלים, לבדוק מקרי קצה ולייצא JavaScript עובד לפני שנוגעים בשרת. המטרה כאן היא סוכן תמיכה פינטק שבודק יתרות חשבון, עוקב אחר סטטוס עסקאות ומשלם חשבונות. באופן קריטי, הוא מגיב ב-Nigerian Pidgin כאשר המשתמש עושה זאת, תוך התאמת הטון מבלי להמציא עובדות פיננסיות לעולם.
למה function calling חשוב לבוטים פיננסיים
ללא function calling, מודל שפה מתייחס לכל שאלה כתרגיל בכתיבה יוצרת. בקשו ממנו יתרה והוא עלול להמציא מספר שנשמע סביר, השאוב מדפוסים בנתוני האימון שלו. מצב כשל כזה אינו קביל כאשר מדובר בכסף אמיתי.
Function calling הופך את זרימת העבודה. התפקיד של המודל אינו לדעת את היתרה. תפקידו הוא לזהות כוונה, לבחור בכלי הנכון ולחלץ פרמטרים. כשמשתמש כותב "בדוק את היתרה שלי", Gemma 4 מפיקה בקשת JSON מובנית — משהו כמו קריאה ל-get_balance עם account_id. ה-backend שלכם מבצע את הקריאה מול מערכת הבנקאות המרכזית, מקבל את המספר האמיתי ומזין אותו בחזרה לשיחה. רק אז המודל מייצר את המשפט המיועד למשתמש. כל תשובה מגיעה מקריאה לכלי ב-backend. מכיוון שהמודל מוגבל על ידי לוגיקה חיצונית, ההזיות נעצרות בגבול ה-API.
דפוס זה יוצר גם עקבות ביקורת ברורים. כל בקשת כלי והתוצאה המתאימה לה נרשמות בהיסטוריית ההודעות. רגולטורים וצוותי סיכונים יכולים לבדוק בדיוק מתי נבדקה יתרה ואיזה מספר המשתמש קיבל.
עיצוב הסוכן ב-Google AI Studio
זרימת העבודה מתחילה בתוך Google AI Studio. בחרו ב-gemma-4-31b-it, הגרסה המותאמת להוראות (instruct-tuned) שעברה אופטימיזציה לדיאלוג ומעקב אחר הוראות.
לאחר מכן, כתבו הוראות מערכת (system instructions) המציבות גבולות ברורים. עבור בנק דיגיטלי, הטון צריך להיות מקצועי, ישיר ורגוע. אך ההוראות חייבות ללכת רחוק יותר. אמרו למודל במפורש שהוא לעולם אינו מעריך נתוני חשבון, לעולם אינו מניח סטטוס עסקה, ולעולם אינו משלים תשלום חשבון מבלי לאשר את תוצאת הכלי. אם המשתמש כותב ב-Nigerian Pidgin, המודל צריך להשיב ב-Nigerian Pidgin. אם המשתמש עובר לאנגלית, המודל עוקב אחריו. ה-system prompt הוא המקום שבו אתם מקודדים מדיניות אמון ובטיחות בשפה פשוטה.
לאחר מכן הגדירו את ה-tool schemas. חשבו על אלו כעל חוזים בין המודל לבין ה-backend שלכם. אתם זקוקים לפחות לשלושה:
get_balance
פרמטרים:account_id(string, required)
מחזיר: יתרה נוכחית ומטבע.get_transaction_status
פרמטרים:transaction_reference(string, required)
מחזיר: סטטוס כגון pending, completed, או failed, בתוספת timestamp.pay_bill
פרמטרים:biller_code(string, required),amount(number, required),account_pin(string, optional depending on your flow)
מחזיר: מספר אישור או הודעת שגיאה.
כל schema משתמש בפורמט JSON סטנדרטי המתאר את שם הפונקציה, התיאור ומאפייני הפרמטרים. שדות התיאור חשובים ביותר. כתבו אותם כך שהמודל יבין מתי להפעיל כל כלי. תיאורים מעורפלים מובילים לבחירת כלי שגויה, לכן היו ספציפיים: "השתמש ב-get_balance כאשר המשתמש רוצה לדעת את יתרת החשבון הנוכחית שלו. אל תשתמש בו להיסטוריית עסקאות."
אב-טיפוס בדפדפן
לפני שתכתבו אפילו נתיב (route) אחד ב-Express, בדקו את כל זרימת השיחה בתוך פאנל הצ'אט של AI Studio. זה חוסך ימים של עבודה מחדש ב-backend. הקלידו שאילתה ב-Nigerian Pidgin: "Wetin remain inside my account?". צפו האם Gemma 4 מפיקה נכון קריאה ל-get_balance או האם היא מנסה לענות מתוך נתוני האימון. אם היא טועה בפרמטרים — למשל משתמשת ב-account_number במקום ב-account_id — אתם מתקנים את תיאור ה-schema ממש שם.
בדקו גם את מצבי הכישלון. בקשו סטטוס של עסקה מבלי לספק מספר סימוכין. מודל עם הנחיות טובות אמור או לבקש מהמשתמש את הפרמטר החסר, או לקרוא לכלי (tool) עם מה שיש לו ולאפשר ל-backend להחזיר שגיאת אימות (validation error). אתם רוצים לראות את ההתנהגויות הללו בסביבת ה-sandbox, לא ב-production.
ברגע שהפרומפטים והסכמות (schemas) מתנהגים כראוי, ייצאו את קוד ה-JavaScript. AI Studio מייצר קטע קוד (snippet) נקי שמבנה את בקשת ה-API עם ה-system prompt שלכם, הודעת המשתמש והגדרות הכלים (tool definitions). זה יהפוך לבסיס של לוגיקת ה-backend שלכם.
חיבור ה-Express Backend
קחו את הקוד שיוצא והכניסו אותו לאפליקציית Express. הארכיטקטורה היא פשוטה, אך לולאת הביצוע (execution loop) היא החלק הקריטי.
הגדירו endpoint מסוג POST — אולי /chat — שמקבל את הודעת המשתמש וכל היסטוריית סשן (session history). העבירו אותם ל-endpoint של Gemma 4, שאליו תוכלו לפנות באמצעות API תואם OpenAI או ה-inference endpoint של Google עצמה, תלוי בבחירת האחסון שלכם.
התגובה מהמודל נכנסת לאחת משתי קטגוריות. או שמדובר בהודעת טקסט סופית, או שהיא מכילה tool_call המבקש נתונים. כשאתם מקבלים קריאה לכלי (tool call), בצעו את הפונקציה המתאימה מול ה-backend שלכם. שאלו את מסד הנתונים לגבי היתרה. פנו למעבד התשלומים עבור סטטוס החשבון. הוסיפו את תוצאת הכלי להיסטוריית השיחה כהודעה חדשה עם התפקיד (role) tool, ושלחו את כל המערך המעודכן בחזרה ל-Gemma 4.
חזרו על הלולאה הזו עד