Jev bilan sun’iy intellektdan yanada oqilona foydalaning

Kirish: LLMlardan haddan tashqari ko‘p foydalanayapmizmi?

So‘nggi bir necha yil davomida AI ilovalarini ishlab chiqish deyarli to‘liq LLMlar (Katta til modellari) atrofida aylandi. Foydalanuvchi savol berganda, uni LLMga yuboramiz; hujjatni tahlil qilganda, uni LLMga yuboramiz; elektron xatlarni tasniflaganda, ularni LLMga yuboramiz; Agent keyingi harakatini belgilashi kerak bo‘lganda esa, yana LLMdan so‘raymiz.

LLMlar nihoyatda kuchli. Ular tabiiy tilni tushunishi, matn yozishi, kod yaratishi, murakkab mazmunni umumlashtirishi va u haqida xulosa yuritishi mumkin. Muammo shundaki, biz LLMlardan ular zarur bo‘lmagan joylarda ham foydalanayapmiz.

Masalan, mijozdan quyidagi elektron xatni olganimizni tasavvur qiling.

"I was charged twice. Please refund the duplicate payment as soon as possible."

Agar biz bilmoqchi bo‘lgan yagona uchta narsa quyidagilardan iborat bo‘lsa-chi?

• Bu so‘rov Billing yoki Technical Support uchunmi?

• So‘rov shoshilinchmi?

• Mijozning norozilik darajasi qanday?

An’anaviy LLMdan foydalanib, quyidagicha so‘rashimiz mumkin.

Analyze the following customer message.

1. Determine the category.
2. Determine whether it is urgent.
3. Evaluate the customer's frustration level.

Return the result as JSON.

LLM, albatta, bu muammoni hal qila oladi. Ammo bizga aslida uzun tushuntirish emas, balki quyidagiga o‘xshash qiymatlar kerak.

category = billing
urgent = 0.91
frustration = 1.7

Boshqacha aytganda, bizga Generation emas, Decision kerak. Shunga qaramay, bu kichik qaror uchun umumiy maqsadli generativ modelni chaqiramiz, prompt yozamiz, undan JSON formatidan foydalanishni so‘raymiz, natijani parse qilamiz, sxemani tekshiramiz va hatto istisno holatlarni ham qayta ishlaymiz.

2026-yil sentabrida TypeSafe AI tomonidan chiqarilgan Jev aynan shu nuqtadan boshlanadigan modeldir. TypeSafe Jevni o‘zining birinchi System One Modeli sifatida ta’riflaydi. Kirish sifatida tabiiy til yoki ilova holatidan foydalanib, uzun jumlalar yaratish o‘rniga, u dastur bevosita ishlata oladigan tiplashtirilgan ehtimolli qarorni qaytaradi — boshqacha aytganda, tip bilan belgilangan, ehtimolga asoslangan hukmni.

Ushbu maqolada muhokama qilmoqchi bo‘lgan asosiy fikrim oddiy. Gap LLMlardan foydalanmasligimiz kerakligida emas; gap LLMlarni ularga ehtiyoj bo‘lmagan qarorlarni hal qilishga majburlamaslikda. Kelgusida AI ilovalarini yaxshi quradigan dasturchilar eng kuchli modellardan foydalanadiganlar emas, balki qaysi muammolarni AI ning qaysi turlariga topshirish kerakligini ajrata oladiganlar bo‘lishi ehtimol.

1. Jev nima?

Jev — TypeSafe AI tomonidan chiqarilgan birinchi System One Modelidir. TypeSafe bu nomni Daniel Kahnemanning 『Tez va sekin fikrlash』 asarida tasvirlangan System 1 tushunchasidan olganini tushuntiradi. Bu inson tafakkurini tez va intuitiv System 1 hamda sekin, mulohazali System 2 ga ajratish g‘oyasidan ilhomlangan. TypeSafe shuningdek, Jev nomi iqtisodchi William Stanley Jevons nomidan olinganini ta’kidlaydi.

Odatdagi LLMni ancha soddalashtirsak, uni quyidagicha ifodalash mumkin.

Input
  ↓
LLM
  ↓
Text Generation
  ↓
"Based on the information provided,
 this customer seems to..."

Jev esa, aksincha, quyidagiga yaqinroq.

State
  ↓
Jev
  ↓
Typed Decision
  ↓
billing : 0.97
urgent : 0.91

TypeSafe terminologiyasidan foydalansak, Jev — o‘ziga xos "frontier-intelligence function call". Boshqacha aytganda, u AIdan odamlar uchun suhbatdosh sifatida emas, balki dasturlash primitiv elementi sifatida foydalanish yondashuvini qo‘llaydi.

unstructured state
        ↓
      Jev
        ↓
typed probabilistic decisions

Bu farq ko‘rinishidan muhimroq. LLMning yakuniy iste’molchisi ko‘pincha inson bo‘ladi, Jev chiqishining iste’molchisi esa asosan dasturdir.

LLM → Text → Human
Jev → Decision → Code

Shu sababli Jevning maqsadi ta’sirchan jumlalar yaratish emas, balki dasturga keyingi qanday harakatni bajarishni belgilash imkonini berishdir.

2. Jev taqdim etadigan qarorlarning uch turi

2.1 Choice

Choice bir nechta nomzod orasidan bitta variantni tanlaydi. Masalan, mijoz so‘rovlarini quyidagicha tasniflaymiz, deb tasavvur qiling.

billing
technical
sales
other

Jevdan "Bu so‘rov bilan qaysi bo‘lim shug‘ullanishi kerak?" deb so‘rasangiz, har bir variantning ehtimoli bilan birga tanlangan elementni olishingiz mumkin.

choice = billing

billing 0.93
technical 0.04
sales 0.01
other 0.02

Choice so‘rovlarni tasniflash, hujjatlarni tasniflash, Agent Tool tanlash, Model Routing, Intent Detection va event Routing kabi muammolar uchun ayniqsa foydalidir.

2.2 Score

Score bir nechta tartiblangan mezonni belgilaydi va ular orasida ball hisoblaydi. Masalan, mijozning norozilik darajasini quyidagicha belgilash mumkin.

0 = Calm
1 = Frustrated
2 = Very Angry

Keyin "Mijoz qanchalik norozi?" deb so‘raymiz. Natija 0, 1 yoki 2 qiymatlaridan biri bo‘lishi shart emas; u score = 1.63 kabi oraliq qiymat bilan ifodalanishi mumkin.

Shu sababli Score shoshilinchlik, xavf, aloqadorlik, sifat, ustuvorlik, mijozning norozilik darajasi va hujjatning muhimligi bilan bog‘liq muammolar uchun juda mos keladi.

if score > 1.5
    → priority queue
else
    → normal queue

2.3 Noul

Eng notanish atama — Noul. Noul imlo xatosi emas; bu TypeSafe o‘zining amaldagi API interfeysida ishlatadigan primitiv nomidir. Sodda qilib aytganda, u Yes/No xususiyatidagi savollar uchun Yes ehtimolini qaytaradi.

Does this customer require an immediate response?

→ 0.92

Ehtimollik qiymatining oddiy Boolean qiymatidan foydaliroq bo‘lishiga sabab shundaki, u ilova siyosatlarini yanada nozik darajada belgilash imkonini beradi.

0.90 이상      → 자동 처리
0.60 ~ 0.90   → 사람이 확인
0.60 미만      → 처리하지 않음

Boshqacha aytganda, AI hamma narsani o‘zi hal qilishi o‘rniga, AI ehtimollikni taqdim etadi, haqiqiy siyosat esa kod orqali belgilanadi. Jevni dasturchi nuqtayi nazaridan ayniqsa qiziqarli qiladigan narsa ham shu.

3. Xo‘sh, LLMlar va Jev qanday farq qiladi?

Avvalo, bitta muhim noto‘g‘ri tushunchaga aniqlik kiritishimiz kerak. Farqni "LLMlar faqat stringlarni qaytaradi, strukturali qiymatlarni esa faqat Jev qaytaradi" deb soddalashtirish to‘g‘ri bo‘lmaydi. Zamonaviy LLMlar Structured Output, JSON Schema, Function Calling, Tool Calling va boshqa imkoniyatlarni qo‘llab-quvvatlaydi. LLM yordamida Choice kabi interfeys yaratish mutlaqo mumkin.

Farq modelning maqsadi va tuzilishidadir. Jev boshidanoq cheklangan formatda hukmlarni tez qaytaradigan qaror qabul qilish primitiv elementi bo‘lishga yo‘naltirilgan.

Kategoriya	LLM	Jev
Asosiy maqsad	Generation, suhbat, mulohaza yuritish	Decision
Namunaviy chiqish	Matn / Kod / JSON	Choice / Score / Noul
Chiqish moslashuvchanligi	Juda yuqori	Oldindan belgilangan diapazon
Mos iste’molchilar	Odamlar + dasturlar	Asosan dasturlar
Erkin shakldagi gap yozish	Juda kuchli	Mos emas
Tasniflash/baholash	Mumkin	Asosiy maqsad
Natijalar ehtimoli	Ko‘pincha alohida loyihalashni talab qiladi	Model interfeysining markaziy qismi
Agent tomonidan qabul qilinadigan kichik qarorlar	Mumkin, ammo nisbatan og‘ir bo‘lishi mumkin	Juda mos
Ijodiy ish/xulosa chiqarish/kod generatsiyasi	Mos	Mos emas

Sodda qilib aytganda, LLM biror narsa yaratadigan AI bo‘lsa, Jev nima qilish kerakligini belgilaydigan AI’ga yaqinroq. Albatta, LLM’ning amaldagi roli bundan ancha keng, biroq rollarni shu darajada ajratishning o‘zi ham ilova arxitekturasini loyihalashda juda foydali.

4. Jev e’tibor qozonayotgan eng katta sabab: tezlik va xarajat

AI xizmatini ishga tushirganda, dastlab faqat modelning intellektiga e’tibor qaratish odatiy holdir. Biroq xizmat kengaygani sari kechikish, xarajat, o‘tkazuvchanlik va ishonchlilik kabi ekspluatatsion xususiyatlar muhim bo‘lib boradi. Ayniqsa, Agent bitta foydalanuvchi so‘rovini qayta ishlash uchun AI’ni bir necha marta chaqirishi mumkin.

현재 화면 분석
    ↓
어떤 행동을 할지 판단
    ↓
버튼 선택
    ↓
다음 화면 확인
    ↓
다음 행동 판단
    ↓
...

Bitta vazifani bajarish uchun 10, 20 yoki 50 ta qaror qabul qilinishi mumkin. Agar har bir qaror uchun yuqori unumdor LLM chaqirilsa, token xarajati va kechikish yig‘ilib boradi.

TypeSafe tomonidan 2026-yil sentyabr oyida e’lon qilingan Jev narxi o‘sha paytda 1 million kiruvchi token uchun $0.042 edi, chiquvchi tokenlar uchun esa alohida to‘lov olinmagan. Kompaniya e’lon qilgan javob vaqti diapazoni taxminan 70–500ms ni tashkil qilgan. Biroq bu raqamlar muhit, kiritilgan matn uzunligi, tarmoq va ish yuklamasiga qarab o‘zgarishi mumkin, shuning uchun ularni har qanday vaziyatda aynan bir xil unumdorlikka erishiladi, deb talqin qilmaslik kerak.

Shunga qaramay, tarkibiy farq aniq. Agar ilovaga faqat billing, 0.92 va 1.71 kabi qiymatlar kerak bo‘lsa, uzun izohlar yaratmaydigan model tabiiyroq tanlov bo‘lishi mumkin. Keraksiz chiqishni yaratmaslikning o‘zi ham optimallashtirishdir.

5. Jev’dan amalda qayerda foydalanish mumkin?

Jev chiqarilganidan beri elektron pochta tasnifi, Browser Agent, reklama tahlili, ilmiy maqolalarni tasniflash va fayllarni avtomatik tartibga solish kabi turli tajribalar paydo bo‘ldi. Quyidagi xarajat va tezliklar har bir demoni yaratuvchilari tomonidan o‘z muhitlarida e’lon qilingan natijalardir, shuning uchun ularni bir xil sharoitlarda taqqoslangan standart benchmarklar sifatida qabul qilmaslik kerak.

5.1 500 ta elektron xatni avtomatik tasniflash

Ommaga ochiq demolardan birida 500 ta elektron xat kategoriya, shoshilinchlik, javob kerakligi va boshqa mezonlar bo‘yicha tasniflangan. Yaratuvchi Jev xarajati taxminan $0.035 bo‘lganini ma’lum qilgan.

Inbox
  ↓
Jev
  ├─ 중요?
  ├─ 답장 필요?
  ├─ 업무 관련?
  └─ 긴급?
  ↓
Priority Queue
  ↓
필요한 메일만 LLM에게 전달
  ↓
답장 초안 생성

Bu tuzilmaning kaliti LLM’ni olib tashlashda emas, balki undan faqat LLM haqiqatan zarur bo‘lgan joylarda foydalanish uchun chaqiruvlar sonini kamaytirishdadir.

5.2 Browser Agent

Browser Agent Jev xususiyatlarini tushunish uchun yaxshi misoldir. Ommaviy loyihalardan birida veb-sahifaning DOM’i tahlil qilingan va Jev keyingi amalni tanlash uchun sozlangan.

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

Qizig‘i shundaki, LLM faqat matnni haqiqatan yaratish kerak bo‘lgan TYPE_TEXT kabi holatlarda ishlatiladi.

Decision        → Jev
Text Generation → LLM
Browser Operation→ Code

Ommaga ochiq Google Flights qidiruv demosida Tsyurixdan Londonga safar uchun umumiy bajarilish vaqti taxminan 7.1 soniya, Jev xarajati esa taxminan $0.0039 deb ko‘rsatilgan. Bu misol butun Agent bitta ulkan LLM bo‘lishi shart emasligini yaqqol namoyish etadi.

5.3 724 ta reklamani tahlil qilish

Yana bir ommaviy demolardan birida 37 ta brendga tegishli 724 ta reklama Hook, Format, Offer, CTA va Awareness Stage kabi mezonlar bo‘yicha tahlil qilingan. Yaratuvchi taxminan 40 soniyalik natija va taxminan $0.09 Jev xarajatini ma’lum qilgan.

AI tomonidan beriladigan bahoning birlik narxi yetarlicha past bo‘lganda, ish jarayonlari faqat ayrim namunalarni ko‘rib chiqishdan mavjud barcha ma’lumotlarni tahlil qilishga o‘tishi mumkin. Bu oddiy xarajatlarni kamaytirishdan ko‘ra muhimroq o‘zgarishdir, chunki ilgari xarajat sababli urinib ko‘rilmagan muammolarni hal qilish imkonini beradi.

5.4 1 018 ta AI maqolasini tasniflash

Shuningdek, AI bilan bog‘liq 1 018 ta maqola 24 ta mavzuga tasniflangan ommaviy holat ham mavjud. Bu holatda LLM maqolalarni xulosa qilish bilan shug‘ullangan, Jev esa oldindan belgilangan taksonomiya bo‘yicha tasniflashni bajargan.

Paper
   ↓
LLM
   ↓
Summary
   ↓
Jev
   ↓
24개 Topic 중 하나 선택

Yaratuvchi Jev tasniflash xarajati taxminan $0.08, har bir maqola uchun median kechikish esa taxminan 256ms bo‘lganini ma’lum qilgan. Biroq umumiy pipeline uchun LLM yordamida xulosa chiqarishga alohida xarajat ham ketgan. Bu holat ko‘rsatgan asosiy jihat shuki, har bir AI muammosini bitta model yordamida hal qilish shart emas.

6. Jev’dan kodda foydalanamiz

TypeSafe Python va JavaScript/TypeScript SDK’larini chiqargan. Python SDK paketi typesafe-sdk deb nomlanadi, rasmiy misolda esa state va questions qiymatlari system_one() funksiyasiga uzatiladi.

uv add typesafe-sdk

export TYPESAFE_API_KEY="..."

Quyida mijozlar so‘rovlarini tasniflaydigan hamda ularning shoshilinchligi va norozilik darajasini aniqlaydigan misol keltirilgan.

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

state = {
    "message": "I was charged twice. "
               "Please refund the duplicate payment today."
}

questions = {
    "category": Choice(
        instructions="What is this customer request about?",
        criteria={
            "billing": "Payment, refund or charge related issue",
            "technical": "Technical problem",
            "sales": "Sales or pricing inquiry",
            "other": "Anything else"
        }
    ),

    "urgent": Noul(
        instructions="Does this request require urgent attention?"
    ),

    "frustration": Score(
        instructions="How frustrated does the customer appear?",
        criteria=["Calm", "Frustrated", "Very angry"]
    )
}

with TypeSafeClient() as client:
    response = client.system_one(
        state=state,
        questions=questions
    )

category = response.choices["category"].choice
urgent = response.nouls["urgent"].noul
frustration = response.scores["frustration"].score

Konseptual jihatdan natijalar category = billing, urgent = 0.94 va frustration = 1.32 bo‘lsin. Shundan so‘ng oddiy dastur kodi yordamida siyosatlarni qo‘llash mumkin.

if urgent > 0.90:
    priority = "HIGH"
elif urgent > 0.60:
    priority = "MEDIUM"
else:
    priority = "NORMAL"

Bu yerda muhim jihat Jev’ga biznes siyosatlarini ham belgilashga ruxsat bermaslikdir. Jev qaror qabul qilish uchun zarur signallarni taqdim etadi, amaldagi siyosatlar esa kod orqali boshqariladi.

AI   → Probability
Code → Business Rule

7. TypeScript’da bu yanada aniqroq

TypeScript SDK’da qaytariladigan natija shaklini savol turiga qarab ham aniq ajratish mumkin. Misol quyidagicha.

import { choice, noul, score, TypeSafeClient }
  from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

const result = await client.systemOne({
  state: {
    message: "I was charged twice. " +
             "Please refund the duplicate payment today."
  },
  questions: {
    category: choice(
      "Which department should handle this?",
      {
        billing: "Payment and refund issues",
        technical: "Product or technical issues",
        sales: "Pricing and sales",
        other: "Anything else"
      }
    ),
    urgent: noul(
      "Does this request need urgent attention?"
    ),
    frustration: score(
      "How frustrated is the customer?",
      ["Calm", "Frustrated", "Very angry"]
    )
  }
});

Dasturchi nuqtayi nazaridan Typed Question → Jev → Typed Decision → Application tuzilmasi String Prompt → AI → String Response → Parsing → Validation → Application tuzilmasidan ancha tabiiyroq tuyulishi mumkin.

8. Java dasturchilari undan qanday foydalanishi mumkin?

TypeSafe tomonidan rasman chiqarilgan asosiy SDK’lar hozircha Python va JavaScript/TypeScript uchun mo‘ljallangan, Java uchun esa hamjamiyat SDK’lari va Spring AI integratsiya loyihalari paydo bo‘lmoqda. Biroq Jev API’ning o‘zi REST’dan foydalangani sababli Java uchun alohida SDK bo‘lishi shart emas.

Asosiy API POST /v1/systemone shakliga ega, so‘rovlarda esa model, state va questions qiymatlari bo‘ladi. Java dasturchilari uni HttpClient, Jackson, Spring RestClient yoki WebClient yordamida osonlik bilan o‘rab olishlari mumkin.

interface DecisionService {
    TicketDecision classify(CustomerMessage message);
}

record TicketDecision(
        String category,
        double urgentProbability,
        double frustrationScore
) {}

Jev API chaqiruvlarini to‘g‘ridan-to‘g‘ri ilova kodi bo‘ylab tarqatish o‘rniga, yuqorida ko‘rsatilgandek abstraksiya qo‘shilsa, ilova ichkarida Jev yoki boshqa Decision Model ishlatilayotganini bilishi shart bo‘lmaydi. Bu kelajakda model yoki provayderni almashtirishda ham foydalidir.

9. Jev’dan foydalanishning eng yaxshi usuli: LLM’ni yo‘q qilishga urinmang

Jev va LLMlar raqobatchilardan ko‘ra, turli rollarga ega vositalardir. Masalan, mijozning shikoyatiga hamdardlik bildirish bilan birga, pulni qaytarish bo‘yicha muloyim yo‘riqnoma xatini yozish jumlalar yaratishni talab qiladi, shuning uchun bunda LLM mos keladi. Boshqa tomondan, «Bu mijozga javob berish kerakmi?» va «Bu murojaat qaysi jamoaga yuborilishi kerak?» kabi savollar uchun Jev ko‘proq mos keladi.

Decision   → Jev
Generation → LLM
Execution  → Code
Review     → Human

Aynan shu kombinatsiya Jevni eng qiziqarli vositaga aylantiradi. Har bir vosita o‘zi eng yaxshi bajaradigan rolni o‘z zimmasiga oladi.

10. Ko‘p agentli davrda model yo‘naltirish yanada muhimlashadi

Kelajakda agent tizimlari tobora murakkablashadi. Bitta Agent hamma ishni bajarishi o‘rniga, ular bir nechta Tool va Modellarni birlashtirishi ehtimolga yaqin.

User Request
     ↓
Jev
     ↓
Task Complexity
     │
     ├── Simple → Small Model
     ├── Medium → General LLM
     └── Complex → Frontier Model

Har bir savolni eng qimmat va kuchli modelga yuborish shart emas. Buning o‘rniga AI tizimining o‘zini avval «Bu muammo qiyinmi?», «Qidiruv kerakmi?», «Inson tasdig‘i talab qilinadimi?» va «Buni yuqori unumdorlikdagi modelga yuborish zarurmi?» degan savollarni aniqlaydigan qilib loyihalash mumkin.

Ilgari dasturchilar Class, Method, Database, API, Transaction va Eventlarni loyihalashgan. AI davrida esa ular Decision Architecture’ni ham loyihalashi kerak. Boshqacha aytganda, qaysi qarorlar kod tomonidan, qaysilari Jev tomonidan, qaysilari LLM tomonidan, qaysilari esa inson tomonidan qabul qilinishi kerakligini ajrata bilish muhim bo‘ladi.

11. AI’ni bitta ulkan funksiyaga aylantirmaylik

LLMdan foydalanishda keng tarqalgan yondashuv — tasniflash, baholash va yo‘naltirishdan tortib generatsiyagacha bo‘lgan hamma narsani bitta ulkan prompt ichiga joylashtirishdir. Avvaliga bu qulay, ammo tizim murakkablashgani sari xatolik qayerda yuz berganini aniqlash qiyinlashadi, siyosatdagi o‘zgarishlar va test o‘tkazish ham mushkullashadi.

isSpam()
    ↓
category()
    ↓
urgency()
    ↓
needsReply()
    ↓
route()
    ↓
generateReply()

Bundan oldingi baholash bosqichini Jev, route()ni kod, faqat yakuniy generateReply()ni esa LLM bajarishi mumkin. Bu tuzilmaning afzalligi faqat uning arzonroq va tezroq ekanida emas, balki debugging va testlashni ham osonlashtirishidadir.

12. Ammo Jev ham xato qilishi mumkin

Jev tiplangan chiqish taqdim etishi uning baholari har doim aniq bo‘ladi degani emas. Masalan, «Bu xat phishing xatimi?» degan savolda javobni to‘g‘ri formatda qaytarish va uning haqiqatan ham phishing ekanini aniq belgilash — butunlay boshqa masalalardir.

Schema correctness ≠ Semantic correctness

Shu sababli ehtimollik qiymatlarini ilova siyosatlariga kiritish muhim.

High Confidence   → Automatic Action
Medium Confidence → Strong LLM / Additional Check
Low Confidence    → Human Review

Ehtimolliklarni taqdim etadigan modelning haqiqiy afzalligi AI’ning ishonch bilan javob berishida emas, balki dasturiy ta’minot noaniqlikni o‘z siyosatlariga singdira olishidadir.

13. Jevdan qayerda foydalanmaslik kerak

Jev e’tibor qozonayotgani uni hamma joyga qo‘shish yaxshi dizayn degani emas. LLMlar hisobotlar, xatlar va bloglar kabi hujjatlarni yozish; uzun hujjatlarni umumlashtirish; kod yaratish; xatolar sababini tushuntirish; shuningdek, murakkab va ochiq strategik muammolarni hal qilish uchun ancha mos keladi.

Aksincha, mumkin bo‘lgan javoblar doirasi nisbatan cheklangan muammolarda Jevdan foydalanishni jiddiy ko‘rib chiqish kerak. Masalan, biror narsa A yoki B ekanini, qaysi Categoryga mansubligini, uning qanchalik muhimligini, qaysi Tool ishga tushirilishi kerakligini, qaysi Modelga yuborilishi lozimligini va inson tasdig‘i talab qilinadimi-yo‘qmi aniqlashda.

14. Ishlab chiquvchi nuqtayi nazaridan Jevning eng katta qiymati

Agar Jevning qiziqarliligi sababini shunchaki uning token narxi pastligida deb hisoblasangiz, mohiyatni ko‘zdan qochirishingiz mumkin. Muhimroq o‘zgarish — AI dasturlarga qanday kirib kelayotganidir.

기존 방식
Application → Prompt → LLM → Text

Decision Model 방식
Application State → Decision Primitive → Probability → Application Logic

Keyingi tuzilma dasturchilarga tanish. Biz o‘nlab yillardan beri if (condition) { execute(); } kabi kodlar yozib kelmoqdamiz. Jevni ilgari kodda ifodalash qiyin bo‘lgan noaniq shartlarni dasturlarga olib kiradigan vosita sifatida ko‘rish mumkin.

if (jev("Is this request urgent?") > 0.9) {
    escalate();
}

15. «AI’dan yaxshi foydalanish» ma’nosi ham o‘zgarmoqda

Hozirgacha odamlar AI’dan yaxshi foydalanuvchi haqida gapirganda, ko‘pincha Prompt Engineering’ni yaxshi biladigan kishini nazarda tutishgan. Biroq Agentlar va AI Automation ko‘paygani sari muhim bo‘lgan qobiliyatlar ham o‘zgarishi mumkin.

• Bu muammoni deterministik kod yordamida hal qilish mumkinmi?

• AI bahosi haqiqatan ham zarurmi?

• Agar AI kerak bo‘lsa, u generatsiya uchunmi yoki baholash uchunmi?

• Kichik model yetarlimi?

• Frontier Model zarurmi?

• Agar ehtimollik past bo‘lsa, bu masalani kimga eskalatsiya qilish kerak?

• Qaysi qarorlar albatta inson tomonidan tasdiqlanishi kerak?

Boshqacha aytganda, bitta modeldan yaxshi foydalanishdan ko‘ra, umuman AI orkestratsiyasini loyihalash muhimroq bo‘ladi.

16. Tavsiya etiladigan AI arxitekturasi

Buni quyidagi bitta oddiy tamoyil bilan umumlashtirish mumkin.

LLM   → 생성합니다.
Jev   → 판단합니다.
Code  → 실행합니다.
Human → 중요한 결정을 검토합니다.

Bu tuzilmada hech bir muayyan model butun tizim ustidan hukmronlik qilmaydi. Har bir vosita o‘zi eng yaxshi bajaradigan ishni bajaradi.

Xulosa: eng kuchli AI’dan emas, eng mos AI’dan foydalanaylik

Jev hali juda yangi texnologiya. TypeSafe Jevni 2026-yil sentabrida ommaga taqdim etdi, uning ekotizimi, APIlari va vositalari ham tez o‘zgarib bormoqda. Shu sababli uning joriy narxlari, unumdorligi yoki SDK holati uzoq muddat davomida o‘zgarmay qoladi deb hisoblamasligingiz kerak.

Shunday bo‘lsa-da, Jev ko‘ndalang qo‘yayotgan savollar juda muhim. Nega biz har bir AI muammosini bitta LLM yordamida hal qilishga urinib ko‘ramiz?

LLMlar ajoyib vositalardir. Biroq xatni qaysi jildga yuborishni hal qilish uchun shunchaki uzun jumla yaratishning hojati yo‘q. Agent keyingi bosqichda qaysi tugmani bosishi kerakligini aniqlash uchun har safar ulkan Frontier Modelning uzoq mulohazasini kutish ham shart emas.

Agar muammo oldindan belgilangan nomzodlar to‘plamidan bittasini tanlashni talab qilsa, Choice’dan foydalanishingiz mumkin. Ha yoki yo‘q tarzidagi baho kerak bo‘lsa, Noul’dan, daraja yoki miqdorni baholash zarur bo‘lsa, Score’dan foydalanishingiz mumkin. Keyin haqiqatan ham matn yozish, kod yaratish yoki murakkab muammoni hal qilish kerak bo‘lganda, LLMdan foydalanishingiz mumkin.

Generation → LLM
Decision   → Jev
Execution  → Code
Review     → Human

AI’dan oqilona foydalanish har doim eng aqlli modelni chaqirish degani emas. Muammo talab qilgan miqdordagina Intelligence’dan foydalanish muhimroq dizayn tamoyiliga aylanishi mumkin.

Ko‘plab kichik baholarni tezkor va arzon Decision Model’larga topshirish, kuchli LLMlardan esa faqat haqiqatan qiyin muammolar uchun foydalanish Multi-Agent va AI Orchestration muhitlarida ayniqsa mazmunlidir.

Kelajakda dasturchilar berishi kerak bo‘lgan savol «Qaysi AI eng yaxshi?» emas, balki «Bu baholashni bajarish uchun qaysi AI eng mos?» bo‘lishi mumkin. Jevning paydo bo‘lishi aynan shu savolni bizga bermoqda.

Manbalar

1. TypeSafe AI, «Introducing System One Models & Jev», 2026-09-15. https://typesafe.ai/blog/introducing-system-one-models-and-jev

2. TypeSafe AI rasmiy veb-sayti / Jev. https://typesafe.ai/

3. TypeSafe API ma’lumotnomasi. https://api.typesafe.ai/docs

4. TypeSafe AI Python SDK. https://github.com/typesafe-ai/typesafe-sdk-python

5. TypeSafe AI JavaScript/TypeScript SDK. https://github.com/typesafe-ai/typesafe-sdk-js

6. TypeSafe Workflow Evals. https://evals.typesafe.ai/

7. Browser Use, jev-ultrafast. https://github.com/browser-use/jev-ultrafast

8. Community Jev Email Classification Demo. https://madewithjev.com/categories/triage-and-routing

9. 1k Papers / Jev Classification Demo. https://jev.gorock.sh/projects/1k-papers

10. 724 Ads Jev namoyishi.https://systemonemodels.org/examples/discussions/breaking-down-724-ads-from-37-brands-with-jev/

11. Spring AI Community, TypeSafe/Jev integratsiya loyihasi.https://github.com/spring-ai-community/spring-ai-typesafe

※ Ushbu maqoladagi narxlar, kechikish va API haqidagi ma’lumotlar 2026-yil 24-sentabr holatiga ko‘ra ommaga ochiq ma’lumotlar asosida jamlangan. Jev uzoq vaqtdan beri ommaga taqdim etilmagan xizmat bo‘lgani sababli, uni amalda joriy etishda TypeSafe’ning eng so‘nggi rasmiy hujjatlari, narx siyosati va model versiyalarini yana bir bor tekshirish tavsiya etiladi.

syhan