‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

מעבר למודלים העדכניים ביותר של Gemini

במדריך הזה מוסבר איך לעדכן את האפליקציה לגרסה העדכנית של Gemini. המדריך הזה מבוסס על ההנחה שהאפליקציה שלכם כבר משתמשת בגרסה ישנה יותר של Gemini. איך מתחילים להשתמש ב-Gemini ב-Gemini Enterprise Agent Platform

המדריך הזה לא מסביר איך להעביר את האפליקציה מ-Vertex AI SDK לגרסה הנוכחית של Google Gen AI SDK. המידע הזה מופיע במדריך להעברת נתונים (מיגרציה) של Vertex AI SDK.

אילו שינויים צפויים?

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

עדכון לגבי דיווח על מספר הטוקנים

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

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

לאיזה מודל Gemini כדאי לעבור?

המודל של Gemini שבו משתמשים תלוי בצרכים של האפליקציה:

תכונה	3.1 Pro	‎3.5 Flash-Lite	‫3.5 Flash	‫3.6 פלאש	‫3.7 פלאש	‫3.8 Flash	‎4 Argon
שלב ההשקה	תצוגה מקדימה	GA	GA	GA	GA	GA	GA
אופני קלט	טקסט, תמונה, אודיו, וידאו	טקסט, תמונה, אודיו, וידאו	טקסט, תמונה, אודיו, וידאו	טקסט, תמונה, אודיו, וידאו	טקסט, תמונה, אודיו, וידאו	טקסט, תמונה, אודיו, וידאו	טקסט, תמונה, אודיו, וידאו
אופני פלט	טקסט	טקסט	טקסט	טקסט	טקסט	טקסט	טקסט
חלון ההקשר, מגבלת הטוקנים הכוללת	1,048,576	1,048,576	1,048,576	1,048,576	1,048,576	1,048,576	1,048,576
אורך חלון ההקשר של הפלט	65,536	65,536	65,536	65,536	65,536	65,536	1,048,576
עיגון באמצעות חיפוש Google
קריאה להפעלת פונקציות
הרצת קוד
שמירת הקשר במטמון באופן משתמע
שמירת הקשר במטמון באופן מפורש
היסק ב-Batch
Gemini Live API
כוונון עדין
זמן אחזור
תאריך הוצאה משימוש		‫21 ביולי 2027 או אחרי	‫19 במאי 2027 או אחרי התאריך הזה	‫19 בנובמבר 2026	‫28 בינואר 2027	‫2 בספטמבר 2027 או אחריו	‫13 באוקטובר 2027 או אחרי התאריך הזה

לפני שמתחילים בהעברה

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

אבטחת מידע (InfoSec), משילות ואישורים רגולטוריים
זמינות לפי מיקום
הבדלים בתמחור לפי אופן הפעולה ולפי טוקניזציה
רכישה או שינוי של הזמנות להקצאת משאבים לפי התפוקה שנקבעה
כוונון מפוקח (SFT)
בדיקות רגרסיה

אבטחת מידע, פיקוח ואישורים רגולטוריים

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

זמינות לפי מיקום

המודלים והתכונות מבוססות ה-AI הגנרטיבי של Google ושל השותפים ב-Gemini Enterprise Agent Platform זמינים דרך נקודות קצה אזוריות ספציפיות ונקודת קצה גלובלית. נקודות קצה גלובליות מכסות את כל העולם ומציעות זמינות ואמינות משופרות בהשוואה לאזורים בודדים.

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

הבדלים בתמחור לפי אופן השימוש ולפי טוקניזציה

המחירים משתנים בין מודלי Gemini השונים. בדף התמחור שלנו מפורטות העלויות של כל המודלים (טקסט, קוד, תמונות, דיבור וכו').

רכישה או שינוי של הזמנות להקצאת משאבים לפי התפוקה שנקבעה

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

כוונון מפוקח (SFT)

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

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

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

בדיקת רגרסיה

כשמשדרגים לגרסה העדכנית של Gemini, צריך שלושה סוגים עיקריים של בדיקות רגרסיה:

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

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

איך עוברים לגרסה העדכנית

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

1. דרישות להערכה ולבדיקה של מודלים של מסמכים

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

2. שדרוג הקוד והרצת בדיקות

כדי לשדרג את הקוד, צריך לבצע שלושה שינויים עיקריים:

שדרוג ל-Google Gen AI SDK
איך משנים את השיחות ב-Gemini
תיקון שינויים בקוד שגורמים לתקלות

בקטעים הבאים מפורטים השינויים האלה.

שדרוג ל-Google Gen AI SDK

אם האפליקציה שלכם ב-Gemini 1.x משתמשת ב-Vertex AI SDK, עברו ל-Google Gen AI SDK. פרטים נוספים זמינים במדריך להעברת נתונים (מיגרציה) של Vertex AI SDK, כולל דוגמאות קוד לביצוע קריאות דומות באמצעות Google Gen AI SDK. גרסאות של Vertex AI SDK שיושקו אחרי יוני 2026 לא יתמכו ב-Gemini, ותכונות חדשות של Gemini יהיו זמינות רק ב-Google Gen AI SDK.

אנחנו ממליצים מאוד לעדכן לגרסה 2.0.0 או לגרסה חדשה יותר של ה-SDK של google-genai כדי ליהנות מכל התכונות החדשות ב-Gemini 3.5 Flash ובמודלים חדשים יותר.

אם אתם משתמשים חדשים ב-Google Gen AI SDK, כדאי לעיין ב-notebook‏ Getting started with Google Generative AI using the Google Gen AI SDK.

איך משנים את השיחות עם Gemini

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

השינויים המדויקים בקוד משתנים בהתאם לאופן שבו פיתחתם את האפליקציה, ובמיוחד אם השתמשתם ב-Google Gen AI SDK או ב-Vertex AI SDK.

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

תיקון שינויים בקוד שגורמים לכשלים

אחזור דינמי: עברו להשתמש בעיגון באמצעות חיפוש Google. התכונה הזו דורשת את Google Gen AI SDK, ו-Vertex AI SDK לא תומך בה.
מסנני תוכן: שימו לב להגדרות ברירת המחדל של מסנני התוכן. אם הקוד שלכם מסתמך על ברירת מחדל שהשתנתה, צריך לשנות אותו.
פרמטר דגימת הטוקנים Top-K: במודלים שאחרי gemini-1.0-pro-vision אי אפשר לשנות את הפרמטר Top-K.
Thinking: במודלים של Gemini 3 Pro ואילך, משתמשים בפרמטר thinking_level במקום ב-thinking_budget. מידע נוסף מופיע במאמר שליטה בתהליך החשיבה של המודל.
חתימות מחשבה: במודלים של Gemini 3 Pro ואילך, אם צפויה חתימת מחשבה בתור מסוים אבל היא לא מסופקת, המודל מחזיר שגיאה במקום אזהרה. חתימות מחשבה
רזולוציית מדיה וטוקניזציה: במודלים של Gemini 3 Pro ואילך, נעשה שימוש באורך משתנה של רצף לטוקניזציה של מדיה במקום ב-Pan and Scan, ויש עלויות טוקנים ורזולוציות חדשות שמוגדרות כברירת מחדל לתמונות, לקובצי PDF ולסרטונים. מידע נוסף זמין במאמרים הבנת תמונות והבנת סרטונים.
מטא-נתונים של שימוש: במודלים של Gemini 3 Pro ואילך, מספר הטוקנים של קובצי PDF ב-usage_metadata מדווחים במודל IMAGE במקום ב-DOCUMENT.
חלוקת תמונות למקטעים: המודלים Gemini 3 Pro והמודלים הבאים לא תומכים בחלוקת תמונות למקטעים.
תשובות לפונקציות מולטי-מודאליות: במודלים של Gemini 3 Pro ואילך, אפשר לכלול נתוני תמונות וקובצי PDF בתשובות לפונקציות. תגובות לפונקציות מולטי-מודאליות
עיבוד קובצי PDF: ב-Gemini 3 Pro ובמודלים מתקדמים יותר, לא נעשה שימוש ב-OCR כברירת מחדל כשמעבדים קובצי PDF סרוקים.

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

אם אתם עוברים מאחזור דינמי, יכול להיות שתצטרכו לשנות את ההוראות למערכת כדי לקבוע מתי להשתמש בחיפוש Google (לדוגמה, "Only generate queries for the Google Search tool if the user asks about sports. Don't generate queries for any other topic."). אבל אל תשנו את ההנחיות לפני שתעריכו את התוצאות.
אם השתמשתם בפרמטר Top-K, אתם יכולים לשנות פרמטרים אחרים לדגימת טוקנים, כמו Top-P, כדי לקבל תוצאות דומות.

3. הרצת הערכות אופליין

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

אם אין לכם דרך אוטומטית להריץ הערכות אופליין, אתם יכולים להשתמש בשירות ההערכה של Gen AI.

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

4. בדיקת תוצאות ההערכה וכוונון ההנחיות וההיפר-פרמטרים

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

שיפור ההנחיות באופן הדרגתי כדי לשפר את הביצועים ("טיפוס הרים"). אם אתם לא מכירים את שיטת טיפוס ההרים, כדאי לעיין בהדרכה אונליין בנושא טיפוס הרים ב-Vertex Gemini. גם הכלי לאופטימיזציה של הנחיות ב-Gemini Enterprise Agent Platform (דוגמה ל-notebook) יכול לעזור.
אם האפליקציה שלכם מושפעת משינויים שעלולים לגרום לכשל באחזור דינמי וב-Top-K, נסו לשנות את ההנחיה ואת הפרמטרים לדגימת טוקנים.

5. הרצת בדיקות עומס

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

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

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

6. (אופציונלי) הרצת הערכות אונליין

כדאי לעבור להערכה אונליין רק אם ההערכה אופליין מראה שאיכות הפלט של Gemini גבוהה וגם אם האפליקציה דורשת הערכה אונליין.

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

אם בארגון שלכם מבצעים באופן קבוע בדיקות A/B, בצעו בדיקה כזו כדי להשוות בין הגרסה הנוכחית של האפליקציה לבין הגרסה האחרונה של Gemini.
אם בארגון שלכם משתמשים באופן קבוע בפריסות של גרסאות ראשוניות (canary), כדאי להשתמש בהן עם המודלים העדכניים ביותר ולמדוד את השינויים בהתנהגות המשתמשים.

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

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

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

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

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

7. פריסה בסביבת הייצור

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

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

עדכוני פרמטרים ושיטות מומלצות ב-Gemini 3.x

הכללים הבאים חלים על כל המודלים של Gemini 3.x, כולל ‎3.5 Flash. הם הושקו ב-Gemini 3.0 ומופיעים כאן כתזכורת.

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

אנחנו כבר לא ממליצים להשתמש ב-temperature, ‏top_p ו-top_k בכל המודלים של Gemini 3.x. המודל מנהל את הדגימה שלו כדי להשיג תוצאות אופטימליות. צריך להסיר את הפרמטרים האלה מכל הבקשות.

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

`thinking_budget` (הוצאה משימוש)

הפרמטר המספרי הגולמי thinking_budget כבר לא מומלץ בכל המודלים של Gemini 3.x, והוא מחזיר שגיאת אימות HTTP 400 במודלים של Gemini 4. במקום זאת, צריך להשתמש במאפיין המחרוזת thinking_level.

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

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

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

תשובות מולטי-מודאליות לפונקציות

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

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

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

צמצום קריאות API מיותרות לכלים

אם אתם נתקלים בשימוש יתר בקריאות API לכלים: 1. מפחיתים את רמת החשיבה (medium, low או minimal). 2. הוסיפו הוראת מערכת כדי להגביל את השימוש בכלים (למשל, "You have a limited action budget of <n> tool calls. Use them efficiently.").

רשימת משימות להעברה

אתם יכולים להשתמש ברשימות המשימות הבאות כהפניה מהירה כשאתם עוברים מגרסאות קודמות של המודל:

מ-Gemini 3.1 Pro Preview ל-Gemini 4 Argon

מעדכנים את שם המודל: gemini-3.1-pro-preview ל-gemini-4-argon (או gemini-4-argon-cyber-permissive לעומסי עבודה בתחום אבטחת הסייבר שאושרו על ידי Fairwind) ומשדרגים לגרסה העדכנית של Google Gen AI SDK (google-genai >= 2.34.0 ל-Python,‏ @google/genai >= 2.32.0 ל-JavaScript או ל-TypeScript).
חשוב להביא בחשבון את המגבלה המאוחדת של 1,048,576 טוקנים לקלט ולפלט (כשהפלט כולל חשיבה, קריאות להפעלת פונקציות והתשובה הסופית) ואת המגבלה של 65,536 טוקנים לפלט של בקשה אחת (32,768 טוקנים לקריאות בחזית ללא סטרימינג). לפלט של סבב יחיד עד 1,048,576 טוקנים, מגדירים פענוחים ארוכים ב-Interactions API או ב-GenerateContent (v1beta1) (מטופל באופן אוטומטי ב-Google Gen AI SDK כש-max_output_tokens מוגדר כגדול מ-65,536, עם background=true ב-Interactions API, או באמצעות continuation_token בלולאות בהתאמה אישית).
מחליפים את thinking_budget ו-thinking_level="MINIMAL" (שניהם מחזירים שגיאת HTTP 400) ב-thinking_level שמוגדר ל-LOW, MEDIUM (ברירת המחדל ב-gemini-4-argon) או HIGH (ברירת המחדל ב-gemini-4-argon-cyber-permissive).
הסירו קריאות מפורשות ל-cached_content. הציבו קידומות סטטיות של הנחיות (4,096 טוקנים או יותר) בתחילת ההנחיות כדי להפעיל שמירה אוטומטית במטמון באופן משתמע.
הסרה של temperature, top_p, top_k, frequency_penalty, presence_penalty, candidate_count ושל model תורות שמולאו מראש.
פרטים מלאים זמינים במאמר מעבר מ-Gemini 3.1 Pro ובמדריך למפתחים בנושא Gemini 4 Argon.

מגרסת טרום-השקה (Preview) של Gemini 3 Flash

עדכון שם המודל: gemini-3-flash-preview ← gemini-3.5-flash.
בודקים את המחיר. ‫3.5 Flash יקר יותר מ-Gemini 3 Flash Preview.
מסירים את temperature,‏ top_p,‏ top_k מההגדרות האישיות.
מחליפים את thinking_budget ב-thinking_level.
בודקים את ההנחיות. המאמץ שמוגדר כברירת מחדל השתנה מ-high ל-medium.
שימור תהליכי החשיבה מופעל עכשיו כברירת מחדל. ההקשר של תהליך החשיבה נשמר לאורך כל השיחה.
כדי לצמצם קריאות API מיותרות לכלים, אפשר לשנות את רמת החשיבה או להוסיף הוראות למערכת.
הפחתת חנופה: אם gemini-3.5-flash מתחיל להראות סימנים של חנופה, אתם יכולים לנסות להפחית את ההתנהגות הזו באמצעות הוראות המערכת שלו, על ידי הוספת הטקסט הבא: - Keep your responses concise. - Provide a summary of your work when you end your turn. Ground your response in the work you did. Keep your tone professional and avoid overconfident language, bragging, or overclaiming success. - AVOID using superlatives such as "perfectly", "flawlessly", "100% correct", "Summary of Accomplishments" etc. to summarize your work for the user. Be humble. - AVOID over-the-top politeness or complimenting the user excessively. - Format your responses in github-style markdown.

מ-Gemini 2.5

בודקים את עומסי העבודה של קובצי PDF ומסמכים. צריכת הטוקנים בקובצי PDF עשויה לעלות.
לפשט את ההנחיות. נסו להשתמש ב-thinking_level: "medium" או ב-"high" עם הנחיות פשוטות יותר במקום הנחיות מורכבות בטכניקת שרשרת חשיבה.
להשתמש בשילוב של כלים (חיפוש, URL Context, הרצת קוד, פונקציות).
העברת תוכן מולטימודלי בתוך חלקי התשובה של הפונקציה.
מוסיפים הוראות בתוך הטקסט של התשובה מהפונקציה.

שיפור הביצועים של המודל

במהלך המעבר, כדאי ליישם את הטיפים הבאים כדי להשיג ביצועים אופטימליים מהמודל של Gemini שבחרתם:

בכל המודלים של Gemini 3, הפרמטרים לדגימה (temperature,‏ top_p ו-top_k) הוצאו משימוש. המודל מנהל את הדגימה שלו כדי להשיג תוצאות אופטימליות. ‫Google ממליצה להסיר את הפרמטרים האלה מכל הבקשות.
בודקים את ההוראות למערכת, את ההנחיות ואת הדוגמאות ללמידה מכמה דוגמאות כדי לוודא שאין חוסר עקביות, סתירות או הוראות ודוגמאות לא רלוונטיות.
לנסות מודל חזק יותר. לדוגמה, אם הערכתם מודל Gemini Flash-Lite, נסו מודל Flash או Pro.
חשוב לבדוק את תוצאות ההערכה האוטומטית כדי לוודא שהן תואמות לשיפוט אנושי, במיוחד תוצאות שמתקבלות באמצעות מודל שופט. חשוב לוודא שההוראות למודל השופט ברורות, עקביות וחד-משמעיות.
כדי לשפר את ההוראות למודל השופט, כדאי לבדוק את ההוראות עם כמה אנשים שעובדים בנפרד. אם בני אדם מפרשים את ההוראות בצורה שונה ומספקים הערכות שונות, ההוראות למודל השופט לא ברורות.
כוונון עדין של המודל.
בודקים את פלטי ההערכה כדי לזהות דפוסים שמצביעים על סוגים ספציפיים של כשלים. קיבוץ הכשלים לפי מודל, סוג או קטגוריה מספק נתוני הערכה ממוקדים יותר, וכך קל יותר לשנות את ההנחיות כדי לתקן את השגיאות האלה.
חשוב להעריך את הרכיבים השונים של ה-AI הגנרטיבי בנפרד.
נסו לשנות את הפרמטרים לדגימת טוקנים.

קבלת עזרה

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

המאמרים הבאים

מדריך