Context Windows மிகப்பெரிய அளவில் விரிவடைந்து வருகின்றன

எல்லாவற்றிற்கும் மக்கள் 'agent' என்ற வார்த்தையைப் பயன்படுத்துகிறார்கள்.

ஒரு கருவியை (tool) அழைக்கும் ஒரு function ஒரு agent ஆகும். நினைவாற்றல் (memory) கொண்ட ஒரு chatbot ஒரு agent ஆகும். ஒரு loop கொண்ட ஒரு script ஒரு agent ஆகும்.

இந்தத் தவறு மோசமான பொறியியலுக்கு (engineering) வழிவகுக்கிறது. குழுக்கள் எளிய பணிகளுக்கு அதிகப்படியான பொறியியலைச் செய்கின்றன (over-engineer), அதே சமயம் சிக்கலான பணிகளுக்குத் தேவையான பொறியியலைச் செய்யத் தவறிவிடுகின்றன (under-engineer). ஒரே ஒரு நல்ல prompt போதுமானதாக இருக்கும் workflows-களுக்கு, agent orchestration செய்ய வாரக்கணக்கில் செலவிடுவதை நான் பார்க்கிறேன்.

ஒரு உண்மையான agent பற்றிய எனது வரையறை இதோ.

ஒரு agent-க்கு ஒரு நோக்கம் (objective) இருக்கும். அது வெறும் அறிவுறுத்தல்களை மட்டும் பின்பற்றுவதில்லை. அடுத்து என்ன செய்ய வேண்டும் என்பதை அதுவே தீர்மானிக்கிறது. அது தோல்விகளைக் கையாள்கிறது. எப்போது நிறுத்த வேண்டும் என்பதும் அதற்குத் தெரியும்.

இந்த அளவுகோல்களைப் (benchmarks) பயன்படுத்தவும்:

• ஒவ்வொரு அடியையும் ஒரு மனிதன் வழிநடத்த வேண்டும் என்றால், அது ஒரு chat interface.
• ஒரு தோல்வியடைந்த tool call-லிருந்து சிஸ்டம் மீண்டு வந்தால், அது ஒரு agent-ஐ நோக்கி நகர்கிறது என்று அர்த்தம்.
• சிஸ்டம் ஒரு இலக்கை பணிகளாகப் (tasks) பிரித்து அவற்றை ஒப்படைத்தால், அது ஒரு உண்மையான agent.

பெரும்பாலான வெற்றிகரமான agents குறுகிய நோக்கத்தைக் கொண்டவை (narrow). அவை ஒரு வேலையைச் சிறப்பாகச் செய்கின்றன. அவை customer support triage அல்லது document extraction போன்றவற்றைச் செய்கின்றன. அவை பொதுவான தர்க்க இயந்திரங்கள் (general reasoning engines) அல்ல.

வெற்றிகரமான குழுக்கள் இந்த மூன்று விஷயங்களில் கவனம் செலுத்துகின்றன:

• Tool design: இடைமுகம் (interface) எவ்வளவு தூய்மையாக உள்ளது?
• Failure handling: ஒரு tool எதையும் திருப்பித் தராதபோது என்ன நடக்கும்?
• Observability: agent ஏன் ஒரு முடிவை எடுத்தது என்பதை உங்களால் கண்டறிய முடிகிறதா?

தோல்வியடையும் குழுக்கள் ஒரு மாடலுக்குப் பதிலாகப் புதிய மாடலை மட்டும் மாற்றிவிட்டு, சிறந்த முடிவுகளை எதிர்பார்க்கிறார்கள். அவர்கள் சிஸ்டம் வடிவமைப்பைப் (system design) புறக்கணிக்கிறார்கள்.

LangChain அல்லது CrewAI போன்ற frameworks ஒவ்வொரு மாதமும் மாறுகின்றன. ஒரு pattern-ஐ விட framework-க்கு முக்கியத்துவம் குறைவு.

இந்த patterns-களைப் பயன்படுத்தவும்:

• Plan then execute: தர்க்க ரீதியான படிநிலையை (reasoning step) செயல்படுத்துதல் படிநிலையிலிருந்து (execution step) பிரிக்கவும்.
• Separate retrieval from reasoning: context-ஐப் பெறுவது (fetching) அதைப்பயன்படுத்துவதிலிருந்து வேறுபட்ட வேலை.
• Explicit handoffs: ஒரு agent தனது வேலையை மற்றொரு agent-இடம் ஒப்படைக்கும்போது, கட்டமைக்கப்பட்ட பதிவுகளை (structured logs) பயன்படுத்தவும்.

Framework என்பது வெறும் சாரத் தூண்கள் (scaffolding) போன்றது. Architecture தான் கட்டிடம்.

RAG என்பது ஒரு தரநிலை (standard), ஆனால் chunking பெரும்பாலும் சரியாக இருப்பதில்லை. நீங்கள் ஆவணங்களைச் சரியாகப் பிரிக்கவில்லை என்றால், மாடல் context-ஐ இழந்துவிடும். இது hallucinations-க்கு வழிவகுக்கும்.

உங்கள் RAG முடிவுகள் பயனற்றதாக இருந்தால், உங்கள் chunking மற்றும் metadata-வைச் சரிபார்க்கவும். மாடல் என்பது அரிதாகவே பிரச்சனையாக இருக்கும்.

மாடல்கள் மேம்படும். Context windows விரிவடையும். Token செலவுகள் குறையும்.

இவை எதுவும் உண்மையான பொறியியல் சவாலைத் தீர்க்காது. நீங்கள் கவனித்துக் கொண்டிருக்காத போதும் சரியாகச் செயல்படும் சிஸ்டம்களை நீங்கள் உருவாக்க வேண்டும்.

Governance, observability மற்றும் நம்பகமான tool பயன்பாடு ஆகியவற்றில் கவனம் செலுத்துங்கள். சிறந்த பொறியாளர்கள் மாடல் ஆராய்ச்சியாளர்களாக இருக்க மாட்டார்கள். அவர்கள் நம்பகமான AI-ஐ உருவாக்கும் சிஸ்டம் வடிவமைப்பாளர்களாக (systems designers) இருப்பார்கள்.

சூழல் சாளரங்கள் (Context windows) மிகப்பெரியதாகி வருகின்றன, அது ஏன் அனைத்தையும் மாற்றுகிறது என்பது இங்கே

சூழல் சாளரங்கள் (Context windows) மிகப்பெரியதாகி வருகின்றன. கண் இமைக்கும் நேரத்தில் நாம் 4k-லிருந்து 128k மற்றும் 1M+ டோக்கன்கள் (tokens