७ चुका करण्यापूर्वी मी RAG इन्फ्रास्ट्रक्चरवर $५०० खर्च केले
मी खाजगी दस्तऐवज शोधण्यासाठी (private document search) एक RAG पाइपलाइन तयार केली. यासाठी संगणकीय संसाधनांवर (compute) $५०० खर्च झाले आणि डीबगिंगसाठी अनेक आठवडे लागले. निकाल खूप खराब होते. वापरकर्त्यांना असंबद्ध उत्तरे मिळत होती आणि क्वेरी (queries) संथ होत्या.
मी पाइपलाइनचे ऑडिट केले आणि ७ सामान्य चुका आढळल्या. त्या सुधारल्यामुळे सर्व काही बदलले.
१. फिक्स्ड टोकन चंकिंग (Fixed Token Chunking) मी ठराविक टोकन संख्येनुसार दस्तऐवज विभाजित केले. यामुळे संदर्भाचा (context) नाश झाला. एखादे वाक्य मधूनच कापले जात असे. LLM ला विखुरलेला डेटा मिळत असे आणि त्यामुळे उत्तरेही निकृष्ट दर्जाची येत असत.
- उपाय: पॅरेंट-डॉक्युमेंट रिट्रिव्हलसह (parent-document retrieval) सिमँटिक चंकिंगचा (semantic chunking) वापर करा.
- परिच्छेद किंवा हेडर्ससारख्या नैसर्गिक सीमांनुसार विभाजित करा.
- शोधण्यासाठी लहान 'चाइल्ड चंक्स' (child chunks) तयार करा.
- मॅच मिळाल्यावर पूर्ण 'पॅरेंट डॉक्युमेंट' LLM ला परत करा.
- चंक्समध्ये १०-२०% ओव्हरलॅप (overlap) ठेवा.
२. डीफॉल्ट सर्च वेट्स (Default Search Weights) मी वेक्टर आणि कीवर्ड सर्चसाठी ५०/५० विभागणी वापरली होती. तांत्रिक दस्तऐवजांसाठी, अचूक कीवर्ड्स अधिक महत्त्वाचे असतात.
- उपाय: डायनॅमिक वेट्सचा (dynamic weights) वापर करा.
- तथ्यात्मक क्वेरीसाठी (Factual queries): ३५% वेक्टर, ६५% कीवर्ड.
- सिमँटिक क्वेरीसाठी (Semantic queries): ७५% वेक्टर, २५% कीवर्ड.
३. HNSW पॅरामीटर्सचे अति-ऑप्टिमायझेशन (Over-optimizing HNSW Parameters)
मी ef_construction ची व्हॅल्यू जास्तीत जास्त सेट केली होती. मोठ्या इंडेक्सवर यामुळे माझा सर्व्हर क्रॅश झाला आणि सर्व RAM वापरली गेली.
- उपाय: योग्य HNSW सेटिंग्ज वापरा.
Mहे ८ ते ३२ च्या दरम्यान ठेवा.ef_construction२०० वर सेट करा.ef_search५० वर सेट करा.
४. चुकीचे एम्बेडिंग मॉडेल्स (Wrong Embedding Models) मी वेब टेक्स्टवर प्रशिक्षित केलेले सामान्य मॉडेल वापरले होते. त्याला माझे तांत्रिक इंजिनिअरिंग दस्तऐवज समजले नाहीत.
- उपाय: तांत्रिक किंवा कोड कंटेंटसाठी फाईन-ट्यून (fine-tuned) केलेल्या मॉडेलकडे वळा.
५. नॅचरल लँग्वेज मिसमॅच (Natural Language Mismatch) वापरकर्ते "माझा बिल्ड संथ का आहे?" (why is my build slow) असे प्रश्न विचारतात. परंतु दस्तऐवजात "CI pipeline optimization" सारखे शब्द वापरले जातात. या दोन्हीमध्ये कोणताही संबंध नव्हता.
- उपाय: LLM क्वेरी रीराईट (query rewrite) स्टेप जोडा.
- शोधण्यापूर्वी वापरकर्त्याची क्वेरी तांत्रिक शब्दांमध्ये पुन्हा लिहा.
६. अनावश्यक संदर्भ (Redundant Context) टॉप १० चंक्स मिळवण्याचा अर्थ अनेकदा तोच परिच्छेद तीन वेळा मिळवणे असा होत असे. यामुळे 'हॅलुसिनेशन्स' (hallucinations) होत होते.
- उपाय: निकालांमध्ये विविधता सुनिश्चित करण्यासाठी Maximal Marginal Relevance (MMR) वापरा.
७. फक्त एंड-टू-एंड इव्हॅल्युएशन (End-to-End Evaluation Only) मी फक्त अंतिम उत्तराची तपासणी केली. समस्या रिट्रिव्हलमध्ये (retrieval) होती की LLM मध्ये, हे मला समजले नाही.
- उपाय: रिट्रिव्हलचे स्वतंत्रपणे मूल्यांकन करा.
- हिट रेट (hit rate) आणि Mean Reciprocal Rank (MRR) ट्रॅक करा.
- १०० क्वेरी-डॉक्युमेंट जोड्यांचा एक टेस्ट सेट तयार करा.
सुधारणांनंतरचे निकाल: • उत्तराची सुसंगतता (Answer relevance): ४५% ते ८५% • क्वेरी लॅटन्सी (Query latency): ३.२s ते १.८s • मासिक खर्च: $१८० ते $९५
आधी chunking ठीक करा. त्यानंतर weights. आणि मग embedding quality.
तुमची सर्वात मोठी RAG समस्या कोणती आहे? मला कमेंट्समध्ये सांगा.
ऐच्छिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi