בין הבטחה למציאות - ואיך לא ליפול במלכודת

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

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

פרה על כביש: הבעיה הבסיסית שלא זזה מילימטר

פעם מודלים של AI זיהו פרות על כבישים בתור מכוניות. למה? כי הם למדו לזהות את האספלט, לא את הרכב. פרה על אספלט שווה מאזדה 3. הגיוני סך הכל.

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

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

וזה בדיוק מה שמפחיד.

כשה-AI פולט את התשובה ה"נכונה" - אבל לא את הנכונה לכם

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

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

וזה לא באג. זה ההתנהגות הצפויה של המודל.

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

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

מי המשתמש? השאלה שמגדירה את הארכיטקטורה

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

וזה מחזיר אותנו לשאלה הכי בסיסית בארכיטקטורה: מי המשתמש? מי צורך את התוצר?

עבור מכונות וסוכנים, Markdown ו-JSON הם המלכים. הם חוסכים בעלויות טוקנים ומתאימים מצוין למנגנוני הקשב של LLMs. עבור בני אדם, HTML יכול להיות הבחירה הנכונה - אבל עם סייגים רציניים.

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

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

למה חייבים מומחה בחדר

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

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

זה לא אומר לא להשתמש ב-AI. ההפך. זה אומר להשתמש בו כמו שמשתמשים בכל כלי חזק - עם מישהו מנוסה שיודע מתי הכלי מתאים ומתי הוא מסוכן. מפתח שמקבל פלט מ-AI ומריץ אותו ישר לפרודקשן בלי לשאול "למה"? הוא לא יעיל - הוא מסוכן.

הגישה הנכונה היא ביונית: אנשים שמשתמשים ב-AI כדי להיות טובים יותר, לא אנשים שמוותרים על החשיבה כי ה-AI "כבר עשה את העבודה".

Takeaways

הבעיה הבסיסית לא השתנתה. ה-AI מוגבל למה שהוא למד באימון. הוא לא יודע מה הוא לא יודע, ולכן הטעויות שלו נראות כמו תשובות נכונות. ככל שהדומיין מורכב יותר, הסיכון גדל.

החלטות ארכיטקטורה הן החלטות עסקיות. הבחירה בין HTML ל-Markdown, בין פתרון גנרי לפתרון מותאם, בין מהירות פיתוח לאבטחה - כל אחת מהן משפיעה על עלויות, על סיכון עסקי, ועל time-to-market. מי שמתייחס לזה כהחלטה טכנית בלבד מפספס את התמונה.

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

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

איפה ה-AI שלכם הפתיע אתכם - לטוב או לרע - בפרודקשן השנה?

הצטרפו לדיון: