பெரும்பாலான RAG பயிற்சிகள் (tutorials) உற்பத்தி நிலை (production) தொடங்கும் இடத்திலேயே முடிந்துவிடுகின்றன. உங்கள் ஆவணங்களை 512-token துண்டுகளாகப் (chunks) பிரித்து, அவற்றை ஒரு एकल embedding model மூலம் அனுப்பி, எளிமையான top-k retrieval முறையைப் பயன்படுத்தி ஒரு vector database-ஐ அழைப்பீர்கள். ஒரு டெமோவில் (demo), இது நம்பகமானதாகத் தோன்றும். உங்கள் நிறுவனத்தின் விடுப்பு கொள்கையைப் பற்றி பாட் (bot) இடம் கேட்டுப் பார்த்தால், அது ஒரு தெளிவான பத்தியைத் தரும். அனைவரும் தலையசைப்பார்கள். துரதிர்ஷ்டவசமாக, டெமோக்கள் உண்மையைச் சொல்வதில்லை.

உற்பத்தி நிலை (Production) ஒவ்வொரு குறுக்குவழியையும் வெளிச்சம் போட்டுக் காட்டுகிறது. நிலையான துண்டுகள் (Fixed chunks), சட்ட ஒப்பந்தங்களில் உள்ள இழப்பீடு தொடர்பான பிரிவுகளின் (indemnification clauses) நடுவே துண்டிக்கின்றன. API ஆவணங்கள், உங்களுக்குத் தேவையான தகவலைத் தற்காத்துக் கொள்ள முடியாதபடி ஒன்றன் மேல் ஒன்று படிந்த இரைச்சலாக மாறுகின்றன. பதில்கள் வருவதற்கு முன்பே பயனர்கள் தேடலைத் கைவிடும் அளவுக்குத் தாமதம் (latency) அதிகரிக்கிறது. நாங்கள் இந்தத் தடையைச் சந்தித்தோம், அதனால் அனைத்தையும் மீண்டும் கட்டமைக்க வேண்டியிருந்தது. எங்களது retrieval layer, "semantic search மற்றும் நம்பிக்கையை" அடிப்படையாகக் கொண்ட நிலையிலிருந்து, அளவிடக்கூடிய மற்றும் கருவிகளால் கண்காணிக்கக்கூடிய (instrumented) ஒரு குழாயாக (pipeline) உருவெடுத்தது. இதன் விளைவாக 95% recall மற்றும் 40% குறைவான தாமதம் (latency) கிடைத்தது. உண்மையில் எது வேலை செய்தது என்பது இதோ:

ஆவணத்திற்கு ஏற்றவாறு Chunking உத்தியைத் தேர்ந்தெடுக்கவும்

512-token என்பது எளிதாக இருப்பதால் அது தொடர்ந்து பயன்படுத்தப்படுகிறது, அது சரியானது என்பதால் அல்ல. வெவ்வேறு ஆவணங்கள் வெவ்வேறு விதமாகப் பொருளைக் கொண்டுள்ளன, எனவே உங்கள் chunking உத்தி அதைப் பிரதிபலிக்க வேண்டும்.

சட்ட ஒப்பந்தங்களுக்கு (legal contracts), கட்டமைப்பு எல்லைகளைப் (structural boundaries) மதிக்கும் recursive chunking முறையைப் பயன்படுத்தவும். சட்ட மொழி என்பது ஒன்றோடொன்று பிணைக்கப்பட்டது. ஒரு பிரிவு அதற்கு மேலே உள்ள பகுதியைச் சார்ந்து இருக்கும், மேலும் ஒரு வாக்கியத்தின் நடுவில் நிலையான துண்டிப்பு என்பது அந்தப் பொறுப்பின் தர்க்கத்தை அழித்துவிடும். Recursive chunking என்பது ஒரு டோக்கன் வரம்பை (token limit) விதிப்பதற்கு முன், பத்திகள் (paragraphs), பின்னர் வாக்கியங்கள் (sentences) என இயற்கையான பிரிப்பான்களைக் கொண்டு பிரிக்க முயற்சிக்கும். இது இழப்பீடு அல்லது பொறுப்பு தொடர்பான பிரிவுகளை முழுமையாக வைத்திருக்க உதவுகிறது.

API ஆவணங்களுக்கு (API documentation), function-aware chunking முறையைப் பயன்படுத்தவும். டெவலப்பர்கள் ஏதோ ஒரு பத்தியைத் தேடவில்லை; அவர்கள் endpoints, parameters மற்றும் error signatures ஆகியவற்றைத் தேடுகிறார்கள். ஒரு chunk என்பது முழு function signature, அதன் விளக்கம் மற்றும் return schema ஆகியவற்றை ஒரு தர்க்கரீதியான அலகாகக் கொண்டிருக்க வேண்டும். அந்தத் தொகுப்பை நீங்கள் பாதியாகப் பிரித்தால், retrieval system பாதி சூழலை மட்டுமே வழங்கும், மேலும் generation model மீதியைத் தவறாகக் கற்பனை செய்து கூறும் (hallucinates).

ஆதரவுத் டிக்கெட்டுகளுக்கு (support tickets), உரையாடல் மாற்றங்களைப் (conversation turns) பின்பற்றும் semantic chunking முறையைச் சார்ந்திருக்கவும். ஆதரவுத் திரட்டுகள் (support threads) நேர்க்கோட்டுத் தன்மையுடனும் மீண்டும் மீண்டும் நிகழும் தன்மையுடனும் இருக்கும். ஒரு வாடிக்கையாளர் சிக்கலைத் திரும்பச் சொல்கிறார், ஒரு முகவர் (agent) logs-களைக் கேட்கிறார், வாடிக்கையாளர் அவற்றை இணைக்கிறார். ஒவ்வொரு மாற்றமும் ஒரு தனி semantic அலகாகும். மாற்றங்களின் அடிப்படையில் chunking செய்வது, யார் எப்போது என்ன சொன்னார்கள் என்பதைப் பாதுகாக்கிறது. இது "செவ்வாய்க்கிழமை முகவர் என்ன பரிந்துரைத்தார்?" என்று பயனர் கேட்கும்போது மிகவும் முக்கியமானது.

உள் விக்கி (internal wikis) பக்கங்களுக்கு, agentic chunking முறையை முயற்சித்துப் பார்க்கவும். ஒரு LLM-இடம் ஒரு பகுதியை வழங்கி, ஒரு தலைப்பு எங்கு முடிகிறது மற்றும் அடுத்த தலைப்பு எங்கு தொடங்குகிறது என்பதைத் தீர்மானிக்கச் சொல்லுங்கள். இது தரவை உள்ளிடும் நேரத்தில் (ingest time) அதிகச் செலவைச் செய்யும், ஆனால் விக்கிகள் குழப்பமானவை. பக்கங்கள் வெவ்வேறு குழுக்களிலிருந்து வந்த தொடர்பற்ற புதுப்பிப்புகளைக் கொண்டிருக்கும், மேலும் மனிதனால் வரையறுக்கப்பட்ட எல்லைகள் அரிதாகவே உதவும். தலைப்பு மாற்றங்களின் அடிப்படையில் ஒரு மாடல் எல்லைகளை வரைவது இரைச்சலைத் (noise) பெருமளவு குறைக்கிறது.

ஒரே pipeline-இல் பல உத்திகளை இயக்குவதற்கு, தரவை உள்ளிடும்போதே ஆவணங்களை அவற்றின் வகையைப் பொறுத்துத் தரம் பிரிப்பது (tagging) அவசியம். அந்தச் சிறிய ஒழுங்குமுறை உடனடியாகப் பலன் தரும்.

தேடல் முறைகளை ஒன்றிணைக்கவும், ஒன்றை மட்டும் தேர்ந்தெடுக்க வேண்டாம்

Vector search நோக்கத்தைப் புரிந்துகொள்கிறது, ஆனால் துல்லியமான பொருத்தங்களில் (exact matches) அது அடிக்கடி தோல்வியடைகிறது. ERR_CONNECTION_REFUSED என்ற error code அல்லது ஒரு குறிப்பிட்ட SKU-வைக் கேட்டால், dense embeddings பெரும்பாலும் கருத்தியல் ரீதியாகத் தொடர்புடைய ஆனால் உண்மையாகத் தவறான முடிவுகளைத் தரும். BM25 என்பது பாரம்பரியமான keyword sparse retrieval முறையாகும், இது துல்லியமான சொற்களைச் சிறப்பாகக் கையாளும் ஆனால் semantic நுணுக்கங்களை 놓விடும். உங்களுக்கு இவை இரண்டும் தேவை.

Hybrid retrieval முறையைப் பயன்படுத்தவும். Vector search மற்றும் BM25 ஆகியவற்றை இணையாக இயக்கவும். பின்னர் அவற்றை Reciprocal Rank Fusion (RRF) மூலம் ஒன்றிணைக்கவும். RRF என்பது இரண்டு முறைகளும் பொருத்தமானவை என்று ஒப்புக்கொள்ளும் ஆவணங்களுக்கு முன்னுரிமை அளிக்கிறது, அதே சமயம் ஏதேனும் ஒரு அணுகுமுறையிலிருந்து வலுவான சாத்தியக்கூறுகளையும் வெளிச்சம் போட்டுக் காட்டுகிறது. இதன் கணிதம் எளிமையானது மற்றும் முடிவு நிலையானது: எந்த ஒரு தனித் தேடல் முறையும் இறுதித் தரவரிசையைத் தீர்மானித்துவிடாது.

ஒன்றிணைத்த பிறகு (fusion), ஒரு cross-encoder reranker-ஐச் சேர்க்கவும். முதல் நிலை — vector மற்றும் sparse retrieval — வேகமானது மற்றும் பரந்தது. பின்னர் cross-encoder ஒவ்வொரு query-document ஜோடியையும் முழு கவனத்துடன் (full attention) மதிப்பிடுகிறது, அதாவது அது அசல் கேள்வியுடன் அந்தத் தேடலைச் சரியாகப் படிக்கிறது. ஆம், இது தாமதத்தை (latency) அதிகரிக்கும். எங்கள் விஷயத்தில், தோராயமாக ஐம்பது முதல் நூறு மில்லி விநாடிகள் வரை. ஆனால் துல்லியத்தில் (precision) கிடைக்கும் முன்னேற்றம் அந்தத் தாமதத்தை விடப் பெரியது. உங்கள் recall முக்கியம் என்றால், இதைத் தவிர்க்க முடியாது.

Index-ஐ சரிசெய்வதற்கு முன், Query-ஐச் சரிசெய்யவும்

பயனர்கள் உங்கள் தேடுபொறிக்காக (search engine) கேள்விகளை (queries) எழுதுவதில்லை. அவர்கள் மனிதர்களுக்காக எழுதுகிறார்கள். "இது வேலை செய்யவில்லை" என்பது ஒரு பொதுவான ஆதரவுத் தேடல் (support query). ஒரு தெளிவற்ற அம்சம் பற்றிய விளக்கம் என்பது ஒரு பொதுவான உள் விக்கித் தேடல். அந்த மூல உள்ளீட்டை (raw input) வைத்து நீங்கள் index-இல் தேடினால், உங்களுக்குத் தவறான முடிவுகளே கிடைக்கும்.

Retriever-ஐச் சென்றடைவதற்கு முன்பே, query-ஐ உருமாற்றவும் (transform).

பயனர் கேட்கும் கேள்வியின் பல பதிப்புகளை உருவாக்க query expansion முறையைப் பயன்படுத்தவும். யாராவது “server down” என்று தட்டச்சு செய்தால், உங்கள் அமைப்பு “service unavailable,” “502 error,” மற்றும் “connection timeout” ஆகியவற்றையும் தேட வேண்டும். இந்தத் தேடல் மாறுபாடுகளை (intent variants) உள்ளடக்கியதன் மூலம் எங்களது recall 78%-லிருந்து 96%-ஆக உயர்ந்தது. இது ஒரு ஒற்றைப்படைச் செயல்முறை மட்டுமே, மேலும் இது கிடைக்கும் பலத்துடன் ஒப்பிடும்போது செலவு மிக மிகக் குறைவு.

சிக்கலான கேள்விகளுக்கு query decomposition முறையைப் பயன்படுத்தவும். ஒரு பயனர் “How do I migrate from the legacy billing API to the new one and what breaking changes affect enterprise accounts?” என்பது போன்ற ஒன்றை கேட்கும்போது, அதைத் துணை-கேள்விகளாகப் பிரிக்கவும். ஒரு துணை-கேள்வி migration வழிமுறைகளைக் குறிக்கும். மற்றொருது enterprise-குறிப்பிட்ட breaking changes-களைக் குறிக்கும். ஒவ்வொன்றும் index-இன் வெவ்வேறு பகுதிகளைத் தொடும். இதன் மூலம், downstream language model ஒரு இரைச்சல் மிகுந்த context window-வில் யூகிக்காமல், சரியாக மீட்டெடுக்கப்பட்ட (well-retrieved) துண்டுகளிலிருந்து (chunks) இறுதிப் பதிலைத் தொகுத்து வழங்கும்.

Hyperparameters-களைக் கணிப்பதைத் தவிர்க்கவும்

உங்களிடம் பல chunking strategies, hybrid retrieval மற்றும் query transformation ஆகியவை இருக்கும்போது, நீங்கள் ஒரு combinatorial சிக்கலை எதிர்கொள்வீர்கள். Chunk size, overlap, fusion weights, reranker depth மற்றும் expansion count ஆகிய அனைத்தும் ஒன்றோடொன்று தொடர்புடையவை. ஒன்றை மட்டும் தனியாக மாற்றியமைப்பது மற்றொன்றைப் பாதிக்கும். இந்த இடமெல்லாம் grid search செய்வது வீணான மற்றும் மெதுவான செயலாகும்.

அதற்குப் பதிலாக Bayesian optimization முறையைப் பயன்படுத்தவும். இதை ஒரு machine learning tuning வேலையைப் போலக் கருதவும். உங்கள் இலக்கை (objective) தெளிவாக வரையறுக்கவும்: latency-ஐ ஒரு குறிப்பிட்ட வரம்பிற்குள் வைத்துகொண்டு recall-ஐ அதிகப்படுத்துங்கள். ஒரு golden dataset-ஐ உருவாக்கவும் — எந்தத் துண்டுகள் (chunks) மீட்டெடுக்கப்பட வேண்டும் என்பதை நீங்கள் துல்லியமாகத் தெரிந்த சில நூறு பிரதிநிதித்துவக் கேள்விகள் கொண்ட தொகுப்பு இது. பின்னர், Bayesian search அந்த configuration space-ஐத் திறம்பட ஆராய அனுமதிக்கவும். இது எது வேலை செய்கிறது என்பதற்கான ஒரு probabilistic model-ஐ உருவாக்கி, அடுத்ததாக மிகவும் நம்பிக்கைக்குரிய பகுதிகளைச் சோதிக்கும்.

ஒவ்வொரு candidate configuration-ம் staging-க்குச் செல்வதற்கு முன் golden dataset-ஐக் கடந்து செல்ல வேண்டும். ஒரு புதிய chunk size recall-ஐக் குறைத்தாலோ அல்லது ஒரு கனமான reranker உங்கள் latency budget-ஐத் தாண்டினாலோ, optimization அதைத் தானாகவே கண்டறிந்துவிடும். இது விவாதங்களைத் தவிர்க்கிறது. 256 அல்லது 512 tokens எது "சிறந்தது" என்று விவாதிப்பதை நிறுத்திவிட்டு, முடிவுகளைப் படிக்கத் தொடங்குவீர்கள்.

முடிவு

இந்த pipeline மாற்றங்கள் நாங்கள் எதிர்பார்த்தது போலவே ஒன்றிணைந்து பலன் அளித்தன.

  • Recall@10 78%-லிருந்து 95%-ஆக உயர்ந்தது.
  • P95 latency 850 ms-லிருந்து 320 ms-ஆகக் குறைந்தது.
  • Hallucination rate 12%-லிருந்து 3%-ஆகக் குறைந்தது.
  • Cost per query 38% குறைந்தது, முக்கியமாகச் சிறந்த retrieval முறையினால் ஒரு சிறிய generation model மற்றும் குறைவான prompt tokens-களைப் பயன்படுத்த முடிந்தது.

latency குறைப்பு குழுவில் உள்ள சிலரை ஆச்சரியப்படுத்தியது. rerankers மற்றும் query expansion-ஐச் சேர்ப்பது விஷயங்களை மெதுவாக்கும் என்று தோன்றலாம். ஆனால் retrieval தரம் மேம்பட்டதால், generation model-க்குக் குறைவான prompting, குறைவான யூகங்கள் மற்றும் குறைவான முயற்சிகள் (retries) தேவைப்பட்டன. சிறந்த retrieval, அதன் தொடர்ச்சியான அனைத்துச் செயல்பாடுகளையும் (downstream) மலிவானதாக மாற்றுகிறது.

Retrieval-ஐ ஒரு Infrastructure போலக் கருதவும்

Retrieval என்பது நீங்கள் ஒருமுறை இயக்கிவிட்டு மறந்துவிடும் notebook அல்ல. இது ஒரு infrastructure, மேலும் இது code போல நிர்வகிக்கப்பட வேண்டும். உங்கள் chunking strategies-களை version செய்யுங்கள். சட்டக் குழு (legal team) ஒரு புதிய ஒப்பந்தத் டெம்ப்ளேட்டை வெளியிடும்போது, உங்கள் recursive splitter production-க்குச் செல்வதற்கு முன் அதைச் சோதிக்கவும். உங்கள் golden dataset-ஐ கடந்த காலாண்டின் நிலையான CSV கோப்பாக வைத்திருக்காமல், ஒரு வாழும் ஆவணமாக (living document) பராமரிக்கவும். உங்கள் மதிப்பீடுகளை (evaluations) CI-இல் தானியக்கமாக்குங்கள் (automate), இதனால் ஒரு embedding model அல்லது fusion weight-ஐ மாற்றும் pull request, ஒரு மனிதர் அதை ஆய்வு செய்வதற்கு முன்பே recall மற்றும் latency எண்களுடன் கூடிய கருத்தைப் பெறும்.

நீங்கள் எந்த embedding model-ஐப் பயன்படுத்துகிறீர்கள் என்று உங்கள் பயனர்கள் ஒருபோதும் கேட்க மாட்டார்கள். உங்கள் chunking heuristic அல்லது reranker architecture பற்றி அவர்கள் கவலைப்பட மாட்டார்கள். பதில் சரியாக இருக்கிறதா, அது வேகமாக வருகிறதா மற்றும் அதை அவர்களால் நம்ப முடியுமா என்பதில் மட்டுமே அவர்கள் கவனம் செலுத்துவார்கள். அந்த நம்பிக்கையைப் பெறும் ஒரு pipeline-ஐ உருவாக்குங்கள், அதை நேர்மையாக அளவிடுங்கள், மேலும் retrieval-ஐ ஒரு தேவையற்ற விஷயமாகக் கருதstop செய்யுங்கள்.

Source: Optimizing RAG At Scale
Join the discussion: GyaanSetu AI Community