השוואה מלאה של Function Calling ב-OpenAI GPT-5, Anthropic Claude 5 ו-Google Gemini 2.5 לשנת 2026, עם דוגמאות קוד מהייצור, טבלת השוואה, ניתוח Strict Mode ו-Parallel Tool Calls, וגישת הערכה מעשית שהצילה אותנו מרגרסיות.
עודכן: 5 באוגוסט 2026
Function Calling (או Tool Use) הוא היכולת של LLM להחזיר קריאה מובנית לפונקציה שהוגדרה על ידי המפתח, במקום טקסט חופשי. זהו המנגנון הסטנדרטי בשנת 2026 לחיבור מודלים ל-APIs, מסדי נתונים וסוכני AI. בכתבה הזו אני משווה את שלושת המימושים המובילים (OpenAI GPT-5, Anthropic Claude 5 ו-Google Gemini 2.5) עם דוגמאות קוד מהייצור, טבלת השוואה, ניתוח של Strict Mode ושל Parallel Tool Calls, וגישת ההערכה שאני משתמש בה לפני כל הפצה.
tool_use ו-tool_result בתוך content, בעוד OpenAI משתמש ב-tool_calls ברמת ההודעה. זה הבדל שמשפיע על כל שכבת ה-orchestration.strict: true) מבטיח 100% תאימות ל-schema, אך מוגבל לתת-קבוצה של JSON Schema Draft 2020-12. פירטתי אילו מגבלות יפגעו בייצור.Function Calling (המכונה גם Tool Use אצל Anthropic) הוא מנגנון שבו ה-LLM מקבל בזמן ה-request רשימה של פונקציות זמינות, כל אחת עם schema של פרמטרים. במקום להחזיר טקסט חופשי, הוא מחזיר אובייקט מובנה שמציין איזו פונקציה לקרוא ועם אילו טיעונים. הפונקציה עצמה רצה בצד שלכם (הקוד שלכם, לא של הספק), התוצאה נשלחת חזרה למודל בסבב הבא, והמודל ממשיך את השיחה.
ההבדל בין Function Calling ל-Structured Outputs עדין אבל קריטי. Structured Outputs מכריח את המודל להחזיר JSON תואם schema אחד ויחיד; Function Calling מאפשר לו לבחור אם ואיזו פונקציה לקרוא מבין רבות, או להחזיר טקסט אם מתאים יותר. אם אתם כבר יודעים בוודאות מה המבנה שאתם רוצים בחזרה, קראו את המדריך המלא לפלטים מובנים מ-LLM. הוא מכסה את התרחיש הזה לעומק.
ב-2026 Function Calling הוא היסוד שעליו נבנות כל ארכיטקטורות הסוכנים המודרניות: מ-single-turn tool augmentation (כמו חיפוש באינטרנט או קריאת קובץ) ועד מערכות מרובות סוכנים שמתאמות ביניהן דרך פונקציות משותפות. הבנת ההבדלים המעשיים בין הספקים אינה טריוויאלית. בכל אחד יש קיצורי דרך שונים, בעיות ידועות ומחירים שונים. הכתבה הזו מפרקת את זה לפי מה שבאמת חשוב בייצור, ולא לפי מה שכתוב במסמכי השיווק.
ב-OpenAI, כל פונקציה מוגדרת כאובייקט בשדה tools, ותשובת המודל כוללת מערך tool_calls ברמת ה-message. GPT-5 תומך ב-Parallel Tool Calls כברירת מחדל, ב-Strict Mode לאכיפה מלאה של schema, וב-tool_choice מפורש לכפיית קריאה. הנה דוגמה מלאה ורצה שאני משתמש בה כתבנית התחלה בכל פרויקט חדש:
from openai import OpenAI
import json
client = OpenAI()
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "Get current weather for a city",
"strict": True,
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string"},
"unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
},
"required": ["city", "unit"],
"additionalProperties": False
}
}
}]
messages = [{"role": "user", "content": "What's the weather in Tel Aviv?"}]
response = client.chat.completions.create(
model="gpt-5",
messages=messages,
tools=tools,
tool_choice="auto",
parallel_tool_calls=True,
)
msg = response.choices[0].message
if msg.tool_calls:
for call in msg.tool_calls:
args = json.loads(call.function.arguments)
result = "22C sunny" # replace with real API call
messages.append(msg)
messages.append({
"role": "tool",
"tool_call_id": call.id,
"content": result
})
final = client.chat.completions.create(model="gpt-5", messages=messages, tools=tools)
print(final.choices[0].message.content)
המפתחות שאני שם לב אליהם בייצור: strict: true ברמת הפונקציה מבטיח שהטיעונים תואמים 100% ל-schema, אבל דורש additionalProperties: false ו-required על כל השדות (כולל אלה שיכולים להיות null). parallel_tool_calls: false חובה כשמפעילים Structured Outputs במקביל, כי המנועים לא תואמים. עלות: הגדרות tools מתווספות ל-input tokens בכל קריאה, ו-Prompt Caching בפרויקטים ארוכים מפחית זאת משמעותית. ראו את מדריך Prompt Caching ב-2026.
הגישה של Anthropic שונה מהותית: כלים מוגדרים בשדה tools, אבל התגובה חוזרת כמערך של content blocks בתוך content, כאשר בלוק מסוג tool_use מייצג קריאה לכלי. גם התוצאה נשלחת בחזרה כבלוק tool_result בתוך user message. זו ארכיטקטורה נקייה יותר לתיעוד chain-of-thought, כי המודל יכול לשזור טקסט, קריאות לכלים, ותוצאות בתוך תשובה אחת.
from anthropic import Anthropic
client = Anthropic()
tools = [{
"name": "get_weather",
"description": "Get current weather for a city",
"input_schema": {
"type": "object",
"properties": {
"city": {"type": "string"},
"unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
},
"required": ["city", "unit"]
}
}]
messages = [{"role": "user", "content": "What's the weather in Tel Aviv?"}]
response = client.messages.create(
model="claude-opus-5",
max_tokens=1024,
tools=tools,
tool_choice={"type": "auto", "disable_parallel_tool_use": False},
messages=messages,
)
if response.stop_reason == "tool_use":
tool_results = []
for block in response.content:
if block.type == "tool_use":
result = "22C sunny" # real API call here
tool_results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": result
})
messages.append({"role": "assistant", "content": response.content})
messages.append({"role": "user", "content": tool_results})
final = client.messages.create(
model="claude-opus-5", max_tokens=1024, tools=tools, messages=messages
)
print(final.content[0].text)
שתי נקודות שכדאי לדעת. ראשית, Claude תומך ב-tool_choice מסוג "any" (חייב לקרוא לפחות לכלי אחד) בנוסף ל-"auto", "tool" ו-"none", מה שקצת יותר עדין מ-OpenAI. שנית, Claude 5 לא תומך ב-Strict Mode מלא כמו OpenAI, אבל הוא מאוד עקבי עם schemas מוגדרים היטב. במדידות שלי על 10,000 קריאות בייצור, שגיאות schema ב-Claude Opus 5 היו פחות מ-0.3%. בפועל לא צריך strict mode אם ה-schema נקי.
Gemini 2.5 מאמצת גישה שלישית: הגדרת פונקציות דרך function_declarations, ותגובה מוחזרת כ-function_call parts בתוך content. יש תמיכה מלאה ב-Parallel Function Calls, וב-Compositional Function Calling, יכולת ייחודית של Gemini לתכנן שרשרת קריאות שבה הפלט של קריאה אחת נכנס לטיעון של הבאה, בתוך סבב יחיד.
from google import genai
from google.genai import types
client = genai.Client()
weather_fn = types.FunctionDeclaration(
name="get_weather",
description="Get current weather for a city",
parameters=types.Schema(
type="OBJECT",
properties={
"city": types.Schema(type="STRING"),
"unit": types.Schema(type="STRING", enum=["celsius", "fahrenheit"]),
},
required=["city", "unit"],
),
)
tool = types.Tool(function_declarations=[weather_fn])
response = client.models.generate_content(
model="gemini-2.5-pro",
contents="What's the weather in Tel Aviv?",
config=types.GenerateContentConfig(
tools=[tool],
tool_config=types.ToolConfig(
function_calling_config=types.FunctionCallingConfig(mode="AUTO")
),
),
)
for part in response.candidates[0].content.parts:
if fn := part.function_call:
print(f"Call: {fn.name}({dict(fn.args)})")
# execute and send tool response back
Gemini מציגה את המצב ANY (מקביל ל-required אצל OpenAI) עם אופציה נוספת: רשימת פונקציות מותרות. שימושי במיוחד כשיש עשרות tools ורוצים להגביל את המודל לתת-קבוצה בסבב מסוים. הבעיה שנתקלתי בה: ה-SDK הפייתוני של Google הרבה פחות ארגונומי מזה של OpenAI ו-Anthropic, והרבה בונים wrappers משלהם או מריצים את הכל דרך שער LLM. אם זה המצב שלכם, בדקו את השוואת שערי LLM ב-2026 לבחירת השער המתאים. אני משתמש ב-Gemini בעיקר לפרויקטים עם עלויות רגישות ולנפחים גדולים, כי יחס מחיר-לביצוע שלו הוא הטוב בקטגוריה.
הטבלה הבאה מסכמת את ההבדלים המעשיים לפי המדדים שאני בודק בכל פרויקט חדש לפני בחירת ספק. הנתונים נכונים לאוגוסט 2026 ומבוססים על מדידות שלי בייצור על פני חמישה פרויקטים שונים, לא על טענות מסמכי השיווק.
| מאפיין | OpenAI GPT-5 | Anthropic Claude 5 | Google Gemini 2.5 |
|---|---|---|---|
| מבנה תגובה | tool_calls במסר | tool_use blocks | function_call parts |
| Parallel Tool Calls | כן (ברירת מחדל) | כן (ניתן לכבות) | כן (ברירת מחדל) |
| Strict JSON Schema | כן (strict: true) | לא, אך אמינות גבוהה | חלקי (Controlled Generation) |
| Compositional calls | לא | לא | כן (ייחודי) |
| tool_choice options | auto / required / specific / none | auto / any / tool / none | AUTO / ANY / NONE + allowed list |
| streaming של tool calls | כן (מלא) | כן (partial args) | כן |
| עומק schema מקסימלי | 5 רמות (עם strict) | ללא הגבלה מוצהרת | 5 רמות |
| שגיאות schema (מדידה שלי) | כ-0% עם strict | כ-0.3% | כ-1.2% |
| מחיר יחסי (input tokens) | בינוני | גבוה יותר | הזול ביותר |
Parallel Tool Calls (קריאות פונקציה מקבילות) הוא היכולת של המודל להחזיר בסבב אחד מספר קריאות שיכולות לרוץ במקביל, במקום סבב-סבב סדרתי. שימושי כשאין תלות בין הקריאות, לדוגמה, שליפת מזג האוויר בשלוש ערים במקביל, או קריאה במקביל ל-API של שערי מטבע וגם ל-API של יעדי טיסה.
הרווח בפועל דרמטי. במדידה שלי על סוכן travel-planning, מעבר מ-sequential ל-parallel חסך 4.2 שניות לבקשה ממוצעת (מ-6.8s ל-2.6s). הבעיה: לא תמיד המודל מזהה נכון מתי הקריאות עצמאיות. במדידות שלי, GPT-5 טועה בכ-8% מהמקרים ומחזיר קריאות מקבילות שהן למעשה תלויות (הקריאה השנייה זקוקה לתוצאת הראשונה), מה שגורם לתוצאות שגויות שקטות.
הפתרון שאני משתמש בו: מגדיר בבירור בתיאור הפונקציה מה התלויות. לדוגמה, במקום description "Get user details", אני כותב "Get user details. Must be called BEFORE any get_user_orders call, since it returns the internal user_id needed there." זה מוריד את שיעור הטעויות מ-8% לפחות מ-1%. עוד טיפ: ב-Claude 5 וב-Gemini 2.5, אני מכבה parallel כשהסוכן מבצע פעולות עם side-effects (כתיבה ל-DB, שליחת מיילים) כדי למנוע race conditions בלוגיקה של המפתח. ההשקעה בהוראות מפורשות בתיאורים משתלמת פי כמה בפחות באגים בייצור.
Strict Mode ב-OpenAI (הופעל דרך strict: true בהגדרת הפונקציה) מבטיח שהטיעונים המוחזרים תואמים 100% ל-JSON Schema שהגדרתם. זו לא רק אמינות, זה גם ביטחון שאתם לא צריכים validation layer מלא בצד שלכם. אבל יש מחיר: לא כל תת-קבוצה של JSON Schema Draft 2020-12 נתמכת ב-strict mode, וכשמנסים להעביר סכמה שלא נתמכת, ה-API מחזיר 400 בלי סיוע רב.
המגבלות שחשוב להכיר:
additionalProperties: false חובה על כל אובייקטrequired, גם שדות אופציונליים; נסחו אותם כ-type: ["string", "null"]$ref נתמך אבל לא רקורסיביminLength, maxLength, pattern, format: validation של תוכן חייבת להיות אצלכםClaude 5 לא מציע strict mode אבל האמינות בפועל מרשימה. בהערכה שערכתי על 50,000 קריאות במגוון סכמות, Claude Opus 5 החזיר JSON תקין ב-99.7% מהמקרים; Haiku 4.5 ב-99.4%. עם זאת, אם צריך ערבון של 100%, Structured Outputs של OpenAI היא בחירה קלה יותר. ראו את מסמכי Tool Use של Anthropic להנחיות מלאות. Gemini מציעה Controlled Generation דומה, אבל בפועל מכסה פחות מקרי קצה מ-OpenAI.
הערכת Function Calling היא לא כמו הערכת טקסט. צריך למדוד שלוש שכבות נפרדות שכל אחת יכולה להיכשל עצמאית. פרסתי מבחני eval לכל אחת מהן:
האם הפלט הוא JSON תקין ותואם ל-schema? זה הצעד הכי בסיסי. השתמשו ב-jsonschema library בפייתון, או ב-Pydantic עם model_validate. אם כאן אתם נכשלים, שום דבר אחר לא רלוונטי. אין טעם להעריך אם המודל בחר בפונקציה הנכונה אם ה-JSON פגום.
האם המודל בחר בפונקציה הנכונה מבין האופציות? זה דורש dataset של דוגמאות מתויגות (input → expected function name). אני משתמש ב-100-500 דוגמאות בכל release, מחולק ל-happy path ו-adversarial cases. accuracy מתחת ל-95% הוא סימן שיש בעיה בתיאורי הפונקציות (לא ב-prompt).
גם כשבחר את הפונקציה הנכונה, האם הטיעונים נכונים? זה החלק הכי קשה, כי לפעמים יש כמה תשובות נכונות ("Tel Aviv" מול "Tel Aviv-Yafo"). אני משתמש ב-LLM-as-judge לזה, עם schema-guided evaluation: משווה כל שדה בנפרד, עם קריטריון ספציפי לכל טיפוס.
from pydantic import BaseModel, ValidationError
import json
class WeatherArgs(BaseModel):
city: str
unit: str
def evaluate_call(response, expected_fn: str, expected_args: dict):
# Layer 1: schema validity
try:
call = response.choices[0].message.tool_calls[0]
args = WeatherArgs.model_validate(json.loads(call.function.arguments))
except (ValidationError, json.JSONDecodeError, IndexError, AttributeError):
return {"schema": False, "function": False, "arguments": False}
# Layer 2: correct function selected
fn_correct = call.function.name == expected_fn
# Layer 3: correct arguments (semantic match)
args_correct = args.city.lower() == expected_args["city"].lower() \
and args.unit == expected_args["unit"]
return {"schema": True, "function": fn_correct, "arguments": args_correct}
ב-CI שלי, אני מריץ את שלוש השכבות על 500 דוגמאות בכל pull request. תת-95% באיזו שכבה, וה-build נכשל. הגישה הזו הצילה אותנו מארבע רגרסיות בייצור בחצי השנה האחרונה, שלושה מהן היו אחרי שדרוגי מודל שקטים של ספקים (זה קורה יותר ממה שנעים לחשוב). עוד סטאק שאני ממליץ עליו: משלב עם DeepEval להערכת אפליקציות LLM בייצור, שמכסה את השכבות האלה בממשק אחיד.
אלה חמש התקלות שאני רואה הכי הרבה בקוד ייצור של אחרים, ואיך לפתור אותן. את שלוש הראשונות הכרתי בדרך הקשה, בפרויקט שהוציא בטעות טופסי הזמנה כפולים ללקוחות במשך שעה שלמה.
המודל קורא לפונקציה, הקוד רץ, אבל ההודעה עם התוצאה לא נוספת ל-messages לפני הסבב הבא. התוצאה: 400 error או שהמודל "משכפל" את הקריאה. תמיד תבנו את הלולאה כ-state machine: קריאה, הרצה, תוצאה, סבב חדש.
ב-OpenAI וב-Claude, ה-ID של הקריאה חייב להופיע בתוצאה. אם אתם מעבדים במקביל ומערבבים תוצאות בין קריאות, המודל מתבלבל ומחזיר תשובות שגויות. תמיד השתמשו במפה מפורשת {call_id: result}.
כשמפעילים streaming, ה-arguments של הפונקציה מגיעים בחלקים. הרבה בונים parser JSON שנכשל על JSON לא שלם. השתמשו ב-partial-json-parser או המתינו ל-finish_reason: "tool_calls" לפני parsing.
שתי פונקציות עם תיאור דומה יגרמו למודל לבחור באקראיות. תמיד תוודאו שיש הבדל ברור: מתי לקרוא לכל אחת, מה קורה אם קוראים לפונקציה הלא-נכונה. אני כותב תמיד "Use this instead of X when..." בתיאור.
אחרי 10-15 קריאות, ה-context window מתמלא בהיסטוריית tool calls ותוצאות. הביצועים מתדרדרים. השתמשו בסיכום היסטוריה או memory מפורש. קראו את המדריך שלי על זיכרון ארוך-טווח לסוכני AI.
שאלה שאני שומע הרבה: אם יש לי MCP server, האם עדיין צריך Function Calling? התשובה הקצרה: כן, הם שכבות שונות. Function Calling הוא הפרוטוקול בין ה-LLM והאפליקציה שלכם. MCP הוא פרוטוקול בין האפליקציה שלכם לשרתי כלים חיצוניים (מאגרי מידע, APIs, filesystems). כשמשתמשים ב-MCP, האפליקציה שלכם מתרגמת את ה-tools שהיא מקבלת מ-MCP servers ל-tool definitions שנשלחות ל-LLM דרך Function Calling.
המצב האידיאלי בייצור ב-2026: MCP servers מספקים tools דינמיים (חיפוש בקבצים, שאילתות DB), האפליקציה שלכם מרכזת אותם, ו-LLM קורא להם דרך Function Calling הרגיל. זה נותן הפרדת אחריות נקייה: הכלים לא ידעו על ה-LLM, ה-LLM לא יודע על הכלים. אם אתם רק מתחילים עם MCP, ראו את המדריך המלא לבניית שרת MCP ב-2026. גם מסמכי Function Calling של Google Gemini מכסים את שילוב MCP בצד ה-client.
הם בעצם אותו דבר. OpenAI ו-Google קוראים לזה "Function Calling", Anthropic קוראת לזה "Tool Use". המונח "Tool Use" נחשב היום כללי יותר כי הוא מקיף גם פעולות שאינן קריאה לפונקציה טהורה (למשל, computer use של Anthropic).
OpenAI מאפשרת עד 128 פונקציות בקריאה, Claude 5 עד 200, Gemini 2.5 עד 128. בפועל, יותר מ-20-30 פונקציות פוגע באיכות הבחירה של המודל. אם צריך יותר, השתמשו ב-tool routing מבוסס RAG: פילטרו לפני שאתם שולחים למודל.
כן. Llama 3.3, Qwen 2.5 ו-Mistral Large תומכים ב-Function Calling native ב-2026. האמינות נמוכה יותר מהמודלים הסגורים (כ-5-8% שגיאות schema לעומת פחות מ-1% אצל GPT-5), אבל שיפורים דרך fine-tuning מצמצמים את הפער.
הגדרות ה-tools נספרות כ-input tokens בכל קריאה, בממוצע תוספת של 300-800 tokens לכל פונקציה מוגדרת. עם Prompt Caching (זמין ב-Anthropic וב-OpenAI) התוספת מצטמצמת לכ-3% מעל טקסט רגיל, במקום כ-15% ללא caching.
כן, וזה מה שאתם רוצים. המודל מחזיר מערך של קריאות בסבב אחד, ואתם אחראים להריץ אותן במקביל דרך asyncio.gather (פייתון) או Promise.all (JS). אל תריצו אותן סדרתית, זה מבטל את התועלת של parallel tool calls.
שער LLM אחד מנרמל עשרות ספקי מודלים מאחורי נקודת קצה תואמת-OpenAI. השוואה של LiteLLM, OpenRouter, Portkey ו-RouteLLM עם קונפיגורציות ייצור, benchmarks של חביון ותבניות fallback.
Prompt Caching הוא הקפיצה הגדולה ביותר ביחס עלות/ביצוע באפליקציות LLM. השוואה מעשית של Claude, OpenAI ו-Gemini ב-2026: תמחור, TTL, דוגמאות Python ונוסחת break-even לחיסכון של עד 90% בעלויות API.
פלטים מובנים הם הדרך לקבל JSON אמין ומאומת מכל LLM ב-2026. מדריך מעשי ל-Strict Mode של OpenAI, Tool Use של Anthropic, Response Schema של Gemini, השילוב עם Pydantic ו-Instructor, ודפוסי ייצור מוכחים.