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

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

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

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

מה קרה

איך מודלי שפה מייצרים טקסט

מודל שפה לא “כותב משפט”. הוא בוחר טוקן אחד בכל פעם.

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

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

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

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

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

שלושה תנאים שמגבירים לולאות

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

nucleus sampling, או top-p, בפשטות

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

ה־nucleus הוא הגרעין בעל ההסתברות הגבוהה בתוך ההתפלגות.

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

איפה משתמשים בזה:

• ברירת מחדל נפוצה ב־Anthropic, OpenAI ו־Google Vertex
• בדרך כלל לא מגדירים את זה ידנית, כי זה כבר פעיל
• משנים את זה רק כשבאמת רוצים אופי פלט אחר: נמוך יותר = ממוקד יותר וגם רגיש יותר ללולאות; גבוה יותר = מגוון יותר

הלקח מהבאג הזה: גם top-p כברירת מחדל לא בהכרח יציל מודל חלש כשהתפלגות הקלט כבר חדה מאוד.

top-p מקטין את הסיכון. הוא לא מעלים אותו כשהמגברים פועלים במלוא הכוח.

מה גרם לתקרית הספציפית הזאת

כל שלושת המגברים הופיעו יחד.

מודל חלש.
gemini-3.1-flash-lite-preview — שכבת העלות הזולה ביותר, שנבחרה בכוונה מטעמי עלות. התפלגות חדה ופחות מכוילת מאשר מודלים חזקים יותר.

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

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

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

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

מה הנתונים הראו

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

SELECT
  percentile_cont(0.50) WITHIN GROUP (ORDER BY output_tokens) AS p50,
  percentile_cont(0.90) WITHIN GROUP (ORDER BY output_tokens) AS p90,
  percentile_cont(0.99) WITHIN GROUP (ORDER BY output_tokens) AS p99
FROM encyclopedia_queries
WHERE created_at > now() - interval '30 days'
  AND output_tokens IS NOT NULL;

התוצאה:

אחוזון	טוקנים	משמעות
p50	592	חצי מהשאילתות החזירו פחות מזה. התשובה ה”טיפוסית”.
p90	1,074	90% מהשאילתות היו מתחת לזה. הגבול של “ארוך אבל נורמלי”.
p99	35,737	99% מהשאילתות היו מתחת לזה. רק האחוז העליון מגיע לשם.

מה הקשר של הקאש לזה

אין קשר ישיר. הקאש חף מפשע.

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

אותה לולאה הייתה יכולה לקרות גם בלי caching. פשוט היה עולה יותר להגיע לשם.

שלוש שכבות הגנה

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

שכבה 1: תקרת טוקנים בצד הספק

שכבה 2: גלאי rolling buffer בצד השרת

שכבה 3: גלאי “זה נראה שבור” בפרונטאנד

האם שכבה 2 מספיקה לבד?

ברוב המקרים כן, אבל עדיין רוצים את שכבה 1.

שכבה 1 היא שורת קוד אחת, והיא תופסת שני מקרים ששכבה 2 יכולה לפספס:

• לולאות נסחפות — כל חזרה קצת שונה: X1 Y1 X2 Y2 X3. גלאי n-gram מדויק עלול לפספס.
• גלאי עם באג — הגלאי עצמו מפספס לולאה אמיתית, או מזהה בטעות תוכן אמיתי כלולאה.

תקרת הטוקנים אדישה לתוכן. היא לא יכולה להכשיל תשובה אמיתית, כי תשובות אמיתיות לא מגיעות לתקרה: p90 הוא בערך אלף, והתקרה היא 3,000.

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

התיקון האמיתי

כל שלוש השכבות הן בקרת נזקים. תיקון האיכות הוא לשדרג את מודל שכבת התשובה.

מודלים טובים יותר לא מעלימים לולאות. הם מעבירים אותן מ”כל כמה שבועות” ל”נדיר מאוד”.

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

השורה התחתונה: repetition loop הוא לא רק “המודל התחרפן”. זה כשל מערכתי שנוצר מהמפגש בין דקודינג, מודל חלש, הקשר ארוך וחזרתי, וחוסר בתקרות קשיחות. הפתרון הוא לא לקוות שזה לא יקרה שוב, אלא לבנות את המערכת כאילו זה יקרה שוב.