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

André Cipriani Bandarra
Alexandra Klepper

תאריך פרסום: 12 במרץ 2025, תאריך עדכון אחרון: 28 במאי 2025

הסבר פיתוח אתרים תוספים סטטוס Chrome כוונת רכישה
MDN Chrome 138 Chrome 138 תצוגה כוונת משלוח

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

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

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

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

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

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

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

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

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

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

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

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

בדיקת הזמינות של הטוקן

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

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

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

יוצרים מופע של הסיכום באמצעות הפונקציה create(). כדי לשמור על כמה שיותר הקשר, הגדרנו את הפרמטר format לערך plain-text, את הפרמטר type לערך tldr ואת הפרמטר 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.