On‑prem RAG үшін векторлық дерекқор: жабық контурға сай таңдау

Неліктен on‑prem RAG үшін векторлық дерекқорды таңдау жиі ұсталып қалады

Ашық ортада көпшілік «ең танымал шешімді алайық және кімде‑кім жасағанын қайталайық» деп ойлайды. On‑prem үшін бұл сирек жұмыс істейді. Жабық контурда маңыздысы — әдемі бенчмарк емес, жүйенің апталар бойы бұлтты сервистерге, маркетплейстерге немесе «жылдам фикстерге» қолжетімсіз жағдайда қалай өмір сүретіні.

Бірінші себеп — пилот пен эксплуатация арасындағы үзіліс. 50 мың құжаттан тұратын тестте бәрі жылдам етеді. Ал іске қосқанда көбіне RAM‑ға «ұрып» қалады: индекстер үлкейеді, кэш пайдалы деректерді ығыстырады, күтпеген кешігулер шығады.

Екінші себеп — «қызықсыз» талаптарды ұмыту: диск, бэкаптар және қалпына келтіру. Пилотта сирек тексереді: индекстер 3–6 айдан кейін қанша орын алады, қайта құрылысы қанша уақыт алады, тоқтау кезінде не болады. Мұнда қымбат тосындар шығады: ұзақ қалпына келтіру, нүктелі кері қайтара алмау, сервисті тоқтатпай консистентті бэкап ұйымдастырудың қиындығы.

Үшінші себеп — бизнестің алдын ала болжам талабында болуы. Жабық контурда әдетте тұрақтылық, иеліктің түсінікті құны және деректерге бақылау жылдамдықтан маңыздырақ. Талаптар SLA ретінде айқындалып, инфрақұрылым шектеулері белгіленбесе, таңдау тежеледі. Мысалы, егер кластер жергілікті серверлерде тұрса, қандай дисктер қажет, қалай репликация жасалған және қанша RAM резервке қалдыру керек — бәрі маңызды болады.

On‑prem RAG қалай жұмыс істейді және векторлық БД‑нің рөлі

On‑prem RAG — іздеу мен жауап генерациясы жабық контурда, сыртқа деректер шығармайтын жүйе. Типтік схемада екі режим бар: жүктеу (индексация) және сұраныстарға жауап (іздеу және генерация).

Жүктеу кезеңінде құжаттар файл жүйесінен, поштадан немесе ішкі жүйелерден алынады, тазаланып, фрагменттерге бөлініп, оларға эмбеддингтер есептеледі. Эмбеддингтер бастапқы мәтінмен немесе оған сілтемемен бірге сақталады. Міне, мұнда векторлық база қажет: векторларды сақтап, жылдам іздеу үшін индексті құрады және метадеректер бойынша (құжат түрі, бөлім, гриф, дата) іріктеуге көмектеседі.

Жиі қоса тағы үш компонент болады: эмбеддинг сервисі (кейде GPU‑да), жауап үшін LLM және пайплайн мен құқықтарды басқаратын оркестраторлық қосымша.

Эксплуатацияда тар жерлер көбіне күтпеген жерде шығады: индекс типі мен баптаулары, RAM (индекс пен кэш сия ма), диск (IOPS, кешігулер, үлкен бэкаптардың әсері), желі және метадеректер бойынша күрделі сүзгілер. Егер RAG өз стойкасында орналаса — векторлық БД‑нің рөлі одан әрі өседі: жүйе шыдамдылық пен ақауларды қалай көтеретініне ол көбіне әсер етеді.

Салыстырудан бұрын не жазып алу керек: деректер, SLA және шектеулер

Векторлық БД‑ларды салыстыру «кім тезірек?» деген дауға оңай түседі. Бірақ деректер мен эксплуатация ережелері болмаса, тест цифрлары көп мағыналы емес. Бір қозғалтқыш регламенттер үшін жақсы болуы мүмкін, ал тикеттер ағыны үшін ыңғайсыз.

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

Келесі — көлемді сандармен бекітіңіз: қазір қанша құжат, бір жылда қанша болады, орташа чанк өлшемі (символ немесе токен), бір құжаттан қанша чанк шығады, эмбеддинг өлшемі (мысалы 768 немесе 1536). «Ыстық» (күнделікті қолданылатынын) және «суық» деректерді бөлген абзал.

SLA‑ны қысқаша жазыңыз: 95% сұраныстарға жауап уақыты, шыңды жүктеме (QPS), қабылданатын тоқтату уақыты және қызмет көрсету терезелері, қалпына келтіру талаптары (RPO және RTO).

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

Жылдамдық: тесттерде неге назар аудару керек

RAG‑тағы жылдамдық бір ғана санға келмейді. On‑prem үшін маңызды — «ұқсас» табу қаншалықты тез, бірақ сондай‑ақ нақты сүзгілер, жаңартулар және параллельдік кезінде жағдай қандай болатынын түсіну керек.

Тесттерде p50 және p95 көрсеткіштерін тіркеңіз. p50 — «орташа» сұраныс, p95 — пайдаланушылар жиі байқайтын құйрық. Қосу ретінде индексті құру уақыты мен жүктеу немесе қайта индексация уақытын өлшеңіз.

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

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

Пилот үшін темірді, датасет пен сұрау жиынтығын тұрақты ұстаңыз. Мысалы, мемлекеттік орган үшін: сұраулардың 70%‑ы бөлім және қолжетім деңгейі бойынша фильтрленеді, 30%‑ы фильтрсіз.

Протоколда бірнеше метрика жеткілікті: p50/p95 оқу (фильтрленген және фильтрсіз), QPS мақсатты жүктеме кезінде, жүктеу және индекстеу уақыты, импорт/жаңарту кезіндегі деградация, CPU және диск шыңдағы мәндер.

RAM тұтыну: алдын ала қалай бағалау және қателеспеу

On‑prem жобаларда жады жиі ең басты шектеу болады: диск сатып алу оңай, ал сервер профилін өзгерту үшін келісім беру қиын. Сондықтан RAM‑ды пилотқа дейін бағалау маңызды.

RAM‑ды төрт нәрсе «жейді»: векторлар өздері, іздеу индексы (көп жағдайда HNSW немесе ұқсас граф құрылымдар), кэштер (диск беттері, сұрау нәтижелері) және қызметтік құрылымдар (метадеректер, сүзгілер, сөздіктер, фондық буферлер). Ең жағымсыз сценарий — индекстің толықтай жадта тұруы міндетті болғанда және коллекция өсімі жады шегіне тез жеткенде.

Не сұрау керек:

• Индекс әрдайым RAM‑де ме немесе disk/mmap режимі бар ма (деректердің бір бөлігін диск арқылы көрсету және қажет кезде жүктеу)?
• Кэштерді шектеуге бола ма және жады лимиттерін қоюға мүмкіндік бар ма, сонда база басқа қызметтерді ығыстырмайды ма?

Шамалап бағалау осылайша басталады: «таза» вектор көлемі ≈ N × D × B. Содан кейін индекстің және қызметтік overhead‑тың шамасын қосыңыз.

Практикалық ережелер:

• Индекс пен overhead әдетте векторлар көлемінің 1.5–4× дейін алады;
• Нәтижені репликалар санына көбейтіңіз (әр репликада өз индексі бар);
• ОС пен кэштер үшін қосымша 20–30% қалдырыңыз, әйтпесе жүйе тұрақсыз болады.

Жадыны үнемдеу іздеу жылдамдығының баяулауы немесе сапасының сәл төмендеуімен келеді (мысалы, күшті сығымдау немесе «жеңіл» индекс). SLA‑ға не маңызды екенін алдын ала шешкен дұрыс, кейіннен жады тапшылығын түзету қиын болады.

Диск және сақтау: жиі ұмытылатын талаптар

On‑prem үшін диск векторлық БД‑да CPU‑дан кем маңызды емес. Қате сценарий: демо‑да бәрі жылдам, ал нақты деректер жүктелгенде жүйе жазуды ойлануды бастайды және қайта индекс кезінде, апаттан кейін қалпына келтіруде баяулайды.

Сыйымдылықтан бөлек дисктың жүктеме кезінде қалай жұмыс істейтінін қараңыз. Векторлық индекстер көптеген ұсақ оқу операцияларын жасайды, ал жаңартуларда жазбалар көбейеді. Сондықтан IOPS және кешігулер, жазу ресурсы (TBW) және контроллер сапасы маңызды. Арзан SSD‑де мәселе көлемде емес, кешігулер мен тозуда шығуы мүмкін.

NVMe параллель жүктемелерде: көптеген іздеу сұраныстары және фондық жазбалар болса, NVMe айқын артықшылық береді. Егер сұраныстар аз және жаңартулар сирек болса, сапалы SATA SSD жеткілікті болуы мүмкін — бюджетті резерв пен бэкапқа қою орынды болады.

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

Бэкап және қалпына келтіру: тосынсыйлардан қалай сақтану

On‑prem жүйелерде бэкап көбіне «админнің жұмысы» деп жазылып, кейін қалпына келтіру сағаттар алатыны немесе көшірме индексті қамтымайтыны анықталады. Векторлық БД үшін бұл аса ауыр: индекс жоғалса, қайта құру ұзаққа созылады және қызмет тоқтайды.

Үш негізгі тәсіл жиі кездеседі. Логикалық бэкаптар (деректер мен метадеректерді экспорттау) тасымалдауға және бөліп қалпына келтіруге ыңғайлы, бірақ үлкен көлемде баяу болуы мүмкін. Диск снапшоттары тез және дәл уақытша күйді сақтайды, бірақ файлдық жүйеде тіркеу тәртібі мен жазуды тоқтату тәртібін талап етеді. Деректер каталогының файлдық көшірмелері қарапайым, бірақ база жазып жатқанда қауіп тудырады.

Бэкап жиілігін RPO/RTO‑дан алуыңыз керек. Егер коллекциялар күнделікті жаңартылса, күнделікті толық көшірме жеткілікті болуы мүмкін. Егер эмбеддингтер мен құжаттар күнің бойы өзгере берсе, жиі қайталанатын чекпоинттар мен айқын жоспар керек.

Көшірмелер «қағазда ғана» болмауы үшін қалпына келтіруді жүйелі түрде тексеріңіз: айына бір рет тест стендті көтеріп, соңғы бэкаптан қалпына келтіріп тексеріңіз; тек деректер емес, іздеу сұраулары, сүзгілер мен нәтижелер сапасын да тексеріңіз; нақты қалпына келтіру уақытын өлшеп, RTO‑мен салыстырыңыз; конфигурация мен схема нұсқаларын бірге сақтаңыз.

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

Репликация және төзімділік: on‑prem үшін не таңдау керек

On‑prem RAG‑та векторлық БД‑ның сәтсіздігі іздеудің тоқтауына тез әкеледі: жауаптар «құрғаяды» және пайдаланушылар сенімінен айырылады. Төзімділікті бастапқыда жобалау керек, кейін қосу қиынырақ.

Ең аз көмектесетін нәрселер: әртүрлі серверлерге репликация, тірі түйінге автоматты ауыстырып қосу, «екі шындықтан» қорғау механизмі (кворум немесе баламалы әдіс), бақылау жүйесі (репликалар статусы, кешігулер метрикасында және логтарда).

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

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

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

Эксплуатация және қауіпсіздік жабық контурда

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

Изоляциядан бастаңыз. Жобалар немесе namespace‑тер, рөлдер мен құқықтар бар ма, коллекциялар мен метадеректерге жеке қолжетімділікті бөліп беруге болады ма. Жиі қатер — пайдаланушыға құжаттарға қолжетімі жоқ кезде қызметтік өрістер (қайнар көзі, тегтер, идентификаторлар) көрінеді.

Одан кейін аудит. Оқу, жазу, жою, схема өзгерістері және авторизация қателері логтала ма? Журналдарды қаншаға сақтау керек (7, 30, 180 күн) және олар қайда сақталады — зерттеу барысында диск жетпейтін жағдайға жол бермеңіз.

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

Мониторинг қарапайым графиктерге негізделгені дұрыс: RAM және кэш өсімі, диск толымдылығы және I/O жылдамдығы, іздеу латенттігі (p95/p99), қателер мен таймауттар. Мемлекеттік жобаларда RBAC және аудит журналдары жиі «қызыл жалауша» болып шығады, олар жылдамдықтан маңыздырақ болады.

Қызмет көрсету ыңғайлылығы: ай сайын нені үнемдейді

Тестіде жылдам болғанмен, өндірісте шешеді — қаншалықты оңай орнату, жаңарту және жөндеу жүргізуге болады интернетке қосылмай. Векторлық БД іздеу тізбегінің бір бөлігі және жауаптардың сапасына тікелей әсер етеді.

Не сұрау керек пилотқа дейін:

• Орнату қалай: бір бинарник пе немесе бірнеше сервис пе?;
• Kubernetes немесе сыртқы БД‑ге тәуелділігі бар ма?;
• түйіндер бойынша жаңартуды тоқтатпай жасау және откаттау мүмкін бе?;
• кластер үшін минималды конфигурация және түйін жоғалғанда не болады?;
• қандай метрикалар мен логтар бар, жаңа серверге қалпына келтіру қанша уақыт алады?

«Типтік ай» осылай көрінуі керек: инциденттер көбіне деградациядан — толық тоқтаудан емес. Мысалы, түнде индекс өседі, диск қалдығы 5% қалады және таңертең p95 құлайды. Ыңғайлы жүйеде метрикалардан себепті тез табасың, фондық тапсырмаларды шектей аласың, диск кеңейтіп, қауіпсіз түрде компактация жүргізесің.

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

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

Мысал сценарий: жабық желідегі ұйымға арналған RAG

Мысалы, ұйымда интернет шектелген, құжаттар ішкі ресурстарда, инфрақұрылымды жаңарту тек демалыс күндері түні бойы рұқсат етілген. Команда RAG‑ты жабық контурда, деректерді сыртқа шығармай іске қосқысы келеді. Бұл жағдайда on‑prem RAG үшін векторлық дерекқор таңдайды.

Пилотты барлық деректермен емес, нақты жүктемені көрсететін бөліктен бастаған дұрыс. Мысалы: 50 000 құжат (PDF, DOCX), 2–3 департамент, 10 типтік сұрақ және журналдан алынған 200–300 нақты іздеу сұрауы.

Пилот барысында әдетте датасет пен тазалау ережелерін бекітеді, метадеректерді орнатады (департамент, құжат түрі, дата, қолжетім деңгейі), 10–20 эталонды сұрақ пен сапа критерийлерін таңдап, жүктеу және іздеу тесттерін (p95) өткізеді.

Проблемалар тез шығады. Индекс чанктерге бөліну мен дубликаттар себебінен күткендегіден үлкен болуы мүмкін. Жүктеу төмен IOPS немесе қайта индексацияның негізгі қызметті тежейтінінен баяу болуы мүмкін. Қалпына келтіру — бөлек мәселе: жабық желіде сыртқы сақтауға сену қиын, ал толық бэкап бір серверде болса, диск жүйесінде ақау болса көмектеспейді.

Нәтижені нақты мақсаттар мен ресурстар қорымен рәсімдеңіз. Мысалы: p95 іздеу 300–500 мс шегінде N бір уақытта пайдаланушыда, түнгі жүктеу терезі 2 сағаттан аспауы керек, RPO 24 сағат, RTO 4 сағат. Бұған диск пен RAM‑қа резерв қоса, өсу жоспары мен қалпына келтіру тесттері тіркеледі.

Векторлық БД‑ны on‑prem таңдау кезінде жиі жіберілетін қателіктер

Ең жиі қателік — бір көрсеткіш бойынша (мысалы, «іздеу жылдамдығы») таңдау. On‑prem RAG деректерді жүктеу, индексация, іздеу, жаңартулар, бэкап және қалпына келтіру циклында өмір сүреді. Егер база іздеуде жылдам, бірақ жаңа құжаттарды жүктеу баяу, бэкап қиын немесе қолмен күтімді талап етсе — болжамдылық жоғалады.

Екінші қателік — өсуге дайын болмау. Коллекция жоспардан тез өседі: жаңа нұсқалар, хаттар, OCR арқылы алынған скан‑құжаттар пайда болады. Деректер көбіне дублируется: репликалар, тесттік ортаға көшірмелер, қайта құрылған уақытша индекс. Бастапқыда сыйған нәрсе 6–12 айдан кейін диск пен RAM‑ға жүк болады.

Үшінші — метадеректерсіз тестілеу. Өндірісте әдетте «тек филиалға», «тек белгілі датадан кейін» сияқты шектеулер бар. Бұл сүзгілер кешіктіру мен дәлдікке әсер етеді, сондықтан сүзгілерсіз салыстыру әдемі, бірақ шынайы емес.

Төртінші — RAM пен диск талаптарын араластыру. Егер индекстің құрылымы жадта тұруы керек болса, диск қосу мәселені шешпейді: жүйе RAM‑ға ғана «ұрып», кэшке жетпейді. Нақты не жадта және не дискте сақталатынын тексеріңіз және RAM жеткіліксіз болғанда мінез қалай өзгеретінін анықтаңыз.

Ақырында — қалпына келтіруді тексермеу. Бэкап формальдық түрде жасалып, ешқашан таза машинада жүйені одан көтеріп көрмеген кезде ауыр жағдай туындайды. Қарапайым тест: түйіннің сәтсіздігін модельдеңіз, базаны қалпына келтіріп, құқықтар, метадеректер мен индекстер дұрыс қайтып келгенін және RAG SLA шеңберінде жауап беруді жалғастырғанын тексеріңіз.

Қадамдық таңдау жоспары және пилот үшін чек‑лист

On‑prem RAG үшін векторлық БД таңдау шағын инженерлік жоба ретінде қарастырылғанда оңайырақ: нақты кіріс деректері, өз теміріңізде пилот, анықталған нәтижелер. Сонда демода әдемі көрінетін, бірақ эксплуатацияда RAM, диск немесе күрделі қолдауға ілініп қалатын шешімді алмайсыз.

Жұмыс реті әдетте былай болады: жүктемені сипаттау (коллекция өлшемі, өсу, мақсатты p95, индексация мен бэкап терезелері, қолжетімділік), жабық контур шектеулеріне сай 2–3 үміткер таңдау (on‑prem орнатуға жарайтын ОС, минимум сыртқы тәуелділік), пилотты өз инфрақұрылымда өткізу және деректермен, эксплуатацияны бағалау (мониторинг, алертер, жаңартулар, рөлдер, апатты қалпына келтіру), ресурстар мен иеліктің шығынын 6–12 айға есептеу.

Салыстыру үшін критерийлерді алдын ала келісіңіз. Мысалы: «p95 іздеу 95% сұраныстарда 250 мс‑тен баяу болмауы, бэкаптан қалпына келтіру 60 минуттан көп болмауы, репликацияның түсінікті схемасы бар болуы».

Пилот протоколы үшін қарапайым чек‑лист жеткілікті: параллель жүктеме кезінде типтік сұраныстарға p95 latency, индекстің өсуі және қайта индексация уақыты, узелдегі steady state және пиковая RAM, SSD/NVMe талаптары және диск деградациясында не болатыны, жұмыс істейтін қалпына келтіру және таңдалған репликация схемасы (апатта не жоғалатынымыз).

Финалдық таңдау критерийлер кестесімен, тәуекелдер тізімімен және масштабтаудың жоспары болу керек. Келесі қадам — сервер конфигурациясы мен орналастыру контурын бекіту пилот пен прод үшін. Егер жоба on‑prem темір таңдау мен эксплуатацияға тірелсе, мұндай тапсырмаларды жүйе интеграторы және инфрақұрылым өндірушісі, мысалы GSE.kz (gse.kz), шешеді — жеткізу, интеграция және қолдау Қазақстан ішінде қажет болғанда.