अधिकांश RAG பயிற்சிகள் நோட்புக்கிலேயே (notebook) முடிந்துவிடுகின்றன. அவை சில நேர்த்தியான PDF கோப்புகளைப் பதிவிறக்கம் செய்து, ஒவ்வொரு ஆயிரம் எழுத்துக்களுக்கும் உரையைத் துண்டுகளாகப் பிரித்து, அந்தத் துண்டுகளை ஒரு வெக்டர் தரவுத்தளத்தில் (vector database) திணித்து, அதை ஒரு கட்டமைப்பைக் (architecture) கொண்டதாகக் கூறிவிடுகின்றன. ஒரு வெள்ளிக்கிழமை மதிய வேளையில், அந்த டெமோ மிகச் சிறப்பாக இயங்கும். ஆனால் தயாரிப்பு நிலையில் (production), அதே பைப்லைன் (pipeline) அமைதியாக ஒரு சுமையாக மாறிவிடும்.
ஒரு மீட்ட்ரிவல் சிஸ்டத்தில் (retrieval system) உண்மையானத் தடை என்பது பெரும்பாலும் மாடல் (model) அல்லது பிராம்ப்ட் (prompt) அல்ல. அது தரவு உள்ளீடு (ingestion) ஆகும். ஒரு RAG பைப்லைனில் எதை உள்ளீடு செய்கிறோமோ அதை மட்டுமே மீட்ட்ரிவல் செய்ய முடியும்; அந்த உள்ளீடு இரைச்சலாகவோ (noisy), காலாவதியானதாகவோ (stale) அல்லது முழுமையற்றதாகவோ இருந்தால், மாடல் நம்பிக்கையுடன் தவறான தகவல்களை வழங்கும். பாட் (bot) தவறான தகவல்களைத் (hallucinated) தருகிறது என்று பயனர்கள் புகார் செய்யும்போது, அந்தத் தவறு பெரும்பாலும் யாரும் உன்னிப்பாகக் கவனிக்காத ஒரு டேட்டா பைப்லைனில் (data pipeline) வெகுதொலைவில் உள்ள தரவுப் பகுதியில்தான் நிகழ்கிறது.
வைட்போர்டு பொறி (The Whiteboard Trap)
கட்டமைப்பு வரைபடங்கள் (Architecture diagrams), தரவு உள்ளீட்டை (ingestion) "Documents → Vector DB" என்று பெயரிடப்பட்ட ஒரு ஒற்றை அம்புக்குறியாகக் காட்டுகின்றன. ஆனால் உண்மை நிலை மிகவும் சிக்கலானது. மூல அமைப்புகள் (Source systems) முன்னறிவிப்பின்றி மாறுகின்றன. HTML வடிவமைப்புகள் (layouts) மறுசீரமைக்கப்படுகின்றன. URL-கள் பொதுவான லேண்டிங் பக்கங்களுக்குத் திசைதிருப்பப்படுகின்றன (redirect). ஆரம்ப HTTP பதிலுக்குப் பிறகு ஜாவாஸ்கிரிப்ட் கட்டமைப்புகள் (JavaScript frameworks) உள்ளடக்கத்தை மாற்றுகின்றன. தரவு உள்ளீட்டை ஒருமுறை மட்டும் செய்யும் பணியாகக் கருதுவது முதல் தவறு. இது எந்தவொரு ETL பைப்லைனையும் போலவே மிகுந்த கவனத்துடன் கையாளப்பட வேண்டிய ஒரு தொடர்ச்சியான டேட்டா இன்ஜினியரிங் (data engineering) பிரச்சனையாகும்.
RAG தோல்விகள் ஏன் பெரும்பாலும் உள்ளீடு தோல்விகளாக இருக்கின்றன?
இதைக் கற்பனை செய்து பாருங்கள்: ஒரு பயனர் உங்கள் நிறுவன உதவியாளரிடம் (internal assistant) தற்போதைய ரீஃபண்ட் கொள்கையைப் (refund policy) பற்றி கேட்கிறார். மாடல் வெக்டர் ஸ்டோரிலிருந்து (vector store) முதல் துண்டைப் பெற்று 30 நாள் கால அவகாசம் என்று கூறுகிறது. ஆனால் உண்மையான கொள்கை கடந்த காலாண்டில் 60 நாட்களாக மாற்றப்பட்டது. LLM தவறான பதிலை உருவாக்கவில்லை. அது தவறான உள்ளீட்டை நம்பியது. மீட்ட்ரிவல் லேயர் (retrieval layer) ஒரு பழைய பக்கத்தை வழங்கியது, மேலும் அந்த எம்பெடிங் (embedding) அர்த்தரீதியாக (semantically) போதுமான அளவு நெருக்கமாக இருந்ததால், மாடல் அதை உண்மையான தகவலாகக் கருதியது.
இந்த முறை தொடர்ந்து நிகழ்கிறது. ஒரு குழுவின் தரவுத் தொகுப்பு (corpus) நேவிகேஷன் ஃபுட்டர்கள் (navigation footers), நகல் செய்தி வெளியீடுகள் (duplicate press releases) மற்றும் அட்டவணைகளை பாதியாகப் பிரிக்கும் துண்டுகளால் நிறைந்திருக்கும் போது, அவர்கள் டெம்பரேச்சர் (temperature) மற்றும் top-k அளவுகளைச் சரிசெய்வதில் பல மணிநேரங்களை வீணடிக்கிறார்கள். நீங்கள் ஜெனரேஷனை (generation) மேம்படுத்துவதற்கு முன், உங்கள் சிஸ்டத்திற்கு என்ன தெரிய அனுமதித்துள்ளீர்கள் என்பதைத் தணிக்கை (audit) செய்யுங்கள்.
தரவு உள்ளீட்டைச் சிதைக்கும் ஏழு பொறிகள்
1. முதல் இயக்கம் ஒரு பொய்
உங்கள் ஆரம்பகட்ட க்ராவலில் (crawl) ஒரு பச்சை நிறக் குறியீடு கிடைப்பது என்பது எதற்கும் உதவாது. தயாரிப்புத் தரவு (Production data) எப்போதும் மாறிக்கொண்டே இருக்கும். ஆவணப் பக்கங்கள் (Documentation pages) மறுசீரமைக்கப்படுகின்றன, பிளாக் பெர்மாலிங்க்ஸ் (blog permalinks) உடைந்து போகின்றன, மற்றும் சைட்மேப்கள் (sitemaps) அமைதியாகப் பகுதிகளைத் துண்டித்துவிடுகின்றன. பைப்லைன் பிழையின்றி முடிந்தது என்பதை மட்டும் நீங்கள் சரிபார்த்தால், நீங்கள் இருட்டில் பறப்பதைப் போன்றது. நீங்கள் வெளியீட்டை (output) சரிபார்க்க வேண்டும். எதிர்பார்க்கப்படும் ஆவணங்கள் உள்ளனவா, அவற்றின் அமைப்பு இன்னும் சரியாகப் பகுப்பாய்வு செய்யப்படுகிறதா மற்றும் ஒரு மூலத் தரவு முடிவுகளைப் பக்கங்களாகப் பிரிக்கத் (paginate) தீர்மானித்ததால் மொத்த உரை அளவு குறைந்துவிட்டதா என்பதைச் சரிபார்க்கவும்.
2. க்ராலிங் (Crawling) என்பது தரவு உள்ளீடு (Ingestion) அல்ல
HTML-ஐப் பெறுவது எளிதான பகுதி. ஒரு நேரடி க்ராவல் (raw crawl) அனைத்தையும் கைப்பற்றுகிறது: குக்கீ பேனர்கள் (cookie banners), "தொடர்புடைய கட்டுரைகள்" (Related Articles) சைட்பார்களை (sidebars), விளம்பரத் தொகுதிகள் (ad blocks) மற்றும் ஃபுட்டர் காப்புரிமை அறிவிப்புகள் (footer copyright notices). நீங்கள் அந்த மூல HTML-ஐத் துண்டுகளாகப் பிரித்தால், ஒவ்வொரு உரைத் துண்டிலும் நேவிகேஷன் மெனுவின் (navigation menu) பகுதிகள் இருக்கும். ஒரு பயனர் API ரேட் லிமிட்ஸ் (API rate limits) பற்றி கேட்கும்போது, மீட்ட்ரிவர் (retriever) 40 சதவீதம் சைட்பார் லிங்க்குகளைக் கொண்ட ஒரு துண்டை வெளிப்படுத்தலாம். சுத்தமான பிரித்தெடுத்தல் (Clean extraction) முக்கியமானது. நீங்கள் முக்கிய உள்ளடக்கப் பகுதியை அடையாளம் கண்டு, தேவையற்ற பகுதிகளை (boilerplate) நீக்கி, ஒவ்வொரு பக்கத்திலும் மீண்டும் மீண்டும் வரும் கூறுகளை அகற்ற வேண்டும். இல்லையெனில் நீங்கள் ஒரு அறிவுத் தளத்தை (knowledge base) உருவாக்கவில்லை; மாறாக இணையதளத்தின் தேவையற்ற கூறுகளைத் தேடும் ஒரு தேடுபொறியை உருவாக்குகிறீர்கள்.
3. சங்கிங் (Chunking) பொருளைச் சிதைக்கிறது
கிட்டத்தட்ட எல்லா விரைவு வழிகாட்டிகளிலும் (quickstart guides) நிலையான அளவு சங்கிங் (Fixed-size chunking) என்பது இயல்பான ஒன்றாக உள்ளது, மேலும் இது ஆபத்தானது. ஒரு ஆவணத்தை வெறும் எழுத்து எண்ணிக்கையின் அடிப்படையில் மட்டும் பிரித்தால், நீங்கள் அட்டவணைகளை நடுப்பகுதியிலேயே துண்டிப்பீர்கள், ஒரு வரிசைமுறைப் பணியில் உள்ள படி 4 மற்றும் 5-ஐப் பிரிப்பீர்கள், மற்றும் புல்லட் பாயிண்டுகளை அவற்றின் தலைப்புகளிலிருந்து தனிமைப்படுத்துவீர்கள். ஒரு விலைப்பட்டியலின் (pricing table) இரண்டாம் பாதியை மட்டும் கொண்ட ஒரு துண்டு அர்த்தமற்றது. கட்டமைப்பு சார்ந்த சங்கிங் (Structure-aware chunking) அசல் வடிவமைப்பைப் பாதுகாக்கிறது. தலைப்பு வரிசைமுறையை (heading hierarchy) பகுப்பாய்வு செய்யுங்கள். முடிந்தவரை அட்டவணைகளை அப்படியே வைத்திருங்கள். ஒரே H2 அல்லது H3 தலைப்பின் கீழ் உள்ள பத்தி எல்லைகளில் (paragraph boundaries) பிரியுங்கள். புல்லட் பாயிண்டுகள் போதுமான அளவு சிறியதாக இருந்தால் அவற்றை ஒரே சங்கிங்கிற்குள் வைத்திருங்கள். இலக்கு சமமான அளவுள்ள தொகுதிகளை உருவாக்குவது அல்ல; மாறாக அர்த்தமுள்ள ஒருங்கிணைந்த அலகுகளை (coherent units of meaning) உருவாக்குவதே ஆகும்.
4. புத்துணர்ச்சிப் பிரச்சனை (The Freshness Problem)
ஒரு உள் விக்கியின் (internal wiki) நிலையான ஸ்னாப்ஷாட் என்பது எளிமையானது. நேரடி இணையத்திலிருந்து தொடர்ந்து தரவுகளை உள்வாங்குவது கடினம். ஒரு பக்கம் கடைசியாக எப்போது சேகரிக்கப்பட்டது, அதன் பிறகு அதில் மாற்றம் ஏற்பட்டுள்ளதா மற்றும் அந்தத் தகவல் எவ்வளவு காலம் செல்லுபடியாகும் என்பதை நீங்கள் தெரிந்து கொள்ள வேண்டும். காலாவதியான அல்லது பழைய தரவு (Stale data) என்பது எப்போதும் ஒரு பழைய தேதியைக் குறிப்பதல்ல. சில நேரங்களில் ஒரு பக்கம் தனது உரையை மாற்றியமைக்கும் ஆனால் அதே URL-ஐத் தக்கவைக்கும், எனவே உள்ளடக்க ஹாஷிங் (content hashing) இல்லாமல் உங்கள் அமைப்பு அதை ஒருபோதும் கவனிக்காது. மூலத்தின் மாறுபாட்டுத் தன்மையைப் (source volatility) பொறுத்து தெளிவான புதுப்பித்தல் விதிகளை உருவாக்குங்கள். ஒரு நிதித் தரவுத் தொடருக்கு (financial data feed) ஒவ்வொரு மணிநேரமும் சரிபார்ப்பு தேவைப்படலாம். ஒரு நிறுவனத்தின் 'About' பக்கத்திற்கு காலாண்டு சரிபார்ப்பு தேவைப்படலாம். முத்திரைகளை (timestamps) பதிவு செய்து, காலாவதி வரம்புகளை (time-to-live boundaries) நிர்ணயிக்கவும், குறிப்பாக உங்கள் டொமைன் ஒழுங்குமுறை அல்லது பாதுகாப்பு சார்ந்த வழிகாட்டுதல்களை உள்ளடக்கியதாக இருந்தால், அங்கு பழைய உண்மைகள் உண்மையான பாதிப்பை ஏற்படுத்தக்கூடும்.
5. நகல் மாசுபாடு (Duplicate Pollution)
இணையதளங்கள் மீண்டும் மீண்டும் வரும் தகவல்களால் நிறைந்திருக்கின்றன. அதே தயாரிப்பு விளக்கம் வகைப்பக்கத்திலும் (category page), தயாரிப்புப் பக்கத்திலும் மற்றும் விளம்பரப் பக்கத்திலும் தோன்றும். அதே செய்தி வெளியீடு /news/, /press/, மற்றும் /blog/ ஆகியவற்றின் கீழ் இருக்கும். வெக்டர் தேடல் (Vector search) தானாகவே நகல்களை நீக்காது. உங்கள் தரவுத்தளத்தில் பத்து கிட்டத்தட்ட ஒரே மாதிரியான துண்டுகள் (chunks) இருந்தால், அவை உங்கள் top-k மீட்டெடுப்பில் (retrieval) பல்வேறு மற்றும் பொருத்தமான முடிவுகளைத் தள்ளிவிடக்கூடும். எம்பெடிங் செய்வதற்கு முன் அதிகாரப்பூர்வமான கண்காணிப்பு (canonical tracking) அல்லது உள்ளடக்க நகல் நீக்கம் (content deduplication) தேவை. இரண்டு துண்டுகள் ஒரே விஷயத்தைச் சொன்னால், அதிகாரப்பூர்வமான மூலத்தை மட்டும் வைத்துக்கொண்டு மற்ற நகல்களை நீக்கிவிடவும். உங்கள் மீட்டெடுப்பிற்கு (retriever) வரையறுக்கப்பட்ட இடங்களே உள்ளன. அவற்றை வீணாக்காதீர்கள்.
6. விடுபட்ட மெட்டாடேட்டா (Missing Metadata)
மெட்டாடேட்டா இல்லாத ஒரு வெக்டர் தரவுத்தளம் என்பது சூழல் பற்றிய நினைவகம் இல்லாத ஒரு அடர்த்தியான உரைத் தேடல் இயந்திரம் (text search engine) போன்றது. புத்திசாலித்தனமான மீட்டெடுப்பு என்பது வெறும் எம்பெடிங்ஸால் (embeddings) வழங்க முடியாத வடிகட்டுதல் (filtering) மற்றும் தரவரிசை (ranking) சிக்னல்களைச் சார்ந்துள்ளது. மூல URL, சேகரித்த தேதி, ஆவண வகை மற்றும் பதிப்பு எண்ணைச் சேமிக்கவும். நீங்கள் API ஆவணங்களை உள்வாங்குகிறீர்கள் என்றால், பதிப்பு மேலாண்மை (versioning) அவசியமானது. அது இல்லையென்றால், ஒரு வினவல் (query) v1 மற்றும் v2 விவரக்குறிப்புகளை ஒரே பதிலுடன் கலந்துவிடக்கூடும். நீங்கள் HR கொள்கைகளை உள்வாங்குகிறீர்கள் என்றால், பிராந்தியம் அல்லது துறையின் அடிப்படையில் டேக் (tagging) செய்வது, முடிவுகள் மாடலைச் சென்றடைவதற்கு முன்பே அவற்றை வடிகட்ட உதவும். மெட்டாடேட்டா ஒரு உரைத் தொகுப்பை ஒரு கியூரேட்டட் அறிவு அமைப்பாக (curated knowledge system) மாற்றுகிறது.
7. ஜாவாஸ்கிரிப்ட் இடைவெளிகள் (JavaScript Gaps)
நவீன தளங்கள் அவற்றின் உள்ளடக்கத்தை முதல் HTML பேலோடிலேயே (payload) வழங்குவதில்லை. அவை ஒரு கட்டமைப்பை (skeleton) அனுப்பி, ஜாவாஸ்கிரிப்ட் அழைப்புகள் மூலம் அதை நிரப்புகின்றன (hydrate). ஒரு அடிப்படை HTTP கோரிக்கை ஒரு லோடிங் ஸ்பின்னரைத் (loading spinner) தவிர வேறொன்றையும் பார்க்காது. உங்கள் குழாயால் (pipeline) ஜாவாஸ்கிரிப்டை இயக்க முடியாவிட்டால், நீங்கள் வெற்றுப் பக்கங்களை அல்லது பகுதித் துண்டுகளை மட்டும் உள்வாங்குவீர்கள், மேலும் ஏதோ தவறு நடப்பதை நீங்கள் ஒருபோதும் உணர மாட்டீர்கள். ஒரு ஹெட்லெஸ் பிரவுசரைப் (headless browser) பயன்படுத்துவது ரெண்டரிங் சிக்கலைத் தீர்க்கும், ஆனால் புதிய சிக்கல்களையும் அறிமுகப்படுத்தும்: அதிக நினைவகப் பயன்பாடு, மெதுவான வேகம் மற்றும் பாட் கண்டெக்ஷன் (bot detection) தடைகள். உங்கள் சமரசங்களைத் (trade-offs) திட்டமிட்டுத் தேர்ந்தெடுங்கள், ஆனால் ஒவ்வொரு மூலத்திற்கும் ஒரு சாதாரண curl போதுமானது என்று
பைப்லைன் டேஷ்போர்டுகளை மட்டும் வைத்து தரவு உள்ளீட்டுத் தன்மையை (ingestion health) அளவிடுவதை நிறுத்துங்கள். வெற்றிகரமாக முடிந்த வேலைகளும் (green jobs) சுத்தமான லாக்ஸ்களும் (clean logs) ஒரு சுத்தமான தரவுத் தொகுப்பை (clean corpus) உறுதி செய்துவிடாது. தரவுத்தளத்தைத் திறந்து, பயனர்கள் மீட்டெடுக்கும் உண்மையான தரவுத் துண்டுகளை (chunks) நேரடியாகப் படியுங்கள். அந்தத் தரவில் பதிப்புரிமை அறிவிப்புகள், சிதறிய அட்டவணைகள் மற்றும் காலாவதியான கொள்கை பக்கங்கள் நிறைந்து காணப்பட்டால், உங்கள் பிரச்சனை LLM அல்ல. முதலில் feed-ஐ சரிசெய்யுங்கள். மற்ற அனைத்தும் குப்பையின் மேல் செய்யப்படும் டியூனிங் (tuning) மட்டுமே.