மாடல் என்பது தயாரிப்பு அல்ல. உண்மையில் எது தயாரிப்பு என்பது இதோ.
நான் AI-ஐ உருவாக்கும் மற்றும் அதை வெளியிடும் பொறியாளர்களுடன் உரையாடுவதிலும், உருவாக்குவதிலும் எனது நேரத்தைச் செலவிடுகிறேன். டெமோக்களுக்கும் (demos) உண்மையான உற்பத்தி அமைப்புகளுக்கும் (production systems) இடையே ஒரு இடைவெளி உள்ளது. பலர் இந்த இடைவெளியைப் பற்றி நேர்மையாக இருப்பதில்லை.
அனைவரும் எல்லாவற்றையும் ஒரு ஏஜென்ட் (agent) என்று அழைக்கிறார்கள். ஒரு லூப் (loop) கொண்ட ஸ்கிரிப்ட் ஒரு ஏஜென்ட். நினைவாற்றல் கொண்ட ஒரு சாட்பாட் (chatbot) ஒரு ஏஜென்ட். இது பொறியியல் தவறுகளுக்கு வழிவகுக்கிறது. நீங்கள் எளிய பணிகளுக்கு அதிகப்படியான பொறியியல் நுட்பங்களையும் (over-engineer), சிக்கலான பணிகளுக்கு போதுமான பொறியியல் நுட்பங்களையும் (under-engineer) பயன்படுத்துகிறீர்கள்.
ஒரு ஏஜென்ட்டிற்கு ஒரு குறிக்கோள் தேவை. அது வெறும் ஒரு கட்டளையை மட்டும் பின்பற்றுவதில்லை. அடுத்து என்ன செய்ய வேண்டும் என்பதை ஒரு ஏஜென்ட் தீர்மானிக்கிறது. அது தோல்விகளைக் கையாள்கிறது. அது எப்போது முடிந்தது என்பதை அதுவே அறியும்.
- ஒரு மனிதன் உங்கள் அமைப்பிற்கு ஒவ்வொரு அடியையும் சொன்னால், அது ஒரு சாட் இன்டர்ஃபேஸ் (chat interface).
- உங்கள் அமைப்பு ஒரு தோல்வியடைந்த டூல் கால்லிலிருந்து (tool call) மீண்டு வந்தால், நீங்கள் ஒரு ஏஜென்ட்டை உருவாக்குகிறீர்கள்.
- உங்கள் அமைப்பு ஒரு இலக்கை துணைப் பணிகளாக (subtasks) பிரித்தால், அது ஒரு உண்மையான ஏஜென்ட்.
உண்மையான ஏஜென்ட் பயன்பாடுகள் (deployments) குறுகிய எல்லை கொண்டவை. அவை ஆவணப் பிரித்தெடுத்தல் (document extraction) அல்லது குறியீடு ஆய்வு (code review) போன்ற ஒரு விஷயத்தை சிறப்பாகச் செய்யும். வெற்றிகரமான குழுக்கள் புதிய மாடல்களைத் துரத்தவில்லை. அவை இந்த மூன்று பகுதிகளில் கவனம் செலுத்துகின்றன:
- டூல் வடிவமைப்பு (Tool design): இன்டர்ஃபேஸ் எவ்வளவு தூய்மையாக உள்ளது?
- தோல்வி கையாளுதல் (Failure handling): ஒரு டூல் எதையும் திரும்பத் தராமல் போனால் என்ன நடக்கும்?
- கண்காணிப்புத் திறன் (Observability): ஏஜென்ட் ஏன் ஒரு முடிவை எடுத்தது என்பதை உங்களால் கண்டறிய முடிகிறதா?
LangChain அல்லது CrewAI போன்ற கட்டமைப்புகளை (frameworks) விட வடிவமைப்பு முறைகளே (patterns) முக்கியம். கட்டமைப்பு என்பது ஒரு சாரமரம் போன்றது. ஆர்க்கிடெக்சர் (architecture) என்பது கட்டிடம் போன்றது.
இந்த வடிவமைப்பு முறைகளைப் பயன்படுத்துங்கள்:
- திட்டமிட்டு பின் செயல்படுங்கள் (Plan then execute). திட்டமிடுவதற்கு ஒரு படிநிலையும், செயல்படுத்துவதற்கு ஒரு தனிப் படிநிலையும் பயன்படுத்துங்கள்.
- மீட்டெடுப்பிலிருந்து (retrieval) பகுத்தறிவை (reasoning) பிரிக்கவும். சூழலைத் திரட்டுவதும் (fetching context), அந்தச் சூழலைப் பயன்படுத்துவதும் வெவ்வேறு வேலைகள்.
- தெளிவான ஒப்படைப்புகள் (Explicit handoffs). ஒரு ஏஜென்ட் மற்றொரு ஏஜென்ட்டிடம் வேலையை ஒப்படைக்கும்போது, அந்த ஒப்படைப்பை முறையாக வடிவமைக்கவும்.
RAG என்பது ஒரு தரநிலையான முறை, ஆனால் சங்கிங் (chunking) பெரும்பாலும் தவறாக உள்ளது. நீங்கள் ஆவணங்களை மோசமாகப் பிரித்தால், மாடல் சூழலை இழந்து தவறான தகவல்களை உருவாக்கும் (hallucinates). உங்கள் RAG முடிவுகள் பயனற்றதாக இருந்தால், உங்கள் சங்கிங் மற்றும் மெட்டாடேட்டாவை (metadata) சரிசெய்யவும். எம்பெடிங் மாடலை (embedding model) குற்றம் சொல்லாதீர்கள்.
மாடல்கள் மேம்படும். கான்டெக்ஸ்ட் விண்டோக்கள் (context windows) விரிவடையும். செலவுகள் குறையும். இது பொறியியல் சவாலை மாற்றாது. நீங்கள் கவனித்துக் கொண்டிருக்காத போதும் நம்பகமான அமைப்புகளை நீங்கள் உருவாக்க வேண்டும்.
நிர்வாகம் (governance), கண்காணிப்புத் திறன் (observability) மற்றும் டூல் பயன்பாடு ஆகியவற்றில் கவனம் செலுத்துங்கள். வெறும் பிராம்ட் இன்ஜினியரிங்கில் (prompt engineering) மட்டும் கவனம் செலுத்தாமல், சிஸ்டம் டிசைனில் (systems design) தேர்ச்சி பெறும் பொறியாளர்களே முக்கியமானவர்கள் ஆவார்கள்.
Source: https://dev.to/aibughunter/the-model-is-not-the-product-heres-what-actually-is-52b5