ఉక్రెయిన్ యొక్క అతిపెద్ద కోర్టు డేటాబేస్ వెక్టరైజ్ ఎలా చేయబడింది: 33.7M తీర్పులు, ఒక Vector DB

ఒక లాయర్ సాధారణ ఆంగ్ల ప్రశ్నను టైప్ చేసి, వేలాది కీవర్డ్ ఫలితాల్లో వెతకాల్సిన అవసరం లేకుండా — అత్యంత సంబంధితమైన ఐదు కోర్టు తీర్పులను, వాటిలోని కీలకమైన పేరాలతో తక్షణమే పొందే అవకాశం ఉంటే ఊహించండి. సిమాంటిక్ సెర్చ్ అందిస్తున్న వాగ్దానం ఇదే. కానీ 33.7 మిలియన్ల కోర్టు తీర్పులకు దీనిని నిజం చేయడం చాలా పెద్ద సవాలు.

EDRSR — యూనిఫైడ్ స్టేట్ రిజిస్టర్ ఆఫ్ కోర్ట్ డిసిషన్స్ — ఉక్రెయిన్ యొక్క మొత్తం న్యాయ రికార్డును పబ్లిక్‌కు తెరిచింది. ఇప్పుడు ఒక బృందం ఆ వచనమంతటినీ సమర్థవంతంగా శోధించగలిగేలా చేయడానికి పనిచేస్తోంది.

ఇది ఇప్పుడు ఎందుకు ముఖ్యం

2026 నాటికి, ఉక్రెయిన్‌లో కోర్టు తీర్పులు పబ్లిక్ డేటాగా ఉన్నాయి, కానీ వాటిని ప్రభావవంతంగా శోధించడం ఇంకా కష్టంగానే ఉంది. ఒక నిర్దిష్ట అంశంపై మునుపటి తీర్పుల కోసం వెతికే లాయర్ క్లంకీ కీవర్డ్ సెర్చ్‌ను ఉపయోగించాల్సి వచ్చేది, అది వేలాది అనవసర ఫలితాలను తిరిగి ఇచ్చేది. సిస్టమ్ అర్థం చేసుకోలేదు అర్థాన్ని — మీరు టైప్ చేసిన పదాలు ఉన్న డాక్యుమెంట్లను మాత్రమే అది కనుగొనేది. vector embeddings ద్వారా నడిచే సిమాంటిక్ సెర్చ్‌తో, లాయర్లు వారు నిజంగా తెలుసుకోవాలనుకుంటున్న దాన్ని అడగవచ్చు: "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, తీర్పు తేదీల (adjudication date) ద్వారా పార్టిషన్ చేయబడిన టేబుళ్లతో ఉంటుంది. పూర్తి కోర్టు టెక్స్ట్‌లు ఒక టేబుల్‌లో, మెటాడేటా మరొక టేబుల్‌లో ఉంటాయి. అన్ని పార్టిషన్లలో JOIN చేయడం 30M+ రోస్‌ను తాకుతుంది, కాబట్టి పైప్‌లైన్ ఒకసారికి ఒక సంవత్సరాన్ని ప్రాసెస్ చేస్తుంది.

పైప్‌లైన్ రన్‌టైమ్: Python 3.11, asyncio, aiohttp. పెద్ద ఫ్రేమ్‌వర్క్‌లు ఏవీ లేవు — Voyage మరియు Qdrant కి నేరుగా HTTP కాల్స్ మాత్రమే. మొత్తం కోడ్ ఒకే ఫైల్‌లో 440 లైన్లు మాత్రమే.

వారు పనిని ఎలా విభజించారు

కోర్టు తీర్పులు చాలా నిడివిగలవి. ఒక సాధారణ సివిల్ తీర్పు 8,000 నుండి 12,000 క్యారెక్టర్లు ఉంటుంది. కొన్ని 200,000 వరకు చేరుకుంటాయి. Voyage ఇన్‌పుట్‌కు 32,000 టోకెన్ల వరకు అంగీకరిస్తుంది, కానీ పొడవైన కాంటెక్స్ట్‌లపై నాణ్యత తగ్గుతుంది, మరియు ఒక పొడవైన వెక్టర్ సమాచారాన్ని తిరిగి పొందడానికి (retrieval) ఉపయోగపడదు — లాంగ్వేజ్ మోడల్ ఏ పేరా సంబంధితమైనదో ఖచ్చితంగా గుర్తించలేదు.

కాబట్టి బృందం వీటిని చంక్స్ (chunks) గా విభజించింది:

• ప్రతి చంక్‌కు గరిష్టంగా 2,048 క్యారెక్టర్లు
• పక్కపక్క చంక్‌ల మధ్య 50-పదాల ఓవర్‌లాప్ (సరిహద్దుల వద్ద కాంటెక్స్ట్‌ను కాపాడటానికి)
• అర్థవంతమైన అనుసంధానతను (semantic coherence) కాపాడటానికి పేరా సరిహద్దుల వద్ద విభజించడం

సగటున, ఒక తీర్పు నుండి 2.7 చంక్స్ వస్తాయి. ప్రతి చంక్ Qdrant లో ఒక కాంపోజిట్ ID (doc_id × 1000 + chunk_index) పొందుతుంది, ఇది ఒకే పేలోడ్ ఫిల్టర్ ద్వారా ఒక తీర్పుకు సంబంధించిన అన్ని చంక్‌లను పొందటానికి సహాయపడుతుంది.

స్పీడ్ మరియు కాన్కరెన్సీ

Voyage కి రేట్ లిమిట్ ఉంది: ఒక API కీకి నిమిషానికి 2,000 రిక్వెస్ట్‌లు. బృందం రెండు కీలను ఉపయోగించి వాటి మధ్య రౌండ్-రాబిన్ చేస్తుంది, తద్వారా సిద్ధాంతపరంగా 4,000 RPM సీలింగ్‌ను చేరుకుంటుంది.

వారు కాన్కరెన్సీని 50 ప్యారలల్ రిక్వెస్ట్‌ల వద్ద ఉంచి, సెకనుకు నిలకడగా 63 డాక్యుమెంట్లను ప్రాసెస్ చేశారు. అది కీకి నిమిషానికి దాదాపు 170 రిక్వెస్ట్‌లు — పరిమితి కంటే బాగా తక్కువే. వారు కాన్కరెన్సీ 70 ప్రయత్నించారు కానీ Python GIL (global interpreter lock) ఆటంకాన్ని ఎదుర్కొన్నారు: ప్రాసెస్ 13% CPU వద్ద నిలిచిపోయింది, ఎటువంటి ప్రగతి లేదు, ఎర్రర్లు కూడా రాలేదు. ఉత్తిగా హ్యాంగ్ అయింది. మళ్లీ 50 కి తగ్గించడంతో అది సజావుగా సాగింది.

ప్రతి 100 డాక్యుమెంట్లకు, వారు 500 చంక్‌లను బ్యాచ్ చేసి Voyage కి పంపుతారు, ఎంబెడ్డింగ్‌లను సేకరిస్తారు, Qdrant పాయింట్లను బిల్డ్ చేస్తారు, మరియు అప్‌సర్ట్ చేస్తారు. ఎర్రర్ వస్తే (429 rate-limit, network timeout), వారు ఎక్స్‌పోనెన్షియల్ బ్యాక్‌ఆఫ్ విత్ జిట్టర్ ఉపయోగిస్తారు, గరిష్టంగా 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 — ప్రొడక్షన్‌ను రక్షించే డిజైన్ నిర్ణయాలు.
• డాక్యుమెంట్ చేసిన ఘటన. పోస్ట్‌గ్రేస్ OOM వైఫల్యం కాన్ఫిగరేషన్ అలైన్‌మెంట్ గురించిన స్పష్టమైన పాఠంగా మారింది.

డిమెరిట్స్

• సుదీర్ఘమైన పైప్‌లైన్ వ్యవధి. మిగిలిన 85+ గంటలు అంటే నిరంతర ఆపరేషన్ వారాలు; చెక్‌పాయింట్లు ఉన్నప్పటికీ మధ్యలో ఇన్‌ఫ్రాస్ట్రక్చర్ విఫలమయ్యే అవకాశం ఉంది.
• సాధారణం కంటే రెండు పరిమాణాల శ్రేణులు పెద్దది. 63M+ వెక్టర్లు అనేది నిర్ధారించబడని రంగం; స్కేలింగ్ ప్రమాదాలు ఇంకా ఉన్నాయి.
• ప్రత్యేక హార్డ్‌వేర్ ఖర్చు. r6a.xlarge ఇన్స్టాన్స్ అవసరమే కానీ నిరంతర కార్యాచరణ ఖర్చును పెంచుతుంది.
• లాంగ్వేజ్ మోడల్ ఆధారపడటం. నాణ్యత ఎంబెడ్డింగ్ మోడల్‌పై ఆధారపడి ఉంటుంది; Voyage ధరను లేదా సేవను మార్చితే, పరిగణనలు మారుతాయి.
• క్వెరీ లేటెన్సీ ప్రస్తావన లేదు. 63M వెక్టర్లపై సిమాంటిక్ సెర్చ్ ఎంత వేగంగా ఎగ్జిక్యూట్ అవుతుందనే దాని గురించి వ్యాసంలో చర్చించలేదు.

హెచ్చరిక

ఈ వ్యాసం విద్యా ప్రయోజనాల కోసం మరియు మూల సామగ్రిలో నివేదించబడిన నిజమైన ప్రాజెక్ట్‌ను వివరిస్తుంది. ఏదైనా అమలు ప్రస్తుత Voyage ధరతో ఖర్చు గణాంకాలను ధృవీకరించాలి, మీ స్వంత డేటాతో మీ స్వంత వాతావరణంలో PostgreSQL కాన్ఫిగరేషన్ పారామితులను పరీక్షించాలి మరియు కాన్కరెన్సీ సెట్టింగ్‌లను ధృవీకరించాలి (ఇక్కడ పనిచేసిన 50 ప్యారలల్ రిక్వెస్ట్‌లు అన్ని సిస్టమ్‌లకు సరిపోకపోవచ్చు). పోస్ట్‌గ్రేస్ shared_buffers విలువ మీ కంటైనర్ మెమరీతో సరిపోలాలి. ఏవైనా నిర్దిష్ట సంఖ్యలు లేదా విధానాలపై ఆధారపడే ముందు, అసలు మూలాన్ని మరియు మీ స్వంత ఇన్‌ఫ్రాస్ట్రక్చర్‌ను సంప్రదించండి.

తరచుగా అడిగే ప్రశ్నలు

• EDRSR అంటే ఏమిటి మరియు ఉక్రెయిన్ అన్ని కోర్టు తీర్పులను ప్రజలకు ఎందుకు అందుబాటులో ఉంచుతుంది?
• వెక్టర్ ఎంబెడ్డింగ్‌లు ఎలా పనిచేస్తాయి మరియు లీగల్ డాక్యుమెంట్ల కోసం కీవర్డ్ సెర్చ్ కంటే ఇవి ఎందుకు మెరుగైనవి?
• Pinecone లేదా Milvus వంటి ఇతర వెక్టర్ డేటాబేస్‌లకు బదులుగా బృందం Qdrant ను ఎందుకు ఉపయోగించింది?
• GIL డెడ్‌లాక్ అంటే ఏమిటి మరియు కాన్కరెన్సీ 70 పైప్‌లైన్‌ను ఎందుకు హ్యాంగ్ అయ్యేలా చేసింది?
• చెక్‌పాయింట్-ఆధారిత రిజ్యూమ్ ఎలా పనిచేస్తుంది మరియు ఇది ఎంత రీస్టార్ట్ ఓవర్‌హెడ్‌ను జోడిస్తుంది?
• కంటైనర్ మెమరీ పరిమితులతో PostgreSQL కాన్ఫిగరేషన్ అలైన్‌మెంట్ ఎందుకు అంత కీలకమైనది?
• 33.7M డాక్యుమెంట్ల వద్ద Voyage AI మరియు OpenAI ఎంబెడ్డింగ్‌ల మధ్య ఖర్చు తేడా ఎంత?
• 63M+ వెక్టర్ కలెక్షన్‌పై సిమాంటిక్ సెర్చ్ క్వెరీ ఎగ్జిక్యూట్ అవ్వడానికి ఎంత సమయం పడుతుంది?

ట్యాగ్‌లు

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