הטמעת מטמון לתשובות LLM: מטמון מדויק וסמנטי

מה נשבר בלי מטמון לתשובות LLM כשהעומס גדל

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

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

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

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

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

מה נותן מטמון LLM: מהירות תגובה ועומס על המודל

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

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

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

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

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

שני מצבי התאמה של בקשות: מדויק ולפי משמעות

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

נרמול הבקשה — רובד משותף לשני המצבים: רישיות, רווחים מיותרים, שדות עזר, סדר פרמטרים. בלעדיו התאמה מדויקת מאבדת פגיעות על לא כלום: «כמה עולה משלוח?» ו«כמה עולה משלוח» נשלחות למודל פעמיים.

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

מגבלה נפרדת של הרובד הסמנטי — איפוס: בעת עדכון המודל הווקטורים הישנים מפסיקים להתאים לתשובות, והרשומות מבוטלות תוקף באופן סלקטיבי, לא כולו.

סדר היישום: מפרופיל בקשות ועד מסירה לתמיכה

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

1. ביקורת זרם בקשות. מוציאים ייצוא פניות ל-2-4 שבועות: שיעור החזרות, פיזור הניסוחים של אותה שאלה, אורך ההקשר, סט פרמטרי היצירה, שיעור הבקשות עם נתונים אישיים. בפלט — מפת תרחישים עם פוטנציאל למטמון.
2. סכמת מפתחות בקשה. מגדירים מה נכנס למפתח ההתאמה המדויקת (טקסט מנורמל, הוראת מערכת, פרמטרי יצירה, מזהה גרסת מודל) ומה נחשב לקרבה עבור הרובד הסמנטי. בנפרד מסמנים תרחישים שאינם נשמרים במטמון כלל.
3. מדיניות אחסון. קובעים זמן חיים לרשומות לפי סוגי תרחישים, כללי ביטול תוקף בעת החלפת פרומפט או מודל, נפח אינדקס ומגבלות אחסון.
4. הגדרת רובד המטמון. מציבים אותו לפני המודל, מרימים אינדקס קרבה, מגדירים חימום מראש על בקשות היסטוריות ותיעוד פגיעות.
5. בדיקה בתעבורת צל. הזרם החי ממשיך כרגיל, והחלטות המטמון נמדדות במקביל, בלי להשפיע על התשובה. בודקים שיעור פגיעות, פערים בתשובות והתנהגות בניסוחים נדירים.
6. מדידות לאחר ההפעלה. משווים לקו הבסיס: שיעור הבקשות שהגיעו למודל, זמן תגובה, עומס על היצירה, שיעור התשובות עם סימני ירידה באיכות.
7. מסירה לתמיכה. נהל ביטול תוקף, דשבורד עם מדדים, ספי התראות וסדר כיבוי מהיר של הרובד — כדי שהתפעול לא יהיה תלוי ביוצרי הפתרון.

ארטיפקטים של יישום: קונפיגורציות, סכמות, מדיניות, נהלים

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

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

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

מקרה בוחן: איך תוך חודש הפחיתו השהיה ועומס על המודל

לפני: זרם בקשות בלי מטמון

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

אחרי: שני רבדי מטמון

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

בפרופיל דומה שיעור הפגיעות יצא 41%, מתוכן 27% — סמנטיות. זמן התגובה הממוצע ירד מ-3.4 ל-0.6 שניות, האחוזון העליון — מ-9 ל-1.4 שניות, מספר הפניות למודל קטן ב-43%. סוג הכשלים «מגבלת הספק בשיא» נעלם: העומס על המודל כבר לא גדל מחזרות.

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

מה לעשות בפגיעות שווא במערכת שכבר עובדת

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

הצעד הראשון — לא לסובב את הסף, אלא לתעד כל פגיעה: הבקשה המקורית, ה«שכן» שנמצא, ערך הקרבה והסימן אם התשובה התקבלה.

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

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

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

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

שאלות טכניות נפוצות: ביטול תוקף, פרטיות, מדידות

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

איך מופרדים נתונים של לקוחות ושוכרים שונים?

המפתח נבנה כ«שוכר → לקוח → גרסת מודל → בקשה»: שאלות זהות של לקוחות שונים נותנות רשומות שונות, והצטלבות נמנעת. את האחסון (למשל Redis) מחזיקים בסטים נפרדים עם מדיניות פינוי נפרדת.

מה קורה בעת החלפת גרסת מודל?

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

איך למדוד את האפקט בצורה הוגנת?

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

נדון במשימה: נשווה דרישות ונחזור עם תוכנית

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

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

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