உக்ரைனின் மிகப்பெரிய நீதிமன்றத் தரவுத்தளம் எவ்வாறு Vectorize செய்யப்பட்டது: 33.7M தீர்ப்புகள், ஒரு Vector DB

ஆயிரக்கணக்கான முக்கியச்சொல் (keyword) முடிவுகளை ஆராய்வதற்குப் பதிலாக, ஒரு வழக்கறிஞர் எளிய ஆங்கிலத்தில் ஒரு கேள்வியைத் தட்டச்சு செய்து, மிகவும் தொடர்புடைய ஐந்து நீதிமன்றத் தீர்ப்புகளையும், அதற்குப் பொருத்தமான துல்லியமான பத்திகளையும் உடனடியாகப் பெற முடிந்தால் எப்படி இருக்கும் என்று கற்பனை செய்து பாருங்கள். அதைத்தான் semantic search உறுதியளிக்கிறது. ஆனால் 33.7 மில்லியன் நீதிமன்றத் தீர்ப்புகளுக்கு அதை நடைமுறைப்படுத்துவது முற்றிலும் வேறுபட்ட ஒரு சவாலாகும்.

EDRSR — ஒருங்கிணைக்கப்பட்ட மாநில நீதிமன்றத் தீர்ப்புகளின் பதிவேடு (Unified State Register of Court Decisions) — உக்ரைனின் முழு நீதித்துறை ஆவணத்தையும் பொதுமக்களுக்கு திறந்துவிட்டுள்ளது. இப்போது ஒரு குழு அந்த உரைகள் அனைத்தையும் உண்மையிலேயே தேடக்கூடியதாக மாற்ற உழைத்து வருகிறது.

இது ஏன் இப்போது முக்கியமானது

2026-இல், உக்ரைனில் நீதிமன்றத் தீர்ப்புகள் பொதுத் தரவுகளாக உள்ளன, ஆனால் அவற்றை திறம்படத் தேடுவது கடினமாகவே உள்ளது. ஒரு குறிப்பிட்ட விவகாரத்தில் முந்தைய முன்மாதிரித் தீர்ப்பைத் தேடும் ஒரு வழக்கறிஞர், திறனற்ற keyword search-ஐப் பயன்படுத்த வேண்டியிருந்தது, அது ஆயிரக்கணக்கான தொடர்பற்ற முடிவுகளைத் தந்தது. அந்த அமைப்பு பொருளை (meaning) — புரிந்து கொள்ளவில்லை; நீங்கள் தட்டச்சு செய்த சொற்களைக் கொண்ட ஆவணங்களை மட்டுமே அது கண்டறிந்தது. Vector embeddings மூலம் இயங்கும் semantic search உதவியுடன், வழக்கறிஞர்கள் தாங்கள் உண்மையில் அறிய விரும்புவதைக் கேட்கலாம்: "Is there case law on recovering bank prepayment fees?" இந்த அமைப்பு மிகவும் தொடர்புடைய ஐந்து தீர்ப்புகளைக் கண்டறிந்து, முக்கிய பத்திகளை எடுத்து, நீதிமன்றங்கள் அதை எவ்வாறு பகுப்பாய்வு செய்தன என்பதைக் காட்டுகிறது.

ஆனால் நீங்கள் semantic search செய்வதற்கு முன், உரையை vectorize செய்ய வேண்டும். உக்ரைனின் நீதிமன்ற அமைப்பு சிறிய விஷயம் அல்ல.

அளவு (The Scale)

பதிவேட்டில் 2006 வரை பின்னோக்கிச் செல்லும் தீர்ப்புகள் உள்ளன. அவற்றின் விவரம்:

• சிவில் வழக்குகள் (CPC): 33.7M ஆவணங்கள் — மிகப்பெரிய பிரிவு
• குற்றவியல் வழக்குகள் (CrPC): 12M+
• நிர்வாக வழக்குகள் (CAS): 14M+
• வணிக வழக்குகள் (CC): 6M+
• சிறு குற்றங்கள் (CUaP): 6M+

தற்போதைய நிலவரப்படி, Qdrant vector database 44M+ வெக்டர்களைக் கொண்டுள்ளது. சிவில் வழக்குகள் 42% முடிவடைந்துள்ளன (33.7M-இல் 14.3M செயல்முறைப்படுத்தப்பட்டுள்ளன). சிவில் வழக்குகள் தொகுதி முடிந்ததும், இந்த சேகரிப்பில் தோராயமாக 63M+ வெக்டர்கள் இருக்கும் — இது வழக்கமாக 100K முதல் 1M வரையிலான வெக்டர்களைக் கொண்ட ஒரு சாதாரண RAG திட்டத்தை விட இரு மடங்கு (two orders of magnitude) பெரியதாகும்.

இவ்வளவு அதிகமான ஆவணங்களைச் செயலாக்குவது என்பது பாதியிலேயே முடங்கிவிடாத ஒரு pipeline-ஐ உருவாக்குவதைக் குறிக்கிறது.

தொழில்நுட்ப ஸ்டேக் (The Technical Stack)

குழு நிரூபிக்கப்பட்ட, நடைமுறைத் தேர்வுகளையே பயன்படுத்தியது:

Embedding model: 1024-பரிமாண (1024-dimensional) வெக்டர்களை வெளியிடும் Voyage AI-இன் voyage-3.5. அவர்கள் Voyage 3 Large மற்றும் OpenAI-இன் text-embedding-3-large ஆகியவற்றைப் பரிசோதித்தனர், ஆனால் சட்ட உரைகளில் கிடைத்த தர மேன்மை செலவு வேறுபாட்டை நியாயப்படுத்தவில்லை என்பதைக் கண்டறிந்தனர். Voyage 3 Large மூன்று மடங்கு கூடுதல் செலவு கொண்டது.

Vector database: ஒரு பிரத்யேக Amazon EC2 இன்ஸ்டன்ஸில் (r6a.xlarge: 4 CPU, 32 GB RAM, 2 TB gp3 storage) Docker-இல் சுயமாக ஹோஸ்ட் செய்யப்பட்ட Qdrant v1.17. HNSW இன்டெக்சிங் கொண்ட 44M+ புள்ளிகள் புரொடக்ஷன் தரவுத்தளத்தின் நினைவகத்தை (out of memory) தீர்த்து, சேட் சேவையை முழுமையாக முடக்கியதால், அவர்கள் இதற்குத் தனி இன்ஸ்டன்ஸை வழங்கினர்.

உண்மை மூலம் (Source of truth): தீர்ப்பு அளிக்கப்பட்ட தேதியின்படி அட்டவணைகள் பிரிக்கப்பட்ட (partitioned) PostgreSQL 15. முழு நீதிமன்ற உரைகளும் ஒரு அட்டவணையிலும், மெட்டாடேட்டா மற்றொரு அட்டவணையிலும் உள்ளன. அனைத்து பார்ட்டிஷன்களிலும் ஒரு JOIN செய்யும்போது 30M+ வரிசைகளை அணுக வேண்டி இருப்பதால், இந்த pipeline ஒரு நேரத்தில் ஒரு வருடத்தைச் செயலாக்குகிறது.

Pipeline இயங்குநேரம் (Pipeline runtime): Python 3.11, asyncio, aiohttp. கனரக பிரேம்வொர்க்குகள் எதுவும் இல்லை — Voyage மற்றும் Qdrant-க்கு நேரடி HTTP அழைப்புகள் மட்டுமே. முழு விஷயமும் ஒரே கோப்பில் 440 வரிகள் மட்டுமே.

அவர்கள் வேலையை எவ்வாறு பிரித்தார்கள்

நீதிமன்றத் தீர்ப்புகள் மிக நீளமானவை. ஒரு சராசரி சிவில் தீர்ப்பு 8,000 முதல் 12,000 எழுத்துகள் கொண்டது. சில 200,000 வரை எட்டும். Voyage ஒரு உள்ளீட்டிற்கு 32,000 டோக்கன்கள் வரை ஏற்கிறது, ஆனால் நீண்ட சூழல்களில் தரம் குறைகிறது, மேலும் மீட்டெடுப்பிற்கு ஒரே ஒரு நீண்ட வெக்டர் பயனற்றது — எந்த பத்தி தொடர்புடையது என்பதை மொழி மாதிரியால் துல்லியமாக சுட்டிக்காட்ட முடியாது.

எனவே குழு சங் (chunk) செய்கிறது:

• ஒரு சங்கிற்கு அதிகபட்சம் 2,048 எழுத்துகள்
• அருகிலுள்ள சங்குகளுக்கு இடையே 50-சொற்கள் மேலடுக்கு (எல்லைகளில் சூழலைப் பாதுகாக்க)
• சொற்பொருள் ஒத்திசைவை (semantic coherence) தக்கவைக்க பத்தி எல்லைகளில் பிரிக்கப்படுகிறது

சராசரியாக, ஒரு தீர்ப்பு 2.7 சங்குகளைத் தருகிறது. ஒவ்வொரு சங்கும் Qdrant-இல் ஒரு கூட்டுக் குறியீட்டைப் பெறுகிறது (doc_id × 1000 + chunk_index), இது ஒற்றைப் பேலோட் ஃபில்டர் மூலம் ஒரு தீர்ப்பின் அனைத்து சங்குகளையும் எடுக்க அனுமதிக்கிறது.

வேகம் மற்றும் ஒத்திகையாக்கம் (Speed and Concurrency)

Voyage-க்கு ஒரு வீத வரம்பு (rate limit) உள்ளது: ஒரு API கீக்கு நிமிடத்திற்கு 2,000 கோரிக்கைகள். குழு இரண்டு கீகளைப் பயன்படுத்தி அவற்றுக்கு இடையே சுழற்சி முறையில் (round-robin) இயக்கி, தத்துவார்த்த ரீதியாக 4,000 RPM வரம்பை எட்டுகிறது.

அவர்கள் ஒரே நேரத்தில் 50 கோரிக்கைகள் என்ற அளவைப் பராமரித்து, வினாடிக்கு 63 ஆவணங்கள் என்ற சீரான வேகத்தில் செயலாக்குகிறார்கள். இது ஒரு கீக்கு நிமிடத்திற்கு சுமார் 170 கோரிக்கைகள் ஆகும் — வரம்பை விட மிகவும் குறைவு. அவர்கள் 70 கோரிக்கைகளை முயன்று Python GIL (global interpreter lock) சிக்கலில் சிக்கினர்: செயல்முறை 13% CPU-இல் முடங்கியது, எந்த முன்னேற்றமும் இல்லை, எந்த பிழையும் காட்டவில்லை. அப்படியே நின்றுவிட்டது. மீண்டும் 50-க்குக் குறைத்ததும் சுமுகமாக இயங்கியது.

ஒவ்வொரு 100 ஆவணங்களுக்கும், அவர்கள் 500 சங்குகளைத் தொகுத்து (batch) Voyage-க்கு அனுப்புகிறார்கள், embeddings-ஐச் சேகரிக்கிறார்கள், Qdrant புள்ளிகளை உருவாக்கி upsert செய்கிறார்கள். பிழை ஏற்பட்டால் (429 rate-limit, நெட்வொர்க் டைம்அவுட்), ஜிட்டர் உடன் எக்ஸ்போனென்ஷியல் பேக்ஆஃப் (exponential backoff with jitter) முறையைப் பயன்படுத்தி, அதிகபட்சம் 5 முறை மீண்டும் முயல்கிறார்கள்.

வாரங்களைக் காப்பாற்றிய செக்பாயிண்ட்

33.7M ஆவணங்களில், எந்தவொரு தோல்வியும் மணிநேரங்கள் அல்லது நாட்களின் உழைப்பை இழப்பதாகும். குழு ஒரு செக்பாயிண்ட் அமைப்பை உருவாக்கியது: ஒவ்வொரு 1,000 செயலாக்கப்பட்ட ஆவணங்களுக்கும், pipeline கடைசி ஆவண ID, எண்ணிக்கை, பயன்படுத்தப்பட்ட டோக்கன்கள் மற்றும் நேரமுத்திரையுடன் கூடிய JSON ஸ்னாப்ஷாட்டை எழுதுகிறது.

மீண்டும் தொடங்கும்போது, அது அந்த செக்பாயிண்டைப் படித்து WHERE doc_id > last_doc_id என்பதிலிருந்து தொடர்கிறது. இரட்டிப்பு வேலை இல்லை, பூஜ்ஜியத்திலிருந்து மீண்டும் தொடங்க வேண்டியதில்லை.

இது அவர்களை இரண்டு முறை காப்பாற்றியுள்ளது. ஒருமுறை PostgreSQL நினைவகம் பற்றாக்குறையானபோது (கீழே விரிவாகக் காணலாம்). மற்றொரு முறை Qdrant மீண்டும் தொடங்கப்பட்டு சுற்றுச்சூழல் மாறிகளிலிருந்து (environment) அதன் API கீயை இழந்தபோது.

ஒரு புரொடக்ஷன் சம்பவம்: Postgres நினைவக பற்றாக்குறை (Out of Memory)

2.86M ஆவணங்களில், PostgreSQL மீட்புப் பயன்முறைக்கு (recovery mode) சென்றது. மூலக் காரணம்: ஒரு கான்ஃபிக் தவறான பொருத்தம் (config mismatch).

தரவுத்தளம் shared_buffers=16GB என அமைக்கப்பட்டிருந்தது, ஆனால் கன்டெய்னர் நினைவக வரம்பு 12GB ஆக இருந்தது. PostgreSQL தன்னிடம் இருந்ததை விட அதிகமாக ஒதுக்க முயன்றது; OS அந்த செயல்முறையை நிறுத்தியது (killed).

இதற்கான தீர்வு (PR #1453) கன்டெய்னர் வரம்பை 24GB ஆகவும், shm_size-ஐ 16GB ஆகவும் உயர்த்தியது. மீண்டும் தொடங்கிய பிறகு, PostgreSQL 4 விநாடிகளில் தயாராகி நிலையாக இருந்தது.

கற்றுக்கொண்ட பாடம்: PostgreSQL உள்ளமைவு அளவுருக்கள் (configuration parameters) கன்டெய்னர் நினைவக வரம்புகளுடன் சீரமைக்கப்பட வேண்டும். முதல் லோட் ஸ்பைக் (load spike) வரை கணினி நன்றாக இயங்குகிறது, பின்னர் மோசமாகத் தோற்கிறது.

அவர்கள் தங்களது dev இயந்திரத்தில் swap நினைவகத்தை 8GB-இலிருந்து 24GB ஆக உயர்த்தினர், ஏனெனில் அதிகப்படியான Voyage API போக்குவரத்து Python செயல்முறையில் நிறைய தற்காலிகப் பொருட்களை உருவாக்குகிறது.

இதுவரையிலான கட்டணம்

ஒரு சிவில் ஆவணம் சராசரியாக 2.7 சங்குகள் × 850 டோக்கன்கள் = 2,300 டோக்கன்கள் பெறுகிறது. Voyage-இன் கட்டணம் ஒரு மில்லியன் டோக்கன்களுக்கு 6 சென்ட் என்ற நிலையில், அது ஒரு ஆவணத்திற்கு 0.014 சென்ட் — தோராயமாக 138 மைக்ரோடாலர்கள்.

இதுவரை (42% நிறைவு):

• 14.3M ஆவணங்கள் செயலாக்கப்பட்டன
• ~$1,980 செலவிடப்பட்டது Voyage API-இல்
• ~63 மணிநேர pipeline இயங்குநேரம்

மீதமுள்ளது (58% பாக்கி):

• 19.4M ஆவணங்கள்
• Voyage செலவுகளில் மதிப்பிடப்பட்ட ~$2,680
• மதிப்பிடப்பட்ட 85 மணிநேரம் (~3.5 நாட்கள் தொடர்ச்சியான இயக்கம்)

முழு சிவில் தொகுதிக்கான மொத்த செலவு: API கட்டணத்தில் தோராயமாக $4,660.

பிரத்யேக EC2 இன்ஸ்டன்ஸ் தேவைக்கேற்ப (on-demand) மணிநேரத்திற்கு சுமார் $0.20 செலவாகிறது — தோராயமாக மாதத்திற்கு $145. புரொடக்ஷனில் ஒரு OOM சம்பவத்திலிருந்து மீள்வதை விட இது மலிவானது.

ஒப்பீட்டிற்கு: OpenAI-இன் text-embedding-3-large இல் அதே பட்ஜெட் கால் பகுதியை மட்டுமே vectorize செய்யும். இந்த அளவில், Voyage நிதி ரீதியாக அர்த்தமுள்ளதாக இருக்கிறது.

இது எதைச் சாத்தியமாக்குகிறது

Pipeline முடிந்ததும், இந்தச் சேகரிப்பு அனைத்து சிவில் வழக்குகளிலும் 63M+ வெக்டர்களைக் கொண்டிருக்கும். ஒரு வழக்கறிஞர் இயல்பான மொழி வினவலைத் தட்டச்சு செய்கிறார் — "case law on voiding a sale contract due to seller incapacity" — மேலும் இந்த அமைப்பு சரியான அதிகார வரம்பிலிருந்து மிகவும் தொடர்புடைய தீர்ப்புகளை, முக்கிய பத்திப் பகுதிகள் மற்றும் EDRSR-க்கான இணைப்புகளுடன் வெளிக்கொண்டுவருகிறது.

அதுதான் முழு உக்ரேனிய சிவில் நீதிமன்ற அமைப்பிற்குமான semantic search.

முடிவுரை

33.7M நீதிமன்றத் தீர்ப்புகளை vectorize செய்வது சிறிய பொறியியல் பிரச்சினை அல்ல. அதற்கு செலவு-தர சமரசத்திற்கு சரியான embedding மாதிரியைத் தேர்ந்தெடுப்பது, புரொடக்ஷனைப் பாதிக்காமல் இருக்க உங்கள் vector database-ஐத் தனிமைப்படுத்துவது, GIL டெட்லாக்குகளைத் தவிர்க்க concurrency-ஐக் கவனமாகக் கையாள்வது மற்றும் 100+ மணிநேர pipeline-இல் தவறு சகிப்புத்தன்மையை (fault tolerance) உருவாக்குவது ஆகியவை தேவைப்படுகின்றன. உக்ரைனின் நீதித்துறை பதிவு இப்போது தேடக்கூடிய அறிவுத் தளமாக மாற்றப்பட்டு வருகிறது.

நன்மைகள் (Merits)

• முழு உரையிலும் Semantic search. வழக்கறிஞர்களுக்கு பதில்கள் கிடைக்கும், keyword முடிவுகள் அல்ல.
• பெரிய அளவில் செலவு குறைந்த திறன். இந்த அளவிற்கு Voyage AI மாற்றை விட 4 மடங்கு மலிவானதாக இருந்தது.
• தவறு சகிப்புத்தன்மை (Fault-tolerant) வடிவமைப்பு. செக்பாயிண்டுகள் மறுஇயக்கம் இல்லாமல் பிழைகளிலிருந்து pipeline தப்பிக்க உதவுகின்றன.
• நடைமுறை உள்கட்டமைப்பு. தனி கன்டெய்னரில் Qdrant, சரியான நினைவக எல்லைகளுடன் PostgreSQL — இவை புரொடக்ஷனைப் பாதுகாக்கும் வடிவமைப்பு முடிவுகள்.
• ஆவணப்படுத்தப்பட்ட சம்பவம். Postgres OOM தோல்வி உள்ளமைவு சீரமைப்பு பற்றிய தெளிவான பாடமாக மாறியது.

குறைபாடுகள் (Demerits)

• நீண்ட pipeline கால அளவு. மீதமுள்ள 85+ மணிநேரம் என்பது வாரக்கணக்கிலான தொடர்ச்சியான செயல்பாட்டைக் குறிக்கிறது; செக்பாயிண்டுகள் இருந்தபோதிலும் இயங்கும் வழியில் உள்கட்டமைப்பு இன்னும் தோல்வியடையக்கூடும்.
• வழக்கமானதை விட இரு மடங்கு (Two orders of magnitude) பெரியது. 63M+ வெக்டர்கள் நிரூபிக்கப்படாத பகுதியாகும்; அளவீட்டு (scaling) அபாயங்கள் உள்ளன.
• பிரத்யேக வன்பொருள் செலவு. r6a.xlarge இன்ஸ்டன்ஸ் அவசியம் ஆனால் தொடர்ந்து இயங்குவதற்கான செயல்பாட்டுச் செலவைச் சேர்க்கிறது.
• மொழி மாதிரி சார்ந்திருத்தல். தரம் embedding மாதிரியைப் பொறுத்தது; Voyage விலை அல்லது சேவையை மாற்றினால், கணக்கீடு மாறுகிறது.
• வினவல் தாமதம் (query latency) பற்றிய எந்தக் குறிப்பும் இல்லை. 63M வெக்டர்களில் semantic search உண்மையில் எவ்வளவு வேகமாக இயங்குகிறது என்பதைப் பற்றி கட்டுரை விவாதிக்கவில்லை.

எச்சரிக்கை (Caution)

இக்கட்டுரை கல்வியியல் சார்ந்ததாகும் மற்றும் மூலப்பொருளில் புகாரளிக்கப்பட்டபடி ஒரு உண்மையான திட்டத்தை விவரிக்கிறது. எந்தவொரு செயலாக்கமும் தற்போதைய Voyage விலையுடன் செலவு புள்ளிவிவரங்களைச் சரிபார்க்க வேண்டும், உங்கள் சொந்த தரவுகளுடன் உங்கள் சொந்த சூழலில் PostgreSQL உள்ளமைவு அளவுருக்களைப் பரிசோதிக்க வேண்டும், மேலும் concurrent அமைப்புகளைச் சரிபார்க்க வேண்டும் (இங்கு செயல்பட்ட 50 concurrent கோரிக்கைகள் அனைத்து அமைப்புகளுக்கும் ஏற்றதாக இருக்காது). Postgres shared_buffers மதிப்பு உங்கள் உண்மையான கன்டெய்னர் நினைவகத்துடன் பொருந்த வேண்டும். எந்தவொரு குறிப்பிட்ட எண்கள் அல்லது அணுகுமுறைகளை நம்புவதற்கு முன், அசல் மூலம் மற்றும் உங்கள் சொந்த உள்கட்டமைப்பைக் கலந்தாலோசிக்கவும்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

• EDRSR என்றால் என்ன, உக்ரைன் ஏன் அனைத்து நீதிமன்றத் தீர்ப்புகளையும் மக்களுக்குத் திறந்துவிடுகிறது?
• Vector embeddings எவ்வாறு செயல்படுகின்றன, மேலும் சட்ட ஆவணங்களுக்கு keyword search-ஐ விட அவை ஏன் சிறந்தவை?
• Pinecone அல்லது Milvus போன்ற பிற vector database-களுக்குப் பதிலாக குழு ஏன் Qdrant-ஐப் பயன்படுத்தியது?
• GIL டெட்லாக் என்றால் என்ன, 70 concurrency ஏன் pipeline-ஐ தொங்க வைத்தது?
• செக்பாயிண்ட் அடிப்படையிலான தொடக்கம் (checkpoint-based resume) எவ்வாறு செயல்படுகிறது, அது எவ்வளவு கூடுதல் நேரத்தைச் (restart overhead) சேர்க்கிறது?
• கன்டெய்னர் நினைவக வரம்புகளுடன் PostgreSQL உள்ளமைவு சீரமைப்பு ஏன் மிகவும் முக்கியமானது?
• 33.7M ஆவணங்களில் Voyage AI மற்றும் OpenAI embeddings ஆகியவற்றிற்கு இடையேயான செலவு வேறுபாடு என்ன?
• 63M+ வெக்டர் சேகரிப்பில் ஒரு semantic search வினவலைச் செயல்படுத்த எவ்வளவு நேரம் ஆகும்?

ஹேஷ்டேக்குகள் (Tags)

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