קריאה לכלים (Tool Use)

מה זו קריאה לכלים, ולמה היא הופכת צ'אטבוט לסוכן

קריאה לכלים (Tool Use) היא יכולת של מודל AI להפעיל בעצמו תוכנות ושירותים חיצוניים — לחפש באינטרנט, להריץ קוד, לגשת למסד-נתונים, לשלוח בקשת-רשת — ולא רק לענות בטקסט מתוך הידע הפנימי שנצבר באימון. היכולת הזו היא הבסיס הטכני שהופך צ'אטבוט פסיבי לסוכן AI פעיל: במקום להסתמך רק על מה שהמודל "זוכר" (שעלול להיות מיושן, חלקי או שגוי), הוא יכול לפנות בזמן-אמת למקורות עדכניים או לבצע פעולות ממשיות בעולם החיצוני.

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

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

איך זה עובד בפועל: סכימת-קלט, tool_use ו-tool_result

מבחינה טכנית, קריאה לכלי מתבצעת כסבב תקשורת של שני צעדים לפחות, לא כ"קסם" חד-פעמי. תחילה המפתח מגדיר לכלי סכימת-קלט (JSON Schema) שמפרטת את שם-הכלי, תיאור מילולי של מה שהוא עושה, ואת הפרמטרים שהוא מקבל — למשל כלי get_weather שמקבל פרמטר location מסוג מחרוזת. המודל מקבל את רשימת-הכלים הזו יחד עם הודעת-המשתמש, ומחליט לבדו אם וכיצד לקרוא לכלי: אם הוא בוחר לקרוא, תשובתו אינה טקסט חופשי אלא בלוק מובנה בשם tool_use (אצל Anthropic) או function_call (אצל OpenAI), שכולל את שם-הכלי ואת הפרמטרים כאובייקט-JSON תקין.

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

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

קריאה-לפונקציה אצל OpenAI: קריאות-מקבילות ו-tool_choice

OpenAI הייתה החברה שהפכה את המנגנון הזה לזמין בקנה-מידה תעשייתי: ביוני 2023 היא פרסמה ממשק-תכנות ייעודי לקריאה-לפונקציות (Function Calling), שהוסיף למודל את היכולת להחזיר בלוק function_call מובנה במקום טקסט חופשי. הגרסה המודרנית של הממשק מוסיפה שתי הרחבות משמעותיות מעבר לקריאה-בודדת-לכלי-בודד. הראשונה, קריאות-מקבילות (Parallel Tool Calls): במודלים תומכים — לפי התיעוד, החל מדור GPT-5 גם לצד כלים מובנים — המודל יכול להחזיר כמה בלוקי function_call באותו סבב-תשובה — למשל לבדוק גם מזג-אוויר וגם תנועה בכביש בקריאה אחת, במקום שני סבבים נפרדים; מפתח שרוצה למנוע את זה יכול לכבות את ההתנהגות במפורש דרך הפרמטר parallel_tool_calls.

ההרחבה השנייה נוגעת לשליטה של המפתח על עצם ההחלטה אם לקרוא לכלי: הפרמטר tool_choice קובע אם הבחירה נשארת לשיקול-דעתו המלא של המודל (auto, ברירת-המחדל — "אפס, כלי אחד, או כמה כלים"), מחייבת קריאה לכלי כלשהו (required), או כופה קריאה לכלי ספציפי-מראש — למשל כשהמפתח יודע בוודאות שהמשימה דורשת בדיוק כלי אחד מסוים, ולא רוצה להשאיר את זה לניחוש. Anthropic מיישמת בדיוק את אותה אבחנה בפרמטר tool_choice משלה, בשלוש הצורות המקבילות: auto, any, ו-tool (כלי ספציפי).

קריאה לכלים לא ניתנת בחינם מבחינת-עלות: עצם הוספת רשימת-כלים לבקשה מוסיפה טוקנים קבועים לכל קריאת-API, גם אם המודל בסוף לא משתמש באף כלי. אצל Anthropic, למשל, התיעוד הרשמי מפרט שעבור Claude Opus 5 עם tool_choice במצב auto מתווספים כ-286 טוקנים לכל בקשה, וכ-406 טוקנים במצב שמחייב קריאה לכלי (any / tool) — עלות-רקע שגדלה עם מספר הכלים המוגדרים ועם אורך התיאורים שלהם, ושמצטרפת לעלות תוכן-השיחה הרגיל.

לולאת ReAct: לשלב חשיבה עם פעולה במשימות מרובות-שלבים

קריאה בודדת לכלי מספיקה לשאלה פשוטה כמו מזג-אוויר, אבל משימה מורכבת-יותר — "מצא לי טיסה זולה ואז הזמן מלון קרוב לשדה-התעופה" — דורשת כמה קריאות-כלים ברצף, כשכל תוצאה משפיעה על הצעד הבא. המסגרת המחקרית שהניחה את הבסיס לדפוס הזה היא ReAct (ראשי-תיבות של Reasoning+Acting), שפרסמו חוקרים מאוניברסיטת פרינסטון וגוגל ריסרץ' באוקטובר 2022: הרעיון הוא לגרום למודל לייצר, בכל צעד, גם "מחשבה" מילולית (מה עליי לעשות עכשיו ולמה) וגם "פעולה" — קריאה לכלי — בצורה מוצלבת, כשתוצאת-הפעולה חוזרת להזין את המחשבה הבאה.

החוקרים דיווחו ששילוב הזה שיפר את הדיוק במשימות ניווט-אינטראקטיבי כמו ALFWorld וקניות-מדומות כמו WebShop בשיעור-הצלחה מוחלט של 34 אחוז ו-10 אחוז בהתאמה, לעומת שיטות של למידה-בחיקוי ולמידת-חיזוק — וגם צמצם טעויות-עובדתיות (הזיות) בהשוואה למודל שחושב בלי גישה לכלים, כי כל טענה עוברת בדיקה מול תוצאת-כלי אמיתית ולא נשארת ניחוש, תוך שימוש במעט-מאוד דוגמאות-הדגמה בתוך הפרומפט. הדפוס הזה, לולאת "קרא-לכלי, קבל-תוצאה, המשך", הוא הבסיס הטכני שעליו נבנים כמעט כל סוכני-ה-AI האוטונומיים היום — כולל מסגרות-סוכנים מסחריות שנבנו שנים אחרי הפרסום המקורי.

מיוני 2023 ועד MCP: מקריאה-בודדת לפרוטוקול שלם

קריאה-לכלים ופרוטוקול-הקשר-למודל (MCP) פותרים בעיות שונות, לא זהות, וחשוב להבין את היחס ביניהן. קריאה-לכלים היא היכולת של המודל "לבחור" כלי בודד ולהריץ אותו; MCP, שפרסמה Anthropic כקוד-פתוח בנובמבר 2024, הוא פרוטוקול-תקשורת שלם שמסטנדרט איך כלים נחשפים למודל מלכתחילה — כדי שמפתח לא יצטרך לכתוב אינטגרציה נפרדת וייעודית לכל כלי חדש.

במילים אחרות: קריאה-לכלים היא המנגנון שבו המודל מפעיל כלי בזמן-אמת; MCP הוא הדרך שבה הכלי "מציג את עצמו" למודל מראש, בשפה אחידה. שני המנגנונים משלימים זה את זה בפועל: שרת-MCP חושף למודל רשימת-כלים זמינים, ומרגע שהמודל בוחר כלי מהרשימה, ההפעלה עצמה עדיין עוברת דרך אותו מנגנון-קריאה-לכלים שתואר למעלה — בלוק tool_use או function_call, ותוצאה שחוזרת כ-tool_result.

בפועל, מפתח שבונה מוצר חדש היום בוחר בין שתי גישות לא-סותרות, ולעיתים קרובות משלב ביניהן באותה מערכת: להגדיר כלים ישירות בקוד שלו (קריאה-לכלים "גולמית", שנתפרת בדיוק למשימה הספציפית), או להתחבר לשרתי-MCP קיימים שכבר חושפים כלים מוכנים-מראש לשירותים נפוצים כמו Google Drive, Slack או GitHub — ולחסוך כך את כתיבת-האינטגרציה מאפס לכל שירות כזה.

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

קריאה לכלים לא חפה מסיכונים, וחלקם נובעים בדיוק מהגמישות שהופכת אותה לשימושית. מודל עלול לבחור כלי לא-מתאים למשימה, לפרש-שגוי פרמטר (למשל להשלים ניחוש למיקום שהמשתמש לא ציין, במקום לשאול, כפי שתועד למעלה), או לקרוא לכלי רגיש — שליחת-מייל, ביצוע-רכישה, מחיקת-קובץ — בלי בקרה מספקת על ההשלכות. מסגרות-הערכה ייעודיות, כמו לוח-התוצאות של Berkeley לקריאה-לפונקציות (Berkeley Function-Calling Leaderboard), נבנו במיוחד כדי למדוד את היכולת הזו על סטים המבוססים בחלקם על נתונים אמיתיים ובחלקם על תרחישים מותאמים: לא רק אם המודל קרא לכלי הנכון, אלא גם אם הוא זיהה נכון מתי לא לקרוא לכלי בכלל — טעות בכיוון ההפוך שקל לפספס בבדיקה שטחית. גרסה 3 של הלוח הוסיפה במיוחד תרחישי רב-תורי (Multi-Turn), שבודקים אם המודל שומר הקשר נכון על פני כמה קריאות-כלים עוקבות באותה שיחה, לא רק בקריאה בודדת ומבודדת.

בדיוק בגלל הסיכונים האלה, מערכות רבות משלבות מנגנוני אדם-בלולאה (Human-in-the-Loop) סביב כלים בעלי-סיכון, ולא מאפשרות לסוכן לפעול בחופשיות מלאה מהרגע הראשון; כלים רגישים במיוחד מורצים גם בתוך ארגז-חול (Sandbox) מבודד, כדי שגם טעות תישאר מוכלת ולא תיגע בסביבת-ייצור אמיתית.