பெரும்பாலான பொறியியல் குழுக்கள் retrieval-augmented generation-இல் ஒரே மாதிரியான தடையைச் சந்திக்கின்றன. அவர்கள் பயிற்சிப் புத்தக முறையைப் பின்பற்றுகிறார்கள்: ஆவணங்களை 512 அல்லது 1024 டோக்கன்கள் கொண்ட நிலையான துண்டுகளாக (fixed chunks) பிரிக்கிறார்கள், அவற்றை ஒரு embedding model மூலம் செலுத்துகிறார்கள், மற்றும் ஒரு vector database-இல் எளிய top-k lookup மூலம் தேடுகிறார்கள். ஒரு ஸ்லைடு டெக்கில் இது சிறப்பாகத் தெரியும். ஆனால் தயாரிப்பு நிலையில் (production), இது தோல்வியடைகிறது.
நிலையான துண்டுகள் (Fixed chunks) உள்ளடக்கத்தைப் பொருட்படுத்துவதில்லை. அவை ஒரு சட்ட ஒப்பந்தத்தை வாக்கியத்தின் நடுவிலேயே மகிழ்ச்சியுடன் பிரித்துவிடக்கூடும், இதனால் பொறுப்புத் துறப்பு விதிகள் (liability clauses) தொடர்பில்லாத இரண்டு உரைத் துண்டுகளுக்கு இடையில் தொங்கிக்கொண்டிருக்கும். ஒரு முழு API endpoint விளக்கத்தையும் ஒரே பெரிய துண்டாகத் திணிக்கும்போது, பயனர் கேட்ட குறிப்பிட்ட அளவுரு (parameter) தேவையற்ற தகவல்களுக்குள் மூழ்கிவிடும். மீட்டெடுப்பு (retrieval) மெதுவாக இருக்கும்போது, ஒவ்வொரு மில்லிசெகண்ட் தாமதமும் (latency) பயனர் அனுபவத்தைப் நேரடியாகப் பாதிக்கிறது. இதை நாங்கள் கடினமான முறையில் கற்றுக்கொண்டோம். பின்னர் எங்கள் retrieval layer-ஐ முழுமையாகத் தகர்த்து மீண்டும் உருவாக்கினோம். எங்களது recall at ten 78 சதவீதத்திலிருந்து 95 சதவீதமாக உயர்ந்தது. தாமதம் (latency) அதிகரிக்கவில்லை; மாறாகக் குறைந்துவிட்டது.
Copy-Paste RAG-இல் உள்ள சிக்கல்
நிலையான RAG stack ஒரு வகையான இயல்பு அமைப்பாக (default setting) மாறிவிட்டது. சிறிய துண்டுகள், ஒரு embedding model, vector search - அவ்வளவுதான். இந்த அணுகுமுறை ஒரு டெமோவில் (demo) வெற்றி பெறலாம், ஏனெனில் டெமோக்களில் தெளிவான கேள்விகளும் நேர்த்தியான ஆவணங்களும் பயன்படுத்தப்படுகின்றன. ஆனால் தயாரிப்புத் தரவுகள் (production data) ஒருபோதும் நேர்த்தியாக இருப்பதில்லை.
சட்ட ஆவணங்கள் படிநிலை அமைப்பைக் (hierarchical structure) கொண்டுள்ளன. பிரிவுகள் (Sections) துணைப் பிரிவுகளைக் (subsections) கொண்டுள்ளன. துணைப் பிரிவுகள் விதிகளைக் (clauses) கொண்டுள்ளன. ஒரு சாதாரண token counter மூலம் அவற்றை நீங்கள் துண்டிக்க முயன்றால், மாதிரி (model) பகுத்தறிவதற்குத் தேவையான உறவுகளை நீங்கள் அழித்துவிடுகிறீர்கள். API ஆவணங்களுக்கும் அமைப்பு உண்டு, ஆனால் அது வேறுபட்டது. ஒரு function signature, அதன் parameters, அதன் return value மற்றும் ஒரு உதாரணம் ஆகியவை ஒரு தர்க்கரீதியான அலகாக (logical unit) அமைகின்றன. அவற்றை ஒரு நிலையான token window-க்குள் திணிக்க முயலும்போது, நீங்கள் உதாரணத்தைத் துண்டிக்க நேரிடும் அல்லது அந்தத் துண்டில் தொடர்பில்லாத function-களை நிரப்ப வேண்டியிருக்கும். Support tickets குழப்பமானவை, உரையாடல் போன்றவை மற்றும் திடீர் தலைப்பு மாற்றங்களைக் கொண்டவை. Wikis விரிவானவை மற்றும் குறுக்குக் குறிப்புகளைக் (cross-referenced) கொண்டவை. ஒரே chunking strategy இவற்றுக்கெல்லாம் பொருந்தாது, இருப்பினும் குழுக்கள் அதை அப்படியே பயன்படுத்துகின்றன. அது சாத்தியம் என்று நாங்கள் நம்புவதை நிறுத்திவிட்டோம்.
Strategic Chunking: முறையைத் தரவுக்கு ஏற்பப் பொருத்துங்கள்
நாங்கள் content-aware chunking முறைக்கு மாறினோம். சட்ட ஆவணங்களுக்கு, ஆவணத்தின் படிநிலையை மதிக்கும் recursive chunking முறையைப் பயன்படுத்துகிறோம். இது விதிகளை அப்படியே வைத்திருக்கும் மற்றும் பிரிவுகளுக்கு இடையிலான parent-child உறவுகளைப் பாதுகாக்கும். API ஆவணங்களுக்கு, ஒவ்வொரு function அல்லது endpoint-ஐயும் ஒரு எல்லையாகக் கருதும் function-aware chunking முறையை உருவாக்கினோம். ஒரு parameter விளக்கம் நீளமாக இருந்தால், அந்தத் துண்டு ஒரு token limit-ஐப் பொறுத்து அல்லாமல், அந்த function-ஐச் சுற்றியே விரிவடையும். Support tickets-களுக்கு, இயற்கையான தலைப்பு எல்லைகளைக் கண்டறியும் semantic chunking முறையைப் பயன்படுத்துகிறோம். ஒரு வாடிக்கையாளர் திடீரெனப் கட்டணப் புகாரிலிருந்து தொழில்நுட்பப் பிழைக்கு மாறும்போது, அந்தத் திருப்பத்திலேயே பிரிப்பு நிகழும். Wikis மற்றும் கட்டமைக்கப்படாத அறிவுத் தளங்களுக்கு (unstructured knowledge bases), ஒரு இலகுரக LLM உரையை மதிப்பீடு செய்து எங்கு அர்த்தமுள்ள எல்லை இருக்க வேண்டும் என்று தீர்மானிக்கும் agentic chunking முறையைப் பயன்படுத்துகிறோம். இது ஒரு character split முறையை விட அமைக்க அதிக நேரம் எடுக்கும், ஆனால் இது சரியாகச் செயல்படும் மீட்டெடுப்பிற்கும், யூகத்தின் அடிப்படையில் செயல்படும் மீட்டெடுப்பிற்கும் இடையிலான வேறுபாடாகும்.
Hybrid Retrieval: ஏன் Vector Search மட்டும் போதுமானதல்ல
Vector search பொருளைப் புரிந்துகொள்கிறது, ஆனால் துல்லியமான பொருத்தங்களைத் (exact matches) தவறவிடக்கூடும். ஒரு பயனர் ERR_CONNECTION_RESET_0x5F3 போன்ற ஒரு error code-ஐப் பதிவிட்டால், semantic similarity அதை பொதுவான நெட்வொர்க் பிழைகளைப் பற்றி விவாதிக்கும் பத்திகளுக்குக் கீழே தரவரிசைப்படுத்தலாம். மறுபுறம், BM25 துல்லியமான சொற்களைக் (exact strings) கண்டறியும், ஆனால் கருத்தியல் ரீதியான தொடர்பைத் (conceptual relatedness) தவறவிடும். உங்களுக்கு இவை இரண்டும் தேவை.
நாங்கள் vector search மற்றும் BM25 ஆகியவற்றை இணையாக (in parallel) இயக்குகிறோம். பின்னர், Reciprocal Rank Fusion அல்லது RRF மூலம் முடிவுகளை இணைக்கிறோம்; இது இரண்டு வெவ்வேறு தேடல் இடங்களிலிருந்து வரும் மதிப்பெண்களை ஒரே அளவீட்டிற்குள் (scale) கட்டாயப்படுத்தாமல் இயல்பாக்குகிறது (normalizes). இணைப்பிற்குப் பிறகு, சிறந்த முடிவுகளை (top candidates) ஒரு cross-encoder reranker மூலம் அனுப்புகிறோம். இது சிறிய அளவிலான தாமதத்தைச் சேர்த்தாலும், துல்லியத்தன்மை (precision) கணிசமாக அதிகரிக்கிறது. reranker என்பது வினவல் (query) மற்றும் ஒவ்வொரு வேட்பாளரையும் (candidate) ஒன்றாகப் படித்து, ஆரம்ப embedding-இன் cosine similarity-யை விட மிகவும் துல்லியமான பொருத்த மதிப்பெண்ணை (relevance score) வழங்குகிறது. நடைமுறையில், இந்தத் தொகுப்பு தூய vector search தவறவிடும் துல்லியமான error code-களைப் பிடிக்கிறது, அதே நேரத்தில் keyword search புறக்கணிக்கும் கருத்தியல் ரீதியாகத் தொடர்புடைய சிக்கலைத் தீர்க்கும் வழிமுறைகளையும் (troubleshooting steps) வெளிச்சத்திற்குக் கொண்டு வருகிறது.
Query Expansion: Index-ஐத் தொடங்குவதற்கு முன்பே பயனர் உள்ளீட்டைச் சரிசெய்தல்
பயனர்கள் சரியான தேடல் வினவல்களை (search queries) எழுதுவதில்லை. "எனது கடைசி deploy ஏன் தோல்வியடைந்தது மற்றும் அதை நான் எவ்வாறு பழைய நிலைக்குக் கொண்டு செல்வது (roll it back)?" போன்ற பல நிலைகளைக் கொண்ட (multi-hop) கேள்விகளை அவர்கள் கேட்கிறார்கள்; இதற்கு இரண்டு வெவ்வேறு அறிவுத் தொகுப்புகளைக் கண்டறிந்து அவற்றை இணைக்க வேண்டியிருக்கும். அல்லது, index-உடன் சரியாகப் பொருந்தாத தெளிவற்ற கேள்விகளைக் கேட்கிறார்கள்.
We transform queries before searching. A multi-hop question gets broken into sub-questions. A vague intent gets expanded into multiple specific search queries. We found that expanding one user query into five distinct search queries can move recall from seventy-eight percent to ninety-six percent. This is not about prompting the LLM harder. It is about giving the retrieval system more shots at finding the right context. Each generated query captures a different angle or terminology, and the merged results paint a complete picture.
Bayesian Optimization: Stop Guessing
Once you have multiple chunking strategies, hybrid retrieval, and query expansion, you face a new problem. There are too many knobs. Chunk size, overlap percentage, vector weight versus BM25 weight, reranking thresholds, and top-k values all interact in nonlinear ways. Manual tuning becomes a guessing game.
We stopped guessing. We treat the