רציתי לבדוק אם הרצת אותה שאלה 51 פעמים תהפוך את התשובה לאמינה יותר. לקחתי LLM מקומי, הזנתי לו קטע קוד ייצור (production code), וביקשתי סקירה. אז עשיתי זאת שוב. ושוב. חמישים ואחת פעמים בסך הכל, תוך שימוש בהצבעת רוב כדי לבחור את התגובה ה"טובה" ביותר. הרעיון היה פשוט: אם המודל נתקל בקושי בהרצה אחת, אולי חוכמת ההמונים לאורך 51 יצירות תבטל את הרעש ותחשוף את הניתוח הנכון. זה לא מה שקרה. הניסוי הראה שהצבעת רוב אינה בוחרת בנכונות. היא בוחרת במה שהמודל הכי עקשן לגביו.
ההבחנה הזו חשובה מכיוון שהצבעת רוב הפכה ל"טריק" פופולרי בצינורות עבודה (pipelines) של LLM. התבנית היא פשוטה. מריצים את המודל מספר פעמים על אותו פרומפט, אוספים את הפלטים, ושומרים את התשובה שמופיעה בתדירות הגבוהה ביותר. בתחומים כמו דימות רפואי או זיהוי ספאם, שיטות ensemble עובדות מכיוון שמודלים שונים, או מבטים שונים על הנתונים, מייצרים שגיאות עצמאיות שבאמת מבטלות זו את זו. מודלי שפה גדולים אינם מצביעים באופן עצמאי. הם מערכת אחת עם היסטוריית אימון אחת, סט משקולות אחד ומרחב הטיות אחד. כשאתה שואל את אותו מודל את אותה שאלה חמישים ואחת, אתה לא מכנס ועדה. אתה עורך סקר של אותו משיב תחת מצבי רוח מעט שונים.
בעיית ההתמדה
הליבה של הבעיה היא ששגיאות LLM הן לעיתים רחוקות אקראיות. הן תבניות המוטמעות בנתוני האימון ובארכיטקטורה. מודל שקורא לא נכון דקורטור Python ספציפי בהרצה אחת, צפוי לקרוא אותו לא נכון גם בהרצה הבאה. מודל שמזייף (hallucinates) פרצת אבטחה כי שם המשתנה נראה כמו סיסמה, כנראה יזייף אותה שוב בהרצה ה-47. הרעש שאתה מנסה למצע הוא בדרך כלל שונות ברמת השטח של ניסוח או פורמט. ההיגיון הבסיסי נשאר לרוב נעול במקומו.
שקלו דוגמה קונקרטית. דמיינו פונקציה שמנתחת קובצי לוג באמצעות ביטוי רגולרי (regex). ה-regex הוא קשיח ובטוח. אך המחרוזת r'...' מכילה תווים שבהקשר אחר עלולים לאפשר הזרקה (injection). בקשו מ-LLM לסקור זאת. אם המודל ראה אלף פוסטים ב-Stack Overflow המזהירים מפני הזרקת regex במנתחי לוגים, הוא עשוי לסמן את הקטע הבטוח הזה כסיכון. הריצו זאת פעם אחת, ותקבלו התרעת שווא (false positive). הריצו זאת 51 פעמים, ויש סיכוי טוב שתקבלו 51 התרעות שווא, או לפחות רוב מוחלט. הצבעת הרוב כעת מעגנת את ההזיה. המודל עקשן, ולכן גם ה"קונצנזוס" עקשן.
זה קורה מכיוון שטכניקות טמפרטורה ודגימה (sampling) אינן משנות את מה שהמודל יודע. הן רק מסדרות מחדש את האופן שבו הוא מדבר. טמפרטורה גבוהה עשויה להפוך את ההסבר למדבר או תמציתי. היא עשויה להחליף מילים נרדפות. היא לא מלמדת את המודל פתאום שה-regex הוא למעשה חסר נזק. הווריאציות שאתם מצביעים עליהן הן קוסמטיות. השגיאה היא מבנית.
מה 51 הרצות חושפות
כשפרשתי את 51 הפלטים הללו על שולחני, התבנית הייתה ברורה. המודל לא חקר 51 פרשנויות שונות של הקוד. הוא חזר על אותה פרשנות בקולות מעט שונים. קומץ הרצות חרגו מהתסריט, והציעו תיקונים למקרי קצה או הבחינו בבעיות סגנון לא קשורות. אך האשכול הדומיננטי, הרוב הברור, המשיך לחזור לאותה טענה מרכזית שגויה. הטענה הזו לא הייתה נכונה. היא פשוט הייתה מוכרת.
המתמטיקה של הצבעת רוב מניחה ניסויים ברנולי עצמאיים. אתם זקוקים לשגיאות לא קשורות כדי שהרוב יתפקד טוב יותר מהיחיד. בניסוי שלי, השגיאות היו קשורות עמוקות. הן חלקו את אותו גורם שורש: התפלגות האימון של המודל מעניקה משקל יתר לטרופים (tropes) מסוימים של כתיבת קוד. לכן, הצבעת הרוב לא הפחיתה את השגיאה. היא הגבירה את הטיית הרוב. היא נתנה תחושת ודאות שגויה לניתוח פגום.
זה מסוכן במיוחד בסקירת קוד מכיוון שמפתחים מתייחסים לפלט AI חד-קולי או כמעט חד-קולי כסמכותי. הצעה אחת מהססת קל להתעלם ממנה. המלצה שנותרת יציבה לאורך חמישים ואחת הרצות מרגישה כמו אמת מוחלטת (ground truth). היא לא. היא לולאת קרקע (ground loop).
איפה הצבעה באמת עובדת
כל זה לא אומר שאתם לא צריכים להריץ מודל יותר מפעם אחת. הצבעת רוב יכולה לעזור במצבים ספציפיים שבהם המשימה היא שטחית והשגיאות הן אקראיות באמת. לבקש ממודל לבחור בין שני פורמטים תחביריים, לבחור מוסכמת שיום משתנים, או לחלץ מחרוזת תאריך משורת לוג — משימות בעלות סיכון נמוך אלו עשויות להפיק תועלת מדגימה חוזרת. השונות היא רעש אמיתי, והצבעה מהירה מנקה אותו.
הבעיה מתחילה כאשר המשימה דורשת הסקה לגבי כוונה. האם בדיקת ה-auth הזו שייכת לכאן? האם הקריאה האסינכרונית הזו בטוחה? האם התנגשות במפתחות ה-cache הזו היא באמת ניתנת לניצול? שאלות אלו דורשות הבנה של הקשר, ולא רק התאמת תבניות. מנגנון התאמת התבניות של המודל הוא דטרמיניסטי בהטיה שלו. הוא ימשוך את התשובה הנפוצה ביותר מנתוני האימון שלו, ולא את התשובה המדויקת ביותר עבור בסיס הקוד שלכם.
דרכים חכמות יותר לנצל את כוח המחשוב שלכם
חמישים ואחת הרצות של מודל מקומי עולות זמן וחשמל אמיתיים. יש דרכים טובות יותר להשקיע את כוח המחשוב הזה. אם אתם רוצים לשפר את האמינות, גיוון עדיף על כמות. הריצו שני מודלים שונים עם