תאריך פרסום: 12 במרץ 2025, עדכון אחרון: 28 במאי 2025
| סרטון הסבר | פיתוח אתרים | תוספים | הסטטוס של Chrome | הרציונל |
|---|---|---|---|---|
| MDN |  Chrome 138 |
Chrome 138 |
תצוגה | כוונה לשלוח |
Summarizer API עוזר לכם ליצור סיכומים של מידע באורכים ובפורמטים שונים. אפשר להשתמש בו עם מודל הבסיס ב-Chrome, או עם מודלים אחרים של שפה שמוטמעים בדפדפנים, כדי לקבל הסבר תמציתי לטקסט ארוך או מורכב.
כשמבצעים הצפנה מצד הלקוח, אפשר לעבוד עם נתונים באופן מקומי, וכך לשמור על בטיחות המידע הרגיש וליהנות מזמינות בכל קנה מידה. עם זאת, חלון ההקשר קטן בהרבה בהשוואה למודלים בצד השרת, ולכן יכול להיות שיהיה קשה לסכם מסמכים גדולים מאוד. כדי לפתור את הבעיה, אפשר להשתמש בטכניקה של סיכום הסיכומים.
מהו סיכום של סיכומים?
כדי להשתמש בטכניקה של סיכום הסיכומים, צריך לפצל את תוכן הקלט בנקודות מרכזיות, ואז לסכם כל חלק בנפרד. אפשר לשרשר את הפלט מכל חלק, ואז לסכם את הטקסט המשורשר הזה לסיכום סופי אחד.
פיצול התוכן בצורה מושכלת
חשוב לחשוב איך לפצל קטע טקסט גדול, כי אסטרטגיות שונות יכולות להניב פלט שונה במודלים שונים של שפה גדולה (LLM). מומלץ לפצל את הטקסט כשעוברים לנושא אחר, למשל כשמתחילים קטע חדש במאמר או כשמתחילים פסקה חדשה. חשוב להימנע מפיצול הטקסט באמצע מילה או משפט, ולכן אי אפשר להשתמש בספירת תווים כהנחיה היחידה לפיצול.
יש הרבה דרכים לעשות את זה. בדוגמה הבאה השתמשנו ב-Recursive Text Splitter מ-LangChain.js, שמאזן בין הביצועים לבין איכות הפלט. השיטה הזו מתאימה לרוב עומסי העבודה.
כשיוצרים מכונה חדשה, יש שני פרמטרים חשובים:
chunkSizeהוא מספר התווים המקסימלי שאפשר להזין בכל פיצול.-
chunkOverlapהוא מספר התווים שחופפים בין שני פיצולים עוקבים. כך אפשר לוודא שלכל מקטע יהיה חלק מההקשר של המקטע הקודם.
מפצלים את הטקסט באמצעות splitText() כדי להחזיר מערך של מחרוזות עם כל נתח.
ברוב מודלי השפה הגדולים, חלון ההקשר מבוטא כמספר טוקנים ולא כמספר תווים. בממוצע, טוקן מכיל 4 תווים. בדוגמה שלנו, chunkSize הוא 3,000 תווים, וזה בערך 750 טוקנים.
איך בודקים את הזמינות של טוקנים
כדי לקבוע כמה טוקנים זמינים לשימוש בקלט, משתמשים בשיטה measureInputUsage() ובמאפיין inputQuota. במקרה כזה, ההטמעה היא ללא הגבלה, כי אי אפשר לדעת כמה פעמים הכלי לסיכום יפעל כדי לעבד את כל הטקסט.
יצירת סיכומים לכל פיצול
אחרי שמגדירים איך התוכן יפוצל, אפשר ליצור סיכומים לכל חלק באמצעות Summarizer API.
יוצרים מופע של הכלי לסיכום באמצעות הפונקציה create(). כדי לשמור על כמה שיותר הקשר, הגדרנו את הפרמטר format לערך plain-text, את הפרמטר type לערך tldr ואת הפרמטר length לערך long.
לאחר מכן, יוצרים את הסיכום לכל פיצול שנוצר על ידי RecursiveCharacterTextSplitter ומשרשרים את התוצאות למחרוזת חדשה.
הפרדנו כל סיכום בשורה חדשה כדי שיהיה קל לזהות את הסיכום של כל חלק.
השורה החדשה הזו לא משנה כשמריצים את הלולאה הזו רק פעם אחת, אבל היא שימושית כדי לקבוע איך כל סיכום מוסיף לערך הטוקן של הסיכום הסופי. ברוב המקרים, הפתרון הזה מתאים לתוכן באורך בינוני וארוך.
סיכום רקורסיבי של סיכומים
אם יש לכם כמות גדולה מאוד של טקסט, יכול להיות שאורך הסיכום המחובר יהיה גדול יותר מחלון ההקשר הזמין, ולכן הסיכום ייכשל. כדי לטפל בבעיה, אפשר לסכם את הסיכומים באופן רקורסיבי.
אנחנו עדיין אוספים את הפיצולים הראשוניים שנוצרו על ידי RecursiveCharacterTextSplitter. לאחר מכן, בפונקציה recursiveSummarizer(), אנחנו מבצעים לולאה של תהליך הסיכום על סמך אורך התווים של החלקים המחוברים. אם אורך התווים של הסיכומים חורג מ-3000,
אז אנחנו משרשרים אותם ל-fullSummaries. אם לא מגיעים למגבלה, הסיכום נשמר כ-partialSummaries.
אחרי שכל הסיכומים נוצרים, הסיכומים החלקיים הסופיים מתווספים לסיכום המלא. אם יש רק סיכום אחד ב-fullSummaries, לא צריך לבצע רקורסיה נוספת. הפונקציה מחזירה סיכום סופי. אם יש יותר מסיכום אחד, הפונקציה חוזרת על עצמה וממשיכה לסכם את הסיכומים החלקיים.
בדקנו את הפתרון הזה עם RFC של Internet Relay Chat (IRC), שכולל 110,030 תווים, כולל 17,560 מילים. הסיכום הבא נוצר באמצעות Summarizer API:
צ'אט ממסר באינטרנט (IRC) הוא דרך לתקשר באינטרנט בזמן אמת באמצעות הודעות טקסט. אתם יכולים לשוחח בצ'אטים בערוצים או לשלוח הודעות פרטיות, וגם להשתמש בפקודות כדי לשלוט בצ'אט ולקיים אינטראקציה עם השרת. זה כמו חדר צ'אט באינטרנט שבו אפשר להקליד ולראות את ההודעות של אחרים באופן מיידי.
זה די יעיל! בנוסף, הוא כולל רק 309 תווים.
מגבלות
טכניקת סיכום הסיכומים עוזרת לכם לפעול במסגרת חלון ההקשר של מודל בגודל לקוח. למרות שיש הרבה יתרונות ל-AI בצד הלקוח, יכול להיות שתיתקלו בבעיות הבאות:
- סיכומים פחות מדויקים: בשימוש ברקורסיה, תהליך הסיכום חוזר על עצמו באופן פוטנציאלי אינסופי, וכל סיכום רחוק יותר מהטקסט המקורי. המשמעות היא שהמודל עשוי ליצור סיכום סופי שלא מספיק מפורט כדי להיות שימושי.
- ביצועים איטיים יותר: לוקח זמן ליצור כל סיכום. שוב, מכיוון שיכול להיות מספר אינסופי של סיכומים בטקסטים ארוכים יותר, יכול להיות שיחלפו כמה דקות עד שהגישה הזו תסתיים.
יש לנו הדגמה של הכלי לסיכום מידע, ואפשר לראות את קוד המקור המלא.
שיתוף משוב
כדאי לנסות להשתמש בטכניקה של סיכום סיכומים עם טקסט קלט באורכים שונים, גדלים שונים של פיצולים ואורכים שונים של חפיפות, באמצעות Summarizer API.
- כדי לשלוח משוב על ההטמעה של Chrome, אפשר לדווח על באג או להגיש בקשה להוספת תכונה.
- קוראים את התיעוד ב-MDN
- אפשר לשוחח עם צוות Chrome AI לגבי תהליך הסיכום או כל שאלה אחרת לגבי AI מובנה.