ఒక కస్టమర్ సపోర్ట్ టీమ్కు ఈ మెసేజ్ పంపారని ఊహించుకోండి:
నా పేమెంట్ రెండుసార్లు తీసుకున్నారు, దీన్ని ఈరోజే సరిచేయాలి.
సమాధానం రాయడానికి అప్లికేషన్కు తప్పనిసరిగా AI మోడల్ అవసరం లేదు. ఎవరైనా రిప్లై ఇచ్చే ముందు, సిస్టమ్ కేవలం ఈ విషయాలు నిర్ణయించాల్సి ఉండొచ్చు:
- మెసేజ్ని ఏ టీమ్ అందుకోవాలి?
- సమస్య అత్యవసరమా?
- కస్టమర్ ఎంత విసుగు చెందినట్టు కనిపిస్తున్నారు?
- కేసును ఆటోమేటిక్గా రూట్ చేయడానికి మోడల్కు తగినంత నమ్మకం ఉందా?
చాలా AI సిస్టమ్లు ఇలాంటి పనిని లార్జ్ లాంగ్వేజ్ మోడల్కు పంపిస్తాయి—ఇమెయిల్స్ రాయడానికి, ఆలోచనలను వివరించడానికి మరియు సంభాషణలు జరపడానికి రూపొందించిన అదే రకమైన మోడల్. ఈ మోడల్ తన నిర్ణయాన్ని వివరిస్తూ ఒక పేరాగ్రాఫ్ లేదా JSON ఆబ్జెక్ట్ను తయారు చేయవచ్చు. దాన్ని వాడే ముందు అప్లికేషన్ ఆ అవుట్పుట్ను వాలిడేట్ చేయాల్సి ఉంటుంది.
Jev, సెప్టెంబర్ 2026లో TypeSafe AI విడుదల చేసిన ఒక మోడల్, వేరే ప్రశ్నతో మొదలవుతుంది: సాఫ్ట్వేర్కు కేవలం ఒక నిర్ణయం మాత్రమే అవసరమైతే, ఒక వ్యక్తి కోసం సమాధానం తయారు చేయమని మోడల్ని ఎందుకు అడగాలి?
Jev ఓపెన్-ఎండెడ్ టెక్స్ట్ను తయారు చేయదు. ఇది అప్లికేషన్ అందించిన సమాచారాన్ని మదింపు చేసి, ముందుగా నిర్వచించిన విలువలను ప్రాబబిలిటీలతో సహా తిరిగి ఇస్తుంది. TypeSafe ఈ కేటగిరీని System One model అని పిలుస్తుంది—సాఫ్ట్వేర్ లోపల వేగవంతమైన, స్ట్రక్చర్డ్ నిర్ణయాలు తీసుకోవడానికి ఉద్దేశించిన మోడల్. ఇది TypeSafe సొంత పరిభాష మాత్రమే, స్థిరపడిన ఇండస్ట్రీ కేటగిరీ కాదు.
ఈ ఆలోచన ఆశాజనకంగా ఉంది. దీన్ని అతిగా చెప్పడం కూడా సులభమే. Jev అనుకోని అవుట్పుట్ స్ట్రక్చర్లను నివారించగలదు, కానీ ఇప్పటికీ తప్పు నిర్ణయం తీసుకోవచ్చు. దీని బలమైన పనితీరు వాదనలు ప్రస్తుతం TypeSafe సొంత మదింపుల నుండే వస్తున్నాయి, మరియు మోడల్ గురించిన ముఖ్యమైన వివరాలు ఇంకా బహిర్గతం కాలేదు.
ఈ ఆర్టికల్ Jev ఏం మారుస్తుందో, ఏమి అలాగే ఉంటుందో, మరియు ఈ విధానం నిజమైన సిస్టమ్లలో ఎక్కడ సరిపోవచ్చు—లేదా సరిపోకపోవచ్చు—అనేది వివరిస్తుంది.
సమస్య ఎప్పుడూ రాయడం కాదు
లార్జ్ లాంగ్వేజ్ మోడల్స్ ఫ్లెక్సిబుల్గా ఉంటాయి ఎందుకంటే అవి ఒక్కో టోకెన్ చొప్పున టెక్స్ట్ను తయారు చేస్తాయి. అందువల్లే అదే మోడల్ బిల్లింగ్ సమస్యను వివరించగలదు, కోడ్ రాయగలదు, రిపోర్ట్ను సంక్షిప్తం చేయగలదు లేదా ప్రశ్నకు సమాధానం ఇవ్వగలదు.
సాఫ్ట్వేర్ ఆటోమేషన్కు తరచుగా మరింత సంకుచితమైనది అవసరం. ఒక అప్లికేషన్ ఒక రూట్ను ఎంచుకోవాల్సి రావచ్చు, స్కోర్ కేటాయించాల్సి రావచ్చు, ఒక ఆపరేషన్ను మళ్లీ ప్రయత్నించాలా వద్దా అని నిర్ణయించాల్సి రావచ్చు, లేదా ఎప్పుడు ఒక వ్యక్తి బాధ్యత తీసుకోవాలో నిర్ణయించాల్సి రావచ్చు. అవసరమైన ఫలితం పేరాగ్రాఫ్ కాదు. నిర్ణయమే.
డెవలపర్లు ఇప్పటికే LLMని JSON తిరిగి ఇవ్వమని అడగవచ్చు లేదా స్ట్రక్చర్డ్-అవుట్పుట్ ఫీచర్లను వాడవచ్చు. అది ఇంటర్ఫేస్ను మెరుగుపరుస్తుంది, కానీ లోపల ఉన్న మోడల్ ఇప్పటికీ ఒక సీక్వెన్స్ను తయారు చేయడం చుట్టూనే నిర్మించబడి ఉంటుంది. సంకుచితమైన నిర్ణయానికి అవసరమైన దానికంటే ఎక్కువ సమయం మరియు కంప్యూటేషన్ను ఇది వాడవచ్చు.
మిషన్-టు-మిషన్ నిర్ణయాలకు మొదటి నుంచే వాటి చుట్టూ రూపొందించిన మోడల్ అవసరమని TypeSafe వాదన. Jev అన్స్ట్రక్చర్డ్ లేదా స్ట్రక్చర్డ్ స్టేట్ను స్వీకరించి, కోడ్ నేరుగా వాడుకోగలిగే టైప్డ్, ప్రాబబిలిస్టిక్ నిర్ణయాలను తిరిగి ఇస్తుందని కంపెనీ వివరిస్తుంది. ఇది ప్రొడక్ట్ ఉద్దేశం గురించి TypeSafe సొంత భావన (vendor claim), స్వతంత్రంగా నిర్ధారించిన ముగింపు కాదు.
దీనివల్ల సంభాషణాత్మక మోడల్స్ అనవసరం కావు. తరచుగా కలిసిపోయే రెండు పనులను ఇది వేరు చేస్తుంది:
- అనిశ్చిత పరిస్థితిని అర్థం చేసుకోవడం.
- ఫలితాన్ని మానవ భాషలో వ్యక్తీకరించడం.
Jev మొదటి పనిపై దృష్టి పెడుతుంది.
Jev రిక్వెస్ట్ ఎలా పనిచేస్తుంది
TypeSafe API డాక్యుమెంటేషన్ ప్రకారం (డాక్యుమెంట్ చేయబడింది, 23 సెప్టెంబర్ 2026న మళ్లీ సరిచూశారు), ఒక అప్లికేషన్ మూడు ప్రధాన అంశాలను పంపుతుంది:
- State: మదింపు చేయాల్సిన సమాచారం. ఇది టెక్స్ట్, ఆబ్జెక్ట్ లేదా అర్రే కావచ్చు.
- Questions: మోడల్ తీసుకోవాలని అప్లికేషన్ కోరుకునే నిర్ణయాలు.
- Criteria: అనుమతించిన సమాధానాలు లేదా వాడుతున్న స్కేల్ అర్థం.
Jev ప్రస్తుతం మూడు రకాల ప్రశ్నలకు మద్దతు ఇస్తుంది, లాంచ్ నుండి ఇవి మారలేదు:
| ప్రశ్న రకం | సాధారణ అర్థం | ఉదాహరణ |
|---|---|---|
Choice | అప్లికేషన్ నిర్వచించిన జాబితా నుండి ఒక ఆప్షన్ను ఎంచుకోవడం (255 ఆప్షన్ల వరకు) | Billing, Technical or Sales |
Score | క్రమబద్ధమైన లెవెల్స్ సెట్కు అనుగుణంగా ఏదైనా రేట్ చేయడం (2–10 లెవెల్స్) | ప్రశాంతం, విసుగు లేదా చాలా కోపం |
Noul | అవును/కాదు అనే స్టేట్మెంట్ నిజమయ్యే అవకాశాన్ని అంచనా వేయడం | ఇది అత్యవసరమా? |
సపోర్ట్ మెసేజ్ కోసం, ఒక ఉదాహరణ రిక్వెస్ట్ Jevని ఒక డిపార్ట్మెంట్ను ఎంచుకోమని, అత్యవసరతను అంచనా వేయమని మరియు విసుగును స్కోర్ చేయమని అడగవచ్చు. సమాధానం భావనాత్మకంగా ఇలా ఉండవచ్చు:
| నిర్ణయం | ఉదాహరణ ఫలితం |
|---|---|
| డిపార్ట్మెంట్ | Billing — 94% |
| అత్యవసరం | అవును — 88% |
| విసుగు | ఎక్కువ — 76% |
ఈ సంఖ్యలు కల్పితమైనవి మరియు ఇంటర్ఫేస్ను వివరించడానికి ఇవ్వబడ్డాయి; ఇవి కొలిచిన Jev ఫలితాలు కావు.
తర్వాత ఏం జరగాలో నిర్ణయించే బాధ్యత చుట్టూ ఉన్న అప్లికేషన్దే. అధిక నమ్మకం ఉన్న కేసులను ఆటోమేటిక్గా రూట్ చేస్తూ, అనిశ్చిత లేదా అధిక పరిణామాలు ఉన్న కేసులను ఒక వ్యక్తికి పంపవచ్చు.
ప్రయత్నించండి: మెసేజ్ నుండి నిర్ణయం వరకు
అదే మూడు ప్రశ్నలు వేర్వేరు టైప్డ్ సమాధానాలను ఎలా తయారు చేయగలవో చూడటానికి కింద వేరే కల్పిత సపోర్ట్ మెసేజ్ను ఎంచుకోండి. ఈ ఎక్స్ప్లోరర్లోని మొత్తం కంటెంట్ పేజీకి మాత్రమే పరిమితం మరియు కల్పితం—ఏ మెసేజ్ కూడా TypeSafeకు లేదా మరే ఇతర సర్వీస్కు పంపబడదు.
State (మెసేజ్): “నా పేమెంట్ రెండుసార్లు తీసుకున్నారు, దీన్ని ఈరోజే సరిచేయాలి.”
- దీన్ని ఏ టీమ్ అందుకోవాలి? (Choice) — Billing, 94%
- ఇది అత్యవసరమా? (Noul) — అవును, 88%
- కస్టమర్ ఎంత విసుగు చెందినట్టు అనిపిస్తున్నారు? (Score) — ఎక్కువ, 76%
ఉదాహరణ థ్రెషోల్డ్ ఫలితం: మూడు ప్రశ్నలలోనూ నమ్మకం అప్లికేషన్ సెట్ చేసిన థ్రెషోల్డ్ కంటే ఎక్కువగా ఉంది, కాబట్టి ఈ కల్పిత ఉదాహరణ అత్యవసరంగా ఆటోమేటిక్గా Billingకు రూట్ అవుతుంది.
State (మెసేజ్): “ఈ ఉదయం నుండి నేను లాగిన్ కాలేకపోతున్నాను, ఒక గంటలో నాకు క్లయింట్ కాల్ ఉంది.”
- దీన్ని ఏ టీమ్ అందుకోవాలి? (Choice) — Technical, 81%
- ఇది అత్యవసరమా? (Noul) — అవును, 62%
- కస్టమర్ ఎంత విసుగు చెందినట్టు అనిపిస్తున్నారు? (Score) — విసుగు, 58%
ఉదాహరణ థ్రెషోల్డ్ ఫలితం: అత్యవసరత నమ్మకం అప్లికేషన్ సెట్ చేసిన మధ్య శ్రేణిలో పడుతుంది, కాబట్టి ఈ కల్పిత ఉదాహరణ ఆటోమేటిక్గా పరిష్కరించకుండా ఒక వ్యక్తికి పంపబడుతుంది.
State (మెసేజ్): “యాప్ రిపోర్ట్లను CSVగా ఎక్స్పోర్ట్ చేయగలిగితే బాగుంటుంది, తొందరేమీ లేదు.”
- దీన్ని ఏ టీమ్ అందుకోవాలి? (Choice) — Product, 90%
- ఇది అత్యవసరమా? (Noul) — కాదు, 95%
- కస్టమర్ ఎంత విసుగు చెందినట్టు అనిపిస్తున్నారు? (Score) — ప్రశాంతం, 97%
ఉదాహరణ థ్రెషోల్డ్ ఫలితం: మూడు సమాధానాలు అధిక నమ్మకంతో మరియు తక్కువ పరిణామాలతో ఉన్నాయి, కాబట్టి ఈ కల్పిత ఉదాహరణ మానవ సమీక్ష లేకుండా ఆటోమేటిక్గా ప్రొడక్ట్ బ్యాక్లాగ్కు రూట్ అవుతుంది.
కల్పిత ఇంటరాక్టివ్ ఉదాహరణ. ఇక్కడ చూపిన ప్రతి మెసేజ్, ప్రశ్న మరియు ప్రాబబిలిటీ కల్పితమైనవి, ఈ ఆర్టికల్ కోసం రాయబడ్డాయి—వీటిలో ఏదీ కొలిచిన Jev ఫలితం కాదు, మీరు ఎంచుకున్నది ఎక్కడికీ పంపబడదు.
ఇది వేగంగా, చౌకగా ఉంటుందని TypeSafe ఎందుకు ఆశిస్తోంది
సంప్రదాయ జనరేటివ్ మోడల్ సాధారణంగా అవుట్పుట్ను వరుసగా తయారు చేస్తుంది. ప్రతి కొత్త టోకెన్ దానికి ముందు తయారైన టోకెన్లపై ఆధారపడి ఉంటుంది. అందువల్ల పొడవైన సమాధానాలకు పదే పదే జనరేషన్ స్టెప్లు అవసరం.
Jev ఓపెన్-ఎండెడ్ స్ట్రింగ్ జనరేషన్ను వదులుకుంటుంది. తన మోడల్ బహుళ ప్రశ్నలను ఒకేసారి (పారలల్గా) మదింపు చేసి, అప్లికేషన్ కోరిన స్ట్రక్చర్డ్ విలువలను మాత్రమే తిరిగి ఇస్తుందని TypeSafe చెబుతుంది. ఒక వర్క్ఫ్లోలో చాలా చిన్న నిర్ణయాలు ఉన్నప్పుడు టెక్స్ట్ జనరేషన్ను తొలగించడం లేటెన్సీని, ఖర్చును తగ్గించవచ్చు.
23 సెప్టెంబర్ 2026న సోర్స్ సమీక్ష నాటికి, TypeSafe ఇన్పుట్ ధరను మిలియన్ టోకెన్లకు $0.042గా ప్రకటించింది, అవుట్పుట్ ధరను తన సొంత లాంచ్ పోస్ట్లో “మీటర్ చేయడానికి చాలా చౌక” అని వర్ణించింది. ఇది సుమారు 70 నుండి 500 మిల్లీసెకన్ల ఎండ్-టు-ఎండ్ రెస్పాన్స్ టైమ్లను నివేదించింది, మరియు తాను ఎంచుకున్న వర్క్ఫ్లోలలో ఫ్రాంటియర్ LLMల కంటే వేగంలో సుమారు 193.6×, ఖర్చులో 444.6× లాభాలు సాధించామని వాదించింది.
ఇవి వెండర్ నివేదించిన వాదనలు, స్థిరపడిన స్వతంత్ర కొలతలు కావు. తన లాంచ్ ఎవిడెన్స్లో TypeSafe స్వయంగా ముఖ్యమైన పరిమితులను అంగీకరిస్తుంది:
- వర్క్ఫ్లోలను దాని సొంత మోడల్-కెపబిలిటీస్ టీమ్ సభ్యులు రూపొందించారు.
- అది సెలెక్షన్ లేదా డిజైన్ బయాస్ అవకాశాన్ని తీసుకువస్తుంది.
- నివేదించిన అతిపెద్ద లాభాలు వాస్తవ-ప్రపంచ మెరుగుదలలో అత్యధిక స్థాయిని సూచిస్తుండవచ్చు.
- కొన్ని రిఫరెన్స్ సమాధానాలు స్వతంత్రంగా నిర్ధారించిన గ్రౌండ్ ట్రూత్ నుండి కాకుండా పెద్ద బాహ్య మోడళ్ల సగటు ప్రిడిక్షన్ల నుండి వచ్చాయి.
- తక్కువ ధర ఈరోజు గమనించవచ్చు, కానీ దాని దీర్ఘకాలిక సుస్థిరతను ఇంకా నిరూపించలేము.
సోర్స్ సమీక్ష నాటికి, Jev వెయిట్లిస్ట్ లేకుండా అందుబాటులో ఉంది: TypeSafe డెవలపర్ కన్సోల్లో సైన్-అప్ స్వీయ-సేవగా ఉంది, కొత్త ఖాతాలకు చిన్న ఉచిత టోకెన్ అలవెన్స్తో సహా. అది దీన్ని ప్రయత్నించడానికి అడ్డంకిని తగ్గిస్తుంది, కానీ లభ్యత ఖచ్చితత్వానికి రుజువు కాదు.
వేగం మరియు ఖర్చు ఇప్పటికీ Jevని పరీక్షించడానికి అర్థవంతమైన కారణాలు. అవి స్వతంత్ర మదింపును దాటవేయడానికి కారణాలు కావు.
కాలిబ్రేటెడ్ ప్రాబబిలిటీ నిజంగా అంటే ఏమిటి
ప్రతి మోడల్ ఒక సమాధానానికి సంఖ్యను జోడించగలదు. కష్టమైన ప్రశ్న ఏమిటంటే ఆ సంఖ్య నమ్మకానికి అర్హమైనదేనా అనేది.
ఒక మోడల్ వందల కొద్దీ ప్రిడిక్షన్లు చేసి, ప్రతి దానికీ సుమారు 80% ప్రాబబిలిటీ ఇస్తుందని అనుకుందాం. మోడల్ బాగా కాలిబ్రేట్ చేయబడి ఉంటే, ఆ ప్రిడిక్షన్లలో సుమారు 80% సరైనవిగా నిరూపితం కావాలి. ఈ స్టాటిస్టికల్ సంబంధాన్ని కాలిబ్రేషన్ అంటారు.
ఒక నిర్దిష్ట నిర్ణయం సరైనదని కాలిబ్రేషన్ హామీ ఇవ్వదు. అనేక నిర్ణయాలలో ఉపయోగకరమైన పాలసీలను నిర్వచించడానికి ఇది సిస్టమ్కు సహాయపడుతుంది. ఉదాహరణకు:
- పరీక్షించిన నమ్మక థ్రెషోల్డ్ కంటే ఎక్కువ ఉన్నప్పుడు ఆటోమేటిక్గా చర్య తీసుకోవడం.
- మధ్య శ్రేణిలో పెద్ద మోడల్ను రెండో అభిప్రాయం కోసం అడగడం.
- తక్కువ నమ్మకం లేదా అధిక పరిణామాలు ఉన్న కేసులను ఒక వ్యక్తికి పంపడం.
Jevని Reinforcement Learning for Calibrated Decisions, లేదా RLCD ఉపయోగించి ట్రైన్ చేస్తామని TypeSafe చెబుతుంది. దాని మెషిన్-లెర్నింగ్ ప్రైమర్ (డాక్యుమెంట్ చేయబడింది, 23 సెప్టెంబర్ 2026న మళ్లీ సరిచూశారు) లక్ష్యాన్ని గమనించిన కరెక్ట్నెస్కు అనుగుణంగా ప్రాబబిలిటీలు ఉండే నిర్ణయాలను తయారు చేయడంగా వివరిస్తుంది.
ఆ వాదనను మోడల్ పనిచేసే వాతావరణంలోనే మదింపు చేయాలి. ఒక డేటాసెట్పై కాలిబ్రేట్ చేసిన మోడల్, భాష, కస్టమర్లు, పాలసీలు లేదా దాడి పద్ధతులు మారినప్పుడు నమ్మదగనిదిగా మారవచ్చు. కాలిబ్రేషన్ ప్రతి డొమైన్లోనూ ఊహించదగిన శాశ్వత లక్షణం కాదు.
Jev నిజంగా హాలూసినేషన్లను తొలగిస్తుందా?
Jev హాలూసినేట్ కాలేదని TypeSafe చెబుతుంది. ఆ స్టేట్మెంట్కు మరింత సంకుచితమైన వివరణ అవసరం.
ఒక అప్లికేషన్ కేవలం Billing, Technical మరియు Salesను మాత్రమే అనుమతిస్తే, Jev Legal వంటి నాలుగో విలువను సృష్టించలేదు. అనుమతించిన టైప్ స్థానంలో పేరాగ్రాఫ్ను, తెలియని ఫీల్డ్ను లేదా తప్పుగా ఏర్పడిన సమాధానాన్ని ఇది తిరిగి ఇవ్వలేదు. సాఫ్ట్వేర్ వర్క్ఫ్లో లోపల AI అవుట్పుట్ కప్పబడి ఉన్నప్పుడు ఇది ఒక ముఖ్యమైన వైఫల్య రీతిని తొలగిస్తుంది.
ఎంచుకున్న విలువ సరైనదని ఇది నిరూపించదు. Jev ఇప్పటికీ ఇలా చేయగలదు:
- టెక్నికల్ సమస్యను Billingకు పంపడం.
- అస్పష్టమైన మెసేజ్ను తప్పుగా అర్థం చేసుకోవడం.
- కొత్త డొమైన్లో వాస్తవ ఖచ్చితత్వానికి సరిపోలని నమ్మకాన్ని కేటాయించడం.
- దాని ట్రైనింగ్ లేదా మదింపు డేటాలో ఉన్న బయాస్ను పునరావృతం చేయడం.
- అనుమతించిన ఆప్షన్లలో ఏదీ సరిపోనప్పుడు తక్కువ-తప్పు ఆప్షన్ను ఎంచుకోవడం.
వ్యత్యాసం సరళమైనది:
స్కీమా-వాలిడ్ సమాధానం తప్పనిసరిగా సరైన నిర్ణయం కాదు.
టైప్ సేఫ్టీ ఒక సమాధానం ఎలాంటి రూపం తీసుకోగలదో నియంత్రిస్తుంది. విశ్వసనీయత మోడల్పై, ప్రశ్నపై, అనుమతించిన ఆప్షన్లపై, డేటాపై, థ్రెషోల్డ్లపై మరియు తప్పు పరిణామాలపై ఆధారపడి ఉంటుంది.

టెక్స్ట్ సమానం—టైప్ సేఫ్టీ నివారించేది: నిర్వచించని ఆప్షన్, తప్పుగా ఏర్పడిన అవుట్పుట్, ఊహించని డేటా టైప్, సంబంధం లేని ప్రోజ్. ఇది నివారించనిది: తప్పు అనుమతించిన ఆప్షన్, అస్పష్టమైన వివరణ, పేలవమైన డొమైన్ కాలిబ్రేషన్, లేదా బయాస్ మరియు అసంపూర్ణ ఆప్షన్ సెట్.
Jev నిజంగా కొత్త రకమైన మోడలా?
Jev పరిష్కరించే సమస్య కొత్తది కాదు. నిర్ణయాలు తీసుకోవడానికి సాఫ్ట్వేర్ చాలా కాలంగా క్లాసిఫయర్లు, రీరాంకర్లు, పాలసీ నెట్వర్క్లు, రివార్డ్ మోడళ్లు మరియు బిజినెస్ రూల్స్ను వాడుతోంది. జనరేటివ్ మోడళ్లు కూడా స్ట్రక్చర్డ్ అవుట్పుట్ను తిరిగి ఇవ్వగలవు లేదా ఇతర మోడళ్లకు జడ్జిలుగా పనిచేయగలవు.
మరింత సమర్థించదగిన కొత్తదనం వాదన క్లాసిఫికేషన్ ఉనికి గురించి కాకుండా ప్యాకేజీ గురించి ఉంది. Jev వీటిని కలుపుతుంది:
- విస్తృత భాషా అవగాహన.
- శాశ్వతంగా స్థిరపరిచిన లేబుల్ సెట్కు బదులుగా రిక్వెస్ట్ చేసినప్పుడు నిర్వచించే ఆప్షన్లు.
- టైప్డ్ అవుట్పుట్.
- ప్రాబబిలిటీ డిస్ట్రిబ్యూషన్లు.
- ఒకేసారి (పారలల్గా) మదింపు చేసిన బహుళ నిర్ణయాలు.
- సాధారణ కోడ్ లోపల కూర్పు కోసం రూపొందించిన API.
ఒక ప్రారంభ స్వతంత్ర పరిశోధన ఉదాహరణ ఖచ్చితంగా జాగ్రత్తగా ఉన్నందుకే ఉపయోగకరంగా ఉంది. సెప్టెంబర్ 2026 పేపర్ Open-Jev Judgments on CallScreenBench (Ren et al., 21 సెప్టెంబర్ 2026న సమర్పించారు) స్కామ్-కాల్ స్క్రీనింగ్ కోసం ఓపెన్ Jev-శైలి ఇంప్లిమెంటేషన్ను పరీక్షించింది. దాని మదింపులో బలమైన డిస్క్రిమినేషన్ను మరియు కాలిబ్రేషన్ను నివేదించింది, అదే బ్యాక్బోన్ యొక్క జనరేటివ్ వెర్షన్ కంటే తక్కువ లేటెన్సీతో సహా. రచయితలు లాభం రీడౌట్ మరియు కాలిబ్రేషన్ నుండి వచ్చిందని, మెరుగైన ఖచ్చితత్వం నుండి కాదని కూడా పేర్కొన్నారు, ఆర్కిటెక్చరల్ కొత్తదనం ఏదీ వాదించలేదు, సింథటిక్ కాలర్లను వాడారు మరియు తమ రెసిపీని టెస్ట్-సెట్ ఎక్స్పోజర్తో ఎంచుకున్నామని అంగీకరించారు.
అది TypeSafe సొంత మోడల్ను ధృవీకరించదు. కొత్త ఫౌండేషనల్ కేటగిరీ స్థాపించబడిందని నిరూపించకుండానే, విస్తృత డిజైన్ పద్ధతి పరిశోధనకు అర్హమైనదని ఇది సూచిస్తుంది.
Jev ఎక్కడ సరిపోవచ్చు
ఒక సిస్టమ్కు భాష లేదా స్ట్రక్చర్డ్ అప్లికేషన్ స్టేట్పై చాలా వేగవంతమైన, పరిమితమైన నిర్ణయాలు అవసరమైనప్పుడు Jev అత్యంత సంబంధితంగా కనిపిస్తుంది.
సాధ్యమైన ఉపయోగాలు:
- సపోర్ట్ రిక్వెస్ట్లను రూట్ చేయడం.
- AI ఏజెంట్లో తదుపరి టూల్ను ఎంచుకోవడం.
- ఒక ఆపరేషన్ను మళ్లీ ప్రయత్నించాలా వద్దా అని నిర్ణయించడం.
- అత్యవసరత, రిస్క్, నాణ్యత లేదా పాలసీ కంప్లయన్స్ను స్కోర్ చేయడం.
- ఒక ఏజెంట్ ట్రేస్ లేదా అవుట్పుట్ను మదింపు చేయడం.
- పెద్ద రికార్డుల సేకరణలను వర్గీకరించడం.
- రియల్-టైమ్ అప్లికేషన్లో చెల్లుబాటు అయ్యే చర్యల మధ్య ఎంచుకోవడం.
పరిణామాలు ముఖ్యం. ఒక ఇమెయిల్ను తప్పుగా రూట్ చేయడం సాధారణంగా సరిదిద్దగలిగేదే. ఒక ఖాతాను బ్లాక్ చేయడం, రీఫండ్ను తిరస్కరించడం, మోసాన్ని గుర్తించడం లేదా ఆర్థిక చర్యను అధికారం చేయడం వంటివి బలమైన ఆధారాలు, పర్యవేక్షణ, ఆడిట్ ట్రెయిల్స్ మరియు అర్థవంతమైన అప్పీల్ మార్గాన్ని కోరుతాయి.
Jevను సరళమైన ప్రత్యామ్నాయాలతో కూడా పోల్చి చూడాలి. ఒక నిర్ణయం ఖచ్చితమైన షరతులను అనుసరిస్తే, సాధారణ కోడ్ మరింత అంచనా వేయదగినది. కేటగిరీలు స్థిరంగా ఉండి తగినంత లేబుల్ చేసిన డేటా ఉంటే, సంప్రదాయ క్లాసిఫయర్ను నిర్వహించడం, నడపడం సులభం కావచ్చు. పనికి వివరణ, సంశ్లేషణ లేదా ముందుగా జాబితా చేయలేని సమాధానం అవసరమైతే, జనరేటివ్ మోడలే మెరుగైన సరిపోతుంది.
ప్రయత్నించండి: ఏ విధానం నిర్ణయానికి సరిపోతుంది?
ఒక డిటర్మినిస్టిక్ రూల్, సంప్రదాయ క్లాసిఫయర్, Jev-శైలి నిర్ణయ మోడల్ మరియు జనరేటివ్ LLM ఒక్కొక్కటి దానికి ఎలా సరిపోతాయో—మరియు ఒక్కొక్కటి ఎక్కడ బలహీనంగా ఉంటుందో పోల్చడానికి ఒక దృశ్యాన్ని ఎంచుకోండి. కింద ఉన్న ప్రతి దృశ్యానికీ Jev ఉత్తమ సరిపోలిక కాదు.
ఉత్తమ సరిపోలిక: డిటర్మినిస్టిక్ బిజినెస్ రూల్. షరతు ఖచ్చితమైనది మరియు ముందుగానే తెలిసినది (ఉదాహరణకు, స్థిరమైన ఖర్చు పరిమితి), కాబట్టి సాధారణ కోడ్ ఏ మోడల్ కంటే మరింత అంచనా వేయదగినది మరియు ఆడిట్ చేయదగినది. క్లాసిఫయర్ లేదా Jev-శైలి మోడల్ స్థిర రూల్కు అవసరం లేని అనిశ్చితిని జోడిస్తుంది; జనరేటివ్ LLM ఇక్కడ అనవసరమైన ఓవర్హెడ్.
తరచుగా మంచి సరిపోలిక: Jev-శైలి నిర్ణయ మోడల్ లేదా సంప్రదాయ క్లాసిఫయర్. కేటగిరీలు చాలావరకు స్థిరంగా ఉంటాయి, ఇన్పుట్ గజిబిజి భాష, ఇది టైప్డ్, ప్రాబబిలిస్టిక్ అవుట్పుట్కు సరిపోతుంది. లేబుల్ చేసిన డేటా మరియు స్థిర కేటగిరీ సెట్ ఇప్పటికే ఉంటే క్లాసిఫయర్ కూడా బాగా పనిచేయగలదు; అస్పష్టమైన పదజాలంతో డిటర్మినిస్టిక్ రూల్ ఇబ్బంది పడుతుంది, పనికి అవసరమైన దానికంటే జనరేటివ్ LLM సాధారణంగా నెమ్మదిగా మరియు ఖరీదైనదిగా ఉంటుంది.
ఉత్తమ సరిపోలిక: జనరేటివ్ LLM. ముందుగా స్థిర ఆప్షన్ల సెట్గా జాబితా చేయలేని వివరణను రూపొందించడం ఈ పనికి అవసరం. డిటర్మినిస్టిక్ రూల్స్, క్లాసిఫయర్లు మరియు Jev-శైలి మోడళ్లు ముందుగా నిర్వచించిన ఫలితాల చుట్టూ నిర్మించబడ్డాయి, కాబట్టి వాటిలో ఏదీ ఓపెన్-ఎండెడ్ ప్రోజ్ను తయారు చేయలేదు.
పరిణామాత్మకమైనది; ఒకటి కంటే ఎక్కువ సంకేతాలు అవసరం. Jev-శైలి మోడల్ లేదా క్లాసిఫయర్ కాలిబ్రేటెడ్ రిస్క్ స్కోర్ను అందించగలదు, కానీ తప్పు నిర్ణయం యొక్క అధిక ఖర్చు అంటే ఫలితం స్వతంత్రంగా చర్య తీసుకోకుండా, పర్యవేక్షణ మరియు అప్పీల్ మార్గంతో కూడిన విస్తృత సమీక్ష ప్రక్రియకు అందాలి. అభివృద్ధి చెందుతున్న మోసం నమూనాలకు కేవలం కఠినమైన రూల్ సాధారణంగా చాలా పెళుసుగా ఉంటుంది, మరియు ఈ పరిణామ స్థాయిలో జనరేటివ్ LLM యొక్క ఫ్రీ-టెక్స్ట్ అవుట్పుట్ను ఆడిట్ చేయడం కష్టం.
సాధ్యమైన సరిపోలిక: Jev-శైలి నిర్ణయ మోడల్. ముందుగా నిర్వచించిన టూల్స్ సెట్లో ఎంచుకోవడం నిర్మాణాత్మకంగా Choice ప్రశ్నను పోలి ఉంటుంది, మరియు టెక్స్ట్ తయారు చేయకుండా దీన్ని చేయడం ఏజెంట్ లేటెన్సీని తగ్గించవచ్చు. టూల్ సెట్ అరుదుగా మారితే క్లాసిఫయర్ పనిచేయగలదు; ముందుగా స్థిరపడని టూల్ సెట్ గురించి ఏజెంట్ ఆలోచించాల్సి వచ్చినప్పుడు జనరేటివ్ LLM ఇప్పటికీ ఉపయోగకరంగా ఉంటుంది.
గుణాత్మకమైన, ఎడిటోరియల్గా రాసిన పోలికలు—బెంచ్మార్క్ స్కోర్లు కావు. కింద ఉన్న టేబుల్ అదే పోలికను స్థిర రూపంలో చూపుతుంది.
| విధానం | ఉత్తమ సరిపోలిక | ముఖ్యమైన పరిమితి |
|---|---|---|
| డిటర్మినిస్టిక్ బిజినెస్ రూల్ | తెలిసిన ఫలితాలతో ఖచ్చితమైన షరతులు | అర్థం గజిబిజి భాష లేదా సందర్భంపై ఆధారపడినప్పుడు పెళుసుగా మారుతుంది |
| సంప్రదాయ క్లాసిఫయర్ | తగిన ట్రైనింగ్ డేటాతో మద్దతు ఉన్న స్థిర కేటగిరీలు | సాధారణంగా స్థిర పని మరియు నిర్వహించిన లేబుల్ డేటా అవసరం |
| Jev-శైలి నిర్ణయ మోడల్ | ముందుగా నిర్వచించిన ఆప్షన్ల మధ్య ఫ్లెక్సిబుల్ భాష-ఆధారిత నిర్ణయాలు | ప్రొప్రయిటరీ ప్రవర్తన మరియు డొమైన్ విశ్వసనీయతను తప్పనిసరిగా పరీక్షించాలి |
| జనరేటివ్ LLM | ఓపెన్-ఎండెడ్ రీజనింగ్, వివరణ లేదా కంటెంట్ జనరేషన్ | సంకుచితమైన నిర్ణయాలకు సాధారణంగా నెమ్మదిగా, ఖరీదైనదిగా మరియు తక్కువ పరిమితంగా ఉంటుంది |
ఇంకా తెలియనిది ఏమిటి
అనేక ముఖ్యమైన అంశాలను స్వతంత్రంగా పరిశీలించడానికి తగినంత సమాచారాన్ని TypeSafe బహిరంగంగా వెల్లడించలేదు:
- Jev పారామీటర్ కౌంట్.
- దాని ఖచ్చితమైన ఆర్కిటెక్చర్.
- అది మొదటి నుండి ట్రైన్ చేయబడిందా లేదా మరో ప్రీట్రైన్డ్ మోడల్ నుండి రూపొందించబడిందా.
- ట్రైనింగ్ కంప్యూట్ మరియు వివరణాత్మక డేటా-జనరేషన్ పద్ధతులు.
- దాని సింథటిక్ ట్రైనింగ్ డేటా యొక్క పూర్తి కూర్పు.
- మోడల్ వెయిట్స్.
- విస్తృత డొమైన్-నిర్దిష్ట కాలిబ్రేషన్ ఫలితాలు.
- బయాస్, అడ్వర్సేరియల్ మరియు సేఫ్టీ మదింపులు.
- దీర్ఘకాలిక ధర సుస్థిరత.
- వాస్తవ ప్రొడక్షన్ డిస్ట్రిబ్యూషన్ మార్పుల కింద విశ్వసనీయత.
మోడల్ ప్రొప్రయిటరీ, మరియు ఈ సమీక్ష నాటికి Jev కోసం TypeSafe పూర్తి స్వతంత్ర టెక్నికల్ పేపర్ను లేదా మోడల్ కార్డ్ను ప్రచురించలేదు. ఈ లోపాలు వాదనలు తప్పు అని చూపించవు. బయటివారు వాటిని ఎంత నమ్మకంగా మదింపు చేయగలరో అవి పరిమితం చేస్తాయి.
Jev వెనుక ఉన్న వ్యక్తులు మరియు కంపెనీ
TypeSafe AI తన టీమ్ పేజీలో ముగ్గురు ఫౌండర్లను గుర్తిస్తుంది:
- Diogo Almeida, CEO: Google Brainలో పనిచేసిన సమయంలో RLHF మరియు InstructGPT యొక్క సహ-ఆవిష్కర్తగా TypeSafe సొంత టీమ్ పేజీ ఆయనకు క్రెడిట్ ఇస్తుంది; TechCrunch సహా మీడియా కవరేజ్, ChatGPT వెనుక ఉన్న ఇన్స్ట్రక్షన్-ఫాలోయింగ్ పద్ధతులకు దోహదపడిన మాజీ OpenAI పరిశోధకుడిగా కూడా ఆయనను వర్ణిస్తుంది.
- Erik Gafni, CTO: ప్రొడక్షన్ AI సిస్టమ్లను నిర్మించడంలో మరియు బయోటెక్నాలజీలో మల్టీమోడల్ AIని అన్వయించడంలో అనుభవం ఉన్న రిపీట్ ఫౌండర్.
- Sasha Sheng, COO: ప్రొడక్ట్ మరియు AI పరిశోధన రెండింటిలో పనిచేసిన మాజీ Meta/FAIR రీసెర్చ్ ఇంజనీర్.
కొన్ని హెడ్లైన్లు Almeidaను “ChatGPT ఆవిష్కర్త” అని పిలుస్తాయి. ఆ పదజాలం పెద్ద టీమ్ రూపొందించిన సిస్టమ్కు ఒక పరిశోధకుడికి మరీ ఎక్కువ క్రెడిట్ ఇస్తుంది. ChatGPTని సాధ్యం చేయడానికి సహాయపడిన ఇన్స్ట్రక్షన్-ఫాలోయింగ్ పద్ధతులకు ఆయన పరిశోధన దోహదపడిందనేది మరింత ఖచ్చితమైన వివరణ.
TypeSafe స్టెల్త్ నుండి బయటకు వచ్చినప్పుడు DCVC నేతృత్వంలో $40 మిలియన్ సీడ్ రౌండ్ సేకరించినట్టు నివేదికలు చెబుతున్నాయి—ఇది ఒకే TypeSafe-ప్రచురించిన ఫండింగ్ ప్రకటన కాకుండా బహుళ స్వతంత్ర నివేదికలచే ధృవీకరించబడింది. నివేదించిన సుమారు $200 మిలియన్ పోస్ట్-మనీ వాల్యుయేషన్ను కనీసం ఒక అవుట్లెట్ TypeSafeకు ఆపాదించింది కానీ ఇది స్వతంత్రంగా ధృవీకరించబడలేదు. కంపెనీ ప్రొడక్ట్ను అభివృద్ధి చేయడానికి మరియు నడపడానికి ఫండింగ్ సహాయపడవచ్చు, కానీ టెక్నికల్ వాదనలు సరైనవని ఇది ఆధారం కాదు.
మీరు ఎంత నేర్చుకోవాలి?
చాలామంది టెక్నాలజీ ప్రొఫెషనల్స్కు ఈరోజు Jevలో నైపుణ్యం సాధించాల్సిన అవసరం లేదు.
తెలుసుకోండి
డెవలపర్లు, ఆర్కిటెక్ట్లు, టెక్నికల్ లీడర్లు మరియు AIని అనుసరించే విద్యార్థులు విస్తృత ఆలోచనను అర్థం చేసుకోవాలి: ప్రతి ఇంటెలిజెంట్ సాఫ్ట్వేర్ నిర్ణయానికీ ఓపెన్-ఎండెడ్ లాంగ్వేజ్ మోడల్ రెస్పాన్స్ అవసరం లేదు.
ఉపయోగించండి
అధిక వాల్యూమ్ AI ఏజెంట్లను లేదా నిర్ణయాలతో నిండిన అప్లికేషన్లను నిర్మించే టీమ్లు Jevని పరీక్షించాలని కోరుకోవచ్చు. ప్రాక్టికల్ మదింపులో డొమైన్ ఖచ్చితత్వం, కాలిబ్రేషన్, లేటెన్సీ, ఖర్చు, ఫాల్బ్యాక్ ప్రవర్తన, డేటా హ్యాండ్లింగ్ మరియు తప్పు నిర్ణయాల ఆపరేషనల్ ప్రభావం ఉండాలి.
నైపుణ్యం సాధించండి
ఆటోమేటెడ్ నిర్ణయ ప్లాట్ఫారమ్లను రూపొందించే ఇంజనీర్లకు కాలిబ్రేషన్, మదింపు డేటాసెట్లు, డిస్ట్రిబ్యూషన్ షిఫ్ట్, థ్రెషోల్డ్ పాలసీలు, అబ్జర్వబిలిటీ, హ్యూమన్ ఎస్కలేషన్ మరియు గవర్నెన్స్పై లోతైన అవగాహన అవసరం. ఒక వెండర్ APIతో పరిచయం కంటే ఆ నైపుణ్యాలే ఎక్కువ ముఖ్యం.
విద్యార్థులు మరియు సాధారణ IT ప్రొఫెషనల్స్ ప్రస్తుతానికి Jev యొక్క అంతర్గత ఇంప్లిమెంటేషన్ను పట్టించుకోకపోవచ్చు. శాశ్వతమైన పాఠం ఏమిటంటే లాంగ్వేజ్ జనరేషన్ మరియు సాఫ్ట్వేర్ నిర్ణయాత్మకత మధ్య విభజన.
“Jev LLMలను భర్తీ చేస్తుందా?” కంటే మెరుగైన ప్రశ్న
రాసే, వివరించే, పరిశోధించే లేదా ఓపెన్-ఎండెడ్ సమస్యల ద్వారా ఆలోచించే మోడళ్లను భర్తీ చేయడానికి Jev రూపొందించబడలేదు. అప్లికేషన్ ఇప్పటికే ఏ రకమైన సమాధానాలను అంగీకరించగలదో తెలిసిన సాఫ్ట్వేర్ లోపల కూర్చోవడానికి ఇది రూపొందించబడింది.
దీని లాంచ్ ఒక ఉపయోగకరమైన ఆర్కిటెక్చరల్ ప్రశ్నను లేవనెత్తుతుంది:
సాఫ్ట్వేర్కు వివరణ కంటే నిర్ణయం అవసరమైనప్పుడు, దాన్ని రాయమని మోడల్కు ఎందుకు చెల్లించాలి?
Jev ఒక ముఖ్యమైన సమాధానంగా నిరూపితం కావచ్చు. ఇది స్ట్రక్చర్డ్ LLM అవుట్పుట్ల నుండి, చిన్న ఫైన్-ట్యూన్డ్ మోడళ్ల నుండి మరియు స్థిరపడిన క్లాసిఫికేషన్ పద్ధతుల నుండి పోటీని కూడా ఎదుర్కోవచ్చు. కొత్త మోడల్ యుగాన్ని ప్రకటించడానికి ఆధారాలు చాలా ముందుగానే ఉన్నాయి.
మారింది ఏమిటంటే డెవలపర్లు అడగగలిగే ప్రశ్న. ప్రతి అనిశ్చిత పనిని సంభాషణాత్మక మోడల్కు పంపడానికి బదులుగా, ఆ పనికి లాంగ్వేజ్ జనరేషన్ అసలు అవసరమా అని వారు నిర్ణయించుకోగలరు.
ఆ నిర్ణయం ఏదైనా ఒక్క మోడల్ చుట్టూ ఉన్న ప్రస్తుత ఉత్సాహం కంటే ఎక్కువ కాలం ముఖ్యంగా ఉండవచ్చు.
రిఫరెన్సులు మరియు మరింత చదవడానికి
- Introducing System One Models & Jev — TypeSafe AI, 15 September 2026. అధికారిక లాంచ్ వివరణ, పనితీరు వాదనలు, మదింపు డిజైన్ మరియు కంపెనీ సొంత అర్హతలు.
- TypeSafe API reference — TypeSafe AI, reviewed 23 September 2026. రిక్వెస్ట్ ఫార్మాట్, ప్రశ్న ప్రిమిటివ్లు, రెస్పాన్స్ స్ట్రక్చర్లు మరియు డాక్యుమెంట్ చేసిన పరిమితులు.
- AI primer: calibrated decisions and RLCD — TypeSafe AI, reviewed 23 September 2026. దాని ట్రైనింగ్ లక్ష్యం మరియు కాలిబ్రేషన్ వివరణ గురించి కంపెనీ వివరణ.
- TypeSafe team — TypeSafe AI, reviewed 23 September 2026. Diogo Almeida, Erik Gafni మరియు Sasha Sheng యొక్క అధికారిక బయోగ్రఫీలు.
- Open-Jev Judgments on CallScreenBench — Ren et al., 21 September 2026. ఉపయోగకరమైన ఫలితాలు మరియు అసాధారణంగా స్పష్టమైన పరిమితులతో కూడిన స్వతంత్ర Jev-శైలి ఇంప్లిమెంటేషన్; ఇది TypeSafe సొంత Jev మోడల్ను మదింపు చేయదు.
- A new kind of AI model from a ChatGPT inventor is thrilling developers — TechCrunch, 18 September 2026. కంపెనీ, ఫండింగ్, లాంచ్ మరియు ప్రారంభ డెవలపర్ల ఆసక్తి గురించి నివేదిక.
- What is Jev, an AI “generalist” model with a new take on decision-making? — The Indian Express, updated 23 September 2026. మోడల్, పబ్లిక్ లభ్యత మరియు ప్రారంభ ఇంటిగ్రేషన్ల సాధారణ అవలోకనం.
