AI एजेंट्स के 5 स्तर: प्रॉम्प्ट से प्रोडक्शन तक

आजकल लोग agents को लेकर पाँच शब्दों का खूब इस्तेमाल कर रहे हैं: Context engineering, loop engineering, Jev engineering, harness engineering, eval engineering.

सुनने में ये पाँच अलग-अलग तरीके लगते हैं। लेकिन ऐसा है नहीं। ये एक ही सिस्टम की पाँच परतें (layers) हैं, और हर परत एक खास सवाल का जवाब देती है।

इन्हें समझने का सबसे आसान तरीका ये है कि सोचो तुमने अभी-अभी एक नया कर्मचारी रखा है:

• Context - जब तुम उससे कुछ पूछते हो, तो उसकी डेस्क पर क्या रखा है
• Loop - क्या वो तुम्हारी चेकलिस्ट फॉलो करता है या अगला कदम खुद तय करता है
• Jev - रिसेप्शन डेस्क जो डाक छांटती है, ताकि उसे सिर्फ वही दिखे जो ज़रूरी है
• Harness - उसका ऑफिस। टूल्स, चाबियाँ, और उसका काम कौन चेक कर रहा है
• Evals - हर महीने होने वाला एक ही टेस्ट, ताकि तुम्हें पता चले कि वो सच में बेहतर हुआ है या नहीं

एक AI agent वही कर्मचारी है। मॉडल वो इंसान है, और ये पाँच परतें उसके आस-पास का सब कुछ हैं। अगर ये पाँच परतें सही हों, तो एक छोटी टीम वो काम भी संभाल सकती है जिसके लिए पहले नई भर्ती करनी पड़ती थी। बार-बार होने वाला काम उस agent के पास चला जाता है जो प्रोडक्शन में टिक कर काम करता है, और फैसले लेने का काम तुम्हारी टीम के पास रहता है। बिना नए लोगों को हायर किए स्केल करना असल में ऐसा ही दिखता है।

हर परत के लिए मैं बताऊंगा कि वो क्या है, कैसे काम करती है, कहाँ इस्तेमाल होती है और उसे बनाना कैसे है।

और हर परत के लिए मैंने एक शॉर्टकट भी तैयार किया है। यानी शुरू से सब कुछ बनाने की बजाय, वही नतीजा पाने का एक आसान तरीका — खासकर शुरुआती लोगों के लिए। मेरे दोस्त Viktor ने इन शॉर्टकट्स को तैयार करने में मेरी मदद की है।

Viktor एक AI employee है जो तुम्हारे Slack या Microsoft Teams में रहता है। वो बाकी सबकी तरह उन्हीं चैनल्स में मौजूद रहता है और एक साथी की तरह काम करता है — जिसे तुम बिना कोई नई पोस्ट खोले अपनी टीम में शामिल कर सकते हो।

उसके साथ काम करना किसी इंसान के साथ काम करने जैसा ही है:

• तुम किसी चैनल या थ्रेड में उसे mention करते हो और काम बताते हो।
• वो खुद स्टेप्स तय करता है, तुम्हारे टूल्स में काम करता है, और नतीजा उसी थ्रेड में वापस पोस्ट कर देता है।

सेटअप बहुत आसान है। बस Viktor को अपने workspace में ऐड करो, और वो तुम्हारी टीम के किसी भी सदस्य की तरह एक participant के रूप में दिखने लगेगा। अगर इसे पढ़ते हुए तुम इसे आज़माना चाहते हो, तो YARCHI100 कोड का इस्तेमाल करो।

pic1. किसी agent की पाँच परतें

1. Context engineering

परिभाषा

हर सवाल से पहले, तुम कर्मचारी की डेस्क पर कुछ कागज़ रख देते हो। अगर सही तीन पेज रखे, तो वो सेकंडों में जवाब दे देगा। तीन सौ पेज रख दिए, तो जवाब उस ढेर के बीच में दब जाएगा। और वो उसे देख ही नहीं पाएगा।

मॉडल वो कर्मचारी है। डेस्क context window है: यानी मॉडल को जवाब देने से पहले जो कुछ भी दिखाई देता है। तुम्हारी हिदायतें, अब तक की चैट, डेटाबेस से खींचे गए डॉक्यूमेंट्स, और उसने जितने भी टूल्स चलाए उनके आउटपुट।

Context engineering का मतलब है ये तय करना कि डेस्क पर क्या रखना है, और कहाँ रखना है।

ये कैसे काम करता है

ज़्यादा context का मतलब बेहतर जवाब नहीं होता। एक हद के बाद इसका मतलब बदतर जवाब होता है।

Stanford ने इसकी सीधे जाँच की। किसी मॉडल को 20 से 30 डॉक्यूमेंट्स दो, तो बीच वाले डॉक्यूमेंट्स पर उसकी accuracy गिरकर करीब 50 से 57 प्रतिशत रह जाती है। जब कोई डॉक्यूमेंट ही नहीं दिया गया, तो उसी मॉडल ने 56 प्रतिशत स्कोर किया। जवाब window में मौजूद था, फिर भी मॉडल ने बिना कुछ दिए वाली स्थिति से भी बदतर प्रदर्शन किया।

इसके पीछे दो वजहें हैं:

• मॉडल window की शुरुआत और अंत पर सबसे ज़्यादा ध्यान देता है, और बीच वाले हिस्से पर सबसे कम।
• हर token की लागत पैसों और समय दोनों में लगती है, चाहे वो काम आए या न आए।

जानने लायक एक चीज़ है prompt caching। प्रोवाइडर तुम्हारे prompt की शुरुआत को स्टोर कर लेता है और अगली कॉल में उसे दोबारा इस्तेमाल करता है, और एक cached token की कीमत नए token से करीब दस गुना कम होती है।

पेच ये है: cache तभी काम करता है जब शुरुआत का हिस्सा byte-for-byte बिल्कुल वैसा ही हो। ऊपर की तरफ एक भी कैरेक्टर बदला, तो उसके बाद का सब कुछ पूरी कीमत पर बिल होगा। इसलिए हमेशा पहले वो चीज़ें रखो जो बदलती नहीं हैं, और जो बदलती हैं उन्हें आखिर में रखो।

इसे कैसे बनाएं

context का हर हिस्सा इन चार जगहों में से किसी एक में जाता है:

1. System prompt. सिर्फ वो बातें जो हर कॉल पर सच हों: role, constraints, output format। इसे byte-for-byte एक जैसा रखो। ऊपर timestamp मत रखो, JSON keys को बेतरतीब क्रम में मत रखो।
2. Tools. बातचीत के बीच में इन्हें ऐड या हटाओ मत। इससे cache टूट जाता है और मॉडल उन टूल्स को कॉल करने लगता है जो अब मौजूद ही नहीं हैं। किसी खास स्टेप पर किसी tool को रोकना हो, तो कॉल को ब्लॉक करो, definition को नहीं।
3. Disk. जो कुछ भी बड़ा है या लंबे समय तक चाहिए, उसे फाइल में रखो, और window में सिर्फ उसका path रहने दो। वेब पेज के साथ भी यही करो: URL रखो, body हटा दो। content हटाओ, लेकिन वो key रखो जिससे वो वापस मिल सके।
4. Tail. हर कुछ स्टेप्स पर, context के अंत के पास मौजूदा goal को दोबारा लिख दो। तुम बीच वाले हिस्से को ठीक नहीं कर सकते, इसलिए जो ज़रूरी है उसे वहाँ से दूर रखो।

टूल्स की भी एक सीमा होती है। Anthropic ने मापा कि यूज़र द्वारा एक शब्द भी टाइप करने से पहले 58 tool definitions करीब 55,000 tokens खा गए। सभी टूल्स को लोड करने की बजाय मॉडल को टूल्स सर्च करने देने पर उनके benchmark पर Opus 4 का स्कोर 49 से बढ़कर 74 प्रतिशत हो गया।

अगर 20 से कम टूल्स हैं, तो उन्हें लोड ही रखो। उससे ज़्यादा हों, तो search पर शिफ्ट हो जाओ।

बड़े कामों के लिए एक और ट्रिक: एक sub-agent भेजो। वो अपनी window में 50 फाइलें पढ़ता है और एक पेज का summary लौटा देता है। तुम्हारे main context को सिर्फ वही summary दिखता है।

pic2. मॉडल की एक कॉल में क्या-क्या जाता है

शॉर्टकट

Viktor इसका ज़्यादातर बोझ तुम्हारे कंधों से उतार लेता है, क्योंकि उसका context कंपनी लेवल पर रहता है।

• Memory. वो पूरी टीम के लिए तुम्हारे बिज़नेस की एक permanent memory रखता है। पिछले हफ्ते उसने तुम्हारे cofounder से जो सीखा, उसे आज तुम्हें अपनी request में paste करने की ज़रूरत नहीं है।
• Connected sources. Notion, Google Drive या HubSpot कनेक्ट होने के बाद, तुम्हें चैट में फाइलें paste करना बंद करना होगा। तुम बस डॉक या रिकॉर्ड का नाम बताओ, वो खुद source पढ़ लेगा। यानी disk वाला नियम, तुम्हारे लिए अपने आप लागू।
• Skills. तुम एक बार अपना स्क्रीन रिकॉर्ड करते हुए कोई काम करके दिखाओ। वो उस रिकॉर्डिंग को लिखित प्रक्रिया में बदल देता है, तुम उसे सुधारकर approve कर देते हो। इसके बाद वो हिदायत पक्की और रिव्यू की हुई हो जाती है, बिल्कुल एक अच्छे system prompt की तरह।

तुम्हारे हिस्से में क्या बचता है:

• एक बार कंपनी का छोटा सा brief लिख दो: तुम क्या बेचते हो, कौन खरीदता है, कौन से आंकड़े मायने रखते हैं, और उसे कभी क्या नहीं करना चाहिए।
• एक थ्रेड में एक ही काम, और पहले मैसेज में ही बता दो कि "काम पूरा हुआ" का मतलब क्या है।
• अगर उसने कुछ गलत सीख लिया है, तो हर थ्रेड में उसे सुधारने की बजाय settings से उसकी memory wipe कर दो।

2. Loop engineering

परिभाषा

तुम कर्मचारी को एक चेकलिस्ट दे सकते हो: फाइल खोलो, लाइन 12 बदलो, सेव करो। या फिर तुम उसे एक goal दे सकते हो: टेस्ट पास कराओ।

goal के साथ, वो कुछ करके देखता है, नतीजा देखता है, और तय करता है कि आगे क्या करना है। चेकलिस्ट एक workflow है। goal एक loop है।

ये कैसे काम करता है

loop चार कदमों का बार-बार चलने वाला चक्र है: सोचो, करो, देखो, तय करो। कोई bug ठीक करना कुछ ऐसा दिखता है:

1. टेस्ट चलाओ। तीन फेल हो गए।
2. पहली error पढ़ो। एक import गायब है।
3. import ऐड करो, दोबारा चलाओ।
4. एक टेस्ट अभी भी फेल है। वो error पढ़ो, ठीक करो, दोबारा चलाओ।
5. सब पास हो गया। रुक जाओ।

ये स्टेप्स किसी ने पहले से नहीं लिखे थे। मॉडल ने पिछला नतीजा देखकर हर कदम खुद चुना।

बस यही पूरा फर्क है। तुम्हारे लिखे सौ स्टेप्स भी एक workflow ही हैं। मॉडल के चुने तीन स्टेप्स एक loop हैं।

loop का इस्तेमाल तभी करो जब तुम स्टेप्स पहले से न लिख सको। अगर लिख सकते हो, तो लिखो। workflow सस्ता होता है, parallel चलता है, और जब चौथा स्टेप फेल होता है तो तुम सिर्फ चौथा स्टेप दोबारा चलाते हो, पूरा नहीं।

loops महंगे भी होते हैं। एक agent एक single call के मुकाबले करीब चार गुना tokens इस्तेमाल करता है। Multi agent setups में ये करीब पंद्रह गुना हो जाता है।

इसे कैसे बनाएं

loop के चार हिस्से होते हैं। कोई एक भी निकाल दो, तो ये काम करना बंद कर देता है:

1. एक goal जिसका 'done' साफ हो। "bug ठीक करो" नहीं। बल्कि: "auth_test.py में फेल हो रहा टेस्ट पास हो जाए और कुछ और न टूटे।"
2. एक checker. मॉडल के बाहर की कोई चीज़ जो pass या fail बताए: test suite, compiler, linter। Self correction पर हुई रिसर्च इस बात पर एकमत है। ये असली external feedback के साथ काम करता है और फेल हो जाता है जब मॉडल खुद ही अपना रिव्यू करता है। checker नहीं तो loop नहीं, बस बिना छोर के पैसे खर्च होंगे।
3. एक stop rule. checker पास कर दे, या turn limit पूरी हो जाए, या पिछली दो कोशिशों का आउटपुट एक जैसा आए।
4. एक budget. turns और डॉलर, दोनों का।

कोड में, ये पूरा मामला कुछ लाइनों में समा जाता है:

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # done
7    if repeated(history, 2):  break   # stuck
8    if spent() > BUDGET:      break   # too expensive
9else:
10    fallback_workflow(goal)

प्रोडक्शन के लिए सबसे बेहतरीन सेटअप जो मैंने पब्लिश होते देखा है, वो एक hybrid है। Atlan पहले एक deterministic filter चलाता है, और आने वाले alerts में से सिर्फ करीब 14 प्रतिशत ही agent तक पहुँच पाते हैं।

फिर loop को ज़्यादा से ज़्यादा तीन cycles मिलते हैं। अगर तीन के बाद भी confidence 50 प्रतिशत से कम है, तो एक fixed Python workflow कमान संभाल लेता है।

पहले filter करो, loop छोटा रखो, और fallback तैयार रखो।

pic3. Workflow और loop के बीच चुनाव कैसे करें

शॉर्टकट

थ्रेड में तुम Viktor को जो भी काम देते हो, वो एक loop होता है। तुम goal लिखते हो, वो स्टेप्स चुनता है, तुम्हारे टूल्स में काम करता है और नतीजे के साथ थ्रेड में लौट आता है।

चार हिस्से इस तरह मैप होते हैं:

• Goal. अधूरे briefs पर वो सवाल उठाता है और अनुमान लगाने की बजाय पूछता है। फिर भी, 'done' साफ लिखो। "पिछले हफ्ते की revenue report, totals Stripe से मेल खाएं, सोमवार सुबह 9 बजे तक #finance में पोस्ट हो जाए" — ये "report बना दो" से कहीं बेहतर है।
• Checker. पोस्ट करने से पहले वो उन आंकड़ों पर निशान लगाता है जो गलत लगते हैं। चेक करने के लिए source का नाम बताकर इसे और मजबूत बनाओ: Stripe total, row count, test suite।
• Stop rule. संवेदनशील कामों पर इंसान की मंज़ूरी के लिए रुक जाता है, और नतीजा हमेशा तुम्हारे पास ही आता है।
• Budget. Credits। Reasoning tier हर स्टेप की कीमत तय करता है, और बार-बार होने वाले कामों में frequency मायने रखती है। हर घंटे की report, हफ्ते की report से कहीं ज़्यादा महंगी पड़ती है।

Atlan वाला hybrid बिना कोड के भी काम करता है। जो काम बार-बार होता है वो scheduled task बन जाता है: वो इसे suggest करता है, और तुम्हारे approve करने तक ये pause रहता है। यही तुम्हारा workflow है।

जो भी काम open-ended है वो थ्रेड में जाता है, और वही तुम्हारा loop है। Fallback तुम खुद हो।

3. Jev engineering

परिभाषा

ऑफिस का एक्सपर्ट हर लिफाफा खुद नहीं खोलता। रिसेप्शन पर कोई होता है जो डाक छांटता है: बिल एक तरफ, स्पैम कूड़ेदान में, कॉन्ट्रैक्ट वकील के पास।

तुम्हारा agent दो तरह के काम करता है: कुछ लिखना, और कुछ तय करना। अभी एक बड़ा मॉडल दोनों कर रहा है, यानी तुम डाक छांटने के लिए वकील को पैसे दे रहे हो।

Jev वो रिसेप्शन है। ये कभी कुछ लिखता नहीं। सिर्फ चुनता है।

ये कैसे काम करता है

तुम Jev को एक सवाल और संभावित जवाब पहले से दे देते हो। ये तीन में से कोई एक चीज़ लौटाता है, साथ में एक confidence score भी:

• हाँ या ना
• किसी सेट में से एक विकल्प
• किसी स्केल पर एक नंबर

क्योंकि ये सिर्फ चुनाव करता है, इसलिए तेज़ और सस्ता है। दावा किए गए आंकड़े 3 से 329 सेकंड के मुकाबले 70 से 500 milliseconds के हैं, और आउटपुट फ्री होने के साथ हर दस लाख input tokens की कीमत $0.042 है।

अब सच्चाई की बात। Jev को आए अभी सिर्फ दो हफ्ते हुए हैं और स्वतंत्र टेस्ट अभी आने शुरू ही हुए हैं।

• Email classification में, plain logistic regression ने 98.9 प्रतिशत स्कोर किया जबकि Jev का 98.6 रहा।
• Phishing detection में, Jev को 62.6 प्रतिशत मिला जबकि Claude Haiku 4.5 को 81.3।
• "zero hallucinations" वाले आंकड़े के साथ लेखकों का अपना footnote है: ये empirical नहीं है, इसका मतलब सिर्फ इतना है कि आउटपुट हमेशा schema से मेल खाता है।

confidence score भी out of the box कोई असली probability नहीं है। इसे ranking की तरह लो और अपने labeled data पर खुद thresholds तय करो।

इसे कैसे बनाएं

समझदारी वाला सेटअप ये है कि महंगे मॉडल के आगे एक gate लगा दो:

1. सब कुछ अंदर आता है।
2. Jev हर item के बारे में एक छोटा सा सवाल तय करता है।
3. Confident और routine: सस्ते में निपट गया। Label हो गया, route हो गया या हटा दिया गया।
4. Unsure या unusual: main model के पास गया।

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # fail closed: unsure goes to the expensive path

इन सब से पहले, सबसे आसान चीज़ आज़माओ जो काम कर सकती है। कुछ सौ असली examples label करो, एक basic classifier train करो, और तभी आगे बढ़ो जब वो काफी अच्छा न हो।

ये तीस मिनट का काम है, और यही वो baseline है जिसे किसी भी vendor के दावे को हराना होगा।

pic4. Jev जिन तीन तरह के सवालों का जवाब देता है

शॉर्टकट

Jev, Viktor के published stack का हिस्सा नहीं है, लेकिन ये आइडिया उन दो जगहों पर लागू होता है जो तुम्हारे कंट्रोल में हैं:

• Reasoning tier. ये तीन पर चलता है: Smart यानी Claude Opus पर, Balanced यानी करीब आधी कीमत पर Claude Sonnet पर, और Ultra यानी करीब दोगुनी कीमत पर Claude Fable पर। requests छांटने या एक नंबर निकालने के लिए top tier की ज़रूरत नहीं होती।
• उसके आगे का gate. अगर तुम चाहते हो कि वो support emails या alerts जैसी कोई stream संभाले, तो पूरी stream उसे मत थमा दो। पहले एक classifier या Jev call लगाओ, ताकि सिर्फ वही items उसके लिए काम बनें जिनमें फैसले की ज़रूरत हो।

ये उन दो परतों में से एक है जहाँ Viktor होने के बावजूद तुम्हारी अपनी engineering अभी भी मायने रखती है।

4. Harness engineering

परिभाषा

वही कर्मचारी, दो अलग ऑफिस। पहले में उसके पास सही टूल्स हैं, दीवार पर एक मैनुअल है, एक सहकर्मी है जो उसका काम चेक करता है, और तिजोरी की चाबी नहीं है। दूसरे में उसके पास एक लैपटॉप और तुम्हारा admin password है।

हुनर वही है, नतीजे ज़मीन-आसमान का फर्क। कर्मचारी मॉडल है। ऑफिस harness है।

Agent = model + harness.

ये कैसे काम करता है

harness वो सब कुछ है जो मॉडल नहीं है: tools, permissions, sandbox, वो फाइलें जो प्रोजेक्ट समझाती हैं, आउटपुट पर होने वाली जाँच।

2026 में ये एक अलग discipline बन गया क्योंकि लोगों ने इसे मापना शुरू किया, और मॉडल ने उम्मीद से कम फर्क डाला:

• Anthropic ने सिर्फ container resources बदले और benchmark score 6 points बढ़ गया।
• LangChain ने मॉडल को वैसा ही रखा और सिर्फ harness बदलकर उसी benchmark पर 13.7 points का फर्क डाल दिया।
• फिर उन्होंने एक ऐसे open model के इर्द-गिर्द harness tune किया जो दस गुना सस्ता था, जब तक कि उसने Opus 4.8 के 0.87 के मुकाबले 0.86 स्कोर नहीं कर लिया।

अब तुम सिर्फ मॉडल नहीं खरीद रहे हो। तुम मॉडल और harness दोनों एक साथ खरीद रहे हो।

जिस पल agent किसी असली चीज़ को छूता है — repo, inbox, payment, production database — तुम्हें harness की ज़रूरत पड़ती है।

इसे कैसे बनाएं

बाहर से अंदर की तरफ बनाओ:

1. Containment. agent भौतिक रूप से किस तक नहीं पहुँच सकता। एक container, एक अलग branch, read only database user, allowlist के अलावा कोई network नहीं। पहला prompt चलाने से पहले ये कर लो।
2. Guides. काम करने से पहले इसे क्या रास्ता दिखाता है। repo में AGENTS.md जैसी कोई फाइल, tool descriptions इतने साफ कि मॉडल सही वाला चुन ले, अच्छे आउटपुट के कुछ examples।
3. Sensors. काम करने के बाद कौन चेक करता है। Linter, type checker, test suite: तेज़ और deterministic, इसलिए इन्हें हर चीज़ पर चलाओ। धीमी जाँच, जैसे कोई दूसरा मॉडल diff रिव्यू करे, सिर्फ उन्हीं पर चलाओ जो ज़रूरी हों।
4. Permissions. जब agents मंज़ूरी माँगते हैं, तो लोग 93 प्रतिशत बार हाँ कर देते हैं। approval prompt लगभग कुछ नहीं बचाता। असली सुरक्षा वो है कि कुछ actions उपलब्ध ही न हों। approval सिर्फ उन कुछ चीज़ों के लिए बचाकर रखो जो सच में irreversible हों।

guide file लंबी होने की ज़रूरत नहीं है। चार लाइनें भी बर्ताव बदल देती हैं:

1# AGENTS.md
2- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)
3- Run tests with `make test`. They must pass before any commit
4- Never edit /migrations by hand, use `make migration`
5- DB access is read only. Ask before any schema change

Hooks इसी आइडिया का enforced version हैं। Claude Code में, hook एक छोटी script होती है जो tool call से पहले चलती है और उसे रोक सकती है। "main पर कभी push मत करो" — ये prompt की एक लाइन के बजाय एक hook के रूप में काम करता है।

एक चेतावनी। तुम्हारे harness का हर हिस्सा इस बात पर दाँव है कि मॉडल कुछ नहीं कर सकता, और इन दाँवों की मियाद खत्म होती रहती है। एक मॉडल upgrade के बाद जब एक scaffolding component की ज़रूरत ही नहीं रही, तो Anthropic ने उसे पूरा डिलीट कर दिया।

हर कुछ महीनों में अपना harness दोबारा पढ़ो और वो सब हटा दो जिसे मॉडल अब खुद कर सकता है।

pic5. Harness के चार घेरे

शॉर्टकट

अगर agent = model + harness है, तो Viktor के साथ तुम्हें ज़्यादातर harness ही मिलता है। अंदर मॉडल Claude है। मॉडल के आस-पास का सब कुछ तैयार आता है:

• Tools. 3,200+ integrations: GitHub, Linear, HubSpot, Stripe, Notion, Google Drive और भी बहुत कुछ। जिन टूल्स का connection तैयार नहीं है, वो खुद बना सकता है।
• Guides. Skills। AGENTS.md खुद लिखने की बजाय, तुम अपनी स्क्रीन रिकॉर्ड करते हो, वो प्रक्रिया का draft बनाता है, तुम उसे edit करते हो।
• Sensors. वो उन data पर निशान लगाता है जिनमें तालमेल नहीं बैठता और अधूरे briefs पर सवाल उठाता है। और हर स्टेप एक Slack thread में दर्ज होता है जिसे तुम्हारी टीम पढ़ सकती है।
• Permissions. Customer emails और financial changes approval के लिए pause हो जाते हैं। नए scheduled automations तब तक pause रहते हैं जब तक कोई उन्हें on न करे।

containment वाला हिस्सा कोई product तुम्हारे लिए नहीं बना सकता, क्योंकि वो उन credentials से बनता है जो तुम सौंपते हो। वो 93 प्रतिशत याद रखो, और उसे काम के लिए जितनी कम से कम access चाहिए उतनी ही दो:

• read only database user
• restricted Stripe key
• shared support inbox, तुम्हारा personal नहीं
• specific repos तक सीमित GitHub token

जहाँ तक वो पहुँच ही नहीं सकता, वहाँ कुछ तोड़ भी नहीं सकता।

pic6. Viktor का harness

5. Evals engineering

परिभाषा

तुम्हें कैसे पता चलेगा कि नए कर्मचारी ने तरक्की की है? तुम उसे वही टेस्ट दोबारा देते हो जो पिछले महीने दिया था और नतीजे मिलाते हो।

एक ही टेस्ट के बिना, तुम जो भी बदलाव करोगे वो अटकलबाजी होगी। Evals तुम्हारे agent के लिए वही टेस्ट हैं: कामों का एक ऐसा सेट जिनके सही जवाब तुम्हें पहले से पता हैं, और जिन्हें तुम हर बदलाव पर चलाते हो।

ये कैसे काम करता है

दो तरह की जाँच होती हैं:

• End to end. क्या आखिरी जवाब सही आया? ये बताता है कि स्कोर बदला, लेकिन क्यों नहीं बताता।
• Behavioral. क्या कोई एक खास चीज़ हुई? क्या उसने जवाब देने से पहले search कॉल किया। क्या request अस्पष्ट होने पर उसने सफाई के लिए सवाल पूछा। क्या 'done' कहने से पहले उसने verify किया।

Behavioral checks trace पर चलते हैं, यानी agent ने जो कुछ भी किया उसका log, सिर्फ आखिरी जवाब पर नहीं। Google का नियम है कि ये suite पाँच सेकंड से कम में पूरा होना चाहिए, ताकि हर बदलाव पर इसे चलाया जा सके।

अगर grading कोई मॉडल कर रहा है, तो वो judge है, और judge की भी जाँच ज़रूरी है। Airbnb ने पाया कि एक ही input को बार-बार चलाने पर उनके model generated reference answers में से करीब तीन-चौथाई हर बार अलग निकले। उनका eval असल में अपना ही noise माप रहा था।

इसे कैसे बनाएं

1. असली failures से शुरू करो। actual runs देखो, पता लगाओ क्या गलत हुआ, हर एक को test case में बदलो। Airbnb के golden sets में 50 से 100 examples चलते हैं, और failures का होना ज़रूरी है।
2. हर case के लिए एक behavioral check लिखो। एक case, एक चीज़ verify करने के लिए।
3. अपने judge को चेक करो। भरोसा करने से पहले एक sample को हाथ से grade करो और देखो कि तुम और मॉडल कितनी बार एकमत होते हो।
4. Production से sample लो। Airbnb हर दिन live traffic का 5 प्रतिशत खींचता है। जैसे-जैसे असली इस्तेमाल बदलता है, तुम्हारा eval set पुराना होता जाता है।

एक single case इतना छोटा हो सकता है:

1input: "Refund order #1042, customer says it arrived broken"
2expect:
3  - looks up the order before replying
4  - asks for approval before issuing the refund
5check:
6  - trace has get_order before send_reply
7  - trace has approval_request before refund

overall pass rate पर नज़र मत रखो। वो ऊपर जा सकता है जबकि कोई खास behavior चुपचाप टूट रहा हो। individual checks पर ध्यान दो।

pic7. अच्छे eval cases कहाँ से आते हैं

शॉर्टकट

कोई product ये परत तुम्हारे लिए तैयार नहीं कर सकता, क्योंकि तुम्हारे बिज़नेस के लिए सही जवाब कैसा दिखता है ये सिर्फ तुम जानते हो। लेकिन तरीका सीधा लागू होता है:

• दो हफ्ते बाद, उसके 20 ऐसे threads चुनो जिनके सही जवाब तुम्हें पता हैं। वो सब शामिल करो जहाँ तुम्हें उसे सुधारना पड़ा हो।
• हर case के लिए एक साधारण check लिखो। क्या उसने हर नंबर के लिए source link किया, क्या brief अस्पष्ट होने पर उसने सवाल पूछा, क्या कंपनी से कुछ बाहर जाने से पहले वो रुका।
• हर बदलाव के बाद सेट दोबारा चलाओ: नई skill, edited brief, अलग tier। Smart से Balanced पर जाने से करीब आधे credits बचते हैं, इसलिए पक्का बदलने से पहले इसे टेस्ट कर लो।
• हफ्ते में एक बार, पाँच random threads को हाथ से grade करो।

सबको एक साथ जोड़ना

पाँच परतें, पाँच सवाल। Context वो है जो इसे दिखता है। Loop वो है जो तय करता है कि फैसला कौन लेगा। Jev सस्ते फैसले संभालता है। Harness वो है कि ये कहाँ तक पहुँच सकता है और कौन चेक कर रहा है। Evals वो हैं जिनसे तुम्हें पता चलता है।

Viktor के साथ, इनमें से तीन ज़्यादातर बने-बनाए आते हैं: context, loop और harness। Jev, evals और जो credentials तुम देते हो, वो तुम्हारी engineering पर निर्भर करते हैं।

अगर तुम आज शुरू कर रहे हो, तो हर एक पर सबसे सस्ता और काम का कदम ये है:

• Context: अपनी stable instructions को system prompt में डाल दो और उन्हें बदलना बंद करो।
• Loop: इसे चलता छोड़ने से पहले turn limit और dollar limit लगा दो।
• Jev: agent जो सबसे ज़्यादा तय करता है, उसके 200 examples label करो।
• Harness: agent को ऐसे user के रूप में चलाओ जो कुछ delete न कर सके।
• Evals: अपनी पिछली पाँच failures को test cases के रूप में लिख लो।

Viktor पर, वही दिन कुछ ऐसा दिखेगा:

• Context: company brief लिखो और अपनी पहली skill record करो।
• Loop: हर task में 'done' की परिभाषा रखो और tier सोच-समझकर चुनो।
• Harness: उसे read only, scoped credentials के साथ connect करो।
• Jev: किसी भी stream को उसके tasks बनने से पहले filter करो।
• Evals: 20 असली threads को अपना पहला test set बनाकर save करो।

ये एक दिन का काम है और ये पाँचों को कवर कर लेता है।

मेरी राय: अब मॉडल मुश्किल हिस्सा नहीं रहा। उसके आस-पास की पाँच परतें मुश्किल हैं। इन्हें सही कर लो और तुम बिना नए लोगों को हायर किए capacity बढ़ा लोगे। ज़्यादातर टीमों को पहली तीन तैयार मिल जानी चाहिए और अपना समय उन दो पर लगाना चाहिए जो quality तय करती हैं — सस्ते फैसले और evals।

इस आर्टिकल को sponsor करने के लिए Viktor का शुक्रिया।

@viktor_com पर मुफ्त आज़माओ। $100 credits, कार्ड की ज़रूरत नहीं। पूरा लिंक मेरे पहले reply में है।

Sign up करते समय YARCHI100 कोड का इस्तेमाल करो।

Paid Partnership