ୟୁକ୍ରେନର ସବୁଠାରୁ ବଡ଼ ଅଦାଲତ ଡାଟାବେସ୍ କିପରି ଭେକ୍ଟରାଇଜ୍ ହେଲା: 33.7M ନିଷ୍ପତ୍ତି, ଗୋଟିଏ Vector DB

କଳ୍ପନା କରନ୍ତୁ ଯଦି ଜଣେ ଓକିଲ ସାଧାରଣ ଇଂରାଜୀରେ ପ୍ରଶ୍ନ ଟାଇପ୍ କରି ହଜାର ହଜାର କୀ-ୱାର୍ଡ ଫଳାଫଳ ଖୋଜିବା ପରିବର୍ତ୍ତେ — ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ ସଠିକ୍ ଅନୁଚ୍ଛେଦ ସହିତ ତୁରନ୍ତ ୫ଟି ସବୁଠାରୁ ପ୍ରାସଙ୍ଗିକ ଅଦାଲତ ରାୟ ପାଇପାରନ୍ତେ। ସେମାଣ୍ଟିକ୍ ସର୍ଚ୍ଚ ଏହି ପ୍ରତିଶ୍ରୁତି ଦିଏ। କିନ୍ତୁ 33.7 ନିୟୁତ ଅଦାଲତ ନିଷ୍ପତ୍ତି ପାଇଁ ଏହାକୁ ବାସ୍ତବ ରୂପ ଦେବା ଏକ ଭିନ୍ନ ସବାଲ।

EDRSR — Unified State Register of Court Decisions — ୟୁକ୍ରେନର ସମଗ୍ର ନ୍ୟାୟିକ ରେକର୍ଡକୁ ଜନସାଧାରଣଙ୍କ ପାଇଁ ଖୋଲି ଦେଇଛି। ବର୍ତ୍ତମାନ ଗୋଟିଏ ଟିମ୍ ଏହି ସମସ୍ତ ଟେକ୍ସଟକୁ ବାସ୍ତବରେ ସନ୍ଧାନଯୋଗ୍ୟ କରିବା ପାଇଁ କାର୍ଯ୍ୟ କରୁଛି।

ଏହା ଏବେ କାହିଁକି ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ

2026 ରେ, ୟୁକ୍ରେନରେ ଅଦାଲତ ନିଷ୍ପତ୍ତିଗୁଡ଼ିକ ସାର୍ବଜନୀନ ଡାଟା, କିନ୍ତୁ ସେଗୁଡ଼ିକୁ ପ୍ରଭାବଶାଳୀ ଭାବରେ ସନ୍ଧାନ କରିବା ଏବେ ବି କଷ୍ଟକର। ଏକ ନିର୍ଦ୍ଦିଷ୍ଟ ମୁଦ୍ଦା ଉପରେ ପୂର୍ବ ନଜିର ପାଇଁ ଖୋଜୁଥିବା ଜଣେ ଓକିଲଙ୍କୁ ଅସୁବିଧାଜନକ କୀ-ୱାର୍ଡ ସର୍ଚ୍ଚ ବ୍ୟବହାର କରିବାକୁ ପଡ଼ୁଥିଲା, ଯାହା ହଜାର ହଜାର ଅପ୍ରାସଙ୍ଗିକ ଫଳାଫଳ ଦେଉଥିଲା। ସିଷ୍ଟମ୍ ଅର୍ଥ — ବୁଝିପାରୁ ନଥିଲା — ଏହା କେବଳ ଆପଣ ଟାଇପ୍ କରିଥିବା ଶବ୍ଦଗୁଡ଼ିକ ଥିବା ଦଲିଲଗୁଡ଼ିକୁ ଖୋଜି ପାଉଥିଲା। ଭେକ୍ଟର ଏମ୍ବେଡିଂ ଦ୍ୱାରା ପରିଚାଳିତ ସେମାଣ୍ଟିକ୍ ସର୍ଚ୍ଚ ସହିତ, ଓକିଲମାନେ ବାସ୍ତବରେ ଯାହା ଜାଣିବାକୁ ଚାହାଁନ୍ତି ତାହା ପଚାରିପାରିବେ: "Is there case law on recovering bank prepayment fees?" ସିଷ୍ଟମ୍ ୫ଟି ସବୁଠାରୁ ପ୍ରାସଙ୍ଗିକ ରାୟ ଖୋଜିବା ସହ, ମୁଖ୍ୟ ଅନୁଚ୍ଛେଦଗୁଡ଼ିକୁ ବାହାର କରେ ଏବଂ ଅଦାଲତଗୁଡ଼ିକ ଏହା ଉପରେ କିପରି ଯୁକ୍ତି କରିଥିଲେ ତାହା ଦେଖାଏ।

କିନ୍ତୁ ଆପଣ ସେମାଣ୍ଟିକ୍ ସର୍ଚ୍ଚ କରିବା ପୂର୍ବରୁ, ଆପଣଙ୍କୁ ଟେକ୍ସଟକୁ ଭେକ୍ଟରାଇଜ୍ କରିବାକୁ ପଡ଼ିବ। ଏବଂ ୟୁକ୍ରେନର ଅଦାଲତ ସିଷ୍ଟମ୍ କୌଣସି ଛୋଟ ସମସ୍ୟା ନୁହେଁ।

ଆକାର

ରେଜିଷ୍ଟରରେ 2006 ପର୍ଯ୍ୟନ୍ତ ନିଷ୍ପତ୍ତିଗୁଡ଼ିକ ରହିଛି। ଏହାର ବିବରଣୀ:

• ଦେୱାନୀ ମାମଲା (CPC): 33.7M ଦଲିଲ — ସବୁଠାରୁ ବଡ଼ ବର୍ଗ
• ଫୌଜଦାରୀ ମାମଲା (CrPC): 12M+
• ପ୍ରଶାସନିକ ମାମଲା (CAS): 14M+
• ବାଣିଜ୍ୟିକ ମାମଲା (CC): 6M+
• କ୍ଷୁଦ୍ର ଅପରାଧ (CUaP): 6M+

ବର୍ତ୍ତମାନ ସୁଦ୍ଧା, Qdrant vector database ରେ 44M+ ଭେକ୍ଟର ରହିଛି। ଦେୱାନୀ ମାମଲାର 42% କାର୍ଯ୍ୟ ଶେଷ ହୋଇଛି (33.7M ରୁ 14.3M ପ୍ରୋସେସ୍ ହୋଇଛି)। ଦେୱାନୀ ପର୍ଯ୍ୟାୟ ଶେଷ ହେବା ପରେ, ସଂଗ୍ରହରେ ପ୍ରାୟ 63M+ ଭେକ୍ଟର ରହିବ — ଯାହା ଏକ ସାଧାରଣ RAG ପ୍ରକଳ୍ପ (ଯେଉଁଥିରେ 100K ରୁ 1M ଭେକ୍ଟର ଥାଇପାରେ) ତୁଳନାରେ ଦୁଇ ଗୁଣରୁ ଅଧିକ ବଡ଼।

ଏତେ ପରିମାଣର ଦଲିଲଗୁଡ଼ିକୁ ପ୍ରୋସେସ୍ କରିବା ଅର୍ଥ ଏପରି ଏକ ପାଇପଲାଇନ୍ ତିଆରି କରିବା ଯାହା ଅଧା ବାଟରେ ବନ୍ଦ ହୋଇଯିବ ନାହିଁ।

ଟେକ୍ନିକାଲ୍ ଷ୍ଟାକ୍

ଟିମ୍ ପ୍ରମାଣିତ, ବ୍ୟାବହାରିକ ପସନ୍ଦଗୁଡ଼ିକୁ ବାଛିଥିଲା:

Embedding model: Voyage AI ର voyage-3.5, ଯାହା 1024-dimensional ଭେକ୍ଟର ଆଉଟପୁଟ୍ ଦିଏ। ସେମାନେ Voyage 3 Large ଏବଂ OpenAI ର text-embedding-3-large ପରୀକ୍ଷା କରିଥିଲେ, କିନ୍ତୁ ଦେଖିଲେ ଯେ ଆଇନଗତ ଟେକ୍ସଟ ଉପରେ ଗୁଣବତ୍ତା ବୃଦ୍ଧି ଖର୍ଚ୍ଚର ପାର୍ଥକ୍ୟକୁ ନ୍ୟାୟସଙ୍ଗତ କରୁନାହିଁ। Voyage 3 Large ତିନି ଗୁଣ ଅଧିକ ମହଙ୍ଗା।

Vector database: Qdrant v1.17, ଏକ ସ୍ୱତନ୍ତ୍ର Amazon EC2 ଇନଷ୍ଟାନ୍ସ (r6a.xlarge: 4 CPU, 32 GB RAM, 2 TB gp3 storage) ରେ Docker ରେ self-hosted। ସେମାନେ ଏହାକୁ ନିଜର ଇନଷ୍ଟାନ୍ସ ଦେଇଥିଲେ କାରଣ HNSW ଇଣ୍ଡେକ୍ସିଂ ସହିତ 44M+ ପଏଣ୍ଟ ପ୍ରୋଡକ୍ସନ୍ ଡାଟାବେସର ମେମୋରୀ ଶେଷ କରିଦେଉଥିଲା ଏବଂ ଚାଟ୍ ସେବାକୁ ସମ୍ପୂର୍ଣ୍ଣ ରୂପେ ବ୍ଲକ୍ କରୁଥିଲା।

Source of truth: PostgreSQL 15, ଯେଉଁଥିରେ ଟେବୁଲଗୁଡ଼ିକ ରାୟ ତାରିଖ ଅନୁସାରେ ବିଭାଜିତ (partitioned)। ସମ୍ପୂର୍ଣ୍ଣ ଅଦାଲତ ଟେକ୍ସଟଗୁଡ଼ିକ ଗୋଟିଏ ଟେବୁଲରେ ଏବଂ ମେଟାଡାଟା ଅନ୍ୟ ଗୋଟିଏ ଟେବୁଲରେ ରହିଛି। ସମସ୍ତ ପାର୍ଟିସନ୍ ସାରା ଏକ JOIN 30M+ ଧାଡ଼ିକୁ ସ୍ପର୍ଶ କରେ, ତେଣୁ ପାଇପଲାଇନ୍ ଥରକରେ ଗୋଟିଏ ବର୍ଷ ପ୍ରୋସେସ୍ କରେ।

Pipeline runtime: 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 key ପାଇଁ ପ୍ରତି ମିନିଟରେ 2,000 ଅନୁରୋଧ। ଟିମ୍ ଦୁଇଟି key ବ୍ୟବହାର କରେ ଏବଂ ସେଗୁଡ଼ିକ ମଧ୍ୟରେ round-robin କରେ, ଯାହା ତତ୍ତ୍ୱଗତ ଭାବେ 4,000 RPM ସୀମା ଛୁଇଁଥାଏ।

ସେମାନେ କନ୍‌କରେନ୍ସିକୁ 50 ସମକାଳୀନ ଅନୁରୋଧରେ ରଖନ୍ତି ଏବଂ ପ୍ରତି ସେକେଣ୍ଡରେ 63ଟି ଦଲିଲ ପ୍ରୋସେସ୍ କରନ୍ତି। ଏହା ପ୍ରତି key ପାଇଁ ପ୍ରତି ମିନିଟରେ ପ୍ରାୟ 170 ଅନୁରୋଧ — ଯାହା ସୀମାଠାରୁ ବହୁତ କମ୍। ସେମାନେ କନ୍‌କରେନ୍ସି 70 ଚେଷ୍ଟା କରିଥିଲେ ଏବଂ Python GIL (global interpreter lock) ସମସ୍ୟାର ସମ୍ମୁଖୀନ ହୋଇଥିଲେ: ପ୍ରୋସେସ୍ 13% CPU ରେ ଅଟକି ଗଲା, କୌଣସି ଅଗ୍ରଗତି କଲାନାହିଁ ଏବଂ କୌଣସି ତ୍ରୁଟି ଦେଲାନାହିଁ। କେବଳ ହ୍ୟାଙ୍ଗ୍ ହୋଇଗଲା। 50 କୁ ହ୍ରାସ କରିବା ପରେ ଏହା ସୁରୁଖୁରୁରେ ଚାଲିଲା।

ପ୍ରତ୍ୟେକ 100 ଦଲିଲରେ, ସେମାନେ 500 ଚଙ୍କକୁ ବ୍ୟାଚ୍ କରି Voyage କୁ ପଠାନ୍ତି, ଏମ୍ବେଡିଂ ସଂଗ୍ରହ କରନ୍ତି, Qdrant ପଏଣ୍ଟ ତିଆରି କରନ୍ତି ଏବଂ upsert କରନ୍ତି। ତ୍ରୁଟି (429 rate-limit, network timeout) ହେଲେ, ସେମାନେ jitter ସହିତ exponential backoff, ସର୍ବାଧିକ 5 ଥର ପୁନଃପ୍ରଚେଷ୍ଟା ବ୍ୟବହାର କରନ୍ତି।

ସପ୍ତାହ ସପ୍ତାହର ସମୟ ବଞ୍ଚାଇଥିବା ଚେକ୍‌ପଏଣ୍ଟ

33.7M ଦଲିଲରେ, କୌଣସି ବିଫଳତାର ଅର୍ଥ ହେଉଛି ଘଣ୍ଟା ଘଣ୍ଟା କିମ୍ବା ଦିନ ଦିନର ନଷ୍ଟ ହୋଇଥିବା କାର୍ଯ୍ୟ। ଟିମ୍ ଏକ ଚେକ୍‌ପଏଣ୍ଟ ସିଷ୍ଟମ୍ ତିଆରି କରିଥିଲା: ପ୍ରତ୍ୟେକ 1,000 ପ୍ରୋସେସ୍ ହୋଇଥିବା ଦଲିଲରେ, ପାଇପଲାଇନ୍ ଶେଷ document ID, count, tokens used, ଏବଂ timestamp ସହିତ ଏକ JSON snapshot ଲେଖେ।

ପୁନରାରମ୍ଭରେ, ଏହା ସେହି ଚେକ୍‌ପଏଣ୍ଟ ପଢ଼େ ଏବଂ WHERE doc_id > last_doc_id ରୁ ପୁନର୍ବାର ଆରମ୍ଭ କରେ। କୌଣସି ନକଲି କାମ ନାହିଁ, ଶୂନ୍ୟରୁ ପୁନରାରମ୍ଭ ନାହିଁ।

ଏହା ସେମାନଙ୍କୁ ଦୁଇଥର ବଞ୍ଚାଇଛି। ଥରେ ଯେତେବେଳେ PostgreSQL ର ମେମୋରୀ ଶେଷ ହୋଇଗଲା (ତଳେ ଅଧିକ ଦିଆଯାଇଛି)। ଥରେ ଯେତେବେଳେ Qdrant ପୁନରାରମ୍ଭ ହେଲା ଏବଂ ଏନଭାୟରନ୍‌ମେଣ୍ଟରୁ ଏହାର API key ହରାଇଲା।

ଏକ ପ୍ରୋଡକ୍ସନ୍ ଘଟଣା: Postgres Out of Memory

2.86M ଦଲିଲରେ, PostgreSQL ରିକଭରୀ ମୋଡ୍‌କୁ ଚାଲିଗଲା। ମୂଳ କାରଣ: config mismatch।

ଡାଟାବେସ୍‌କୁ shared_buffers=16GB ରେ ସେଟ୍ କରାଯାଇଥିଲା, କିନ୍ତୁ କଣ୍ଟେନର ମେମୋରୀ ସୀମା 12GB ଥିଲା। PostgreSQL ତାହା ପାଖରେ ଥିବା ମେମୋରୀଠାରୁ ଅଧିକ ଆଲୋକେଟ୍ କରିବାକୁ ଚେଷ୍ଟା କଲା; OS ପ୍ରୋସେସ୍‌କୁ kill କରିଦେଲା।

ସମାଧାନ (PR #1453) କଣ୍ଟେନର ସୀମାକୁ 24GB ଏବଂ shm_size କୁ 16GB କୁ ବୃଦ୍ଧି କଲା। ପୁନରାରମ୍ଭ ପରେ, PostgreSQL 4 ସେକେଣ୍ଡରେ ଚାଲୁହେଲା ଏବଂ ସ୍ଥିର ରହିଲା।

ଶିକ୍ଷା: PostgreSQL configuration parameters କଣ୍ଟେନର ମେମୋରୀ ସୀମା ସହିତ ସମାନ ହେବା ଆବଶ୍ୟକ। ପ୍ରଥମ load spike ପର୍ଯ୍ୟନ୍ତ ସିଷ୍ଟମ୍ ଠିକ୍ ଚାଲେ, ତା'ପରେ ଖରାପ ଭାବରେ ବିଫଳ ହୁଏ।

ସେମାନେ ସେମାନଙ୍କର dev ମେସିନରେ swap କୁ 8GB ରୁ 24GB କୁ ବୃଦ୍ଧି କରିଥିଲେ କାରଣ ଭାରୀ Voyage API traffic Python process ରେ ଅନେକ ଅସ୍ଥାୟୀ ଅବଜେକ୍ଟ ସୃଷ୍ଟି କରେ।

ବର୍ତ୍ତମାନ ସୁଦ୍ଧା ଖର୍ଚ୍ଚ

ଗୋଟିଏ ଦେୱାନୀ ଦଲିଲର ହାରାହାରି 2.7 chunks × 850 tokens = 2,300 tokens। Voyage ର ମୂଲ୍ୟ ପ୍ରତି ନିୟୁତ ଟୋକନ୍ ପାଇଁ 6 ସେଣ୍ଟ ହିସାବରେ, ତାହା ପ୍ରତି ଦଲିଲ ପାଇଁ 0.014 ସେଣ୍ଟ — ପ୍ରାୟ 138 microdollars।

ବର୍ତ୍ତମାନ ସୁଦ୍ଧା (42% ସମ୍ପୂର୍ଣ୍ଣ):

• 14.3M ଦଲିଲ ପ୍ରୋସେସ୍ ହୋଇଛି
• ~$1,980 Voyage API ରେ ଖର୍ଚ୍ଚ ହୋଇଛି
• ~63 ଘଣ୍ଟାର ପାଇପଲାଇନ୍ ରନ୍‌ଟାଇମ୍

ବାକି (58% ବାକି ଅଛି):

• 19.4M ଦଲିଲ
• Voyage ଖର୍ଚ୍ଚ ଆନୁମାନିକ ~$2,680
• ଆନୁମାନିକ 85 ଘଣ୍ଟା (~3.5 ଦିନର ନିରବଚ୍ଛିନ୍ନ ଚାଲିବା)

ସମ୍ପୂର୍ଣ୍ଣ ଦେୱାନୀ ପର୍ଯ୍ୟାୟ ପାଇଁ ମୋଟ ଖର୍ଚ୍ଚ: API ଫି' ରେ ପ୍ରାୟ $4,660।

ସ୍ୱତନ୍ତ୍ର EC2 instance on-demand ରେ ଘଣ୍ଟା ପ୍ରତି ପ୍ରାୟ $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 ଅଦାଲତ ନିଷ୍ପତ୍ତିକୁ ଭେକ୍ଟରାଇଜ୍ କରିବା କୌଣସି ଛୋଟ ଇଞ୍ଜିନିୟରିଂ ସମସ୍ୟା ନୁହେଁ। ଏହା ପାଇଁ ଖର୍ଚ୍ଚ-ଗୁଣବତ୍ତା ବୁଝାମଣା ପାଇଁ ସଠିକ୍ embedding model ବାଛିବା, ପ୍ରୋଡକ୍ସନ୍ ବାଧାପ୍ରାପ୍ତ ନହେବା ପାଇଁ ଆପଣଙ୍କ vector database କୁ ଅଲଗା କରିବା, GIL deadlocks ରୁ ବଞ୍ଚିବା ପାଇଁ ସାବଧାନତାର ସହିତ concurrency ପରିଚାଳନା କରିବା, ଏବଂ 100+ ଘଣ୍ଟାର ପାଇପଲାଇନ୍ ରେ fault tolerance ତିଆରି କରିବା ଆବଶ୍ୟକ। ୟୁକ୍ରେନର ନ୍ୟାୟିକ ରେକର୍ଡ ଏବେ ଏକ ସନ୍ଧାନଯୋଗ୍ୟ knowledge base ରେ ରୂପାନ୍ତରିତ ହେଉଛି।

ସୁଗୁଣଗୁଡ଼ିକ

• ସମ୍ପୂର୍ଣ୍ଣ-ଟେକ୍ସଟ ଉପରେ ସେମାଣ୍ଟିକ୍ ସର୍ଚ୍ଚ। ଓକିଲମାନେ ଉତ୍ତର ପାଆନ୍ତି, କୀ-ୱାର୍ଡ ଫଳାଫଳ ନୁହେଁ।
• ବଡ଼ ପରିମାଣରେ ଖର୍ଚ୍ଚ-ପ୍ରଭାବଶାଳୀ। Voyage AI ଏହି ପରିମାଣ ପାଇଁ ବିକଳ୍ପ ତୁଳନାରେ 4 ଗୁଣ ଶସ୍ତା ଥିଲା।
• Fault-tolerant design। Checkpoints ପାଇପଲାଇନ୍‌କୁ replay ବିନା ବିଫଳତାରୁ ରକ୍ଷା ପାଇବାକୁ ଦିଅନ୍ତି।
• ବ୍ୟାବହାରିକ ଇନ୍‌ଫ୍ରାଷ୍ଟ୍ରକ୍ଚର। ଗୋଟିଏ ଅଲଗା କଣ୍ଟେନରରେ Qdrant, ସଠିକ୍ ମେମୋରୀ ସୀମା ସହିତ PostgreSQL — ଡିଜାଇନ୍ ନିଷ୍ପତ୍ତିଗୁଡ଼ିକ ଯାହା ପ୍ରୋଡକ୍ସନ୍‌କୁ ସୁରକ୍ଷିତ ରଖେ।
• ନଥିଭୁକ୍ତ ଘଟଣା। Postgres OOM ବିଫଳତା configuration alignment ବିଷୟରେ ଏକ ସ୍ପଷ୍ଟ ଶିକ୍ଷା ହୋଇଗଲା।

ଦୁର୍ବଳତାଗୁଡ଼ିକ

• ଦୀର୍ଘ ପାଇପଲାଇନ୍ ଅବଧି। 85+ ଘଣ୍ଟା ବାକି ରହିବାର ଅର୍ଥ ହେଉଛି ସପ୍ତାହ ସପ୍ତାହର ନିରବଚ୍ଛିନ୍ନ କାର୍ଯ୍ୟ; checkpoints ସତ୍ତ୍ୱେ କାର୍ଯ୍ୟ ମଝିରେ ଇନ୍‌ଫ୍ରାଷ୍ଟ୍ରକ୍ଚର ବିଫଳ ହୋଇପାରେ।
• ସାଧାରଣ ତୁଳନାରେ ଦୁଇ ଗୁଣରୁ ଅଧିକ ବଡ଼। 63M+ vectors ହେଉଛି ଅପରୀକ୍ଷିତ କ୍ଷେତ୍ର; scaling ବିପଦ ରହିଛି।
• ସ୍ୱତନ୍ତ୍ର ହାର୍ଡୱେର୍ ଖର୍ଚ୍ଚ। r6a.xlarge instance ଆବଶ୍ୟକ କିନ୍ତୁ କ୍ରମାଗତ ପରିଚାଳନା ଖର୍ଚ୍ଚ ଯୋଡିଥାଏ।
• Language model ନିର୍ଭରଶୀଳତା। ଗୁଣବତ୍ତା embedding model ଉପରେ ନିର୍ଭର କରେ; ଯଦି Voyage ମୂଲ୍ୟ କିମ୍ବା ସେବା ବଦଳାଏ, ତେବେ ହିସାବ ବଦଳିଯାଏ।
• Query latency ର କୌଣସି ଉଲ୍ଲେଖ ନାହିଁ। 63M vectors ଉପରେ ସେମାଣ୍ଟିକ୍ ସର୍ଚ୍ଚ ବାସ୍ତବରେ କେତେ ଶୀଘ୍ର କାର୍ଯ୍ୟକାରୀ ହୁଏ ତାହା ପ୍ରବନ୍ଧରେ ଆଲୋଚନା କରାଯାଇ ନାହିଁ।

ସାବଧାନତା

ଏହି ପ୍ରବନ୍ଧଟି ଶିକ୍ଷଣୀୟ ଏବଂ ମୂଳ ସାମଗ୍ରୀରେ ରିପୋର୍ଟ କରାଯାଇଥିବା ପରି ଏକ ବାସ୍ତବ ପ୍ରକଳ୍ପ ବର୍ଣ୍ଣନା କରେ। କୌଣସି କାର୍ଯ୍ୟକାରିତା ବର୍ତ୍ତମାନର Voyage ମୂଲ୍ୟ ସହିତ ଖର୍ଚ୍ଚ ସଂଖ୍ୟା ଯାଞ୍ଚ କରିବା, ଆପଣଙ୍କ ନିଜ ଡାଟା ସହିତ ଆପଣଙ୍କ ନିଜ ପରିବେଶରେ PostgreSQL configuration parameters ପରୀକ୍ଷା କରିବା, ଏବଂ concurrency settings (ଏଠାରେ କାମ କରିଥିବା 50 concurrent requests ସମସ୍ତ ସିଷ୍ଟମ୍ ପାଇଁ ଉପଯୁକ୍ତ ନହୋଇପାରେ) ବୈଧ କରିବା ଉଚିତ। Postgres shared_buffers ମୂଲ୍ୟ ଆପଣଙ୍କ ପ୍ରକୃତ କଣ୍ଟେନର ମେମୋରୀ ସହିତ ମେଳ ଖାଇବା ଆବଶ୍ୟକ। କୌଣସି ନିର୍ଦ୍ଦିଷ୍ଟ ସଂଖ୍ୟା କିମ୍ବା ଦୃଷ୍ଟିକୋଣ ଉପରେ ନିର୍ଭର କରିବା ପୂର୍ବରୁ, ମୂଳ ଉତ୍ସ ଏବଂ ଆପଣଙ୍କର ନିଜସ୍ୱ ଇନ୍‌ଫ୍ରାଷ୍ଟ୍ରକ୍ଚର ସହିତ ପରାମର୍ଶ କରନ୍ତୁ।

ବାରମ୍ବାର ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନଗୁଡ଼ିକ

• EDRSR କ’ଣ ଏବଂ ୟୁକ୍ରେନ୍ କାହିଁକି ସମସ୍ତ ଅଦାଲତ ନିଷ୍ପତ୍ତିକୁ ଜନସାଧାରଣଙ୍କ ପାଇଁ ଖୋଲା କରେ?
• Vector embeddings କିପରି କାମ କରେ ଏବଂ ଆଇନଗତ ଦଲିଲ ପାଇଁ ସେଗୁଡ଼ିକ କୀ-ୱାର୍ଡ ସର୍ଚ୍ଚ ତୁଳନାରେ କାହିଁକି ଭଲ?
• ଟିମ୍ Pinecone କିମ୍ବା Milvus ଭଳି ଅନ୍ୟ vector databases ପରିବର୍ତ୍ତେ Qdrant କାହିଁକି ବ୍ୟବହାର କଲା?
• GIL deadlock କ’ଣ ଏବଂ କନ୍‌କରେନ୍ସି 70 କାହିଁକି ପାଇପଲାଇନ୍‌କୁ ହ୍ୟାଙ୍ଗ୍ କରାଇଲା?
• Checkpoint-based resume କିପରି କାମ କରେ ଏବଂ ଏହା କେତେ restart overhead ଯୋଡିଥାଏ?
• PostgreSQL configuration କଣ୍ଟେନର ମେମୋରୀ ସୀମା ସହିତ ସମାନ ହେବା କାହିଁକି ଏତେ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ?
• 33.7M ଦଲିଲରେ Voyage AI ଏବଂ OpenAI embeddings ମଧ୍ୟରେ ଖର୍ଚ୍ଚର ପାର୍ଥକ୍ୟ କ’ଣ?
• 63M+ vector collection ରେ ଏକ ସେମାଣ୍ଟିକ୍ ସର୍ଚ୍ଚ କ୍ୱେରୀ କାର୍ଯ୍ୟକାରୀ ହେବାକୁ କେତେ ସମୟ ନିଏ?

ଟ୍ୟାଗ୍‌ଗୁଡ଼ିକ

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