ஒரு மெருகூட்டப்பட்ட AI டெமோவிற்கும், அதிகாலை 2 மணிக்கு எந்தப் பிரச்சனையும் இன்றி இயங்கும் ஒரு தயாரிப்பு முறைக்கும் (production system) இடையிலான இடைவெளி மிகப்பெரியது. டெமோக்களை உருவாக்கும் பெரும்பாலான மக்களுக்கு இது தெரியும். ஆனால், அவர்கள் ஒரு திட்டத்தை (blueprint) விற்கும் போது அதை எப்போதும் வெளிப்படையாகச் சொல்வதில்லை. தயாரிப்புச் சூழலில் (production), நீங்கள் தவறான ஃபவுண்டேஷன் மாடலை (foundation model) தேர்ந்தெடுத்ததால் உங்கள் பைப்லைன் (pipeline) தோல்வியடைவதில்லை. மாறாக, உங்கள் சிஸ்டம் டிசைன் ஒரு முன்மாதிரியை (prototype) ஒரு தயாரிப்பாக (product) கருதுவதால் அது தோல்வியடைகிறது.

தற்போது, எல்லாவற்றையும் ஏஜென்ட் (agent) என்று அழைக்கிறார்கள். ஒரு நிபந்தனை நிறைவேறும் வரை லூப் (loop) செய்யும் ஒரு ஸ்கிரிப்ட் திடீரென்று ஒரு ஏஜென்ட் ஆகிவிடுகிறது. கடைசி மூன்று செய்திகளை நினைவகத்தில் (memory) சேமித்து வைக்கும் ஒரு சாட்பாட் (chatbot) கூட ஒரு ஏஜென்ட் தான். இந்தத் தெளிவற்ற கலைச்சொற்கள் பொறியியல் ரீதியாகப் பெரும் பாதிப்பை ஏற்படுத்துகின்றன. ஒரு எளிய cron job மூலம் கையாளக்கூடிய ஐந்து படிநிலைகளைக் கொண்ட பணிப்பாய்வை (workflow) தானியக்கமாக்க, குழுக்கள் கனமான ஏஜென்ட் கட்டமைப்புகளை (agent frameworks) நாடுகின்றன. அதே நேரத்தில், பெரிய மொழி மாதிரிகள் (large language models) விளிம்பு நிலைச் சூழல்களை (edge cases) மாயாஜாலமாகச் சரிசெய்துவிடும் என்று நம்பி, உண்மையான சிக்கலான வேலைகளுக்குத் தேவையான முதலீடுகளைக் குறைக்கின்றனர். அது நடக்காது.

ஒரு ஏஜென்ட் உண்மையில் என்ன?

ஒரு ஏஜென்ட் என்பது ஒரு நோக்கத்தைக் (objective) கொண்ட ஒரு அமைப்பாகும். அது ஒரு மனிதன் கொடுக்கும் தொடர்ச்சியான அறிவுறுத்தல்களை மட்டும் அப்படியே பின்பற்றுவதில்லை. உலகத்தின் நிலையைப் (state of the world) பொறுத்து அடுத்து என்ன செய்ய வேண்டும் என்பதை அதுவே தீர்மானிக்கிறது. ஒரு கருவி (tool) பழுதானாலோ அல்லது தரவு காணாமல் போனாலோ, அது தோல்விகளைக் கையாள்கிறது. அதன் இலக்கு எப்போது முடிவடைகிறது என்பதை அது அறிந்து தானாகவே நின்றுவிடும்.

நீங்கள் எதை உருவாக்குகிறீர்களோ, அதைத் தீர்மானிக்க இந்த மூன்று விதிகலைப் பயன்படுத்தவும்:

  • ஒவ்வொரு அடியையும் ஒரு மனிதன் சொல்லிக்கொண்டே இருக்க வேண்டும் என்றால், அது ஒரு சாட் இன்டர்ஃபேஸ் (chat interface). நீங்கள் தான் வாகனம் ஓட்டுகிறீர்கள். அந்த சிஸ்டம் ஒரு மிக மரியாதையான ஸ்டீயரிங் வீல் மட்டுமே.
  • ஒரு தோல்வியடைந்த டூல் கால்லிலிருந்து (tool call) அது மீண்டு வர முடிந்தால், நீங்கள் சரியான பாதையில் இருக்கிறீர்கள். ஒரு search API காலாவதியாவதோ (timeout) அல்லது 500 பிழையைத் தருவதோ வேலையை முடித்துவிடக் கூடாது. அந்த சிஸ்டம் மீண்டும் முயற்சிக்க வேண்டும் (retry), சற்று இடைவெளி விட்டு முயல வேண்டும், மாற்று ஆதாரத்திற்கு மாற வேண்டும் அல்லது உதவி கேட்க வேண்டும்.
  • அது ஒரு இலக்கை துணைப் பணிகளாகப் பிரித்து அவற்றை ஒப்படைத்தால், அது ஒரு உண்மையான ஏஜென்ட். "Q3 இணக்க அறிக்கையைத் தயார் செய்" போன்ற ஒரு கட்டளையை நீங்கள் கொடுத்தால், அது தரவு ஆதாரங்களைக் கண்டறிந்து, தரவுப் பிரித்தெடுப்பதைத் திட்டமிட்டு, மூல எண்களைக் கணக்கீட்டுத் தொகுதிக்கு (calculation module) அனுப்பி, வரைவு அறிக்கையை மதிப்பாய்விற்கு அனுப்பி, எப்போது நிறுத்த வேண்டும் என்பதையும் அதுவே அறியும்.

உங்கள் சிஸ்டம் இவற்றைச் செய்யவில்லை என்றால், உங்களுக்கு ஏஜென்ட் பிரச்சனை இல்லை. உங்களுக்கு ஸ்கிரிப்டிங் பிரச்சனை அல்லது பணிப்பாய்வு (workflow) பிரச்சனை உள்ளது. இதை ஆரம்பத்திலேயே ஒப்புக்கொள்வது, தேவையற்ற கட்டமைப்புகளால் (framework bloat) ஏற்படும் வாரக்கணக்கிலான நேர விரயத்தைத் தவிர்க்க உதவும்.

வெற்றிபெறும் குழுக்கள் உண்மையில் எதற்கு முன்னுரிமை அளிக்கின்றன?

நம்பகமான அமைப்புகளை உருவாக்கும் குழுக்கள், ஒரு பெஞ்ச்மார்க்கில் (benchmark) சில புள்ளிகளைப் பெறுவதற்காகத் தொடர்ந்து புதிய மாடல்களை மாற்றி மாற்றிப் பயன்படுத்துவதில் நேரத்தைச் செலவிடுவதில்லை. அவர்கள் மூன்று சலிப்பான ஆனால் அதிகத் தாக்கத்தை ஏற்படுத்தும் பகுதிகளில் கவனம் செலுத்துகிறார்கள்.

டூல் வடிவமைப்பு (Tool design). நீங்கள் ஒரு ஏஜென்ட்டுக்கு வழங்கும் கருவிகளைப் பொறுத்தே அதன் திறனும் அமையும். ஒரு தேடல் செயல்பாடு (search function) சீரற்ற புலப் பெயர்களுடன் (field names) கூடிய நெஸ்டட் JSON-ஐத் திருப்பிக் கொடுத்தால், அந்த மாடல் உள்ளடக்கத்தைப் பற்றிச் சிந்திப்பதற்குப் பதிலாக, அதன் கட்டமைப்பைப் பகுப்பாய்வு செய்வதிலேயே தனது விலைமதிப்பற்ற கான்டெக்ஸ்ட் விண்டோவை (context window) வீணடிக்கும். டூல் விளக்கங்கள் தெளிவற்றதாக இருந்தால், மாடல் தவறான ஆர்குமென்ட்களைக் கற்பனை செய்து உருவாக்கும் (hallucinate). டூல் இன்டர்ஃபேஸ்களை, சுத்தமான உள்ளீடுகள் (inputs), கணிக்கக்கூடிய வெளியீடுகள் (outputs) மற்றும் தெளிவான பிழை நிலைகள் (error states) தேவைப்படும் ஒரு மிகத் துல்லியமான ஜூனியர் டெவலப்பருக்கான API போலக் கருதுங்கள்.

தோல்வி கையாளுதல் (Failure handling). ஒரு தரவு மீட்டெடுப்புப் படி (retrieval step) எதையும் வழங்கவில்லை என்றால் என்ன நடக்கும்? பல பைப்லைன்கள் காலியான கான்டெக்ஸ்டை (empty context) அமைதியாக ப்ராம்ப்ட்டிற்குள் (prompt) தள்ளிவிடுகின்றன, இதனால் மாடல் தனது பயிற்சித் தரவிலிருந்து ஒரு பதிலை மாயாஜாலமாக உருவாக்குகிறது (hallucinate). இது ஒரு வசதி அல்ல; இது தயாரிப்புச் சூழலில் (production) எப்பொழுது வேண்டுமானாலும் நடக்கக்கூடிய ஒரு விபத்து. ஒரு சரியான சிஸ்டம் அந்தத் தரவு இல்லாமையை உணர்ந்து கொள்ளும். அது விரிவான தேடலுடன் மீண்டும் முயற்சிக்கும். ஒரு மனிதரிடம் ஒப்படைக்கும் அல்லது தெளிவான விளக்கத்துடன் நின்றுவிடும். தரவு இல்லாதபோது ஏதோ ஒன்றைச் செய்ததாக அது ஒருபோதும் pretending செய்யாது.

கண்காணிப்புத் திறன் (Observability). ஏஜென்ட் ஏன் ஒரு குறிப்பிட்ட முடிவை எடுத்தது என்பதை நீங்கள் பார்க்க வேண்டும். இறுதி வெளியீடு மட்டுமல்ல—சிந்தனைச் சங்கிலி (chain of thought), டூல் தேர்வு, மீட்டெடுக்கப்பட்ட துண்டுகள் (retrieved chunks) மற்றும் ஹேண்ட்ஆஃப் லாக்ஸ் (handoff logs) ஆகிய அனைத்தையும் பார்க்க வேண்டும். அந்தத் தடயங்கள் (trace) இல்லாமல், டீபக் செய்வது (debugging) வெறும் யூகமாகிவிடும். அடுத்த வாரம் ஒரு பயனர் தவறான பதிலைப் பற்றிப் புகார் கூறினால், எந்தத் தரவு மீட்டெடுப்புப் படி தவறான தரவைத் தந்தது மற்றும் ஏன் என்பதை நீங்கள் துல்லியமாக மறுவிளக்கம் (replay) செய்ய முடிய வேண்டும்.

கட்டமைப்புகளை (Frameworks) விட நீண்ட காலம் நிலைத்திருக்கும் ஆர்க்கிடெக்சர் முறைகள்

LangChain, CrewAI மற்றும் அடுத்த ஆறு மாதங்களில் வரப்போகும் அடுத்த சூப்பர் ஃபிரேம்வொர்க் ஆகியவை வெறும் சாரக்கட்டுகள் (scaffolding) மட்டுமே. ஆர்க்கிடெக்சர் தான் உண்மையான கட்டிடம். உங்கள் வடிவமைப்பு பலவீனமாக இருந்தால், எந்த ஒரு ஃபிரேம்வொர்க்காலும் அதைத் காப்பாற்ற முடியாது. நிரூபிக்கப்பட்ட நிலையான முறைகளைப் பின்பற்றுங்கள்:

  • திட்டமிடுங்கள், பிறகு செயல்படுத்துங்கள். மாடல் ஒரே நேரத்தில் சிந்திப்பதையும் செயல்படுத்துவதையும் செய்ய அனுமதிக்காதீர்கள். முதலில், ஒரு திட்டத்தை உருவாக்குங்கள். பிறகு படிகளைச் செயல்படுத்துங்கள். ஏதேனும் தவறு நடக்கும்போது, செயல்பாட்டிலிருந்து திட்டத்தை நீங்கள் தனித்து ஆய்வு செய்யலாம். ஒன்றோடொன்று கலந்திருக்கும் கருவி அழைப்புகள் (tool calls) மற்றும் தொடர்ச்சியான சிந்தனை ஓட்டங்களை (stream-of-consciousness reasoning) சரிசெய்ய நீங்கள் மிகக் குறைந்த நேரத்தையே செலவிடுவீர்கள்.
  • தகவல் மீட்டெடுப்பை (retrieval) சிந்தனையிலிருந்து (reasoning) பிரிக்கவும். சூழலைத் (context) திரட்டுவது ஒரு I/O பணி. அந்தச் சூழலைப் பயன்படுத்துவது ஒரு சிந்தனைப் பணி. இரண்டையும் கலப்பது என்பது உங்கள் மீட்டெடுப்பாளர் (retriever) மாடலின் டோக்கன் வரம்புகளால் கட்டுப்படுத்தப்படுவதையும், உங்கள் மாடல் தேவையற்றத் தகவல்களால் (retrieval noise) மாசுபடுவதையும் குறிக்கும். தகவல் மீட்டெடுப்பு அடுக்கு (retrieval layer) தீவிரமாகத் தகவல்களைத் திரட்டட்டும். சிந்தனை அடுக்கு (reasoning layer) தான் பெற்றவற்றைச் சந்தேகத்துடன் மதிப்பீடு செய்யட்டும்.
  • தெளிவான ஒப்படைப்புகளைப் (handoffs) பயன்படுத்தவும். ஒரு பணியில் பல ஏஜெண்டுகள் (agents) ஈடுபட்டால், அந்தப் பணியை ஒப்படைக்கும் முறையை ஒழுங்குபடுத்துங்கள். தெளிவான வெளியீட்டு ஸ்கீமாக்கள் (output schemas), உரிமையாளர் எல்லைகள் மற்றும் ஒப்படைப்புப் பதிவுகளை (handoff logs) வரையறுக்கவும். ஏஜெண்டுகளுக்கு இடையிலான தெளிவற்ற மற்றும் முறைசாரா உரையாடல்கள், விடுபட்ட பணிகள், சுழற்சி முறைகள் அல்லது இரட்டிப்பு வேலைகளுக்கு வழிவகுக்கும். ஏஜென்ட்-டு-ஏஜென்ட் தொடர்புகளை ஒரு குழு உரையாடல் போலக் கருதாமல், நன்கு வரையறுக்கப்பட்ட API ஒப்பந்தத்தைப் போலக் கருதுங்கள்.

உங்கள் RAG ஏன் பயனற்றத் தகவல்களைத் தருகிறது என்பதற்கான உண்மையான காரணம்

உங்கள் retrieval-augmented generation (RAG) குழாய்முறை (pipeline) தொடர்ந்து பயனற்ற முடிவுகளைத் தந்தால், embedding மாடலைச் சரிசெய்வதை நிறுத்திவிட்டு, உங்கள் chunking உத்தியைக் கவனியுங்கள். RAG அமைப்புகளில் இதுவே அதிகம் கவனிக்கப்படாத தோல்விப் புள்ளியாகும்.

ஆவணங்களை நிலையான அளவு கொண்ட துண்டுகளாக (fixed-size chunks) பிரிக்கும்போது, நீங்கள் பெரும்பாலும் கருத்துக்களைத் தனிமைப்படுத்தி விடுகிறீர்கள். “இருப்பினும், இந்த அணுகுமுறை ஒழுங்குமுறை மாற்றங்களைக் கணக்கில் கொள்ளத் தவறிவிட்டது” என்று தொடங்கும் ஒரு பத்தி, அந்த அணுகுமுறையைக் குறிப்பிட்ட முந்தைய பத்தி இல்லாமல் எந்தப் பொருளையும் தராது. அந்தத் தனிமைப்படுத்தப்பட்ட துண்டுகளை ஒரு மாடலுக்கு வழங்கினால், அந்த மாடல் தனக்குத் தேவையான சூழலைத் தானே கற்பனை செய்து கொள்ளும். அது தகவல் மீட்டெடுப்பு அல்ல; அது ஒரு மாயத்தோற்றத் தொழிற்சாலை (hallucination factory).

இந்தத் தீர்வுகளை முயற்சிக்கவும்:

  • மேலடுக்கு ஜன்னல்கள் (Overlapping windows). கருத்துக்கள் பாதியிலேயே நின்றுவிடாமல் இருக்க, அடுத்தடுத்த துண்டுகள் அவற்றின் எல்லைகளில் ஒரு அல்லது இரண்டு வாக்கியங்களைப் பகிர்ந்து கொள்ளட்டும்.
  • பொருள் சார்ந்த துண்டுகளாகப் பிரித்தல் (Semantic chunking). எழுத்துக்களின் எண்ணிக்கைக்குப் பதிலாக, இயல்பான எல்லைகளில்—பத்தி முடிவுகள், பிரிவுத் தலைப்புகள் அல்லது தலைப்பு மாற்றங்கள்—பிரிப்பதே சிறந்தது.
  • தாய்-ஆவண மீட்டெடுப்பு (Parent-document retrieval). பொருள் பொருத்தம் (semantic matching) காண சிறிய, துல்லியமான துண்டுகளை மீட்டெடுங்கள், ஆனால் மொழி மாடலுக்கு முழுமையான தாய்ப் பிரிவு அல்லது ஆவணத்தை வழங்கவும், இதனால் அது தகவல்களை உருவாக்கும்போது சுற்றியுள்ள சூழலைப் பெற்றிருக்கும்.
  • மூல உரையைத் (raw text) தவிர்த்து, கட்டமைக்கப்பட்ட தரவைச் சேமிக்கவும். அட்டவணைத் தரவு, key-value இணைகள் மற்றும் உறவுகள் பெரும்பாலும் உரை வடிவில் சரியாகப் பொருத்தப்படாது (embed). உங்கள் மூலப் பொருள் கட்டமைக்கப்பட்டதாக இருந்தால், அதை ஒரு graph database அல்லது relational store-இல் கட்டமைக்கப்பட்ட நிலையிலேயே வைத்திருங்கள்; மேலும் ஏஜென்ட், உட்பொதிக்கப்பட்ட உரைத் துண்டுகளிலிருந்து ஊகிப்பதற்குப் பதிலாக, அதைத் தெளிவாகக் கேள்வி கேட்க (query) அனுமதியுங்கள்.

நீங்கள் நம்பக்கூடிய அமைப்புகளை உருவாக்குங்கள்

பெஞ்ச்மார்க்குகளைத் (benchmarks) துரத்துவதை நிறுத்துங்கள். லீடர்போர்டு மதிப்பெண் என்பது ஆய்வகச் சூழல் மட்டுமே. உற்பத்திச் சூழல் (Production) குழப்பமானது, சவாலானது மற்றும் async ஆனது. நீங்கள் தூங்கும்போது, upstream API சரியாகச் செயல்படாதபோது மற்றும் பயனர் பயிற்சித் தரவில் இல்லாத ஒன்றைக் கேட்கும்போது உங்கள் அமைப்பு சரியாகச் செயல்படுகிறதா என்பதே முக்கியமானது.

அமைப்புகளின் வடிவமைப்பில் (systems design) கவனம் செலுத்துங்கள். தகவல் மீட்டெடுப்பு மற்றும் சிந்தனைக்கு இடையே தெளிவான எல்லைகளை உருவாக்குங்கள். தோல்வியடையும் போது அதைத் தெளிவாகக் காட்டும் மற்றும் சுத்தமாக மீண்டு வரும் கருவிகளை வடிவமைக்கவும். முடிவுகளைப் பதிவு (log) செய்யுங்கள், அப்போதுதான் அவற்றை நீங்கள் தணிக்கை (audit) செய்ய முடியும். சூழல் சிதையாமல் இருக்க உங்கள் ஆவணங்களைத் துண்டுகளாகப் பிரியுங்கள். இதைச் செய்தால், நீங்கள் வெறும் செயல்விளக்கத்திற்கு (demo) மட்டும் சிறப்பாக இல்லாமல், நிஜமான பயன்பாட்டில் நம்பகமான குழாய்முறைகளை உருவாக்குவீர்கள்.

மூலம்: The Overlooked Reason Your RAG Pipeline Keeps Returning Garbage

கற்றல் சமூகத்தில் இணையுங்கள்: GyaanSetu AI on Telegram