AI एजेंट्स बनानामध्यमपाठ 2067 मिनट का पाठ

एजेंट्स के लिए कॉस्ट, लेटेन्सी और रिलायबिलिटी

एजेंट कई कॉल्स करते हैं, इसलिए छोटी-छोटी लागत और देरी मिलकर बहुत बढ़ जाती हैं। बजट, कैशिंग, पैरेलल टूल कॉल्स, टाइमआउट, फ़ॉलबैक और किसी इंसान को काम कब सौंपना है, यह सीखें।

पाठ वीडियो में

60 सेकंड में

एजेंट्स के लिए कॉस्ट, लेटेन्सी और रिलायबिलिटी

एजेंट कई कॉल्स करते हैं, इसलिए छोटी-छोटी लागत और देरी मिलकर बहुत बढ़ जाती हैं। बजट, कैशिंग, पैरेलल टूल कॉल्स, टाइमआउट, फ़ॉलबैक और किसी इंसान को काम कब सौंपना है, यह सीखें।

1/4
आसान शब्दों में
रोड ट्रिप पर निकला एक परिवार पेट्रोल का बजट तय करता है, ट्रैफ़िक से बचने के लिए जल्दी निकलता है, एक अतिरिक्त पहिया (स्टेपनी) साथ रखता है, और जानता है कि कब रुककर रास्ता पूछना है। एक अच्छे एजेंट की भी यही आदतें होती हैं: एक बजट, तेज़ी लाने के तरीके, एक बैकअप प्लान, और किसी इंसान से पूछने का सही समय।
हर मॉडल कॉल में टोकन और समय खर्च होता है। एक एजेंट जो 15 स्टेप्स लेता है, और हर बार बढ़ता हुआ कॉन्टेक्स्ट दोबारा भेजता है, वह आपकी उम्मीद से कहीं ज़्यादा धीमा और महंगा हो सकता है। और किसी मॉडल या टूल की हर कॉल फेल भी हो सकती है। यह पाठ इन व्यावहारिक कंट्रोल्स को एक साथ लाता है।

खर्च कहाँ से आता है

  • Input tokens हर स्टेप पर बढ़ते जाते हैं, क्योंकि आमतौर पर पूरा कॉन्टेक्स्ट फिर से भेजा जाता है।
  • टूल के बड़े रिज़ल्ट, जैसे पूरे वेब पेज या फ़ाइलें, कॉन्टेक्स्ट को तेज़ी से भर देते हैं।
  • Retries और loops काम को दोहराते हैं।
  • Output tokens, जिनमें लंबी रीज़निंग शामिल है, उनकी प्रति-टोकन कीमत अक्सर इनपुट से ज़्यादा होती है। अपने प्रोवाइडर की मौजूदा कीमतें देखें।

असरदार कंट्रोल्स

कंट्रोलयह क्या करता हैकैसे
टोकन और पैसों का बजटऐसे टास्क को रोक देता है जो बहुत ज़्यादा खर्च करता है।API रिस्पॉन्स से प्रति रन टोकन गिनें; बजट पूरा होने पर टास्क रोकें और रिपोर्ट करें।
टूल के रिज़ल्ट्स को ट्रिम करनाकॉन्टेक्स्ट को छोटा रखता है।केवल ज़रूरी फ़ील्ड्स वापस भेजें; लंबे टेक्स्ट को काटें; बाकी को कहीं स्टोर करें और उसका सिर्फ़ रेफरेंस दें।
Prompt cachingजब कई कॉल्स की शुरुआत एक जैसी होती है, तो यह लागत और देरी को कम कर सकता है।कई प्रोवाइडर्स इसे ऑफ़र करते हैं। न बदलने वाले हिस्सों (निर्देश, टूल डेफ़िनिशन) को शुरुआत में रखें। देखें कि आपका प्रोवाइडर इसे कैसे करता है।
Result cachingएक ही टूल कॉल को बार-बार दोहराने से बचाता है।रीड-ओनली टूल रिज़ल्ट्स को टूल के नाम और आर्ग्युमेंट्स के आधार पर थोड़े समय के लिए कैश करें।
Parallel tool callsइंतज़ार का समय बचाता है।कुछ APIs मॉडल को एक साथ कई स्वतंत्र टूल कॉल्स करने की अनुमति देती हैं; उन्हें एक साथ चलाएं।
ज़रूरत के हिसाब से सही मॉडलआसान स्टेप्स पर खर्च बचाता है।राउटिंग या एक्सट्रैक्शन जैसे आसान स्टेप्स के लिए छोटे मॉडल का इस्तेमाल करें, बशर्ते टेस्टिंग में वह काफ़ी साबित हो।

Timeouts, retries और fallbacks

reliable.py: budget, timeout, retry with backoff, fallbackpython
import random, time

class BudgetExceeded(Exception):
    pass

class Budget:
    def __init__(self, max_tokens: int):
        self.max_tokens, self.used = max_tokens, 0
    def spend(self, tokens: int):
        self.used += tokens
        if self.used > self.max_tokens:
            raise BudgetExceeded("used " + str(self.used) + " tokens")

def call_model(prompt: str, timeout: float) -> tuple:
    # Placeholder: call your provider with this timeout.
    # Returns (text, tokens_used). Here it sometimes fails, for the demo.
    if random.random() < 0.3:
        raise TimeoutError("model did not answer in time")
    return "ok: " + prompt[:30], 500

def reliable_call(prompt: str, budget: Budget, tries: int = 3) -> str:
    for attempt in range(tries):
        try:
            text, tokens = call_model(prompt, timeout=30)
            budget.spend(tokens)
            return text
        except TimeoutError:
            wait = (2 ** attempt) + random.random()   # backoff with jitter
            time.sleep(wait * 0.01)                    # shortened for the demo
    return "FALLBACK: could not reach the model; handing over to a person."

budget = Budget(max_tokens=5000)
try:
    for step in range(20):
        print(step, reliable_call("step " + str(step), budget))
except BudgetExceeded as err:
    print("Stopped:", err)
Backoff का मतलब है हर नाकामी के बाद थोड़ा ज़्यादा इंतज़ार करना, ताकि किसी व्यस्त सर्विस पर रिक्वेस्ट्स की बाढ़ न आ जाए। Jitter थोड़ा रैंडम गैप जोड़ता है ताकि बहुत सारे क्लाइंट एक ही पल में दोबारा कोशिश न करें। सिर्फ़ उन एरर्स के लिए retry करें जो अपने आप ठीक हो सकते हैं (timeouts, "busy" रिस्पॉन्स), न कि "invalid argument" जैसी गलतियों के लिए। और केवल उन्हीं राइट टूल्स को दोबारा चलाएं जो idempotent हों (पाठ 2)।

Fallbacks और इंसान को काम सौंपना

  1. 1

    Retry

    छोटी, अस्थायी नाकामियों के लिए, बैकऑफ़ और एक छोटी लिमिट के साथ।
  2. 2

    Fall back

    कोई आसान रास्ता आज़माएं: कोई दूसरा मॉडल, पहले से कैश किया गया जवाब, या आम मामलों के लिए तय किया गया फ़िक्स्ड वर्कफ़्लो।
  3. 3

    साफ़गोई से अधूरा जवाब देना

    अधूरा जवाब दें और साफ़ बताएं कि क्या चीज़ छूट गई है।
  4. 4

    इंसान को काम सौंपना

    मामले को एक छोटे सारांश और ट्रेस आईडी के साथ आगे बढ़ाएं, ताकि उन्हें शून्य से शुरू न करना पड़े।
किसी इंसान को काम तब सौंपें जब: बजट या स्टेप लिमिट पूरी हो जाए, एजेंट को भरोसा न हो, यूज़र नाराज़ हो या किसी इंसान से बात करने को कहे, या अगला एक्शन जोखिम भरा हो और मंज़ूरी की ज़रूरत हो। एक अच्छा हैंडऑफ़ तेज़ होता है और उसमें यह शामिल होता है कि एजेंट पहले क्या आज़मा चुका है।

Latency: इसे तेज़ महसूस कराना

  • स्वतंत्र टूल कॉल्स को पैरेलल चलाएं।
  • अंतिम उत्तर को स्ट्रीम करें ताकि यूज़र को टेक्स्ट लिखते हुए दिखे।
  • लंबे टास्क के लिए प्रोग्रेस दिखाएं ("3 सप्लायर्स चेक किए जा रहे हैं… 2 पूरे हुए")।
  • स्टेप्स कम करें: बेहतर टूल डिज़ाइन अक्सर कई गैर-ज़रूरी राउंड ट्रिप्स को पूरी तरह हटा देता है।
  • सिर्फ़ हर कॉल के लिए ही नहीं, बल्कि पूरे टास्क के लिए कुल समय सीमा तय करें।
सावधान रहें
बजट एक सिक्योरिटी कंट्रोल भी हैं। इनके बिना, कोई यूज़र या इंजेक्ट किया गया निर्देश आपके एजेंट को लूप में फंसाकर भारी बिल बना सकता है। देखें Unbounded consumption: denial of wallet।
यह करके देखें। ऊपर दिए गए कोड को कुछ बार चलाएं। यह कितनी बार फ़ॉलबैक करता है? max_tokens को 2000 में बदलें और देखें कि यह कहाँ रुकता है।

और देखें और पढ़ें

लैब

आपके एजेंट के लिए एक लागत और रिलायबिलिटी प्लान, जो आपके इवैल रन के आंकड़ों पर आधारित हो।

~35 min

समस्या

पाठ 10 की लैब से अपने एजेंट और इवैल सेट का इस्तेमाल करें (फ़ेक टूल्स भी चलेंगे; अगर आपके पास असली API नहीं है, तो कैरेक्टर्स को 4 से भाग देकर "टोकन्स" गिनें)।

  1. हर रन के लिए टोकन्स और समय रिकॉर्ड करें। प्रति टास्क औसत और सबसे खराब स्थिति रिपोर्ट करें।
  2. प्रति-टास्क टोकन बजट और कुल समय सीमा जोड़ें। ऐसा एक परिदृश्य दिखाएं जहाँ दोनों रन को रोकते हों।
  3. अस्थिर फ़ेक टूल के लिए बैकऑफ़ के साथ रिट्राय जोड़ें, और एक फ़ॉलबैक संदेश जोड़ें जो ट्रेस आईडी के साथ किसी इंसान को काम सौंपता हो।
  4. पाठ में से दो बदलाव चुनें (रिज़ल्ट्स ट्रिम करना, कैशिंग, पैरेलल कॉल्स, किसी एक स्टेप के लिए छोटा मॉडल)। उनके प्रभाव का अनुमान लगाएं, उन्हें आज़माएं, और अपने अनुमान से तुलना करें।

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1प्रॉम्प्ट कैशिंग जोड़ने से आपकी औसत लागत तो घट गई, लेकिन सबसे खराब स्थिति की लागत में कोई बदलाव नहीं हुआ। इसकी क्या वजह हो सकती है?दिखाएं

कैशिंग तब मदद करती है जब कई कॉल्स की शुरुआत एक जैसी होती है। सबसे खराब स्थिति वाले रन शायद लंबे लूप होते हैं या टूल के बहुत बड़े रिज़ल्ट्स वाले रन होते हैं, जहाँ ज़्यादातर टोकन्स नया कंटेंट होते हैं, न कि शेयर किया गया प्रीफ़िक्स। सबसे खराब स्थिति को ठीक करने के लिए, आपको केवल कैशिंग ही नहीं, बल्कि बजट, लूप डिटेक्शन और बड़े रिज़ल्ट्स को ट्रिम करने की ज़रूरत होती है।

Q2अगर आप सावधान न रहें, तो किसी छोटे और तेज़ मॉडल पर फ़ॉलबैक करने से सिस्टम कुल मिलाकर कम रिलायबल क्यों बन सकता है?दिखाएं

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

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

मैं कैसे अंदाज़ा लगाऊं कि किसी एजेंट का खर्च कितना आएगा?

अपने इवैल परिदृश्यों को चलाएं, हर कॉल के आने वाले और जाने वाले टोकन्स रिकॉर्ड करें, और प्रति टास्क औसत व सबसे खराब स्थिति (worst case) का हिसाब लगाएं। इसे अपने प्रोवाइडर की मौजूदा कीमतों और संभावित उपयोग से गुणा करें। सबसे खराब स्थिति मायने रखती है: बेकाबू हो चुके कुछ ही रन सामान्य रनों की तुलना में बहुत ज़्यादा महंगे पड़ सकते हैं।

क्या सबसे सस्ता मॉडल हमेशा सबसे किफ़ायती विकल्प होता है?

हमेशा नहीं। एक कमज़ोर मॉडल को ज़्यादा स्टेप्स, ज़्यादा रिट्राय या ज़्यादा बार इंसानों की मदद की ज़रूरत पड़ सकती है, जिससे हर सफल टास्क की लागत बढ़ सकती है। प्रति कॉल लागत के बजाय प्रति सफल टास्क लागत मापें।

मुझे कौन सा टाइमआउट इस्तेमाल करना चाहिए?

अपने ट्रेसेस देखें: सामान्य कॉल्स में कितना समय लगता है? टाइमआउट को सामान्य से थोड़े धीमे स्तर से थोड़ा ऊपर सेट करें, और पूरे टास्क के लिए एक अलग कुल समय सीमा तय करें। बहुत लंबी रीज़निंग कॉल्स के लिए छोटी कॉल्स की तुलना में ज़्यादा लंबे टाइमआउट की ज़रूरत हो सकती है।

क्या कैशिंग गलत जवाब दे सकती है?

हाँ, अगर डेटा बदल गया हो। केवल रीड-ओनली रिज़ल्ट्स को कैश करें, बदलने वाले डेटा (कीमतें, स्टॉक, ट्रेन का स्टेटस) के लिए कैश का समय कम रखें, और कैश किए गए प्राइवेट डेटा को कभी भी यूज़र्स के बीच शेयर न करें।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें