Agent API के हर प्रयास स्तर में सुधार

Perplexity Agent API में प्रयास स्तर डेवलपर्स को हर कार्य के लिए लागत, गति और शोध की गहराई का संतुलन चुनने देते हैं। आज से, हर प्रयास स्तर की प्रति क्वेरी लागत कम है, और शोध की गुणवत्ता पहले से बेहतर या समान है। सबसे व्यापक और विस्तृत शोध के लिए नया ultra स्तर उपलब्ध है। कोई भी अनुरोध जो स्तर को नाम से चुनता है, जैसे effort="fast", उसे अपडेट किया गया कॉन्फ़िगरेशन अपने आप मिल जाता है।

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

ये सुधार दो तरह के बदलावों से आए। बजट, कॉन्टेक्स्ट हैंडलिंग और एक्सट्रैक्शन ने हर रन की लागत कम की, और कौशल, मॉडल चयन और समानांतर एजेंटों ने उत्तर की गुणवत्ता को बढ़ाया या बनाए रखा।

medium का प्रदर्शन BrowseComp और DSQA पर 55% से बढ़कर 77% हो गया, जबकि लागत लगभग 90% घट गई। BrowseComp और DSQA सार्वजनिक शोध बेंचमार्क हैं; WANDR लंबे, कई इकाइयों वाले शोध कार्यों का Perplexity का बेंचमार्क है। xhigh एजेंटिक कार्य करता है, जैसे सैंडबॉक्स में कोड चलाना, लंबे टूल-उपयोग लूप बनाए रखना और एक साथ कई स्रोतों पर काम करना। xhigh ने अपना WANDR स्कोर 76.5% पर बनाए रखा, जबकि यह अगस्त 2026 के कॉन्फ़िगरेशन की लागत के लगभग 25% पर चल रहा था।

एक गहन शोध अनुरोध उत्तर देने से पहले दर्जनों खोजें चला सकता है, सैकड़ों पेज पढ़ सकता है और साक्ष्यों की जाँच कर सकता है। इनमें से हर क्रिया कॉन्टेक्स्ट में टोकन और बिल में डॉलर जोड़ती है। सीमाओं के बिना, एजेंट ऐसी क्रियाएँ करता रहता है जो उत्तर को बेहतर बनाए बिना लागत बढ़ाती हैं और कॉन्टेक्स्ट को भर देती हैं। उस लागत के अधिकांश हिस्से के पीछे पाँच कारक होते हैं:

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

इनमें से हर चुनौती को हल करने से प्रदर्शन घटाए बिना हर प्रयास स्तर की लागत कम हुई।

हर प्रयास स्तर का एक निश्चित शोध बजट होता है, जिसके तीन घटक हैं:

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

बजट मुख्य ट्रेडऑफ़ है: ज़्यादा स्टेप का मतलब बेहतर उत्तर है, और हर स्टेप पर लागत आती है। openai/gpt-6-luna के साथ, स्टेप सीमा 1 से बढ़ाकर 15 करने पर BrowseComp + DSQA पर सटीकता 41% से बढ़कर 80% हो जाती है, जबकि प्रति क्वेरी लागत $0.0017 से बढ़कर $0.0152 हो जाती है, यानी लगभग 2 गुना स्कोर के लिए लगभग 9 गुना लागत।

केवल स्टेप सीमा से शोध की लागत नियंत्रित नहीं होती। पाँच स्टेप के समान बजट में, openai/gpt-6.1-terra, openai/gpt-6-luna की तुलना में ज़्यादा टूल कॉल करता है, क्योंकि अधिक सक्षम मॉडल अक्सर एक ही स्टेप में कई कॉल करते हैं। प्रयास स्तर टूल कॉल और स्टेप, दोनों को सीमित करते हैं। इन मॉडलों के लिए, टूल-कॉल सीमा उतनी ही मायने रखती है जितनी स्टेप सीमा।

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

बजट रिमाइंडर वाले और बिना बजट रिमाइंडर वाले दो एजेंटों का परीक्षण एक BrowseComp कार्य पर किया गया, जिसमें तीन कलाकारों की जीवनियाँ देकर 1990 के दशक की एक टीवी सीरीज़ की पहचान करनी थी। रिमाइंडर वाले एजेंट ने बजट के 40 में से 13 स्टेप का उपयोग करके सही उत्तर ढूँढ लिया। बिना बजट रिमाइंडर वाले एजेंट ने सभी 40 स्टेप इस्तेमाल किए और सही उत्तर नहीं ढूँढ पाया। उस एजेंट का लूप अप्रत्याशित रूप से समाप्त हो गया, और मॉडल को बचे हुए शोध बजट की जानकारी नहीं थी। रिमाइंडर एजेंटों को केंद्रित रखते हैं और बचे हुए संसाधनों को प्रभावी ढंग से प्राथमिकता देने में उनकी मदद करते हैं।

लंबे समय तक चलने वाले शोध कार्य मॉडल की कॉन्टेक्स्ट विंडो को खोज परिणामों, फ़ेच किए गए पेज और बीच के नोट्स से भर देते हैं। विंडो भर जाने पर एजेंट को काम रोकना पड़ता है।

कॉम्पैक्शन लंबे रन को कॉन्टेक्स्ट विंडो भरे बिना चालू रखता है। जब कॉन्टेक्स्ट एक सीमा से अधिक हो जाता है, तो एजेंट अब तक के काम को एक छोटे सारांश से बदल देता है, जिसमें बताया जाता है कि उसने क्या पाया है और क्या बाकी है, और फिर काम जारी रखता है।

कॉम्पैक्शन हमेशा तीन चीज़ों को कॉन्टेक्स्ट में बनाए रखता है: सिस्टम प्रॉम्प्ट, मूल अनुरोध और वे सभी कौशल जिन्हें एजेंट पहले ही लोड कर चुका है। हर कॉम्पैक्शन के बाद, एजेंट को दो छोटे निर्देश मिलते हैं। पहला निर्देश है, ‘कार्य पूरा होने तक काम करते रहें।’ इससे एजेंट सारांश को रुकने का बिंदु नहीं मानता। दूसरा निर्देश एजेंट को बताता है कि कितने कॉम्पैक्शन हो चुके हैं, ताकि वह अपने बचे हुए शोध कार्यों की योजना बना सके। लंबे रन में मूल लक्ष्य और योजना ध्यान में बने रहते हैं, और गुणवत्ता में कमी के बिना लंबे लूप की लागत घट जाती है।

एजेंट जो भी पेज पढ़ता है, वह उसके कॉन्टेक्स्ट में जुड़ जाता है, और एजेंट उसे हर अगले स्टेप में साथ लेकर चलता है। किसी वेब पेज में प्रश्न से असंबंधित जानकारी होती है, जैसे नेविगेशन, बॉयलरप्लेट और अन्य सामग्री।

एजेंट को पूरा पेज देने के बजाय, fetch_url पहले एक एक्सट्रैक्शन पास चलाता है। पेज का टेक्स्ट एजेंट के मौजूदा कार्य के साथ एक छोटे मॉडल को भेजा जाता है। मॉडल केवल प्रासंगिक अंश लौटाता है, जिन्हें हूबहू उद्धृत किया जाता है ताकि एजेंट उनका हवाला दे सके। एक मूल्यांकन के दौरान, 5,561 टोकन का एक पेज घटकर 293 टोकन रह गया, जिससे अतिरिक्त प्रासंगिक कॉन्टेक्स्ट के लिए जगह खाली हुई।

fetch_url का एक्सट्रैक्शन के साथ उपयोग high प्रयास स्तर पर करने से प्रति क्वेरी इनपुट टोकन लगभग 50% कम हो गए। एक्सट्रैक्शन से बेंचमार्क प्रदर्शन भी बेहतर हुआ: प्रति क्वेरी $0.073 पर 88.0% स्कोर हासिल हुआ, जबकि एक्सट्रैक्शन के बिना यह $0.094 पर 83.5% था।

वेब पर खोज करना हर एजेंट शोध अनुरोध का केंद्रीय हिस्सा है। एजेंटों के खोज करने के तरीके में तीन बदलाव किए गए:

हर खोज में अधिक कॉन्टेक्स्ट: हर खोज अब 2K के बजाय 4K टोकन तक के परिणाम लौटाती है। एजेंट को जो चाहिए, वह जल्दी मिल जाता है, जिससे खोजें कम होती हैं और लागत भी कम होती है।

नया स्निपेट इंजन: खोज परिणामों को ऐसे स्निपेट मिलते हैं जो क्वेरी से बेहतर मेल खाते हैं, इसलिए एजेंट पर अप्रासंगिक टेक्स्ट का बोझ नहीं पड़ता।
तेज़ खोज: प्रति 1K अनुरोध $1.00 पर, Fast Search हर खोज कॉल की लागत और लेटेंसी दोनों को कम करता है।

Perplexity Search टीम कई तरह के कार्यों में रिट्रीवल की गुणवत्ता में लगातार सुधार करती है। हाल के अपडेट से कोड, डेवलपर डॉक्स, रेफ़रेंस पेज, कानूनी और नियामक सामग्री में सुधार हुए।

कुछ कार्यों में कई खोजों को समानांतर में चलाना ज़रूरी होता है; दूसरों में कुछ लंबे दस्तावेज़ों को ध्यान से पढ़ना पड़ता है।

हालाँकि, हर वर्कफ़्लो को एजेंट के सिस्टम प्रॉम्प्ट में लोड करने से कॉन्टेक्स्ट ओवरहेड बढ़ता है और सरल कार्यों पर मॉडल का प्रदर्शन कमज़ोर हो सकता है। इसके बजाय, कौशलों को क्रमिक प्रकटीकरण के साथ एक ट्री में व्यवस्थित किया जाता है। मॉडल काम करते समय प्रासंगिक कौशल और निर्देश लोड करता है, और असंबंधित जानकारी को अपने कॉन्टेक्स्ट से बाहर रखता है। हर कौशल की लागत केवल उसके नाम और विवरण जितनी होती है, जब तक कि मॉडल यह तय न कर ले कि वह कार्य के लिए उपयुक्त है और उसे लोड न कर ले; उस समय पूरे निर्देश कॉन्टेक्स्ट में जोड़ दिए जाते हैं और मॉडल निर्धारित वर्कफ़्लो का पालन करता है।

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

नीचे दिए गए WANDR बेंचमार्क रन दिखाते हैं कि एजेंट विशिष्ट कार्यों के लिए सही वर्कफ़्लो चुनते हैं। हर कार्य के लिए wide-search और fanout मार्गदर्शन लोड किया गया, जो कई इकाइयों की जाँच की ज़रूरत को दर्शाता है। people-search केवल 6% कार्यों के लिए लोड किया गया, और केवल तब जब प्रश्न लोगों से जुड़े थे।

WANDR के एक अन्य कार्य का परीक्षण करते समय, एजेंट ने लंदन में इन्फ़रेंस इंजीनियर ढूँढने के लिए फ़ैनआउट पैटर्न के साथ people-search कौशल लोड किया। उसने 39 भूमिका शब्दों को 117 क्वेरी में विस्तारित किया, फिर आगे की स्क्रीनिंग के लिए पहले चरण के परिणामों को 43 विशिष्ट प्रोफ़ाइल में मिला दिया। people-search कौशल ने अप्रासंगिक कॉन्टेक्स्ट जोड़े बिना इस विस्तार में एजेंट का मार्गदर्शन किया। नीचे दिया गया अंश एजेंट की स्क्रिप्ट से रूपांतरित किया गया है; हेल्पर के नाम केवल उदाहरण के लिए हैं।

code1

text

Python

# roles contains the 39 role variants selected by the agent.
queries = []
for role in roles:
    queries.extend([
        {"query": f"Google DeepMind {role} London"},
        {"query": f"Google {role} London"},
        {"query": role, "company": "Google", "location": "London"},
    ])

results = pplx_sdk.search.people_many(
    queries, limit_per_query=50, concurrency=8
)

profiles = {}
for result in results:
    if not result.ok:
        continue
    for profile in result.result:
        if "linkedin.com/in/" not in profile.url:
            continue
        url = profile.url.split("?")[0].rstrip("/")
        previous = profiles.get(url, {})
        if url not in profiles or len(profile.summary or "") > len(
            previous.get("summary") or ""
        ):
            profiles[url] = {
                "url": url,
                "title": profile.title,
                "summary": profile.summary,
            }

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

WANDR के एक अन्य कार्य में, एजेंट को 188 इंजीनियरों की प्रोफ़ाइल की स्क्रीनिंग करनी थी। उसने काम करते समय हर परिणाम रिकॉर्ड करने के लिए चेकपॉइंट पैटर्न लोड किया। पहले चरण में 160 प्रोफ़ाइल निकाली गईं, लेकिन 28 पर यह विफल रहा। जब एजेंट ने स्क्रिप्ट दोबारा चलाई, तो उसने पहले से रिकॉर्ड की गई प्रोफ़ाइल छोड़ दीं और केवल बची हुई 28 को दोबारा आज़माया। चेकपॉइंट के बिना, एक भी खराब रिकॉर्ड का मतलब होता कि सभी 188 को फिर से फ़ेच करना पड़ता।Python का रूपांतरित अंश; इनपुट पेज, स्क्रीनिंग निर्देश, स्कीमा और इम्पोर्ट हटा दिए गए हैं; हेल्पर के नाम केवल उदाहरण के लिए हैं।

code 2

text

Python

checkpoint = Checkpoint("research/profile-screening")
config = instruction + json.dumps(schema)
config_id = hashlib.md5(config.encode()).hexdigest()[:6]

def checkpoint_key(page):
    url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10]
    return config_id + url_id

pending = [
    page for page in pages if not checkpoint.has(checkpoint_key(page))
]
for offset in range(0, len(pending), 20):
    batch = pending[offset : offset + 20]
    inputs = [
        json.dumps({
            "url": page["url_in"], "content": page["content"][:30_000]
        })
        for page in batch
    ]
    results = pplx_sdk.llm.extract_many(
        inputs,
        instruction=instruction,
        output_schema=schema,
        chunk_size=5,
        concurrency=4,
    )
    for page, result in zip(batch, results):
        if not result.ok or result.result.error:
            continue
        checkpoint.record(
            checkpoint_key(page),
            [{"url": page["url_in"], **result.result.result}],
        )

चेकपॉइंट सफल परिणामों को रिकॉर्ड करता है; यह दोबारा प्रयास शुरू नहीं करता। कुंजी में निर्देश और स्कीमा शामिल करने से यह सुनिश्चित होता है कि स्क्रीनिंग मानदंड बदलने पर दोबारा प्रोसेसिंग हो।

हर परीक्षण से गुणवत्ता और दक्षता में सुधार नहीं हुआ। एजेंट के कार्य शुरू करने से पहले उसमें सभी कौशल प्रीलोड करने का मूल्यांकन किया गया। BrowseComp और DSQA पर, प्रीलोडिंग से लागत 13% बढ़ गई। WANDR पर, जहाँ लंबी शोध प्रक्रियाओं के कारण प्राप्त की गई सामग्री इनपुट टोकन का बड़ा हिस्सा बन जाती है, प्रीलोडिंग से स्कोर भी कम हो जाते हैं। इन परिणामों ने क्रमिक प्रकटीकरण के निरंतर उपयोग का समर्थन किया।

जैसे-जैसे मॉडल की क्षमताएँ आगे बढ़ती हैं, हर प्रयास स्तर के लिए सबसे अच्छा मॉडल भी बदलता है। Perplexity एक स्वचालित शोध लूप का उपयोग करता है, जो नए मॉडल की घोषणाओं और उपलब्धता पर नज़र रखता है। कोई मॉडल उपलब्ध होते ही मूल्यांकन शुरू हो जाते हैं।

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

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

एक अकेला एजेंट एक लूप में सीमित स्रोतों को ही कवर कर सकता है। जटिल कार्यों के लिए, कई एजेंट समानांतर में काम करते हैं, और हर एजेंट समस्या के अलग हिस्से पर तालमेल से काम करता है।

प्राइमरी एजेंट ऑर्केस्ट्रेटर होता है। यह चाइल्ड एजेंट बनाने के लिए spawn_agent को कॉल करता है और हर एक को एक विशिष्ट, केंद्रित कार्य सौंपता है। हर चाइल्ड एजेंट अलग कॉन्टेक्स्ट के साथ अपना शोध लूप चलाता है, जिसमें वह अपने मॉडल, टूल और स्टेप बजट का उपयोग करता है। चाइल्ड एजेंट अपने परिणाम पैरेंट को रिपोर्ट करते हैं, जो किसी चाइल्ड एजेंट को आगे का असाइनमेंट भेज सकता है या उसकी प्रगति की जाँच कर सकता है। ऑर्केस्ट्रेटर और उसके चाइल्ड एजेंट साक्ष्य साझा करने, रुकावटों को चिह्नित करने और अगले कदमों को समायोजित करने के लिए संदेशों का आदान-प्रदान करते हैं। जैसे-जैसे नई जानकारी आती है, ऑर्केस्ट्रेटर असाइनमेंट को बेहतर बनाता है और काम पूरा होने पर परिणामों को एक ही उत्तर में जोड़ देता है।

Agent API पहले से तय एजेंट भूमिकाओं का समर्थन करता है, और ऑर्केस्ट्रेटर कस्टम निर्देशों के साथ चाइल्ड एजेंट बना सकता है।

ultra प्रयास स्तर किसी कार्य पर तीन एजेंट समानांतर में चलाता है। हर एजेंट स्वतंत्र रूप से पूरे कार्य पर शोध करता है, जिससे अलग-अलग साक्ष्य मिलते हैं। एक चौथा एजेंट उनके निष्कर्षों को मिलाता है, दोहराव हटाता है और अंतिम उत्तर लिखता है।

WANDR पर, ultra प्रति कार्य $21.71 पर 85.9% स्कोर करता है। परीक्षण किए गए कॉन्फ़िगरेशन में इसका स्कोर सबसे अधिक है।

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

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

Agent API आज़माएँ और अपने वर्कलोड पर प्रयास स्तरों की तुलना करें। प्रयास स्तरों का विवरण हमारे Agent API प्रयास दस्तावेज़ में देखें।

शोध की लागत

शोध बजट को नियंत्रित करना

कॉन्टेक्स्ट का प्रबंधन

कॉम्पैक्शन

केवल ज़रूरी सामग्री फ़ेच करना

केंद्रित वेब खोज

सही वर्कफ़्लो का चयन

मॉडल का चयन

मल्टी-एजेंट स्केलिंग

आगे क्या है