या ७ चुका सुधारण्यापूर्वी मी RAG इन्फ्रास्ट्रक्चरवर $५०० खर्च केले
मी खाजगी दस्तऐवज शोधण्यासाठी (private document search) एक RAG पाइपलाइन तयार केली. यासाठी संगणकीय संसाधनांवर (compute) $५०० खर्च झाले आणि डीबगिंगसाठी अनेक आठवडे लागले. निकाल खूप खराब होते. वापरकर्त्यांना चुकीची उत्तरे मिळत होती आणि क्वेरी (queries) खूप संथ होत्या.
मी त्या पाइपलाइनचे ऑडिट केले. मला ७ चुका आढळल्या. त्या सुधारल्यामुळे सर्व काही बदलले.
१. टोकन चंकिंग (Token Chunking) सुधारले मी ५१२ टोकन्सने दस्तऐवज विभाजित केले होते. यामुळे संदर्भाचा (context) नाश झाला. एखाद्या API चे स्पष्टीकरण वाक्याच्या मध्यभागीच विभागले जात असे. LLM ला फक्त तुकडे मिळत होते आणि त्यामुळे चुकीची उत्तरे मिळत होती. उपाय: सिमेंटिक चंकिंग (semantic chunking) वापरा.
- परिच्छेद किंवा हेडर्ससारख्या नैसर्गिक सीमांनुसार विभाजित करा.
- पॅरेंट-डॉक्युमेंट रिट्रिव्हल (parent-document retrieval) वापरा.
- शोधण्यासाठी लहान 'चाइल्ड चंक्स' (child chunks) तयार करा.
- LLM ला पूर्ण पॅरेंट डॉक्युमेंट परत करा.
- चंक्समध्ये १०-२०% ओव्हरलॅप (overlap) ठेवा.
२. चुकीचे हायब्रिड सर्च वेट्स (Hybrid Search Weights) मी वेक्टर (vector) आणि कीवर्ड (keyword) सर्चसाठी ५०/५० विभागणी वापरली होती. तांत्रिक दस्तऐवजांसाठी (technical docs) हे अपयशी ठरले. तांत्रिक वापरकर्त्यांना अचूक कीवर्ड मॅचेसची गरज असते. उपाय: डायनॅमिक वेट्स (dynamic weights) वापरा.
- तथ्यात्मक क्वेरी (Factual queries): ३५% वेक्टर, ६५% कीवर्ड.
- सिमेंटिक क्वेरी (Semantic queries): ७५% वेक्टर, २५% कीवर्ड.
- सामान्य क्वेरी (General queries): ६०% वेक्टर, ४०% कीवर्ड.
३. HNSW पॅरामीटर्सचे अति-ट्यूनिंग (Over-tuning)
मी ef_construction जास्तीत जास्त सेट केले होते. यामुळे माझा सर्व्हर क्रॅश झाला. त्याने उपलब्ध असलेली सर्व RAM वापरली.
उपाय: योग्य पॅरामीटर्स वापरा.
Mची व्हॅल्यू ८ ते ३२ दरम्यान ठेवा.ef_construction२०० वर सेट करा.ef_search५० वर सेट करा. मेमरीचा वापर ७०% ने कमी झाला.
४. सामान्य एम्बेडिंग मॉडेल्स (General Embedding Models) मी विकिपीडियावर प्रशिक्षित केलेले मॉडेल वापरले होते. माझे दस्तऐवज तांत्रिक इंजिनिअरिंग रनबुक्स (engineering runbooks) होते. मॉडेलला माझ्या क्षेत्रातील (domain) माहिती नव्हती. उपाय: तांत्रिक किंवा कोड कंटेंटसाठी फाईन-ट्यून (fine-tuned) केलेले मॉडेल वापरा.
५. क्वेरी रीरायटिंगचा (Query Rewriting) अभाव वापरकर्ते नैसर्गिक प्रश्न विचारतात. तांत्रिक दस्तऐवजांमध्ये औपचारिक संज्ञा वापरल्या जातात. त्या एकमेकांशी जुळत नाहीत. उपाय: क्वेरी पुन्हा लिहिण्यासाठी (rewrite) एक हलकी (lightweight) LLM स्टेप जोडा.
- वापरकर्ता विचारतो: "why is my build slow"
- सिस्टम ते असे पुन्हा लिहिते: "CI pipeline performance optimization"
- यामुळे रिकॉल (recall) ४०% ने सुधारला.
६. पुनरावृत्ती होणारे निकाल (Redundant Results) टॉप-१० चंक्स शोधताना अनेकदा तोच परिच्छेद तीन वेळा मिळत असे. LLM स्वतःचीच पुनरावृत्ती करत असे. उपाय: निकालांमध्ये विविधता सुनिश्चित करण्यासाठी Maximal Marginal Relevance (MMR) वापरा.
७. चुकीच्या गोष्टीची चाचणी करणे मी संपूर्ण पाइपलाइनची एकाच वेळी चाचणी केली. समस्या रिट्रिव्हलमध्ये (retrieval) होती की LLM मध्ये, हे मला समजत नव्हते. उपाय: रिट्रिव्हल इव्हॅल्युएशन (retrieval evaluation) वेगळे करा.
- हिट रेट (hit rate) ट्रॅक करा.
- Mean Reciprocal Rank (MRR) ट्रॅक करा.
- १०० क्वेरी-दस्तऐवज जोड्यांचा (query-document pairs) एक टेस्ट सेट तयार करा.
सुधारणांनंतरचे निकाल:
- उत्तराची सुसंगतता: 45% ते 85%
- लॅटन्सी: 3.2s ते 1.8s
- मासिक खर्च: $180 ते $95
प्रथम चंकिंग (chunking) सुधारा. त्यानंतर वेट्स (weights). त्यानंतर एम्बेडिंगची गुणवत्ता (embedding quality).