למודלים רבים של Gemini יש חלונות הקשר גדולים של מיליון טוקנים או יותר. בעבר, מודלים גדולים של שפה (LLM) היו מוגבלים באופן משמעותי בכמות הטקסט (או הטוקנים) שאפשר להעביר למודל בכל פעם. חלון ההקשר הארוך של Gemini פותח הרבה תרחישי שימוש חדשים ופרדיגמות חדשות למפתחים.
הקוד שבו אתם כבר משתמשים במקרים כמו יצירת טקסט או קלט רב-אופני יפעל ללא שינויים עם הקשר ארוך.
במסמך הזה מפורטת סקירה כללית על מה שאפשר להשיג באמצעות מודלים עם חלונות הקשר של מיליון טוקנים ומעלה. בדף הזה יש סקירה קצרה של חלון הקשר, והסבר על האופן שבו מפתחים צריכים לחשוב על הקשר ארוך, על תרחישים שונים לדוגמה מהעולם האמיתי שבהם יש הקשר ארוך ועל דרכים לאופטימיזציה של השימוש בהקשר ארוך.
בדף המודלים מפורטים גדלי חלונות ההקשר של מודלים ספציפיים.
מה זה חלון הקשר?
הדרך הבסיסית שבה משתמשים במודלים של Gemini היא העברת מידע (הקשר) למודל, ולאחר מכן המודל יוצר תשובה. אפשר להשוות את חלון ההקשר לזיכרון לטווח קצר. יש כמות מוגבלת של מידע שאפשר לאחסן בזיכרון לטווח קצר של מישהו, וזה נכון גם לגבי מודלים גנרטיביים.
מידע נוסף על אופן הפעולה של המודלים זמין במדריך למודלים גנרטיביים.
תחילת העבודה עם הקשר רחב
בגרסאות קודמות של מודלים גנרטיביים הייתה אפשרות לעבד רק 8,000 טוקנים בכל פעם. בדגמים חדשים יותר, המגבלה הזו גדולה יותר, והם יכולים לקבל 32,000 או אפילו 128,000 טוקנים. Gemini הוא המודל הראשון שיכול לקבל מיליון טוקנים.
בפועל, מיליון טוקנים ייראו כך:
- 50,000 שורות קוד (עם 80 תווים סטנדרטיים בכל שורה)
- כל הודעות הטקסט ששלחתם ב-5 השנים האחרונות
- 8 רומנים באנגלית באורך ממוצע
- תמלילים של יותר מ-200 פרקים של פודקאסטים באורך ממוצע
חלונות ההקשר המוגבלים יותר שקיימים בדרך כלל בהרבה מודלים אחרים מחייבים שימוש באסטרטגיות כמו השמטה שרירותית של הודעות ישנות, סיכום תוכן, שימוש ב-RAG עם מסדי נתונים וקטוריים או סינון הנחיות כדי לחסוך בטוקנים.
הטכניקות האלה עדיין שימושיות בתרחישים ספציפיים, אבל חלון ההקשר הרחב של Gemini מאפשר גישה ישירה יותר: לספק את כל המידע הרלוונטי מראש. המודלים של Gemini נוצרו במיוחד עם יכולות הקשר נרחבות, ולכן הם מפגינים יכולות למידה חזקות בהקשר. לדוגמה, Gemini למד לתרגם מאנגלית לקלמנג – שפה פפואנית עם פחות מ-200 דוברים – באמצעות חומרי הדרכה רק בהקשר (ספר דקדוק בן 500 עמודים, מילון וכ-400 משפטים מקבילים), באיכות דומה לזו של לומד אנושי שמשתמש באותם חומרים. האיור הזה ממחיש את השינוי הפרדיגמטי שמתאפשר בזכות ההקשר הארוך של Gemini, ומאפשר אפשרויות חדשות באמצעות למידה חזקה בהקשר.
תרחישים לדוגמה לשימוש בהקשר ארוך
למרות שהשימוש הסטנדרטי ברוב המודלים הגנרטיביים הוא עדיין קלט טקסט, משפחת מודלי Gemini מאפשרת פרדיגמה חדשה של תרחישי שימוש מולטימודאליים. המודלים האלה יכולים להבין טקסט, סרטונים, אודיו ותמונות באופן טבעי. לנוחותכם, הם מגיעים עם Gemini API שמקבל סוגים של קבצים מרובי-מוֹדָלִים.
טקסט ארוך
הטקסט הוא שכבת האינטליגנציה שעומדת בבסיס של הרבה מהמומנטום סביב מודלים גדולים של שפה. כפי שציינו קודם, הרבה מהמגבלות המעשיות של מודלים גדולים של שפה נבעו מכך שלא היה חלון הקשר גדול מספיק כדי לבצע משימות מסוימות. הדבר הוביל לאימוץ מהיר של שיטות כמו RAG (יצירה משופרת באמצעות אחזור) ושיטות אחרות שמספקות למודל באופן דינמי מידע רלוונטי בהקשר. עכשיו, עם חלונות הקשר גדולים יותר ויותר, יש טכניקות חדשות שמאפשרות תרחישי שימוש חדשים.
הנה כמה תרחישי שימוש חדשים וסטנדרטיים בהקשר ארוך מבוסס-טקסט:
- סיכום של מאגרי טקסט גדולים
- אפשרויות קודמות לסיכום עם מודלים קטנים יותר של הקשר היו דורשות חלון נע או טכניקה אחרת כדי לשמור את המצב של קטעים קודמים כשמועברים טוקנים חדשים למודל
- שאלה ותשובה
- בעבר, האפשרות הזו הייתה זמינה רק באמצעות RAG, כי כמות ההקשר הייתה מוגבלת והיכולת של המודלים לשחזר עובדות הייתה נמוכה
- תהליכי עבודה אג'נטיים
- טקסט הוא הבסיס לאופן שבו סוכנים שומרים על מצב הפעולה שלהם, כלומר מה הם עשו ומה הם צריכים לעשות. חוסר מידע מספיק על העולם ועל המטרה של הסוכן הוא מגבלה על המהימנות של הסוכנים.
למידה בהקשר עם הרבה דוגמאות היא אחת מהיכולות הייחודיות ביותר שמתאפשרות על ידי מודלים עם הקשר ארוך. מחקרים הראו שאם לוקחים את פרדיגמת הדוגמאות הנפוצה של 'דוגמה אחת' או 'כמה דוגמאות', שבה המודל מקבל דוגמה אחת או כמה דוגמאות למשימה, ומרחיבים אותה למאות, אלפים או אפילו מאות אלפי דוגמאות, אפשר להגיע ליכולות חדשות של המודל. הוכח גם שהגישה הזו של למידה עם הרבה דוגמאות פועלת באופן דומה למודלים שעברו כוונון עדין למשימה ספציפית. במקרים שבהם הביצועים של מודל Gemini עדיין לא מספיקים לפריסה בסביבת ייצור, אפשר לנסות את גישת ה-many-shot. כפי שאפשר לראות בהמשך בקטע על אופטימיזציה של הקשר הארוך, שמירת הקשר במטמון הופכת את סוג העומס הזה של טוקנים עם קלט גבוה להרבה יותר כלכלי, ובמקרים מסוימים אפילו מקצרת את זמן האחזור.
סרטון ארוך
השימוש בתוכן וידאו מוגבל כבר הרבה זמן בגלל חוסר הנגישות של המדיום עצמו. היה קשה לסרוק את התוכן, התמלילים לא הצליחו לתעד את הניואנסים של הסרטון, ורוב הכלים לא מעבדים תמונות, טקסט ואודיו ביחד. היכולות של Gemini לעיבוד טקסט עם הקשר ארוך מאפשרות לו להסיק מסקנות ולענות על שאלות לגבי קלט מולטי-מודאלי עם ביצועים טובים לאורך זמן.
הנה כמה תרחישי שימוש חדשים ונפוצים בהקשר ארוך של סרטונים:
- שאלות ותשובות בסרטון
- זיכרון וידאו, כפי שמוצג ב-Project Astra של Google
- כתוביות לסרטונים
- מערכות המלצות לסרטונים, על ידי העשרת מטא-נתונים קיימים בהבנה חדשה של מודלים מרובי-מוֹדָלִים
- התאמה אישית של סרטונים על ידי ניתוח מאגר נתונים ומטא-נתונים של סרטונים קשורים, והסרת חלקים בסרטונים שלא רלוונטיים לצופה
- ניהול תוכן בסרטונים
- עיבוד סרטונים בזמן אמת
כשעובדים עם סרטונים, חשוב להבין איך הסרטונים מעובדים לטוקנים, כי זה משפיע על החיוב ועל מגבלות השימוש. במדריך לכתיבת הנחיות יש מידע נוסף על כתיבת הנחיות עם קובצי וידאו.
תוכן אודיו ארוך
מודלי Gemini היו המודלים הגדולים הראשונים של שפה (LLM) עם מולטי-מודאליות טבעית שיכלו להבין אודיו. בעבר, תהליך העבודה הטיפוסי של מפתחים כלל שרשור של כמה מודלים ספציפיים לדומיין, כמו מודל של דיבור לטקסט ומודל של טקסט לטקסט, כדי לעבד אודיו. הדבר הוביל לזמן אחזור נוסף שנדרש לביצוע של כמה בקשות הלוך ושוב, ולירידה בביצועים שבדרך כלל משויכת לארכיטקטורות מנותקות של הגדרת כמה מודלים.
הנה כמה תרחישי שימוש חדשים ונפוצים בהקשר של אודיו:
- תמלול ותרגום בזמן אמת
- שאלות ותשובות על פודקאסטים וסרטונים
- תמלול וסיכום של פגישות
- עוזרים קוליים
במדריך ליצירת הנחיות יש מידע נוסף על יצירת הנחיות באמצעות קובצי אודיו.
אופטימיזציות של הקשר ארוך
האופטימיזציה העיקרית כשעובדים עם הקשר ארוך ועם מודלים של Gemini היא שימוש בשמירת הקשר במטמון. בנוסף לבעיה הקודמת של עיבוד מספר רב של טוקנים בבקשה אחת, המגבלה העיקרית השנייה הייתה העלות. אם יש לכם אפליקציה שמאפשרת למשתמשים לשוחח עם הנתונים שלהם, והמשתמש מעלה 10 קובצי PDF, סרטון וכמה מסמכים שקשורים לעבודה, בעבר הייתם צריכים לעבוד עם כלי או מסגרת מורכבים יותר של שליפה מוגברת של מידע (RAG) כדי לעבד את הבקשות האלה, ולשלם סכום משמעותי על טוקנים שהועברו לחלון ההקשר. עכשיו אפשר לשמור במטמון את הקבצים שהמשתמש מעלה ולשלם על האחסון שלהם לפי שעה. לדוגמה, עלות הקלט / פלט לכל בקשה ב-Gemini Flash נמוכה פי 4 בערך מהעלות הרגילה של קלט / פלט. לכן, אם המשתמשים ינהלו מספיק שיחות עם הנתונים שלהם, תוכלו לחסוך בעלויות.
מגבלות של הקשר ארוך
בקטעים שונים במדריך הזה דיברנו על האופן שבו מודלים של Gemini משיגים ביצועים גבוהים במגוון רחב של הערכות של שליפת נתונים מתוך כמות גדולה של נתונים. בבדיקות האלה אנחנו מתייחסים להגדרה הבסיסית ביותר, שבה מחפשים מחט אחת. במקרים שבהם אתם מחפשים כמה 'מחטים' או פיסות מידע ספציפיות, המודל לא פועל באותה רמת דיוק. הביצועים יכולים להשתנות במידה רבה בהתאם להקשר. חשוב לקחת את זה בחשבון כי יש פה איזון בין קבלת המידע הנכון לבין העלות. אפשר לקבל ~99% בשאילתה אחת, אבל צריך לשלם את עלות טוקן הקלט בכל פעם ששולחים את השאילתה הזו. לכן, כדי לאחזר 100 פריטי מידע, אם אתם צריכים ביצועים של 99%, סביר להניח שתצטרכו לשלוח 100 בקשות. זו דוגמה טובה למצב שבו שמירת מטמון של ההקשר יכולה להפחית באופן משמעותי את העלות שקשורה לשימוש במודלים של Gemini, תוך שמירה על רמת ביצועים גבוהה.
שאלות נפוצות
איפה הכי טוב להציב את השאילתה שלי בחלון ההקשר?
ברוב המקרים, במיוחד אם ההקשר הכולל ארוך, הביצועים של המודל יהיו טובים יותר אם תמקמו את השאילתה או השאלה בסוף ההנחיה (אחרי כל ההקשר האחר).
האם הביצועים של המודל ירדו אם אוסיף עוד טוקנים לשאילתה?
באופן כללי, אם לא צריך להעביר טוקנים למודל, עדיף להימנע מהעברתם. עם זאת, אם יש לכם נתח גדול של טוקנים עם מידע מסוים ואתם רוצים לשאול שאלות לגבי המידע הזה, המודל מסוגל מאוד לחלץ את המידע הזה (עד 99% דיוק במקרים רבים).
איך אפשר להפחית את העלות של שאילתות עם הקשר ארוך?
אם יש לכם קבוצה דומה של טוקנים או הקשר שאתם רוצים להשתמש בהם שוב ושוב, שמירת ההקשר במטמון יכולה לעזור לכם להקטין את העלויות שקשורות לשאילת שאלות לגבי המידע הזה.
האם אורך ההקשר משפיע על זמן האחזור של המודל?
יש כמות קבועה של זמן אחזור בכל בקשה, ללא קשר לגודל שלה, אבל בדרך כלל לשאילתות ארוכות יותר יהיה זמן אחזור גבוה יותר (הזמן עד לטוקן הראשון).