Most teams build their first retrieval system the same way: slice every document into fixed 512 token chunks, push them

பெரும்பாலான குழுக்கள் தங்களது முதல் retrieval system-ஐ ஒரே மாதிரியாகவே உருவாக்குகின்றன: ஒவ்வொரு ஆவணத்தையும் நிலையான 512-token துண்டுகளாகப் (chunks) பிரித்து, அவற்றை ஒரு vector database-க்குள் செலுத்தி, embedding model கடினமான வேலையைச் செய்துவிடும் என்று நம்புகின்றன. அந்த நம்பிக்கை ஒரு டெமோவிற்கு (demo) போதுமானதாக இருக்கலாம். ஆனால் உண்மையான பயனர்களுடன் தொடர்பு கொள்ளும்போது அது நிலைக்காது.

நடைமுறையில் (In production), ஒரு பொறுப்புத் துறையை விளக்கும் விதியிலிருந்து (liability clause) அதன் விதிவிலக்குகளை நீங்கள் பிரிக்கும்போது, ஒரு சட்ட ஒப்பந்தம் சிதைந்துவிடும். ஒரு code sample அதன் function signature-லிருந்து பிரிக்கப்படும்போது, API documentation பயனற்றதாகிவிடும். ஒரு வாடிக்கையாளர் ஆதரவு உரையாடலில் (customer support thread) இருந்து ஒரு தனிப் புகாரை மட்டும் நீங்கள் பிரிக்கும்போது, அது வெறும் இரைச்சலாக (noise) மாறிவிடும். இந்தப் பிரச்சனையின் காரணம் பெரும்பாலும் pipeline-இன் இறுதியில் இருக்கும் language model அல்ல. நீங்கள் அதற்கு எதைக் கொடுக்கிறீர்கள் என்பதே பிரச்சனை.

இதை நாங்கள் கடினமான அனுபவத்தின் மூலம் கற்றுக்கொண்டோம். எங்களது ஆரம்பகால retrieval layer பார்ப்பதற்குத் தரமானதாகத் தெரிந்தாலும், அதன் செயல்பாடு சீரற்றதாக இருந்தது. எனவே, retrieval-ஐ ஒரு மாயமாகப் பார்க்காமல், அளவிடக்கூடிய ஒரு உள்கட்டமைப்பாக (measured infrastructure) கருத வேண்டும் என்ற எளிய கருத்தைச் சுற்றி அதை நாங்கள் மீண்டும் உருவாக்கினோம். நாங்கள் சரியாக என்ன மாற்றினோம் என்பதையும், 95th-percentile latency-ஐ 850 ms-லிருந்து 320 ms-ஆகக் குறைக்கும் அதே வேளையில், recall-ஐ எவ்வாறு 95 சதவீதமாக உயர்த்தினோம் என்பதையும் இங்கே காணலாம்.

The Fixed-Chunk Trap

சீரான token எண்ணிக்கையைக் கையாள்வது குறியீட்டு முறைக்கும் (coding) விளக்குவதற்கும் எளிது. ஆனால் அந்த வசதி ஒரு அடிப்படை உண்மையை மறைக்கிறது: ஆவணங்களுக்கு ஒரு கட்டமைப்பு (structure) உண்டு. அந்த கட்டமைப்பை நீங்கள் புறக்கணிக்கும்போது, முக்கியமான தகவல்களை (signal) நீங்கள் அழித்துவிடுகிறீர்கள்.

பத்து பக்கங்கள் கொண்ட ஒரு master service agreement-ஐ எடுத்துக் கொள்ளுங்கள். ஒரு நிலையான 512-token துண்டு, ஒரு கடப்பாட்டின் (obligation) நடுப்பகுதியிலேயே முடிந்துவிடும், இதனால் ஒரு விதியை (clause) அதைத் கட்டுப்படுத்தும் அட்டவணையிலிருந்து (cap table) பிரித்துவிடும். அப்போது retrieval செயல்முறை ஒரு முழுமையற்ற கருத்தையே வழங்கும். மீதமுள்ளதை generator கற்பனையாக (hallucinates) உருவாக்கிவிடும். API documentation-இல், ஒரு chunk மிகப்பொரியதாக இருந்தால், அது தேவையற்ற தலைப்புகளால் (boilerplate headers) embedding-ஐக் குறைத்துவிடும், இதனால் ஒரு developer-க்குத் தேவையான குறிப்பிட்ட method மறைந்துவிடும். Support tickets-இல், ஒரு நிலையான window முறை உரையாடலை வெறும் வாக்கியங்களின் தொகுப்பாக மட்டுமே கருதுகிறது, இதனால் உண்மையில் என்ன தவறு நடந்தது என்பதைக் காட்டும் உரையாடல் ஓட்டத்தை (back-and-forth) அது இழந்துவிடுகிறது.

chunk size-ஐ நாங்கள் வெறும் யூகத்தின் அடிப்படையில் அமைக்கும் ஒரு hyperparameter ஆகக் கருதுவதை நிறுத்தினோம். அதற்குப் பதிலாக, ஆவண வகையிற்கும் அதன் உள்ளே இருக்கும் தகவல் கட்டமைப்பிற்கும் (information architecture) இடையிலான ஒரு வரைபடப் பணியாக (mapping exercise) அதைக் கருதத் தொடங்கினோம்.

Match Your Chunking to the Data

இதற்கு ஒரே ஒரு சரியான chunk size தீர்வாகாது. மூன்று வெவ்வேறு தரவு வடிவங்களுக்கு (data shapes) ஏற்றவாறு வடிவமைக்கப்பட்ட மூன்று தனித்துவமான உத்திகளே (strategies) தீர்வாகும்.

Legal documents இப்போது recursive splitting முறையைப் பயன்படுத்துகின்றன. இந்த algorithm முதலில் பெரிய இயற்கை எல்லைகளைத் தேடுகிறது—பிரிவுகள் (sections), பின்னர் துணைப் பிரிவுகள் (subsections), பிறகு எண் இடப்பட்ட விதிகளாக (numbered clauses)—தேவைப்படும்போது மட்டுமே சிறிய துண்டுகளாகப் பிரிக்கிறது. இது ஒரு termination clause-ஐ அதன் survival conditions-உடன் இணைத்தே வைத்திருக்கும். இதனால் retrieval செயல்முறை முழுமையான தர்க்கரீதியான அலகுகளைப் (logical units) பார்க்கிறது, இது விடுபட்ட விதிவிலக்குகளைத் தவறாகக் கற்பனை செய்யும் மாதிரியின் (model) தூண்டுதலைக் கடுமையாகக் குறைக்கிறது.

API and code documentation ஆகியவை கட்டமைப்பை உணர்ந்த (structure-aware) chunking முறையைப் பெறுகின்றன. Markdown headers, code fences மற்றும் parameter tables ஆகியவை atomic units-களாகப் பகுப்பாய்வு செய்யப்படுகின்றன. நாங்கள் ஒரு code block-க்குள் பிரியமாட்டோம். docstrings-களை அவற்றின் signatures-களுக்கு அருகிலேயே வைத்திருக்கிறோம். இதன் விளைவாக, ஒரு குறிப்பிட்ட class method-க்கான தேடல் (query), ஒரு developer-க்குத் தேவையான முழுமையான சூழலையும் (context) வழங்குகிறது: விளக்கம், typed parameters மற்றும் ஒரு working example.

Support and conversational data semantic chunking முறையைப் பயன்படுத்துகின்றன. tokens எண்ணிக்கையைக் கணக்கிடுவதற்குப் பதிலாக, தலைப்பு அல்லது நோக்கத்தின் (intent) மாற்றங்களை நாங்கள் கவனிக்கிறோம். ஒரு வாடிக்கையாளர் மூன்றாவது செய்தியில் ஒரு பிழையை விவரித்து, ஏழாவது செய்தியில் ஒரு stack trace-ஐப் பதிவிட்டால், நாங்கள் செய்தியின் வரிசை எண்ணை (message index) வைத்துப் பிரிக்காமல், பொருளின் அடிப்படையில் (meaning) பிரிக்கிறோம். இதனால் retrieval layer ஒரு தனித்து விடப்பட்ட வாக்கியத்திற்குப் பதிலாக, பிரச்சனையின் முழுமையான போக்கையும் (full arc) வழங்குகிறது.

Why Vector Search Alone Fails

மிகச்சரியான துண்டுகள் கூட ஒரு தூய vector search-இல் தோல்வியடையக்கூடும். Dense embeddings பொருளையும் அதன் synonymy-யையும் கண்டறிவதில் சிறந்து விளங்கினாலும், துல்லியமான சொற்களைக் (exact strings) கண்டறிவதில் அவை தடுமாறுகின்றன. ஒரு பொறியாளர் துல்லியமான error code ERR_CONNECTION_REFUSED-ஐத் தேடினால், vector similarity ஒரு டஜன் கருத்து ரீதியான நெருக்கமான முடிவுகளைத் தரலாம், ஆனால் 14-வது இடத்தில் மறைந்திருக்கும் துல்லியமான பொருத்தத்தைத் தவறவிடலாம்.

BM25 கொண்டு செய்யப்படும் Keyword search-இல் இதற்கு நேர்மாறான பிரச்சனை உள்ளது. அது துல்லியமான tokens-களைக் கண்டறியும் ஆனால் அதன் semantic intent-ஐ தவறவிடும். “why is my database down” என்று கேட்கும் ஒரு பயனர், “troubleshooting connection timeouts” என்று கூறும் ஆவணத்துடன் ஒருபோதும் பொருந்தமாட்டார்.

நாங்கள் இப்போது இரண்டையும் பயன்படுத்துகிறோம். Vector மற்றும் keyword முடிவுகள் Reciprocal Rank Fusion-க்குள் செலுத்தப்படுகின்றன, இது அளவிடப்பட்ட மதிப்பெண்கள் (calibrated scores) இல்லாமலேயே இரண்டு வரிசைப் பட்டியல்களையும் ஒன்றிணைக்கிறது. இந்த இணைக்கப்பட்ட பட்டியல் பின்னர் ஒரு cross-encoder reranker வழியாக அனுப்பப்படுகிறது. reranker என்பது ஆரம்பகால retrieval-ஐ விட மெதுவானது, ஆனால் அது அழுத்தப்பட்ட embeddings வழியாக இல்லாமல், query-document இடையிலான பொருத்தத்தை நேரடியாகத் தீர்மானிப்பதால் மிகவும் துல்லியமானது. இந்த hybrid pipeline மட்டுமே எங்களது recall-ஐ 15 சதவீதம் உயர்த்தியது.

Fixing Bad Queries Before They Hit the Index

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

இப்போது, ஒவ்வொரு வரும் வினவலையும் மீட்டெடுப்பு அடுக்குக்கு (retrieval layer) அனுப்பும் முன், மூன்று முதல் ஐந்து மாறுபாடுகளாக விரிவுபடுத்துகிறோம். ஒரு மாறுபாடு நேரடித் துணைச் சொல்லாக (paraphrase) இருக்கலாம். மற்றொன்று ஒரு கற்பனையான சிறந்த ஆவணத் தலைப்பாக இருக்கலாம். மூன்றாவது, உரையாடல் சார்ந்த தேவையற்ற சொற்களை நீக்கிவிட்டு, தொழில்நுட்ப முக்கியச் சொற்களை மட்டும் பிரித்தெடுக்கும். ஒவ்வொரு மாறுபாடும் உட்பொதிக்கப்பட்டு (embedded) தேடப்படுகிறது. பின்னர், நாங்கள் தேடப்பட்ட முடிவுகளில் இருந்து நகல்களை நீக்கி (deduplicate), அவற்றை ஒன்றிணைக்கிறோம்.

இது இலவசமானது அல்ல. அந்த கூடுதல் உட்பொதித்தல் அழைப்புகள் (embedding calls) பணத்தையும், சில மில்லி விநாடிகளையும் செலவிடுகின்றன. ஆனால், மீட்டெடுப்பின் துல்லியத்தில் (recall) ஏற்பட்ட மாற்றம் வியக்கத்தக்கது: வினவல்களை விரிவுபடுத்தியதன் மூலம், நாங்கள் 78 சதவீதத்திலிருந்து 96 சதவீதத்திற்கு முன்னேறினோம். சிறந்த மீட்டெடுப்பு, உருவாக்கக் காலத்தை (generation window) குறைப்பதோடு, மாதிரியைச் சரியான சூழலில் (context) நிலைநிறுத்துகிறது, இதனால் இறுதியில் நாங்கள் பணத்தைச் சேமிக்க முடிந்தது. சற்று அதிகச் செலவுள்ள மீட்டெடுப்பு முறை, நீண்ட மற்றும் தவறான தகவல்களை உருவாக்கும் (hallucinated generation) முறையை விட மலிவானது.

யூகிக்கುವುದைத் தவிருங்கள். தேடத் தொடங்குங்கள்.

சரியான துண்டாக்குதல் (chunking), கலப்பு மீட்டெடுப்பு (hybrid retrieval) மற்றும் வினவல் விரிவாக்கம் ஆகியவற்றைச் செய்த பிறகும், நாங்கள் ஒரு சிக்கலான கலப்பு நிலையைச் சந்தித்தோம். துண்டு அளவு (chunk size), துண்டுகளின் மேற்பொருந்துதல் (chunk overlap), top-k மீட்டெடுப்பு ஆழம், reranker வரம்புகள் மற்றும் இணைப்பு எடைகள் (fusion weights) ஆகிய அனைத்தும் ஒன்றோடொன்று தொடர்புடையவை. ஒரு கைமுறைத் தேடல் (manual grid search) வாரக்கணக்கில் எடுத்திருக்கும், அப்படியிருந்தாலும் அது ஒரு குறிப்பிட்ட நிலையை மட்டுமே எட்டியிருக்கும்.

இந்தத் தேடலை மேற்கொள்ள நாங்கள் Bayesian optimization முறையை மாற்றினோம். ஒவ்வொரு சேர்க்கையையும் முழுமையாகச் சோதிப்பதற்குப் பதிலாக, எந்த அமைப்புகள் சிறப்பாகச் செயல்படும் என்ற நம்பிக்கையை இந்தத் தேடல் அல்காரிதம் பராமரித்து, படிப்படியாகச் சிறந்த பகுதிகளை நோக்கிச் சுருங்கிச் செல்கிறது.

இதன் வெளியீடு என்பது ஒரே ஒரு சிறந்த அமைப்பல்ல. அது பல தேர்வுகளின் ஒரு எல்லை (Pareto frontier) ஆகும். ஒரு முனையில், எங்களது அதிகத் திறன் கொண்ட API ஆதரவு முனையத்திற்கு (high-throughput API support endpoint) ஏற்ற ஒரு லீன் (lean) அமைப்பு உள்ளது: வேகமான அனுமானம் (inference), மிதமான மீட்டெடுப்பு மற்றும் மிகக் குறைந்த தாமதம் (latency). மறுமுனையில், சட்டப் பரிசீலனைக்காக (legal review) ஒரு தீவிரமான அமைப்பு உள்ளது: ஆழமான மீட்டெடுப்பு, அதிகப்படியான reranking மற்றும் நெருக்கமான மேற்பொருந்துதல், அதாவது துல்லியத்திற்காக மில்லி விநாடிகளைத் தியாகம் செய்கிறது. இந்த எல்லைத் தெரிவுகள் தெளிவாக இருப்பதால், "அனைத்திற்கும் ஒன்று பொருந்தும்" என்று போலித்தனமாகச் சொல்லாமல், தயாரிப்பிற்குத் தேவையான சரியான புள்ளியைத் தேர்ந்தெடுக்க முடிகிறது.

எண்கள் உண்மையில் எதைக் காட்டுகின்றன

இந்த மாற்றங்கள் அமைப்பை ஒரு பலவீனமான முன்மாதிரியிலிருந்து (prototype), அளவிடக்கூடிய ஒரு உற்பத்திப் பாதையாக (production pipeline) மாற்றின.

Recall at ten என்பது 78 சதவீதத்திலிருந்து 95 சதவீதமாக உயர்ந்தது. இதன் பொருள், எங்களது தரவுத் தொகுப்பில் (corpus) சரியான விடை இருக்கும்போது, இருபதில் பத்தொன்பது முறை நாங்கள் அதைக் கண்டுபிடித்துவிடுகிறோம்.

95-வது சதவீதத் தாமதம் (Latency at the 95th percentile) 850 ms-லிருந்து 320 ms ஆகக் குறைந்தது. கலப்பு அடுக்கு (hybrid stack) பார்ப்பதற்குப் பெரியதாகத் தோன்றலாம், ஆனால் புத்திசாலித்தனமான குறியீட்டு முறை (indexing), சிறிய rerankers மற்றும் தேவைப்படும்போது மட்டுமே தீவிரமான துண்டுகளை (aggressive chunks) வழங்குதல் ஆகியவை ஒட்டுமொத்த அமைப்பையும் வேகமாக்கின.

தவறான தகவல்களை உருவாக்கும் விகிதம் (Hallucination rate) — ஒரு குறிப்பிட்ட தரவுத் தொகுப்பில் (golden dataset) மனித மதிப்பீட்டாளர்களால் கண்காணிக்கப்பட்டது — 12 சதவீதத்திலிருந்து 3 சதவீதமாகக் குறைந்தது. மாதிரிக்கு முழுமையான மற்றும் பொருத்தமான சூழல் கிடைக்கும்போது, அது கற்பனையான உண்மைகளை உருவாக்குவதை நிறுத்துகிறது.

வினவலுக்கான செலவு $0.008-லிருந்து $0.005 ஆகக் குறைந்தது. சிறந்த மீட்டெடுப்பு என்பது குறுகிய மற்றும் அதிகக் கவனம் செலுத்தும் LLM தூண்டுதல்களையும் (prompts), குறைவான மீட்பு முயற்சிகளையும் குறிக்கிறது. வினவல் விரிவாக்கத்திற்காகச் செய்யப்படும் கூடுதல் உட்பொதித்தல் செலவு, உருவாக்கத்தின் போது சேமிக்கப்படும் தொகையை விட மிகக் குறைவு.

ஒரு சிறந்த தரவுத் தொகுப்பை (Golden Dataset) உருவாக்குங்கள் மற்றும் மீட்டெடுப்பை ஒரு நிரலைப் போலக் கருதுங்கள்

இதிலிருந்து நீங்கள் ஒன்றைக் கற்றுக் கொள்ள வேண்டும் என்றால், அது அளவீட்டு ஒழுக்கம் (discipline of measurement) தான். உண்மையான கேள்விகள் மற்றும் சரிபார்க்கப்பட்ட விடை இடங்களைக் கொண்ட ஒரு சிறிய சிறந்த தரவுத் தொகுப்பை (golden dataset) நாங்கள் உருவாக்கினோம். எந்த மாற்றமும் பயன்பாட்டுக்கு (production) வரும் முன், அது அந்தத் தரவுத் தொகுப்பில் சோதிக்கப்படுகிறது. மீட்டெடுப்பு மற்றும் தாமதம் ஆகியவை நிகழ்நேரத்தில் (real time) கண்காணிக்கப்படுகின்றன, அவை நோட்புக்கில் (notebook) பார்த்துத் தீர்மானிக்கப்படுவதில்லை.

மீட்டெடுப்பு என்பது ஒரு ஆராய்ச்சிச் செயல்முறை (research demo) அல்ல. அது ஒரு உள்கட்டமைப்பு (infrastructure). உங்கள் தொழில்நுட்பத் தொகுப்பின் (stack) மற்ற பகுதிகளைப் போலவே, இதற்கும் யூனிட் தேர்வுகள் (unit tests), பின்னடைவு அளவீடுகள் (regression benchmarks) மற்றும் தானியங்கி மேம்படுத்தல் (automated optimization) ஆகியவை தேவைப்படுகின்றன. ஆவணத்தின் கட்டமைப்பைப் பொறுத்துத் துண்டாக்குங்கள், டோக்கன் (token) நம்பிக்கையின் அடிப்படையில் அல்ல. வெக்டர் (vector) மற்றும் முக்கியச் சொல் (keyword) தேடலை reranker உடன் இணைக்கவும். பயனர்கள் உண்மையில் எழுதும் வினவல்களை விரிவுபடுத்தவும். பின்னர், உங்கள் உள்ளுணர்வுக்குப் பதிலாக ஒரு தேடல் அல்காரிதத்தை (search algorithm) மாற்றங்களைச் செய்ய அனுமதிக்கவும்.

நாங்கள் விவரித்த இந்தத் தொடர்முறை வெறும் தியரி மட்டுமல்ல. இதன் அசல் கட்டுரையை நீங்கள் இங்கே படிக்கலாம். மேலும், இதைப் பற்றி அக்கறை கொண்ட ஒரு சமூகத்துடன் மீட்டெடுப்பு பொறியியல் (retrieval engineering) குறித்து விவாதிக்க விரும்பினால், GyaanSetu AI group திறந்தே உள்ளது.