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

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

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

  1. ഫിക്സഡ് ടോക്കൺ ചങ്കിംഗ് (Fixed Token Chunking) ഞാൻ ഡോക്യുമെന്റുകളെ 512 ടോക്കണുകളായി വിഭജിച്ചു. ഇത് സന്ദർഭത്തിന്റെ (context) വ്യക്തത നശിപ്പിച്ചു. ഒരു API വിശദീകരണം വാചകത്തിന്റെ പകുതിയിൽ വെച്ച് മുറിഞ്ഞുപോയി. LLM കഷണങ്ങൾ മാത്രമാണ് ലഭിച്ചതുള്ളൂ, അതിനാൽ അർത്ഥശൂന്യമായ ഉത്തരങ്ങളാണ് നൽകിയത്. പരിഹാരം: സെമാന്റിക് ചങ്കിംഗ് (semantic chunking) ഉപയോഗിക്കുക.
  • പാരഗ്രാഫുകൾ അല്ലെങ്കിൽ ഹെഡറുകൾ പോലുള്ള സ്വാഭാവികമായ അതിർവരമ്പുകൾ ഉപയോഗിച്ച് വിഭജിക്കുക.
  • പാരന്റ്-ഡോക്യുമെന്റ് റിട്രീവൽ (parent-document retrieval) ഉപയോഗിക്കുക.
  • സെർച്ചിനായി ചെറിയ ചൈൽഡ് ചങ്കുകൾ (child chunks) നിർമ്മിക്കുക.
  • പൂർണ്ണമായ പാരന്റ് ഡോക്യുമെന്റ് LLM-ലേക്ക് നൽകുക.
  • ചങ്കുകൾക്കിടയിൽ 10-20% ഓവർലാപ്പ് (overlap) നൽകുക.
  1. മോശം ഹൈബ്രിഡ് സെർച്ച് വെയ്റ്റുകൾ (Bad Hybrid Search Weights) വെക്റ്റർ (vector), കീവേഡ് (keyword) സെർച്ചിനായി ഞാൻ 50/50 വിഭജനം ഉപയോഗിച്ചു. സാങ്കേതിക ഡോക്യുമെന്റുകളിൽ ഇത് പരാജയപ്പെട്ടു. സാങ്കേതിക ഉപയോക്താക്കൾക്ക് കൃത്യമായ കീവേഡ് മാച്ചുകൾ ആവശ്യമാണ്. പരിഹാരം: ഡൈനാമിക് വെയ്റ്റുകൾ (dynamic weights) ഉപയോഗിക്കുക.
  • വസ്തുതാപരമായ ക്വറികൾ (Factual queries): 35% വെക്റ്റർ, 65% കീവേഡ്.
  • സെമാന്റിക് ക്വറികൾ (Semantic queries): 75% വെക്റ്റർ, 25% കീവേഡ്.
  • പൊതുവായ ക്വറികൾ (General queries): 60% വെക്റ്റർ, 40% കീവേഡ്.
  1. HNSW പാരാമീറ്ററുകൾ അമിതമായി ട്യൂൺ ചെയ്തു (Over-tuning HNSW Parameters) ഞാൻ ef_construction പരമാവധി സെറ്റ് ചെയ്തു. ഇത് എന്റെ സെർവർ ക്രാഷ് ചെയ്യാൻ കാരണമായി. ഇത് ലഭ്യമായ എല്ലാ RAM-ഉം ഉപയോഗിച്ചു. പരിഹാരം: അനുയോജ്യമായ പാരാമീറ്ററുകൾ ഉപയോഗിക്കുക.
  • M 8-നും 32-നും ഇടയിൽ സെറ്റ് ചെയ്യുക.
  • ef_construction 200 ആയി സെറ്റ് ചെയ്യുക.
  • ef_search 50 ആയി സെറ്റ് ചെയ്യുക. മെമ്മറി ഉപയോഗം 70% കുറഞ്ഞു.

  1. ജനറൽ എംബെഡിംഗ് മോഡലുകൾ (General Embedding Models) വികീപീഡിയയിൽ പരിശീലിപ്പിച്ച ഒരു മോഡലാണ് ഞാൻ ഉപയോഗിച്ചത്. എന്നാൽ എന്റെ ഡോക്യുമെന്റുകൾ സാങ്കേതികമായ എഞ്ചിനീയറിംഗ് റൺബുക്കുകൾ (engineering runbooks) ആയിരുന്നു. ആ മോഡലിന് എന്റെ ഡൊമൈൻ മനസ്സിലാക്കാൻ കഴിഞ്ഞില്ല. പരിഹാരം: സാങ്കേതികമായതോ കോഡ് ഉള്ളതോ ആയ ഉള്ളടക്കത്തിനായി ഫൈൻ ട്യൂൺ ചെയ്ത (fine-tuned) ഒരു മോഡൽ ഉപയോഗിക്കുക.

  2. ക്വറി റൈറ്റിംഗ് ഇല്ല (No Query Rewriting) ഉപയോക്താക്കൾ സ്വാഭാവികമായ ചോദ്യങ്ങളാണ് ചോദിക്കുന്നത്. എന്നാൽ സാങ്കേതിക ഡോക്യുമെന്റുകൾ ഔദ്യോഗിക പദങ്ങളാണ് ഉപയോഗിക്കുന്നത്. ഇവ തമ്മിൽ യോജിക്കില്ല. പരിഹാരം: ക്വറികൾ റീറൈറ്റ് (rewrite) ചെയ്യാൻ ഒരു ലൈറ്റ് വെയ്റ്റ് LLM സ്റ്റെപ്പ് ചേർക്കുക.

  • ഉപയോക്താവ് ചോദിക്കുന്നു: "why is my build slow"
  • സിസ്റ്റം റീറൈറ്റ് ചെയ്യുന്നു: "CI pipeline performance optimization"
  • ഇത് റീകോൾ (recall) 40% മെച്ചപ്പെടുത്തി.

  1. ആവർത്തന ഫലങ്ങൾ (Redundant Results) ടോപ്പ്-10 ചങ്കുകൾ റിട്രീവ് ചെയ്യുമ്പോൾ പലപ്പോഴും ഒരേ പാരഗ്രാഫ് തന്നെ മൂന്ന് തവണ ലഭിച്ചു. LLM ഒരേ കാര്യം തന്നെ ആവർത്തിച്ചു പറഞ്ഞു. പരിഹാരം: ഫലങ്ങളിൽ വൈവിധ്യം ഉറപ്പാക്കാൻ Maximal Marginal Relevance (MMR) ഉപയോഗിക്കുക.

  2. തെറ്റായ കാര്യങ്ങൾ പരിശോധിച്ചു (Testing the Wrong Thing) ഞാൻ മുഴുവൻ പൈപ്പ്‌ലൈനും ഒരേസമയം പരിശോധിച്ചു. പ്രശ്നം റിട്രീവലിലാണോ അതോ LLM-ലാണോ എന്ന് എനിക്ക് മനസ്സിലായില്ല. പരിഹാരം: റിട്രീവൽ ഇവാലുവേഷൻ (retrieval evaluation) വേർതിരിക്കുക.

  • ഹിറ്റ് റേറ്റ് (hit rate) ട്രാക്ക് ചെയ്യുക.
  • Mean Reciprocal Rank (MRR) ട്രാക്ക് ചെയ്യുക.
  • 100 ക്വറി-ഡോക്യുമെന്റ് ജോഡികൾ അടങ്ങിയ ഒരു ടെസ്റ്റ് സെറ്റ് നിർമ്മിക്കുക.

തിരുത്തലുകൾക്ക് ശേഷമുള്ള ഫലങ്ങൾ:

  • ഉത്തരത്തിന്റെ പ്രസക്തി: 45% മുതൽ 85% വരെ
  • ലേറ്റൻസി (Latency): 3.2s മുതൽ 1.8s വരെ
  • പ്രതിമാസ ചിലവ്: $180 മുതൽ $95 വരെ

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

ഉറവിടം: https://dev.to/kollittle/i-spent-500-on-rag-infrastructure-before-realizing-these-7-mistakes-were-killing-my-results-iph