பெரிய அளவில் இயங்கும் Production RAG: தினமும் 10,000+ பட்டியல்களைக் கையாள்வதில் கிடைத்த பாடங்கள்

நான் ஒரு வேலைவாய்ப்பு இணையதளத்திற்காக (job board) ஒரு RAG pipeline-ஐ உருவாக்கினேன். அது staging நிலையில் நன்றாகச் செயல்பட்டது, ஆனால் உண்மையான சுமையின் (real load) கீழ் திணறியது. தினமும் ஆயிரக்கணக்கான பட்டியல்களைச் செயலாக்குவதற்கு ஒரு சிறந்த vector store மட்டும் போதாது. உங்கள் அமைப்பு எங்கே முறிந்து போகிறது என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும்.

chunking, embeddings, செலவுகள் மற்றும் observability குறித்த எனது பாடங்கள் இதோ.

  1. உங்கள் chunking உத்தியை யூகிக்காதீர்கள்

பெரும்பாலான பயிற்சிகள் (tutorials) chunking-ஐ ஒரு எளிய அமைப்பாகவே கருதுகின்றன. ஆனால் production நிலையில், உங்கள் உத்தியே துல்லியம் மற்றும் செலவைத் தீர்மானிக்கிறது.

வேலைவாய்ப்புப் பட்டியல்களுக்கு நான் மூன்று முறைகளைச் சோதித்தேன்:

  • Fixed-size chunks: இவை தோல்வியடைந்தன. இவை "requirements" மற்றும் "benefits" போன்ற பகுதிகளைத் தன்னிச்சையான புள்ளிகளில் பிரித்தன. இது தேடலில் குழப்பத்தை (noisy retrieval) உருவாக்கியது.
  • Semantic chunking: இது சிறப்பாக இருந்தது ஆனால் நிலையற்றதாக இருந்தது. சில chunks மிக நீளமாகவும், மற்றவை மிகச் சிறியதாகவும் இருந்தன.
  • Recursive character splitting with overlap: இதுவே மிகச்சிறப்பாகச் செயல்பட்டது. நான் புதிய வரிகள் (newlines) மற்றும் வாக்கியங்களின் அடிப்படையில் பிரித்தேன். 50 token overlap உடன் 400 token அளவைப் பயன்படுத்தினேன். இது இரண்டு chunks-களுக்கு இடையில் உள்ள வாக்கியங்கள் இணைந்தே இருப்பதை உறுதி செய்கிறது.

Pro tip: Chunking செய்வதற்கு முன் உங்கள் தரவை (data) சீரமைக்கவும் (Normalize). Greenhouse அல்லது Lever போன்ற பல்வேறு ஆதாரங்கள் வெவ்வேறு வடிவங்களைத் தருகின்றன. உங்கள் chunker ஒரு நிலையான கட்டமைப்பைக் காண முதலில் உரையைச் (text) சுத்தம் செய்யவும்.

  1. Embeddings: செலவு vs. துல்லியம்

நான் Ollama வழியாக Llama 3.1-ஐ OpenAI text-embedding-3-small உடன் ஒப்பிட்டுச் சோதித்தேன். உள்ளூர் மாதிரி (local model) இலவசமானது, ஆனால் "equity compensation" போன்ற துறை சார்ந்த சொற்களைக் கையாள்வதில் திணறியது. இது குழப்பமான முடிவுகளைத் தந்தது. OpenAI அதிக செலவு ஆனால் துல்லியமான பொருத்தங்களை வழங்கியது. மோசமான தேடல் (retrieval) பின்னர் LLM அழைப்புகளில் (calls) அதிக செலவை ஏற்படுத்தும் என்பதால் நான் OpenAI-ஐத் தேர்ந்தெடுத்தேன்.

நேரத்தைச் சேமிக்க, நான் எனது கோரிக்கைகளைத் தொகுப்பாக (batch) அனுப்புகிறேன். ஒரே அழைப்பில் 100 chunks வரை அனுப்புகிறேன். இது தாமதத்தைக் (latency) குறைத்து, pipeline-ஐ வேகமாகவும் வைத்திருக்கிறது.

  1. Vector Store சார்ந்த சமரசங்கள் (Trade-off)

முன்மாதிரி (prototyping) உருவாக்க Pinecone-ஐப் பயன்படுத்தினேன், ஏனெனில் அதை அமைப்பது எளிது. இருப்பினும், பெரிய அளவில் செயல்படும்போது செலவுகள் மிக அதிகமாக உயர்ந்தன.

நான் PostgreSQL-க்குள் pgvector-க்கு மாறினேன்.

  • இதை அமைப்பதற்கு அதிக வேலை இருந்தது.
  • இது பெரும் தொகையைச் சேமித்தது.
  • இது பரிவர்த்தனை நிலைத்தன்மையை (transactional consistency) வழங்கியது. Embeddings மற்றும் வேலைத் தரவு இரண்டும் ஒரே தரவுத்தளத்தில் (database) இருப்பதால், உங்களிடம் ஒரே உண்மை ஆதாரம் (source of truth) இருக்கும். இரண்டு வெவ்வேறு அமைப்புகளை நீங்கள் ஒருங்கிணைக்க (sync) வேண்டிய அவசியமில்லை.
  1. LLM செலவுகளைக் கட்டுப்படுத்துதல்

ஒவ்வொரு பட்டியலையும் GPT-4o மூலம் மதிப்பிடுவது (scoring) செலவு மிக்கது. செலவைக் குறைக்க நான் மூன்று உத்திகளைப் பயன்படுத்தினேன்:

  • OpenAI Batch API: நான் மதிப்பிடும் பணிகளை இரவு நேரத்தில் செயலாக்குகிறேன். இது பெரிய அளவில் தள்ளுபடி அளிக்கிறது.
  • Caching: மீண்டும் வரும் விண்ணப்பதாரர்களின் சுயவிவரங்களுக்கான (candidate profiles) முடிவுகளை நான் cache செய்கிறேன்.
  • Model tiering: "Sales Representative" போன்ற பொதுவான பணிகளுக்கு நான் GPT-4o-mini-ஐப் பயன்படுத்துகிறேன். துல்லியம் மிக முக்கியமான சிறப்புப் பணிகளுக்கு (niche roles) மட்டுமே நான் GPT-4o-ஐப் பயன்படுத்துகிறேன்.
  1. முதலில் Observability-ஐ உருவாக்குங்கள்

எனது pipeline ஒருமுறை எந்தத் தவறுச் செய்தியும் காட்டாமல் தோல்வியடைந்தது. தவறான தரவு (malformed data) காலியான chunks-களை உருவாக்கியது, அதை அமைப்பு பிழை ஏதும் காட்டாமல் தவிர்த்துவிட்டது.

ஒரு correlation ID உடன் கட்டமைக்கப்பட்ட பதிவுகளை (structured logging) சேர்ப்பதன் மூலம் இதைச் சரிசெய்தேன். இது ஒரு பட்டியலை உள்ளீடு (ingestion) முதல் மதிப்பீடு (scoring) வரை கண்காணிக்க எனக்கு அனுமதித்தது. எந்தத் தரவு ஆதாரங்கள் தோல்விகளுக்குக் காரணமாகின்றன என்பதை என்னால் இறுதியாகக் காண முடிந்தது.

மிகப்பெரிய பாடம்: பெரும்பாலான சிக்கல்கள் ஒழுங்கற்ற தரவிலிருந்து (messy data) வருகின்றன, AI-யிடமிருந்து அல்ல. முதலில் உங்கள் தரவு கட்டமைப்பைச் (data plumbing) சரிசெய்யுங்கள்.

Source: https://dev.to/abdul___rehman/production-rag-at-scale-lessons-from-processing-10000-listings-daily-22gm

Optional learning community: https://t.me/GyaanSetuAi