Jev 1.13 jaggedness: 9 failure modes और उनके आसान उपाय

Jev 1.13 (jev-1.13) TypeSafe का तेज़, calibrated judgment model है – System One tasks में सबसे अच्छा: तुरंत हाँ/ना (Noul) और pick-one (Choice) फैसले, दिए गए text पर। यह calculator नहीं है, date parser नहीं है, और text generator भी नहीं है। TypeSafe का अपना jev-1.13 के लिए model-jaggedness page (last reviewed 2026-09-17) नौ ऐसी जगहें बताता है जहाँ यह sharp रहता है और जहाँ jagged हो जाता है। यह guide उन नौ points का सारांश है, हर एक के practical fix के साथ – ताकि आप model से वह काम करवाना बंद करें जो code का है।

एक line का नियम: judgment Jev को दें, math code में रखें। Extraction एक judgment है – वह उसे दें। गिनती, तारीखों की तुलना, "yes" और "not yes" का जोड़ एक होना – यह सब code का काम है।

9 failure modes – एक नज़र में

Source: TypeSafe docs, Jev 1.13 jaggedness। नीचे मेरा सारांश है, साथ में जोड़े गए उदाहरण।

1. Literal reading

Jev वही सवाल जवाब देता है जो आपने लिखा, वह नहीं जो आपके मन में था। Scoping words, negations और implied conditions को वह face value पर पढ़ता है। इंसान इरादा सुनता है; Jev text पढ़ता है। जब भी गलत जवाब के बाद आप "मेरा मतलब असल में यह था" समझाएँ – वही स्पष्टीकरण आपके instruction का गुम आधा हिस्सा था।

Fix: instructions में exact condition लिखें, criteria में boundary cases बताएँ, और जहाँ interpretation टल न सके, एक fuzzy सवाल को दो literal सवालों में बाँटकर जवाब code में जोड़ें।

2. Math and numbers – Jev calculator नहीं है

तीन जुड़े जाल: counting (characters, term occurrences, list items – चीज़ बड़ी होते ही error बढ़ता है), numeric representations (hex colours, RGB triples, assembly या binary – नामों और high-level code से खराब पढ़े जाते हैं), और score interpolation (expectation पर threshold चला सकते हैं, पर score levels के बीच interpolate करके exact number न निकालें – वहाँ calibration कमज़ोर है)।

Fix: अगर unit regex या parser से मिल सके, तो गिनती code में करें। हर candidate पर एक yes/no पूछें, फिर खुद जोड़ें:

from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient(model="jev-1.13")
YES = 0.5  # threshold depends on your use case

items = ["typesafe", "apple", "california", "banana",
         "likes", "calibration", "orange", "vertex"]

result = client.system_one(
    {"items": items},
    {f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?")
     for i in range(len(items))},
)
count = sum(result.nouls[f"item_{i}"].noul > YES for i in range(len(items)))

Colours और code के लिए भी वही idea: पहले code में number या named bucket में convert करें, और model को सिर्फ असली judgment के लिए रखें (जैसे, कोई colour warning जैसा लगता है या नहीं)।

3. Date and time comparison

Jev तारीखों को text की तरह पढ़ता है, ordered quantities की तरह नहीं। "कौन सी date पहले आती है?", "कितना अंतर है?", "इस window के अंदर है?" – अविश्वसनीय, और mixed formats, relative references ("next Friday") और quarters या settlement windows जैसी domain boundaries के साथ और खराब।

Fix: काम बाँटें। Extraction judgment है, इसलिए हर part (year, month, day) को explicit "not stated" option के साथ छोटे closed set पर Choice बनाएँ – फिर code में असली date जोड़ें और ordering, duration, offsets, weekdays सब code के हवाले करें। TypeSafe के date-extraction cookbook में पूरा worked version है।

4. Indirection

Double negatives और multi-hop सवाल ("property की property") accuracy घटाते हैं। Reasoning का हर extra hop भटकने का एक मौका है।

Fix: instructions जितना हो सके सीधे लिखें और state के relevant हिस्से का नाम स्पष्ट रूप से बताएँ, बजाय model को pointers के पीछे दौड़ाने के।

5. बड़ा state, भरी हुई irrelevant detail

Unrelated content बढ़ते ही accuracy गिरती है – distractors signal डुबो देते हैं, और debugging ("किस input से यह हुआ?") मुश्किल हो जाता है। Jev की context window भी bounded है (exact token limits के लिए TypeSafe Models page देखें), और wall तक पहुँचने से पहले ही unrelated material accuracy खाता है – practitioners इसे context rot कहते हैं।

Fix: पहले code में retrieve और filter करें; सिर्फ वही fields भेजें जो सवाल को चाहिए। जब upfront filtering मुमकिन न हो, तो Noul को relevance gate की तरह इस्तेमाल करें (TypeSafe का classifying-RAG-passages cookbook यही pattern दिखाता है)।

6. Adversarial content

State data है, और Jev उसे default रूप से hostile नहीं मानता। Injected instructions, misleading framing, या खुद अपने classification के पक्ष में दलील देता text जवाब को हिला सकता है।

Fix: criteria में स्पष्ट लिखें कि क्या गिना जाएगा, और कई users तक rollout से पहले edge cases अच्छी तरह test करें। TypeSafe कहता है इस पर hardening roadmap में है।

7. Contradictory instructions and criteria

जब instructions और criteria अलग दिशाओं में खींचें – classic उदाहरण वह Noul है जहाँ true को "no" और false को "yes" लिखा गया हो – performance गिरता है। ऐसी phrasing रखें जिसे औसत व्यक्ति एक बार में सही समझ ले।

Fix: criteria को instruction का extension मानें और दोनों को साफ, सटीक भाषा में मिलाएँ।

8. Common-sense structural invariants जो लागू नहीं होते

Jev similar inputs पर बहुत consistent है, पर अलग-अलग सवाल arithmetic identities नहीं मानते। TypeSafe के दो documented उदाहरण:

• वही refund सवाल Noul (0.22) बनाम yes/no Choice के रूप में (yes 0.01 / no 0.99, confidence 0.97) – comparable numbers उम्मीद जैसी line में नहीं आते।
• एक सवाल और उसका negation दो Nouls के रूप में 0.72 और 0.47 score करते हैं – जोड़ 1.19 होता है, 1.0 नहीं।

Choice relative है (कौन सा option?), जबकि हर Noul absolute है (क्या यही सच है?) – सारे Nouls एक साथ low हो सकते हैं। एक primitive पर tune किया threshold दूसरे पर न ले जाएँ।

Fix: हर सवाल को सीधे वही अर्थ देने वाली wording में पूछें, और identities code में लागू करें। Skill-suggestion cookbook pattern ही template है: skill चुनने के लिए Choice, suggest करना है या नहीं इसके लिए Nouls।

9. Generation – Jev से prose न लिखवाएँ

Jev text generate करने के लिए trained नहीं है। Choices को chain करके generation करवाना slow और खराब है। Extraction के लिए पहले regex या generative model से candidate spans निकालें।

Fix: जब answer space bounded हो, extraction को options पर Choice बना दें। अगर सच में open-ended text चाहिए, तो वह हिस्सा generative model से करवाएँ।

Ship करने से पहले checklist

• Model से वह कभी न पूछें जो code exactly compute कर सकता है।
• एक सवाल में कई judgments न छिपाएँ – उन्हें बाँटें।
• System Two tasks (indirection की परतें) System One model पर नहीं हैं।
• सवाल को जितना चाहिए, उससे ज़्यादा state कभी न भेजें।

Bottom line

Jev 1.13 अपनी speed छोटे, literal, well-scoped judgments पर छोटे, relevant state के साथ कमाता है। Jagged list की हर चीज़ अलग कपड़ों में वही गलती है: judgment model से calculator, calendar, filter या writer बनने को कहना। Exact हिस्से code में धकेलें, semantic decision Jev पर रखें – और "jaggedness" ज़्यादातर गायब हो जाएगी। Full source: docs.typesafe.ai/model-jaggedness/jev-1.13।