מודל ה-AI Jev נבנה להחלטות, לא לפרוזה

Jev מתואר על ידי TypeSafe AI כמודל חדש מבוסס טרנספורמר, אבל לא כמודל שפה גדול. במקום לייצר טוקני טקסט, הוא מחזיר הסתברויות על פני פלטים שמפתחים מגדירים מראש. לפי TechCrunch, TypeSafe מכנה את הפלטים האלה “החלטות מכוילות”.

לפי הדיווח, לתכנון הזה יש שלוש השלכות מיידיות.

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

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

שלישית, ההסתברות הזו היא חלק מהמוצר, לא מחשבה בדיעבד. Armin Ronacher, ה-CTO של Earendil, אמר ל-TechCrunch ש-Jev “מעביר את בעיית ההזיות קצת אל המשתמש”. אם תוצאה חוזרת עם 50%, האפליקציה עשויה להתעלם ממנה. אם היא חוזרת עם 95%, האפליקציה עשויה לפעול.

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

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

שתי דוגמאות בדיווח מראות את צורת הביקוש הזו.

Pranit Sharma, מהנדס תוכנה ב-Vercel, אמר ל-TechCrunch ש-Vercel השתמשה במודל של OpenAI כדי להריץ מסווג שבדק פקודות מבחינת בטיחות. כש-Vercel החליפה את Luna של OpenAI ב-Jev, Sharma אמר שהיא קיבלה תוצאות מהר פי חמישה עד פי 18, ובדיוק גבוה יותר.

Nikhil Mudholkar, ה-CTO של Bryo AI, בדק את Jev מול Gemini בסיווג אימיילים עסקיים, לפי TechCrunch. בבדיקה שלו, Gemini היה מעט מדויק יותר, אבל יקר פי 10 עד פי 20. Mudholkar הדגיש את ציוני הביטחון של Jev, ואמר שהוא היה “היחיד שמחזיר הסתברות אמיתית”, מה שהפך אותו לשימושי לאוטומציה של תהליכי עבודה.

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

דוגמאות כוללות:

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

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

אחד השימושים המעניינים ביותר בדיווח של TechCrunch אינו החלפת LLMs, אלא החלטה מתי להשתמש בהם.

Ronacher אמר ל-TechCrunch ש-Jev יכול להיות שימושי לניתוב מודלים: חיזוי האם עומס עבודה נתון צריך מודל מסוים. שימוש ב-LLM כדי לקבל את ההחלטה הזו יכול להיות יקר. מודל זול ומהיר יותר שמחזיר ציון מכויל יכול לשבת לפני מערך מודלים ולהחליט לאן כל בקשה צריכה ללכת.

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

כאן גם הצורה של Jev חשובה. נתב לא צריך מאמר על למה prompt מסוים קשה. הוא צריך החלטה כמו:

• לשלוח למודל קטן;
• לשלוח למודל חזיתי;
• לאחזר מסמכים קודם;
• לבקש אישור אנושי;
• לדחות כלא בטוח.

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

Jev מרמז שגם הניתוב עצמו עשוי להפוך לעומס עבודה של AI עם מודלים ייעודיים מאחוריו.

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

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

אבל הארכיטקטורה נקייה:

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

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

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

הארכיטקטורה נותרת חלקית עמומה. לפי TechCrunch, Almeida “שומר על עמימות” לגבי הקרביים של Jev, בעוד משקיפים חיצוניים חושדים שהוא בנוי על גבי LLM עם משקלים פתוחים. TypeSafe AI מכנה את Jev “מודל System One”: מודל שמותאם להחלטות מהירות ודמויות אינטואיציה במקום לחשיבה מפורשת, עם תכנון צר יותר שמותאם למשימה.

Almeida אמר ל-TechCrunch ש-Jev מאומן אך ורק על נתונים סינתטיים באמצעות טכניקה שהוא מכנה “למידת חיזוק מהחלטות מכוילות”. הוא גם אמר ש-TypeSafe AI הימרה מוקדם על יצירת כל הנתונים שלה בעצמה. הוא תיאר חלק מהחברה כמעבדה שמתמקדת ב“נתונים סינתטיים שמובנים היטב סטטיסטית”.

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

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

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

Jev נקרא על שם William Stanley Jevons, הכלכלן בן המאה ה-19 שמזוהה עם פרדוקס Jevons: כשמשאב נעשה יעיל יותר לשימוש, הצריכה הכוללת יכולה לעלות במקום לרדת. Almeida אמר ל-TechCrunch ש-TypeSafe AI מצפה שאינטליגנציה זולה יותר תוביל ל“תוכנה חכמה בכל מקום”, יותר כמו האינטרנט המוקדם מאשר עולם שנשלט רק על ידי “מגה-אפליקציות”.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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