7 തെറ്റുകൾ വരുത്തുന്നതിന് മുമ്പ് ഞാൻ RAG ഇൻഫ്രാസ്ട്രക്ചറിനായി $500 ചിലവാക്കി

സ്വകാര്യ ഡോക്യുമെന്റുകൾ തിരയുന്നതിനായി ഞാൻ ഒരു RAG പൈപ്പ്‌ലൈൻ നിർമ്മിച്ചു. കമ്പ്യൂട്ടിംഗിനായി $500 രൂപയും ഡീബഗ്ഗിംഗിനായി ആഴ്ചകളും എനിക്ക് ചിലവായി. ഫലങ്ങൾ മോശമായിരുന്നു. ഉപയോക്താക്കൾക്ക് പ്രസക്തമല്ലാത്ത ഉത്തരങ്ങൾ ലഭിക്കുകയും ക്വറികൾ (queries) സാവധാനത്തിലാവുകയും ചെയ്തു.

ഞാൻ പൈപ്പ്‌ലൈൻ പരിശോധിക്കുകയും 7 പൊതുവായ തെറ്റുകൾ കണ്ടെത്തുകയും ചെയ്തു. അവ പരിഹരിച്ചത് എല്ലാം മാറ്റിമറിച്ചു.

  1. ഫിക്സഡ് ടോക്കൺ ചങ്കിംഗ് (Fixed Token Chunking) ഞാൻ ഡോക്യുമെന്റുകളെ നിശ്ചിത ടോക്കൺ എണ്ണങ്ങൾ ഉപയോഗിച്ച് വിഭജിച്ചു. ഇത് സന്ദർഭത്തിന്റെ (context) വ്യക്തത നശിപ്പിച്ചു. ഒരു വാചകം പകുതിയായി മുറിഞ്ഞുപോയി. LLM-ന് കഷണങ്ങളായ വിവരങ്ങൾ ലഭിക്കുകയും മോശം ഉത്തരങ്ങൾ നൽകുകയും ചെയ്തു.
  • പരിഹാരം: പാരന്റ്-ഡോക്യുമെന്റ് റിട്രീവലോടെയുള്ള സെമാന്റിക് ചങ്കിംഗ് (semantic chunking) ഉപയോഗിക്കുക.
  • ഖണ്ഡികകൾ അല്ലെങ്കിൽ ഹെഡറുകൾ പോലുള്ള സ്വാഭാവിക അതിരുകൾ ഉപയോഗിച്ച് വിഭജിക്കുക.
  • സെർച്ചിനായി ചെറിയ ചൈൽഡ് ചങ്കുകൾ (child chunks) നിർമ്മിക്കുക.
  • ഒരു മാച്ച് ലഭിക്കുമ്പോൾ മുഴുവൻ പാരന്റ് ഡോക്യുമെന്റും LLM-ന് നൽകുക.
  • ചങ്കുകൾക്കിടയിൽ 10-20% ഓവർലാപ്പ് (overlap) നൽകുക.
  1. ഡിഫോൾട്ട് സെർച്ച് വെയ്റ്റുകൾ (Default Search Weights) വെക്റ്റർ (vector), കീവേഡ് (keyword) സെർച്ചിനായി ഞാൻ 50/50 വിഭജനം ഉപയോഗിച്ചു. സാങ്കേതിക ഡോക്യുമെന്റുകളിൽ കൃത്യമായ കീവേഡുകൾക്കാണ് കൂടുതൽ പ്രാധാന്യം.
  • പരിഹാരം: ഡൈനാമിക് വെയ്റ്റുകൾ ഉപയോഗിക്കുക.
  • വസ്തുതാപരമായ ക്വറികൾ (Factual queries): 35% വെക്റ്റർ, 65% കീവേഡ്.
  • സെമാന്റിക് ക്വറികൾ (Semantic queries): 75% വെക്റ്റർ, 25% കീവേഡ്.
  1. HNSW പാരാമീറ്ററുകൾ അമിതമായി ഒപ്റ്റിമൈസ് ചെയ്യുന്നത് (Over-optimizing HNSW Parameters) ഞാൻ ef_construction പരമാവധി മൂല്യത്തിലേക്ക് സെറ്റ് ചെയ്തു. വലിയൊരു ഇൻഡക്സിൽ ഇത് എന്റെ സെർവർ ക്രാഷ് ചെയ്യാനും മുഴുവൻ RAM ഉപയോഗിക്കാനും കാരണമായി.
  • പരിഹാരം: അനുയോജ്യമായ HNSW ക്രമീകരണങ്ങൾ ഉപയോഗിക്കുക.
  • M എന്നത് 8-നും 32-നും ഇടയിൽ നിർത്തുക.
  • ef_construction 200 ആയി സെറ്റ് ചെയ്യുക.
  • ef_search 50 ആയി സെറ്റ് ചെയ്യുക.
  1. തെറ്റായ എംബെഡിംഗ് മോഡലുകൾ (Wrong Embedding Models) വെബ് ടെക്സ്റ്റിൽ പരിശീലിപ്പിച്ച ഒരു ജനറൽ മോഡലാണ് ഞാൻ ഉപയോഗിച്ചത്. അത് എന്റെ സാങ്കേതിക എഞ്ചിനീയറിംഗ് ഡോക്യുമെന്റുകൾ മനസ്സിലാക്കിയില്ല.
  • പരിഹാരം: സാങ്കേതികമായതോ കോഡ് ഉള്ളതോ ആയ ഉള്ളടക്കത്തിനായി ഫൈൻ ട്യൂൺ ചെയ്ത (fine-tuned) ഒരു മോഡലിലേക്ക് മാറുക.
  1. നാച്ചുറൽ ലാംഗ്വേജ് മിസ്മാച്ച് (Natural Language Mismatch) ഉപയോക്താക്കൾ "എന്തുകൊണ്ടാണ് എന്റെ ബിൽഡ് സാവധാനത്തിലാകുന്നത്" (why is my build slow) എന്നിങ്ങനെയുള്ള ചോദ്യങ്ങൾ ചോദിക്കുന്നു. എന്നാൽ ഡോക്യുമെന്റേഷനിൽ "CI pipeline optimization" പോലുള്ള പദങ്ങളാണ് ഉപയോഗിക്കുന്നത്. ഇവ തമ്മിൽ യാതൊരു ബന്ധവുമില്ലായിരുന്നു.
  • പരിഹാരം: ഒരു LLM ക്വറി റീറൈറ്റ് (query rewrite) ഘട്ടം ചേർക്കുക.
  • സെർച്ച് ചെയ്യുന്നതിന് മുമ്പ് ഉപയോക്താവിന്റെ ക്വറി സാങ്കേതിക പദങ്ങളിലേക്ക് മാറ്റുക.
  1. അനാവശ്യമായ കോൺടെക്സ്റ്റ് (Redundant Context) ടോപ്പ് 10 ചങ്കുകൾ റിട്രീവ് ചെയ്യുന്നത് പലപ്പോഴും ഒരേ ഖണ്ഡിക മൂന്ന് തവണ ലഭിക്കാൻ കാരണമായി. ഇത് ഹാലൂസിനേഷനുകൾക്ക് (hallucinations) ഇടയാക്കി.
  • പരിഹാരം: ഫലങ്ങളിൽ വൈവിധ്യം ഉറപ്പാക്കാൻ Maximal Marginal Relevance (MMR) ഉപയോഗിക്കുക.
  1. എൻഡ്-ടു-എൻഡ് ഇവാലുവേഷൻ മാത്രം (End-to-End Evaluation Only) ഞാൻ അവസാന ഉത്തരം മാത്രമേ പരിശോധിച്ചിരുന്നുള്ളൂ. പ്രശ്നം റിട്രീവലിലാണോ അതോ LLM-ലാണോ എന്ന് എനിക്ക് അറിയില്ലായിരുന്നു.
  • പരിഹാരം: റിട്രീവൽ പ്രത്യേകം വിലയിരുത്തുക.
  • ഹിറ്റ് റേറ്റ് (hit rate), Mean Reciprocal Rank (MRR) എന്നിവ ട്രാക്ക് ചെയ്യുക.
  • 100 ക്വറി-ഡോക്യുമെന്റ് ജോഡികളുള്ള ഒരു ടെസ്റ്റ് സെറ്റ് നിർമ്മിക്കുക.

പരിഹരിച്ചതിന് ശേഷമുള്ള ഫലങ്ങൾ: • ഉത്തരത്തിന്റെ പ്രസക്തി (Answer relevance): 45% മുതൽ 85% വരെ • ക്വറി ലാറ്റൻസി (Query latency): 3.2s മുതൽ 1.8s വരെ • പ്രതിമാസ ചിലവ്: $180 മുതൽ $95 വരെ

ആദ്യം chunking ശരിയാക്കുക. പിന്നീട് weights. അതിനുശേഷം embedding quality.

നിങ്ങളുടെ ഏറ്റവും വലിയ RAG തലവേദന എന്താണ്? കമന്റുകളിൽ അറിയിക്കുക.

സ്രോതസ്സ്: https://dev.to/kollittle/i-spent-500-on-rag-infrastructure-before-realizing-these-7-mistakes-were-killing-my-results-iph

ആവശ്യമെങ്കിൽ ചേരാവുന്ന ലേണിംഗ് കമ്മ്യൂണിറ്റി: https://t.me/GyaanSetuAi