Self-Correction ב-LLMs — מתי מודל מסוגל לתקן את עצמו ומתי לא

מאת צוות מדיה דיל · 09.08.2026 · AI · 11 דק׳

'תבדוק שוב ותתקן טעויות' הוא אחד הפרומפטים הכי נפוצים והכי מוטעים בשימוש היום. מדריך טכני על מתי self-correction במודלי שפה עובד באמת ומתי הוא רק אשליה מרגיעה.

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

המיתוס של "תבדוק את עצמך שוב"

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

מתי Self-Correction עובד בפועל

self-correction אפקטיבי במיוחד כשהטעות היא שטחית או פרוצדורלית, לא מהותית-תוכנית:

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

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

מתי מודל לא יכול לתקן את עצמו — מגבלות ידע פנימיות

כאשר הטעות נובעת מ-hallucination (המודל "בטוח" בעובדה שגויה) או מפער ידע אמיתי (המודל פשוט לא יודע את התשובה הנכונה), self-correction לא עוזר — כי אין למודל שום דרך פנימית להבחין בין מה שהוא "יודע" נכון לבין מה שהוא ממציא בביטחון זהה. מחקר בתחום מראה שוב ושוב שביקורת עצמית ללא מידע חיצוני חדש נוטה לשפר פורמט ועקביות, אך משפרת הרבה פחות דיוק עובדתי — ולעיתים אפילו פוגעת בו, כשהמודל "משכנע את עצמו" להחליף תשובה נכונה בתשובה שגויה שנשמעת יותר בטוחה.

הכלל המעשי: אם תיקון התשובה דורש מידע שלא היה זמין למודל בפעם הראשונה — self-correction לא יעזור, לא משנה כמה פעמים מבקשים ממנו לנסות שוב. הפתרון היחיד הוא לספק את המידע החסר בפועל (retrieval, קריאה לכלי, תוצאת בדיקה בפועל) — לא לבקש עוד סיבוב חשיבה על אותו קלט.

הבדל בין Self-Correction ל-Verification חיצוני

ההבדל הקריטי: self-correction משתמש רק במה שכבר "בתוך" המודל. verification חיצוני (ראו Verifier Models) מכניס מקור אמת בלתי-תלוי — הרצת קוד בפועל, שאילתת DB, מודל שני שלא ראה את התהליך שיצר את התשובה המקורית, או בדיקה דטרמיניסטית מול כללים ידועים. verification חיצוני יכול לתפוס בדיוק את הטעויות ש-self-correction מפספס, כי הוא לא כפוף לאותה מגבלת ידע — הוא בודק מול משהו חיצוני, לא "חושב שוב" על אותו דבר.

כלל אצבע לעיצוב מערכת: שימוש ב-self-correction לבעיות פורמט ועקביות, שימוש ב-verification חיצוני לבעיות דיוק עובדתי ותקינות פונקציונלית. לרוב המשימות שדורשות אמינות אמיתית, נדרש שילוב של שתיהן — לא אחת במקום השנייה.

איך לעצב פרומפט/לולאה שממנפת Self-Correction בלי להטעות את עצמכם

• הבדילו מראש בין סוגי טעות — לפני שבונים לולאת תיקון, שאלו: הטעות הזו נובעת מחוסר תשומת לב או מחוסר ידע? זה קובע אם self-correction רלוונטי בכלל.
• תנו פידבק ספציפי, לא כללי — "תבדוק שוב" גרוע. "השדה X לא תואם לפורמט Y" טוב.
• אל תסתמכו על self-correction לתקן שגיאות עובדתיות — לכך יש להשתמש בכלים חיצוניים (retrieval, חישוב, בדיקה בפועל).
• מדדו את שיעור השיפור בפועל — לא להניח ש"זה עוזר" כי זה נשמע הגיוני; להשוות תוצאות עם ובלי סבב self-correction על מדגם ממשי (ראו LLM Evals).

דוגמה מהשטח

סוכן שמחלץ נתונים ממסמכים ומייצר JSON מובנה. self-correction עוזר מאוד כשמתגלה שהפלט לא עומד בסכימה (שדה חסר, טיפוס שגוי) — המודל יכול לתקן זאת בקלות כשמצביעים על השדה הבעייתי. אבל כשהמודל "ממציא" ערך למספר עוסק מורשה שלא הופיע בפועל במסמך (hallucination), בקשת "תבדוק שוב" לא תעזור — כי המודל "בטוח" שהוא ראה את המספר הזה. הפתרון האמיתי הוא verifier חיצוני שמשווה כל ערך שחולץ בחזרה מול הטקסט המקורי (grounding check), לא עוד קריאה למודל שמבקשת ממנו "לבדוק את עצמו".

טעויות נפוצות

• לבקש "תבדוק שוב" כפתרון גורף לכל בעיית איכות — עובד רק לתת-קבוצה מצומצמת של טעויות.
• להסתמך על self-correction לבעיות עובדתיות/hallucination — כמעט תמיד לא אפקטיבי, ולעיתים אפילו מזיק.
• לא להבחין בין "המודל לא שם לב" לבין "המודל לא יודע" — הטיפול הנכון שונה לחלוטין בין השניים.
• להוסיף סבבי self-correction בלי למדוד שיפור בפועל — מוסיף latency ועלות מבלי לוודא שיש תועלת.

הקשר בין Self-Correction ל-Temperature

פרמטר ה-temperature (מידת האקראיות בדגימת התשובה) משפיע גם על יעילות self-correction, ולעיתים בצורה לא-אינטואיטיבית. temperature נמוך (תשובות "בטוחות" ועקביות יותר) נותן פחות שונות בין ניסיון לניסיון — מה שיכול להיות בעיה בסבב תיקון, כי המודל נוטה לחזור על אותה תשובה כמעט זהה גם כשמבקשים ממנו לתקן. temperature מעט גבוה יותר בשלב ה-refine (בניגוד לשלב ה-generate הראשוני) יכול לעזור למודל "לצאת" מהתשובה השגויה המקורית ולחפש כיוון שונה, במקום להתכנס בחזרה לאותה נקודה. זו התאמה עדינה שכדאי לבחון אמפירית לפי סוג המשימה, לא כלל אצבע גורף.

השפעת גודל המודל על יכולת Self-Correction

יש הבדל אמפירי בין מודלים גדולים וחזקים לבין מודלים קטנים וזולים ביכולת ה-self-correction — לא כי מודל גדול "יודע יותר" באופן מוחלט, אלא כי יכולת ה-reasoning החזקה יותר שלו מאפשרת לו לזהות אי-עקביות פנימית ברמה עדינה יותר. בפרקטיקה, זה אומר שכדאי לשקול להשתמש במודל חזק יותר דווקא בשלב הביקורת (critique), גם אם השלב שיצר את התשובה הראשונית (generate) משתמש במודל קטן וזול יותר לצורך חיסכון — שילוב שנותן חלק ניכר מהיתרון של "שתי דעות" בעלות נמוכה יחסית ביחס להרצת שני סבבים מלאים במודל הכי חזק.

Self-Correction ברמת פסקה מול רמת מסמך שלם

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

מחקר וממצאים מהתחום — מה שידוע ומה שעדיין פתוח

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

איך Chain-of-Thought משפיע על self-correction

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

מקרה מיוחד: קוד שמריץ את עצמו

יש תחום אחד שבו self-correction עובד יוצא מן הכלל טוב — כתיבת קוד, בתנאי שהסוכן מריץ את הקוד בפועל ומקבל את פלט השגיאה האמיתי. זה למעשה כבר לא self-correction "טהור" במובן שתואר למעלה — זו לולאה שמשלבת מקור אמת חיצוני (הריצה בפועל, ראו AI Testing Agents) עם יכולת התיקון של המודל. המודל לא "מנחש" מה השגיאה — הוא רואה אותה במפורש (stack trace, הודעת קומפיילר), מה שהופך את הבעיה מ"תיקון עצמי ללא מידע חדש" ל"תיקון עם מידע חדש שסופק חיצונית". זה בדיוק ההבדל שקובע האם reflection/self-correction יעילים — יש מידע חדש בלולאה, או שהמודל פשוט מסתכל שוב על אותו דבר.

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

שאלות נפוצות

האם מודלים חזקים יותר (reasoning models) פותרים את בעיית ה-self-correction?

הם משפרים את זה חלקית — יש להם יכולת reasoning עמוקה יותר שמזהה יותר סוגי טעויות פרוצדורליות. אבל מגבלת הידע הפנימי (מה שהמודל לא יודע) לא נעלמת רק כי ה-reasoning חזק יותר.

האם self-correction מוסיף ערך גם אם משתמשים ב-verifier חיצוני?

כן — הם משלימים. verifier תופס בעיות עובדתיות ופונקציונליות; self-correction יעיל ומהיר לתיקון בעיות פורמט ועקביות שלא מצריכות בדיקה חיצונית יקרה.

איך יודעים אם טעות ספציפית ניתנת לתיקון עצמי?

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

האם לתת למודל לגשת לכלים (retrieval, קוד) הופך אותו ליותר "self-correcting"?

זה בדיוק המהות — ברגע שהמודל יכול לבדוק את עצמו מול מקור אמת חיצוני (הרצת קוד, שאילתה), זה כבר לא self-correction במובן הצר אלא verification עם כלים, שהרבה יותר אמין.

תגיות: Self-Correction · LLM Limitations · Verifier Models · AI Reasoning · Prompt Engineering · Hallucination

← חזרה לבלוג · צור קשר