ഉക്രെയ്നിലെ ഏറ്റവും വലിയ കോടതി ഡാറ്റാബേസ് എങ്ങനെ വെക്ടറൈസ് ചെയ്യപ്പെട്ടു: 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+ വെക്ടറുകൾ ഉണ്ടാകും — 100K മുതൽ 1M വരെ വെക്ടറുകൾ മാത്രമുള്ള സാധാരണ RAG പ്രോജക്റ്റുകളേക്കാൾ നൂറുമടങ്ങ് വലുതാണിത്.

ഇത്രയും രേഖകൾ പ്രോസസ്സ് ചെയ്യുക എന്നതിനർത്ഥം പകുതിവഴിയിൽ തകരാറിലാകാത്ത ഒരു പൈപ്പ്‌ലൈൻ നിർമ്മിക്കുക എന്നാണ്.

ടെക്നിക്കൽ സ്റ്റാക്ക്

ടീം തെളിയിക്കപ്പെട്ടതും പ്രായോഗികവുമായ തിരഞ്ഞെടുപ്പുകളാണ് നടത്തിയത്:

എംബഡിംഗ് മോഡൽ: Voyage AI-യുടെ voyage-3.5, ഇത് 1024-ഡൈമൻഷണൽ വെക്ടറുകൾ ഔട്ട്പുട്ട് ചെയ്യുന്നു. അവർ Voyage 3 Large, OpenAI-യുടെ text-embedding-3-large എന്നിവ പരിശോധിച്ചുവെങ്കിലും നിയമപരമായ ടെക്സ്റ്റുകളിലെ ഗുണനിലവാര വ്യത്യാസം ചിലവിലെ വ്യത്യാസത്തെ ന്യായീകരിക്കുന്നില്ലെന്ന് കണ്ടെത്തി. Voyage 3 Large-ന് മൂന്ന് മടങ്ങ് വില കൂടുതലാണ്.

വെക്ടർ ഡാറ്റാബേസ്: ഒരു ഡെഡിക്കേറ്റഡ് Amazon EC2 ഇൻസ്റ്റൻസിൽ (r6a.xlarge: 4 CPU, 32 GB RAM, 2 TB gp3 storage) Docker-ൽ സ്വയം ഹോസ്റ്റ് ചെയ്ത Qdrant v1.17. HNSW ഇൻഡെക്സിംഗ് ഉള്ള 44M+ പോയിന്റുകൾ പ്രൊഡക്ഷൻ ഡാറ്റാബേസിന്റെ മെമ്മറി തീർക്കുകയും ചാറ്റ് സേവനത്തെ പൂർണ്ണമായി തടസ്സപ്പെടുത്തുകയും ചെയ്തതിനാലാണ് അവർ ഇതിനായി പ്രത്യേക ഇൻസ്റ്റൻസ് നൽകിയത്.

സൂഴ്സ് ഓഫ് ട്രൂത്ത്: വിധിയുടെ തീയതി അനുസരിച്ച് ടേബിളുകൾ വിഭജിച്ച PostgreSQL 15. പൂർണ്ണ കോടതി വാചകങ്ങൾ ഒരു ടേബിളിലും മെറ്റാഡാറ്റ മറ്റൊരു ടേബിളിലുമാണ് ഉള്ളത്. എല്ലാ പാർട്ടിഷനുകളിലുമുള്ള JOIN 30M+ വരികളെ ബാധിക്കുന്നു, അതിനാൽ പൈപ്പ്‌ലൈൻ ഒരു സമയം ഒരു വർഷത്തെ ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്നു.

പൈപ്പ്‌ലൈൻ റൺടൈം: Python 3.11, asyncio, aiohttp. വലിയ ഫ്രെയിംവർക്കുകളൊന്നുമില്ല — Voyage, Qdrant എന്നിവയിലേക്കുള്ള നേരിട്ടുള്ള HTTP കോളുകൾ മാത്രം. മുഴുവൻ കാര്യങ്ങളും ഒരൊറ്റ ഫയലിലെ 440 വരികളിൽ ഒതുങ്ങുന്നു.

അവർ എങ്ങനെയാണ് ജോലി വിഭജിച്ചത്

കോടതി വിധികൾ വളരെ ദൈർഘ്യമേറിയതാണ്. ഒരു ശരാശരി സിവിൽ വിധി 8,000 മുതൽ 12,000 വരെ അക്ഷരങ്ങളാണ്. ചിലത് 2,00,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 (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 കോൺഫിഗറേഷൻ പാരാമീറ്ററുകൾ കണ്ടെയ്നർ മെമ്മറി പരിധികളുമായി വിന്യസിക്കണം. ആദ്യത്തെ ലോഡ് സ്പൈക്ക് ഉണ്ടാകുന്നത് വരെ സിസ്റ്റം നന്നായി പ്രവർത്തിക്കും, തുടർന്ന് തകരാറിലാകും.

Voyage API ട്രാഫിക് Python പ്രോസസ്സിൽ ധാരാളം താൽക്കാലിക ഒബ്‌ജക്റ്റുകൾ സൃഷ്ടിക്കുന്നതിനാൽ അവർ തങ്ങളുടെ ഡെവലപ്‌മെന്റ് മെഷീനിലെ സ്വാപ്പ് 8GB-യിൽ നിന്ന് 24GB ആയും വർദ്ധിപ്പിച്ചു.

ഇതുവരെയുള്ള ചെലവ്

ഒരു സിവിൽ രേഖ ശരാശരി 2.7 ചങ്കുകൾ × 850 ടോക്കണുകൾ = 2,300 ടോക്കണുകൾ വരുന്നു. ഒരു ദശലക്ഷം ടോക്കണുകൾക്ക് 6 സെന്റ് എന്ന Voyage-ന്റെ നിരക്കിൽ, ഇത് ഒരു രേഖയ്ക്ക് 0.014 സെന്റ് ആണ് — ഏകദേശം 138 മൈക്രോഡോളർ.

ഇതുവരെ (42% പൂർത്തിയായി):

• 14.3M രേഖകൾ പ്രോസസ്സ് ചെയ്തു
• Voyage API-യിൽ ~$1,980 ചെലവഴിച്ചു
• ~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 കൺകറന്റ് അഭ്യർത്ഥനകൾ എല്ലാ സിസ്റ്റങ്ങൾക്കും അനുയോജ്യമായേക്കില്ല). Postgres shared_buffers മൂല്യം നിങ്ങളുടെ യഥാർത്ഥ കണ്ടെയ്നർ മെമ്മറിയുമായി പൊരുത്തപ്പെടണം. ഏതെങ്കിലും പ്രത്യേക സംഖ്യകളെയോ രീതികളെയോ ആശ്രയിക്കുന്നതിന് മുമ്പ്, അസ്സൽ ഉറവിടവും നിങ്ങളുടെ സ്വന്തം ഇൻഫ്രാസ്ട്രക്ചറും പരിശോധിക്കുക.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

• എന്താണ് EDRSR, ഉക്രെയ്ൻ എന്തിനാണ് എല്ലാ കോടതി വിധികളും പൊതുജനങ്ങൾക്കായി തുറന്നുകൊടുക്കുന്നത്?
• വെക്ടർ എംബഡിംഗുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു, നിയമപരമായ രേഖകൾക്ക് കീവേഡ് സെർച്ചിനേക്കാൾ മികച്ചത് എന്തുകൊണ്ട്?
• Pinecone അല്ലെങ്കിൽ Milvus പോലെയുള്ള മറ്റ് വെക്ടർ ഡാറ്റാബേസുകൾക്ക് പകരം ടീം എന്തുകൊണ്ടാണ് Qdrant ഉപയോഗിച്ചത്?
• എന്താണ് GIL ഡെഡ്‌ലോക്ക്, കൺകറൻസി 70 പൈപ്പ്‌ലൈൻ ഹാങ് ആകാൻ കാരണമായത് എന്തുകൊണ്ട്?
• ചെക്ക്പോയിന്റ് അടിസ്ഥാനമാക്കിയുള്ള പുനരാരംഭിക്കൽ എങ്ങനെ പ്രവർത്തിക്കുന്നു, ഇത് എത്രത്തോളം റീസ്റ്റാർട്ട് ഓവർഹെഡ് വർദ്ധിപ്പിക്കുന്നു?
• കണ്ടെയ്നർ മെമ്മറി പരിധികളുമായി PostgreSQL കോൺഫിഗറേഷൻ വിന്യസിക്കുന്നത് എന്തുകൊണ്ട് നിർണായകമാണ്?
• 33.7M രേഖകളിൽ Voyage AI, OpenAI എംബഡിംഗുകൾ തമ്മിലുള്ള ചിലവിലെ വ്യത്യാസം എന്താണ്?
• 63M+ വെക്ടർ കളക്ഷനിൽ ഒരു സെമാന്റിക് സെർച്ച് ക്വറി എക്സിക്യൂട്ട് ചെയ്യാൻ എത്ര സമയമെടുക്കും?

ടാഗുകൾ

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