למודלים רבים של 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 שמקבל סוגים של קבצים מולטי-מודאליים.
טקסט ארוך
הטקסט הוא שכבת האינטליגנציה שעומדת בבסיס של חלק גדול מהמומנטום סביב מודלים גדולים של שפה (LLM). כפי שציינו קודם, הרבה מהמגבלות המעשיות של מודלים גדולים של שפה נבעו מכך שלא היה להם חלון הקשר גדול מספיק כדי לבצע משימות מסוימות. הדבר הוביל לאימוץ מהיר של יצירה משולבת-אחזור (RAG) וטכניקות אחרות שמספקות למודל באופן דינמי מידע רלוונטי בהתאם להקשר. עכשיו, עם חלונות הקשר גדולים יותר ויותר, יש טכניקות חדשות שמאפשרות תרחישי שימוש חדשים.
הנה כמה תרחישי שימוש חדשים וסטנדרטיים בהקשר ארוך מבוסס-טקסט:
- סיכום של מאגרי טקסט גדולים
- אפשרויות קודמות לסיכום עם מודלים קטנים יותר של הקשר היו דורשות חלון הזזה או טכניקה אחרת כדי לשמור את המצב של קטעים קודמים כשמועברים טוקנים חדשים למודל
- שאלה ותשובה
- בעבר, היה אפשר לעשות את זה רק באמצעות RAG, כי כמות ההקשר הייתה מוגבלת והיכולת של המודלים לשחזר עובדות הייתה נמוכה
- תהליכי עבודה אג'נטיים
- הטקסט הוא הבסיס לאופן שבו סוכנים שומרים את המצב של מה שהם עשו ומה שהם צריכים לעשות. חוסר מידע מספיק על העולם ועל המטרה של הסוכן הוא מגבלה על המהימנות של הסוכנים.
למידה בהקשר עם הרבה דוגמאות היא אחת מהיכולות הייחודיות ביותר שמתאפשרות על ידי מודלים עם הקשר ארוך. מחקרים הראו שאם לוקחים את הפרדיגמה הנפוצה של דוגמה אחת או כמה דוגמאות, שבהן מוצגות למודל דוגמה אחת או כמה דוגמאות למשימה, ומרחיבים אותה למאות, אלפים או אפילו מאות אלפי דוגמאות, אפשר להגיע ליכולות חדשות של המודל. הוכח גם שהגישה הזו של הרבה דוגמאות פועלת באופן דומה למודלים שעברו כוונון עדין למשימה ספציפית. במקרים שבהם הביצועים של מודל Gemini עדיין לא מספיקים לפריסה בסביבת ייצור, אפשר לנסות את הגישה של many-shot. כפי שאפשר לחקור בהמשך, בקטע על אופטימיזציה של הקשר הארוך, שמירת הקשר במטמון הופכת את סוג עומס העבודה הזה של טוקנים עם קלט גבוה להרבה יותר משתלם, ואפילו מקצרת את זמן האחזור במקרים מסוימים.
סרטון ארוך
השימוש בתוכן וידאו מוגבל כבר הרבה זמן בגלל חוסר הנגישות של המדיום עצמו. היה קשה לסרוק את התוכן, התמלילים לרוב לא הצליחו לתעד את הניואנסים של הסרטון, ורוב הכלים לא מעבדים תמונה, טקסט ואודיו יחד. היכולות של Gemini לעיבוד טקסט עם הקשר ארוך מאפשרות לו להסיק מסקנות ולענות על שאלות לגבי קלט מולטי-מודאלי עם ביצועים יציבים.
הנה כמה תרחישי שימוש חדשים ונפוצים בהקשר ארוך של סרטונים:
- שאלות ותשובות בסרטון
- זיכרון של סרטון, כפי שמוצג ב-פרויקט Astra של Google
- כתוביות לסרטונים
- מערכות להמלצה על סרטונים, באמצעות העשרה של מטא-נתונים קיימים עם הבנה חדשה של מודלים מרובי-אופנים
- התאמה אישית של סרטונים על ידי ניתוח מאגר נתונים ומטא-נתונים של סרטונים קשורים, ואז הסרת חלקים בסרטונים שלא רלוונטיים לצופה
- ניהול תוכן בסרטונים
- עיבוד סרטונים בזמן אמת
כשעובדים עם סרטונים, חשוב להבין איך הסרטונים מעובדים לטוקנים, כי זה משפיע על החיוב ועל מגבלות השימוש. במדריך לכתיבת הנחיות יש מידע נוסף על כתיבת הנחיות עם קובצי וידאו.
תוכן אודיו ארוך
מודלי Gemini היו המודלים הגדולים הראשונים של שפה (LLM) עם מולטי-מודאליות טבעית שיכלו להבין אודיו. בעבר, תהליך העבודה הטיפוסי של מפתחים כלל שרשור של כמה מודלים ספציפיים לתחום, כמו מודל של המרת דיבור לטקסט (STT) ומודל של יצירת טקסט על סמך טקסט, כדי לעבד אודיו. הדבר הוביל לזמן טעינה נוסף שנדרש לביצוע בקשות מרובות של הלוך ושוב, ולירידה בביצועים שבדרך כלל משויכת לארכיטקטורות מנותקות של הגדרת מודלים מרובים.
הנה כמה תרחישי שימוש חדשים ונפוצים בהקשר של אודיו:
- תמלול ותרגום בזמן אמת
- שאלות ותשובות על פודקאסטים וסרטונים
- תמלול וסיכום של פגישות
- עוזרים קוליים
מידע נוסף על יצירת הנחיות באמצעות קובצי אודיו זמין במדריך ליצירת הנחיות.
אופטימיזציות של הקשר ארוך
האופטימיזציה העיקרית כשעובדים עם הקשר ארוך ומודלים של Gemini היא שימוש בשמירת הקשר במטמון. בנוסף לבעיה הקודמת של עיבוד מספר רב של טוקנים בבקשה אחת, המגבלה העיקרית השנייה הייתה העלות. אם יש לכם אפליקציה של 'צ'אט עם הנתונים שלך' שבה משתמש מעלה 10 קובצי PDF, סרטון וכמה מסמכים שקשורים לעבודה, בעבר הייתם צריכים לעבוד עם כלי או מסגרת מורכבים יותר של שליפה משופרת של מידע (RAG) כדי לעבד את הבקשות האלה, ולשלם סכום משמעותי על טוקנים שהועברו לחלון ההקשר. עכשיו אפשר לשמור במטמון את הקבצים שהמשתמש מעלה ולשלם על האחסון שלהם לפי שעה. לדוגמה, עלות הקלט / הפלט לכל בקשה ב-Gemini Flash נמוכה פי 4 בערך מהעלות הסטנדרטית של קלט / פלט. לכן, אם המשתמש ינהל מספיק שיחות עם הנתונים שלו, תוכלו לחסוך בעלויות.
מגבלות של הקשר ארוך
בקטעים שונים במדריך הזה דיברנו על האופן שבו מודלים של Gemini משיגים ביצועים גבוהים במגוון רחב של הערכות של שליפת מידע מסוג 'מחט בערימת שחת'. בבדיקות האלה אנחנו מתייחסים להגדרה הבסיסית ביותר, שבה מחפשים מחט אחת. במקרים שבהם אתם מחפשים כמה 'מחטים' או פיסות מידע ספציפיות, המודל לא פועל באותה רמת דיוק. הביצועים יכולים להשתנות במידה רבה בהתאם להקשר. חשוב לקחת את זה בחשבון כי יש פה איזון בין קבלת המידע הנכון לבין העלות. אפשר לקבל ~99% בשאילתה אחת, אבל צריך לשלם את עלות טוקן הקלט בכל פעם ששולחים את השאילתה הזו. לכן, כדי לאחזר 100 פריטי מידע, אם נדרשים ביצועים של 99%, סביר להניח שתצטרכו לשלוח 100 בקשות. זו דוגמה טובה למצב שבו שמירת מטמון של ההקשר יכולה להפחית באופן משמעותי את העלות שקשורה לשימוש במודלים של Gemini, תוך שמירה על רמת ביצועים גבוהה.
שאלות נפוצות
איפה הכי טוב למקם את השאילתה שלי בחלון ההקשר?
ברוב המקרים, במיוחד אם ההקשר הכולל ארוך, הביצועים של המודל יהיו טובים יותר אם תמקמו את השאילתה או השאלה בסוף ההנחיה (אחרי כל ההקשר האחר).
האם הביצועים של המודל ירדו אם אוסיף עוד טוקנים לשאילתה?
באופן כללי, אם לא צריך להעביר טוקנים למודל, עדיף להימנע מהעברתם. עם זאת, אם יש לכם נתח גדול של טוקנים עם מידע מסוים ואתם רוצים לשאול שאלות לגבי המידע הזה, המודל מסוגל לחלץ את המידע הזה (עד 99% דיוק במקרים רבים).
איך אפשר להפחית את העלויות של שאילתות עם הקשר ארוך?
אם יש לכם קבוצה דומה של טוקנים או הקשר שאתם רוצים להשתמש בהם שוב ושוב, שמירת ההקשר במטמון יכולה לעזור לכם להקטין את העלויות שקשורות לשאילת שאלות לגבי המידע הזה.
האם חלון ההקשר משפיע על זמן האחזור של המודל?
יש כמות קבועה של זמן טעינה בכל בקשה, ללא קשר לגודל שלה, אבל בדרך כלל לשאילתות ארוכות יותר יהיה זמן טעינה גבוה יותר (הזמן עד לטוקן הראשון).