HarnessDev: LLM-கள் தமக்கான உள்கட்டமைப்பைத் தாங்களே உருவாக்குகின்றன

ByteDance மற்றும் ஒரு பல்கலைக்கழகக் குழு இணைந்து HarnessDev என்ற கட்டமைப்பைத் தொடங்கியுள்ளனர். இது பெரிய மொழி மாதிரிகள் (LLMs) தமக்கான "ஏஜென்ட் இயங்குதளங்களை" (agent operating systems) எழுத அனுமதிக்கிறது, இவை Agent Harnesses என்று அழைக்கப்படுகின்றன. இந்தத் குழு ஒரு LLM-க்கு ஒரு சிறிய தொடக்கக் கருவியை (starter kit) வழங்கி, மீதமுள்ளவற்றை அதுவே விரிவுபடுத்த அனுமதிக்கிறது. இதன் மூலம், ஒரு மனிதன் ஒவ்வொரு வரியையும் தட்டச்சு செய்யாமலேயே, AI எவ்வாறு தனது சொந்த கருவிப் பயன்பாட்டு சுழற்சிகள் (tool-use loops), சரிபார்ப்புப் படிகள் மற்றும் பிழை கையாளுதல் போன்ற கட்டுப்பாட்டு அடுக்கை (control layer) உருவாக்க முடியும் என்பதைக் காட்டுகிறது.

தானாகவே உருவாக்கப்படும் ஹார்னஸ் (harness) ஏன் முக்கியமானது

AI ஏஜென்ட்கள், ஒற்றை-தூண்டுதல் (single-prompt) உதவியாளர்களிலிருந்து, API-களை அழைக்கும், தரவுத்தளங்களை (databases) ஆய்வு செய்யும் மற்றும் முடிவுகளை ஒருங்கிணைக்கும் பல-படிநிலை பணியாளர்களாக பரிணமித்துள்ளன. இதுவரை, ஒரு மாதிரி எப்போது தேடல் கருவியைக் அழைக்க வேண்டும், இடைநிலை நிலையை (intermediate state) எவ்வாறு சேமிக்க வேண்டும் மற்றும் இறுதிப் பதிலைப் எவ்வாறு சரிபார்க்க வேண்டும் என்பதைத் தீர்மானிக்கும் ஒருங்கிணைப்பு குறியீட்டை (orchestration code) டெவலப்பர்களே கைமுறையாக உருவாக்கினர். HarnessDev இந்த முறையை மாற்றுகிறது: ஒரு seed harness என்பது சுழற்சி (looping), கருவிகளைத் தேர்ந்தெடுத்தல் மற்றும் நிலையைத் கண்காணித்தல் போன்ற அடிப்படைச் செயல்பாடுகளுக்கான கட்டமைப்பை (scaffolding) மட்டும் வழங்குகிறது; பின்னர் LLM அதனை ஒரு முழுமையான ரன்டைமாக (runtime) விரிவுபடுத்துகிறது.

இந்த ஆய்வறிக்கையின் பெஞ்ச்மார்க்கில் (benchmark), அந்த மாதிரி 18 தனித்துவமான ஹார்னஸ்களை உருவாக்கியதுடன், அசல் விதைக்கு (seed) கூடுதலாக 17,000-க்கும் மேற்பட்ட வரிக் குறியீடுகளைச் சேர்த்துள்ளது. ஒவ்வொரு ஹார்னஸும் ஒரு பணியின் முழு வாழ்க்கைச் சுழற்சியையும் நிர்வகித்தது: சுழற்சிகளைச் செயல்படுத்துதல், சரியான கருவியைத் தேர்ந்தெடுத்தல், சூழலைப் (context) பராமரித்தல், நிலையைத் கண்காணித்தல், முடிவுகளைச் சரிபார்த்தல் மற்றும் பிழைகளிலிருந்து மீளுதல் போன்றவை இதில் அடங்கும்.

ஆய்வு வெளிப்படுத்திய மறைமுகச் செலவுகள்

இந்த எண்கள் ஈர்க்கக்கூடியதாகத் தோன்றினாலும், வெறும் செயலாக்கம் (raw implementation) என்பது நடைமுறைப் பயன்பாட்டிற்குச் சமமானது அல்ல என்று ஆய்வாளர்கள் எச்சரிக்கின்றனர்.

  • பயன்படுத்தப்படாத கூறுகள் (Unused components) – உருவாக்கப்பட்ட குறியீட்டில் ஒரு குறிப்பிடத்தக்க பகுதி உண்மையான பணிச் செயல்பாட்டின் போது ஒருபோதும் இயங்கவில்லை. ஏஜென்ட் ஒருபோதும் அழைக்காத செயல்பாடுகளை LLM எழுதியது, இது எந்த மதிப்பையும் வழங்காமல் குறியீட்டுத் தொகுப்பை (code base) அதிகரித்தது.
  • மாடல் லாக்-இன் (Model lock-in) – ஹார்னஸ்கள் அவற்றை உருவாக்கிய குறிப்பிட்ட LLM-க்கு ஏற்றவாறு அமைந்திருந்தன. அதே ஹார்னஸை வேறொரு மாதிரிக்கு வழங்கியபோது, அதன் செயல்திறன் குறிப்பிடத்தக்க அளவில் குறைந்தது. இது தானாக உருவாக்கப்பட்ட கட்டுப்பாட்டு தர்க்கத்தில் (control logic) அந்த குறிப்பிட்ட மாடலின் தனித்துவமான குணாதிசயங்கள் இணைந்துள்ளன என்பதைக் காட்டுகிறது.
  • சரிபார்ப்பு இடைவெளிகள் (Verification gaps) – ஒரு சோதனை ஹார்னஸ் 99% வெற்றி விகிதத்தைக் (100 ஓட்டங்களில் 99) குறிப்பிட்டது, ஆனால் அது 48% நேரங்களில் மட்டுமே சரியாக இருந்தது. வலுவான சரிபார்ப்பு இல்லையென்றால், ஒரு ஏஜென்ட் தவறான பதில்களைத் தன்னம்பிக்கையுடன் வழங்கக்கூடும்.
  • டோக்கன் கூடுதல் சுமை (Token overhead) – கணக்கீட்டுச் செலவின் (compute cost) அளவீடாகக் கருதப்படும் டோக்கன் பயன்பாடு, வியத்தகு முறையில் மாறுபட்டது. ஒரே முடிவைப் பெற ஒரு ஹார்னஸ் மற்றொன்றை விட ஏழு மடங்கு அதிக டோக்கன்களைத் தேவைப்பட்ந்தது, இது உற்பத்திச் சூழலில் (production settings) அளவிடுதல் (scalability) குறித்த கவலைகளை எழுப்பியுள்ளது.

குறியீடு ஒரு LLM-லிருந்து உருவானாலும் கூட, ஒழுக்கமான வடிவமைப்பின் (disciplined design) அவசியம் இந்தத் கண்டுபிடிப்புகள் மூலம் சுட்டிக்காட்டப்படுகிறது.

டெவலப்பர்கள் கவனத்தில் கொள்ள வேண்டியவை

  1. ஹார்னஸ் வடிவமைப்பை ஒரு கட்டமைப்பாக (architecture) கருதுங்கள் – மாடல் தானாகவே "வேலை செய்யும்" என்று நம்பிவிடாதீர்கள். LLM-ஐ அவற்றை நிரப்ப அனுமதிப்பதற்கு முன், சுழற்சி கட்டுப்பாடு, கருவித் தேர்வு, நிலை கையாளுதல் மற்றும் சரிபார்ப்பு ஆகியவற்றிற்கான தெளிவான தொகுதிகளை (modules) வரையறுக்கவும்.
  2. வலுவான சரிபார்ப்பை உருவாக்குங்கள் – ஒரு ஏஜென்ட்டின் கூற்றை உண்மைத் தரவுகளுடனோ (ground truth) அல்லது ஒரு இரண்டாம் நிலை மாடலுடனோ ஒப்பிடும் தெளிவான சோதனைகளைச் சேர்க்கவும். 99% சுய-அறிவிக்கப்பட்ட வெற்றி விகிதத்திற்குப் பிறகும் ஆய்வின் 48% துல்லியம் என்பது, சரிபார்ப்பு என்பது ஒரு கூடுதல் சிந்தனையாக (afterthought) மட்டும் இருக்கக்கூடாது என்பதைக் காட்டுகிறது.
  3. டோக்கன் வரவுசெலவுத் திட்டத்தைக் கவனியுங்கள் – மிகவும் சிக்கலான ஹார்னஸ்கள் டோக்கன் எண்ணிக்கையை அதீதமாக அதிகரிக்கக்கூடும். மறைமுகமான செலவு அதிகரிப்பைத் தவிர்க்க, பல்வேறு ஹார்னஸ் மாறுபாடுகளை ஆரம்பத்திலேயே ஆய்வு செய்யவும்.
  4. பல்வேறு மாடல்களில் சோதிக்கவும் – ஒரே ஹார்னஸை பல LLM பேக்-எண்டுகளுடன் (back-ends) இயக்கவும். செயல்திறன் கடுமையாகக் குறைந்தால், உங்களுக்கு மாடல்-சார்பற்ற (model-agnostic) வடிவமைப்பு அல்லது ஒவ்வொரு மாடலுக்கும் தனித்தனி ஹார்னஸ்கள் தேவைப்படலாம்.

சுருக்கமாக: LLM-கள் தமக்கான இயங்குதளம் போன்ற கட்டுப்பாட்டு குறியீட்டைத் தாங்களே எழுத முடியும் என்பதை HarnessDev நிரூபிக்கிறது.