உங்கள் மாடலை ஃபைன்-டியூன் (Fine-Tuning) செய்வதை நிறுத்துங்கள். உங்கள் கட்டமைப்பு (Architecture) தான் பிரச்சனை.

டெமோக்கள் சிறப்பாகத் தெரியும். ஆனால் தயாரிப்பு அமைப்புகள் (Production systems) வேறாக இருக்கும். இவ்விரண்டிற்கும் இடையே ஒரு இடைவெளி உள்ளது.

இப்போது எல்லாவற்றையும் மக்கள் ஒரு ஏஜென்ட் (agent) என்று அழைக்கிறார்கள். நினைவாற்றல் கொண்ட ஒரு சாட்பாட் (chatbot) ஒரு ஏஜென்ட். ஒரு லூப் (loop) கொண்ட ஸ்கிரிப்ட் ஒரு ஏஜென்ட். இந்தத் தவறு பொறியியல் பிழைகளுக்கு வழிவகுக்கிறது. இதன் விளைவாக, எளிமையான பணிகளுக்கு அதிகப்படியான பொறியியல் நுட்பங்களையும் (over-engineering), சிக்கலான பணிகளுக்குப் போதுமான பொறியியல் நுட்பங்களையும் (under-engineering) பயன்படுத்தும் நிலை ஏற்படும்.

ஒரு ஏஜென்ட்டிற்கு ஒரு குறிக்கோள் தேவை. அது வெறும் ஒரு கட்டளையை மட்டும் பின்பற்றுவதில்லை. அடுத்து என்ன செய்ய வேண்டும் என்பதை அதுவே தீர்மானிக்கிறது. அது தோல்விகளைக் கையாள்கிறது. எப்போது நிறுத்த வேண்டும் என்பதையும் அது அறியும்.

உங்கள் அமைப்பைச் சரிபார்க்க இந்த விதிகலைப் பயன்படுத்தவும்:

  • ஒவ்வொரு அடியையும் ஒரு மனிதன் வழிநடத்த வேண்டும் என்றால், அது ஒரு சாட் இடைமுகம் (chat interface).
  • ஒரு தோல்வியடைந்த டூல் கால்லிலிருந்து (tool call) அது மீண்டு வந்தால், அது ஒரு ஏஜென்ட்.
  • ஒரு இலக்கை துணைப் பணிகளாக (subtasks) பிரித்தால், அது ஒரு உண்மையான ஏஜென்ட்.

வெற்றிகரமான குழுக்கள் புதிய மாடல்களின் பின்னால் ஓடுவதில்லை. அவை குறிப்பிட்ட நோக்கத்திற்காக உருவாக்கப்பட்ட குறுகிய குழாய்களை (pipelines) கட்டமைக்கின்றன. அவை இந்த மூன்று விஷயங்களில் கவனம் செலுத்துகின்றன:

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

நீங்கள் பயன்படுத்தும் பிரேம்வொர்க்கை (framework) விட உங்கள் முறைகளே (patterns) முக்கியம். நான் வெவ்வேறு பிரேம்வொர்க்குகளில் கட்டமைப்புகளை மீண்டும் உருவாக்கியுள்ளேன், ஆனால் முடிவுகள் ஒன்றாகவே உள்ளன. பிரேம்வொர்க் என்பது ஒரு சாரக்கட்டு (scaffolding) போன்றது. கட்டமைப்பு (architecture) என்பது ஒரு கட்டிடம் போன்றது.

இந்த முறைகளைப் பின்பற்றுங்கள்:

  • திட்டமிட்டு பின் செயல்படுங்கள். காரணமறிதலுக்கு (reasoning) ஒரு படிநிலையையும், செயல்படுவதற்கு ஒரு தனிப் படிநிலையையும் பயன்படுத்துங்கள்.
  • மீட்டெடுப்பிலிருந்து (retrieval) காரணமறிதலைத் தனிமைப்படுத்துங்கள். சூழலைத் திரட்டுவதும் (fetching context), அந்தச் சூழலைப் பயன்படுத்துவதும் வெவ்வேறு வேலைகள்.
  • தெளிவான ஒப்படைப்புகளைப் (explicit handoffs) பயன்படுத்துங்கள். ஒரு ஏஜென்ட் மற்றொரு ஏஜென்ட்டிடம் வேலையை ஒப்படைக்கும்போது, கட்டமைக்கப்பட்ட பதிவுகளைப் (structured logs) பயன்படுத்துங்கள்.

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

உங்கள் RAG பைப்பலைன் (pipeline) பயனற்ற முடிவுகளைத் தந்தால், உங்கள் சங்கிங் மற்றும் மெட்டாடேட்டாவைப் (metadata) பாருங்கள். எம்பெடிங் மாடலை (embedding model) குறை சொல்லாதீர்கள்.

நீங்கள் நம்பக்கூடிய அமைப்புகளை உருவாக்குவதே பொறியியல் சவாலாகும். நிர்வாகம் (governance), கவனிப்புத்திறன் (observability) மற்றும் நம்பகமான டூல் பயன்பாடு ஆகியவற்றில் கவனம் செலுத்துங்கள். பெஞ்ச்மார்க் (benchmarks) மதிப்பெண்களுக்காக மட்டும் ஓடாதீர்கள்.

சிறந்த பொறியாளர்கள் சிஸ்டம் டிசைனில் (systems design) கவனம் செலுத்துவார்கள். மற்றவர்கள் பராமரிக்கக்கூடிய மற்றும் நம்பக்கூடிய AI அமைப்புகளை அவர்கள் உருவாக்குவார்கள்.

ஆதாரம்: https://dev.to/aibughunter/stop-fine-tuning-your-model-your-architecture-is-the-problem-3kkg