מדריך למפתחים בנושא Gemini 3.5 Flash

‫Gemini 3.5 Flash הוא מודל מתקדם וחסכוני במשפחת Gemini 3, שפועל במהירות גבוהה. המודל הזה נועד לספק יכולות של סוכנים ברמה כמעט מקצועית, בלי להתפשר על הביצועים או על הערך. עכשיו הוא זמין לכולם (GA) למפתחים שמשתמשים ב-Gemini API ולארגונים שמשתמשים ב-Gemini Enterprise Agent Platform.

במסמך הזה מוסבר מה חדש ב-3.5 Flash, מתי כדאי להשתמש בו, איך עוברים ל-3.5 Flash ומוצג מדריך להתחלת העבודה עם 3.5 Flash.

איפה הוא משתלב במשפחת Gemini?

בטבלה הבאה מוצגת השוואה של חלק מהמפרטים בין 3.5 Flash,‏ 3.1 Pro ו-3.1 Flash-Lite:

הרשימה המלאה של היכולות, הכלים ואפשרויות הצריכה הנתמכים מופיעה בדף של מודל Flash 3.5.

פירוט תרחישי שימוש

האסטרטגיה המומלצת לתהליכי עבודה של Agentic Workflows משתמשת בגישה מדורגת כדי לייעל את האיכות, המהירות והעלות:

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

מה חדש ב-Gemini 3.5 Flash?

‫Gemini 3.5 Flash מביא איתו את השינויים והשיפורים הבאים לסדרת מודלי Gemini:

• ‫ביצועים מתקדמים ברמה גבוהה: מודל Flash הכי חכם שלנו, שעבר אופטימיזציה למשימות של סוכנים ולכתיבת קוד בהיקף נרחב.
• ביצוע באמצעות סוכנים: פריסת סוכני משנה, פתרון בעיות ולולאות מהירות של סוכנים בהיקף נרחב.
• תכנות משופר: מחזורי תכנות איטרטיביים, חיפוש מהיר ויצירת אב טיפוס לבדיקת נתיבים חלופיים ולחיפוש דינמי של פתרונות.
• טווח ארוך: תהליכי עבודה מרובי-שלבים ושימוש בכלי בהיקף נרחב.
• שמירת מחשבות: המודל שומר באופן אוטומטי על שלבי הביניים של הנימוקים במהלך שיחות מרובות. אין צורך לבצע שינויים ב-API.
• רמת העמקה חדשה שמוגדרת כברירת מחדל: רמת העמקה שמוגדרת כברירת מחדל השתנתה מHIGH לMEDIUM.
• שיפור LOWהחשיבה: רמת החשיבה הנמוכה שופרה באופן משמעותי עבור קוד ומשימות שדורשות פחות שלבים, ומציעה איכות גבוהה יותר עם חביון ועלות נמוכים יותר.

פרטים נוספים זמינים בקטע שינויים עיקריים.

מדריך למתחילים

לפני שמתחילים, צריך לבצע אימות בפלטפורמת הסוכנים באמצעות Application Default Credentials ‏ (ADC) או מפתח API. מידע נוסף מופיע במאמר איך מתחילים להשתמש ב-Gemini Enterprise Agent Platform.

בבלוקי הקוד הבאים, מחליפים את PROJECT_ID במזהה הפרויקט.

התקנה

מוודאים שאתם משתמשים בגרסה העדכנית ביותר של google-genai SDK:

pip install --upgrade google-genai

בקשה בסיסית

from google import genai

client = genai.Client(enterprise=True, project="PROJECT_ID", location="global")

response = client.models.generate_content(
  model="gemini-3.5-flash",
  contents="How does AI work?",
)
print(response.text)

curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/global/publishers/google/models/gemini-3.5-flash:generateContent \
-d '{
  "contents": {
    "role": "USER",
    "parts": { "text": "Why is the sky blue?" },
  },
}'

השינויים העיקריים

בקטע הזה מוסבר בפירוט על השינויים הבאים שבוצעו ב-Gemini 3.5 Flash:

• רמת חשיבה חדשה שמוגדרת כברירת מחדל (MEDIUM)
• שימור תהליכי חשיבה
• הוצא משימוש: פרמטרים של דגימה
• הוצא משימוש: thinking_budget

רמת העמקה חדשה שמוגדרת כברירת מחדל

רמת החשיבה שמוגדרת כברירת מחדל במודלים של Gemini 3 היא עכשיו MEDIUM, במקום HIGH בגרסת הטרום-השקה של Gemini 3 Flash. רמת החשיבה MEDIUM מניבה תוצאות טובות במגוון רחב של משימות, והיא מהירה וחסכונית יותר.

רמות ההעמקה הנתמכות הן:

• ‫MINIMAL: מתאים להגדרה 'ללא חשיבה' עבור רוב השאילתות. יכול להיות שהמודל יחשוב מעט מאוד כדי לעבוד על משימות מורכבות כמו תכנות. מצמצם את זמן האחזור בצ'אט או באפליקציות עם תפוקה גבוהה.
• ‫LOW: חשיבה קלה לרוב המשימות, במהירות גבוהה ובעלות נמוכה יותר.
• ‫MEDIUM: (ברירת מחדל) הגדרה מאוזנת לרוב המשימות שדורשות חשיבה רציונלית.
• ‫HIGH: ממקסם את החשיבה הרציונלית כדי לבצע אופטימיזציה של ביצועי המשימה. יכול להיות שייקח למודל יותר זמן מההגדרה של MEDIUM כדי ליצור את הטוקן הראשון, אבל הפלט יהיה מקיף יותר.

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

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
   model="gemini-3.5-flash",
   contents="A farmer has chickens and rabbits. There are 35 heads and 94 legs. How many chickens and how many rabbits does he have? Show your step-by-step logic.",
   config=types.GenerateContentConfig(
       thinking_config=types.ThinkingConfig(
           thinking_level=types.ThinkingLevel.HIGH
       )
   ),
)
print(response.text)

הפרמטר thinking_level הוא אופציונלי. אם לא מציינים ערך, ‫3.5 Flash ישתמש בהגדרת ברירת המחדל שלו (MEDIUM).

שימור תהליכי חשיבה

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

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

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

הוצאה משימוש: פרמטרים של דגימה

הפרמטרים הבאים לדגימה לא מומלצים יותר לשימוש במודלים של Gemini 3:

• temperature
• top_p
• top_k

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

הוצא משימוש: thinking_budget

הפרמטר thinking_budget של מספר גולמי כבר לא נתמך בכל המודלים של Gemini 3. במקום זאת, צריך להשתמש ב-enum של מחרוזת thinking_level.

# ⚠️ Before (not recommended)
config = types.GenerateContentConfig(
    thinking_config=types.ThinkingConfig(thinking_budget=7500)
)

# ✅ After
config = types.GenerateContentConfig(
    thinking_config=types.ThinkingConfig(thinking_level="MEDIUM")
)

שיטות מומלצות

בקטע הזה מתוארות השיטות המומלצות הבאות לשימוש ב-Flash 3.5:

• שימוש בהתאמה מדויקת של תגובות לבקשות להפעלת פונקציות
• הכללת תוכן מולטימודאלי בתשובת הפונקציה parts
• שימוש בהוראות מוטבעות בתשובת הפונקציה
• הפחתת שימוש מיותר בכלי

שימוש בהתאמה מדויקת של תשובות לקריאות לפונקציות

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

• כולל id: כל FunctionResponse חייב לכלול את id מה-FunctionCall המתאים.
• התאמה ל-name: הערך של name בתגובה צריך להיות זהה לערך של name בקריאה.
• מספר ההתאמות: מחזירה בדיוק FunctionResponse אחד לכל FunctionCall שהתקבל.

הקוד הבא הוא דוגמה להפעלה נכונה של פונקציה:

# ✅ Include matching id and name in the function response
final_response = client.models.generate_content(
    model="gemini-3.5-flash",
    config=config,
    contents=[
        *previous_contents,
        response.candidates[0].content,
        types.Content(role="user", parts=[
            types.Part.from_function_response(
                name=tool_call.name,
                response={"result": result},
                id=tool_call.id,
            )
        ]),
    ],
)

הכללת תוכן מולטימודאלי בתגובה של הפונקציה parts

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

לדוגמה:

# ✅ Include multimodal content in the function response
final_response = client.models.generate_content(
    model="gemini-3.5-flash",
    config=config,
    contents=[
        *previous_contents,
        response.candidates[0].content,
        types.Content(role="user", parts=[
            types.Part.from_function_response(
                name=tool_call.name,
                response={
                    "result": "instrument.jpg",
                    "image": base64_image_data,
                },
                id=tool_call.id,
            )
        ]),
    ],
)

שימוש בהוראות מוטבעות בתשובת הפונקציה

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

לדוגמה:

# ✅ Append inline instructions to the end of the function response separated by two newlines
result_text = f"{json.dumps(result)}\n\n<your inline instructions>"

final_response = client.models.generate_content(
    model="gemini-3.5-flash",
    config=config,
    contents=[
        *previous_contents,
        response.candidates[0].content,
        types.Content(role="user", parts=[
            types.Part.from_function_response(
                name=tool_call.name,
                response={"result": result_text},
                id=tool_call.id,
            )
        ]),
    ],
)

הפחתת השימוש בכלי

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

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

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

   You have a limited action budget of <n> tool calls. Use them efficiently.
   

מעבר ל-‎3.6 Flash מ-‎3.5 Flash או מ-‎3.1 Pro

כדי לעבור ל-3.6 Flash מ-3.5 Flash או מ-3.1 Pro, פועלים לפי השלבים הבאים:

1. עדכון מזהה המודל: משנים את מחרוזת המודל בקריאות ל-API ל-gemini-3.6-flash.
2. התאמת הקוד לכללי ה-API החדשים של משפחת Gemini 3: ב-Gemini 3.6 Flash נאכפים באופן קפדני כללי הפרמטרים ומוסכמות ה-API שנקבעו למשפחת Gemini 3:
   • הסרת הפרמטרים temperature,‏ top-K ו-top-P: מסירים את הפרמטרים המותאמים אישית האלה ממטען הייעודי (payload). המודל לא יציג שגיאה, אבל הוא יתעלם מהם לגמרי. במקום זאת, משתמשים בפרמטר thinking_level או בפלט מובנה json_schema כדי לשלוט בדטרמיניזם של הפלט.
   • הסרת עונשים על תדירות ונוכחות: צריך להסיר את כל ההגדרות המותאמות אישית של עונשים על תדירות ונוכחות כדי למנוע שגיאות בזמן ריצה בקריאות ל-API.
   • מוודאים ששילוב הצ'אט לא מנסה למלא מראש את המודל: בודקים את מערכי היסטוריית ההודעות כדי לוודא שמטען ה-API לא מסתיים בתור ריק של משתמש או בתור ריק של מודל. אם האובייקט האחרון במערך ההיסטוריה הוא תפקיד model (GenerateContent API) או סוג model_output (Interactions API), צריך לשנות את מבנה הרצף כדי למנוע הפעלה של שגיאת אימות מחמירה.
   • שימוש ב-thinking_level: מסירים מופעים של הפרמטר thinking_budget שהוצא משימוש ומשתמשים ב-thinking_level במקומו.
   • החלת כללים מחמירים להפעלת פונקציות: FunctionResponse חייב להתאים בדיוק ל-id, ל-name ולמספר הביצועים של FunctionCall הקודם. אם אתם צריכים להוסיף הוראות בתוך השורה, אתם צריכים להוסיף אותן ישירות בטקסט של תגובת הפונקציה, ולהפריד אותן באמצעות שני מעברי שורה (\n\n).
3. התאמה לשינויים בתהליכי העבודה:
   • אם האפליקציה שלכם מסתמכת על לולאות שיחה מרובות, כדאי לבדוק את תהליכי העבודה כדי לוודא שהתמציתיות של השלב החדש במודל לא גורמת ליציאות מוקדמות.
   • אם אתם בונים סוכנים של frontend או סוכנים בסיסיים של סקריפטים, כדאי לעקוב אחרי קריאות מיותרות של execute_code לצורך בדיקה, בגלל ההטיה החדשה של המודל כלפי בדיקה תוכניתית מראש.

פתרונות עקיפים לדרישות הטקסט של כלי ההכנה

אם ההנחיה שלכם דורשת מהמודל להפיק טקסט מובנה (XLM,‏ YAML,‏ Json וכו') (לדוגמה, <UPDATE>...</UPDATE>) מיד לפני ביצוע קריאה לכלי, יכול להיות שהקריאה לכלי תיכשל מדי פעם עם שגיאה Malformed_Function_Call. כדי לפתור את הבעיה, אפשר לנסות אחד מהפתרונות הבאים:

• (מומלץ) מנחים את המודל להוסיף את ההערות שלו לפני השימוש בכלי בתוך update()בקשה להפעלת פונקציה ייעודית במקום בטקסט גולמי. הוראות מפורטות להטמעה מופיעות בקטע הבא.
• מנחים את המודל לכתוב הערות ככותרות ב-Markdown (לדוגמה, # UPDATE, ## PLAN) במקום כטקסט מובנה.
• לא לחייב את המודל להפיק טקסט לפני קריאות לכלים.

פתרון מומלץ: עוטפים את הערות העבודה בקריאה ייעודית לפונקציה

במקום ההוראה המקורית:

Before calling a tool, in every response you MUST first output a single
`<UPDATE>` part as specified, don't skip this part or any of required sub-tags
within `<UPDATE>`.

משתמשים בהוראה המעודכנת הזו:

Before calling any other tool, in every response you MUST first call `update`
with all required parameters (previous_step, plan, next_step, external).

מעדכנים את כל ההפניות לפורמט ה-XML הישן <UPDATE> בבקשת הלקוח. אחר כך מוסיפים את הצהרת הפונקציה המתאימה לפונקציית העדכון:

{
  "name": "update",
  "description": "Update working notes (previous step analysis, plan, next step, external note).",
  "parameters": {
    "type": "OBJECT",
    "properties": {
      "previous_step": {
        "type": "STRING",
        "description": "Key findings and outcomes since the previous step."
      },
      "plan": {
        "type": "STRING",
        "description": "The current status of the plan."
      },
      "next_step": {
        "type": "STRING",
        "description": "Brief explanation of the immediate next action according to the plan."
      },
      "external": {
        "type": "STRING",
        "description": "A short, plain-language note shown to the User about what you are ABOUT TO DO next."
      }
    },
    "required": [
      "previous_step",
      "plan",
      "next_step",
      "external"
    ]
  }
}

המודל יבצע שתי קריאות באותו השלב: הקריאה update() שמחליפה את ה-XML המובנה, וקריאת הפונקציה בפועל שהוא רוצה לבצע.

מקורות מידע נוספים

• דף המודל Gemini 3.5 Flash
• מחברת מבוא