ಉಕ್ರೇನ್‌ನ ಅತ್ಯಂತ ದೊಡ್ಡ ನ್ಯಾಯಾಲಯ ಡೇಟಾಬೇಸ್ ವೆಕ್ಟರೈಸ್ ಆದದ್ದು ಹೇಗೆ: 33.7M ತೀರ್ಪುಗಳು, ಒಂದು Vector DB

ಸಾವಿರಾರು ಕೀವರ್ಡ್ ಫಲಿತಾಂಶಗಳನ್ನು ಹುಡುಕುವ ಬದಲಿಗೆ, ಒಬ್ಬ ವಕೀಲರು ಸರಳ ಇಂಗ್ಲಿಷ್‌ನಲ್ಲಿ ಪ್ರಶ್ನೆಯನ್ನು ಟೈಪ್ ಮಾಡಿ ಪ್ರಮುಖವಾದ ಸರಿಯಾದ ಪ್ಯಾರಾಗ್ರಾಫ್‌ಗಳೊಂದಿಗೆ ಅತ್ಯಂತ ಸೂಕ್ತವಾದ ಐದು ನ್ಯಾಯಾಲಯದ ತೀರ್ಪುಗಳನ್ನು ತಕ್ಷಣವೇ ಪಡೆಯಲು ಸಾಧ್ಯವಾದರೆ ಹೇಗಿರುತ್ತದೆ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಸೆಮ್ಯಾಂಟಿಕ್ ಸರ್ಚ್ ನೀಡುವ ಭರವಸೆ ಇದೇ ಆಗಿದೆ. ಆದರೆ ಇದನ್ನು 33.7 ಮಿಲಿಯನ್ ನ್ಯಾಯಾಲಯದ ತೀರ್ಪುಗಳಿಗೆ ನಿಜವಾಗಿಸುವುದು ದೊಡ್ಡ ಸವಾಲಾಗಿದೆ.

EDRSR — ಅಂದರೆ ಯುನಿಫೈಡ್ ಸ್ಟೇಟ್ ರಿಜಿಸ್ಟರ್ ಆಫ್ ಕೋರ್ಟ್ ಡಿಸಿಷನ್ಸ್ — ಉಕ್ರೇನ್‌ನ ಇಡೀ ನ್ಯಾಯಾಂಗ ದಾಖಲೆಯನ್ನು ಸಾರ್ವಜನಿಕರಿಗೆ ಮುಕ್ತಗೊಳಿಸಿದೆ. ಈಗ ತಂಡವೊಂದು ಆ ಎಲ್ಲಾ ಪಠ್ಯವನ್ನು ನಿಜವಾಗಿಯೂ ಹುಡುಕಬಹುದಾದಂತೆ ಮಾಡಲು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ.

ಇದು ಈಗೇಕೆ ಪ್ರಮುಖವಾಗಿದೆ

2026 ರಲ್ಲಿ, ಉಕ್ರೇನ್‌ನಲ್ಲಿ ನ್ಯಾಯಾಲಯದ ತೀರ್ಪುಗಳು ಸಾರ್ವಜನಿಕ ಡೇಟಾ ಆಗಿವೆ, ಆದರೆ ಅವುಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಹುಡುಕುವುದು ಇನ್ನೂ ಕಷ್ಟಕರವಾಗಿದೆ. ನಿರ್ದಿಷ್ಟ ವಿಷಯದ ಪೂರ್ವಾಪರ ಉಲ್ಲೇಖ (precedent) ಗಾಗಿ ಹುಡುಕುವ ವಕೀಲರು ತೊಡಕಿನ ಕೀವರ್ಡ್ ಸರ್ಚ್ ಬಳಸಬೇಕಾಗಿತ್ತು, ಅದು ಸಾವಿರಾರು ಅನಗತ್ಯ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತಿತ್ತು. ಸಿಸ್ಟಮ್‌ಗೆ ಅರ್ಥ — ಅರ್ಥವಾಗುತ್ತಿರಲಿಲ್ಲ, ಅದು ನೀವು ಟೈಪ್ ಮಾಡಿದ ಪದಗಳನ್ನು ಹೊಂದಿರುವ ದಾಖಲೆಗಳನ್ನು ಮಾತ್ರ ನೀಡುತ್ತಿತ್ತು. vector embeddings ನಿಂದ ಚಾಲಿತವಾದ ಸೆಮ್ಯಾಂಟಿಕ್ ಸರ್ಚ್ ಮೂಲಕ, ವಕೀಲರು ತಾವು ನಿಜವಾಗಿ ತಿಳಿಯಲು ಬಯಸುವುದನ್ನು ಕೇಳಬಹುದು: "Is there case law on recovering bank prepayment fees?" ಸಿಸ್ಟಮ್ ಅತ್ಯಂತ ಸೂಕ್ತವಾದ ಐದು ತೀರ್ಪುಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ, ಪ್ರಮುಖ ಪ್ಯಾರಾಗ್ರಾಫ್‌ಗಳನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ ಮತ್ತು ನ್ಯಾಯಾಲಯಗಳು ಅದನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸಿದವು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

ಆದರೆ ನೀವು ಸೆಮ್ಯಾಂಟಿಕ್ ಸರ್ಚ್ ಮಾಡುವ ಮೊದಲು, ಪಠ್ಯವನ್ನು ವೆಕ್ಟರೈಸ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ಉಕ್ರೇನ್‌ನ ನ್ಯಾಯಾಲಯ ವ್ಯವಸ್ಥೆಯು ಸಣ್ಣ ಪ್ರಮಾಣದ್ದಲ್ಲ.

ಪ್ರಮಾಣ (The Scale)

ಈ ರಿಜಿಸ್ಟರ್ 2006 ರವರೆಗಿನ ತೀರ್ಪುಗಳನ್ನು ಹೊಂದಿದೆ. ಅದರ ವಿವರ:

• ಸಿವಿಲ್ ಪ್ರಕರಣಗಳು (CPC): 33.7M ದಾಖಲೆಗಳು — ಅತ್ಯಂತ ದೊಡ್ಡ ವರ್ಗ
• ಕ್ರಿಮಿನಲ್ ಪ್ರಕರಣಗಳು (CrPC): 12M+
• ಆಡಳಿತಾತ್ಮಕ ಪ್ರಕರಣಗಳು (CAS): 14M+
• ವಾಣಿಜ್ಯ ಪ್ರಕರಣಗಳು (CC): 6M+
• ಸಣ್ಣ ಅಪರಾಧಗಳು (CUaP): 6M+

ಇಲ್ಲಿಯವರೆಗೆ, Qdrant ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ 44M+ ವೆಕ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ಸಿವಿಲ್ ಪ್ರಕರಣಗಳು 42% ಪೂರ್ಣಗೊಂಡಿವೆ (33.7M ನಲ್ಲಿ 14.3M ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆ). ಸಿವಿಲ್ ವಿಭಾಗವು ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಸಂಗ್ರಹಣೆಯು ಸುಮಾರು 63M+ ವೆಕ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ — ಇದು ಸಾಮಾನ್ಯ RAG ಪ್ರಾಜೆಕ್ಟ್‌ಗಿಂತ (ಅದು 100K ನಿಂದ 1M ವೆಕ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಿರಬಹುದು) ಎರಡು ಆರ್ಡರ್ಸ್ ಆಫ್ ಮ್ಯಾಗ್ನಿಟ್ಯೂಡ್ ದೊಡ್ಡದಾಗಿದೆ.

ಇಷ್ಟೊಂದು ದಾಖಲೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು ಎಂದರೆ ಅರ್ಧ ಹಾದಿಯಲ್ಲಿ ವಿಫಲವಾಗದ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದಾಗಿತ್ತು.

ತಾಂತ್ರಿಕ ಸ್ಟ್ಯಾಕ್

ತಂಡವು ಸಾಬೀತಾದ, ಪ್ರಾಯೋಗಿಕ ಆಯ್ಕೆಗಳನ್ನು ಮಾಡಿಕೊಂಡಿದೆ:

Embedding ಮಾದರಿ: Voyage AI ನ voyage-3.5, ಇದು 1024-ಆಯಾಮದ ವೆಕ್ಟರ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ. ಅವರು Voyage 3 Large ಮತ್ತು OpenAI ನ text-embedding-3-large ಅನ್ನು ಪರೀಕ್ಷಿಸಿದರು ಆದರೆ ಕಾನೂನು ಪಠ್ಯದಲ್ಲಿ ಗುಣಮಟ್ಟದ ಲಾಭವು ವೆಚ್ಚದ ವ್ಯತ್ಯಾಸಕ್ಕೆ ಸಮರ್ಥನೀಯವಲ್ಲ ಎಂದು ಕಂಡುಕೊಂಡರು. Voyage 3 Large ಮೂರು ಪಟ್ಟು ಹೆಚ್ಚು ದುಬಾರಿಯಾಗಿದೆ.

Vector ಡೇಟಾಬೇಸ್: Qdrant v1.17, ಮೀಸಲಾದ Amazon EC2 ಇನ್‌ಸ್ಟಾನ್ಸ್‌ನಲ್ಲಿ (r6a.xlarge: 4 CPU, 32 GB RAM, 2 TB gp3 ಸ್ಟೋರೇಜ್) Docker ನಲ್ಲಿ ಸೆಲ್ಫ್-ಹೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ. HNSW ಇಂಡೆಕ್ಸಿಂಗ್‌ನೊಂದಿಗೆ 44M+ ಪಾಯಿಂಟ್‌ಗಳು ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾಬೇಸ್‌ನ ಮೆಮೊರಿಯನ್ನು ಖಾಲಿ ಮಾಡುತ್ತಿದ್ದವು ಮತ್ತು ಚಾಟ್ ಸೇವೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಡೆಯುತ್ತಿದ್ದವು, ಆದ್ದರಿಂದ ಅವರು ಇದಕ್ಕೆ ಪ್ರತ್ಯೇಕ ಇನ್‌ಸ್ಟಾನ್ಸ್ ನೀಡಿದರು.

ಸತ್ಯದ ಮೂಲ (Source of truth): PostgreSQL 15, ತೀರ್ಪಿನ ದಿನಾಂಕದ ಪ್ರಕಾರ ಟೇಬಲ್‌ಗಳನ್ನು ಭಾಗಿಸಲಾಗಿದೆ (partitioned). ಸಂಪೂರ್ಣ ನ್ಯಾಯಾಲಯದ ಪಠ್ಯಗಳು ಒಂದು ಟೇಬಲ್‌ನಲ್ಲಿ, ಮೆಟಾಡೇಟಾ ಇನ್ನೊಂದರಲ್ಲಿ ಇರುತ್ತವೆ. ಎಲ್ಲಾ ಪಾರ್ಟಿಷನ್‌ಗಳಲ್ಲಿ JOIN ಪ್ರಕ್ರಿಯೆಯು 30M+ ಸಾಲುಗಳನ್ನು ಸ್ಪರ್ಶಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪೈಪ್‌ಲೈನ್ ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದು ವರ್ಷವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ.

Pipeline ರನ್‌ಟೈಮ್: Python 3.11, asyncio, aiohttp. ಯಾವುದೇ ದೊಡ್ಡ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳಿಲ್ಲ — ಕೇವಲ Voyage ಮತ್ತು Qdrant ಗೆ ನೇರ HTTP ಕಾಲ್‌ಗಳು. ಇಡೀ ಕೋಡ್ ಒಂದೇ ಫೈಲ್‌ನಲ್ಲಿ 440 ಸಾಲುಗಳಲ್ಲಿದೆ.

ಅವರು ಕೆಲಸವನ್ನು ಹೇಗೆ ವಿಂಗಡಿಸಿದರು

ನ್ಯಾಯಾಲಯದ ತೀರ್ಪುಗಳು ದೀರ್ಘವಾಗಿರುತ್ತವೆ. ಸರಾಸರಿ ಸಿವಿಲ್ ತೀರ್ಪು 8,000 ದಿಂದ 12,000 ಅಕ್ಷರಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಕೆಲವು 200,000 ತಲುಪುತ್ತವೆ. Voyage ಪ್ರತಿ ಇನ್‌ಪುಟ್‌ಗೆ 32,000 ಟೋಕನ್‌ಗಳವರೆಗೆ ಸ್ವೀಕರಿಸುತ್ತದೆ, ಆದರೆ ದೀರ್ಘ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ (long contexts) ಗುಣಮಟ್ಟ ಕಡಿಮೆಯಾಗುತ್ತದೆ, ಮತ್ತು ರಿಟ್ರೈವಲ್‌ಗಾಗಿ ಒಂದು ಉದ್ದನೆಯ ವೆಕ್ಟರ್ ಉಪಯುಕ್ತವಲ್ಲ — ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್‌ಗೆ ಯಾವ ಪ್ಯಾರಾಗ್ರಾಫ್ ಪ್ರಸ್ತುತವಾಗಿದೆ ಎಂದು ನಿಖರವಾಗಿ ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ ತಂಡವು ತುಂಡು ಮಾಡುತ್ತದೆ (chunks):

• ಪ್ರತಿ ಚಂಕ್‌ಗೆ ಗರಿಷ್ಠ 2,048 ಅಕ್ಷರಗಳು
• ಪಕ್ಕದ ಚಂಕ್‌ಗಳ ನಡುವೆ 50-ಪದಗಳ ಓವರ್‌ಲ್ಯಾಪ್ (ಗಡಿಗಳಲ್ಲಿ ಸನ್ನಿವೇಶವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು)
• ಸೆಮ್ಯಾಂಟಿಕ್ ಸಾಂತ್ಯತ್ಯವನ್ನು ಕಾಯ್ದುಕೊಳ್ಳಲು ಪ್ಯಾರಾಗ್ರಾಫ್ ಗಡಿಗಳಲ್ಲಿ ವಿಭಜನೆ

ಸರಾಸರಿಯಾಗಿ, ಒಂದು ತೀರ್ಪು 2.7 ಚಂಕ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ. ಪ್ರತಿ ಚಂಕ್ Qdrant ನಲ್ಲಿ ಕಾಂಪೋಸಿಟ್ ID (doc_id × 1000 + chunk_index) ಅನ್ನು ಪಡೆಯುತ್ತದೆ, ಇದು ಒಂದೇ ಪೇಲೋಡ್ ಫಿಲ್ಟರ್‌ಗೆ ಒಂದು ತೀರ್ಪಿನ ಎಲ್ಲಾ ಚಂಕ್‌ಗಳನ್ನು ಎಳೆಯಲು ಅನುಮತಿಸುತ್ತದೆ.

ವೇಗ ಮತ್ತು ಕನ್ ಕರೆನ್ಸಿ (Concurrency)

Voyage ದರ ಮಿತಿಯನ್ನು ಹೊಂದಿದೆ (rate limit): ಪ್ರತಿ API ಕೀಗೆ ನಿಮಿಷಕ್ಕೆ 2,000 ವಿನಂತಿಗಳು. ತಂಡವು ಎರಡು ಕೀಗಳನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ನಡುವೆ ರೌಂಡ್-ರಾಬಿನ್ ಮಾಡುತ್ತದೆ, ಸೈದ್ಧಾಂತಿಕ 4,000 RPM ಮಿತಿಯನ್ನು ತಲುಪುತ್ತದೆ.

ಅವರು ಕನ್ ಕರನ್ಸಿಯನ್ನು 50 ಸಮಾನಾಂತರ ವಿನಂತಿಗಳಲ್ಲಿ (50 concurrent requests) ಇರಿಸುತ್ತಾರೆ ಮತ್ತು ಸೆಕೆಂಡಿಗೆ ಸ್ಥಿರ 63 ದಾಖಲೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಾರೆ. ಅದು ಪ್ರತಿ ಕೀಗೆ ನಿಮಿಷಕ್ಕೆ ಸುಮಾರು 170 ವಿನಂತಿಗಳು — ಮಿತಿಗಿಂತ ಸಾಕಷ್ಟು ಕಡಿಮೆ. ಅವರು 70 ಕನ್ ಕರನ್ಸಿ ಪ್ರಯತ್ನಿಸಿದರು ಮತ್ತು Python GIL (global interpreter lock) ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದರು: ಪ್ರಕ್ರಿಯೆಯು 13% CPU ನಲ್ಲಿ ಸ್ಥಗಿತಗೊಂಡಿತು, ಯಾವುದೇ ಪ್ರಗತಿ ಸಾಧಿಸಲಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ದೋಷಗಳನ್ನು ನೀಡಲಿಲ್ಲ. ಕೇವಲ ಹ್ಯಾಂಗ್ ಆಯಿತು. ಹಿಂತಿರುಗಿ 50 ಕ್ಕೆ ಇಳಿಸಿದಾಗ ಅದು ಸುಗಮವಾಗಿ ಚಾಲನೆಗೊಂಡಿತು.

ಪ್ರತಿ 100 ದಾಖಲೆಗಳಿಗೆ, ಅವರು 500 ಚಂಕ್‌ಗಳನ್ನು ಬ್ಯಾಚ್ ಮಾಡಿ Voyage ಗೆ ಕಳುಹಿಸುತ್ತಾರೆ, embeddings ಸಂಗ್ರಹಿಸುತ್ತಾರೆ, Qdrant ಪಾಯಿಂಟ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಾರೆ ಮತ್ತು ಅಪ್‌ಸರ್ಟ್ ಮಾಡುತ್ತಾರೆ. ದೋಷ ಸಂಭವಿಸಿದಲ್ಲಿ (429 rate-limit, ನೆಟ್‌ವರ್ಕ್ ಟೈಮ್‌ಔಟ್), ಅವರು ಜಿಟ್ಟರ್‌ನೊಂದಿಗೆ ಎಕ್ಸ್‌ಪೋನೆನ್ಶಿಯಲ್ ಬ್ಯಾಕ್‌ಆಫ್ ಬಳಸುತ್ತಾರೆ, ಗರಿಷ್ಠ 5 ಮರುಪ್ರಯತ್ನಗಳು (retries).

ವಾರಗಳನ್ನು ಉಳಿಸಿದ ಚೆಕ್‌ಪಾಯಿಂಟ್

33.7M ದಾಖಲೆಗಳಲ್ಲಿ, ಯಾವುದೇ ವೈಫಲ್ಯ ಎಂದರೆ ಗಂಟೆಗಳ ಅಥವಾ ದಿನಗಳ ಕೆಲಸ ವ್ಯರ್ಥವಾದಂತೆ. ತಂಡವು ಚೆಕ್‌ಪಾಯಿಂಟ್ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸಿದೆ: ಪ್ರತಿ 1,000 ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ದಾಖಲೆಗಳಿಗೆ, ಪೈಪ್‌ಲೈನ್ ಕೊನೆಯ ಡಾಕ್ಯುಮೆಂಟ್ ID, ಕೌಂಟ್, ಬಳಸಿದ ಟೋಕನ್‌ಗಳು ಮತ್ತು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ನೊಂದಿಗೆ JSON ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಬರೆಯುತ್ತದೆ.

ಮರುಪ್ರಾರಂಭಿಸಿದಾಗ, ಅದು ಆ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಓದುತ್ತದೆ ಮತ್ತು WHERE doc_id > last_doc_id ನಿಂದ ಪುನರಾರಂಭಿಸುತ್ತದೆ. ಯಾವುದೇ ನಕಲಿ ಕೆಲಸವಿಲ್ಲ, ಶೂನ್ಯದಿಂದ ಮರುಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ.

ಇದು ಅವರನ್ನು ಎರಡು ಬಾರಿ ರಕ್ಷಿಸಿದೆ. ಒಮ್ಮೆ PostgreSQL ಮೆಮೊರಿ ಖಾಲಿಯಾದಾಗ (ಕೆಳಗೆ ವಿವರವಿದೆ). ಇನ್ನೊಮ್ಮೆ Qdrant ಮರುಪ್ರಾರಂಭಗೊಂಡು ಪರಿಸರದಿಂದ ತನ್ನ API ಕೀಯನ್ನು ಕಳೆದುಕೊಂಡಾಗ.

ಪ್ರೊಡಕ್ಷನ್ ಘಟನೆ: Postgres ಮೆಮೊರಿ ಖಾಲಿಯಾದದ್ದು (Out of Memory)

2.86M ದಾಖಲೆಗಳಲ್ಲಿ, PostgreSQL ರಿಕವರಿ ಮೋಡ್‌ಗೆ ಬಿದ್ದಿತು. ಮೂಲ ಕಾರಣ: ಕಾನ್ಫಿಗ್ ಹೊಂದಾಣಿಕೆಯಾಗದಿರುವುದು (config mismatch).

ಡೇಟಾಬೇಸ್ ಅನ್ನು shared_buffers=16GB ಗೆ ಹೊಂದಿಸಲಾಗಿತ್ತು, ಆದರೆ ಕಂಟೇನರ್ ಮೆಮೊರಿ ಮಿತಿ 12GB ಆಗಿತ್ತು. PostgreSQL ತನ್ನಲ್ಲಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಹಂಚಿಕೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿತು; OS ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಿತು (killed the process).

ಪರಿಹಾರ (PR #1453) ಕಂಟೇನರ್ ಮಿತಿಯನ್ನು 24GB ಗೆ ಮತ್ತು shm_size ಅನ್ನು 16GB ಗೆ ಹೆಚ್ಚಿಸಿತು. ಮರುಪ್ರಾರಂಭಿಸಿದ ನಂತರ, PostgreSQL 4 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಮೇಲಕ್ಕೆ ಬಂತು ಮತ್ತು ಸ್ಥಿರವಾಗಿ ಉಳಿಯಿತು.

ಕಲಿತ ಪಾಠ: PostgreSQL ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು ಕಂಟೇನರ್ ಮೆಮೊರಿ ಮಿತಿಗಳೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಮೊದಲ ಲೋಡ್ ಸ್ಪೈಕ್ (load spike) ಬರುವವರೆಗೆ ಸಿಸ್ಟಮ್ ಚೆನ್ನಾಗಿ ಚಲಿಸುತ್ತದೆ, ನಂತರ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ.

ಅವರು ತಮ್ಮ ಡೆವ್ ಮೆಷಿನ್‌ನಲ್ಲಿ ಸ್ವ್ಯಾಪ್ (swap) ಅನ್ನು 8GB ಯಿಂದ 24GB ಗೆ ಹೆಚ್ಚಿಸಿದರು ಏಕೆಂದರೆ ಭಾರಿ Voyage API ಟ್ರಾಫಿಕ್ Python ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಹೆಚ್ಚಿನ ತಾತ್ಕಾಲಿಕ ವಸ್ತುಗಳನ್ನು (temporary objects) ಉತ್ಪಾದಿಸುತ್ತದೆ.

ಇಲ್ಲಿಯವರೆಗಿನ ವೆಚ್ಚ

ಒಂದು ಸಿವಿಲ್ ದಾಖಲೆಯು ಸರಾಸರಿ 2.7 ಚಂಕ್‌ಗಳು × 850 ಟೋಕನ್‌ಗಳು = 2,300 ಟೋಕನ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಮಿಲಿಯನ್ ಟೋಕನ್‌ಗಳಿಗೆ 6 ಸೆಂಟ್ಸ್‌ಗಳ Voyage ದರದಲ್ಲಿ, ಅದು ಪ್ರತಿ ಡಾಕ್ಯುಮೆಂಟ್‌ಗೆ 0.014 ಸೆಂಟ್ಸ್ — ಸುಮಾರು 138 ಮೈಕ್ರೋಡಾಲರ್‌ಗಳು.

ಇಲ್ಲಿಯವರೆಗೆ (42% ಪೂರ್ಣಗೊಂಡಿದೆ):

• 14.3M ದಾಖಲೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆ
• ~$1,980 spent on Voyage API
• ~63 ಗಂಟೆಗಳ ಪೈಪ್‌ಲೈನ್ ರನ್‌ಟೈಮ್

ಉಳಿದಿರುವುದು (58% ಬಾಕಿ ಇದೆ):

• 19.4M ದಾಖಲೆಗಳು
• Voyage ವೆಚ್ಚದಲ್ಲಿ ಅಂದಾಜು ~$2,680
• ಅಂದಾಜು 85 ಗಂಟೆಗಳು (~3.5 ದಿನಗಳ ನಿರಂತರ ಚಾಲನೆ)

ಸಂಪೂರ್ಣ ಸಿವಿಲ್ ವಿಭಾಗಕ್ಕೆ ಒಟ್ಟು ವೆಚ್ಚ: ಸುಮಾರು $4,660 API ಶುಲ್ಕದಲ್ಲಿ.

ಮೀಸಲಾದ 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 ನ್ಯಾಯಾಲಯದ ತೀರ್ಪುಗಳನ್ನು ವೆಕ್ಟರೈಸ್ ಮಾಡುವುದು ಸಣ್ಣ ಎಂಜಿನಿಯರಿಂಗ್ ಸಮಸ್ಯೆಯಲ್ಲ. ವೆಚ್ಚ-ಗುಣಮಟ್ಟದ ವಿನಿಮಯಕ್ಕಾಗಿ ಸೂಕ್ತವಾದ embedding ಮಾದರಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು, ಪ್ರೊಡಕ್ಷನ್ ಬಟಾವಡೆಯಾಗದಂತೆ ತಡೆಯಲು ನಿಮ್ಮ ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು, GIL ಡೆಡ್‌ಲಾಕ್‌ಗಳನ್ನು ತಪ್ಪಿಸಲು ಕನ್ ಕರನ್ಸಿಯನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ನಿರ್ವಹಿಸುವುದು ಮತ್ತು 100+ ಗಂಟೆಗಳ ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ಫಾಲ್ಟ್ ಟಾಲರೆನ್ಸ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು ಇದಕ್ಕೆ ಅಗತ್ಯವಿದೆ. ಉಕ್ರೇನ್‌ನ ನ್ಯಾಯಾಂಗ ದಾಖಲೆಯನ್ನು ಈಗ ಹುಡುಕಬಹುದಾದ ಜ್ಞಾನದ ಮೂಲವಾಗಿ (knowledge base) ಪರಿವರ್ತಿಸಲಾಗುತ್ತಿದೆ.

ಅನುಕೂಲಗಳು

• ಸಂಪೂರ್ಣ ಪಠ್ಯದ ಮೇಲೆ ಸೆಮ್ಯಾಂಟಿಕ್ ಸರ್ಚ್. ವಕೀಲರು ಉತ್ತರಗಳನ್ನು ಪಡೆಯುತ್ತಾರೆ, ಕೇವಲ ಕೀವರ್ಡ್ ಫಲಿತಾಂಶಗಳನ್ನಲ್ಲ.
• ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ವೆಚ್ಚ-ಪರಿಣಾಮಕಾರಿ. ಈ ಪ್ರಮಾಣಕ್ಕೆ ಪರ್ಯಾಯಕ್ಕಿಂತ Voyage AI 4 ಪಟ್ಟು ಅಗ್ಗವಾಗಿತ್ತು.
• ಫಾಲ್ಟ್-ಟಾಲರೆಂಟ್ ವಿನ್ಯಾಸ. ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳು ಮರುಪ್ರಯತ್ನವಿಲ್ಲದೆ ವೈಫಲ್ಯಗಳಿಂದ ಪೈಪ್‌ಲೈನ್ ಬದುಕಲು ಅನುಮತಿಸುತ್ತವೆ.
• ಪ್ರಾಯೋಗಿಕ ಮೂಲಸೌಕರ್ಯ. ಪ್ರತ್ಯೇಕ ಕಂಟೇನರ್‌ನಲ್ಲಿ Qdrant, ಸರಿಯಾದ ಮೆಮೊರಿ ಮಿತಿಗಳೊಂದಿಗೆ PostgreSQL — ಪ್ರೊಡಕ್ಷನ್ ಅನ್ನು ರಕ್ಷಿಸುವ ವಿನ್ಯಾಸ ನಿರ್ಧಾರಗಳು.
• ದಾಖಲಾದ ಘಟನೆ. Postgres OOM ವೈಫಲ್ಯವು ಕಾನ್ಫಿಗರೇಶನ್ ಜೋಡಣೆಯ ಬಗ್ಗೆ ಸ್ಪಷ್ಟ ಪಾಠವಾಯಿತು.

ಅನನುಕೂಲಗಳು

• ದೀರ್ಘ ಪೈಪ್‌ಲೈನ್ ಅವಧಿ. 85+ ಗಂಟೆಗಳು ಬಾಕಿ ಇರುವುದು ಎಂದರೆ ವಾರಗಳ ನಿರಂತರ ಕಾರ್ಯಾಚರಣೆ; ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳಿದ್ದರೂ ಸಹ ಮೂಲಸೌಕರ್ಯವು ಮಧ್ಯದಲ್ಲಿ ವಿಫಲಗೊಳ್ಳಬಹುದು.
• ಸಾಮಾನ್ಯಕ್ಕಿಂತ ಎರಡು ಆರ್ಡರ್ಸ್ ಆಫ್ ಮ್ಯಾಗ್ನಿಟ್ಯೂಡ್ ದೊಡ್ಡದು. 63M+ ವೆಕ್ಟರ್‌ಗಳು ಅಪರಿಚಿತ ಕ್ಷೇತ್ರವಾಗಿದೆ; ಸ್ಕೇಲಿಂಗ್ ಅಪಾಯಗಳು ಉಳಿದಿವೆ.
• ಮೀಸಲಾದ ಹಾರ್ಡ್‌ವೇರ್ ವೆಚ್ಚ. r6a.xlarge ಇನ್‌ಸ್ಟಾನ್ಸ್ ಅತ್ಯಗತ್ಯ ಆದರೆ ಚಾಲ್ತಿಯಲ್ಲಿರುವ ಕಾರ್ಯಾಚರಣೆಯ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
• ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ ಮೇಲಿನ ಅವಲಂಬನೆ. ಗುಣಮಟ್ಟವು embedding ಮಾದರಿಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ; Voyage ಬೆಲೆ ಅಥವಾ ಸೇವೆಯನ್ನು ಬದಲಾಯಿಸಿದರೆ, ಲೆಕ್ಕಾಚಾರವು ಬದಲಾಗುತ್ತದೆ.
• ಕ್ವೆರಿ ಲ್ಯಾಟೆನ್ಸಿ (query latency) ಬಗ್ಗೆ ಉಲ್ಲೇಖವಿಲ್ಲ. 63M ವೆಕ್ಟರ್‌ಗಳಲ್ಲಿ ಸೆಮ್ಯಾಂಟಿಕ್ ಸರ್ಚ್ ವಾಸ್ತವವಾಗಿ ಎಷ್ಟು ವೇಗವಾಗಿ ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಲೇಖನ ಚರ್ಚಿಸುವುದಿಲ್ಲ.

ಎಚ್ಚರಿಕೆ

ಈ ಲೇಖನವು ಶೈಕ್ಷಣಿಕವಾಗಿದೆ ಮತ್ತು ಮೂಲ ವಿಷಯದಲ್ಲಿ ವረዳಿಯಾದಂತೆ ನೈಜ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ. ಯಾವುದೇ ಅನುಷ್ಠಾನವು ಪ್ರಸ್ತುತ Voyage ಬೆಲೆಯೊಂದಿಗೆ ವೆಚ್ಚದ ಅಂಕಿಅಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕು, ನಿಮ್ಮ ಸ್ವಂತ ಡೇಟಾದೊಂದಿಗೆ ನಿಮ್ಮ ಸ್ವಂತ ಪರಿಸರದಲ್ಲಿ PostgreSQL ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಬೇಕು ಮತ್ತು ಕನ್ ಕರನ್ಸಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸಬೇಕು (ಇಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ 50 ಸಮಾನಾಂತರ ವಿನಂತಿಗಳು ಎಲ್ಲಾ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಸೂಕ್ತವಾಗದಿರಬಹುದು). Postgres shared_buffers ಮೌಲ್ಯವು ನಿಮ್ಮ ವಾಸ್ತವಿಕ ಕಂಟೇನರ್ ಮೆಮೊರಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಗಳು ಅಥವಾ ವಿಧಾನಗಳನ್ನು ಅವಲಂಬಿಸುವ ಮೊದಲು, ಮೂಲ ಆಕರ ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಮೂಲಸೌಕರ್ಯವನ್ನು ಸಂಪರ್ಕಿಸಿ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• EDRSR ಎಂದರೇನು ಮತ್ತು ಉಕ್ರೇನ್ ಎಲ್ಲಾ ನ್ಯಾಯಾಲಯದ ತೀರ್ಪುಗಳನ್ನು ಸಾರ್ವಜನಿಕರಿಗೆ ಏಕೆ ಮುಕ್ತಗೊಳಿಸುತ್ತದೆ?
• Vector embeddings ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಮತ್ತು ಕಾನೂನು ದಾಖಲೆಗಳಿಗಾಗಿ ಅವು ಕೀವರ್ಡ್ ಸರ್ಚ್‌ಗಿಂತ ಏಕೆ ಉತ್ತಮವಾಗಿವೆ?
• Pinecone ಅಥವಾ Milvus ನಂತಹ ಇತರ ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್‌ಗಳ ಬದಲಿಗೆ ತಂಡವು Qdrant ಅನ್ನು ಏಕೆ ಬಳಸಿತು?
• GIL ಡೆಡ್‌ಲಾಕ್ ಎಂದರೇನು ಮತ್ತು ಕನ್ ಕರನ್ಸಿ 70 ಪೈಪ್‌ಲೈನ್ ಹ್ಯಾಂಗ್ ಆಗಲು ಏಕೆ ಕಾರಣವಾಯಿತು?
• ಚೆಕ್‌ಪಾಯಿಂಟ್-ಆಧಾರಿತ ಪುನರಾರಂಭ (checkpoint-based resume) ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದು ಎಷ್ಟು ಮರುಪ್ರಾರಂಭದ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ?
• ಕಂಟೇನರ್ ಮೆಮೊರಿ ಮಿತಿಗಳೊಂದಿಗೆ PostgreSQL ಕಾನ್ಫಿಗರೇಶನ್ ಜೋಡಣೆಯು ಏಕೆ ಅತ್ಯಂತ ಪ್ರಮುಖವಾಗಿದೆ?
• 33.7M ದಾಖಲೆಗಳಲ್ಲಿ Voyage AI ಮತ್ತು OpenAI embeddings ನಡುವಿನ ವೆಚ್ಚದ ವ್ಯತ್ಯಾಸವೇನು?
• 63M+ ವೆಕ್ಟರ್ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಸೆಮ್ಯಾಂಟಿಕ್ ಸರ್ಚ್ ಕ್ವೆರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ?

ಟ್ಯಾಗ್‌ಗಳು

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