मोठ्या प्रमाणावर प्रोडक्शन RAG: दररोज १०,०००+ लिस्टिंग्जच्या अनुभवातून मिळालेले धडे
मी एका जॉब बोर्डसाठी RAG पाइपलाइन तयार केली. ती स्टेजिंगमध्ये व्यवस्थित चालली, पण प्रत्यक्ष लोड आल्यावर अडखळू लागली. दररोज हजारो लिस्टिंग्जवर प्रक्रिया करण्यासाठी केवळ एक चांगला vector store असून चालत नाही. सिस्टीम नेमकी कुठे फेल होते, हे तुम्हाला समजून घेणे आवश्यक आहे.
चंकिंग (chunking), एम्बेडिंग्स (embeddings), खर्च आणि ऑब्झर्व्हेबिलिटी (observability) याबद्दलचे माझे अनुभव खालीलप्रमाणे आहेत.
१. तुमच्या चंकिंग स्ट्रॅटेजीचा अंदाज लावू नका
बहुतेक ट्युटोरियल्समध्ये चंकिंगकडे एक साधी सेटिंग म्हणून पाहिले जाते. परंतु प्रोडक्शनमध्ये, तुमची स्ट्रॅटेजी अचूकता आणि खर्च ठरवते.
मी जॉब लिस्टिंगसाठी तीन पद्धतींची चाचणी घेतली:
- Fixed-size chunks: या पद्धती अपयशी ठरल्या. त्यांनी "requirements" आणि "benefits" सारखे विभाग यादृच्छिक (random) ठिकाणी कापले. यामुळे रिट्रिव्हलमध्ये गोंधळ (noisy retrieval) निर्माण होतो.
- Semantic chunking: ही पद्धत चांगली होती पण विसंगत होती. काही चंक्स खूप मोठे होते तर काही खूप लहान.
- Recursive character splitting with overlap: ही पद्धत सर्वात प्रभावी ठरली. मी न्यूलाईन्स (newlines) आणि वाक्यांच्या आधारे विभागणी केली. मी ४०० टोकन साईज आणि ५० टोकन ओव्हरलॅपचा वापर केला. यामुळे दोन चंक्समध्ये विभागली जाणारी वाक्ये एकमेकांशी जोडलेली राहतात.
प्रो टिप: चंकिंग करण्यापूर्वी तुमचा डेटा नॉर्मलाईज (normalize) करा. Greenhouse किंवा Lever सारख्या विविध स्रोतांकडून मिळणारे फॉरमॅट्स वेगवेगळे असतात. मजकूर आधी स्वच्छ (clean) करा जेणेकरून तुमच्या चंकरला (chunker) एक सुसंगत रचना मिळेल.
२. एम्बेडिंग्स: खर्च विरुद्ध अचूकता
मी Ollama द्वारे Llama 3.1 ची तुलना OpenAI text-embedding-3-small सोबत केली. लोकल मॉडेल मोफत होते पण "equity compensation" सारख्या डोमेन-विशिष्ट शब्दांसोबत त्याला संघर्ष करावा लागला. त्यामुळे रिझल्ट्समध्ये गोंधळ निर्माण झाला. OpenAI चा खर्च जास्त होता पण त्याने अचूक मॅचेस दिले. मी OpenAI निवडले कारण खराब रिट्रिव्हलमुळे नंतर होणाऱ्या LLM कॉल्सचा खर्च अधिक वाढू शकतो.
वेळ वाचवण्यासाठी, मी माझ्या विनंत्या बॅच (batch) स्वरूपात पाठवतो. मी एका कॉलमध्ये १०० चंक्सपर्यंत पाठवतो. यामुळे लॅटन्सी (latency) कमी होते आणि पाइपलाइन वेगवान राहते.
३. वेक्टर स्टोअरचा (Vector Store) ट्रेड-ऑफ
प्रोटोटाइपिंगसाठी मी Pinecone वापरले कारण ते सेट करणे सोपे आणि जलद आहे. मात्र, मोठ्या प्रमाणावर वापरताना त्याचा खर्च खूप वाढला.
मी PostgreSQL मधील pgvector कडे वळलो.
- ते सेट करण्यासाठी जास्त मेहनत लागली.
- यामुळे मोठ्या प्रमाणात पैसे वाचले.
- यामुळे ट्रान्झॅक्शनल कन्सिस्टन्सी (transactional consistency) मिळाली. एम्बेडिंग्स आणि जॉब डेटा एकाच डेटाबेसमध्ये असल्याने, तुमच्याकडे माहितीचा एकच मुख्य स्रोत (source of truth) असतो. तुम्हाला दोन वेगवेगळ्या सिस्टीम्स सिंक (sync) करण्याची गरज पडत नाही.
४. LLM खर्च नियंत्रित करणे
प्रत्येक लिस्टिंगला GPT-4o द्वारे स्कोर देणे महागडे आहे. खर्च कमी करण्यासाठी मी तीन डावपेटी वापरल्या:
- OpenAI Batch API: मी स्कोरिंगची कामे रात्रभर प्रोसेस करतो. यामुळे मोठी सवलत मिळते.
- कॅशिंग (Caching): वारंवार येणाऱ्या उमेदवार प्रोफाइल्ससाठी मी रिझल्ट्स कॅश करतो.
- मॉडेल टियरिंग (Model tiering): "Sales Representative" सारख्या सामान्य भूमिकांसाठी मी GPT-4o-mini वापरतो. जिथे अचूकता अत्यंत महत्त्वाची आहे अशा विशिष्ट (niche) भूमिकांसाठीच मी GPT-4o वापरतो.
५. प्रथम ऑब्झर्व्हेबिलिटी (Observability) तयार करा
माझी पाइपलाइन एकदा शांतपणे (silently) फेल झाली. चुकीच्या डेटा (malformed data) मुळे रिकामे चंक्स तयार झाले, जे सिस्टीमने कोणत्याही एररशिवाय वगळले.
मी 'correlation ID' सह स्ट्रक्चर्ड लॉगिंग (structured logging) जोडून ही समस्या सोडवली. यामुळे मला डेटा इनजेशनपासून (ingestion) स्कोरिंगपर्यंत प्रत्येक लिस्टिंगचा मागोवा घेणे शक्य झाले. यामुळे कोणत्या डेटा सोर्समुळे त्रुटी येत आहेत, हे मला शेवटी समजले.
सर्वात मोठा धडा: बहुतेक समस्या AI मुळे नाही, तर विस्कळीत (messy) डेटा मुळे येतात. आधी तुमच्या डेटा प्लंबिंगवर (data plumbing) काम करा.
Optional learning community: https://t.me/GyaanSetuAi