jev-latest

Jev הוא מודל הדגל של TypeSafe והמודל הראשון בקטגוריה החדשה System One. הוא אינו כותב טקסט, אלא מקבל במהירות החלטות שהתוכנה יכולה להשתמש בהן מיד: מוסרים מצב (state) — טקסט או JSON — וקבוצת שאלות, ומקבלים ערכים מוגדרי טיפוס עם הסתברויות מכוילות.

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

במה System One שונה ממודל שפה

• אינו מייצר. Jev אינו כותב תשובות למשתמש, אינו כותב קוד ואינו מסביר את מהלך ההסקה. אתם מגדירים את התשובות האפשריות — באמצעות אחד משלושת סוגי השאלות.
• מאומן להחלטות מכוילות. TypeSafe מאמנת את המודל בשיטת RLCD (Reinforcement Learning for Calibrated Decisions): ההסתברויות מותאמות לתוצאות בפועל ומשקפות אי־ודאות. מתוך תשובות רבות עם הסתברות של 0,8, בערך 80% אמורות להיות נכונות. כיול הוא תכונה של מדגם גדול, ולא הבטחה לנכונותה של תשובה בודדת.
• מטרת אימון שונה. מודלי שיחה מאומנים למצוא חן בעיני אנשים (RLHF), ולפי התצפית של TypeSafe זה מעודד ריצוי ושגיאות שנשמעות בטוחות. אחד השותפים ליצירת RLHF, דיוגו אלמיידה, הוא מייסד שותף של TypeSafe.

השם מתייחס ל«מערכת 1» בספרו של דניאל כהנמן «לחשוב מהר, לחשוב לאט»: שיפוט אינטואיטיבי מהיר לעומת חשיבה שקולה ואיטית של «מערכת 2». Jev נוצר לשיפוטים מהירים וצרים.

שלושה סוגי שאלות

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

1. Choice — בחירת אפשרות. מחלקה לפנייה, קטגוריית מוצר, שפת קטע קוד. האפשרויות הן מילון «אפשרות → תיאור», עד 255 אפשרויות. התשובה כוללת את ה־choice שנבחר, probabilities לכל האפשרויות (בסכום של 1) ומידת ביטחון confidence. אם הרשימה עשויה לא לכסות את כל המקרים, הוסיפו «אחר» או «אף אחת מהאפשרויות».
2. Score — דירוג בסולם. מקום בסולם מסודר שאתם מתארים: חומרת שגיאה, מידת הרוגז של הלקוח, רמת מיומנות. בין 2 ל־10 רמות, מהנמוכה לגבוהה; המודל מעריך כל רמה בנפרד, בלי לראות את מספרה ואת שכנותיה. התשובה כוללת score (סכום מספרי הרמות כפול הסתברויותיהן, ולכן הערך עשוי להיות בין הרמות), legend עם תיאורי הרמות, probabilities ו־confidence.
3. Noul — כן או לא. האם הטענה נכונה. התשובה noul היא הסתברות ל«כן» בין 0 ל־1: קרוב ל־1 — «כן» בטוח, קרוב ל־0 — «לא» בטוח, קרוב ל־0,5 — המודל מתלבט. אין confidence נפרד: מספר אחד מתאר את התשובה בשלמותה. criteria אופציונלי מבהיר מה נחשב «כן» ומה «לא».

איך לבחור: אפשרויות ידועות ללא סדר — choice; דרגות בספקטרום — score; «כן/לא» בלבד, כשההסתברות עצמה חשובה — noul. Noul 0,5 פירושו סיכוי שווה ל«כן» ול«לא», ולא «רמה בינונית»: score מודד דרגה. מבין שני סוגים מתאימים בחרו את זה שהקוד פועל לפיו מיד: choice לתנאים מסועפים, score לסף, noul ל־if.

אפשר לשלב סוגים בבקשה אחת. התשובה תמיד מוגבלת לאפשרויות שלכם ואינה תלויה בשאלות אחרות: אפשר להוסיף או להסיר שאלות בלי לשנות את שאר התשובות.

המצב

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

• מחרוזת — כשיש טקסט אחד: הודעה, מאמר, קטע.
• אובייקט — שדות בעלי שם, רשומות קשורות, מצב היישום. TypeSafe ממליצה על אובייקט לרוב הבקשות: לכל חלק יש שם מובן.
• מערך — רצף של הודעות או רשומות.

הכינו אותו כחומרים למומחים: שימו יחד התכתבות, הזמנה וכללי החזרה אם ההחלטה דורשת להשוות ביניהם. שמרו תוכן במצב ושיפוטים בשאלות. אם השאלה עוסקת בחלק אחד של המצב, ציינו בה את הנתיב אליו בגרשיים הפוכים, למשל ticket.messages[0].text.

איך להגדיר שאלות

• שיפוט מהיר אחד לכל שאלה. שאלה טובה היא כזו שאדם שמבין בתחום ועם ההקשר הדרוש יענה עליה בשנייה: «האם יש דחיפות בהודעה?». «נתח את ההודעה והחלט מה לעשות» הוא כבר הסקה איטית, וצריך לחלקו לשאלות פשוטות.
• כל השאלה ב־instructions. מפתח השאלה, למשל refund_requested, דרוש רק לקוד שלכם ואינו מועבר למודל.
• כל השאלות לגבי מצב אחד בבקשה אחת. המודל מעריך אותן במקביל: לפי TypeSafe, שאלות נוספות כמעט אינן מאריכות את זמן התשובה ועלותן רק הטוקנים שלהן. שאלה «ליתר ביטחון» עולה כמעט כלום — הקוד יחליט בעצמו אילו תשובות דרושות.
• שיפוט מורכב בחלקים. במקום «הערך בקשת סטארט־אפ», שאלו בנפרד על גודל השוק, ההיתכנות הטכנית וההבדלים מהמתחרים, וחשבו את התוצאה בקוד עם משקלים. השתנו העדיפויות — שנו את המשקלים, ולא את השאלה.
• שאלות תלויות בבקשה שנייה. תשובות בבקשה אחת אינן משמשות הקשר זו לזו. בקשה שנייה דרושה רק אם אי אפשר להרכיב אותה ללא התשובה הראשונה: צריך לטעון נתונים נוספים או לבחור אפשרויות לשאלה הבאה.
• שאלה ארוכה כאובייקט. instructions ו־criteria הם בדרך כלל מחרוזות, אך יכולים להיות אובייקט או מערך: השאלה בשדה אחד, והנתונים באחרים. כך נוח להשוות קורות חיים לרשומות בסיס נתונים בשאלה אחת.

מידת ביטחון

ב־choice וב־score, confidence בין 0 ל־1 מציג עד כמה ההסתברות מרוכזת בתשובה אחת: 1 — כולה באפשרות אחת, 0 — שווה בכל האפשרויות. ב־score רמה סמוכה מפחיתה את הביטחון פחות מרמה רחוקה. ב־noul מידת הביטחון היא הערך עצמו: ככל שהוא רחוק מ־0,5, כך התשובה נחרצת יותר.

TypeSafe ממליצה על שלושה טווחים:

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

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

איך לבנות מערכת סביב Jev

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

1. כל מה שאפשר לעשות בקוד, עשו בקוד — באופן מהימן ובעלות נמוכה.
2. במצב — רק מה שהשאלות הנוכחיות צריכות; עובדות עדכניות — מבסיס הידע שלכם, ולא מזיכרון המודל.
3. מבנה במצב: JSON מקונן, ובשאלה נתיב לשדה הדרוש בגרשיים הפוכים, אם כך יש פחות עמימות.
4. שאלות צרות ומוגדרות ככל האפשר — לפי TypeSafe, אולי הכלל החשוב ביותר: שאלה רחבה מסתירה כמה שיפוטים מאחורי תשובה אחת.
5. מבנה בשאלות: השאלה עצמה קצרה; הסברים, דוגמאות וערכים מהבסיס שלכם בשדות סמוכים באובייקט instructions או criteria, ולא במחרוזת ארוכה אחת.
6. שאלות עצמאיות רבות למצב אחד בבקשה אחת — יותר תועלת לכל דולר.
7. הקוד משלב תשובות: באמצעות כללים, סכום משוקלל או כתכונות למודל קלאסי של למידת מכונה.
8. הסתעפות לפי מידת ביטחון: מקרים לא בטוחים לאדם או למודל עם הסקה.

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

תחומי שימוש

• אוטומציה ברקע — החלטות שמפעילים מיליון פעמים בלי אדם לידן.
• זמן אמת — לפי TypeSafe, רוב הבקשות מבוצעות בתוך כ־100 אלפיות השנייה: מספיק לעיבוד בזמן הפעולה ולממשקים.
• נתונים גדולים — חיפוש במאגרים עצומים, תיוג יומני עבודה של סוכנים, תכונות לחיזוי.
• בדיקת מודלים אחרים — בקשות, חילוץ מידע, הסקה, קריאות לכלים: עקיפת מגבלות, שגיאות ציטוט ומידע מומצא.
• חיפוש ודירוג — רלוונטיות של צמד «שאילתה — מועמד», דירוג מחדש, בחירת הקשר.
• הסתעפות לפי כוונה — מה המשתמש רוצה ואיזה מטפל דרוש: לוגיקה פשוטה, מודל ייעודי או אדם; הנושא, המורכבות והסיכון קובעים לאיזה מודל שפה להעביר את הבקשה.
• בדיקות הגנה — קלט, פלט וקריאות לכלים של מודל שפה: הוראות מוזרקות, הפרות כללים, דליפת נתונים אישיים.
• תמיכה — נושא הפנייה וכוונתה, דחיפות, רוגז, סיכון נטישה, בקשת החזר כספי, תור.
• פיקוח על תוכן — לפי כללי הפלטפורמה שלכם: רעילות, בריונות, ספאם, הונאה, עצות מסוכנות, נתונים אישיים; לפי חומרה ומידת ביטחון — לאפשר, להזהיר, לבדוק או לחסום.
• ענפים — מקרי ביטוח, חקירות פיננסיות ו־KYC, חוזים ופרסום, כרטיסי מוצרים, גיוס עובדים, לקוחות פוטנציאליים, משחקים, סיכונים, חיזוי ביקוש, גרפי ידע, סקירות מדעיות, בדיקות משמעות של קוד ב־CI.

מאפיינים

• jev-latest — כינוי לגרסה היציבה האחרונה, כרגע Jev 1.13; הגרסה שהשיבה מופיעה בשדה model, למשל jev-1.13.0. בגרסה חדשה הכינוי עובר אליה, והתשובות עשויות להשתנות בלי תיקונים מצדכם — עקבו אחר השדה הזה אם הספים הותאמו לגרסה.
• הקשר — 64K טוקנים בכל בקשה: המצב וכל השאלות יחד; המצב עם השאלה הארוכה ביותר עד 32K. המודל קורא את המצב פעם אחת ובודק מולו את כל השאלות במקביל.
• קלט — טקסט בלבד: מחרוזת, אובייקט JSON או מערך טקסטים. תמונות, אודיו ווידאו עדיין אינם נתמכים — המירו אותם לטקסט מראש.
• שפה — שפת האימון העיקרית היא אנגלית, ובה הדיוק כרגע הגבוה ביותר. המודל מקבל שפות אחרות, כולל סינית, יפנית וקוריאנית, אך הדיוק נמוך יותר — בדקו על הנתונים שלכם.
• מחירים וחיוב ב־Ailoot API — התנאים תלויים במתודה שנבחרה ומצוינים בכרטיס שלה.
• הגדרה — Jev אינו עובר אימון נוסף על נתוני הלקוח: החומרים שלכם ב־state, וכללי התחום ב־instructions וב־criteria.
• נתונים — TypeSafe מדווחת ש־Jev אינו מאומן על בקשות ותשובות של לקוחות.

נקודות חולשה ידועות של Jev 1.13

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

1. קורא מילולית. עונה על השאלה שנכתבה, ולא על המשתמעת: הסתייגויות, שלילות ותנאים מרומזים מובנים מילולית. כתבו תנאי מדויק ומקרי קצה ב־criteria; פרשנות בלתי נמנעת חלקו לשתי שאלות מילוליות.
2. אינו מחשבון. ספירת תווים, חזרות ופריטי רשימה אינה מהימנה, והטעות גדלה עם הגודל — ספרו בקוד, עם שאלה לכל מועמד. המודל מבין צבעים ב־hex או ב־RGB פחות טוב משמותיהם. score מתאים לסף, אך לא למספר מדויק בין רמות.
3. תאריכים וזמן. איזה תאריך מוקדם יותר, מה המרווח ביניהם, האם תאריך נכלל בתקופה — לא מהימן, במיוחד בפורמטים מעורבים ובתאריכים יחסיים. חלצו חלקי תאריך באמצעות choice (עם אפשרות «לא צוין»), והשוו בקוד.
4. ניסוח עקיף. שלילות כפולות ושאלות על תכונה של תכונה מפחיתות את הדיוק. כתבו ישירות וציינו חלקי מצב בשמם.
5. תוכן עודף במצב. טקסט זר מפחית את הדיוק. סננו בקוד, ואם אי אפשר — הסירו תוכן לא רלוונטי בשאלות noul.
6. טקסט עוין. כברירת מחדל המודל אינו מצפה למלכודות במצב: הוראה מוזרקת או טקסט שמתווכח על סיווגו שלו יכולים להזיז את התשובה. כתבו קריטריונים מדויקים ובדקו מקרי גבול לפני ההפעלה.
7. סתירות. אם instructions ו־criteria מבקשים דברים שונים — למשל ב־noul «כן» מתואר כ«לא» — הדיוק יורד. הקריטריונים הם המשך השאלה.
8. סדר האפשרויות. לפעמים המודל נוטה לאפשרות הראשונה ב־choice. שנו את הסדר ובדקו שהתשובה אינה משתנה.
9. יצירה. Jev לא אומן לכתוב טקסט. לחילוץ נתונים מצאו מועמדים בביטוי רגולרי או במודל יוצר, ותנו ל־Jev לבחור את הנכון באמצעות choice.