यूक्रेन का सबसे बड़ा कोर्ट डेटाबेस कैसे वेक्टराइज हुआ: 33.7M फैसले, एक वेक्टर DB

कल्पना कीजिए कि अगर कोई वकील सामान्य अंग्रेजी में सवाल टाइप कर सके और हजारों कीवर्ड परिणामों में उलझने के बजाय, सटीक महत्वपूर्ण अनुच्छेदों के साथ तुरंत पांच सबसे प्रासंगिक अदालती फैसले प्राप्त कर सके — सेमैटिक सर्च यही वादा करता है। लेकिन 33.7 मिलियन अदालती फैसलों के लिए इसे साकार करना एक बिल्कुल अलग चुनौती है।

EDRSR — यूनिफाइड स्टेट रजिस्टर ऑफ कोर्ट डिसीजन्स — ने यूक्रेन का संपूर्ण न्यायिक रिकॉर्ड जनता के लिए खोल दिया है। अब एक टीम उस पूरे टेक्स्ट को वास्तव में खोजयोग्य बनाने के लिए काम कर रही है।

यह अभी क्यों मायने रखता है

2026 में, यूक्रेन में अदालती फैसले सार्वजनिक डेटा हैं, लेकिन फिर भी उन्हें प्रभावी ढंग से खोजना कठिन बना हुआ है। किसी विशिष्ट मुद्दे पर नजीर खोजने वाले वकील को अनाड़ी कीवर्ड सर्च का उपयोग करना पड़ता था, जिससे हजारों अप्रासंगिक परिणाम आते थे। सिस्टम यह नहीं समझता था अर्थ — यह बस उन दस्तावेज़ों को ढूंढता था जिनमें आपके द्वारा टाइप किए गए शब्द शामिल थे। वेक्टर एम्बेडिंग्स द्वारा संचालित सेमैटिक सर्च के साथ, वकील पूछ सकते हैं कि वे वास्तव में क्या जानना चाहते हैं: "Is there case law on recovering bank prepayment fees?" सिस्टम पांच सबसे प्रासंगिक फैसलों को ढूंढता है, मुख्य अनुच्छेदों को निकालता है, और दिखाता है कि अदालतों ने इसके माध्यम से कैसे तर्क दिया।

लेकिन इससे पहले कि आप सेमैटिक सर्च कर सकें, आपको टेक्स्ट को वेक्टराइज करना होगा। और यूक्रेन का कोर्ट सिस्टम कोई छोटी समस्या नहीं है।

पैमाना

रजिस्टर में 2006 तक के फैसले शामिल हैं। इसका विवरण:

• सिविल मामले (CPC): 33.7M दस्तावेज़ — सबसे बड़ी श्रेणी
• आपराधिक मामले (CrPC): 12M+
• प्रशासनिक मामले (CAS): 14M+
• वाणिज्यिक मामले (CC): 6M+
• छोटे अपराध (CUaP): 6M+

अब तक, Qdrant वेक्टर डेटाबेस में 44M+ वेक्टर्स हैं। सिविल मामलों का 42% काम पूरा हो चुका है (33.7M में से 14.3M प्रोसेस किए गए)। एक बार जब सिविल वर्ग समाप्त हो जाता है, तो संग्रह में लगभग 63M+ वेक्टर्स होंगे — एक विशिष्ट RAG प्रोजेक्ट की तुलना में दो परिमाण क्रम बड़ा, जिसमें 100K से 1M वेक्टर्स हो सकते हैं।

इतने सारे दस्तावेज़ों को प्रोसेस करने का मतलब एक ऐसी पाइपलाइन बनाना था जो बीच रास्ते में क्रैश न हो।

तकनीकी स्टैक

टीम ने प्रामाणिक, व्यावहारिक विकल्पों को चुना:

एम्बेडिंग मॉडल: Voyage AI का voyage-3.5, जो 1024-आयामी वेक्टर्स आउटपुट करता है। उन्होंने Voyage 3 Large और OpenAI के text-embedding-3-large का परीक्षण किया लेकिन पाया कि कानूनी टेक्स्ट पर गुणवत्ता में वृद्धि लागत के अंतर को उचित नहीं ठहराती है। Voyage 3 Large तीन गुना अधिक महंगा है।

वेक्टर डेटाबेस: Qdrant v1.17, एक समर्पित Amazon EC2 इंस्टेंस (r6a.xlarge: 4 CPU, 32 GB RAM, 2 TB gp3 स्टोरेज) पर Docker में स्व-होस्टेड। उन्होंने इसे अपना खुद का इंस्टेंस दिया क्योंकि HNSW इंडेक्सिंग के साथ 44M+ पॉइंट्स प्रोडक्शन डेटाबेस की मेमोरी समाप्त कर रहे थे और चैट सेवा को पूरी तरह से ब्लॉक कर रहे थे।

सोर्स ऑफ ट्रुथ: PostgreSQL 15, जिसमें फैसले की तारीख के आधार पर टेबल विभाजित हैं। पूरे कोर्ट टेक्स्ट एक टेबल में रहते हैं, मेटाडेटा दूसरी में। सभी विभाजनों में एक JOIN 30M+ पंक्तियों को छूता है, इसलिए पाइपलाइन एक बार में एक वर्ष को प्रोसेस करती है।

पाइपलाइन रनटाइम: Python 3.11, asyncio, aiohttp। कोई भारी फ्रेमवर्क नहीं — बस Voyage और Qdrant को सीधे HTTP कॉल। पूरी चीज़ एक फ़ाइल में 440 लाइनें है।

उन्होंने काम को कैसे विभाजित किया

अदालती फैसले होते हैं लंबे। एक औसत सिविल फैसला 8,000 से 12,000 अक्षरों का होता है। कुछ 200,000 तक पहुँचते हैं। Voyage प्रति इनपुट 32,000 टोकन तक स्वीकार करता है, लेकिन लंबे संदर्भों पर गुणवत्ता घटती है, और एक लंबा वेक्टर पुनर्प्राप्ति के लिए बेकार है — भाषा मॉडल यह सटीक रूप से चिन्हित नहीं कर सकता कि कौन सा अनुच्छेद प्रासंगिक है।

इसलिए टीम चंक्स बनाती है:

• प्रति चंक अधिकतम 2,048 अक्षर
• पड़ोसी चंक्स के बीच 50-शब्दों का ओवरलैप (सीमाओं पर संदर्भ को बनाए रखने के लिए)
• अर्थगत सुसंगतता बनाए रखने के लिए अनुच्छेद की सीमाओं पर विभाजन

औसतन, एक फैसले से 2.7 चंक्स मिलते हैं। प्रत्येक चंक को Qdrant में एक समग्र ID (doc_id × 1000 + chunk_index) मिलती है, जो एक एकल पेलोड फ़िल्टर को एक फैसले के सभी चंक्स खींचने की अनुमति देती है।

गति और समवर्तीता

Voyage की एक दर सीमा है: प्रति API कुंजी प्रति मिनट 2,000 अनुरोध। टीम दो कुंजियों का उपयोग करती है और उनके बीच राउंड-रॉबिन करती है, जो सैद्धांतिक रूप से 4,000 RPM की सीमा तक पहुँचती है।

वे समवर्तीता को 50 समवर्ती अनुरोधों पर रखते हैं और प्रति सेकंड 63 स्थिर दस्तावेज़ प्रोसेस करते हैं। यह प्रति कुंजी प्रति मिनट लगभग 170 अनुरोध है — सीमा से काफी नीचे। उन्होंने समवर्तीता 70 का प्रयास किया और Python GIL (ग्लोबल इंटरप्रेटर लॉक) दीवार से टकरा गए: प्रक्रिया 13% CPU पर रुक गई, कोई प्रगति नहीं हुई, और कोई त्रुटि नहीं दी। बस हैंग हो गई। वापस 50 पर आ गए और यह सुचारू रूप से चला।

प्रत्येक 100 दस्तावेज़ों पर, वे 500 चंक्स का बैच बनाते हैं और Voyage को भेजते हैं, एम्बेडिंग्स एकत्र करते हैं, Qdrant पॉइंट्स का निर्माण करते हैं, और अपसर्ट करते हैं। त्रुटि होने पर (429 rate-limit, नेटवर्क टाइमआउट), वे जिटर के साथ एक्सपोनेंशियल बैकऑफ का उपयोग करते हैं, अधिकतम 5 पुनः प्रयास।

चेकपॉइंट जिसने हफ़्तों बचाया

33.7M दस्तावेज़ों पर, किसी भी विफलता का अर्थ है घंटों या दिनों के काम का नुकसान। टीम ने एक चेकपॉइंट सिस्टम बनाया: प्रत्येक 1,000 प्रोसेस किए गए दस्तावेज़ों पर, पाइपलाइन अंतिम दस्तावेज़ ID, गिनती, उपयोग किए गए टोकन और टाइमस्टैम्प के साथ एक JSON स्नैपशॉट लिखती है।

रीस्टार्ट होने पर, यह उस चेकपॉइंट को पढ़ता है और WHERE doc_id > last_doc_id से फिर से शुरू होता है। कोई दोहराया काम नहीं, शून्य से कोई रीस्टार्ट नहीं।

इसने उन्हें दो बार बचाया है। एक बार जब PostgreSQL की मेमोरी समाप्त हो गई (नीचे अधिक जानकारी)। एक बार जब Qdrant रीस्टार्ट हुआ और एनवायरनमेंट से अपनी API कुंजी खो दी।

एक प्रोडक्शन घटना: पोस्टग्रेज आउट ऑफ मेमोरी

2.86M दस्तावेज़ों पर, PostgreSQL रिकवरी मोड में चला गया। मूल कारण: एक कॉन्फिग बेमेल।

डेटाबेस को shared_buffers=16GB पर सेट किया गया था, लेकिन कंटेनर मेमोरी सीमा 12GB थी। PostgreSQL ने अपने पास मौजूद से अधिक आवंटित करने का प्रयास किया; OS ने प्रक्रिया को समाप्त कर दिया।

सुधार (PR #1453) ने कंटेनर सीमा को 24GB और shm_size को 16GB तक बढ़ा दिया। रीस्टार्ट करने के बाद, PostgreSQL 4 सेकंड में चालू हो गया और स्थिर रहा।

सबक: PostgreSQL कॉन्फ़िगरेशन पैरामीटर कंटेनर मेमोरी सीमाओं के साथ संरेखित होने चाहिए। सिस्टम पहले लोड स्पाइक तक ठीक चलता है, फिर अचानक विफल हो जाता है।

उन्होंने अपनी देव मशीन पर स्वैप को 8GB से बढ़ाकर 24GB कर दिया क्योंकि भारी Voyage API ट्रैफ़िक Python प्रक्रिया में बहुत सारी अस्थायी वस्तुएं उत्पन्न करता है।

अब तक का बिल

एक सिविल दस्तावेज़ का औसत 2.7 चंक्स × 850 टोकन = 2,300 टोकन है। Voyage की प्रति मिलियन टोकन 6 सेंट की कीमत पर, वह 0.014 सेंट प्रति दस्तावेज़ है — लगभग 138 माइक्रोडॉलर।

अब तक (42% पूर्ण):

• 14.3M दस्तावेज़ प्रोसेस किए गए
• ~$1,980 Voyage API पर खर्च किए गए
• ~63 घंटे का पाइपलाइन रनटाइम

शेष (58% बाकी):

• 19.4M दस्तावेज़
• Voyage लागतों में अनुमानित ~$2,680
• अनुमानित 85 घंटे (~3.5 दिन निरंतर चलने के)

पूरे सिविल वर्ग के लिए कुल लागत: API शुल्क में लगभग $4,660।

समर्पित EC2 इंस्टेंस ऑन-डिमांड लगभग $0.20 प्रति घंटा चलता है — लगभग $145 प्रति माह। प्रोडक्शन पर OOM घटना से उबरने से सस्ता।

तुलना के लिए: OpenAI के text-embedding-3-large पर समान बजट केवल एक चौथाई वॉल्यूम को वेक्टराइज करेगा। इस पैमाने पर, Voyage वित्तीय रूप से तर्कसंगत है।

यह क्या सक्षम बनाता है

एक बार जब पाइपलाइन समाप्त हो जाती है, तो संग्रह में सभी सिविल मामलों में 63M+ वेक्टर्स होंगे। एक वकील प्राकृतिक भाषा में प्रश्न टाइप करता है — "case law on voiding a sale contract due to seller incapacity" — और सिस्टम EDRSR के लिंक और मुख्य अनुच्छेद अंशों के साथ सही क्षेत्राधिकार से सबसे प्रासंगिक फैसलों को सामने लाता है।

यह संपूर्ण यूक्रेनी सिविल कोर्ट सिस्टम के लिए सेमैटिक सर्च है।

निष्कर्ष

33.7M कोर्ट फैसलों को वेक्टराइज करना कोई छोटी इंजीनियरिंग समस्या नहीं है। इसके लिए लागत-गुणवत्ता संतुलन के लिए सही एम्बेडिंग मॉडल चुनने, प्रोडक्शन को बाधित होने से बचाने के लिए अपने वेक्टर डेटाबेस को अलग करने, GIL डेडलॉक से बचने के लिए समवर्तीता को सावधानीपूर्वक प्रबंधित करने और 100+ घंटे की पाइपलाइन में फॉल्ट टॉलरेंस का निर्माण करने की आवश्यकता होती है। यूक्रेन का न्यायिक रिकॉर्ड अब खोजयोग्य ज्ञान आधार में परिवर्तित किया जा रहा है।

गुण

• पूर्ण-पाठ पर सेमैटिक सर्च। वकीलों को उत्तर मिलते हैं, कीवर्ड हिट नहीं।
• पैमाने पर लागत-कुशल। Voyage AI इस वॉल्यूम के लिए विकल्प की तुलना में 4 गुना सस्ता था।
• फॉल्ट-टॉलरेंट डिज़ाइन। चेकपॉइंट्स पाइपलाइन को बिना दोबारा चलाए विफलताओं से बचाते हैं।
• व्यावहारिक इंफ्रास्ट्रक्चर। एक अलग कंटेनर में Qdrant, सही मेमोरी सीमाओं के साथ PostgreSQL — डिज़ाइन निर्णय जो प्रोडक्शन की रक्षा करते हैं।
• दस्तावेज़ित घटना। Postgres OOM विफलता कॉन्फ़िगरेशन संरेखण के बारे में एक स्पष्ट सबक बन गई।

दोष

• लंबी पाइपलाइन अवधि। 85+ घंटे शेष होने का मतलब है निरंतर संचालन के हफ़्ते; चेकपॉइंट्स के बावजूद इंफ्रास्ट्रक्चर अभी भी बीच में विफल हो सकता है।
• सामान्य से दो परिमाण क्रम बड़ा। 63M+ वेक्टर्स अप्रमाणित क्षेत्र है; स्केलिंग के जोखिम बने हुए हैं।
• समर्पित हार्डवेयर लागत। r6a.xlarge इंस्टेंस आवश्यक है लेकिन जारी परिचालन खर्च जोड़ता है।
• भाषा मॉडल निर्भरता। गुणवत्ता एम्बेडिंग मॉडल पर निर्भर करती है; यदि Voyage मूल्य निर्धारण या सेवा बदलता है, तो गणना बदल जाती है।
• क्वेरी विलंबता का कोई उल्लेख नहीं। लेख में इस बात पर चर्चा नहीं की गई है कि 63M वेक्टर्स पर एक सेमैटिक सर्च वास्तव में कितनी तेज़ी से निष्पादित होता है।

सावधानी

यह लेख शैक्षणिक है और स्रोत सामग्री में बताई गई वास्तविक परियोजना का वर्णन करता है। किसी भी कार्यान्वयन को वर्तमान Voyage मूल्य निर्धारण के साथ लागत के आंकड़ों को सत्यापित करना चाहिए, अपने स्वयं के डेटा के साथ अपने स्वयं के वातावरण में PostgreSQL कॉन्फ़िगरेशन पैरामीटर का परीक्षण करना चाहिए, और समवर्तीता सेटिंग्स (यहाँ काम करने वाले 50 समवर्ती अनुरोध सभी प्रणालियों के लिए उपयुक्त नहीं हो सकते हैं) को मान्य करना चाहिए। Postgres shared_buffers मान आपकी वास्तविक कंटेनर मेमोरी से मेल खाना चाहिए। किसी भी विशिष्ट संख्या या दृष्टिकोण पर भरोसा करने से पहले, मूल स्रोत और अपने स्वयं के इंफ्रास्ट्रक्चर से परामर्श लें।

अक्सर पूछे जाने वाले प्रश्न

• EDRSR क्या है और यूक्रेन सभी अदालती फैसलों को जनता के लिए क्यों खोलता है?
• वेक्टर एम्बेडिंग्स कैसे काम करती हैं और वे कानूनी दस्तावेज़ों के लिए कीवर्ड सर्च से बेहतर क्यों हैं?
• टीम ने Pinecone या Milvus जैसे अन्य वेक्टर डेटाबेस के बजाय Qdrant का उपयोग क्यों किया?
• GIL डेडलॉक क्या है और समवर्तीता 70 के कारण पाइपलाइन क्यों हैंग हुई?
• चेकपॉइंट-आधारित फिर से शुरू करना कैसे काम करता है और यह कितना रीस्टार्ट ओवरहेड जोड़ता है?
• कंटेनर मेमोरी सीमाओं के साथ PostgreSQL कॉन्फ़िगरेशन संरेखण इतना महत्वपूर्ण क्यों है?
• 33.7M दस्तावेज़ों पर Voyage AI और OpenAI एम्बेडिंग्स के बीच लागत का क्या अंतर है?
• 63M+ वेक्टर संग्रह पर एक सेमैटिक सर्च क्वेरी को निष्पादित करने में कितना समय लगता है?

टैग

#vectorsearch #qdrant #voyageai #legaltech #ukraine #semanticsearch #ragapplications #scalinginfrastructure