വലിയ തോതിലുള്ള പ്രൊഡക്ഷൻ RAG: ദിവസേന 10,000-ലധികം ലിസ്റ്റിംഗുകളിൽ നിന്നുള്ള പാഠങ്ങൾ
ഞാൻ ഒരു ജോബ് ബോർഡിനായി ഒരു RAG പൈപ്പ്ലൈൻ നിർമ്മിച്ചു. സ്റ്റേജിംഗിൽ ഇത് നന്നായി പ്രവർത്തിച്ചുവെങ്കിലും യഥാർത്ഥ ലോഡ് വന്നപ്പോൾ ബുദ്ധിമുട്ടുകൾ നേരിട്ടു. ദിവസേന ആയിരക്കണക്കിന് ലിസ്റ്റിംഗുകൾ പ്രോസസ്സ് ചെയ്യാൻ ഒരു നല്ല വെക്റ്റർ സ്റ്റോർ (vector store) മാത്രം പോരാ. സിസ്റ്റം എവിടെയാണ് തകരാറിലാകുന്നത് എന്ന് നിങ്ങൾ മനസ്സിലാക്കണം.
ചങ്കിംഗ് (chunking), എംബെഡിംഗുകൾ (embeddings), ചിലവ് (costs), ഒബ്സർവബിലിറ്റി (observability) എന്നിവയെക്കുറിച്ചുള്ള എന്റെ പാഠങ്ങൾ താഴെ നൽകുന്നു.
1. നിങ്ങളുടെ ചങ്കിംഗ് സ്ട്രാറ്റജി ഊഹിച്ചു തീരുമാനിക്കരുത്
മിക്ക ട്യൂട്ടോറിയലുകളും ചങ്കിംഗിനെ ഒരു ലളിതമായ സെറ്റിംഗ് ആയിട്ടാണ് കാണുന്നത്. എന്നാൽ പ്രൊഡക്ഷനിൽ, നിങ്ങളുടെ സ്ട്രാറ്റജി കൃത്യതയെയും (accuracy) ചിലവിനെയും നിർണ്ണയിക്കുന്നു.
ജോബ് ലിസ്റ്റിംഗുകൾക്കായി ഞാൻ മൂന്ന് രീതികൾ പരീക്ഷിച്ചു:
- Fixed-size chunks: ഇവ പരാജയപ്പെട്ടു. "requirements", "benefits" തുടങ്ങിയ വിഭാഗങ്ങളെ ഇവ ക്രമരഹിതമായി വിഭജിച്ചു. ഇത് തെറ്റായ വിവരങ്ങൾ ലഭിക്കാൻ (noisy retrieval) കാരണമായി.
- Semantic chunking: ഇത് മെച്ചപ്പെട്ടതായിരുന്നുവെങ്കിലും സ്ഥിരതയില്ലാത്തതായിരുന്നു. ചില ചങ്കുകൾ വളരെ വലുതും മറ്റു ചിലത് വളരെ ചെറുതുമായിരുന്നു.
- Recursive character splitting with overlap: ഇതാണ് ഏറ്റവും നന്നായി പ്രവർത്തിച്ചത്. ഞാൻ പുതിയ വരികളിലും (newlines) വാക്യങ്ങളിലും (sentences) വിഭജിച്ചു. 400 ടോക്കൺ വലുപ്പവും 50 ടോക്കൺ ഓവർലാപ്പും (overlap) ആണ് ഞാൻ ഉപയോഗിച്ചത്. ഇത് രണ്ട് ചങ്കുകളിലായി വരുന്ന വാക്യങ്ങൾ തമ്മിൽ ബന്ധം നിലനിർത്താൻ സഹായിക്കുന്നു.
പ്രോ ടിപ്പ് (Pro tip): ചങ്കിംഗിന് മുമ്പ് നിങ്ങളുടെ ഡാറ്റ നോർമലൈസ് (normalize) ചെയ്യുക. Greenhouse അല്ലെങ്കിൽ Lever പോലുള്ള വ്യത്യസ്ത സ്രോതസ്സുകൾ വ്യത്യസ്ത ഫോർമാറ്റുകളാണ് നൽകുന്നത്. നിങ്ങളുടെ ചങ്കർക്ക് (chunker) കൃത്യമായ ഘടന ലഭിക്കുന്നതിനായി ആദ്യം ടെക്സ്റ്റ് ക്ലീൻ ചെയ്യുക.
2. എംബെഡിംഗുകൾ: ചിലവും കൃത്യതയും (Cost vs. Accuracy)
Ollama വഴിയുള്ള Llama 3.1-ഉം OpenAI text-embedding-3-small-ഉം ഞാൻ താരതമ്യം ചെയ്തു. ലോക്കൽ മോഡൽ സൗജന്യമായിരുന്നുവെങ്കിലും "equity compensation" പോലുള്ള ഡൊമെയ്ൻ-സ്പെസിഫിക് പദങ്ങൾ കൈകാര്യം ചെയ്യാൻ അതിന് ബുദ്ധിമുട്ടായിരുന്നു. ഇത് തെറ്റായ ഫലങ്ങൾ നൽകി. OpenAI-ക്ക് കൂടുതൽ ചിലവ് ഉണ്ടായെങ്കിലും കൃത്യമായ ഫലങ്ങൾ നൽകി. മോശം റിട്രീവൽ (retrieval) പിന്നീട് LLM കോളുകളിൽ കൂടുതൽ ചിലവ് വരുത്തിവെക്കുന്നതിനാൽ ഞാൻ OpenAI ആണ് തിരഞ്ഞെടുത്തത്.
സമയം ലാഭിക്കാൻ, ഞാൻ റിക്വസ്റ്റുകൾ ബാച്ച് (batch) ചെയ്യുന്നു. ഒരു കോളിൽ തന്നെ 100 ചങ്കുകൾ വരെ ഞാൻ അയക്കുന്നു. ഇത് ലേറ്റൻസി (latency) കുറയ്ക്കുകയും പൈപ്പ്ലൈൻ വേഗത്തിൽ പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുന്നു.
3. വെക്റ്റർ സ്റ്റോർ ട്രേഡ്-ഓഫ് (The Vector Store Trade-off)
പ്രോട്ടോടൈപ്പിംഗിനായി ഞാൻ Pinecone ഉപയോഗിച്ചു, കാരണം അത് സെറ്റ് ചെയ്യാൻ എളുപ്പമാണ്. എന്നാൽ വലിയ തോതിൽ ഉപയോഗിക്കുമ്പോൾ ചിലവ് വളരെ കൂടുതലായി മാറി.
ഞാൻ PostgreSQL-നുള്ള pgvector-ലേക്ക് മാറി.
- ഇത് സെറ്റ് ചെയ്യാൻ കൂടുതൽ അധ്വാനം ആവശ്യമായിരുന്നു.
- ഇത് വലിയ amounts of money ലാഭിച്ചു.
- ഇത് ട്രാൻസാക്ഷണൽ കൺസിസ്റ്റൻസി (transactional consistency) നൽകി.
എംബെഡിംഗുകൾ ജോബ് ഡാറ്റ ഇരിക്കുന്ന അതേ ഡാറ്റാബേസിൽ തന്നെ ആയതിനാൽ, നിങ്ങൾക്ക് ഒരൊറ്റ സോഴ്സ് ഓഫ് ട്രൂത്ത് (source of truth) ലഭിക്കുന്നു. രണ്ട് വ്യത്യസ്ത സിസ്റ്റങ്ങൾ സിങ്ക് (sync) ചെയ്യേണ്ട ആവശ്യമില്ല.
4. LLM ചിലവുകൾ നിയന്ത്രിക്കുക
ഓരോ ലിസ്റ്റിംഗും GPT-4o ഉപയോഗിച്ച് സ്കോർ ചെയ്യുന്നത് ചിലവേറിയതാണ്. ചിലവ് കുറയ്ക്കാൻ ഞാൻ മൂന്ന് തന്ത്രങ്ങൾ ഉപയോഗിച്ചു:
- OpenAI Batch API: സ്കോറിംഗ് ജോലികൾ ഞാൻ രാത്രികാലങ്ങളിൽ പ്രോസസ്സ് ചെയ്യുന്നു. ഇത് വലിയ ഡിസ്കൗണ്ട് നൽകുന്നു.
- Caching: ആവർത്തിച്ചു വരുന്ന കാൻഡിഡേറ്റ് പ്രൊഫൈലുകൾക്കായി ഞാൻ ഫലങ്ങൾ കാഷെ (cache) ചെയ്യുന്നു.
- Model tiering: "Sales Representative" പോലുള്ള സാധാരണ റോളുകൾക്കായി ഞാൻ GPT-4o-mini ഉപയോഗിക്കുന്നു. കൃത്യത വളരെ പ്രധാനപ്പെട്ട നിഷ് (niche) റോളുകൾക്കായി മാത്രം ഞാൻ GPT-4o ഉപയോഗിക്കുന്നു.
5. ആദ്യം ഒബ്സർവബിലിറ്റി (Observability) നിർമ്മിക്കുക
എന്റെ പൈപ്പ്ലൈൻ ഒരിക്കൽ ഒരു പിശക് അറിയിക്കാതെ പരാജയപ്പെട്ടു. തെറ്റായ ഡാറ്റ (malformed data) കാരണം ശൂന്യമായ ചങ്കുകൾ ഉണ്ടാവുകയും, സിസ്റ്റം ഒരു എറർ പോലും കാണിക്കാതെ അവ ഒഴിവാക്കുകയും ചെയ്തു.
ഒരു കോറിലേഷൻ ഐഡി (correlation ID) ഉപയോഗിച്ച് സ്ട്രക്ചേർഡ് ലോഗിംഗ് (structured logging) ചേർത്ത് ഞാൻ ഇത് പരിഹരിച്ചു. ഇത് ഒരു ലിസ്റ്റിംഗിനെ ഇൻജഷൻ (ingestion) മുതൽ സ്കോറിംഗ് വരെ ട്രാസ് (trace) ചെയ്യാൻ എന്നെ അനുവദിച്ചു. ഏത് ഡാറ്റാ സ്രോതസ്സുകളാണ് പരാജയത്തിന് കാരണമാകുന്നത് എന്ന് എനിക്ക് കണ്ടെത്താൻ കഴിഞ്ഞു.
ഏറ്റവും വലിയ പാഠം: മിക്ക പ്രശ്നങ്ങളും വരുന്നത് AI-യിൽ നിന്നല്ല, മറിച്ച് ക്രമരഹിതമായ ഡാറ്റയിൽ നിന്നാണ്. ആദ്യം നിങ്ങളുടെ ഡാറ്റാ പ്ലംബിംഗ് (data plumbing) ശരിയാക്കുക.
Optional learning community: https://t.me/GyaanSetuAi