API

Jev — מודל לקבלת החלטות

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

המדריך המלא

POSThttps://api.ailoot.ai/v1/systemone

curl https://api.ailoot.ai/v1/systemone \
  -H "Authorization: Bearer $AILOOT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "עזרה! העברות הכספים אליי נכשלות כבר 3 ימים.",
    "questions": {
      "is_urgent": {
        "type": "noul",
        "instructions": "האם זה מבטא דחיפות?"
      }
    }
  }'

import json, os, urllib.request

body = {
    "model": "jev-latest",
    "state": "עזרה! העברות הכספים אליי נכשלות כבר 3 ימים.",
    "questions": {
        "is_urgent": {"type": "noul", "instructions": "האם זה מבטא דחיפות?"},
    },
}
req = urllib.request.Request(
    "https://api.ailoot.ai/v1/systemone",
    data=json.dumps(body).encode(),
    headers={"Authorization": "Bearer " + os.environ["AILOOT_API_KEY"],
             "Content-Type": "application/json"},
)
with urllib.request.urlopen(req, timeout=60) as resp:
    result = json.load(resp)
print(result["answers"]["is_urgent"]["noul"])  # 0.95

const resp = await fetch("https://api.ailoot.ai/v1/systemone", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.AILOOT_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "jev-latest",
    state: "עזרה! העברות הכספים אליי נכשלות כבר 3 ימים.",
    questions: {
      is_urgent: { type: "noul", instructions: "האם זה מבטא דחיפות?" },
    },
  }),
});
const result = await resp.json();
if (!resp.ok) throw new Error(`${resp.status} ${JSON.stringify(result)}`);
console.log(result.answers.is_urgent.noul); // 0.95

200 OK

{
  "model": "jev-1.13.0",
  "answers": {
    "is_urgent": {
      "type": "noul",
      "noul": 0.95
    }
  },
  "usage": { "input_tokens": 296, "output_tokens": 20 }
}

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

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

מה	בתמצית
מודל	`jev-latest` — כינוי לגרסה היציבה האחרונה של Jev; כרטיס בקטלוג
מתודה	`POST /v1/systemone`. זה אינו צ'אט: הפורמטים של OpenAI, Anthropic ו-Gemini אינם מתאימים ל-Jev. התשובה מגיעה בשלמותה, באובייקט JSON אחד
מה מתקבל כקלט	רק טקסט: מחרוזת, אובייקט JSON או מערך טקסטים. תמונות, שמע ווידאו יש להמיר תחילה לטקסט
הקשר	64K טוקנים לבקשה — state וכל השאלות יחד; state עם השאלה הארוכה ביותר — עד 32K
שפה	לפי TypeSafe, המודל מדויק ביותר באנגלית; הוא מקבל שפות אחרות, אך הדיוק נמוך יותר — בדקו על הנתונים שלכם
מחיר	קלט: $0.084 ל-1 מיליון טוקנים, פלט ללא תשלום

בקשה

אימות

Authorizationheaderחובה
מפתח Ailoot בפורמט Bearer sk-….

גוף הבקשה

modelstringחובה
jev-latest.
statestring | object | arrayחובה
מה להעריך: מחרוזת טקסט או JSON — פניית לקוח, רשומה ממסד נתונים, התכתבות או המצב הנוכחי של האפליקציה שלכם. אובייקט עם שמות שדות ברורים בדרך כלל נוח יותר ממחרוזת אחת.
questionsobjectחובה
שאלות. אתם בוחרים את המפתחות, והתשובות יגיעו תחת אותם מפתחות; המפתח אינו משפיע על התשובה — השאלה עצמה מוגדרת ב- instructions.
questions.*.typestringחובה
noul, choice או score — ראו בהמשך.
questions.*.instructionsstring | object | arrayחובה
השאלה עצמה. אפשר להעביר שאלה ארוכה עם נתונים כאובייקט: השאלה בשדה אחד והנתונים בשדות אחרים; הפנו לשדות בשמם בתוך backticks.
questions.*.criteriaobject | array
אפשרויות התשובה שונות בכל טיפוס: תיאורי "כן" ו"לא" ב-noul (רשות), מילון אפשרויות ב-choice ורשימת רמות מסודרת ב-score.

טיפוסי שאלות

טיפוס	מה נשאל	מה מוחזר
`noul`	האם הטענה נכונה: כן או לא	`noul` — ההסתברות ל"כן", מ-0 עד 1
`choice`	איזו מהאפשרויות הנתונות מתאימה	`choice`, `probabilities`, `confidence`
`score`	היכן נמצא state בסולם הרמות שלכם	`score`, `legend`, `probabilities`, `confidence`

אפשר לשלב טיפוסים שונים בבקשה אחת.

noul — כן או לא

השדה criteria הוא שדה רשות: אפשר לתאר בו מה משמעות "כן" (true) ו"לא" (false). התשובה noul — מספר מ-0 (לא) עד 1 (כן).

"is_urgent": {
  "type": "noul",
  "instructions": "האם זה מבטא דחיפות?",
  "criteria": {
    "true": "מצוין במפורש שהעניין רגיש לזמן",
    "false": "לא מובעת דחיפות"
  }
}

"is_urgent": {
  "type": "noul",
  "noul": 0.95
}

choice — בחירה בין אפשרויות

criteria — מילון "אפשרות ← תיאור"; אם אין צורך בתיאור, ציינו null. עד 255 אפשרויות. בתשובה choice — האפשרות הסבירה ביותר, probabilities — ההסתברות של כל אפשרות (הסכום הוא 1), confidence — רמת הביטחון מ-0 עד 1.

"department": {
  "type": "choice",
  "instructions": "איזה צוות צריך לטפל בזה?",
  "criteria": {
    "billing": "תשלומים, הפקת חשבוניות, החזרים",
    "technical": "באגים, השבתות, אינטגרציות",
    "sales": "תמחור, שדרוגים, לקוחות חדשים"
  }
}

"department": {
  "type": "choice",
  "choice": "billing",
  "probabilities": { "billing": 0.88, "technical": 0.12, "sales": 0.0 },
  "confidence": 0.81
}

score — הערכה בסולם

criteria — רמות מהנמוכה לגבוהה, לא יותר מ-10 (TypeSafe ממליצה על לפחות שתיים). בתשובה score — ערך המשוקלל לפי הסתברויות הרמות (הוא עשוי להיות בין רמות), legend — מספר הרמה והתיאור שלה, probabilities וכן confidence. לפי TypeSafe, score מתאים להשוואה מול סף, אך לא לקבלת מספר מדויק בין הרמות.

"frustration": {
  "type": "score",
  "instructions": "עד כמה הלקוח מתוסכל?",
  "criteria": ["רגוע", "מתוסכל", "כועס מאוד"]
}

"frustration": {
  "type": "score",
  "score": 1.05,
  "legend": { "0": "רגוע", "1": "מתוסכל", "2": "כועס מאוד" },
  "probabilities": { "0": 0.0, "1": 0.95, "2": 0.05 },
  "confidence": 0.92
}

תשובה

modelstring
גרסת המודל שענתה. הכינוי jev-latest עובר עם הזמן לגרסאות חדשות: אם התאמתם את ספי confidence לגרסה מסוימת, עקבו אחר השדה הזה.
answersobject
תשובה אחת לכל שאלה, תחת אותם מפתחות. לכל תשובה יש type, וב-choice וב-score יש גם confidence.
usageobject
input_tokens וכן output_tokens. רק טוקני הקלט מחויבים.

כמה שאלות בבקשה אחת

שלחו את כל השאלות לאותו state בבקשה אחת: הן נבדקות במקביל וה-state מועבר פעם אחת. לפי TypeSafe, בדוגמה שלה עם 13 שאלות, בקשה משותפת אחת הייתה זולה פי 12.2 ומהירה פי 10 לעומת 13 בקשות נפרדות שנשלחו בזו אחר זו, עם אותן תשובות.

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

{
  "model": "jev-latest",
  "state": "עזרה! העברות הכספים אליי נכשלות כבר 3 ימים.",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "איזה צוות צריך לטפל בזה?",
      "criteria": {
        "billing": "תשלומים, הפקת חשבוניות, החזרים",
        "technical": "באגים, השבתות, אינטגרציות",
        "sales": "תמחור, שדרוגים, לקוחות חדשים"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "עד כמה הלקוח מתוסכל?",
      "criteria": ["רגוע", "מתוסכל", "כועס מאוד"]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "האם זה מבטא דחיפות?"
    }
  }
}

מתי מתאים

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

מתי אינו מתאים

צ'אט, תשובות למשתמש ויצירת טקסט או קוד. Jev אינו כותב טקסט — לשם כך יש מודלי טקסט.
מודל עבור Claude Code, Cursor וסוכנים אחרים. אי אפשר להציב jev-latest במקום מודל הסוכן: הסוכן זקוק למודל שכותב טקסט וקורא לכלים. אפשר לקרוא ל-Jev מהקוד שהסוכן כותב עבורכם.
חישובים אריתמטיים, ספירה והשוואת תאריכים. לפי TypeSafe, אמין יותר לבצע זאת בקוד ולבקש מהמודל רק את החלק הסמנטי — למשל, לחלץ רכיבי תאריך באמצעות choice.
תמונות, שמע ווידאו. המודל מקבל רק טקסט — המירו נתונים כאלה לטקסט מראש.

מחיר

רק טוקני הקלט מחויבים — השדה usage.input_tokens בתשובה: $0.084 ל-1 מיליון. טוקני הפלט אינם מחויבים.

הבקשה שבדוגמה בעמוד הזה (296 טוקני קלט) עולה פחות מ-$0.0001.

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

מגבלות

מה	מגבלה
הבקשה כולה: state וכל השאלות	64K טוקנים
state עם השאלה הארוכה ביותר	32K טוקנים
מספר האפשרויות ב-choice אחד	עד 255
מספר הרמות ב-score אחד	מ-2 עד 10
קלט	רק טקסט: מחרוזת, אובייקט JSON או מערך טקסטים

מגבלות המודל מוצגות לפי TypeSafe. מגבלות המפתח והיתרה שלכם חלות כמו בכל מודל של Ailoot: שגיאות ומגבלות.

שגיאות

שגיאות מגיעות בפורמט הכללי של Ailoot API: קוד, הודעה ברורה ו-Request ID. השגיאות הנפוצות ביותר במתודה הזאת הן:

קוד	מתי	מה לעשות
400 `invalid_request`	גוף הבקשה לא עבר בדיקה: חסרים state, model או questions, ה-type אינו מוכר, ל-choice יש יותר מ-255 אפשרויות או ל-score יותר מ-10 רמות	תקנו את הבקשה לפי הודעת השגיאה: ללא תיקון היא תידחה שוב
400 `context_length_exceeded`	state והשאלות יחד חורגים ממגבלת האורך של המודל	סננו את state בקוד והשאירו רק את הנתונים הנדרשים לשאלות
401 `invalid_api_key`	המפתח חסר או אינו תקין	העבירו את המפתח בכותרת Authorization
402 `insufficient_balance`	אין די יתרה פנויה לשמירת הרזרבה	הוסיפו כסף ליתרה
404 `model_not_found`, `unsupported_endpoint`	המזהה שגוי או שהקריאה למודל נעשתה במתודה לא מתאימה, למשל דרך /v1/chat/completions	יש לקרוא ל-jev-latest רק דרך POST /v1/systemone
429 `rate_limit_exceeded`	יותר מדי בקשות	המתינו את מספר השניות שבכותרת Retry-After ונסו שוב
503 `model_overloaded`, `model_unavailable`	המודל עמוס זמנית או אינו זמין	אם X-Should-Retry: true — נסו שוב לאחר מספר השניות של Retry-After; אם false — בדקו תחילה את ה-Request ID בהיסטוריה
504 `model_timeout`	המודל לא ענה בזמן	אל תשלחו את הבקשה מחדש לפני שבדקתם את ה-Request ID בהיסטוריה

רשימת הקודים המלאה נמצאת בעמוד שגיאות ומגבלות.

נשארו שאלות? שלחו Request ID ותיאור — נעזור לברר.פנייה לתמיכה