एजेंट्स के लिए कॉस्ट, लेटेन्सी और रिलायबिलिटी
एजेंट कई कॉल्स करते हैं, इसलिए छोटी-छोटी लागत और देरी मिलकर बहुत बढ़ जाती हैं। बजट, कैशिंग, पैरेलल टूल कॉल्स, टाइमआउट, फ़ॉलबैक और किसी इंसान को काम कब सौंपना है, यह सीखें।
60 सेकंड में
एजेंट्स के लिए कॉस्ट, लेटेन्सी और रिलायबिलिटी
एजेंट कई कॉल्स करते हैं, इसलिए छोटी-छोटी लागत और देरी मिलकर बहुत बढ़ जाती हैं। बजट, कैशिंग, पैरेलल टूल कॉल्स, टाइमआउट, फ़ॉलबैक और किसी इंसान को काम कब सौंपना है, यह सीखें।
खर्च कहाँ से आता है
- Input tokens हर स्टेप पर बढ़ते जाते हैं, क्योंकि आमतौर पर पूरा कॉन्टेक्स्ट फिर से भेजा जाता है।
- टूल के बड़े रिज़ल्ट, जैसे पूरे वेब पेज या फ़ाइलें, कॉन्टेक्स्ट को तेज़ी से भर देते हैं।
- Retries और loops काम को दोहराते हैं।
- Output tokens, जिनमें लंबी रीज़निंग शामिल है, उनकी प्रति-टोकन कीमत अक्सर इनपुट से ज़्यादा होती है। अपने प्रोवाइडर की मौजूदा कीमतें देखें।
असरदार कंट्रोल्स
| कंट्रोल | यह क्या करता है | कैसे |
|---|---|---|
| टोकन और पैसों का बजट | ऐसे टास्क को रोक देता है जो बहुत ज़्यादा खर्च करता है। | API रिस्पॉन्स से प्रति रन टोकन गिनें; बजट पूरा होने पर टास्क रोकें और रिपोर्ट करें। |
| टूल के रिज़ल्ट्स को ट्रिम करना | कॉन्टेक्स्ट को छोटा रखता है। | केवल ज़रूरी फ़ील्ड्स वापस भेजें; लंबे टेक्स्ट को काटें; बाकी को कहीं स्टोर करें और उसका सिर्फ़ रेफरेंस दें। |
| Prompt caching | जब कई कॉल्स की शुरुआत एक जैसी होती है, तो यह लागत और देरी को कम कर सकता है। | कई प्रोवाइडर्स इसे ऑफ़र करते हैं। न बदलने वाले हिस्सों (निर्देश, टूल डेफ़िनिशन) को शुरुआत में रखें। देखें कि आपका प्रोवाइडर इसे कैसे करता है। |
| Result caching | एक ही टूल कॉल को बार-बार दोहराने से बचाता है। | रीड-ओनली टूल रिज़ल्ट्स को टूल के नाम और आर्ग्युमेंट्स के आधार पर थोड़े समय के लिए कैश करें। |
| Parallel tool calls | इंतज़ार का समय बचाता है। | कुछ APIs मॉडल को एक साथ कई स्वतंत्र टूल कॉल्स करने की अनुमति देती हैं; उन्हें एक साथ चलाएं। |
| ज़रूरत के हिसाब से सही मॉडल | आसान स्टेप्स पर खर्च बचाता है। | राउटिंग या एक्सट्रैक्शन जैसे आसान स्टेप्स के लिए छोटे मॉडल का इस्तेमाल करें, बशर्ते टेस्टिंग में वह काफ़ी साबित हो। |
Timeouts, retries और fallbacks
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)Fallbacks और इंसान को काम सौंपना
- 1
Retry
छोटी, अस्थायी नाकामियों के लिए, बैकऑफ़ और एक छोटी लिमिट के साथ। - 2
Fall back
कोई आसान रास्ता आज़माएं: कोई दूसरा मॉडल, पहले से कैश किया गया जवाब, या आम मामलों के लिए तय किया गया फ़िक्स्ड वर्कफ़्लो। - 3
साफ़गोई से अधूरा जवाब देना
अधूरा जवाब दें और साफ़ बताएं कि क्या चीज़ छूट गई है। - 4
इंसान को काम सौंपना
मामले को एक छोटे सारांश और ट्रेस आईडी के साथ आगे बढ़ाएं, ताकि उन्हें शून्य से शुरू न करना पड़े।
Latency: इसे तेज़ महसूस कराना
- स्वतंत्र टूल कॉल्स को पैरेलल चलाएं।
- अंतिम उत्तर को स्ट्रीम करें ताकि यूज़र को टेक्स्ट लिखते हुए दिखे।
- लंबे टास्क के लिए प्रोग्रेस दिखाएं ("3 सप्लायर्स चेक किए जा रहे हैं… 2 पूरे हुए")।
- स्टेप्स कम करें: बेहतर टूल डिज़ाइन अक्सर कई गैर-ज़रूरी राउंड ट्रिप्स को पूरी तरह हटा देता है।
- सिर्फ़ हर कॉल के लिए ही नहीं, बल्कि पूरे टास्क के लिए कुल समय सीमा तय करें।
max_tokens को 2000 में बदलें और देखें कि यह कहाँ रुकता है।और देखें और पढ़ें
लैब
आपके एजेंट के लिए एक लागत और रिलायबिलिटी प्लान, जो आपके इवैल रन के आंकड़ों पर आधारित हो।
समस्या
पाठ 10 की लैब से अपने एजेंट और इवैल सेट का इस्तेमाल करें (फ़ेक टूल्स भी चलेंगे; अगर आपके पास असली API नहीं है, तो कैरेक्टर्स को 4 से भाग देकर "टोकन्स" गिनें)।
- हर रन के लिए टोकन्स और समय रिकॉर्ड करें। प्रति टास्क औसत और सबसे खराब स्थिति रिपोर्ट करें।
- प्रति-टास्क टोकन बजट और कुल समय सीमा जोड़ें। ऐसा एक परिदृश्य दिखाएं जहाँ दोनों रन को रोकते हों।
- अस्थिर फ़ेक टूल के लिए बैकऑफ़ के साथ रिट्राय जोड़ें, और एक फ़ॉलबैक संदेश जोड़ें जो ट्रेस आईडी के साथ किसी इंसान को काम सौंपता हो।
- पाठ में से दो बदलाव चुनें (रिज़ल्ट्स ट्रिम करना, कैशिंग, पैरेलल कॉल्स, किसी एक स्टेप के लिए छोटा मॉडल)। उनके प्रभाव का अनुमान लगाएं, उन्हें आज़माएं, और अपने अनुमान से तुलना करें।
आपका काम तब पूरा होगा जब
कठिन सवाल
उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।
Q1प्रॉम्प्ट कैशिंग जोड़ने से आपकी औसत लागत तो घट गई, लेकिन सबसे खराब स्थिति की लागत में कोई बदलाव नहीं हुआ। इसकी क्या वजह हो सकती है?दिखाएं
कैशिंग तब मदद करती है जब कई कॉल्स की शुरुआत एक जैसी होती है। सबसे खराब स्थिति वाले रन शायद लंबे लूप होते हैं या टूल के बहुत बड़े रिज़ल्ट्स वाले रन होते हैं, जहाँ ज़्यादातर टोकन्स नया कंटेंट होते हैं, न कि शेयर किया गया प्रीफ़िक्स। सबसे खराब स्थिति को ठीक करने के लिए, आपको केवल कैशिंग ही नहीं, बल्कि बजट, लूप डिटेक्शन और बड़े रिज़ल्ट्स को ट्रिम करने की ज़रूरत होती है।
Q2अगर आप सावधान न रहें, तो किसी छोटे और तेज़ मॉडल पर फ़ॉलबैक करने से सिस्टम कुल मिलाकर कम रिलायबल क्यों बन सकता है?दिखाएं
फ़ॉलबैक पाथ बहुत कम चलता है, इसलिए इसकी टेस्टिंग कम होती है। जब मुख्य मॉडल डाउन होता है, तो सारा ट्रैफ़िक अचानक ऐसे रास्ते से गुज़रता है जो शायद ज़्यादा बार फ़ेल हो सकता है या अलग तरह का व्यवहार कर सकता है, जैसे कि टूल कॉल्स या आउटपुट फ़ॉर्मेट के मामले में। अपने इवैल सेट में फ़ॉलबैक पाथ को शामिल करें और नियमित रूप से उसकी टेस्टिंग करें, या इसके बजाय एक सीधे-सादे ईमानदार संदेश और इंसान पर फ़ॉलबैक करें।
अक्सर पूछे जाने वाले सवाल
मैं कैसे अंदाज़ा लगाऊं कि किसी एजेंट का खर्च कितना आएगा?
अपने इवैल परिदृश्यों को चलाएं, हर कॉल के आने वाले और जाने वाले टोकन्स रिकॉर्ड करें, और प्रति टास्क औसत व सबसे खराब स्थिति (worst case) का हिसाब लगाएं। इसे अपने प्रोवाइडर की मौजूदा कीमतों और संभावित उपयोग से गुणा करें। सबसे खराब स्थिति मायने रखती है: बेकाबू हो चुके कुछ ही रन सामान्य रनों की तुलना में बहुत ज़्यादा महंगे पड़ सकते हैं।
क्या सबसे सस्ता मॉडल हमेशा सबसे किफ़ायती विकल्प होता है?
हमेशा नहीं। एक कमज़ोर मॉडल को ज़्यादा स्टेप्स, ज़्यादा रिट्राय या ज़्यादा बार इंसानों की मदद की ज़रूरत पड़ सकती है, जिससे हर सफल टास्क की लागत बढ़ सकती है। प्रति कॉल लागत के बजाय प्रति सफल टास्क लागत मापें।
मुझे कौन सा टाइमआउट इस्तेमाल करना चाहिए?
अपने ट्रेसेस देखें: सामान्य कॉल्स में कितना समय लगता है? टाइमआउट को सामान्य से थोड़े धीमे स्तर से थोड़ा ऊपर सेट करें, और पूरे टास्क के लिए एक अलग कुल समय सीमा तय करें। बहुत लंबी रीज़निंग कॉल्स के लिए छोटी कॉल्स की तुलना में ज़्यादा लंबे टाइमआउट की ज़रूरत हो सकती है।
क्या कैशिंग गलत जवाब दे सकती है?
हाँ, अगर डेटा बदल गया हो। केवल रीड-ओनली रिज़ल्ट्स को कैश करें, बदलने वाले डेटा (कीमतें, स्टॉक, ट्रेन का स्टेटस) के लिए कैश का समय कम रखें, और कैश किए गए प्राइवेट डेटा को कभी भी यूज़र्स के बीच शेयर न करें।
पाठ का टेस्ट
5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।