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

André Cipriani Bandarra
Alexandra Klepper

תאריך פרסום: 12 במרץ 2025

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

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

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

מהו סיכום של סיכומים?

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

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

חלוקה מושכלת של התוכן

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

יש הרבה דרכים לעשות את זה, בלי מאמץ ידני. בדוגמה הבאה, השתמשנו ב-Recursive Text Splitter מ-LangChain.js, שמאזן בין הביצועים לבין איכות הפלט. הפתרון הזה אמור לפעול ברוב עומסי העבודה.

כשיוצרים מכונה חדשה, יש שני פרמטרים חשובים:

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

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

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

בדוגמה שלנו, השדה chunkSize מכיל 3,000 תווים, שהם כ-750 אסימונים.

יצירת סיכומים לכל חלוקה

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

יוצרים מכונה של הסיכום באמצעות הפונקציה create(). כדי לשמור על כמה שיותר הקשר, הגדרנו את הפרמטר format כ-plain-text, את הפרמטר type כ-tl;dr ואת הפרמטר length כ-long.

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

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

סיכום חזרה של סיכומים

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

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

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

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

בדקנו את הפתרון הזה עם Internet Relay Chat (IRC) RFC, שמכיל 110,030 תווים, כולל 17,560 מילים. Summarizer API סיפק את הסיכום הבא:

Internet Relay Chat‏ (IRC) הוא שירות שמאפשר לתקשר באינטרנט בזמן אמת באמצעות הודעות טקסט. אתם יכולים להתכתב בצ'אטים בערוצים או לשלוח הודעות פרטיות, וגם להשתמש בפקודות כדי לשלוט בצ'אט ולנהל אינטראקציה עם השרת. זה כמו חדרי צ'אט באינטרנט, שבהם אפשר להקליד ולראות הודעות של אנשים אחרים באופן מיידי.

זה די יעיל! בנוסף, הוא מכיל רק 309 תווים.

מגבלות

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

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

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

שיתוף משוב

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

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