ஒரு RAG Pipeline-ஐ ஆரம்பத்திலிருந்து உருவாக்குதல்
SmartQueue-இல் ஒரு AI உதவியாளரைச் சேர்க்க விரும்பினேன்.
SmartQueue என்பது IT ஆதரவு டிக்கெட்டுகளுக்காக நான் Go மொழியில் உருவாக்கிய ஒரு task queue ஆகும். எனக்கு ஒரு பொதுவான AI தேவையில்லை. ஒரு பொதுவான மாடலுக்கு உங்கள் குறிப்பிட்ட கடவுச்சொல் மறுசீரமைப்பு விதிகள் (password reset rules) அல்லது உங்கள் சேவைத் தடங்கல் கையேடுகள் (outage runbooks) பற்றித் தெரியாது.
எனக்கு Retrieval-Augmented Generation (RAG) தேவைப்பட்டது. இது முதலில் உங்கள் ஆவணங்களிலிருந்து உண்மைகளைத் திரட்டுகிறது. பின்னர் அந்த உண்மைகளை மாடலுக்கு ஒரு சூழலாக (context) வழங்குகிறது.
இந்த pipeline-ஐ உருவாக்கும்போது நான் கற்றுக்கொண்டவை இதோ.
வரிசைப்படுத்தலில் ஏற்பட்ட தோல்வி
எனது முதல் பதிப்பில் vector search-க்காக ChromaDB-ஐப் பயன்படுத்தினேன். அது உள்ளூர் கணினியில் (locally) நன்றாக வேலை செய்தது. ஆனால் deployment செய்யும்போது தோல்வியடைந்தது.
நான் அனைத்தையும் Hugging Face Spaces-இல் ஒரு ஒரே ஒரு container-இல் இயக்கினேன். இதில் Redis, ஒரு Go API, workers, ஒரு FastAPI service மற்றும் ChromaDB ஆகியவை அடங்கும். ஐந்து செயல்முறைகள் (processes) வரையறுக்கப்பட்ட memory மற்றும் CPU-க்காகப் போட்டியிட்டன. ChromaDB தொடக்கத்தின் போது போட்டிகளை (startup races) மற்றும் அமைதியான தோல்விகளை (silent failures) ஏற்படுத்தியது.
நான் ஒரு முடிவெடுத்தேன். vector database-ஐ நீக்கிவிட்டு, அதற்குப் பதிலாக ஒரு எளிய BM25 search-ஐப் பயன்படுத்தினேன்.
எளிய தீர்வு
புதிய மாற்றமானது வெறும் 50 வரிகள் கொண்ட Python குறியீடு மட்டுமே. இதில் வெளிப்புற செயல்முறைகள் இல்லை. நெட்வொர்க் அழைப்புகளும் இல்லை. இது memory-இல் உள்ள முக்கியச் சொற்களை (keywords) பொருத்துவதற்கு Okapi BM25 சூத்திரத்தைப் பயன்படுத்துகிறது.
இதில் உள்ள சமரசம் (trade-off) தெளிவானது:
- BM25 துல்லியமான வார்த்தை பொருத்தங்களைச் சார்ந்துள்ளது. இது ஒத்த சொற்களை (synonyms) தவறவிடக்கூடும்.
- 10 குறுகிய IT runbooks-களுக்கு இது ஒரு பிரச்சினையல்ல. பயனர்கள் "VPN" அல்லது "password reset" போன்ற குறிப்பிட்ட சொற்களையே பயன்படுத்துகிறார்கள்.
- இப்போது இந்தச் சேவை ஒவ்வொரு முறையும் நம்பகமான முறையில் தொடங்குகிறது.
அமைப்பைச் சீரமைத்தல்
அமைப்பை நிலையாக வைத்திருக்க நான் பல அமைப்புகளைச் (settings) சீரமைத்தேன்: • பெறப்பட்ட ஆவணங்கள் (k): 4. இது token வரம்புகளைத் தாண்டாமல் போதுமான சூழலை வழங்குகிறது. • Bot temperature: 0.2. சிக்கலைத் தீர்ப்பதற்கு (troubleshooting) படைப்பாற்றல் தேவையில்லை, நேரடியான பதில்களே தேவை. • Classifier temperature: 0.1. இது JSON வெளியீடு கணிக்கக்கூடியதாக இருப்பதை உறுதி செய்கிறது. • Session history: கடைசி 10 உரையாடல்கள் (turns). இது அதிக memory-ஐப் பயன்படுத்தாமல் தொடர்ச்சியை வழங்குகிறது. • Rate limits: நிமிடத்திற்கு 30 கோரிக்கைகள் (requests). இது எனது API ஒதுக்கீட்டைப் (quota) பாதுகாக்கிறது.
சிறந்த வடிவமைப்பு என்பது செயல்பாட்டுத் திறன் குறையும் வடிவமைப்பு
நான் ஒவ்வொரு endpoint-ஐயும் ஒரு non-AI fallback வசதியுடன் உருவாக்கினேன். AI சேவை செயலிழந்தால், அமைப்பு keyword matching அல்லது விதி அடிப்படையிலான தர்க்கத்தைப் (rule-based logic) பயன்படுத்தும். இதனால் அமைப்பு முழுமையாகத் தோல்வியடைவதற்குப் பதிலாக, அதன் செயல்பாட்டுத் திறன் குறையக்கூடும் (degrades).
இது ஒரு சிக்கலான RAG அமைப்பு அல்ல. இதில் re-ranking அல்லது hybrid search இல்லை. இது ஒரு குறிப்பிட்ட அளவிற்காக உருவாக்கப்பட்ட ஒரு சிறிய, புத்திசாலித்தனமான கருவியாகும்.
கற்றுக்கொண்ட பாடங்கள்:
- ஒரு பாடப்புத்தக அமைப்பிற்காக அல்லாமல், உங்கள் கட்டுப்பாடுகளுக்கு ஏற்ப மேம்படுத்தவும்.
- நம்பகத்தன்மை பெரும்பாலும் கோட்பாட்டு ரீதியான துல்லியத்தை விட மேலானது.
- நூற்றுக்கணக்கான ஆவணங்கள் இருக்கும்போது வெக்டர் தேடலைப் (vector search) பயன்படுத்தவும். பத்து ஆவணங்கள் இருக்கும்போது முக்கியச்சொல் தேடலைப் (keyword search) பயன்படுத்தவும்.
விருப்பமான கற்றல் சமூகம்: https://t.me/GyaanSetuAi