Векторлық базаға rebuild қашан қажет екенін қалай түсінуге болады

Векторлық базада жою орындалса, орын мен граф сол сәтте босай қалады деген сөз емес. Қолданба үшін нүкте жоғалды: іздеу оны қайтармауы керек. Ал индекс үшін ол tombstone-жазбасы, upsert кезіндегі ескі нұсқа немесе қозғалтқыш кейінірек тазалайтын сегменттің бөлігі болып қалуы мүмкін. Логикалық және физикалық жою арасындағы осы алшақтық артық кідіріске, жадтың өсуіне, ұсақ сегменттерге және кей жағдайда іздеу сапасының төмендеуіне әкеледі.

Rebuild апталық әдетке айналмауы және әр batch delete-тен кейін іске қосылмауы керек. Қызмет көрсету режимі өлшенетін болуы қажет: жиналған жоюларды бөлек есептеңіз, өзгерістер қарқынын бөлек бақылаңыз, бақылау сұрауларындағы сапаны тексеріңіз және фондық компакция үлгеріп жатқанын бағалаңыз. Сирек өзгеретін коллекциядағы бір пайыз артық дерек маңызды емес. Ал белсенді жаңартылатын HNSW индексінде сағат сайын қосылатын сол бірнеше пайыздың өзі шешім қабылдауды талап етеді.

Жойылған нүкте индексте қалып қоюы мүмкін

Логикалық жою нүктені нәтижеден жасырады, ал физикалық жою сақтау құрылымдарын босатып, индексті сол нүктесіз қайта құрады. Бұл екі оқиғаны шатастыру қауіпті: команда delete сәтті орындалғанын көріп, коллекция кішірейіп, жылдамырақ болды деп ойлайды. Әдетте бұл дұрыс емес.

HNSW графы төбелер арасындағы байланыстарды сақтайды. Қозғалтқыш нүктені жойылған деп белгілесе, оны соңғы нәтижеден алып тастауы мүмкін, бірақ графты аралау кезінде бұл төбе әлі кездеседі. Іздеу кейін алып тастайтын кандидатқа есептеу ресурсын жұмсайды. Бір жою кезінде бұл байқалмайды. Құжаттар ұзақ уақыт бойы қайта-қайта ауыстырылса, әр сұрауда артық жұмыс көбейеді.

Сегменттік қоймалар мәселені тағы бір қабатқа күрделендіреді. Жаңа нүктелер жаңа немесе өсіп жатқан сегментке түседі, ескілері мөрленген сегментте қалуы мүмкін, ал жарамды жазбалар көптеген ұсақ бөлікке шашырайды. Сұрау бірнеше индексте іздеу жасап, ішінара кандидаттарды жинап, нәтижені біріктіруі керек. Бұл кезде тірі векторлар саны мүлде өзгермеуі мүмкін.

Qdrant құжаттамасында жою soft delete ретінде, яғни биттік маска арқылы сипатталған: индекс әр delete-тен кейін қайта құрылмайды. Құжаттамада жаңарту кезінде жиі ескерілмейтін маңызды жайт та бар: дәл сол деректері бар қолданыстағы нүктеге жасалған upsert алдыңғы нұсқаны жойылған деп белгілеп, жаңа көшірме енгізеді. Демек, бүкіл корпусты әр түн сайын тексерусіз қайта жазатын пайплайн құжаттар саны өзгермесе де техникалық қарыз жинайды.

Бұл upsert-ке тыйым салу керек дегенді білдірмейді. Кезек хабарламаны қайталағанда idempotent жүктеу қажет. Бірақ бизнес-логика үшін idempotent болу физикалық индекс үшін шығынсыз деген сөз емес. Құжат мәтінінің жаңа нұсқасы, жаңа embedding моделі келгенін немесе тек хабарлама қайталанғанын білмесеңіз, векторды әдетпен қайта жібермеңіз.

Жоюдан бөлек тағы бір санатты ажыратқан жөн: көріністің өзгеруі. Embedding моделін, өлшемділікті, қашықтық метрикасын немесе нормализация әдісін ауыстырсаңыз, ескі векторлар сол деректердің бұрынғы нұсқасы болып қалмайды. Оларды компакция арқылы «емдеу» мүмкін емес. Мұндай өзгеріске қатар жұмыс істейтін жаңа коллекция және бастапқы құжаттарды толық қайта индекстеу қажет.

Жою үлесі жалғыз өзі шешім бермейді

Tombstone-жазбаларының үлесі пайдалы, бірақ коллекцияның қаншалықты тез артық дерек жинайтынын және оның сұрауларға қаншалықты кедергі келтіретінін көрсетпейді. Rebuild туралы шешім үшін кемінде төрт бақылау қажет: физикалық жазбалар саны, тірі жазбалар саны, ауыстыру қарқыны және іздеудің әрекеті.

Екі есептік көрсеткіш жүргізіңіз. Біріншісі индекс орнының қанша бөлігі өзекті емес нүктелерге тиесілі екенін көрсетеді:

removed_ratio = deleted_or_superseded / physical_points

physical_points = live_points + deleted_or_superseded

Екіншісі бақылау терезесіндегі churn көрсеткішін береді. Ол «қанша артық дерек жиналды?» деген сұраққа емес, «тазалау жазу ағынына үлгере ме?» деген сұраққа жауап береді:

update_churn_7d = updated_or_reinserted_points_7d / live_points

Churn-ды тек ашық delete бойынша есептеуге болмайды. Оған сол ID бойынша векторды ауыстыру, құжаттарды қайта өңдеу, chunking өзгергеннен кейін embeddings қайта есептеу, TTL аяқталуы және құжаттарды tenant-тер арасында көшіру кіреді. Бір аптада тірі корпустың 30%-ын қайта жазып, фондық тапсырмалар deleted ratio көрсеткішін 18%-дан 12%-ға түсірсеңіз, база сауықты деген сөз емес. Ол тек жарыста баяуырақ ұтылып жатыр.

Бұл есептегіштерге үш эксплуатациялық метриканы қосыңыз:

• кәдімгі сүзгілері бар негізгі search-сұрауының p50, p95 және p99 latency мәндері;
• тұрақты сұраулар жиынындағы recall@k немесе nDCG@k және белгіленген релевантты құжаттар;
• қозғалтқыш бұл деректерді берсе, сегменттер саны және индекстелмеген не өсіп жатқан сегменттердің көлемі.

Мұнда орташа кідіріс дерлік пайдасыз. Сегменттік фрагментация мен tombstone тазалауы алдымен үлестірімнің құйрығына әсер етеді: бір сұрау жүктемесі жоғары шардқа, екіншісі қайта құрылып жатқан сегментке, үшіншісі тым көп ұсақ сегментке түседі. Орташа көрсеткіш тыныш көрінеді, ал пайдаланушы әдеттегіден бірнеше есе ұзақ күтеді.

Іздеу сапасында да екі түрлі ақау бар. Біріншісі қозғалтқыш зақымдалған немесе толып кеткен құрылымнан жеткілікті тірі кандидаттарды тез таба алмаған кезде көрінеді. Екіншісі latency үшін дайын емес сегменттер іздеуден шығарылғанда пайда болады. Qdrant FAQ бөлімінде тікелей ескерту бар: индекстелмеген сегменттерден іздеу кезінде кідіріс өседі, ал indexed_only немесе prevent_unoptimized қосылғанда нәтижелер толық болмауы мүмкін. Бұл жауаптың болжамдылығына айырбас ретінде нәтиже толықтығын саналы түрде төмендету, яғни бағасыз «оңтайландыру» емес.

Қызмет көрсету шектері өлшем мен churn-ды ескеруі керек

Жұмыс істеп тұрған коллекция үшін барлық жағдайға бір сиқырлы пайыз белгілемес едім. Үш аймақ енгізіп, әрқайсысын іздеудің бақыланатын күйімен байланыстырар едім. Бұл шектер өлшеудің орнын баспайды, бірақ командаға ортақ тіл береді.

Жасыл аймақ: 10%-ға дейін

Жойылған немесе ауыстырылған нүктелер үлесі 10%-ға дейін болса, әдетте бақылау жеткілікті. Тек есептегіш әдемі көрінсін деп қолмен rebuild іске қоспаңыз. p95 пен recall базалық деңгейге жақын екенін, ал фондық процестер ірі batch-операциялардан кейін ескі жазбаларды шынымен азайтып жатқанын тексеріңіз.

Өте шағын сегменттер үшін ерекшелік бар. 500 нүктелі сегментте 50 жою да 10% береді, бірақ метадеректер мен fan-out шығыны коллекция бойынша жалпы пайыз көрсеткеннен маңыздырақ болуы мүмкін. Сондықтан тек жиынтық көрсеткішке емес, сегменттер мен шардтар бойынша таралуға қараңыз.

Сары аймақ: 10%-дан 20%-ға дейін

Бұл аймақта компакцияны жоспарлаңыз, әсіресе churn жоғары болса немесе p95 өсе бастаса. Пайдаланушы мәселені байқағанша күтпеңіз. Алдымен фондық оңтайландыру іске қосылып тұрғанын және оған CPU, жад пен I/O жеткілікті екенін тексеріңіз. Ол жұмыс істеп, бірақ тыныш кезеңнен кейін жою үлесін азайтпаса, кезегін, параллелизм шектерін және бос орынды тексеріңіз.

20% кездейсоқ алынған сан емес. Qdrant Vacuum Optimizer конфигурациясының мысалында deleted_threshold параметрі 0.2 мәніне тең, ал сегмент оңтайландыруға түсу үшін кемінде vacuum_min_vector_number нүктесіне ие болуы керек. Құжаттама мұны міндетті норма емес, критерийлердің мысалы деп атайды. Оны бастапқы бағдар ретінде қолданып, кейін өз өлшемдеріңізге қарай түзетіңіз.

Қызыл аймақ: 20%-дан жоғары немесе пайызға қарамастан деградация

Мән 20%-дан асса, тазалаудың нақты жоспарын жасап, уақыт аралығын белгілеңіз. 30-35% деңгейінде коллекция пайдаланудан шығарылуға жақын болмаса, мен мұны міндетті жұмыс деп қабылдаймын. Белсенді базада жаңарту ағыны жалғасып тұрғанда мұндай өлі жазбалар көлемі өздігінен сирек жоғалады.

Алайда қызыл аймақ үлес аз болғанда да басталады, егер мына шарттардың бірі орындалса: p95 немесе p99 базалық деңгеймен салыстырғанда тұрақты нашарласа, бақылау жиынындағы recall төмендесе, әр batch-upsert-тен кейін сегменттер саны өссе немесе optimizer кезекті өңдеуге үлгермесе. Бұл дөңгелек саннан маңызды. 8% tombstone және тәулігіне корпустың 25%-ын жаңартатын коллекция 22% көрсеткіші бар дерлік статикалық индекске қарағанда нашар күйде болуы мүмкін.

Бұл режимді толық қайта индекстеумен шатастырмаңыз. Векторлар мен индекс параметрлері өзгермесе, алдымен физикалық сегменттерге компакция немесе rebuild қажет. Бастапқы деректерден толық қайта жүктеу индекстің өзін өзгерткіңіз келсе, пайплайндағы тарихи ақауды түзетсеңіз немесе қазіргі деректердің тұтастығына сенбесеңіз ғана орынды.

Фрагментация тек tombstone-жазбаларынан тұрмайды

Фрагментация тірі деректер тым көп физикалық бөлікке немесе граф құрылымына бөлініп кеткенін білдіреді. Tombstone-дар оны күшейтеді, бірақ мәселе мұнымен шектелмейді. Жою үлесі нөлге жақын болса да, жиі орындалатын шағын жүктемелерден кейін ондаған ұсақ сегмент бойынша іздеу үшін ақы төлеуіңіз мүмкін.

Milvus бұл механизмді мөрленген сегменттер арқылы жақсы көрсетеді. Оның командасы Force Merge операциясын шағын sealed segments сегменттерін ірі сегменттерге біріктіру ретінде сипаттайды. Әйтпесе әр сұрау осындай сегменттердің әрқайсысынан іздеп, ішінара нәтижелерді біріктіреді. Жарияланған бақыланатын тестте HNSW бар миллион 768 өлшемді вектордан тұратын статикалық коллекцияда сегменттерді біріктіру QPS көрсеткішін едәуір өсіріп, p99 мәнін төмендеткен. Бұл сіздің кластеріңізге берілген уәде емес, бірақ себеп жалпы: fan-out әр сұрауда ресурс талап етеді.

Сондықтан мониторингке removed_ratio ғана емес, мына белгілерді де қосыңыз:

• live count өзгермесе де сегменттер саны өседі;
• түнгі жүктемеден кейін p99 нашарлайды, ал deleted ratio дерлік өзгермейді;
• кейбір шардтар басқаларына қарағанда айтарлықтай баяу жауап береді;
• кішкентай сегменттер жазу аяқталғанына қарамастан апталап кішкентай күйінде қалады;
• tenant немесе құжат түрі бойынша сүзгі қолданылғанда кандидаттар іздеуден кейін жиі алынып тасталады.

Соңғы тармақ сүзгі мәселесі сияқты көрінеді, бірақ ол деректердің физикалық ұйымдасуымен байланысты. Егер бір шард көптеген tenant нүктелерін сақтап, сұрау тек бір tenant-ті алса, HNSW жарамсыз кандидаттардың көп санын аралауы мүмкін. Rebuild нашар шардтау стратегиясын өзі түзетпейді. Ол артық жұмысты уақытша ғана азайтады.

Фрагментацияны тек диск көлемі бойынша бағаламаңыз. Квантизация, payload, журналдар, репликация және файлдық жүйе көріністі бұрмалайды. Көлем rebuild сыйымдылығы үшін маңызды, бірақ іздеуді оңтайландыру туралы шешім сегменттер санына, жұмыс кезіндегі кідіріске және сапаға сүйенуі керек.

Жиі жаңартуларды жаппай қайта индекстеуден ажырату керек

RAG жүйелеріндегі ең жиі қате былай көрінеді: crawler тәулігіне бір рет құжаттар жиынын алып, өзектілікті сақтау оңай болғандықтан әр chunk үшін upsert жібереді. 2 миллион chunk ішінен шын мәнінде 40 мыңы өзгерсе, 40 мың пайдалы жаңарту үшін шамамен 2 миллион ескі нұсқа жасау қаупін тудырасыз.

Дұрыс жол векторлық базадан бұрын басталады. Әр құжат үшін контент хешін, chunking схемасының нұсқасын, embedding моделінің атауын және мәтінге әсер етсе, промпт немесе препроцессор нұсқасын сақтаңыз. Осы шарттардың кемінде бірі өзгергенде ғана жаңа вектор қажет. Бір құжаттың қайталанып жеткізілуі embedding пен жазу операциясына түспеуі керек.

Практикалық минималды келісім мынадай болуы мүмкін:

{
  "id": "policy-431:chunk-07",
  "content_sha256": "...",
  "chunking_version": "2026-06",
  "embedding_model": "text-model-v4",
  "embedding_version": "v4.2",
  "source_updated_at": "2026-07-21T03:14:00Z"
}

Жаңа вектор жасамас бұрын сақталған өрістерді кіріс құжатымен салыстырыңыз. Хеш пен нұсқалар сәйкес келсе, жазуды өткізіп жіберіңіз. Тек қозғалтқыш векторды ауыстырмай жаңарта алатын metadata параметрі өзгерсе, тек payload-ты жаңартыңыз. Мәтін, chunking немесе embedding моделі өзгерсе, жаңа вектор жасап, оны churn есебіне саналы түрде қосыңыз.

Бұл бөлу тағы бір пайда береді: индекстің қалыпты күнделікті өмірін миграциядан ажырата аласыз. Бүкіл корпус үшін embedding_version өзгерсе, қатар жұмыс істейтін коллекция, сапаны бағалау және оқырмандарды ауыстыруы бар бөлек жоба іске қосылуы керек. Оны «құжаттарды жаңартатын» әдеттегі job ішіне жасыруға болмайды. Әйтпесе 80% нүкте ауысып, optimizer кезегі толып, нәтижелердің қайсысы ескі вектор кеңістігіне тиесілі екенін түсіндіру мүмкін болмайды.

Ірі жүктемелерді батчпен жазып, жүктеу аяқталғаннан кейін қозғалтқышқа индекстеуді аяқтауға мүмкіндік берген дұрыс. Сонда ол әр мың нүктеден кейін құрылымдарды қайта құрмайды. Qdrant құжаттамасында optimizer бастапқы жаппай жүктеу кезінде индекстеуді уақытша өшіріп, кейін қайта қосуды ұсынады. Бұл тәсіл бақыланатын жүктеуге жарайды, бірақ сұраулар жаңа деректерді көруі тиіс үнемі қолжетімді коллекцияға арналмаған.

Rebuild бір есептегішке емес, екі сигналға сүйеніп іске қосылады

Шешімді деректер күйі мен сервистің күйін бірге ескеретін ереже ретінде рәсімдеген жөн. Тек жою есептегіші артық жұмысты іске қосады. Тек latency белгілерді емдеуге мәжбүр етеді. Екеуі бірге түсінікті триггер береді.

Әр маңызды коллекция үшін сәтті жүктеу мен оңтайландырудан кейін базалық деңгейді белгілеңіз. Бұл тест ноутбугіндегі «идеалды» сандар емес, нақты жүктемедегі p50, p95, p99, recall@10 немесе recall@20, индекс көлемі, сегменттер саны және жою үлесі болуы керек. Содан кейін мынадай ереже жасаңыз:

Компакцияны жоспарлау керек, егер:
removed_ratio >= 0.20
және update_churn_7d >= 0.05

Жедел диагностика іске қосылады, егер:
p95_latency > baseline_p95 * 1.25
немесе recall@10 базалық деңгейден келісілген шектен артық төмендесе
немесе optimizer кезегі екі бақылау аралығы қатарынан өссе

Жаңа коллекцияда rebuild жүргізіледі, егер:
embedding_model, өлшемділік немесе distance metric өзгерсе
немесе HNSW/квантизация параметрлері жаңа физикалық индексті талап етсе

1,25 көбейткіші физика заңы емес. SLO әлі бапталмаған болса, ол бастапқы шек ретінде пайдалы. Пайдаланушы SLA-сы қатаң сервиске азырақ деградация рұқсат етілуі мүмкін. Түнгі аналитикалық процесс үшін көбірек болуы ықтимал. Ең маңыздысы, ереже коллекцияны бөгде benchmark-пен емес, өзінің бұрынғы күйімен салыстыруы керек.

Recall-ды іздеуіңізді көрсететін жиынтықта тексеріңіз. Support жүйесінде бұл күтілетін мақалалары бар клиент сұрақтары болуы тиіс. Тауар каталогында нақты іздеу сұраулары мен қолмен тексерілгеннен кейінгі кликтерді қолданыңыз. Құжаттарды ішкі іздеуде қызметкерлердің сұрақтары мен дұрыс жауап деп санайтын құжаттарын алыңыз. Базада жатқан мәтіндердің өзінен жасалған синтетикалық сұраулар индекске әдетте тым жеңіл болады.

Сапаны бағалауды ef немесе nprobe өсуімен алмастырмаңыз. Бұл параметрлер кейде пайдалы авариялық тетік болады: latency есебінен recall аласыз. Бірақ команда фрагментацияны search breadth өсіру арқылы айлар бойы өтесе, әр сұрауда артық дерек үшін төлейді. Алдымен коллекцияның физикалық күйін реттеңіз, содан кейін іздеу параметрлерін таңдаңыз.

Қауіпсіз rebuild оқу үшін екінші жолды талап етеді

Команда жалғыз жұмыс істеп тұрған коллекцияны қайта жазып, фондық тапсырмалар трафиктен бұрын үлгеретініне үміт артса, толық қайта құру қауіпті. Қайта өндірілетін дерек көзінен жаңа нұсқа жасап, тек тексеруден кейін оқырмандарды ауыстырған қауіпсіз.

Реті мынадай:

1. Кіріс snapshot-ын бекітіңіз: құжат көзі, chunking ережелері, embedding моделі нұсқасы, метрика, индекс параметрлері және payload схемасы.
2. Версиясы бар атаумен жаңа коллекция жасаңыз. Валидация кезінде ескі коллекцияны өзгертпеңіз.
3. Векторларды батчпен жүктеп, индекс құрылғанша күтіңіз. Көлем, сегменттер және индекстеу уақыты метрикаларын тіркеңіз.
4. Бақылау сұрауларының жиынын ескі және жаңа коллекцияда орындаңыз. Latency-мен қатар top-k құжаттарын, сүзгілерді және бизнес-дедупликация ережелерін салыстырыңыз.
5. Оқуды alias, қолданба конфигурациясы немесе маршрутизация қабаты арқылы ауыстырыңыз. Ескі коллекцияны келісілген rollback кезеңіне қалдырып, кейін жойыңыз.

Сізге қосымша сыйымдылық қажет болады. Rebuild кезінде бастапқы векторлар, жаңа коллекция, аралық сегменттер және кейде репликация кезіндегі көшірмелер қатар тұрады. Қазіргі индекс үшін диск әрең жетсе, ескі нұсқаны жою орынды босатады деп үміттеніп қайта құруды бастамаңыз. Ол ең соңында жойылады.

Qdrant сегмент rebuild-ін copy-on-write арқылы сипаттайды: қайта құру жүріп жатқанда ескі сегмент оқуға қолжетімді болып қалады, ал өзгерістер басым қабатқа түседі. Бұл онлайн-оңтайландыруға ыңғайлы модель, бірақ ресурс жүктемесін жоймайды және толық дерек миграциясы кезінде ауыстыру сынағын алмастырмайды.

Rebuild кезінде жаңа жазба келетін жағдайды да тексеріңіз. Егер жаңа коллекция бір batch-процеспен толтырылып, ескі коллекция пайдаланушылар тарапынан жаңартыла берсе, ауысу сәтінде өзгерістердің соңғы бөлігін жоғалтасыз. Шешімді алдын ала таңдаңыз: жазуға қысқа үзіліс, екі коллекцияға қатар жазу немесе cutover алдында жаңа нұсқаны қуып жететін өзгерістер журналы. Жүктемесі жоғары сервис үшін журнал мен айқын watermark дұрыс. «Тез ауысамыз» деген сөз келісімділік стратегиясы емес.

Әртүрлі қозғалтқыштардың тазалау механизмдері әртүрлі

Rebuild термині әртүрлі операцияларды жасырады. Құжаттамадағы сөздер ұқсас болғаны үшін бір қозғалтқыштың баптауын екіншісіне көшірмеңіз.

Qdrant-та vacuum optimizer сегменттерді жойылған векторлардың үлесі мен векторлардың ең аз санына қарай таңдайды. Ол сегменттерді біріктіріп, индекстер де құрады. Optimizer кіріс ағынынан қалып қоймағанын бақылау пайдалы. Квантизация қолдансаңыз, бастапқы full precision vectors мәндерін сақтаңыз: Qdrant құжаттамасында олар Vacuum Optimizer кезінде квантталған көріністерді қайта есептеу үшін қажет делінген. Орын үнемдеу үшін бастапқы векторларды жойып, кейін дұрыс rebuild күтудің мәні жоқ.

Milvus-та компакция sealed segments сегменттерімен жұмыс істеп, Time Travel сақтау уақытынан тыс жойылған нысандарды тазартады. Оның конфигурациясы сегмент өлшемі мен эксплуатация сапасының байланысын да көрсетеді: шағын сегменттер біріктіріледі, ал нәтиженің рұқсат етілген өлшемі dataCoord.segment.expansionRate арқылы реттеледі. Milvus-ты тек delete пайызы бойынша бағаламаңыз. Әр сұрауға нақты қанша sealed segment қызмет көрсететінін қараңыз.

Weaviate-та HNSW индексі tombstone-дарды және мерзімді тазалауды қолданады. Құжаттама tombstone саны, cleanup циклі барысы және тазалау ағындарының саны метрикаларын бақылауды ұсынады. Үлкен индекстер үшін тазалау бірден барлық CPU-ды алып қоймауы және шексіз созылмауы үшін бір циклдегі жоюлардың жоғарғы және төменгі шектері де бар. Бұл дұрыс тепе-теңдіктің жақсы мысалы: тазалау ресурстарды іздеуден тартып алса, агрессивті тазалау сервисті үнемі жылдамдата бермейді.

hnswlib-та mark_deleted арқылы жою элементті белгілейді, ал кітапхана allow_replace_deleted және replace_deleted=True арқылы жойылған слоттарды қайта пайдалануға мүмкіндік береді. Бұл ендірілген немесе жергілікті индекстерге пайдалы, бірақ слотты қайта пайдалануды граф құрылымының толық профилактикасы деп қабылдамаңыз. Жұмыс жиыны үнемі өзгерсе, тек capacity емес, latency мен recall-ды да өлшеңіз.

Жалпы қорытынды қарапайым: алдымен нақты қозғалтқыштың ескі нұсқаларды қалай сақтайтынын, тазалауды қашан іске қосатынын, оңтайландыру кезінде оқуға не болатынын және қандай метрикаларды беретінін анықтаңыз. Содан кейін шектерді таңдаңыз. Сегменттік базаға жақсы жұмыс істейтін конфигурация бір in-memory HNSW файлы үшін ештеңе білдірмеуі мүмкін.

Индекс архитектурасы болашақ тазалау көлемін анықтайды

Деректердің өмірлік циклі схеманың өзінде көрінсе, қызмет көрсету айтарлықтай жеңілдейді. Embedding өлшемділігі бірдей болғаны үшін ғана әртүрлі жылдамдықта ескіретін құжаттарды бір коллекцияға жинамаңыз.

Саясаттар, нұсқаулықтар мен архивтерден тұратын дерлік өзгермейтін корпусты тауар карточкаларынан, сессиялардан, тапсырыс күйлерінен немесе хабарламалардан бөлек ұстаңыз. Статикалық коллекция фрагментациясыз айлар бойы жұмыс істей алады. Жедел деректер коллекциясына басқа шек, сегменттердің кіші өлшемі және компакцияға бөлек бюджет қажет. Оларды араластырсаңыз, жиі жаңартулар суық корпусты да тұрақты қызмет көрсетуге мәжбүр етеді.

Multi-tenant іздеу үшін өте маңызды себеп болмаса, әр пайдаланушыға жеке коллекция жасамаңыз. Бұл индекстер санын көбейтіп, қызмет көрсетуді қиындатады. Бірақ ойластырылған shard key-і жоқ бір ортақ индекс те мәселені шешпейді. Гранулярлықты tenant өлшеміне, жаңарту жиілігіне және сүзгілер сипатына қарай таңдаңыз. Каталогын сағат сайын қайта жазатын ірі tenant мыңдаған шағын клиенттің деректерін үнемі фрагментацияламауы тиіс.

Бастапқы мәтінді немесе оған сенімді сілтемені векторлық базадан тыс сақтаңыз. Rebuild жойылатын коллекцияда ескі payload өрістері кездейсоқ сақталып қалғанына тәуелді болмауы керек. Сізге қайта өндірілетін құжаттар, deterministic chunking және embedding параметрлерінің нұсқалары қажет. Бұлар болмаса, кез келген қайта құру қазба жұмысына айналады: команда жаңа нұсқаны тексерудің орнына индекстің қандай кодпен жасалғанын анықтауға уақыт жұмсайды.

AI Router бұл схемада модельдерге OpenAI-мен үйлесімді бірыңғай жол және residency пен latency маңызды болғанда open-weight модельдерді Қазақстандағы инфрақұрылымда орналастыру нұсқасы ретінде орынды. Бірақ ол деректер тәртібін алмастырмайды: rebuild уақытын таңдау коллекция метрикалары мен embeddings-тің бақыланатын өмірлік цикліне байланысты.

Жаман әдетті алғашқы аварияға дейін түзету арзанырақ

Индекс анық баяулағанша күтпеңіз. Алғашқы жүктеуден кейін бірден baseline енгізіңіз, tombstone мен churn-ды бөлек өлшеңіз, ал жаппай өзгерістерді миграция ретінде рәсімдеңіз. Сонда rebuild p99 кестесіне қарап түнде жасалатын алаңдатарлық операция емес, ережелер бойынша орындалатын қалыпты жұмысқа айналады.

Егер қазірдің өзінде кідірісі өсіп жатқан коллекция болса, жою мен қайта жүктеуден бастамаңыз. Live count, физикалық count, жою үлесін, сегменттер санын, p95, p99 және бір сұраулар жиынындағы recall-ды тіркеңіз. Жаппай жаңартулар тоқтағаннан кейін бір тәулік өткен соң өлшемді қайталаңыз. Optimizer жағдайды өзгертпесе, компакцияға немесе коллекцияның жаңа нұсқасына негіз бар. Ал өзгерсе, сіз «векторлық базадағы мәселені» емес, ingestion-пайплайнда түзетілуі тиіс тым жылдам өзгеріс ағынын таптыңыз.