ஒவ்வொரு 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% ஆகத் தக்கவைத்தது.

ஓர் ஆழமான ஆய்வுக் கோரிக்கை, பதிலளிப்பதற்கு முன் டஜன் கணக்கான தேடல்களை இயக்கலாம், நூற்றுக்கணக்கான பக்கங்களைப் படிக்கலாம், சான்றுகளைச் சரிபார்க்கலாம். அந்தச் செயல்கள் ஒவ்வொன்றும் சூழலில் டோக்கன்களையும் கட்டணத்தில் டாலர்களையும் சேர்க்கின்றன. வரம்புகள் இல்லாவிட்டால், ஓர் ஏஜென்ட் பதிலை மேம்படுத்தாமலேயே செலவை அதிகரித்துச் சூழலை நெரிசலாக்கும் செயல்களைத் தொடர்ந்து மேற்கொள்ளும். அந்தச் செலவின் பெரும்பகுதிக்கு ஐந்து காரணிகள் காரணமாகின்றன:

பட்ஜெட் ஒதுக்கீடு. நிர்ணயிக்கப்பட்ட பட்ஜெட் உள்ள ஏஜென்ட்களுக்குப் படிகள் தீர்ந்துபோய், தங்கள் பணியை இறுதிசெய்வதற்கு முன்பே இயக்கம் முன்கூட்டியே முடிந்துவிடலாம். மாறாக, நிலையான பட்ஜெட் இல்லாத ஏஜென்ட்கள் இறுதிப் பதிலை மேம்படுத்தாமலேயே செலவுகளை ஏற்படுத்தியபடி தொடர்ந்து இயங்கலாம்.
சூழல் சுமை. தேடல் முடிவுகளும் பெறப்பட்ட பக்கங்களும் சான்றுகளைக் கொண்டுள்ளன, ஆனால் கட்டுப்படுத்தப்படாவிட்டால், சூழல் சாளரம் தொடர்பற்ற தகவல்களால் விரைவாக நிரம்பக்கூடும். சூழல் சாளரங்கள் படிக்குப் படி செலவுகளைச் சுமந்து செல்கின்றன, மேலும் அதிகச் சுமையேற்றப்பட்ட சாளரங்கள் ஏஜென்ட்டின் செயல்திறனைக் குறைக்கக்கூடும்.
பணிப்பாய்வுத் தேர்வு. வெவ்வேறு பணிகளுக்கு வெவ்வேறு அணுகுமுறைகள் தேவை. ஒற்றைத் தகவல் தேடல், பல-படிநிலைக் (multi-hop) கேள்வி, பரந்த அளவிலான மூல ஆய்வு ஆகிய ஒவ்வொன்றுக்கும் வெவ்வேறு பணிப்பாய்வு தேவைப்படுகிறது. தானே தேர்வுசெய்ய விடப்பட்டால், மாடல் பெரும்பாலும் செயல்திறன் குறைந்த ஒன்றைத் தேர்ந்தெடுக்கிறது. கிடைக்கக்கூடிய ஒவ்வொரு உத்தியையும் ஏஜென்ட்டின் ப்ராம்ப்டில் விவரிப்பது இதற்குத் தீர்வாகாது. கூடுதல் அறிவுறுத்தல்கள் ஒவ்வொரு படியிலும் டோக்கன்களாகச் சுமந்து செல்லப்படுகின்றன, மேலும் காலப்போக்கில் மாடல் ஒவ்வொன்றையும் குறைவான நம்பகத்தன்மையுடன் பின்பற்றுகிறது.
மாடல் தேர்வு. பெரிய மாடலுக்கு மாறுவது, கூடுதல் செலவுக்கு ஏற்ற மேம்பட்ட செயல்திறனை வழங்காமல் போகலாம். புதிய மாடல்கள் தலைப்புச் செய்திகளுடனும் வெளியிடப்பட்ட பெஞ்ச்மார்க் மதிப்பெண்களுடனும் வருகின்றன. இருப்பினும், பெஞ்ச்மார்க் முன்னேற்றங்கள் தரவு மாசுபாட்டால் பாதிக்கப்பட்டிருக்கலாம் அல்லது மாடலின் ஓவர்ஃபிட்டிங்கைப் பிரதிபலிக்கலாம். நிஜப் பணிகளில் மதிப்பீடு இல்லாமல், மாடல் மாற்றம் தரத்தை உயர்த்தாமலேயே செலவுகளை உயர்த்தக்கூடும்.
பல-ஏஜென்ட் அளவிடுதல். ஓர் ஏஜென்ட் ஓர் இயக்கத்தில் வரையறுக்கப்பட்ட எண்ணிக்கையிலான மூலங்களை மட்டுமே தேடவும், படிக்கவும், பகுத்தாராயவும் முடியும். பல ஏஜென்ட்களை இணையாக இயக்குவது மிகவும் கடினமான பணிகளில் தரத்தை மேம்படுத்துகிறது, ஆனால் செலவுகளையும் அதிகரிக்கிறது, சரியாகக் கையாளப்படாவிட்டால் சிக்கலையும் உண்டாக்குகிறது.

இந்தச் சவால்கள் ஒவ்வொன்றையும் தீர்த்தது, செயல்திறனைக் குறைக்காமல் ஒவ்வொரு முயற்சி நிலைக்குமான செலவுகளைக் குறைத்தது.

ஒவ்வொரு முயற்சி நிலைக்கும் மூன்று கூறுகளைக் கொண்ட ஒரு நிலையான ஆய்வு பட்ஜெட் உள்ளது:

படி வரம்புகள்: ஏஜென்ட் எடுக்கக்கூடிய சுற்றுகளின் எண்ணிக்கை
கருவி அழைப்புகள்: ஒரு கோரிக்கையில் உள்ள மொத்தக் கருவி அழைப்புகளின் எண்ணிக்கைக்கான உச்சவரம்பு. ஒரே படியில் பல கருவிகளில் ஒரே நேரத்தில் பல அழைப்புகளை மேற்கொள்ள முடியும் என்பதால், படி வரம்பு மட்டுமே ஒரு படிக்குள் எத்தனை செயல்கள் நிகழ்கின்றன என்பதைக் கட்டுப்படுத்தாது.
பட்ஜெட் நினைவூட்டல்கள்: இன்னும் எத்தனை படிகள் மீதமுள்ளன என்பது பற்றிய அவ்வப்போதான அறிவிப்புகள்; இதனால் பணியின் நடுவில் பட்ஜெட் தீர்ந்துபோவதற்குப் பதிலாக, ஏஜென்ட் முன்னுரிமைப்படுத்தி, பதிலை எழுத இடம் விட முடியும்.

பட்ஜெட்தான் மையச் சமரசம்: அதிகப் படிகள் சிறந்த பதில்களைக் குறிக்கின்றன, ஆனால் ஒவ்வொரு படியும் செலவை ஏற்படுத்துகிறது. 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 நிலைக்கு, நினைவூட்டல்கள் படி பட்ஜெட் மற்றும் கருவி அழைப்பு பட்ஜெட் இரண்டையும் உள்ளடக்குகின்றன.

பட்ஜெட் நினைவூட்டல் உள்ள ஒன்று, இல்லாத ஒன்று என இரண்டு ஏஜென்ட்கள், மூன்று நடிகர்களின் வாழ்க்கைக் குறிப்புகளைக் கொண்டு 1990களின் ஒரு தொலைக்காட்சித் தொடரைக் கண்டறியும் BrowseComp பணியில் சோதிக்கப்பட்டன. நினைவூட்டல் உள்ள ஏஜென்ட், பட்ஜெட்டில் உள்ள 40 படிகளில் 13 படிகளைப் பயன்படுத்தி சரியான பதிலைக் கண்டறிந்தது. பட்ஜெட் நினைவூட்டல் இல்லாத ஏஜென்ட் 40 படிகளையும் பயன்படுத்தியது, ஆனால் சரியான பதிலைக் கண்டறியவில்லை. அந்த ஏஜென்ட்டின் லூப் எதிர்பாராதவிதமாக முடிந்தது, மேலும் மீதமுள்ள ஆய்வு பட்ஜெட் குறித்து மாடலுக்குத் தெரியவில்லை. நினைவூட்டல்கள் ஏஜென்ட்களைக் கவனம் சிதறாமல் வைத்திருக்கின்றன, மேலும் மீதமுள்ள வளங்களைத் திறம்பட முன்னுரிமைப்படுத்த உதவுகின்றன.

நீண்ட நேரம் இயங்கும் ஆய்வுப் பணிகள், தேடல் முடிவுகள், பெறப்பட்ட பக்கங்கள், இடைநிலைக் குறிப்புகள் ஆகியவற்றால் மாடலின் சூழல் சாளரத்தை நிரப்புகின்றன. அது நிரம்பியதும், ஏஜென்ட் வேலையை நிறுத்த வேண்டும்.

சுருக்கமாக்கல், சூழல் சாளரத்தை நிரப்பாமல் நீண்ட இயக்கங்களைத் தொடர்ந்து செயல்பட வைக்கிறது. சூழல் ஒரு வரம்பைத் தாண்டும்போது, ஏஜென்ட் இதுவரை செய்த பணியை, அது கண்டறிந்தவை மற்றும் மீதமுள்ளவை பற்றிய சுருக்கமான தொகுப்பால் மாற்றி, பின்னர் தொடர்கிறது.

சுருக்கமாக்கல் எப்போதும் மூன்று விஷயங்களைச் சூழலில் தக்கவைக்கிறது: சிஸ்டம் ப்ராம்ப்ட், அசல் கோரிக்கை, மற்றும் ஏஜென்ட் ஏற்கனவே ஏற்றியுள்ள திறன்கள். ஒவ்வொரு சுருக்கமாக்கலுக்குப் பிறகும், ஏஜென்ட் இரண்டு குறுகிய அறிவுறுத்தல்களைப் பெறுகிறது. முதல் அறிவுறுத்தல்: ‘பணி முடியும் வரை தொடர்ந்து வேலை செய்.’ இது சுருக்கத்தை ஒரு நிறுத்தப் புள்ளியாகக் கருதுவதிலிருந்து ஏஜென்ட்டைத் தடுக்கிறது. இரண்டாவது அறிவுறுத்தல் இதுவரை எத்தனை சுருக்கமாக்கல்கள் நடந்துள்ளன என்பதை ஏஜென்ட்டுக்குத் தெரிவிக்கிறது, இதனால் அது மீதமுள்ள ஆய்வுப் பணிகளைத் திட்டமிட முடியும். நீண்ட இயக்கங்கள் அசல் இலக்கையும் திட்டத்தையும் கண்முன் வைத்திருக்கின்றன, மேலும் தரம் குறையாமல் நீண்ட லூப்களின் செலவு குறைகிறது.

ஏஜென்ட் படிக்கும் ஒவ்வொரு பக்கமும் அதன் சூழலில் சேர்கிறது, அதைத் தொடர்ந்து வரும் ஒவ்வொரு படியிலும் ஏஜென்ட் அதைச் சுமந்து செல்கிறது. ஒரு வலைப்பக்கத்தில் வழிசெலுத்தல், வழக்கமான நிலையான உரை (boilerplate) மற்றும் பிற உள்ளடக்கம் போன்ற, கேள்விக்குத் தொடர்பில்லாத தகவல்களும் இருக்கும்.

ஏஜென்ட்டிடம் ஒரு முழுப் பக்கத்தையும் ஒப்படைப்பதற்குப் பதிலாக, 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 குழு பல்வேறு வகையான பணிகளில் மீட்டெடுப்புத் தரத்தைத் தொடர்ந்து மேம்படுத்துகிறது. சமீபத்திய புதுப்பிப்புகள் குறியீடு, டெவலப்பர் ஆவணங்கள், குறிப்புப் பக்கங்கள், சட்டம் மற்றும் ஒழுங்குமுறை உள்ளடக்கம் ஆகியவற்றில் முன்னேற்றங்களை வழங்கின.

சில பணிகளுக்குப் பல தேடல்கள் இணையாக இயங்க வேண்டும்; மற்றவற்றுக்குச் சில நீண்ட ஆவணங்களைக் கவனமாகப் படிக்க வேண்டும்.

இருப்பினும், ஒவ்வொரு பணிப்பாய்வையும் ஏஜென்ட்டின் சிஸ்டம் ப்ராம்ப்டில் ஏற்றுவது சூழல் சுமையைக் கூட்டுகிறது, மேலும் எளிய பணிகளில் மாடல் குறைவாகச் செயல்பட வழிவகுக்கலாம். அதற்குப் பதிலாக, திறன்கள் படிப்படியான வெளிப்படுத்தலுடன் ஒரு மரக் கட்டமைப்பில் ஒழுங்கமைக்கப்பட்டுள்ளன. மாடல் வேலை செய்யும்போது தொடர்புடைய திறன்களையும் அறிவுறுத்தல்களையும் ஏற்றுகிறது, தொடர்பில்லாத தகவல்களைத் தனது சூழலுக்கு வெளியே விடுகிறது. ஒரு திறன் பணிக்குப் பொருந்தும் என்று மாடல் முடிவுசெய்து அதை ஏற்றும் வரை, அந்தத் திறனுக்கு அதன் பெயர் மற்றும் விளக்கத்திற்கான செலவு மட்டுமே ஆகும்; ஏற்றியதும், முழு அறிவுறுத்தல்களும் சூழலில் சேர்க்கப்பட்டு, மாடல் பரிந்துரைக்கப்பட்ட பணிப்பாய்வைப் பின்பற்றுகிறது.

தனிப்பட்ட திறன்கள் எவ்வாறு பங்களிக்கின்றன என்பதை அளவிட, அடிப்படை ஏஜென்ட் ஒரு திறனை ஏற்றிய பணிகளில், ஒவ்வொரு திறனும் ஒவ்வொன்றாக நீக்கப்பட்டு, தரமும் செலவும் ஒப்பிடப்படுகின்றன. எந்தப் பணிப்பாய்வுகள் ஏஜென்ட்டுக்கு உதவுகின்றன, அவை ஆய்வுச் செயல்திறனை எவ்வாறு பாதிக்கின்றன என்பதை இந்த நீக்கல் சோதனைகள் (ablations) காட்டுகின்றன.

கீழே உள்ள WANDR பெஞ்ச்மார்க் இயக்கங்கள், குறிப்பிட்ட பணிகளுக்கு ஏஜென்ட்கள் சரியான பணிப்பாய்வுகளைத் தேர்ந்தெடுப்பதைக் காட்டுகின்றன. பல உருப்படிகளை ஆராய வேண்டிய தேவையைப் பிரதிபலிக்கும் வகையில், ஒவ்வொரு பணிக்கும் பரந்த தேடல் மற்றும் ஃபேன்அவுட் வழிகாட்டுதல்கள் ஏற்றப்பட்டன. நபர் தேடல் 6% பணிகளுக்கு மட்டுமே ஏற்றப்பட்டது, அதுவும் கேள்விகள் நபர்களை உள்ளடக்கியபோது மட்டுமே.

மற்றொரு WANDR பணியைச் சோதிக்கும்போது, லண்டனில் உள்ள இன்ஃபரன்ஸ் பொறியாளர்களைக் கண்டறிய, ஏஜென்ட் நபர் தேடல் திறனை ஃபேன்அவுட் பேட்டர்னுடன் ஏற்றியது. அது 39 பணிப் பெயர்ச் சொற்களை 117 வினவல்களாக விரிவுபடுத்தி, பின்னர் முதல் சுற்று முடிவுகளை மேலும் வடிகட்டுவதற்காக 43 தனித்துவமான சுயவிவரங்களாக ஒன்றிணைத்தது. தொடர்பற்ற சூழலைச் சேர்க்காமல் இந்த விரிவாக்கத்தின் வழியாக நபர் தேடல் திறன் ஏஜென்ட்டை வழிநடத்தியது. கீழே உள்ள பகுதி ஏஜென்ட்டின் ஸ்கிரிப்டிலிருந்து தழுவப்பட்டது; ஹெல்பர் பெயர்கள் விளக்கத்திற்காக மட்டுமே.

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,
            }

நீண்ட நேரம் இயங்கும் பணிகளில் ஏஜென்ட்களுக்கு உதவும் மற்றொரு பணிப்பாய்வு செக்பாயிண்டிங் ஆகும். செக்பாயிண்டிங் பேட்டர்ன் தொகுதி நிரலாக்கத்திலிருந்து (batch programming) வருகிறது. ஒரு ஸ்கிரிப்ட் நீண்ட பட்டியலைச் செயலாக்கும்போது, இறுதிவரை அனைத்தையும் நினைவகத்தில் வைத்திருப்பதற்குப் பதிலாக, ஒவ்வொரு முடிவும் கிடைத்தவுடனேயே அதை டிஸ்க்கில் எழுதுகிறது. ஸ்கிரிப்ட் இடையில் செயலிழந்தாலோ பிழைகளைச் சந்தித்தாலோ, எதுவும் இழக்கப்படுவதில்லை: அடுத்த இயக்கம் ஏற்கனவே சேமிக்கப்பட்டதைப் படித்து, விட்ட இடத்திலிருந்து தொடர்கிறது, தோல்வியடைந்த உருப்படிகளை மட்டுமே மீண்டும் முயல்கிறது.

மற்றொரு 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 பயன்படுத்துகிறது. ஒரு மாடல் அணுகக்கூடியதாக ஆனவுடனேயே மதிப்பீடுகள் தூண்டப்படுகின்றன.

ஒரு புதிய மாடல் வெளியிடப்படும்போது, ஒரு தானியங்கு ஏஜென்ட் அதை மதிப்பீட்டு harness மூலம் சோதிக்கிறது. அது பகுத்தறிதல் முயற்சி, படி மற்றும் கருவி அழைப்பு பட்ஜெட்டுகள், கருவி உள்ளமைவுகள் ஆகியவற்றை முறையாக மாற்றிப் பார்த்து, ஒவ்வொரு இயக்கத்தையும் தற்போதைய முயற்சி நிலைகளுடன் ஒப்பிட்டுத் தரம் மற்றும் செலவின் அடிப்படையில் மதிப்பிடுகிறது. ஓர் இயக்கம் பின்னடைவைச் சந்திக்கும் இடத்தில், ஏஜென்ட் அதற்கான காரணத்தை ஆராய்ந்து, அமைப்புகளைச் சரிசெய்து, மதிப்பீட்டை மீண்டும் இயக்குகிறது. அதே அல்லது குறைந்த செலவில் தரத்தில் வெற்றி பெறும்போது மட்டுமே ஒரு வேட்பாளர் மாடல் தற்போதைய மாடலை மாற்றுகிறது.

பொது பெஞ்ச்மார்க்குகள் பயனுள்ளவை, ஆனால் அவற்றின் மதிப்பெண்கள் எப்போதும் நிஜ உலகப் பணிகளுக்குப் பொருந்துவதில்லை. எடுத்துக்காட்டாக, BrowseComp-இல் அடிப்படை அளவை விட 13.3 புள்ளிகள் அதிகம் பெற்ற, ஆனால் உள் நிறுவன, சட்ட மற்றும் நிதி ஆய்வுப் பணிகளில் தொடர்புடைய அடிப்படை அளவுகளை விட மிகக் குறைவாகப் பெற்ற, பரிசீலனையில் உள்ள ஒரு மாடலைக் கீழே உள்ள விளக்கப்படம் காட்டுகிறது.

ஓர் ஏஜென்ட் ஒரு லூப்பில் குறிப்பிட்ட எண்ணிக்கையிலான மூலங்களை மட்டுமே உள்ளடக்க முடியும். சிக்கலான பணிகளுக்கு, பல ஏஜென்ட்கள் இணையாகச் செயல்படுகின்றன, ஒவ்வொன்றும் சிக்கலின் வெவ்வேறு பகுதியில் ஒருங்கிணைந்து பணியாற்றுகின்றன.

முதன்மை ஏஜென்ட்தான் ஒருங்கிணைப்பாளர். அது துணை ஏஜென்ட்களை உருவாக்க spawn_agent-ஐ அழைத்து, ஒவ்வொன்றுக்கும் குறிப்பிட்ட, கவனம் செலுத்திய ஒரு பணியை ஒதுக்குகிறது. ஒவ்வொரு துணை ஏஜென்ட்டும் தனக்கென தனிச் சூழலுடன், தனது சொந்த மாடல், கருவிகள் மற்றும் படி பட்ஜெட்டைப் பயன்படுத்தி, தனது சொந்த ஆய்வு லூப்பை இயக்குகிறது. துணை ஏஜென்ட்கள் தங்கள் முடிவுகளை முதன்மை ஏஜென்ட்டிடம் தெரிவிக்கின்றன; அது ஒரு துணை ஏஜென்ட்டுக்குத் தொடர் பணியை அனுப்பலாம் அல்லது அதன் முன்னேற்றத்தைச் சரிபார்க்கலாம். சான்றுகளைப் பகிரவும், தடைகளைச் சுட்டிக்காட்டவும், அடுத்த படிகளைச் சரிசெய்யவும் ஒருங்கிணைப்பாளரும் அதன் துணை ஏஜென்ட்களும் செய்திகளைப் பரிமாறிக்கொள்கின்றன. புதிய தகவல்கள் வரும்போது, ஒருங்கிணைப்பாளர் பணி ஒதுக்கீடுகளைச் செம்மைப்படுத்துகிறது, மேலும் பணி முடிந்ததும் முடிவுகளை ஒரே பதிலாக ஒருங்கிணைக்கிறது.

Agent API முன்வரையறுக்கப்பட்ட ஏஜென்ட் பாத்திரங்களை ஆதரிக்கிறது, மேலும் ஒருங்கிணைப்பாளர் தனிப்பயன் அறிவுறுத்தல்களுடன் துணை ஏஜென்ட்களை உருவாக்க முடியும்.

ultra முயற்சி நிலை ஒரு பணியில் மூன்று ஏஜென்ட்களை இணையாக இயக்குகிறது. ஒவ்வொரு ஏஜென்ட்டும் முழுப் பணியையும் சுயாதீனமாக ஆராய்வதால், வெவ்வேறு சான்றுகள் கிடைக்கின்றன. நான்காவது ஏஜென்ட் அவற்றின் கண்டுபிடிப்புகளை ஒன்றிணைத்து, நகல்களை நீக்கி, இறுதிப் பதிலை எழுதுகிறது.

WANDR-இல், ultra ஒரு பணிக்கு $21.71 செலவில் 85.9% மதிப்பெண் பெறுகிறது. சோதிக்கப்பட்ட உள்ளமைவுகளில் இதுவே மிக உயர்ந்த மதிப்பெண்.

முயற்சி நிலைகள் தொடர்ந்து மதிப்பீடு செய்யப்பட்டு மேம்படுத்தப்படுகின்றன. ஒரு பணிக்கு எவ்வளவு ஆய்வு கிடைக்கும், அதற்கு எவ்வளவு செலவாகும் என்பதைப் பயனர்கள் தேர்ந்தெடுக்கும் நிலையே தீர்மானிக்கிறது. படி மற்றும் கருவி அழைப்பு பட்ஜெட்டுகள், அவை குறையும்போது வரும் நினைவூட்டல்களுடன், கோரிக்கைகளை பட்ஜெட்டுக்குள் வைத்திருக்கின்றன. சுருக்கமாக்கல், பிரித்தெடுத்தல், மேம்பட்ட துணுக்குகள் ஆகியவை சூழலைச் சான்றுகளில் கவனம் செலுத்த வைக்கின்றன. திறன்கள் பணிக்கேற்ற பணிப்பாய்வைப் பொருத்துகின்றன, இணையாக இயங்கும் ஏஜென்ட்கள் ஒரு லூப் உள்ளடக்கக்கூடியதை விரிவுபடுத்துகின்றன. ஒரு தானியங்கு மதிப்பீட்டு லூப், அதே செலவில் ஆய்வுத் தரத்தை மேம்படுத்தும்போது மட்டுமே புதிய மாடலை ஏற்றுக்கொள்கிறது.

புதிய மாடல்களும் உள்ளமைவுகளும் மதிப்பீட்டில் தங்களை நிரூபிக்கும்போது, ஒவ்வொரு முயற்சி நிலையும் தொடர்ந்து மேம்படும். ஒரு நிலையைப் பெயரால் அழைத்தால் அந்த மேம்பாடுகள் தானாகவே கிடைக்கும்; ஒரு குறிப்பிட்ட பதிப்பைப் பின் செய்தால் உள்ளமைவு மாறாமல் இருக்கும்.

Agent API-ஐ முயன்று பாருங்கள், உங்கள் சொந்தப் பணிச்சுமைகளில் முயற்சி நிலைகளை ஒப்பிடுங்கள். முயற்சி நிலை விவரங்களை எங்கள் Agent API முயற்சி ஆவணங்களில் காணலாம்.

ஆய்வின் செலவு

ஆய்வு பட்ஜெட்டைக் கட்டுப்படுத்துதல்

சூழலை நிர்வகித்தல்

சுருக்கமாக்கல்

முக்கியமானதை மட்டும் பெறுதல்

இலக்கு சார்ந்த இணையத் தேடல்

சரியான பணிப்பாய்வைத் தேர்ந்தெடுத்தல்

மாடல் தேர்வு

பல-ஏஜென்ட் அளவிடுதல்

அடுத்தது என்ன