ஒரு Jupyter notebook-லிருந்து நேரடிச் சேவையாக (live service) ஒரு Retrieval-Augmented Generation (RAG) பைப்லைனை நான்கு மாதங்கள் உருமாற்றிய பிறகு, ஒரு சாதாரண டெமோவை பயனர்கள் நம்பகமான முறையில் பயன்படுத்தக்கூடிய ஒரு அமைப்பாக மாற்றிய ஐந்து முக்கியமான முடிவுகளை ஆசிரியர் சுட்டிக்காட்டுகிறார். இந்த மாற்றத்தின் விளைவு எண்களில் தெரிகிறது: உரையைத் துண்டாக்கும் (text splitting) முறையில் செய்த ஒரு எளிய மாற்றம், மீட்டெடுப்பு வெற்றி விகிதத்தை (retrieval hit rate) 61% இலிருந்து 83% ஆக உயர்த்தியது; மேலும் 200 உண்மையான வினவல்களைக் கொண்ட ஒரு சிறிய மதிப்பீட்டுத் தொகுப்பு (evaluation set), வாடிக்கையாளர்களைச் சென்றடைவதற்கு முன்பே பெரும்பாலான பின்னடைவுகளை (regressions) கண்டறிந்துவிடுகிறது.

ஏன் இது முக்கியம்

RAG டெமோக்கள் பார்ப்பதற்குத் திகைப்பூட்டும் வகையில் இருக்கும் – அவை ஒரு பகுதியைத் தேடி எடுத்துச் சில நொடிகளில் பொருத்தமான பதிலைத் தரும். ஆனால் தயாரிப்பு நிலையில் (production), அதே அணுகுமுறை பெரும்பாலும் காலாவதியான தகவல்கள், விடுபட்ட பிழை குறியீடுகள் (error codes) அல்லது சிதைந்த வாக்கியங்களை வழங்குகிறது, இது பயனரின் நம்பிக்கையைச் சிதைக்கிறது. இங்குத் தடையானது பெரும்பாலும் மொழி மாதிரி (language model) அல்ல; மாறாக உள்ளடக்கம் எவ்வாறு உள்வாங்கப்படுகிறது (ingested), குறியீடாக்கப்படுகிறது (indexed) மற்றும் வழங்கப்படுகிறது (served) என்பதே ஆகும். பைப்லைனைச் சரியாக அமைப்பது, ஒரு மதிப்புமிக்க தயாரிப்பிற்கும், ஒரு சுமையாக மாறும் தயாரிப்பிற்கும் இடையிலான வித்தியாசத்தைத் தீர்மானிக்கிறது.

1. நிலையான அளவு கொண்ட துண்டுகளைப் (fixed-size chunks) பயன்படுத்துவதை நிறுத்துங்கள்

பல முன்மாதிரிகள் (prototypes) ஒவ்வொரு ஆவணத்தையும் 512-டோக்கன் தொகுதிகளாகத் துண்டிக்கின்றன. இது குறுகிய உரைகளுக்குச் சரியாக இருக்கும், ஆனால் தொழில்நுட்ப கையேடுகள், ஆதரவு விவாதங்கள் (support threads) மற்றும் குறியீட்டுத் துண்டுகளை (code snippets) சிதைத்துவிடும். வாக்கியங்கள் பிரிக்கப்படுகின்றன, தலைப்புகள் காணாமல் போகின்றன, மேலும் பயனர் எதிர்பார்க்கும் சூழலை (context) மீட்டெடுப்பு இயந்திரத்தால் (retrieval engine) சரியாகப் பொருத்த முடிவதில்லை.

பொருண்மைப் பிரிவுகளை (semantic units) பாதுகாக்க, அமைப்பு சார்ந்த துண்டாக்குதலை (structure-aware chunking) மாற்றவும்—தலைப்புகள், உரையாடல் எல்லைகள் அல்லது குறியீடு எல்லைகளைப் (code fences) பொறுத்துத் துண்டிக்கவும். ஆசிரியரின் அமைப்பில், இது மட்டுமே பொருத்தமான பகுதியைத் தேடிக் கண்டறியும் வினவல்களின் விகிதத்தை 61% இலிருந்து 83% ஆக உயர்த்தியது. இந்த முன்னேற்றம் தரவு வடிவத்தில் (data-format) செய்யப்பட்ட மாற்றத்தினால் கிடைக்கிறது; அடிப்படை மாதிரி (underlying model) அப்படியேதான் உள்ளது.

தூய வெக்டர் தேடல் (pure vector search - embedding-based similarity) ஒரே பொருளைக் கொண்ட பகுதிகளைக் கண்டறிவதில் சிறந்து விளங்குகிறது, ஆனால் பிழை குறியீடுகள் (error codes), பதிப்பு எண்கள் (version numbers) அல்லது பிரத்யேகச் சொற்கள் (proprietary terminology) போன்ற துல்லியமான அடையாளங்களைக் கண்டறிவதில் தடுமாறுகிறது. “ERR-XXXX” போன்ற ஒரு பிழை குறியீட்டைத் தேடும் பயனர், அந்த குறியீடே இல்லாத, ஆனால் பொருண்மை ரீதியாகத் தொடர்புடைய ஒரு பத்தியைப் பெறக்கூடும்.

ஹைப்ரிட் தேடல் என்பது ஒரு அடர்த்தியான வெக்டர் குறியீட்டை (dense vector index) பாரம்பரிய BM25 குறியீட்டுடன் (term-frequency based) இணைக்கிறது. இந்த இரண்டு மதிப்புகளையும் (scores) சரிசெய்வதன் மூலம், பயனர் தட்டச்சு செய்த துல்லியமான சொற்களையும் கொண்டுள்ள, அதே சமயம் பொருண்மை ரீதியாக நெருக்கமானமானப் பொருட்களையும் அமைப்பு மீட்டெடுக்கிறது. தயாரிப்பு நிலைக்கு (production), ஹைப்ரிட் தேடல் என்பது ஒரு கூடுதல் வசதி அல்ல, அது ஒரு அடிப்படைத் தேவையாகும்.

3. காலாவதியான தரவைக் கையாளுங்கள்

காலாவதியான விலைப்பட்டியல்கள், கொள்கை ஆவணங்கள் அல்லது ஃபார்ம்வேர் (firmware) வெளியீட்டுக் குறிப்புகள் நம்பகத்தன்மையை விரைவாகச் சிதைத்துவிடும். குறியீட்டைப் புத்துணர்ச்சியுடன் வைத்திருக்க மூன்று நடைமுறைப் படிகள் உள்ளன:

  • ஒவ்வொரு ஆவணத்தையும் ஒரு பதிப்பு முத்திரை (version stamp) அல்லது நேர முத்திரையுடன் (timestamp) குறிக்கவும்.
  • மதிப்பெண் வழங்கும் போது (scoring) சமீபத்தியத் தரவுகளுக்கு முன்னுரிமை (recency boost) அளிக்கவும், இதனால் புதிய உருப்படிகள் பழைய நகல்களை விட முன்னிலையில் இருக்கும்.
  • மூல அமைப்புகளிலிருந்து (source systems) மாற்றங்களைக் கொண்டு வர ஒவ்வொரு இரவும் படிப்படியான மறு-குறியீட்டை (incremental re-indexing) இயக்கவும்.

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

4. மாதிரிகளை மேம்படுத்துவதற்குப் பதிலாக ரீரங்க் (Rerank) செய்யுங்கள்

எம்பெடிங் மாதிரியை (embedding model) மேம்படுத்துவது சிறிய அளவிலான தர மேம்பாட்டையே தரும், ஆனால் ஒரு கிராஸ்-என்கோடர் ரீரங்கரை (cross-encoder reranker) சேர்ப்பது குறைந்த செலவில் மிகப்பெரிய முன்னேற்றத்தைத் தரும்.

தயாரிப்பு ஓட்டத்தில் (production flow), ஹைப்ரிட் தேடல் மூலம் 20 மலிவான வேட்பாளர்களை (candidates) மீட்டெடுத்து, பின்னர் சிறந்த ஐந்துவற்றைத் தேர்ந்தெடுக்க அவற்றை ரீரங்கர் மூலம் கடத்துகிறது. இந்த இரண்டு கட்ட அணுகுமுறை, முழு மாதிரியை மேம்படுத்துவதற்கான செலவில் ஒரு சிறு பகுதி மட்டுமே செலவில் பெரிய தர உயர்வைக் கொடுக்கிறது.

5. ஒரு உண்மையான மதிப்பீட்டுத் தொகுப்பை (evaluation set) உருவாக்குங்கள்

நீங்கள் அளவிடாத எதையும் மேம்படுத்த முடியாது. ஆசிரியர் 200 உண்மையான பயனர் வினவல்களைக் கொண்ட ஒரு சோதனைத் தொகுப்பைத் தயார் செய்தார், ஒவ்வொன்றும் ஒரு நிபுணரால் உருவாக்கப்பட்ட பதிலுடன் இணைக்கப்பட்டுள்ளது. ஒவ்வொரு குறியீடு மாற்றமும் இந்தத் தொகுப்பிற்கு எதிராகச் சோதிக்கப்படுகிறது; ஏதேனும் பின்னடைவு (regression) இருந்தால் அது பயன்பாட்டிற்கு (deployment) முன்பே கண்டறியப்படுகிறது.

ஒரு பயனர் தவறான பதிலைப் புகாரளிக்கும் போது, அந்த வினவலை உடனடியாக மதிப்பீட்டுத் தொகுப்பில் சேர்க்கவும், இதன் மூலம் நிஜ உலகத் தோல்விகளை எதிர்காலப் பாதுகாப்பு நடவடிக்கைகளாக மாற்றலாம். ஒவ்வொரு உருவாக்கப்பட்ட பதிலையும் தொடர்ந்து பதிவு செய்வது (logging) மதிப்பீட்டுச் சுழற்சிக்கு (evaluation loop) உதவுகிறது, இது அமைப்பை உண்மையான பயன்பாட்டுடன் ஒத்துப்போகச் செய்கிறது.

நடைமுறைத் தயாரிப்பு பைப்லைன் (The production pipeline in practice)

  • Ingest: அமைப்பு சார்ந்த துண்டாக்குதல் (Structure-aware chunking) தலைப்புகள், குறியீடு தொகுதிகள் (code blocks) மற்றும் உரையாடல் திருப்பங்களைப் பாதுகாக்கிறது.
  • Index: அடர்த்தியான எம்பெடிங்குகள் (dense embeddings) மற்றும் BM25 சொல் புள்ளிவிவரங்கள் (term statistics) ஆகிய இரண்டையும் சேமிக்கவும்.
  • Retrieve: ஹைப்ரிட் தேடல் பொருண்மை ஒற்றுமை மற்றும் துல்லியமான சொல் பொருத்தங்களைச் சமன் செய்து 20 வேட்பாளர்களைத் திருப்பித் தருகிறது.
  • Rerank: ஒரு கிராஸ்-என்கோடர் பட்டியலை மிகவும் நம்பிக்கைக்குரிய ஐந்து பத்திகளாகக் குறைக்கிறது.
  • Generate: இறுதிப் பதிலைத் தயாரிக்க LLM இந்தத் தலைசிறந்த துண்டுகளையும் அவற்றின் மெட்டாடேட்டாவையும் (metadata) பெறுகிறது.
  • Evaluate: ஒவ்வொரு பதிலும் பதிவு செய்யப்படுகிறது; தோல்விகள் 200-வினவல் சோதனைத் தொகுப்பிற்குத் திரும்ப அனுப்பப்படுகின்றன.

முக்கியத்துவம் மற்றும் சமரசங்கள் (Stakes and trade-offs)

நன்கு சரிசெய்யப்பட்ட ஒரு pipeline, மாயத்தோற்றங்களைக் (hallucinations) குறைக்கிறது, பதிலின் பொருத்தத்தன்மையை மேம்படுத்துகிறது மற்றும் அதிகப்படியான வளங்கள் ஒதுக்கப்பட்ட மாதிரிகளின் (over-provisioned models) செலவைக் குறைக்கிறது. இதன் மூலம் அதிக பயனர் திருப்தியையும் குறைந்த பராமரிப்புச் சுமையையும் பெற முடியும். இந்த நிலைகளைப் புறக்கணிப்பது, பிராண்ட் மீதான நம்பிக்கையைச் சிதைத்து, அதிகச் செலவுமிக்க அவசரத் தீர்வு முயற்சிகளுக்கு (firefighting) தள்ளும் ஒரு பலவீனமான சேவையை உருவாக்கும்.

அடுத்து கவனிக்க வேண்டியவை

திறந்த மூல (open-source) embeddings மற்றும் வெக்டர் தரவுத்தளங்கள் (vector databases) முதிர்ச்சியடையும் போது, “dense” மற்றும் “sparse” மீட்டெடுப்பிற்கு (retrieval) இடையிலான வேறுபாடு மங்கலாகிவிடும், ஆனால் பொருண்மை சார்ந்த (semantic) மற்றும் துல்லியமான (exact) பொருத்தத்தை இணைக்கும் கொள்கை மாறாமல் இருக்கும்.

முக்கியக் கருத்து: ஒரு RAG அமைப்பில், மொழி மாதிரி (language model) என்பது அரிதாகவே ஒரு தடையாகும் புள்ளியாக (choke point) இருக்கும். உண்மையான வேலை என்பது நீங்கள் அடிப்படை உள்ளடக்கத்தை எவ்வாறு துண்டிக்கிறீர்கள் (slice), குறியிடுகிறீர்கள் (index) மற்றும் வெளிப்படுத்துகிறீர்கள் (surface) என்பதில் தான் உள்ளது. அந்த முடிவுகளைச் சரியாக எடுப்பது, ஒரு கவர்ச்சிகரமான டெமோவை (flashy demo) ஒரு நம்பகமான தயாரிப்பாக மாற்றும்.