מודל החלטות Jev: להפסיק לשלם למודל גדול על החלטות כן או לא

מה זה מודל החלטות Jev ולמה הוא מוזיל סוכני AI?

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

המדריך מבוסס על מאמר של Hanako (@hanakoxbt) ב-X מ-20 בספטמבר 2026, Jev Engineering: How to Stop Paying a Frontier Model to Make Yes-or-No Decisions (נפתח בחלון חדש). כתבנו אותו מחדש בעברית, הרצנו את דוגמאות הקוד מול ה-API החי והוספנו מדידות משלנו, כולל בדיקה על פניות בעברית.

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

למה החשבון על מודלים לא יורד גם כשמחיר הטוקנים יורד?

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

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

מה שולחים ל-Jev ומה מקבלים בחזרה

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

יש שלושה סוגי שאלות, וזה כל ה-API. הטבלה מסכמת מה כל אחד מחזיר לפי התיעוד הרשמי של TypeSafe (נפתח בחלון חדש) ולפי התשובות שקיבלנו בפועל ב-5 באוקטובר 2026.

נתונים מהתיעוד, נכון ל-5 באוקטובר 2026: המחיר הוא 0.042 דולר למיליון טוקנים של קלט, טוקני הפלט חינמיים, והגבול הוא 64 אלף טוקנים לבקשה כולה (ה-state וכל השאלות יחד), כשה-state והשאלה הארוכה ביותר יחד מוגבלים ל-32 אלף [docs.typesafe.ai/models, אוקטובר 2026]. הקלט הוא טקסט בלבד, בלי תמונות או קול.

איך מחליטים מה עובר ל-Jev ומה נשאר במודל שפה?

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

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

צעד 1: מתקינים את ה-SDK ושומרים את המפתח בסביבה

בדוגמה נבנה עזר לביקורת קוד: ממליץ שהשינוי מוכן להמשך תהליך הפריסה (ship), מחזיר לתיקון (return) או מעביר לאדם (escalate). זו דוגמה למצב צל, לא שער שמוסמך לפרוס לייצור. גם ship מחייב את בדיקות ה-CI ואישור הסוקר הקיימים; מודל יכול לפספס שינוי רגיש גם כשה-diff מלא.

צריך חשבון TypeSafe עם גישת API ומפתח מלוח הבקרה. ה-SDK ל-Python הוא typesafe-sdk (בדקנו את הגרסה 0.7.2, שדורשת Python 3.10 ומעלה) וה-SDK ל-JavaScript הוא @typesafe-ai/sdk. לפני כתיבת קוד אפשר לנסות שאלה אחת ב-Playground של TypeSafe ולראות איך ההסתברויות זזות כשמשנים שדה אחד ב-state.

1. יוצרים סביבה וירטואלית ומתקינים את typesafe-sdk (Python 3.10 ומעלה; הדוגמאות נבדקו עם Python 3.12).
2. שומרים את המפתח במשתנה הסביבה TYPESAFE_API_KEY. ה-SDK קורא אותו אוטומטית, כך שהמפתח לא נכנס לקוד ולא ל-Git.
3. מריצים קריאה אחת קטנה ומוודאים שהתשובה מגיעה עם שדה model שמציין גרסה, למשל jev-1.13.0.
4. אם עובדים עם סוכן קוד, התיעוד מציע להתקין קודם את ה-skill הרשמי של TypeSafe כדי שהסוכן יכיר את מבנה הבקשה והתשובה.

python3 -m venv .venv
.venv/bin/pip install typesafe-sdk==0.7.2

# המפתח נשמר בסביבה, לא בקוד
export TYPESAFE_API_KEY="your-key"

# ב-Node.js:
npm install @typesafe-ai/sdk

צעד 2: בונים את ה-state בקוד, לא במודל

הטעות הנפוצה ביותר היא לשלוח ל-Jev את ה-diff הגולמי ולקוות לטוב. כל מה שאפשר לחשב נשאר בקוד: מספר שורות, נתיבי קבצים, קוד היציאה של הבדיקות, האם יש קובץ migration, אילו קבצים יצאו מחוץ לתוכנית.

מעבירים ל-build_state את ה-diff המלא ממקור מהימן, כולל תוכן קבצים חדשים. השדה diff_complete מסמן שהקלט שסופק אינו ריק ולא נחתך במגבלת 2,000 התווים. אם הוא false, השער מעביר לאדם לפני קריאת API. הדגל אינו יכול לגלות שקובץ הושמט עוד בזמן האיסוף: איסוף שנכשל, שינוי בינארי או מידע חסר מחייבים בדיקה ידנית. נתיבי הקבצים ותוצאות הבדיקות מגיעים מ-Git ו-CI, לא מדיווח הסוכן שכתב את הקוד.

def build_state(plan_paths, changed_paths, lines_added, tests_exit_code, has_migration, full_diff):
    """Everything here is computed by code. Jev only reads the result."""
    outside = sorted(set(changed_paths) - set(plan_paths))
    return {
        "planned_paths": plan_paths,
        "changed_paths": changed_paths,
        "paths_outside_plan": outside,
        "lines_added": lines_added,
        "tests_passed": tests_exit_code == 0,
        "has_migration": has_migration,
        "diff_excerpt": full_diff[:2000],
        "diff_complete": bool(full_diff.strip()) and len(full_diff) <= 2000,
    }

צעד 3: כותבים שאלות שמסבירות את עצמן

שלושת סוגי השאלות נכנסים יחד לאותה בקשה. כאן יש Choice להחלטה עצמה, Score לרמת הסיכון ו-Noul לשאלה אם השינוי נוגע בהרשאות. שאלות Score מקבלות רשימה מסודרת של דרגות מהנמוכה לגבוהה; כשניסינו לשלוח מילון במקום רשימה, ה-API החזיר שגיאה 422.

Jev לא רואה את שם השאלה. לקרוא לשדה needs_human לא מוסיף כלום, ולכן הדרישה צריכה להופיע בהוראות ובתיאור של כל אפשרות. כתבו תיאורים שמבדילים בין האפשרויות, ותנו ראיות במקום סיכומים: אילו קבצים זזו ומה התוכנית אמרה, לא "הבדיקות רצו".

from typesafe_sdk import Choice, Score, Noul

QUESTIONS = {
    "verdict": Choice(
        instructions="Decide what should happen to this code change.",
        criteria={
            "ship": "Tests passed, every changed path is in the plan, and nothing is irreversible or sensitive.",
            "return": "A reversible deviation from the plan, such as extra files or refactors outside "
                      "the planned paths, with nothing irreversible or sensitive.",
            "escalate": "Irreversible or sensitive: database migrations, authentication, permissions, "
                        "billing or deleted data. If both return and escalate apply, choose escalate.",
        },
    ),
    "blast_radius": Score(
        instructions="How much damage could this change do if it is wrong?",
        criteria=[
            "Contained: one module, easy to revert.",
            "Moderate: several modules or shared code.",
            "Severe: data, auth, billing or anything hard to undo.",
        ],
    ),
    "touches_auth": Noul(instructions="Does this change touch authentication or permissions?"),
}

צעד 4: מחליטים בקוד, עם ספים שאפשר לבדוק ב-Pull Request

סדר הבדיקות חשוב: precheck מעביר לאדם migration, קבצים מחוץ לתוכנית ו-diff שאינו מלא, עוד לפני קריאת API. הכללים האלה קודמים גם לבדיקות שנכשלו, כדי ששינוי רגיש לא יוסתר מאחורי החזרה לתיקון. אם אין סיבה להסלמה והבדיקות נכשלו, מחזירים לתיקון. decide מקבל גם את ה-state ובודק שוב את אותן מגבלות, כך שגם קריאה ישירה אליו לא מאפשרת למודל לעקוף אותן. אחר כך נבדקים ציוני הסיכון וההרשאות, ורק לבסוף ההסתברות של הפעולה.

שימו לב שהשער בודק את ההסתברות של הפעולה עצמה (probabilities["ship"]), וה-confidence לא נכנס להחלטה. ה-confidence מודד עד כמה ההתפלגות חדה, לא אם התשובה נכונה. הסף 0.88 הוא נקודת התחלה; את הסף האמיתי קובעים מדוגמאות מתויגות שלכם, כמו בשלב ההטמעה בהמשך.

from typesafe_sdk import TypeSafeClient

def precheck(state):
    """Known restrictions cannot be overridden by a model response."""
    if (state["has_migration"] or state["paths_outside_plan"]
            or not state["diff_complete"]):
        return "escalate"
    if not state["tests_passed"]:
        return "return"
    return None

def decide(state, result):
    early = precheck(state)
    if early:
        return early
    verdict = result.choices["verdict"]
    blast = result.scores["blast_radius"].score          # 0.0 to 2.0
    auth = result.nouls["touches_auth"].noul             # P(yes), 0.0 to 1.0

    # 1. Hard risk rules first: they beat any verdict, however confident.
    if blast >= 1.5 or auth >= 0.3:   # missing auth costs more than a false alarm
        return "escalate"
    # 2. The confident path, on the probability of the action itself.
    if verdict.choice == "ship" and verdict.probabilities["ship"] >= 0.88:
        return "ship"
    if verdict.choice == "escalate" and verdict.probabilities["escalate"] >= 0.6:
        return "escalate"
    # 3. Everything else goes back: the cheapest failure.
    return "return"

plan = ["app/search/ranking.py", "tests/test_ranking.py"]
diff = "def rank(results):\n-    return sorted(results, key=lambda r: r.score)\n+    return sorted(results, key=lambda r: (r.score, r.recency), reverse=True)"
state = build_state(plan, plan, lines_added=84, tests_exit_code=0, has_migration=False, full_diff=diff)

early = precheck(state)
if early:
    print(early)                  # decided by code, zero tokens
else:
    with TypeSafeClient() as client:
        result = client.system_one(state, QUESTIONS, model="jev-1.13.0")
        print(decide(state, result), result.model, result.usage.input_tokens)

מה אומרות ההסתברויות שחוזרות מ-Jev?

הרצנו את השער על חמישה תרחישים ב-5 באוקטובר 2026, מול jev-latest, והשדה model בתשובה החזיר jev-1.13.0. כל תרחיש הוא קריאה אחת עם שלוש שאלות. התוצאות בטבלה הן הפלט כפי שחזר, מעוגל לשתי ספרות. בתרחישי ה-migration והבדיקות שנכשלו precheck מחליט לבד; כאן שלחנו גם אותם ל-Jev רק כדי להראות מה המודל היה עונה. בהרצה חוזרת הערכים זזו בכמה מאיות, וההחלטות נשארו זהות. אלה מדידות הגרסה המקורית, לפני תיקון הכללים. בגרסה המתוקנת גם חריגה מהתוכנית עוברת לאדם בקוד, ו-diff חסר אינו נשלח להכרעת המודל. השינויים נבדקו מקומית עם תשובות מדומות; לא נמדדו מחדש טוקנים או הסתברויות מול API.

בגרסה הראשונה של הבדיקה התוכנית כללה קובץ בשם app/billing/invoice.py. Jev נתן לשינוי נקי לגמרי ציון סיכון 1.71, כי המילה billing מופיעה בדרגה החמורה, והכלל הקשה העביר אותו לאדם. זו התנהגות נכונה של השער, והיא מראה שהניסוח של הדרגות קובע את התוצאה לא פחות מהמודל.

התרחיש החשוב ביותר בטבלה הוא ה-diff שמוחק בדיקת הרשאה. ה-verdict אמר ship בהסתברות 0.75 עד 0.82 בשלוש הרצות, ורק שאלת ה-Noul הנפרדת זיהתה את ההרשאות (0.50 עד 0.58). עם סף של 0.5 השער היה עוצר את השינוי בקושי, ובהרצה אחת על הגבול ממש; לכן הסף להרשאות הוא 0.3, ושאר התרחישים קיבלו 0.02. זו הסיבה ששאלה ממוקדת וכלל קשה קודמים ל-verdict הכללי.

המאמר המקורי מתאר מצב הפוך שכדאי להכיר: ship מנצח ב-6 נקודות בלבד על return, וה-confidence הוא 0.18. מודל שפה היה כותב "נראה טוב לעלות" בלי להראות שההפרש הוא 6 נקודות ושה-confidence הוא 0.18. עם Jev רואים שהמרוץ צמוד ושולחים לאדם או אוספים עוד מידע.

• המלצת ship רק אחרי בדיקת ה-state: כל הקבצים בתוכנית, אין migration, ה-diff מלא והבדיקות עברו. בנוסף נדרשים הסתברות ship של 0.88 ומעלה, סיכון מתחת ל-1.5 והרשאות מתחת ל-0.3. ההמלצה אינה מחליפה אישור סוקר או CI.
• escalate לכל חריגה מהתוכנית, migration או diff חסר, בלי קשר לתשובת המודל. לאחר מכן חלים גם ספי הסיכון וה-escalate של המודל.
• כל השאר, כולל מרוץ צמוד בין שתי אפשרויות, חוזר לתיקון. אפשר להחליף את הענף הזה בבקשת אישור, במודל חזק יותר או באיסוף state נוסף, אבל זה דורש קוד נוסף.
• TypeSafe מאמנים את Jev בשיטה שהם קוראים לה RLCD כדי שההסתברויות יהיו מכוילות. זו טענת יצרן: כיול נמדד על קבוצות של החלטות, לא על תשובה בודדת, ולכן בודקים אותו על הנתונים שלכם.

האם Jev מבין עברית? בדקנו על פניות לקוח

התיעוד של TypeSafe אומר שאנגלית היא שפת האימון העיקרית ושם הדיוק הכי טוב, ושפות אחרות נתמכות אבל לא באותה רמה [docs.typesafe.ai/models, אוקטובר 2026]. לכן שלחנו ארבע פניות בעברית עם שאלת Choice באנגלית: החזר, משלוח, החלפה או אחר.

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

את אותה קריאה אפשר לשלוח גם ישירות ב-HTTP, בלי SDK. זה שימושי דרך צומת HTTP Request ב-n8n או מודול HTTP ב-Make. הקריאה שבדוגמה החזירה refund בהסתברות 1.00 ונספרו בה 392 טוקנים של קלט.

curl https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "ההזמנה 1182 הגיעה שבורה, אני רוצה את הכסף בחזרה",
    "questions": {
      "intent": {
        "type": "choice",
        "instructions": "What does the customer want?",
        "criteria": {
          "refund": "wants money back",
          "shipping": "asks where the order is",
          "exchange": "wants a different size or item",
          "other": "anything else"
        }
      },
      "urgent": { "type": "noul", "instructions": "Is this urgent?" }
    }
  }'

איך משלבים את Jev בתוך סוכן ובתוך תהליך אוטומציה?

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

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

לפי המאמר, Browser Use בונה בכל צעד רשימה חדשה של הכפתורים שמופיעים בדף ונותן ל-Jev לבחור מתוכה. העיקרון הזה מתאים לכל נתב: בונים את רשימת האפשרויות ממה שקיים עכשיו, למשל רק הנציגים שמחוברים כרגע, ולא מרשימה קבועה של אתמול. Choice מקבל עד 255 אפשרויות. מה שלא קיים עכשיו לא נכנס לרשימה, ומוסיפים אפשרות other כשהרשימה עלולה לא לכסות כל מקרה.

• סוללת שאלות אחת לכל אירוע, לא שרשרת של קריאות.
• רשימת אפשרויות דינמית שנבנית בכל קריאה ממה שקיים כרגע.
• שער לפני כל פעולה של סוכן: מה שמסוכן נחסם, מה שבטוח מאושר, בלי טוקנים של יצירה. LangChain מתארים את התבנית הזאת (נפתח בחלון חדש) כ-middleware שבודק כל קריאה לכלי.
• נתב מודלים: Jev בוחר את המודל הזול ביותר שסביר שיצליח במשימה, והמודל היקר מתעורר רק כשצריך.
• בדיקה עצמאית אחרי הפעולה: תשובה בטוחה לא מוכיחה שקובץ נכתב או שמשימה נפתחה. בודקים את התוצאה בנפרד, כמו בניטור אוטומציות.

כמה עולה החלטה של Jev בהשוואה למודל גדול?

החשבון פשוט. במדידה המקורית, לפני תיקון ה-state, השער צרך 613 עד 666 טוקנים של קלט לכל החלטה. ב-0.042 דולר למיליון טוקנים זה פחות מ-0.00003 דולר להחלטה, ו-10,000 החלטות עולות כ-0.27 דולר. המאמר המקורי מחשב לפי 1,000 טוקנים להחלטה ומגיע ל-0.42 דולר ל-10,000 החלטות, מול 300 דולר אם כל החלטה היא קריאה של 3 סנט למודל גדול.

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

המאמר של Hanako מביא גם דוגמאות מהימים הראשונים אחרי ההשקה, כפי שדווחו ברשת ולא נבדקו על ידינו: Browser Use מצאו טיסות בסוכן דפדפן תוך 7 שניות בעלות של 0.0039 דולר (לא כולל הזמנה בפועל), Hassan סיווג 1,018 מאמרי מחקר ב-0.08 דולר, Riley Brown סיווג 500 מיילים בשלושה סנט וחצי, ו-Alex Volkov הוריד סשן של כמעט מיליון טוקנים ל-86 אלף בעזרת סינון רלוונטיות. לתקציב אוטומציה מלא, מדדו עלות לכל משימה שהושלמה, לא לכל קריאה.

טעויות נפוצות ומתי Jev לא מתאים

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

שתי מגבלות קבועות של המוצר: אין כיוונון משקלים ללקוח (מתאימים את Jev רק דרך ה-state, ההוראות וההגדרות), והקלט הוא טקסט בלבד. כבר פורסמו בדיקות עצמאיות ראשונות, למשל ניסוי פתוח על 3,080 הודעות Banking77 (נפתח בחלון חדש), אבל הן באנגלית ועל סיווג בנקאי, ולכן הן לא מחליפות בדיקה על הנתונים שלכם.

Jev מפסיק להיות שימושי ברגע שמרחב התשובות לא ידוע מראש. אלה המקרים שבהם משאירים את העבודה למודל שפה או לקוד:

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

איך מטמיעים את Jev בלי ליצור תקלה חדשה?

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

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

1. בוחרים החלטה אחת, מוגבלת ובסיכון נמוך, שאפשר למנות את כל התשובות האפשריות שלה.
2. כותבים את ההגדרה של כל אפשרות לפני הקריאה הראשונה למודל.
3. אוספים 50 עד 200 דוגמאות אמיתיות עם התשובה הנכונה, כולל מקרים עמומים ומקרי קצה. המספר תלוי בכמה אפשרויות יש ובכמה הן קרובות זו לזו.
4. מריצים במצב צל לצד הלוגיקה הקיימת, בלי לשנות שום התנהגות, ורושמים כל אי הסכמה.
5. משרטטים דיוק מול הסתברות וקובעים את הספים מהעקומה, לא מפוסט ברשת.
6. מעבירים לאוטומציה רק את הענף הבטוח ביותר, ומשאירים אדם בלולאה או מודל חזק יותר על המקרים הלא בטוחים.
7. נועלים גרסת מודל (למשל jev-1.13.0 במקום jev-latest), ושומרים את השאלות, ההגדרות והספים בגרסאות, כדי שכל שינוי יהיה ניתן לשחזור ולהרצה מחדש של סט הבדיקה.

שאלות נפוצות

האם Jev מחליף את ChatGPT או Claude?

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

כמה עולה להשתמש ב-Jev?

לפי התיעוד הרשמי, 0.042 דולר למיליון טוקנים של קלט, ופלט בחינם (אוקטובר 2026). במדידת הגרסה המקורית של השער כל החלטה צרכה 613 עד 666 טוקנים, כלומר פחות מ-0.00003 דולר. העלות האמיתית תלויה באורך ה-state ובמספר השאלות, ולכן מודדים אותה על התהליך שלכם.

האם Jev עובד עם טקסט בעברית?

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

אפשר לחבר את Jev ל-n8n או ל-Make?

כן. Jev הוא קריאת HTTP רגילה עם מפתח API, ולכן צומת HTTP Request ב-n8n או מודול HTTP ב-Make מספיקים. שולחים את ה-state והשאלות כ-JSON, ומפצלים את התהליך לפי השדה choice או לפי ההסתברות שחוזרת. את המפתח שומרים ב-credentials של הכלי.

בשורה התחתונה

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