உங்கள் RAG பைப்லைன் ஒரு சாதாரண லோட் டெஸ்ட்டை (load test) மிகச் சிறப்பாகக் கடந்துவிடுகிறது. p95 லேட்டன்சி (latency) ஆரோக்கியமாகத் தெரிகிறது. பிழை விகிதங்கள் (error rates) பூஜ்ஜியத்திற்கு அருகிலேயே உள்ளன. இருப்பினும், பயனர்கள் கேள்வியைத் தவிர்க்கும் பதில்கள், இல்லாத ஆவணங்களைக் குறிப்பிடும் பதில்கள் அல்லது ஆறு மாதங்களுக்கு முன்பு பதிவேற்றப்பட்ட ஒரு வெள்ளை அறிக்கையிலிருந்து (white paper) தொடர்பில்லாத பத்திகளைத் தேடித் தரும் பதில்கள் குறித்துப் புகார் கூறுகிறார்கள். டேஷ்போர்டு அனைத்தும் சரியாக இருப்பதாகக் கூறுகிறது. ஆனால் அனுபவம் அது உடைந்துவிட்டதாகக் கூறுகிறது.
இந்த முரண்பாடு ஏன் ஏற்படுகிறது என்றால், வழக்கமான செயல்திறன் சோதனை (performance testing) என்பது கோரிக்கை-பதில் (request-response) அமைப்புகளுக்காக உருவாக்கப்பட்டது, சிந்திக்கும் அமைப்புகளுக்காக அல்ல. நீங்கள் ஒரு REST எண்ட்-பாயிண்டிற்கு (endpoint) ஆயிரம் இணையான கோரிக்கைகளை (parallel requests) அனுப்பும்போது, உங்கள் சேவையகங்கள் (servers) நிலைத்து நிற்கின்றனவா என்பதைத் தெரிந்துகொள்ளலாம். ஆனால் உங்கள் மீட்டெடுப்பு அடுக்கு (retrieval layer) சரியான துண்டுகளை (chunks) எடுக்கிறதா, உங்கள் பிராம்ட் டெம்ப்ளேட் (prompt template) சூழலை (context) அப்படியே வைத்திருக்கிறதா அல்லது வெக்டர் ஸ்டோர் (vector store) காலியாக இருக்கும்போது மாதிரி (model) ஆதாரங்களைத் தானாகவே உருவாக்குகிறதா என்பதைப் பற்றி நீங்கள் எதையும் அறிய முடியாது. சாதாரண லோட் டெஸ்ட் வேகத்தை அளவிடுகிறது. RAG பயன்பாடுகள் நீங்கள் புரிதலை (understanding) அளவிட வேண்டும் என்று கோருகின்றன.
Status Code 200-க்கு அப்பால்
ஒரு பொதுவான API லோட் டெஸ்ட் மூன்று விஷயங்களைச் சரிபார்க்கிறது: கிடைப்புத்தன்மை (availability), லேட்டன்சி (latency), மற்றும் த்ரூபுட் (throughput). சர்வர் பதிலளித்ததா, அதற்கு எவ்வளவு நேரம் எடுத்தது மற்றும் எத்தனை ஒரே நேரத்தில் வரும் பயனர்களை (concurrent users) அது தாங்கியது போன்றவற்றை அது கேட்கிறது. ஒரு RAG பயன்பாட்டிற்கு, அந்த எண்கள் முன்னுரைகளே தவிர, முடிவுகள் அல்ல. ஒரு வேகமான தவறான பதில் என்பது இன்னும் ஒரு தவறான பதில்தான், மேலும் பெரிய அளவில் (at scale) ஏற்படும் தவறான பதில்கள் மெதுவான பதில்களை விட அதிக செலவை ஏற்படுத்தும்.
ஒவ்வொரு கோரிக்கைக்கும் RAG இரண்டு தனித்துவமான நிலைகளைச் சேர்க்கிறது. முதலாவதாக, சிஸ்டம் ஒரு பயனர் கேள்வியை எம்பெடிங்காக (embedding) மாற்றி, ஒரு வெக்டர் ஸ்டோரை (vector store) வினவிக், ஒரு தொகுப்பு சூழல் துண்டுகளை (context chunks) மீட்டெடுக்கிறது. இரண்டாவதாக, அந்தத் துண்டுகளை ஒரு பிராம்ட்டில் (prompt) திணித்து, அனைத்தையும் ஒரு மொழி மாதிரிக்கு (language model) அனுப்பி, ஒரு முழுமையான பதிலை (completion) ஸ்ட்ரீம் (stream) செய்கிறது. பாரம்பரிய சோதனைகள் பெரும்பாலும் இவற்றை ஒரு ஒற்றை "பதில் நேரம்" (response time) அளவீடாகக் கருதுகின்றன. அவை மீட்டெடுப்பு இயந்திரத்தையும் (retrieval engine) உருவாக்கிநிலையையும் (generator) ஒரே பிளாக் பாக்ஸாக (black box) கருதுகின்றன.
நீங்கள் அந்தப் பெட்டியைத் திறந்து பார்க்க வேண்டும். உங்கள் வெக்டர் தரவுத்தளம் (vector database) சுமையின் கீழ் மெதுவாகச் செயல்பட்டால், மீட்டெடுப்பு லேட்டன்சி (retrieval latency) அதிகரிக்கும். LLM இன்னும் விரைவாகப் பதிலளிக்கலாம், ஆனால் அது அவசரமாகப் பெறப்பட்ட குப்பைச் சூழலை (garbage context) அடிப்படையாகக் கொண்டு பதிலளிக்கிறது. மாற்றாக, LLM வரிசை (queue) நெரிசலடையும் போது வெக்டர் தேடல் (vector search) வேகமாக இருக்கலாம், இது பயனர்கள் மின்னும் கர்சரைப் (blinking cursor) பார்த்துக் கொண்டிருக்கும் வரை 'time-to-first-token' நேரத்தை அதிகரிக்கும். ஒரு ஒற்றை end-to-end டைமர் இந்த இரண்டு தோல்விகளையும் மறைத்துவிடுகிறது.
தரவுத்தளத்தை மட்டுமல்ல, மீட்டெடுப்பையும் (Retrieval) சோதிக்கவும்
பெரும்பாலான குழுக்கள் ஒரு விரைவான வெக்டர் தேடல் பெஞ்ச்மார்க்கை (vector search benchmark) நடத்தி, மீட்டெடுப்பு அடுக்கு சோதிக்கப்பட்டுவிட்டது என்று கூறிவிடுகிறார்கள். அந்த பெஞ்ச்மார்க் பொதுவாக ஒரு குறிப்பிட்ட வினவலுக்கு (query) தரவுத்தளம் எவ்வளவு விரைவாக அருகிலுள்ள அண்டை உறுப்புகளை (nearest neighbors) வழங்குகிறது என்பதை மட்டுமே அளவிடுகிறது. அந்த அண்டை உறுப்புகளில் உண்மையில் பதில் இருக்கிறதா என்பதை அது அரிதாகவே அளவிடுகிறது.
மீட்டெடுப்புத் தரம் (Retrieval quality) சுமையின் போது நுணுக்கமான வழிகளில் மாறுகிறது. ஒரே நேரத்தில் வரும் அழுத்தத்தின் கீழ் (concurrent pressure), approximate nearest neighbor indexes தனித்து இயங்குவதை விட வித்தியாசமாகச் செயல்படலாம். ஒரு நோட்புக்கில் (notebook) சரியாகத் தெரிந்த சங்கிங் உத்திகள் (chunking strategies), பத்தாயிரம் ஆவணங்கள் ஒரே எம்பெடிங் இடத்திற்காகப் போட்டியிடும்போது எல்லைகளைத் தாண்டி சூழலைத் தவறாகக் கொண்டு செல்லத் தொடங்கும். அமைதியான சூழலில் ஒரு சிறந்த பத்தியைத் தரும் வினவல், இன்டெக்ஸ் (index) மீண்டும் கட்டமைக்கப்படும் போதோ அல்லது கோரிக்கை அழுத்தத்தின் கீழ் மெட்டாடேட்டா (metadata) வடிகட்டுதல் நீக்கப்படும் போதோ தவறான ஒரு மார்க்கெட்டிங் ஸ்லைடைத் (marketing slide) தரக்கூடும்.
இதைச் சரியாகச் சோதிக்க, உங்களுக்கு ஒரு உண்மைத் தரவுத்தொகுப்பு (ground-truth dataset) தேவை. எந்த ஆதார ஆவணங்கள் வர வேண்டும் என்று உங்களுக்குத் தெரிந்த கேள்விகளைத் தயார் செய்யுங்கள். அந்த கேள்விகளை வெவ்வேறு இணைக்கணிப்பு நிலைகளில் (concurrency levels) இயக்கி, எதிர்பார்க்கப்படும் துண்டுகள் top-k முடிவுகளில் வருகின்றனவா என்று சரிபார்க்கவும். வெறும் வினவல் காலத்தை (query duration) மட்டும் பார்க்காமல், ஹிட் ரேட்டை (hit rate) கண்காணிக்கவும். உங்கள் முதல் ஐந்து துண்டுகள் முக்கியமான ஆதாரத்தைத் தவறவிட்டால், LLM விழிப்பதற்கு முன்பே உங்கள் மீட்டெடுப்பு பைப்லைன் தோல்வியடைந்துவிட்டது என்று அர்த்தம்.
நீங்கள் ஓரங்களில் உள்ள சவால்களையும் (edges) சோதனை செய்ய வேண்டும். உங்கள் தொகுப்பில் (corpus) பதில் இல்லாத வினவல்களைச் சமர்ப்பிக்கவும். பல டொமைன்களுக்குப் பொருந்தக்கூடிய தெளிவற்ற கேள்விகளைச் சமர்ப்பிக்கவும். உங்கள் எம்பெடிங் மாதிரியின் டோக்கன் வரம்பைத் (token limit) தாண்டி, அமைதியாகத் துண்டிக்கப்படும் (truncated) நீண்ட கேள்விகளைச் சமர்ப்பிக்கவும். மீட்டெடுப்பு அடுக்கு எதைத் திருப்பித் தருகிறது என்பதைக் கவனியுங்கள். ஒவ்வொரு சூழலிலும், கடந்த மில்லி விநாடிகளை விட தோல்வி முறை (failure mode) முக்கியமானது.
மாதிரி அமைதியாகத் தடுமாறும்போது (When the Model Chokes Quietly)
துண்டுகள் LLM-ஐச் சென்றடைந்ததும், வழக்கமான லோட் டெஸ்டிங் தொடர்ந்து பொய் சொல்கிறது