𝗔𝗴𝗲𝗻𝘁 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗜𝘀 𝗔 𝗖𝗼𝗺𝗽𝘂𝘁𝗲 𝗔𝗹𝗹𝗼𝗰𝗮𝘁𝗶𝗼𝗻 𝗣𝗿𝗼𝗯𝗹𝗲𝗺
சமீபத்தில் மூன்று தனித்தனி குழுக்கள் AI ஏஜென்ட் வடிவமைப்பிற்கான ஒரே முடிவுக்கு வந்துள்ளன.
Anthropic நிறுவனம் advisor strategy குறித்த ஒரு வலைப்பதிவை வெளியிட்டுள்ளது. அவர்கள் முக்கியச் சுழற்சியை (main loop) இயக்க ஒரு மலிவான மாடலைப் பயன்படுத்துகின்றனர். மலிவான மாடல் சிக்கலில் சிக்கிக்கொள்ளும் போது மட்டுமே அவர்கள் ஒரு விலையுயர்ந்த மாடலை அழைக்கிறார்கள். BrowseComp-ல் இந்த அமைப்பு, அனைத்திற்கும் ஒரு உயர்தர மாடலைப் பயன்படுத்துவதற்கான செலவில் வெறும் 15% செலவில் 41.2% துல்லியத்தை எட்டியது.
Shopify நிறுவனத்தைச் சேர்ந்த Tobi Lutke, X தளத்தில் இதே போன்ற ஒரு அமைப்பைப் பகிர்ந்துள்ளார். அவர் ஆராய்ச்சிக்காக ஒரு local model-ஐ இயக்குகிறார் மற்றும் ஒரு frontier model-ஐ advisor ஆகப் பயன்படுத்துகிறார். டெவலப்பர்கள் சில மணிநேரங்களிலேயே இதற்கான open-source பதிப்புகளை உருவாக்கினர்.
HazyResearch ஒரு compressor-predictor கட்டமைப்பைப் பற்றிய ஆய்வறிக்கையை வெளியிட்டுள்ளது. ஒரு சிறிய மாடல், ஒரு பெரிய மாடல் சிந்திப்பதற்குத் தேவையான சூழலை (context) சுருக்கித் தருகிறது. அவர்களின் அமைப்பு 26% செலவில் 99% துல்லியத்தை மீட்டெடுத்தது.
இந்த ஒற்றுமை தற்செயலானது அல்ல. இது ஒரு குறிப்பிட்ட வடிவமைப்பு விதியைப் பின்பற்றுகிறது: cost-curve frame.
இந்தத் தொடரில் மூன்று அடுக்குகளில் இந்த கட்டமைப்பைப் பற்றி நான் வாதிட்டுள்ளேன்:
- Layer 1 (Retrieval): பெரும்பாலான code tasks-களுக்கு ஏன் tool-loops, RAG-ஐ விடச் சிறந்தது.
- Layer 2 (Storage): symbol graphs-களுக்கு ஏன் SQLite, vector databases-ஐ விடச் சிறந்தது.
- Layer 3 (Orchestration): மாடல் தேர்வில் ஏன் advisor strategy வெற்றி பெறுகிறது.
இதன் தர்க்கம் ஒன்றுதான். பெரும்பாலான ஏஜென்ட் பணிகள் பல குறைந்த மதிப்புள்ள செயல்பாடுகளையும், சில அதிக மதிப்புள்ள முடிவுகளையும் கொண்டிருக்கின்றன.
ஒவ்வொரு token-க்கும் நீங்கள் ஒரு விலையுயர்ந்த மாடலைப் பயன்படுத்தினால், சூழலை வாசிப்பது அல்லது உரையை வடிவமைப்பது போன்ற வழக்கமான வேலைகளுக்காகப் பணத்தை வீணடிக்கிறீர்கள். advisor strategy இந்த வழிகளைப் பிரிக்கிறது. நீங்கள் பெரும்பான்மையான வேலைகளுக்கு ஒரு மலிவான executor-ஐயும், முக்கியமான முடிவெடுக்கும் புள்ளிகளுக்கு மட்டுமே ஒரு விலையுயர்ந்த advisor-ஐயும் பயன்படுத்துகிறீர்கள்.
நீங்கள் ஏஜென்ட்களை உருவாக்குகிறீர்கள் என்றால், இந்த மூன்று பொறியியல் சவால்களைக் கவனத்தில் கொள்ளுங்கள்:
- Data Egress: ஒரு தொலைதூர advisor-க்குச் சூழலை அனுப்புவது முக்கியமான தரவுகளைக் கசிய விடக்கூடும். ஒரு redaction layer-ஐப் பயன்படுத்தவும்.
- Escalation Policy: advisor-ஐ எப்போது அழைக்க வேண்டும் என்று தீர்மானிப்பது கடினம். மிக விரைவாக அழைப்பது பணத்தை வீணடிக்கும். மிகத் தாமதமாக அழைப்பது நேரத்தை வீணடிக்கும்.
- Handoff Design: advisor ஒரு முழுமையான தீர்வை வழங்காமல், ஒரு குறுகிய திட்டத்தை மட்டுமே வழங்க வேண்டும்.
இந்த முறை உண்மையானது, ஏனெனில் இது திறமையானது. தேவைப்படாத tokens-களுக்கு frontier-model விலையைச் செலுத்துவதை நிறுத்துங்கள்.
Optional learning community: https://t.me/GyaanSetuAi