Agent API च्या प्रत्येक प्रयत्न पातळीमध्ये सुधारणा

Perplexity Agent API मधील प्रयत्न पातळ्यांमुळे डेव्हलपर्सना प्रत्येक कार्यासाठी खर्च, वेग आणि संशोधनाची सखोलता यांचा समतोल निवडता येतो. आजपासून प्रत्येक प्रयत्न पातळीचा प्रति क्वेरी खर्च कमी झाला आहे, आणि संशोधनाची गुणवत्ता एकतर वाढली आहे किंवा तशीच आहे. सर्वात व्यापक आणि सर्वसमावेशक संशोधनासाठी नवीन ultra पातळी उपलब्ध आहे. नावाने पातळी निवडणाऱ्या कोणत्याही विनंतीला, जसे की effort="fast", अपडेट केलेले कॉन्फिगरेशन आपोआप मिळते.

संशोधन एजंट तयार करणे म्हणजे प्रत्येक कार्यासाठी खर्च, वेग आणि सखोलता यांचा योग्य समतोल निवडणे. Agent API मधील प्रयत्न पातळ्या वापरकर्त्यासाठी हा निर्णय घेतात. प्रत्येक पातळी हे एक एकत्रित कॉन्फिगरेशन असते, जे विशिष्ट प्रकारच्या कार्यासाठी मॉडेल, पायऱ्यांचे बजेट, शोध सेटिंग्ज आणि टूल्स निश्चित करते. सध्याच्या खर्चात किंवा त्याहून कमी खर्चात सर्वोत्तम संशोधन देण्यासाठी Perplexity कालांतराने प्रत्येक पातळीचे मूल्यमापन करते आणि ती अपडेट करते.

हे फायदे दोन प्रकारच्या बदलांमुळे झाले. बजेट्स, कॉन्टेक्स्ट हाताळणी आणि एक्स्ट्रॅक्शन यांनी प्रत्येक रनचा खर्च कमी केला, तर कौशल्ये, मॉडेल निवड आणि समांतर एजंट यांनी उत्तराची गुणवत्ता वाढवली किंवा कायम ठेवली.

BrowseComp आणि DSQA वर medium ची कामगिरी 55% वरून 77% पर्यंत सुधारली, तर खर्च जवळपास 90% ने कमी झाला. BrowseComp आणि DSQA हे सार्वजनिक संशोधन बेंचमार्क आहेत; WANDR हा दीर्घ, अनेक घटकांचा समावेश असलेल्या संशोधन कार्यांसाठीचा Perplexity चा बेंचमार्क आहे. xhigh सँडबॉक्समध्ये कोड चालवणे, दीर्घ टूल-वापर लूप टिकवून ठेवणे आणि एकाच वेळी अनेक स्रोतांवर काम करणे यांसारखी एजंटिक कामे करते. ऑगस्ट 2026 च्या कॉन्फिगरेशनच्या खर्चाच्या सुमारे 25% खर्चात चालताना xhigh ने आपला WANDR स्कोअर 76.5% वर कायम ठेवला.

एखादी सखोल संशोधन विनंती उत्तर देण्यापूर्वी डझनभर शोध चालवू शकते, शेकडो पेजेस वाचू शकते आणि पुरावे तपासू शकते. यातील प्रत्येक कृतीमुळे कॉन्टेक्स्टमध्ये टोकनची आणि बिलात डॉलर्सची भर पडते. मर्यादा नसल्यास, एजंट उत्तरात सुधारणा न करता खर्च वाढवणाऱ्या आणि कॉन्टेक्स्टमध्ये गर्दी करणाऱ्या कृती करत राहतो. यातील बहुतांश खर्च पाच घटकांमुळे होतो:

बजेट वाटप. ठरावीक बजेट असलेल्या एजंटच्या पायऱ्या संपू शकतात आणि कार्य अंतिम करण्यापूर्वीच त्यांचा रन लवकर संपू शकतो. याउलट, निश्चित बजेट नसलेले एजंट अंतिम उत्तरात सुधारणा न करता खर्च करत चालूच राहू शकतात.
कॉन्टेक्स्ट ओव्हरहेड. शोध निकाल आणि फेच केलेल्या पेजेसमध्ये पुरावे असतात, पण नियंत्रण न ठेवल्यास कॉन्टेक्स्ट विंडो पटकन असंबंधित माहितीने भरू शकते. कॉन्टेक्स्ट विंडोचा खर्च एका पायरीवरून पुढच्या पायरीवर वाहून नेला जातो आणि जास्त भरलेल्या विंडोमुळे एजंटची कामगिरी कमी होऊ शकते.
वर्कफ्लो निवड. वेगवेगळ्या कार्यांसाठी वेगवेगळ्या पद्धती लागतात. एकच तथ्य शोधणे, मल्टी-हॉप प्रश्न आणि स्रोतांचे व्यापक सर्वेक्षण — या प्रत्येकासाठी वेगळा वर्कफ्लो लागतो. स्वतःहून निवड करायला सोडल्यास, मॉडेल अनेकदा अकार्यक्षम वर्कफ्लो निवडते. एजंटच्या प्रॉम्प्टमध्ये उपलब्ध प्रत्येक रणनीतीचे तपशीलवार वर्णन केल्याने ही समस्या सुटत नाही. त्या अतिरिक्त सूचना प्रत्येक पायरीवर टोकन म्हणून सोबत राहतात आणि कालांतराने मॉडेल त्यापैकी प्रत्येक सूचना कमी विश्वसनीयपणे पाळते.
मॉडेल निवड. मोठ्या मॉडेलवर स्विच केल्याने अतिरिक्त खर्चाच्या प्रमाणात कामगिरी सुधारेलच असे नाही. नवीन मॉडेल गाजावाजासह आणि प्रकाशित बेंचमार्क स्कोअरसह येतात. मात्र, बेंचमार्कमधील वाढ दूषित असू शकते किंवा मॉडेलचे ओव्हरफिटिंग दर्शवू शकते. प्रत्यक्ष कार्यांवर मूल्यमापन न करता मॉडेल बदलल्यास गुणवत्ता न वाढता खर्च वाढू शकतो.
मल्टी-एजंट स्केलिंग. एक एजंट प्रत्येक रनमध्ये मर्यादित संख्येच्या स्रोतांमध्येच शोध घेऊ शकतो, ते वाचू शकतो आणि त्यांवर तर्क करू शकतो. अनेक एजंट समांतर चालवल्याने सर्वात कठीण कार्यांवरील गुणवत्ता सुधारते, पण त्यामुळे खर्चही वाढतो आणि योग्यरीत्या हाताळले नाही तर गुंतागुंत निर्माण होते.

यातील प्रत्येक आव्हान सोडवल्यामुळे कामगिरी कमी न होता प्रत्येक प्रयत्न पातळीचा खर्च कमी झाला.

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

पायऱ्यांची मर्यादा: एजंट किती टर्न घेऊ शकतो याची संख्या
टूल कॉल: एका विनंतीतील एकूण टूल कॉलच्या संख्येवरील मर्यादा. एकाच पायरीत एकाच वेळी अनेक टूल्सवर अनेक कॉल केले जाऊ शकतात, त्यामुळे केवळ पायऱ्यांच्या मर्यादेने एका पायरीत किती कृती होतात यावर नियंत्रण राहत नाही.
बजेट स्मरणपत्रे: किती पायऱ्या उरल्या आहेत याबद्दल वेळोवेळी मिळणाऱ्या सूचना, जेणेकरून कार्याच्या मध्येच बजेट संपण्याऐवजी एजंट प्राधान्यक्रम ठरवू शकेल आणि उत्तर लिहिण्यासाठी वाव ठेवू शकेल.

बजेट हा मुख्य समतोल आहे: अधिक पायऱ्या म्हणजे अधिक चांगली उत्तरे, आणि प्रत्येक पायरीचा खर्च येतो. openai/gpt-6-luna सह पायऱ्यांची मर्यादा 1 वरून 15 पर्यंत वाढवल्यास BrowseComp + DSQA वरील अचूकता 41% वरून 80% पर्यंत वाढते, तर प्रति क्वेरी खर्च $0.0017 वरून $0.0152 पर्यंत वाढतो — म्हणजे सुमारे 2x स्कोअरसाठी सुमारे 9x खर्च.

केवळ पायऱ्यांची मर्यादा संशोधन खर्चावर नियंत्रण ठेवत नाही. पाच पायऱ्यांच्या समान बजेटमध्ये 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.094 मध्ये मिळालेल्या 83.5% च्या तुलनेत, प्रति क्वेरी $0.073 मध्ये 88.0% गाठले.

वेबवर शोध घेणे हा प्रत्येक एजंट संशोधन विनंतीचा केंद्रबिंदू आहे. एजंट कसा शोध घेतात यात तीन बदल करण्यात आले:

प्रत्येक शोधासाठी अधिक कॉन्टेक्स्ट: प्रत्येक शोध आता 2K ऐवजी 4K पर्यंत टोकनचे निकाल देतो. एजंटला हवे ते लवकर सापडते, त्यामुळे शोध कमी लागतात आणि खर्चही कमी होतो.

नवीन स्निपेट इंजिन: शोध निकालांना क्वेरीशी अधिक जुळणारे स्निपेट्स मिळतात, त्यामुळे एजंटवर असंबंधित मजकुराचा भार पडत नाही.
Fast search: प्रति 1K विनंत्यांसाठी $1.00 दराने, Fast Search प्रत्येक सर्च कॉलचा खर्च आणि लेटन्सी दोन्ही कमी करते.

Perplexity Search टीम विविध प्रकारच्या कार्यांमध्ये रिट्रीव्हल गुणवत्ता सातत्याने सुधारते. अलीकडील अपडेट्समुळे कोड, डेव्हलपर डॉक्स, संदर्भ पेजेस, कायदेशीर आणि नियामक मजकूर या सर्वांमध्ये सुधारणा झाली.

काही कार्यांसाठी अनेक शोध समांतर चालवावे लागतात; तर इतर कार्यांसाठी काही दीर्घ दस्तऐवजांचे बारकाईने वाचन आवश्यक असते.

मात्र, प्रत्येक वर्कफ्लो एजंटच्या सिस्टम प्रॉम्प्टमध्ये लोड केल्याने कॉन्टेक्स्ट ओव्हरहेड वाढतो आणि साध्या कार्यांवर मॉडेलची कामगिरी खालावू शकते. त्याऐवजी, कौशल्ये क्रमिक प्रकटीकरणासह एका ट्रीमध्ये संघटित केली जातात. मॉडेल काम करताना संबंधित कौशल्ये आणि सूचना लोड करते आणि असंबंधित माहिती आपल्या कॉन्टेक्स्टबाहेर ठेवते. मॉडेल एखादे कौशल्य कार्यासाठी योग्य आहे असे ठरवून ते लोड करेपर्यंत, त्या कौशल्यासाठी फक्त त्याचे नाव आणि वर्णन इतकाच खर्च येतो; लोड केल्यावर संपूर्ण सूचना कॉन्टेक्स्टमध्ये जोडल्या जातात आणि मॉडेल निर्धारित वर्कफ्लोचे पालन करते.

प्रत्येक कौशल्य किती योगदान देते हे मोजण्यासाठी, बेसलाइन एजंटने ज्या कार्यांवर ते कौशल्य लोड केले होते त्या कार्यांवरील गुणवत्ता आणि खर्चाची तुलना करता यावी म्हणून प्रत्येक कौशल्य एका वेळी एक काढून टाकले जाते. या अ‍ॅब्लेशन्समधून कोणते वर्कफ्लो एजंटला मदत करतात आणि ते संशोधनाच्या कार्यक्षमतेवर कसा परिणाम करतात हे दिसून येते.

खालील WANDR बेंचमार्क रन एजंट विशिष्ट कार्यांसाठी योग्य वर्कफ्लो कसे निवडतात हे दाखवतात. अनेक घटकांचा तपास करण्याची गरज लक्षात घेता, प्रत्येक कार्यासाठी wide-search आणि fanout मार्गदर्शन लोड केले गेले. people-search फक्त 6% कार्यांसाठी लोड केले गेले, आणि तेही केवळ प्रश्न लोकांशी संबंधित असतानाच.

WANDR मधील आणखी एका कार्याची चाचणी करताना, लंडनमधील इन्फरन्स इंजिनिअर्स शोधण्यासाठी एजंटने fanout पॅटर्नसह 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}],
        )

चेकपॉइंट यशस्वी निकालांची नोंद करतो; तो पुन्हा प्रयत्न सुरू करत नाही. की (key) मध्ये सूचना आणि स्कीमा समाविष्ट केल्याने, स्क्रीनिंगचे निकष बदलल्यास पुन्हा प्रक्रिया होईल याची खात्री होते.

प्रत्येक चाचणीतून गुणवत्ता आणि कार्यक्षमतेत वाढ झाली नाही. एजंटने कार्य सुरू करण्यापूर्वीच त्यात सर्व कौशल्ये प्रीलोड करण्याचेही मूल्यमापन करण्यात आले. BrowseComp आणि DSQA वर प्रीलोडिंगमुळे खर्च 13% ने वाढला. WANDR वर, जिथे दीर्घ संशोधन मार्गक्रमणांमुळे इनपुट टोकनमध्ये मिळवलेल्या मजकुराचा वाटा अधिक असतो, तिथे प्रीलोडिंगमुळे स्कोअरही कमी होतात. या निकालांमुळे क्रमिक प्रकटीकरणाचा वापर सुरू ठेवण्याला पाठबळ मिळाले.

मॉडेलच्या क्षमता जसजशा वाढतात, तसतसे प्रत्येक प्रयत्न पातळीसाठीचे सर्वोत्तम मॉडेलही बदलते. Perplexity एक स्वयंचलित संशोधन लूप वापरते, जो नवीन मॉडेलच्या घोषणा आणि उपलब्धतेवर लक्ष ठेवतो. एखादे मॉडेल उपलब्ध होताच मूल्यमापन सुरू केले जाते.

नवीन मॉडेल रिलीझ झाल्यावर, एक स्वयंचलित एजंट मूल्यमापन हार्नेसमध्ये त्याची चाचणी घेतो. तो कारणमीमांसा प्रयत्न, पायऱ्या आणि टूल कॉलची बजेट्स आणि टूल कॉन्फिगरेशन यांच्या विविध मूल्यांची चाचणी करतो आणि सध्याच्या प्रयत्न पातळ्यांच्या तुलनेत प्रत्येक रनला गुणवत्ता आणि खर्चावर गुण देतो. एखाद्या रनची कामगिरी घसरल्यास, एजंट त्याचे कारण शोधतो, सेटिंग्ज समायोजित करतो आणि पुन्हा मूल्यमापन चालवतो. उमेदवार मॉडेल तेव्हाच सध्याच्या मॉडेलची जागा घेते जेव्हा ते त्याच किंवा कमी खर्चात गुणवत्तेत सरस ठरते.

सार्वजनिक बेंचमार्क उपयुक्त असतात, पण त्यांचे स्कोअर प्रत्यक्ष जगातील कार्यांमध्ये नेहमीच तसेच दिसत नाहीत. उदाहरणार्थ, खालील चार्टमध्ये असे एक उमेदवार मॉडेल दाखवले आहे, ज्याने BrowseComp वर बेसलाइनपेक्षा 13.3 गुण अधिक मिळवले, पण अंतर्गत एंटरप्राइझ, कायदेशीर आणि वित्त संशोधन कार्यांवर संबंधित बेसलाइनपेक्षा बरेच कमी गुण मिळवले.

एक एजंट एका लूपमध्ये मर्यादित स्रोतांनाच कव्हर करू शकतो. गुंतागुंतीच्या कार्यांसाठी अनेक एजंट समांतर काम करतात, आणि प्रत्येक जण समस्येच्या वेगळ्या भागावर समन्वयाने काम करतो.

मुख्य एजंट हा ऑर्केस्ट्रेटर असतो. तो चाइल्ड एजंट तयार करण्यासाठी spawn_agent कॉल करतो आणि प्रत्येकाला एक विशिष्ट, केंद्रित कार्य सोपवतो. प्रत्येक चाइल्ड एजंट स्वतःचे मॉडेल, टूल्स आणि पायऱ्यांचे बजेट वापरून, वेगळ्या कॉन्टेक्स्टसह स्वतःचा संशोधन लूप चालवतो. चाइल्ड एजंट आपले निकाल पॅरेंट एजंटला कळवतात; पॅरेंट एजंट एखाद्या चाइल्डला पुढील असाइनमेंट पाठवू शकतो किंवा त्याची प्रगती तपासू शकतो. ऑर्केस्ट्रेटर आणि त्याचे चाइल्ड एजंट पुरावे शेअर करण्यासाठी, अडथळे नोंदवण्यासाठी आणि पुढील पायऱ्या समायोजित करण्यासाठी एकमेकांना संदेश पाठवतात. नवीन माहिती मिळत जाईल तसे ऑर्केस्ट्रेटर असाइनमेंट अधिक नेमक्या करतो आणि काम पूर्ण झाल्यावर सर्व निकाल एकत्र करून एकच उत्तर तयार करतो.

Agent API पूर्वनिर्धारित एजंट भूमिकांना सपोर्ट करते आणि ऑर्केस्ट्रेटर कस्टम सूचनांसह चाइल्ड एजंट तयार करू शकतो.

ultra प्रयत्न पातळी एका कार्यावर तीन एजंट समांतर चालवते. प्रत्येक एजंट संपूर्ण कार्याचे स्वतंत्रपणे संशोधन करतो, त्यामुळे वेगवेगळे पुरावे मिळतात. चौथा एजंट त्यांचे निष्कर्ष एकत्र करतो, पुनरावृत्ती काढून टाकतो आणि अंतिम उत्तर लिहितो.

WANDR वर ultra प्रति कार्य $21.71 खर्चात 85.9% स्कोअर करते. चाचणी घेतलेल्या कॉन्फिगरेशनपैकी हा सर्वोच्च स्कोअर आहे.

प्रयत्न पातळ्यांचे सतत मूल्यमापन केले जाते आणि त्यांत सुधारणा केल्या जातात. वापरकर्ते निवडत असलेली पातळी एखाद्या कार्यावर किती संशोधन होईल आणि त्याचा खर्च किती येईल हे ठरवते. पायऱ्या आणि टूल कॉलची बजेट्स, ती संपत येताना मिळणाऱ्या स्मरणपत्रांसह, विनंत्या बजेटमध्ये ठेवतात. कॉम्पॅक्शन, एक्स्ट्रॅक्शन आणि अधिक चांगले स्निपेट्स कॉन्टेक्स्ट पुराव्यांवर केंद्रित ठेवतात. कौशल्ये कार्यानुसार योग्य वर्कफ्लो जुळवतात आणि समांतर एजंट एका लूपच्या व्याप्तीपलीकडे काम विस्तारतात. स्वयंचलित मूल्यमापन लूप नवीन मॉडेलला तेव्हाच स्वीकारतो जेव्हा ते त्याच खर्चात संशोधनाची गुणवत्ता सुधारते.

नवीन मॉडेल आणि कॉन्फिगरेशन मूल्यमापनात स्वतःला सिद्ध करत जातील तसतशी प्रत्येक प्रयत्न पातळी विकसित होत राहील. पातळीला तिच्या नावाने कॉल केल्यास त्या सुधारणा आपोआप लागू होतात; एखादी आवृत्ती पिन केल्यास कॉन्फिगरेशन स्थिर राहते.

Agent API वापरून पहा आणि तुमच्या स्वतःच्या वर्कलोडवर प्रयत्न पातळ्यांची तुलना करा. प्रयत्न पातळ्यांचे तपशील आमच्या Agent API प्रयत्न पातळी दस्तऐवजीकरणात मिळतील.

संशोधनाचा खर्च

संशोधन बजेटवर नियंत्रण

कॉन्टेक्स्टचे व्यवस्थापन

कॉम्पॅक्शन

फक्त महत्त्वाचे तेच मिळवणे

केंद्रित वेब शोध

योग्य वर्कफ्लो निवडणे

मॉडेल निवड

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

पुढे काय