Agents-ஐ இயக்க அனுமதிப்பதன் மறைமுக செலவு

AI coding agents ஒற்றைக் கேள்விகளுக்கு பதிலளிப்பதை நிறுத்தி, தாமாகவே வேலை செய்யத் தொடங்கியதும் அவற்றின் பொருளாதாரம் மாறுகிறது. ஒரு முறை மட்டும் செய்யப்படும் கணிப்பு மலிவானது. ஆனால் நீண்ட, மேற்பார்வையற்ற இயக்கம் அப்படி அல்ல: reasoning படிகள் tool calls மீது சேரும், அவை feedback loops மீது சேரும், ஒவ்வொரு சுழற்சியிலும் token செலவு அதிகரிக்கும். Nvidia ஆராய்ச்சியாளர்கள், அடிப்படை மாதிரியை இயக்குவதை மலிவாக்குவதன் மூலம் அல்லாமல், அதைச் சுற்றியுள்ள scaffolding-ஐ மீண்டும் எழுதுவதன் மூலம், எதிர்பாராத கோணத்தில் அந்தச் செலவைத் தாக்கும் ஒரு அமைப்பை விவரிக்கும் ஆய்வுக் கட்டுரையை வெளியிட்டுள்ளனர்.

SoL-Pi எனப்படும் அவர்களின் முறை, செயல்திறனை கிட்டத்தட்ட மாற்றமின்றி வைத்துக்கொண்டே token நுகர்வை கிட்டத்தட்ட பாதியாகக் குறைக்கிறது என்று ஆராய்ச்சியாளர்கள் கூறுகின்றனர். இந்த வேலை The Decoder-ஆல் அறிக்கை செய்யப்பட்டது; இந்த அமைப்பு மாதிரியையே அல்லாமல், harness எனப்படும் கட்டுப்பாட்டு அடுக்கை இலக்காகக் கொண்டுள்ளது என்பதை அது குறிப்பிடுகிறது.

Harness உண்மையில் என்ன செய்கிறது

Harness என்பது ஒரு மாதிரிக்கும் அது இயங்கும் சூழலுக்கும் இடையில் அமைந்துள்ள மென்பொருள் அடுக்கு. இது agent-க்கு தான் எந்த நிலையில் உள்ளது என்பதைக் காட்டுகிறது, செயல்கள் எவ்வாறு செயல்படுத்தப்பட வேண்டும் என்பதை முடிவு செய்கிறது, பின்னர் மாதிரிக்கு என்ன feedback திரும்பும் என்பதை தீர்மானிக்கிறது. Codex, Claude Code, OpenClaw போன்ற பரிச்சயமான தயாரிப்புகள், ஒரு language model-ஐ கோப்புகளைத் திருத்தவும், சோதனைகளை இயக்கவும், மீண்டும் மீண்டும் செயல்படவும் கூடிய ஒன்றாக மாற்ற இத்தகைய harness-களை நம்பியுள்ளன.

அந்த அடுக்கு loop-இன் பெரும் பகுதியை நிர்வகிப்பதால், அது செலவில் மிகப்பெரிய தாக்கத்தை ஏற்படுத்துகிறது. ஒவ்வொரு தேவையற்ற tool call, ஒவ்வொரு அதிக அளவிலான context window, தாமதமாக இயங்கும் ஒவ்வொரு verification படி ஆகியவை கண்டிப்பாக தேவையில்லாத tokens-ஐ சேர்க்கின்றன. இதுவரை, பெரும்பாலான செயல்திறன் மேம்பாட்டு வேலைகள் வேறு இடங்களில் கவனம் செலுத்தின: வேகமான attention kernels மற்றும் serving infrastructure மூலம் ஒரு token-இன் விலையைக் குறைப்பது, quantization மூலம் மாதிரிகளை சுருக்குவது, அல்லது வேலையை சிறிய, மலிவான மாதிரிகளுக்கு வழிமாற்றுவது.

Harness மேம்படுத்தல் ஏன் கடினம்

Harness-ஐ கைமுறையாக சரிசெய்வது கடினம், ஏனெனில் அதன் பொறுப்புகள் ஒன்றோடொன்று பின்னிப் பிணைந்துள்ளன. Tool பயன்பாடு, context மேலாண்மை, verification வழக்கங்கள், abort logic ஆகியவை அனைத்தும் ஒன்றோடொன்று தொடர்பு கொள்கின்றன. ஒரு கட்டத்தில் tokens-ஐ குறைக்கும் மாற்றம், வேறு எங்கோ தோல்விகளை அறிமுகப்படுத்தலாம், அல்லது செலவை இயக்கத்தின் பிற்பகுதிக்கு நகர்த்தலாம்; அங்கு அதைக் காண்பது மேலும் கடினம்.

Diagram of the SoL-Pi auto-research loop showing research environments, a research AI, an idea pool, and four retained mechanisms, alongside bar charts comparing score and API costs for Codex, Claude Code, Pi, and SoL-Pi on EdgeBench.
A research AI analyzes agent traces, proposes harness changes, and keeps only those that maintain performance while cutting costs. SoL-Pi saves 50 percent compared to Codex and 54.3 percent compared to Claude Code on EdgeBench. | Image: Nvidia

நடைமுறையில், பொறியாளர்கள் நீண்ட execution traces-ஐ படித்து, மீண்டும் மீண்டும் நிகழும் தோல்வி முறைகளைக் கண்டறிந்து, அந்த அவதானிப்புகளை code மாற்றங்களாக மாற்றுகிறார்கள். இது மெதுவான, கைமுறை வேலை; அதே தவறை பத்தாவது முறையாக யாராவது கவனிக்க வேண்டியிருக்கும்.

SoL-Pi தேடலை எவ்வாறு தானியங்கியாக்குகிறது

SoL-Pi அந்த மனித loop-ஐ எடுத்து தானியங்கியாக்குகிறது. ஒரு research agent மற்றொரு agent உருவாக்கிய traces-ஐ கவனிக்கிறது, harness-க்கு மாற்றங்களை முன்மொழிகிறது, பின்னர் அந்த முன்மொழிவுகளை தயாரிக்கப்பட்ட சூழல்களில் சோதிக்கிறது. வேட்பாளர் மாற்றங்கள் capability checks மற்றும் efficiency checks ஆகிய இரண்டின் மூலமும் சல்லடை செய்யப்படுகின்றன; செயல்திறனை நிலையாக வைத்துக்கொண்டே செலவைக் குறைக்கும் variants மட்டுமே தக்கவைக்கப்படுகின்றன.

இந்த அணுகுமுறை recursive self-improvement-ஐ அடிப்படையாகக் கொண்டது என்று ஆசிரியர்கள் விவரிக்கின்றனர்: ஒரு AI அமைப்பு மற்றொன்றின் இயக்க நிலைமைகளை திறம்பட மேம்படுத்துகிறது. இறுதி முடிவை மதிப்பிட பயன்படுத்தப்படும் மதிப்பீடு, harness freeze செய்யப்பட்ட பின்னரே நடைபெறுகிறது என்பதும், அந்த held-out மதிப்பீடு தேடல் செயல்முறைக்கு feedback அளிக்காது என்பதும் ஒரு முக்கிய விவரம். அந்தப் பிரிப்பு முக்கியமானது, ஏனெனில் optimization செயல்முறை இறுதியில் எதிர்கொள்ளப்போகும் சோதனைகளுக்கு எவ்வளவு தன்னைத் தகவமைத்துக்கொள்ள முடியும் என்பதை அது கட்டுப்படுத்துகிறது.

சோதனையின் அளவு

தேடல் பரந்த அளவில் இருந்தது. 535 executable சூழல்களில், SoL-Pi 152 தனித்துவமான திசைகளை ஆராய்ந்தது. பணிக் கலவையில் அடங்கியவை:

  • GitHub issue மற்றும் pull request ஜோடிகளிலிருந்து உருவாக்கப்பட்ட 495 பணிகள்
  • மதிப்பீட்டிற்காக வடிவமைக்கப்பட்ட 40 செயற்கை சோதனை நிகழ்வுகள்
  • மொத்தம் 3,000-க்கும் மேற்பட்ட இயக்கங்கள்
  • 60,000-க்கும் மேற்பட்ட agent-சூழல் தொடர்புகள்

இந்த அளவை, அமைப்பு எவ்வளவு பரந்த அளவில் தேடியது என்பதற்கான ஆதாரமாக ஆராய்ச்சியாளர்கள் முன்வைக்கின்றனர், ஆனால் அதிக தேடல் தானாகவே சிறந்த முடிவுகளை உருவாக்காது என்றும் அவர்கள் எச்சரிக்கின்றனர். பரந்த தன்மை ஒரு பயனுள்ள harness configuration-ஐக் கண்டுபிடிக்கும் வாய்ப்பை அதிகரிக்கிறது, ஆனால் அதை உறுதிப்படுத்தாது.

அளவிடப்பட்ட சேமிப்புகள்

முக்கிய எண்கள் கணிசமானவை. EdgeBench-இல், SoL-Pi Codex-ஐ விட 50 சதவீதம் tokens-ஐயும், Claude Code-ஐ விட 54.3 சதவீதம் tokens-ஐயும் சேமித்தது என்று ஆராய்ச்சியாளர்கள் கூறுகின்றனர்; செயல்திறன் ஏறக்குறைய அதே அளவில் இருந்தது. ஒட்டுமொத்த token குறைப்பு 49 சதவீதம் வரை, பணித் திறனில் சிறிய மாற்றத்துடன் என்று கட்டுரை வரையறுக்கிறது.

Flowchart of the search pipeline from trajectory rollouts through map-reduce analysis, mechanism proposal, candidate implementation, independent review, and development validation to a separate held-out evaluation.
The held-out evaluation happens only after the harness is frozen and doesn't feed back into the search process. | Image: Nvidia

அந்த வரையறை முக்கியமானது. ஒரு agent அடிக்கடி தோல்வியடைய அனுமதிக்கப்பட்டால், verification-ஐ தவிர்த்தால், அல்லது செல்லுபடியாகும் பணிகளில் முன்கூட்டியே நிறுத்தினால் token பயன்பாட்டைக் குறைப்பது எளிது. இங்கு கூறப்படும் கூற்று வேறுபட்டது: சேமிப்புகள் சிதைந்த நடத்தையிலிருந்து அல்லாமல், ஒல்லியான கட்டுப்பாட்டு logic-இலிருந்து வருகின்றன; அதனால்தான் தேர்வுச் செயல்முறையில் capability checks efficiency checks-க்கு அருகிலேயே அமர்ந்துள்ளன.

Overfitting கேள்வி

இந்த ஆராய்ச்சிப் பாதையில் ஒரு அறியப்பட்ட ஆபத்து உள்ளது. தானியங்கியாக மேம்படுத்தப்பட்ட harness-கள் overfit ஆகும் போக்கைக் கொண்டுள்ளன; அவை சரிசெய்யப்பட்ட traces-இல் மிகவும் திறமையாக இருக்கும், ஆனால் புதிய சூழ்நிலைகளுக்கு மோசமாகப் பொதுமைப்படுத்தும் என்று முந்தைய வேலைகள் காட்டியுள்ளன. Nvidia ஆசிரியர்கள் இதை அறிந்திருப்பதாகத் தெரிகிறது; அதனால்தான் இறுதி மதிப்பீடு ஒரு freeze செய்யப்பட்ட harness-இல் நடத்தப்பட்டு, தேடல் loop-இலிருந்து தனிமைப்படுத்தப்படுகிறது.

இருந்தபோதிலும், இந்த எச்சரிக்கையை முன்னெடுத்துச் செல்வது மதிப்புள்ளது. இங்கு பயன்படுத்தப்பட்ட சூழல்கள், எண்ணிக்கையில் அதிகமாக இருந்தாலும், coding agents எதிர்கொள்ளும் சிக்கலான யதார்த்தத்தின் ஒரு வரையறுக்கப்பட்ட மாதிரியே. 535 சூழல்களில் செம்மைப்படுத்தப்பட்ட ஒரு harness, உண்மையிலேயே அறிமுகமில்லாத ஒரு repository, நிலையற்ற ஒரு test suite, அல்லது தெளிவற்ற ஒரு bug report ஆகியவற்றை எதிர்த்து நிற்குமா என்பது, பரந்த பயன்பாட்டால் மட்டுமே பதிலளிக்கப்படும் ஒரு திறந்த கேள்வியாகவே உள்ளது.

Agent பொருளாதாரத்திற்கு இதன் பொருள்

ஆய்வகத்திற்கு வெளியே இந்த முடிவுகள் நிலைத்தால், அதன் தாக்கங்கள் தத்துவார்த்தமானவை அல்ல, நடைமுறைக்குரியவை. தன்னாட்சி coding agents-ஐ இயக்கும் குழுக்கள் ஒவ்வொரு token-க்கும் பணம் செலுத்துகின்றன; agents-ஐ பயனுள்ளதாக்கும் நீண்ட மேற்பார்வையற்ற அமர்வுகளே அவற்றை விலை உயர்ந்ததாக்குகின்றன. ஒரு workflow-இலிருந்து திறனை இழக்காமல் கிட்டத்தட்ட பாதி tokens-ஐ பிழிந்தெடுப்பது, ஒரு பட்ஜெட் அந்த அமர்வுகளில் எத்தனை நடத்த முடியும் என்பதை மாற்றுகிறது.

மேலும், optimization முயற்சியை எங்கு செலவிடுவது மதிப்புள்ளது என்பதில் ஒரு மாற்றத்தையும் இந்த வேலை குறிக்கிறது. Model-நிலை செயல்திறன் பல ஆண்டுகளாக இயல்புநிலை இலக்காக இருந்து வருகிறது, அது நிச்சயமாக இன்னும் முக்கியமானது. ஆனால் context, verification, retries பற்றிய முடிவுகள் எடுக்கப்படும் இடம் harness தான்; இந்தக் கட்டுரை விளக்குவது போல, அந்த முடிவுகளில்தான் பெரும் பங்கு வீண் செலவு குவிகிறது. மாதிரிக்கும் சூழலுக்கும் இடையிலான இடைவெளியே, இனி பார்க்க வேண்டிய மிகவும் பயனுள்ள இடமாக இருக்கலாம்.

இந்தக் கட்டுரை The Decoder-இன் அறிக்கையை அடிப்படையாகக் கொண்டது. மூலக் கட்டுரையைப் படிக்கவும்.

Originally published on the-decoder.com