יש הבדל אחד גדול בין באג רגיל לריקבון של מערכת AI. באג צועק. משהו נשבר, מקבלים שגיאה, מתקנים. ריקבון שותק. שום דבר לא קורס, אין שגיאה אדומה, פשוט לאט לאט התשובות נעשות פחות טובות, פחות עקביות, פחות אמינות. וכשאין רעש, אין מי שיתריע. זה מה שהופך את הדרדור השקט למסוכן יותר מכל קריסה.
הבנייה של מערכת AI היום מרגישה כמו הצלחה מהירה. הדמו עובד תוך יומיים, וזה משכר. אבל מה שקל לבנות קשה לתחזק, ורוב הצוותים מגלים את זה רק בשנה השנייה. בואו נפרק את ארבעת המנגנונים שגורמים לריקבון, כי ברגע שרואים אותם, אפשר לעצור אותם.
מנגנון ראשון: ידע משוכפל שנסחף
זה הגדול מכולם. כשכל סוכן מחזיק את ההוראות שלו בתוך ה-prompt שלו, ואותה יכולת חוזרת בכמה מקומות, כתבת את אותו ידע כמה פעמים. עכשיו מישהו משפר עותק אחד. השאר נשארים מאחור. מאותו רגע יש לך סוכנים שלא מסכימים: אחד יודע את הגרסה החדשה, השני עובד לפי הישנה. תכפילו את זה בעשרה מוצרים, ותקבלו עשרות עותקים שנסחפים כל אחד לכיוון אחר. קוראים לזה prompt drift, וזו הצורה הכי שקטה של ריקבון.
מנגנון שני: אתה לא מודד, אז אתה לא רואה
רוב הצוותים בונים מערכת AI בלי מדידה אוטומטית של האיכות. הם בודקים ידנית שזה עובד ביום ההשקה, ואז ממשיכים הלאה. הבעיה: איכות של פלט מ-AI לא יציבה כמו פונקציה. היא זזה. בלי evals שרצים על פלטים אמיתיים ומשווים לאורך זמן, אין לך שום דרך לדעת שהאיכות ירדה, עד שמישהו מבחוץ אומר לך. אתה עף עיוור, ומגלה את הבעיה מהלקוחות במקום מהמערכת.
מנגנון שלישי: הקרקע זזה מתחתיך
מערכת ה-AI שלך רצה על מודל בסיס של ספק חיצוני. וזה מתעדכן. כשהספק מוציא גרסה חדשה, ההתנהגות משתנה: פורמט שהיה יציב מתחיל לזוז, ניסוח שעבד מפסיק לעבוד, הגבולות של מה המודל מוכן לעשות זזים. לא נגעת בקוד, והמערכת מתנהגת אחרת. תוכנה רגילה לא עושה את זה, היא נשארת בדיוק כמו שהשארת אותה. מערכת AI לא, כי חלק ממנה חי אצל מישהו אחר. מי שלא מקבע גרסת מודל ולא בודק אחרי שדרוג, מגלה את זה בדרך הקשה.
מנגנון רביעי: כל שיפור נשאר מקומי
זה הצד השני של המטבע הראשון. לא רק שבעיה במקום אחד לא מתפשטת, גם תיקון במקום אחד לא מתפשט. מצאת ניסוח מעולה שמשפר את התשובות של סוכן אחד? נהדר, אבל שאר הסוכנים לא יודעים עליו. כל למידה נשארת כלואה במקום שבו קרתה. המערכת לא נעשית חכמה יותר כמכלול, היא רק צוברת אי-אחידות. ארגון שלא מרכז את הידע גם לא מרכז את השיפורים.
הסימנים שזה כבר קורה
איך יודעים שהמערכת שלך כבר בתהליך? יש שלושה סימנים מוקדמים, וכולם שקטים:
- שני חלקים במערכת מחזירים תשובות שונות לאותה שאלה, ואף אחד לא יודע איזו נכונה.
- יש סוכן או רכיב שאף אחד בצוות לא רוצה לגעת בו, כי לא ברור מה יישבר.
- המשפט ״זה עבד פעם״ מתחיל להישמע בישיבות. זה הצליל של ריקבון.
אם משהו מזה נשמע מוכר, המערכת שלך לא עומדת להתדרדר. היא כבר מתדרדרת. פשוט עוד לא מדדת את זה.
תוכנה רגילה נשארת כמו שהשארת אותה. מערכת AI נשענת על מודל שזז ועל ידע שמבוזר, ושניהם נעים לבד. יציבות היא לא ברירת מחדל פה, היא משהו שבונים בכוונה.
התרופה: לעצור את הסחיפה, לא לכתוב prompt חכם יותר
הטעות הנפוצה היא לחשוב שהפתרון הוא ניסוח טוב יותר. הוא לא. אי אפשר לנסח את הדרך החוצה מבעיה מבנית. התרופה היא לשנות איך הידע חי במערכת: לרכז כל יכולת למקום אחד שכולם טוענים ממנו כדי שאין עותקים שנסחפים, למדוד את האיכות אוטומטית כדי שתראה דרדור מוקדם, ולנעול גרסאות של הידע ושל המודל כדי שכלום לא זז בשקט. זו הגישה שקראנו לה הנדסת יכולות, והרחבנו עליה בנפרד. היא לא זוהרת ולא מרשימה בדמו, אבל היא ההבדל בין מערכת שמתחדדת עם הזמן לאחת שמתפוררת.
איך זה עובד ב-HELIX
כל מוצר ב-HELIX בנוי כצוות סוכנים, ובנינו אותם מראש נגד הריקבון. הידע לא יושב בתוך כל סוכן בנפרד אלא בספרייה משותפת שכולם טוענים ממנה, כך שאין עותקים שנסחפים. שיפור ביכולת אחת מגיע לכל הסוכנים שמשתמשים בה. הפלטים נמדדים, והגרסאות נעולות. התוצאה היא מערכת שנעשית חדה יותר ככל שעובדים עליה, במקום כזו שצריך לשקם אותה כל חצי שנה. זו לא קסם, זו משמעת שבנויה פנימה.
השורה התחתונה: מערכת AI לא נשארת טובה מעצמה, היא נשחקת אם לא מחזיקים אותה בכוונה. אם אתה לא מרכז את הידע ולא מודד את האיכות, המערכת שלך כבר בתהליך, אתה פשוט עוד לא רואה אותו. הזמן הכי טוב לעצור את הסחיפה הוא לפני שהיא נראית. השני הכי טוב הוא היום.