RAG үшін сақтау: деректер жинақтары мен журналдарды сақтау деңгейлері
RAG үшін сақтау: индексті NVMe-ге қою, бастапқы файлдарды бөлек қабатқа орналастыру және журналдардың өмірлік циклін орнату арқылы шығынды азайту және өнімділікті сақтау.
Неліктен RAG, датасеттер және логтар үшін сақтау қабаттарын бөлу керек
RAG қарапайым тілмен айтқанда — жүйе алдымен білім базасынан сәйкес үзінділерді тауып, содан кейін модель соларға сүйене отырып жауап құрайды. Жауаптар тез және тұрақты болуы үшін іздеуге қатысатын деректер, бастапқы файлдар және қызметтік жазбалар әртүрлі қабаттарда болғаны дұрыс.
Барлығын бір жерге салсаңыз, сақтау тез арада компромисске айналады: бір жағынан іздеу үшін төмен кешігу, екінші жағынан үлкен файлдарға арзан орын және қолайлы бэкаптар керек болады. Нәтижесінде жылдамдық та, шығын да, қалпына келтіру де зардап шегеді.
RAG жүйесінде әдетте төрт дерек класы бар:
- векторлық индекс (жылдам іздеу жүретін нәрсе)
- бастапқы құжаттар және олардың нұсқалары (PDF, DOCX, хаттар, беттер)
- оқу мен бағалау датасеттері (сұрақ-жауап, разметка, эталондар)
- логтар және трассировкалар (сұраулар, қателер, метрикалар, оқиғалар)
Олар бір жерде болса, проблемалар тез келеді. Іздеу тежеледі, өйткені жылдам дискілер қажетсіз нәрселермен толтырылады. Қымбат қабат логтармен ластанады, ал бэкаптар монолитке айналып, қалпына келтіру уақыты жоғарылайды.
Қабаттар бойынша бөлу бұл мәселені тікелей шешеді: индекске ең жылдам қол жеткізу беріледі, бастапқы файлдар мен датасеттер сенімді және арзан жерде сақталады, ал логтар анық ретеншн және көлем саясатына бағынады. Бұл шығынды бақылауды жеңілдетіп, іздеуді жылдамдатады және апаттан кейін қалпына келтіруді нақты процедура етеді.
Қандай деректер бар және олар қалай ерекшеленеді
Дұрыс схема дискі таңдау емес, әр деректің талаптарын түсінуден басталады. Барлығын бір пулға салсаңыз, не баяу іздеу шығады, не қымбат көлемге ақша кетеді, не қол жетімділік жүйесі айналады.
Векторлық индекс әдетте бастапқы файлдардан көлемі жағынан кішірек, бірақ кешігуге өте сезімтал. Оқу кезінде қосымша миллисекундтар жауап уақытын секундтарға айналдыра алады, әсіресе жүктеме жоғары болса.
Бастапқы файлдар (PDF, DOCX, презентациялар, скандер, суреттер) көлемі үлкен және оларды толықтай сирек оқиды. Бірақ олар қайтаиндекстеу, дәйексөз тексеру және құқықтық дәлдік үшін қажет. Оларды жоғалтуға болмайды және оларды уақытша файлдар сияқты басқаруға болмайды.
Оқыту және бағалау датасеттері — нұсқалар, эксперименттер және архивтер, кейде сезімтал деректер бар. Мұнда нұсқалау, қол жетімдікті бақылау және өткен нұсқаға оралу маңызды.
Логтар — көптеген кішкентай жазбалар, күнделікті өсу, құндылық уақыт өте төмендейді. Ретеншн жоқ болса, олар орын алып, маңызды жазбалар шудың арасында жоғалады.
Деректер кластарын тез ажырату үшін өзіңізге бес сұрақ қойыңыз:
- Не маңыздырақ: кешігу, өткізу қабілеті немесе көлем?
- Деректер қаншалықты жиі оқылады және қайта жазылады?
- Деректерді басқа көзден қалпына келтіруге бола ма?
- Қатаң рұқсаттар мен аудит қажет пе?
- Қандай сақтау мерзімі шынымен пайдалы?
Бэкаптар мен снапшоттарды бөлек есте сақтаңыз. Бұл "тек бір қосымша көшірме" емес, қалпына келтіру стратегиясының бөлігі. Индексті көбінесе қайта құруға болады, ал бастапқы файлдар мен датасеттер бэкапсыз мәңгі жоғалуы мүмкін.
Практикалық сақтау деңгейлері: 3 қабат
Идея қарапайым: жылдам және қымбат сақтау тек RAG жауап жылдамдығына тікелей әсер ететін жерде болсын. Қалғанын үлкенірек және арзанырақ қабаттарға ауыстырыңыз.
Қабат 1: жылдам (NVMe) — индекс және іздеу
Мұнда әр сұрауда қатысатын нәрселер жатады:
- векторлық индекс (файлдар/сегменттер)
- аз көлемді сәйкестік кестелері (мысалы, құжат id және фрагмент id)
- ыстық сұраулар мен эмбеддингтердің кэші (егер бар болса)
- жиі оқылатын іздеу қозғалтқышының қызметтік файлдары
Бұл қабатты таза ұстау маңызды. Мұнда архивтер, бастапқы файлдардың толық көшірмесі, үлкен датасеттер және ескі журналдарды салмаңыз. Олар жауап жылдамдығын жақсартпайды, бірақ орынды тез тұтынады және қызмет көрсетуді күрделендіреді.
Көлемді индекстің өлшеміне қарай жоспарлаңыз, бірақ өсу мен қайта құру үшін резерв қалдырыңыз. Практикалық ереже: ағымдағы индекс, оның өсуі және ребилдтің уақытша файлдары үшін орын қалдыру. Мысалы, егер индекс 400 ГБ болса, 1–1.5 ТБ айналасы жиі шындығында қорғаныс береді.
Сенімділік те маңызды, индексті қайта құруға болатын болса да. NVMe жоғалту — бұл тоқтап қалулар және қалпына келтіруге сағаттар кетуі мүмкін. Әдетте минимум — екі NVMe-де айна.
Жаңарту ережелерін алдын ала анықтаңыз: индексті қаншалықты жиі қайта жинайсыз (күнделікті, апта сайын, өзгерістер бойынша) және ребилдтің уақытша файлдары қайда тұрады. Ыңғайлы тәсіл — уақытша қалтаны сол NVMe-де ұстап, нақты лимитпен белгілеу, ал қайта құруға қажетті бастапқы файлдар екінші қабатта болсын.
Қабат 2: көлемді — бастапқы файлдар және датасеттер
Мұнда бастапқы құжаттар (PDF, DOCX, хаттар, OCR кейінгі скандерлер), өңделген мәтіндер мен суреттер, сонымен қатар оқу және тест датасеттері орналасады. Оларға әр сұрауда қол жеткізу қажет емес, олар қайтаиндекстеу, сапаны тексеру және даулы жағдайларды қарастыру кезінде керек болады. Сондықтан сенімділік пен құрылым жылдамдықтан маңызды.
"Қалай алғанымыз" және "өнімге не шыққаны" араласпауы үшін үш зона жасау ыңғайлы:
- raw: алынған күйде (түпнұсқалар, өңделмеген)
- processed: мәтін шығарылған, қалыпқа келтірілген және бөлінген
- published: өндірісте пайдалануға рұқсат етілген
Тіпті шағын жобаларда да нұсқалау қажет. Наборларды жеке нұсқалар ретінде сақтаңыз (v1, v2) және не өзгергенін тіркеңіз: қайдан алынғаны, тазалау ережелері, разметка. Сол кезде сапаны адал салыстырып, егер жаңа нұсқа жауапты нашарлатса тез оралуға болады.
Қолжетімділікті алдын ала реттеңіз, әйтпесе тәртіп бұзылады. Көп кездесетін схема: raw — тек дереккөзі иелеріне және қауіпсіздік қызметіне, processed — деректер командасына, published — RAG сервистеріне және тест дайындаушыларға.
Индекспен байланыс тұрақты идентификаторлар арқылы сақталсын. Әр құжат және фрагмент ID алады, ал индексте нұсқаға сілтеме және тұтастықты бақылау (хэш) сақталады. Егер published-файл өзгерсе, оны бірден байқайсыз және индекстің басқа дерекке сілтеме жасағанын іздеумен уақыт өткізбейсіз.
Қабат 3: логирование — өмірлік цикл және ретеншн
RAG-да логтар екі нәрсе үшін қажет: қателер себебін тез табу және жүйенің ережелерге сәйкес жұмыс істегенін дәлелдеу (аудит). Барлығын мәңгі сақтасақ, шығын өсіп, пайдасы төмендейді.
Не жазу керек: не болғаны, қашан, қай жерде және неге деген сұрақтарға жауап беретін жазбалар: сұраулар (артық жеке деректерсіз), жауап статусы, промпт пен модель нұсқалары, техникалық қателер, қадамдар бойынша кешігулер (іздеу, ранжирование, генерация), сондай-ақ аудит оқиғалары (кім датасеттерді өзгертті, кім индексті қайта құрды, кім саясатты өзгертті).
Содан кейін құндылық бойынша өмірлік цикл орнатыңыз. Мысал:
- ыстық қабат 7–30 күн: тез талдауға қажет оқиғалар
- жылы қабат 3–6 ай: тек маңызды өрістер, сығымдау, сирек сұраныс
- архив 12–36 ай (реттеуші талаптар болса): аудит және минималды техжазбалар
Жазбалардан бұрын маскирлеу жасаңыз. Құпия сөздер, токендер, API кілттерін, құжат нөмірлерін, ИИН және медициналық мәліметтерді логқа жазбаңыз. Тергеу үшін көбінесе хэштер, категориялар және объект идентификаторлары жеткілікті.
Логтарға қолжетімдікті бөлек рольге беру жақсы: тек қажетті индекстерді оқу, жобалар бойынша шектеу және қолжетімділікті журналдау міндетті болсын.
1–2 аптада қабатты енгізу қадамдары
Осыны шағын жоба ретінде қарасаңыз, сақтау қабаттарын 1–2 аптада енгізуге болады, дамуды тоқтатпай. Әр ағынға кім жауапты болатынын анықтаңыз: іздеу (индекс), контент иелері (бастапқы файлдар), MLOps (датасеттер және пайплайнындар), қауіпсіздік (логтар және аудит).
Алдымен деректер картасын жасаңыз: қайдан келеді, қайда жатады, иесі кім, күнделікті өсу және нақты сақтау мерзімі қандай.
Содан кейін қысқа жоспар құрыңыз:
- ағындарды және иелерді бекіту
- әр дерек типі үшін өсу және ретеншн бағалау
- деңгейлерді бөлу (индекс үшін NVMe, бастапқы файлдар мен датасеттерке бөлек сыйымдылық, журналдарға жеке саясат)
- бэкапты орнату және тест ортада бір рет қалпына келтіру тестін өткізу
- бір құжатқа ережелерді жазу: не қайда жатады, кімнің қолы бар, қандай мерзімдер және неге
Еске қарапайым пилот жасаңыз: бір типті құжат, бастапқы файлдардың бөлек қабаты, индексті NVMe-ге қою және ескі логтарды суық қабатқа көшіру. Егер іздеу тұрақты жұмыс істесе және бэкаптан қалпына келтіру қарапайым болса, масштабтау жылдам жүреді.
Көп кездесетін қателіктер
Көбінесе барлығын бір жылдам қабатқа салады. NVMe үлкен және жылдам көрінеді, бірақ тез бастапқы файлдармен, логтармен және уақытша файлдармен толтырылады. Нәтижесі: іздеу баяулайды, ал толғанда ақаулар басталады.
Екінші қате — тест және өндірісті деректерді араластыру. Бүгін прототип қосылды, ал айдан кейін не өшіруге болатыны түсініксіз болады. Бұл әсіресе модель жауаптарының дереккөзі мен құжаттардың қатысуын дәлелдеу қажет болғанда ауыр соғады.
Логтарға көбінесе лимит қоймайды. Жүйе кіші болған кезде бәрі шыдайды. Сосын толық трассировка қосылады, интеграциялар көбейеді, және бірнеше аптада диск толып қалады.
Бэкаптарда да жиі қателеседі: тек индексті көшіріп, бастапқы файлдар мен метадеректерді ұмытады, немесе керісінше. Біріншіден, индекс дұрыс қалпына келтірілмейді. Екіншісінде қалпына келтіру өте ұзақ уақыт алады, өйткені индексті нөлден құру қажет.
Тағы бір аспект — переиндекстеу үшін орын қалдырмау. Эмбеддингтерді жаңартқанда немесе чанкинг схемасын өзгерткенде ескі және жаңа индексті параллель ұстап, қосымша уақытша файлдар үшін орын қажет.
Қарапайым индикатор: NVMe-дегі орын күтпегендей өзгереді, ал команда деректерді өшіруден қорқады, себебі не нақты өндірісте қатысатыны белгісіз.
Іске қоспас бұрын қысқа чеклист
RAG-ты өндірісте іске қоспас бұрын келесі мәселерді тексеріңіз:
- индекс пен іздеу құрылымдары жылдам сақтау орнында, және толық индексті бір рет қайта жасай алатындай бос орын бар
- бастапқы файлдар мен датасеттер индексінен бөлінген және raw, processed, published қайда екенін түсінікті
- журналдар үшін ретеншн және горячий/тёплый/архив араластыру ережелері бар
- бэкап тест ортада қалпына келтіру арқылы тексерілген және қалпына келтіру уақыты белгілі
- сақтау саясатының иесі тағайындалған және ережелерді қайта қарау кестесі бар (мысалы, тоқсан сайын)
Жиі көмектесетін шағын тест: тесттік индексті өшіріп, бастапқы файлдардан қайта жинап, жауаптардың күтпеген өзгеріссіз қалатындығын тексеріңіз. Егер бұл сағаттар алса — деректер араласып кеткен немесе ребилд үшін орын жеткіліксіз.
Мысал: сақтау талаптары бар ұйымға RAG
Банк немесе ірі аурухана ішкі регламенттер, келісімшарттар, нұсқаулықтар және қолдау базасы бойынша RAG-іздеуді іске қосады. Талаптар қарапайым: қызметкерлерге жылдам жауап, өзгерістер тарихы түсінікті және терең зерттеу үшін логтар сақталуы керек — өнімді сақтау мөлшерін үлкейтусыз.
Практикалық схема: векторлық индекс және іздеуге қажет нәрселер NVMe-де орналасады. Бұл ондаған қолданушылар бір уақытта іздегенде тұрақты жауап береді. Бастапқы файлдар (құжат нұсқалары, жүйелерден шығарылымдар, сканерлер) бөлек көлемді қабатта, мұнда көлем мен сенімділік маңызды.
Логтар ретеншн бойынша сақталады: ыстық қабатта 7–14 күн тез тергеулер үшін, кейін аудит пен тергеулер үшін арзан қабатқа, содан кейін талап бойынша архивке немесе жоюға жіберіледі. Көлем өскен сайын сценарий басқарылатын күйінде қалады: құжаттар қосылды, жаңа индекс жасалды, ескі нұсқалар мен логтар өз қабаттарына автоматты түрде көшеді.
Егер қауіпсіздік қызметі соңғы 90 күн ішіндегі белгілі бір бөлім бойынша сұраулар тізбегін талап етсе, сіз прод-индексті қозғалмай ұстап, терабайттарды көшірудің қажеті болмайды. Қажетті кезеңді лог қабатынан таңдап, есеп дайындап, іздеу дәл сол жауап беру уақытында жұмысын жалғастыра береді.
Келесі қадамдар: саясатты бекіту және инфрақұрылымды таңдау
Индекс, бастапқы файлдар және логтар әр түрлі ережелерге бағынатыны түсінікті болса, келесі қадам — оны қысқа тексерілетін саясатқа айналдыру. Қарапайым кесте жеткілікті: әр дерек типі бойынша шешім — көлем және өсу, жауап пен қалпына келтіру SLA-сы, сақтау мерзімі, деңгей (NVMe, көлемді қабат, архив) және қолжетімділіктер.
Пилоттан кейін масштабтауды екі бөлек міндетке бөлген дұрыс: өнімділік (NVMe және іздеу үшін CPU/RAM түйіндері) және сыйымдылық (бастапқы файлдар, датасеттер және бэкап түйіндері). Осылайша қымбат NVMe-ді қажетсіз жерде сатып алмайсыз.
Егер өз инфрақұрылымыңызда осындай схеманы құрып жатсаңыз, сервер платформасының индекс үшін бөлек NVMe пулын және бөлек сақтау саясаттарын қолдайтынына көз жеткізу пайдалы. Осындай жобаларда кейде GSE.kz (gse.kz) өндіруші және жүйелік интегратор ретінде тәжірибесіне сүйенеді, әсіресе есептеу және кейінгі эксплуатация үшін 24/7 қолдау қажет болғанда.
FAQ
Неліктен индекс, бастапқы файлдар, датасеттер және журналдарды бір қоймада сақтауға болмайды?
Әдетте: іздеу индексі, бастапқы құжаттар, датасеттер және журналдар түрлі талаптарға ие болғандықтан оларды бөлек сақтау ұсынылады. Бұл іздеудің кешігуін, сақтау құнын және апаттан кейін қалпына келтіруді бақылауды жеңілдетеді.
Индекс үлкен болмаса да, неге оны NVMe-ге қою керек?
Векторлық индекс көбінесе әр сұрауда қолданылады, сондықтан дисктегі қосымша миллисекундтар жауап уақытын айтарлықтай ұзарта алады. NVMe жүктеме астында тұрақты жауап беруді қамтамасыз етіп, фондық операциялар әсерін азайтады.
Егер индексті қайта жасауға болатын болса, NVMe үшін RAID қажет пе?
Индексті қайта құруға болады, бірақ бұл уақытша тоқтап қалу және жүйеге қосымша жүктеме әкеледі, әсіресе индекс үлкен болса. Екі NVMe-ге айна (RAID1) әдетте диск ақауларынан қорғаныс үшін логикалық минимумды береді және төтенше қалпына келтірілу ықтималдығын азайтады.
Неліктен бастапқы құжаттарды бөлек сақтау маңызды, егер индексте фрагменттер болса?
Бастапқы файлдар қайтаиндекстеу, дәйексөздерді және құқықтық дәлдікті тексеру үшін қажет. Егер тек чанктар немесе индекс сақталса, контекст пен құжат нұсқасын жоғалтып, жүйені тез қалпына келтіру қиынға соғуы мүмкін.
Құжаттар үшін raw/processed/published бөлу не береді?
raw/processed/published реттелуі «қандай күйде алынғанын» және «өнімде пайдалануға рұқсат етілгенін» араластырудан сақтайды. Бұл жобаның шатасуын азайтады және жаңарту сапасы нашарласа тез қайта оралуға мүмкіндік береді.
RAG жобасында оқу және бағалау датасеттерін нұсқалау не береді?
Датасеттер нұсқалармен өмір сүреді: тазалау ережелері, разметка және тестілер өзгеруі мүмкін. Нұсқаларды тіркемесеңіз, тәжірибелерді әділ салыстыру және сапаның өзгеру себептерін тез анықтау мүмкін болмайды.
Логтарға қандай сақтау мерзімі таңдау керек?
Логтар тез өседі және уақыт өте құндылығы төмендейді, сондықтан оларға ретеншн пен өмірлік цикл қажет. Практикалық тәсіл — егжей-тегжейлі жазбаларды қысқа уақытқа сақтау, ал аудиторлық қажеттілік үшін ғана маңызды өрістерді ұзақ сақтау.
RAG жүйесінің логтарына не жазуға болмайды және оны неге ауыстыру керек?
Логтарға құпия және сезімтал деректерді жазбаңыз: парольдер, токендер, кілттер, қажетсіз жеке идентификаторлар және медициналық мәліметтер. Талдау үшін әдетте техникалық идентификаторлар, хэштелген мәндер, статус, модель мен промпт нұсқалары және кешігу метрикалары жеткілікті.
Индексті құжаттармен қалай байланыстыру керек, сонда модельдің жауабының қалай алынғанын түсіндіруге болады?
Индекске және фрагменттерге тұрақты идентификаторлар, нұсқаға сілтеме және тұтастықты тексеру (мысалы, хэш) қажет. Осылайша қай деректер жауап жасауда қатысты екенін дәлелдейсіз және жарияланған файл өзгерсе, индекстің ескіргенін бірден байқайсыз.
Сақтау схемасының өндірістік дайын екеніне қалай тез көз жеткізуге болады?
Калпына келтіру тестін жасаңыз: тесттік индексті жойып, бастапқы файлдардан қайта жинап, жауаптарды күтілгенімен салыстырыңыз. Егер бұл көп сағат алса немесе қолмен көп әрекет қажет етсе, деректер араласып кеткен немесе ребилд үшін орын жеткіліксіз деген белгі.