Backups, Migrations और Re-Embedding

Index दोबारा बन सकता है, खोया पाठ नहीं

तय करें सत्य का स्रोत क्या है। मूल दस्तावेज़ और उनका metadata अपूरणीय हैं; vectors और ANN indexes दोबारा बन सकते हैं (समय और embedding शुल्क की क़ीमत पर), इसलिए स्रोत सुरक्षित रखें और index को व्युत्पन्न, दोबारा बनने योग्य वस्तु मानें, फिर भी recovery छोटी करने के लिए उसका backup लें। Engine की प्रणाली उपयोग करें: PostgreSQL के लिए point-in-time recovery सहित pg_dump/base backups, समर्पित engines के लिए snapshots, और नियमित restore परीक्षण। नए embedding model या आयाम के लिए vectors कभी न मिलाएँ: नई collection या index बनाएँ, सब दोबारा embed करें, golden set पर गुणवत्ता की तुलना करें, traffic बदलें (alias या config), और rollback के लिए पुराना रखें। अपना schema version करें और डेटा के साथ मॉडल नाम, संस्करण और chunking settings दर्ज करें। आपदा बहाली की योजना बनाएँ: restore में कितना समय, कितना डेटा खोना सह सकते हैं (RPO) और कितनी देर बंद रह सकते हैं (RTO)।

मॉडल-upgrade runbook

Search तोड़े बिना embedding model बदलने के चरण।

1. create collection/index "docs_v2" (new dimension / metric if the model changed)
2. re-embed all source text with the NEW model; write idempotently by deterministic id
3. build the ANN index; check counts and a recall sample vs exact search
4. run the golden-set evaluation on v1 and v2; compare recall@k and MRR
5. shadow traffic: send real queries to both, compare results and latency
6. switch the alias/config from docs_v1 to docs_v2 (instant, reversible)
7. keep docs_v1 for a rollback window, then delete it (and its backups, per retention policy)

Restore का अभ्यास करें

जिस backup को कभी restore नहीं किया वह आशा है, योजना नहीं। बहाली का अभ्यास करें और समय मापें।

त्वरित जाँच: नए embedding model पर कैसे बदलना चाहिए?

• मॉडल बदलें और पुराने vectors रखें
• पुराने और नए vectors एक ही index में मिलाएँ
• नया index बनाएँ, सब दोबारा embed करें, तुलना करें, फिर rollback विकल्प के साथ बदलें
• स्रोत हटाएँ