આ 7 ભૂલો સુધારતા પહેલા મેં RAG ઇન્ફ્રાસ્ટ્રક્ચર પર $500 ખર્ચ્યા
મેં પ્રાઇવેટ ડોક્યુમેન્ટ સર્ચ માટે એક RAG પાઇપલાઇન બનાવી હતી. તેના કમ્પ્યુટિંગમાં મારે $500 અને ડિબગિંગમાં અઠવાડિયાનો સમય ખર્ચવો પડ્યો. પરિણામો ખરાબ હતા. યુઝર્સને ખોટા જવાબો મળતા હતા અને ક્વેરીઝ ધીમી હતી.
મેં પાઇપલાઇનનું ઓડિટ કર્યું. મને 7 ભૂલો મળી. તેને સુધારવાથી બધું જ બદલાઈ ગયું.
- ફિક્સ્ડ ટોકન ચંકિંગ (Fixed Token Chunking) મેં ડોક્યુમેન્ટ્સને 512 ટોકન્સ દ્વારા વિભાજિત કર્યા હતા. આનાથી સંદર્ભ (context) નાશ પામ્યો. API ની સમજૂતી વાક્યની વચ્ચેથી જ કપાઈ જતી હતી. LLM ને ટુકડાઓ મળતા અને તે કચરા જેવા જવાબો આપતું. સુધારો: સેમેન્ટિક ચંકિંગ (semantic chunking) નો ઉપયોગ કરો.
- પેરાગ્રાફ અથવા હેડર્સ જેવા કુદરતી સીમાઓ દ્વારા વિભાજિત કરો.
- પેરેન્ટ-ડોક્યુમેન્ટ રિટ્રાઇવલ (parent-document retrieval) નો ઉપયોગ કરો.
- સર્ચ માટે નાના ચાઇલ્ડ ચંક્સ (child chunks) બનાવો.
- LLM ને આખું પેરેન્ટ ડોક્યુમેન્ટ પરત કરો.
- ચંક્સ વચ્ચે 10-20% ઓવરલેપ ઉમેરો.
- ખરાબ હાઇબ્રિડ સર્ચ વેટ્સ (Bad Hybrid Search Weights) મેં વેક્ટર અને કીવર્ડ સર્ચ માટે 50/50 સ્પ્લિટનો ઉપયોગ કર્યો હતો. ટેકનિકલ ડોક્યુમેન્ટ્સ માટે આ નિષ્ફળ ગયું. ટેકનિકલ યુઝર્સને ચોક્કસ કીવર્ડ મેચની જરૂર હોય છે. સુધારો: ડાયનેમિક વેટ્સ (dynamic weights) નો ઉપયોગ કરો.
- તથ્ય આધારિત ક્વેરીઝ (Factual queries): 35% વેક્ટર, 65% કીવર્ડ.
- સેમેન્ટિક ક્વેરીઝ (Semantic queries): 75% વેક્ટર, 25% કીવર્ડ.
- સામાન્ય ક્વેરીઝ (General queries): 60% વેક્ટર, 40% કીવર્ડ.
- HNSW પેરામીટર્સનું ઓવર-ટ્યુનિંગ (Over-tuning HNSW Parameters) મેં ef_construction ને મહત્તમ (maximum) પર સેટ કર્યું હતું. આનાથી મારો સર્વર ક્રેશ થઈ ગયો. તેણે ઉપલબ્ધ તમામ RAM વાપરી નાખી. સુધારો: યોગ્ય પેરામીટર્સનો ઉપયોગ કરો.
- M ને 8 અને 32 ની વચ્ચે સેટ કરો.
- ef_construction ને 200 પર સેટ કરો.
- ef_search ને 50 પર સેટ કરો. મેમરી વપરાશમાં 70% નો ઘટાડો થયો.
સામાન્ય એમ્બેડિંગ મોડલ્સ (General Embedding Models) મેં Wikipedia પર તાલીમ પામેલા મોડલનો ઉપયોગ કર્યો હતો. મારા ડોક્યુમેન્ટ્સ ટેકનિકલ એન્જિનિયરિંગ રનબુક્સ હતા. મોડલ મારા ડોમેનને સમજી શકતું નહોતું. સુધારો: ટેકનિકલ અથવા કોડ કન્ટેન્ટ માટે ફાઇન-ટ્યુન કરેલા મોડલનો ઉપયોગ કરો.
ક્વેરી રિરાઈટિંગનો અભાવ (No Query Rewriting) યુઝર્સ કુદરતી પ્રશ્નો પૂછે છે. ટેકનિકલ ડોક્યુમેન્ટ્સમાં ઔપચારિક શબ્દોનો ઉપયોગ થાય છે. તેઓ એકબીજા સાથે મેળ ખાતા નથી. સુધારો: ક્વેરીઝને ફરીથી લખવા (rewrite) માટે એક લાઇટવેઇટ LLM સ્ટેપ ઉમેરો.
- યુઝર પૂછે છે: "why is my build slow"
- સિસ્ટમ તેને આ રીતે રિરાઇટ કરે છે: "CI pipeline performance optimization"
- આનાથી રિકોલ (recall) માં 40% નો સુધારો થયો.
બિનજરૂરી પરિણામો (Redundant Results) ટોપ-10 ચંક્સ રિટ્રાઇવ કરવાથી ઘણીવાર એક જ પેરાગ્રાફ ત્રણ વાર મળતો હતો. LLM પોતાની વાતનું પુનરાવર્તન કરતું હતું. સુધારો: પરિણામોમાં વિવિધતા સુનિશ્ચિત કરવા માટે Maximal Marginal Relevance (MMR) નો ઉપયોગ કરો.
ખોટી વસ્તુનું પરીક્ષણ (Testing the Wrong Thing) મેં આખી પાઇપલાઇનનું એકસાથે પરીક્ષણ કર્યું હતું. મને ખબર નહોતી કે સમસ્યા રિટ્રાઇવલમાં હતી કે LLM માં. સુધારો: રિટ્રાઇવલ ઇવેલ્યુએશન (retrieval evaluation) ને અલગ કરો.
- હિટ રેટ (hit rate) ટ્રેક કરો.
- Mean Reciprocal Rank (MRR) ટ્રેક કરો.
- 100 ક્વેરી-ડોક્યુમેન્ટ જોડીઓનો ટેસ્ટ સેટ બનાવો.
સુધારા પછીના પરિણામો:
- જવાબની સુસંગતતા: 45% થી 85%
- લેટન્સી: 3.2s થી 1.8s
- માસિક ખર્ચ: $180 થી $95
સૌ પ્રથમ chunking સુધારો. ત્યારબાદ weights. અને પછી embedding quality.