ஒரு உறுதியான பதில் இல்லாத பதிலைப் விட மோசமானதாக ஏன் இருக்கலாம்

நீங்கள் நிறுவனத்தின் உள்முறை சாட்போட்டை (internal chatbot) உருவாக்க முடித்தீர்கள். உங்கள் நிறுவனத்திடம் உள்ள அனைத்து HR கொள்கைகள், பொறியியல் விவரக்குறிப்புகள் (engineering spec) மற்றும் பணியாளர் சேர்க்கை ஆவணங்களையும் (onboarding doc) அதற்கு வழங்குகிறீர்கள். ஒரு புதிய ஊழியர் வாடிக்கையாளர் இரவு உணவிற்கான பயணச் செலவு வரம்பு பற்றி கேட்கிறார். சாட்போட் உடனடியாகப் பதிலளிக்கிறது. அது மிகவும் உறுதியாகத் தோன்றுகிறது. அது கூறும் வரம்பு ஒரு நபருக்கு $75.

உண்மையான கொள்கை $50 என்று கூறுகிறது. சாட்போட் அந்தப் பதிலைத் தானாகவே உருவாக்கிக்கொண்டது. அது உங்கள் கோப்புகளைத் திறக்கவே இல்லை. பல ஆண்டுகளுக்கு முன்பு அதன் பயிற்சித் தரவுகளில் (training data) இருந்த வடிவங்களைக் கொண்டு அது வெறும் ஊகமே செய்தது. தனிப்பட்ட ஆவணங்களுடன் நேரடி பெரிய மொழி மாதிரிகளை (raw large language models) இயக்குவதில் உள்ள கசப்பான உண்மை இதுதான். அவற்றுக்கு உங்கள் நிறுவனத்தின் உள்முறை அறிவைப் பற்றிய அணுகல் இல்லை. அவற்றுக்குத் தேவையான உண்மைகள் அவற்றின் பயிற்சி எடைகளுக்கு (training weights) வெளியே இருக்கும்போது, தெரியாது என்று ஒப்புக்கொள்வதற்குப் பதிலாக அவை பொய்யான தகவல்களைத் தயாரிக்கின்றன. நடைமுறைப் பயன்பாட்டில் (production), இது வேடிக்கையாக இருப்பதில்லை, மாறாக ஒரு பொறுப்புத் தடையாக (liability) மாறுகிறது.

Retrieval-Augmented Generation அல்லது RAG சரியாக இதற்காகவே உருவாக்கப்பட்டது. மாதிரியிடம் எல்லாவற்றையும் நினைவில் கொள்ளச் சொல்வதற்குப் பதிலாக, தகவல்களைத் தேடிப் பார்க்க நீங்கள் அதற்கு அனுமதிக்கிறீர்கள்.

ஊகிப்பதிலிருந்து வாசிப்பதிற்கு

ஒரு நேரடி LLM-ஐ, சிறந்த நினைவாற்றல் கொண்ட ஒரு புத்திசாலி சக ஊழியராகக் கருதுங்கள், ஆனால் அவர் நீங்கள் நிறுவனத்தில் சேருவதற்கு முன்பே விலகிச் சென்றுவிட்டார். அவர்களால் சரளமான உரைநடையை எழுத முடியும், தர்க்கரீதியான புதிர்களைத் தீர்க்க முடியும் மற்றும் கருத்துக்களை எளிமையான சொற்களில் விளக்க முடியும். ஆனால் கடந்த காலாண்டின் API மாற்றங்களைப் பற்றி கேட்டால், அவர்கள் நம்பகமானதாகத் தோன்றும் ஏதோ ஒன்றைச் சும்மா உருவாக்கிச் சொல்வார்கள். அவர்களுக்கு வேறு வழி இல்லை.

RAG அந்த ஊழியருக்கு ஒரு கோப்பு அலமாரி (filing cabinet) போன்ற அணுகலை வழங்குகிறது. ஒரு பயனர் கேள்வி கேட்கும்போது, இந்த அமைப்பு அந்த கேள்வியை நேரடியாக மாதிரியிடம் 던க்காது. இது முதலில் தொடர்புடைய ஆவணங்களைப் பெறுகிறது, அவற்றைச் சூழலாக (context) பிராம்ப்ட்டில் (prompt) சேர்க்கிறது, அதன் பின்னரே மாதிரியிடம் அதைப் படித்துப் பதிலளிக்குமாறு கேட்கிறது. மாதிரி உண்மைகளை நினைவுகூருவதிலிருந்து, அதன் முன்னால் இருக்கும் உண்மைகளைப் புரிந்துகொள்வதிற்கு மாறுகிறது.

இந்தச் செயல்முறை இரண்டு பகுதிகளாகப் பிரிக்கப்பட்டுள்ளது: ஆஃப்லைன் (offline) அடிப்படை வேலை மற்றும் ஆன்லைன் (online) பதில்.

நிலை 1: தயாரிப்பு நிலை (Offline)

யாராவது ஒரு கேள்வியைத் தட்டச்சு செய்வதற்கு நீண்ட காலத்திற்கு முன்பே, உங்கள் ஒழுங்கற்ற ஆவணத் தொகுப்பைத் தேடக்கூடிய அறிவுத் தளமாக (searchable knowledge base) மாற்ற வேண்டும். உங்கள் RAG அமைப்பு சிறப்பாகச் செயல்படுமா அல்லது தோல்வியடையும் என்பதை இந்த அடிப்படை வேலைதான் தீர்மானிக்கிறது.

Document loaders உங்கள் தொடக்கப் புள்ளியாகும். இந்த இணைப்பிகள் (connectors) PDF, Notion பணி இடங்கள், SharePoint கோப்புறைகள், வலைப்பக்கங்கள் மற்றும் உள் விக்கி (internal wikis) ஆகியவற்றிலிருந்து மூல உரையைப் பெறுகின்றன. இங்கேதான் நடைமுறைச் சிக்கல்கள் தொடங்குகின்றன. ஒரு லோடர் (loader) ஒரு Word ஆவணத்திலிருந்து சுத்தமான உரையைப் பிரித்தெடுக்கலாம், ஆனால் உரை அடுக்கு (text layer) இல்லாத ஒரு ஸ்கேன் செய்யப்பட்ட PDF-ஐக் கையாளும்போது தடுமாறலாம். லோடர் ஒரு வெற்றுச் சரத்தை (empty string) வழங்கும், உங்கள் தரவுத்தளம் எதையும் சேமிக்காது, மேலும் பயனர் பின்னர் எந்த எச்சரிக்கையும் இன்றி "எனக்குத் தெரியாது" என்ற பதிலைப் பெறுவார். உங்கள் லோடர்கள் உண்மையில் எதைப் பிரித்தெடுத்தன என்பதை எப்போதும் சரிபார்க்கவும். ஒவ்வொரு மூலத்திலிருந்தும் சில ஆவணங்களைச் சோதனை செய்து பார்த்துவிட்டுப் பிறகு அந்தத் தொடரை (pipeline) நம்புங்கள்.

அடுத்து text splitting வருகிறது, இது chunking என்றும் அழைக்கப்படுகிறது. நீங்கள் எண்பது பக்க பாதுகாப்பு கொள்கையை ஒரே தொகுதியாக பிராம்ப்ட்டில் கொடுக்க முடியாது; அது சூழல் வரம்புகளைத் (context limits) தாண்டிச் சென்று, முக்கியமான தகவல்களை இரைச்சலில் (noise) மூழ்கடித்துவிடும். அதற்குப் பதிலாக, ஆவணங்களைச் சிறு துண்டுகளாக (chunks) வெட்டுகிறீர்கள். சரியான அளவைத் தேர்ந்தெடுப்பதே இதில் உள்ள ரகசியம். ஒற்றை வாக்கியங்கள் போன்ற மிகச் சிறிய துண்டுகள் பெரும்பாலும் முக்கியமான சூழலைத் தவறவிடுகின்றன. "அனைத்து கோரிக்கைகளும் மேலாளரால் அங்கீகரிக்கப்பட வேண்டும்" என்று ஒரு துண்டு வாக்கியம் இருந்தால், இந்த விதி சர்வதேசப் பயணங்களுக்கு மட்டுமே பொருந்தும் என்பதை அது குறிப்பிடத் தவறிவிடும். முழு அத்தியாயங்கள் போன்ற மிகப் பெரிய துண்டுகள், embedding-ஐக் குறைத்துத் தேடுதலைக் குழப்பமடையச் செய்யும், ஏனெனில் அவை ஒரே நேரத்தில் பதினைந்து வெவ்வேறு தலைப்புகளைக் கொண்டிருக்கும். நடைமுறையில், பல குழுக்கள் 300 முதல் 500 டோக்கன்கள் (tokens) கொண்ட துண்டுகளுடன் தொடங்குகின்றன, மேலும் வாக்கியங்கள் துண்டிக்கப்படாமல் இருக்க 50-டோக்கன் மேற்பொருந்துதலை (overlap) பயன்படுத்துகின்றன. உங்கள் உள்ளடக்கத்தைப் பொறுத்து இதை மாற்றியமைக்கவும். API ஆவணங்கள் சிறிய துண்டுகளைத் தாங்கும். சட்ட ஒப்பந்தங்களுக்கு நிபந்தனைத் தர்க்கத்தைப் (conditional logic) பாதுகாக்கப் பெரிய துண்டுகள் தேவைப்படலாம்.

துண்டுகளாகப் பிரிக்கப்பட்ட பிறகு, ஒவ்வொரு பகுதியும் ஒரு embedding ஆக மாற்றப்படுகிறது. இதன் பொருள், அந்த உரையை ஒரு மாதிரியின் மூலம் செலுத்தி, அந்தத் துண்டின் பொருளைக் குறிக்கும் எண்களின் பட்டியல் அல்லது ஒரு வெக்டரை (vector) வெளியீடாகப் பெறுவதாகும். ஒத்த கருத்துக்கள் இந்த கணித வெளியில் அருகருகே அமையும். "'401k matching policy' மற்றும் 'retirement contribution rules' ஆகியவை '401k matching policy' மற்றும் 'office printer setup' ஆகியவற்றை விட அருகருகே இருக்கும். இந்த வெக்டர்கள் Pinecone, Weaviate அல்லது Chroma போன்ற திறந்த மூல (open-source) மாற்றுகளில் ஏதேனும் ஒரு vector database-இல் சேமிக்கப்படுகின்றன. வெக்டர் சேமிப்பகம் என்பது வெறும் குப்பைத் தொட்டி அல்ல. இது 'approximate nearest-neighbor search'-க்காக மேம்படுத்தப்பட்ட ஒரு குறியீடு (index) ஆகும், இது மில்லியன் கணக்கான ஆவணங்களுக்கு இடையிலும் மில்லி விநாடிகளில் மிகவும் பொருத்தமான துண்டுகளைக் கண்டறிய உதவுகிறது.

நிலை 2: நேரலைப் பாதை (Online)

ஒரு பயனர் இறுதியாக, "வாடிக்கையாளர் இரவு உணவுகளுக்கான எங்களது பயணச் செலவுத் திரும்பப் பெறுதல் கொள்கை என்ன?" என்று கேட்கும்போது, நேரடித் தரவுப் பாதை (live pipeline) செயல்படத் தொடங்குகிறது.

அந்த