Retries, Fallbacks और Timeouts

विफल होती call की योजना बनाएँ

Model providers को network calls विफल होती हैं: rate limits, timeouts, अस्थायी 5xx errors। हर runnable में प्रयासों की सीमा और (वैकल्पिक) exponential backoff के साथ errors पर retry के लिए .with_retry(...) और विफल होने पर वैकल्पिक runnable (जैसे दूसरा provider या सस्ता मॉडल) पर जाने के लिए .with_fallbacks([...]) है। मॉडल पर ही timeouts और अधिकतम retries भी रखें, और सिर्फ़ वही errors retry करें जिन्हें दोहराना सुरक्षित है; ईमेल भेजने जैसे दुष्प्रभाव वाले चरणों को आँख मूँदकर retry न करें।

Retry और fallback, चलाकर

मैंने यह Python virtual environment में langchain-core 1.6.6, langchain-text-splitters 1.1.2 और llama-index-core 0.14.25 के साथ ऑफ़लाइन चलाया। किसी API key या network call की ज़रूरत नहीं क्योंकि असली मॉडल की जगह fake मॉडल या खिलौना embedding है। Flaky function दो बार विफल होता है और तीसरी call पर सफल, और with_retry "ok after 3 calls" लौटाता है। हमेशा विफल होने वाला runnable (1/0) backup पर fallback होकर "fallback answer" लौटाता है।

from langchain_core.runnables import RunnableLambda

calls = {"n": 0}
def flaky(x):
    calls["n"] += 1
    if calls["n"] < 3:
        raise ValueError("temporary failure")
    return f"ok after {calls['n']} calls"

chain = RunnableLambda(flaky).with_retry(stop_after_attempt=4, wait_exponential_jitter=False)
print(chain.invoke("x"))

backup = RunnableLambda(lambda x: "fallback answer")
broken = RunnableLambda(lambda x: 1 / 0).with_fallbacks([backup])
print(broken.invoke("x"))

Output:

ok after 3 calls
fallback answer

त्वरित जाँच: किसी चरण को आँख मूँदकर retry कब नहीं करना चाहिए?

• जब वह pure function हो
• जब उसके दुष्प्रभाव हों, जैसे ईमेल भेजना
• जब वह केवल-पढ़ने वाला lookup हो
• जब वह तेज़ हो