பெரும்பாலான RAG பயிற்சிகள் டெமோவிலேயே முடிந்துவிடுகின்றன. நீங்கள் டோக்கன் எண்ணிக்கையின் அடிப்படையில் துண்டுகளாகப் பிரித்து (chunk), அனைத்தையும் ஒரு வெக்டர் தரவுத்தளத்தில் (vector database) திணித்துவிட்டு வேலையை முடித்துவிடுகிறீர்கள். ஒரு பயனர் "திரும்பப் பெறும் கொள்கை என்ன?" (What is the return policy?) என்று தெளிவான FAQ-இல் கேட்கும்போது இது வேலை செய்யும். ஆனால், யாராவது ஒரு ஒப்பந்தத்தின் பாதியை நகலெடுத்து மூன்றாவது விதியைப் பற்றி கேட்டாலோ, அல்லது ஒரு டெவலப்பர் உங்கள் ஆவணத் தேடலில் (documentation search) ஒரு தெளிவற்ற பிழை குறியீட்டை (error code) தட்டச்சு செய்தாலோ இது தோல்வியடைகிறது.

நிலையான டோக்கன் விண்டோக்கள் (Fixed token windows) சட்ட ஒப்பந்தங்களை வாக்கியத்தின் நடுவிலேயே துண்டித்துவிடுகின்றன. பெரிய துண்டுகள் (Large chunks) API குறிப்புகளைத் தேவையற்ற தகவல்களுக்குக் கீழே புதைத்துவிடுகின்றன. எல்லாவற்றையும் விட மோசமானது, மெதுவான மீட்டெடுப்பு (slow retrieval), மாடல் பதிலைத் தரத் தொடங்குவதற்கு முன்பே பயனர்களைத் தேடலை விட்டு விலகச் செய்கிறது. இதை நாங்கள் கடினமான முறையில் கற்றுக்கொண்டோம். எங்களது மீட்டெடுப்பு அடுக்கை (retrieval layer) வெறும் நம்பிக்கையிலிருந்து அளவீடாக மாற்றியபோது, தாமதத்தை (latency) நாற்பது சதவீதம் குறைத்தோம் மற்றும் recall அளவை தொண்ணூற்று ஐந்து சதவீதமாக உயர்த்தினோம். எதில் மாற்றம் ஏற்பட்டது என்பது இதோ.

Smart Chunking

Chunk அளவை ஒரு மாயாஜால எண்ணாகக் கருதுவதை நிறுத்துங்கள். ஒரு தனி விதி பல பத்திகளாக நீளும் ஒரு சட்ட ஆவணத்திற்கு 512-டோக்கன் விண்டோ எந்தப் பயனும் தராது; அதேபோல், ஒரு function signature மற்றும் அதன் இரண்டு வரி விளக்கத்தை ஒன்றாக வைத்திருக்க வேண்டிய API ஆவணங்களுக்கும் இது பயனற்றது. நாங்கள் கட்டமைப்பை உணர்ந்த பிரிப்பிற்கு (structure-aware splitting) மாறினோம்.

சட்ட உரைகளுக்கு, recursive chunking ஆவணத்தின் படிநிலையை (hierarchy) மதிக்கிறது. விதிகளும் (clauses) அப்படியே இருக்கும். API ஆவணங்களுக்கு, signatures, parameters மற்றும் உதாரணங்களை அணுக்கரு அலகுகளாக (atomic units) ஒன்றாக வைத்திருக்கும் function-aware splitting முறையைப் பயன்படுத்துகிறோம். சப்போர்ட் டிக்கெட்டுகள் மற்றும் உரையாடல் தரவுகளுக்குப் பொருண்மை சார்ந்த எல்லைகள் (semantic boundaries) தேவை; அதாவது ஒரு தன்னிச்சையான எழுத்து எண்ணிக்கையில் பிரிக்காமல், தலைப்பு மாறும் இடத்தில் பிரிக்க வேண்டும். இதன் விளைவாக, ஒவ்வொரு chunk-உம் பயனுள்ளதாக இருக்கும் அளவுக்குப் போதுமான சூழலைக் (context) கொண்டுள்ளது, ஆனால் தகவலின் தெளிவைக் குறைக்காத அளவு மட்டுமே உள்ளது. உங்கள் embedding மாடலுக்குக் கவனிக்கக் கூடிய திறன் (attention budget) வரையறுக்கப்பட்டது. அதைத் புத்திசாலித்தனமாகப் பயன்படுத்துங்கள்.

Hybrid Retrieval

கருத்தியல் ரீதியாக ஒத்த உள்ளடக்கத்தைக் கண்டறிவதில் Vector search சிறந்து விளங்குகிறது. மெதுவான தரவுத்தள வினவல்களைப் (database queries) பற்றி கேட்டால், அது செயல்திறன் மேம்பாட்டு வழிகாட்டிகளை (performance tuning guides) வெளிக்கொண்டு வரும். ஆனால் "Error 0x80070057" என்று கேட்டால், semantic search தொடர்பற்ற இடத்திற்குச் சென்றுவிடும், ஏனெனில் dense embeddings துல்லியமான பொருத்தங்களை (exact matches) சிறப்பாகக் கையாளுவதில்லை. மறுபுறம், BM25 துல்லியமான சரங்களையும் (strings) அரிதான சொற்களையும் சரியாகக் கண்டறியும், ஆனால் "latency" மற்றும் "slow response time" ஆகிய இரண்டும் ஒரே பொருளைத் தருகின்றன என்பது அதற்குத் தெரியாது.

நாங்கள் இரண்டையும் இணையாக இயக்கி, Reciprocal Rank Fusion மூலம் அவற்றை இணைக்கிறோம். RRF எளிமையானது மற்றும் பயனுள்ளது. இது ஒவ்வொரு முறையிலிருந்தும் பெறப்பட்ட வரிசைப்படுத்தப்பட்ட பட்டியல்களை எடுத்து, அவற்றின் நிலையைப் பொறுத்து ஆவணங்களுக்கு மதிப்பெண் அளிக்கிறது, இதனால் இரு அமைப்புகளிலிருந்தும் சிறந்த முடிவுகளுக்குச் சமமான வாய்ப்பு கிடைக்கிறது. இணைப்பிற்குப் பிறகு, ஒருங்கிணைக்கப்பட்ட முடிவுகளில் ஒரு cross-encoder reranker-ஐ இயக்கி, முதல் ஐந்து முடிவுகளை மட்டும் வழங்குகிறோம். reranker சுமார் ஐம்பது மில்லி விநாடிகள் தாமதத்தைச் சேர்த்தாலும், எங்களது recall அளவை பதினைந்து சதவீதம் மேம்படுத்தியது. இந்தச் சமநிலை (trade-off), உருவாக்கத் தரத்தில் (generation quality) பல மடங்கு பலனைத் தருகிறது.

Query Expansion

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

இப்போது ஒவ்வொரு வினவலையும் இன்டெக்ஸ் (index) செய்வதற்கு முன்பே நாங்கள் மாற்றியமைக்கிறோம். முதலாவதாக, ஒத்த சொற்கள் (synonyms) மற்றும் மாற்றுத் தொடர்களை உள்ளடக்கும் வகையில் அசல் கேள்வியின் பல மறுபதிப்புகளை (rephrased versions) உருவாக்குகிறோம். இரண்டாவதாக, சிக்கலான கேள்விகளைச் சிறிய துணை-கேள்விகளாகப் பிரிக்கிறோம். "சர்வதேச வாடிக்கையாளர்களுக்கு ஏன் ரீஃபண்ட் (refund) தோல்வியடைகிறது மற்றும் அதை நான் எப்படி சரி செய்வது?" போன்ற ஒரு வினவல் இரண்டு தனித்த தேடல்களாக மாறுகிறது: ஒன்று சர்வதேச ரீஃபண்ட் தோல்விகள் பற்றியது, மற்றொன்று அதைச் சரிசெய்யும் வழிமுறைகள் பற்றியது. Query expansion மட்டுமே எங்களது recall அளவை எழுபத்து எட்டு சதவீதத்திலிருந்து தொண்ணூற்று நான்கு சதவீதமாக உயர்த்தியது. பாடம் எளிமையானது: பயனரின் முதல் வரைவை (first draft) அப்படியே நம்பாதீர்கள். அவர்களுக்கு உதவுங்கள்.

Stop Guessing, Start Searching

Chunk அளவு, overlap சதவீதம், top-k cutoff மற்றும் reranker ஆழம் ஆகியவை கைகளால் சரிசெய்ய முடியாத வகையில் ஒன்றோடொன்று தொடர்பு கொள்கின்றன. உண்மையில் ஒத்திசைவை (coherence) அழித்துக் கொண்டிருந்த overlap அமைப்பைப் புறக்கணித்துவிட்டு, 256 டோக்கன்கள் 512-ஐ விடச் சிறந்ததா என்று விவாதிப்பதிலேயே நாங்கள் அதிக நேரத்தைச் செலவிட்டோம்.

நாங்கள் உள்ளுணர்வுக்குப் (intuition) பதிலாக Bayesian optimization முறையைப் பயன்படுத்தினோம்.明らかに மோசமான பகுதிகளில் கணக்கீட்டுத் திறனை (compute) வீணடிக்கும் grid search-க்கு பதிலாக, Bayesian முறைகள் எது வேலை செய்கிறது என்பதற்கான ஒரு நிகழ்தகவு மாதிரியை (probabilistic model) உருவாக்கி, தாமதத்தைக் குறைக்கும் அதே வேளையில் recall-ஐ அதிகப்படுத்தும் Pareto frontier-ஐத் தீவிரமாகத் தேடுகின்றன. எங்களது தொழில்நுட்பக் கட்டமைப்பிற்கு (stack), தாமத வரம்பைத் தாண்டாமல் தொண்ணூற்று ஐந்து சதவீத recall-ஐத் தரும் chunk அளவு, overlap மற்றும் top-k ஆகியவற்றின் குறிப்பிட்ட கலவையைக் கண்டறிவதைக் குறித்தது. வெவ்வேறு பயன்பாட்டுத் தேவைகள் (use cases) அந்த எல்லையின் வெவ்வேறு புள்ளிகளில் அமைந்தன. வாடிக்கையாளர் சார்ந்த சாட்போட்கள் (chatbots) வேகத்திற்கு முன்னுரிமை அளித்தன. உள்நாட்டு சட்ட ஆராய்ச்சி recall-க்கு முன்னுரிமை அளித்தது. தானியங்கி உகப்பாக்கம் (Automated optimization), config கோப்புகளைக் கைமுறையாக நகலெடுத்து ஒட்டாமல் இரண்டையும் கையாள எங்களுக்கு அனுமதித்தது.

The Results

புள்ளிவிவரங்கள் தெளிவாகக் காட்டுகின்றன. எங்களது Recall@10 எழுபத்து எட்டு சதவீதத்திலிருந்து தொண்ணூற்று ஐந்து சதவீதமாக உயர்ந்தது. p95 latency 850 மில்லி விநாடிகளிலிருந்து 320 மில்லி விநாடிகளாகக் குறைந்தது. மேலும், மாதிரி (model) தேவையற்ற இரைச்சலுக்குப் (noise) பதிலாக இறுதியாகத் தொடர்புடைய சூழலைப் (relevant context) பெற்றதால், hallucination rate பன்னிரண்டு சதவீதத்திலிருந்து மூன்று சதவீதமாகக் குறைந்தது. சிறந்த மீட்டெடுப்பு (retrieval) பதில்களை வேகப்படுத்துவது மட்டுமல்ல; அவற்றை உண்மையானதாகவும் மாற்றுகிறது.

அடுத்து என்ன செய்ய வேண்டும்

உங்கள் மீட்டெடுப்பு அடுக்கை (retrieval layer) நீங்கள் மீண்டும் கட்டமைப்பதாக இருந்தால், இங்கிருந்து தொடங்குங்கள்:

  • டோக்கன் எண்ணிக்கையை வைத்து அல்லாமல், ஆவணத்தின் கட்டமைப்பைக் கொண்டு துண்டுகளாகப் பிரிக்கவும் (Chunk). உங்கள் தரவின் வடிவத்திற்கு ஏற்ப உங்கள் பிரிக்கும் உத்தியை (splitting strategy) அமைக்கவும்.
  • கலப்பு மீட்டெடுப்பைப் (hybrid retrieval) பயன்படுத்தவும். Vector search மற்றும் BM25 ஆகியவற்றை இணைக்கவும், Reciprocal Rank Fusion மூலம் ஒன்றிணைக்கவும், மேலும் பதில்களை உருவாக்குவதற்கு முன் மறுவரிசைப்படுத்தவும் (rerank).
  • சிறந்த பரப்பளவிற்கு வினவல்களை (queries) விரிவுபடுத்தவும். தேடல் தொடங்குவதற்கு முன்பே அவற்றை மறுசீரமைக்கவும் மற்றும் பிரிக்கவும்.
  • சோதனை செய்வதற்காக ஒரு 'golden dataset' உருவாக்கவும். நீங்கள் அளவிடாத ஒன்றைத் துல்லியப்படுத்த (optimize) முடியாது.
  • தானியங்கி கருவிகளைக் கொண்டு அளவுருக்களை (parameters) மேம்படுத்தவும். உங்கள் உள்ளுணர்வை விட Bayesian search சிறந்த அமைப்புகளைக் கண்டறியும்.

மீட்டெடுப்பு (Retrieval) என்பது நீங்கள் ஒருமுறை அமைத்துவிட்டு மறந்துவிடும் ஒரு உள்ளமைவு கோப்பு (configuration file) அல்ல. இது ஒரு உள்கட்டமைப்பு (infrastructure), மேலும் உள்கட்டமைப்பானது தயாரிப்பு குறியீட்டைப் (production code) போலவே சோதனைகள், அளவீடுகள் மற்றும் தொடர்ச்சியான மேம்படுத்தல் போன்ற கடுமையான நடைமுறைகளைக் கோருகிறது. அவ்வாறு கையாண்டால், உங்கள் RAG அமைப்பு ஒரு செயல்விளக்கத்திலிருந்து (demo) ஒரு தயாரிப்பாக (product) மாறும்.

விருப்பத்தேர்வு கற்றல் சமூகம்: GyaanSetu AI