Жасанды интеллектсіз құжаттар бойынша корпоративтік іздеу: Elasticsearch, OpenSearch

Міндет: құжаттарды табу және рұқсаттарды бұзбау

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

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

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

Жобаларда шектеулер жиі қайталанады: бөлініп тұрған сақтау орындары (файл шарлар, SharePoint, пошта шығару), мәтіні жоқ скандар, дубликаттар, «тарихи» форматтар және қисайған файл атаулары. 10+ ТБ архивте бұл тез арада инвентаризация мәселесіне айналады: не индекселеміз, не өткізіп жібереміз, құқықтардың қай өрістерге тәуелді екенін және «шындық» қайда екенін анықтау қажет.

Мысал ретінде: бухгалтер «счет на оплату ТОО Альфа март» деп іздейді, ал архивте скан да, хаттағы қосымша да бар. Іздеу екеуін де тез табуы керек, алайда нәтижелерді тек жобаның папкасына немесе поштасына рұқсаты бар адамдар ғана көре алуы тиіс. Егер рұқсаттар дұрыс бапталмаса, іздеу басқа жобалар туралы артық ақпарат алудың ыңғайлы құралына айналады.

Elasticsearch, OpenSearch және баламалар: қалай таңдау керек

Жасанды интеллектсіз корпоративтік іздеу керек болса, таңдау әдетте екі класқа бөлінеді: жалпы мақсаттағы іздеу қозғалтқыштары (Elasticsearch, OpenSearch, Solr) және сіздің ECM/DMS ішіндегі іздеу. Қайсысы дұрыс екенін сән емес, қолданушылар қандай сұраулар жасайтыны мен контурдағы шектеулер шешеді.

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

ИИ-сыз альтернативалар да жұмыс істейді. Solr схемада икемділік пен ересек практикалар қажет жерде таңдалады. Sphinx/Manticore қарапайым сценарийлерге және шектеулі форматтарға сай келеді, бірақ үлкен архивтерде басқарудың ыңғайлылығы мен экожүйеге бөгеледі. ECM/DMS ішіндегі іздеу жақсы, егер құжаттар жүйеде тұрса және фильтрлер мен есептерге қойылатын талаптар орташа болса.

Қандай күрделілік деңгейі керектігін түсіну үшін сұраңыз: пайдаланушылар «мәтіннен сөз табуды» ма іздейді, әлде «сипаттар жиынтығына сай құжат табуды» ма? Фасеттер, күрделі фильтрлер мен топтастырулар қажет болғанда бұл құралдар өте көмектеседі, әсіресе адамдар жиі нәтижені күн, бөлім, құжат түрі, контрагент бойынша нақтылайды.

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

10+ ТБ көлемінде әдетте компромистер пайда болады: сақтау шығыны мен репликалар саны, схема өзгергеннен кейін индекс қайта құру уақыты, кластерді және жаңартуларды тоқтатпай басқару қиындығы, OCR пен жүктеу конвейеріне қойылатын аппараттық талаптар, сондай-ақ мэппинг пен анализаторларды нәзік баптау, индексті шамадан тыс ұлғайтпау үшін.

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

Деректерді дайындау: форматтар, метадеректер, OCR

Көбінесе іздеу Elasticsearch немесе OpenSearch-та істен шығады деп емес, кіріс деректерінде. Құжаттар файл шарларынан, поштадан, DMS-тен, базадан шығарып алынған файлдардан және сканархивтерден келеді. Әр көздің өз файл атаулары, кодировкалары, дубликаттары және «қол тимеу керек» сияқты кездейсоқ папкалары бар. Оны бір қалыпқа келтірмесеңіз, нәтижелер таңқаларлық болып, пайдаланушыларды ренжітеді.

Мәтін әдетте жеткіліксіз. Сұрауды нақтылау, фильтр құру және неге құжат шыққанын түсіндіру үшін метадеректер қажет. Әдетте кірістіргенде өзін ақтайтын минималды жиын: дереккөз (пошта, файл шар, DMS), құжат түрі (шарт, акт, бұйрық), автор немесе иесі, құжат күнi және жүктеу күнi, бөлім немесе жоба, нөмір (бар болса) және статус (жоба, қол қойылған, архив).

Скандармен OCR-ды бөлек кезең деп санаған дұрыс, оны коннектордағы бір чекбокстан гөрі. Екі мәтінді сақтау ыңғайлы: распознаваниедан шыққан шикі мәтін және тазартылған нұсқа. Сондай-ақ распознавание сапасының белгілерін қосыңыз, сонда кейін «ештеңе табылмауының» себебін дауласпай анықтауға болады.

OCR: жаппай іске қоспас бұрын не тексеру керек

Кішкене сынақ жиынтығында бірнеше жылдам тексеріс апталар үнемдейді. Распознавание тілін (ru, kz, en) және аралас құжаттарды, PDF-тегі мәтін қабатының бар-жоғын, ұқсас таңбалардың типтік қателерін (0/О, 1/I, ң/н), «қоқыс» таңбалардың және бос беттердің үлесін тексеріңіз.

Одан кейін нормализация: біртұтас кодировка (әдетте UTF-8), басқару таңбаларын жою, даталар мен нөмірлерді бір форматқа келтіру. OCR-дан кейін стоп-сөздер мен сөздерді «қосып» қоюды слепой түрде баптамаңыз — алдымен пайдаланушылардың нақты қандай сұраулар енгізетінін көріңіз.

Дубликаттар мен нұсқалар — бөлек мәселе. Практикалық ереже: бір «негізгі» көшірмені көрсетіп, қалғандарын «ұқсас» деп жасыру немесе версия бойынша (v1, v2, қол қойылған) байланыстыру. Мұның үшін тұрақты идентификаторлар қажет: мазмұн хеші, құжат нөмірі, (нөмір + дата) жұбы немесе DMS-ден алынған ID.

10+ ТБ архивке арналған индекс жобалау

Алғашында көлемді жуық бағалаудан бастаңыз. 10+ ТБ үшін маңызды тек гигабайттар емес, файлдар саны, орташа өлшем, скандар үлесі (мәтіні жоқ PDF) және архивтің өсу қарқыны. Бірдей көлемдегі екі архив әртүрлі жүріс көрсетуі мүмкін: миллиондаған кішкентай файл метадеректерді көбейтеді және индексация операцияларын арттырады, ал жүз мың үлкен файл басқа сипат береді.

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

Қазақ және орыс үшін мэппинг пен анализаторлар

Мэппингтегі қателер кейін қымбатқа түседі. Қай өрістер толықмәтінді (full-text), қайсысы тек фильтр мен сұрыптау үшін қажет екенін алдын ала шешіңіз. Қазақ және орыс тілдері үшін анализаторларды — токенизация, нормализация, морфология және сақтықпен енгізілген синонимдерді таңдау маңызды (сіздің релеванттылықты «шашыратып» жібермеуі тиіс).

Аттар, ЖСН/БИН, келісімшарт нөмірлері және даталар үшін бөлек ойлану керек: оларды мүмкіндігінше keyword/сан/дата ретінде сақтау дұрыс, мәтін орнына емес.

Шардтар, репликалар және ыстық-суық сақтау

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

Бастан өлшеңіз: bulk жүктеу жылдамдығы (құжат/сек), индекс көлемінің бастапқы деректерге қатынасы, құжат қолжетімді болғанға дейінгі уақыт, диск жүктемесі және I/O кезектері, сондай-ақ OCR-дан кейін алынатын мәтін көлемі.

Релеванттылықты тексеру: қарапайым тест әдістемесі

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

Ұсақ тест жиынтығы, оны ұстау оңай

Теориядан гөрі адамдардың сұрауларынан бастаңыз. Әртүрлі рөлдерден (бухгалтерия, заңгер, сатып алу, ИТ, басшылық) 30–100 сұрау жинаңыз. Контекстті тіркеп қойыңыз: адам не іздеді және қалай есте сақтай отырып сұрау енгізген.

Әр сұрауға 3–10 құжаттан тұратын «эталон» жасаңыз — олар топ-10 ішінде болуы тиіс, және 2–3 құжатты көрсетіңіз, олар шығып кетпеуі керек (мысалы, ұқсас шаблондар, ескі нұсқалар, басқа филиалдардан қатысты емес құжаттар).

Тексеру қарапайым болуы мүмкін: қанша сұрау ештеңе қайтарған, эталондық құжаттар топ-3 және топ-10 ішінде бар ма, қажетті файлды табу үшін қанша уақыт пен переформулировка қажет, нәтижелер қайта іске қосқаннан кейін «жылжып» кетпеуі және тесттің неліктен сәтсіз болғаны (тіл, синонимдер, метадеректер шуылы).

Прогондар арасында тек бір параметрді өзгертіңіз: атау өрісінің анализаторы, өрістердің салмақтары (тақырып денеден күшті), метадеректер бойынша шағын boost (құжат түрі, бөлім, дата).

Релеванттылықты жиі бұзатын «қауіпті» сұраулар

Қысқа сөздер, аббревиатуралар, келісімшарт және шот нөмірлері, қателер — релеванттылықты жиі бұзатындар тізімін бөлек ұстаңыз. Мысалдар: «ДП-17/24», «акт КС2», «сч 4512», «ТЗ АСУП». Егер мұндай сұраулар жұмыс істемесе, пайдаланушылар іздеуге сенімін жоғалтады, тіпті ұзын фразалар жақсы ізделсе де.

Нәтижелердегі рұқсаттар: модельдер мен тексеру

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

Алдымен жүйеңізде нақты өмір сүретін рұқсат моделін анықтаңыз. Әдетте бұл құжаттағы ACL, топтар мен рөлдер (бөлім, жоба), папкалар немесе кейстерден мұрагерлік және қауіпсіздік белгілері («ДСП», «конфиденциалды»). Көбі қолжетімділік мерзімдерін қосады, сонда құқықтар жобаның жабылуымен «жанып кетеді».

Сүзуді қалай жасау керек

Ең сенімді жол — сұрау деңгейінде security trimming: нәтиже әрқашан ағымдағы пайдаланушының құқықтары бойынша сүзгіден өтсін. Басқа тәсілдер де болады (деректерді индекстерге бөліп қою немесе қосымша қабатта алдын ала фильтр қолдану), бірақ олардың өзінде сәйкессіздік қаупі жоғары.

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

Ағып кетпегеніне қалай тексеру керек

Тексеру «жалпылама» түрде емес, пайдаланушылар профилі бойынша жүргізілуі керек. Әдетте 5–7 тесттік персона жеткілікті: қызметкер, басшы, сыртқы мердігер, аудитор және негативті тесттер жиынтығы: фамилиялар, келісімшарт нөмірлері, жабық файлдардан алынған кілт сөздер. Құжатты ашып көру ғана емес, сниппеттерді, бөлектеуді, тіркемелерді, нұсқаларды және метадеректерді (автор, бөлім, сома) тексеріңіз. Автотолтыру жабық атауларды ұсынбауы тиіс.

Қарапайым сценарий: бухгалтер «договор 1245» деп іздейді және тек өз жобасының нәтижелерін көруі керек; басқа филиал қызметкері тіпті атауын немесе контрагентті көрмеуі тиіс.

Индексация жылдамдығы: 10+ ТБ-ты тосынсыйсыз қалай өткізу

10+ ТБ архивте индексация жылдамдығы жиі Elasticsearch/OpenSearch-тан емес, оларға дейінгі пайплайннан шектеледі: файлдарды оқу, мәтінді шығару, нормализация, метадеректер қосу және тек содан кейін индекске жазу. Сондықтан қадамдар бойынша уақытты өлшеңіз, әйтпесе OCR немесе желілік сақтау баяулап тұрғанда «іздеуді жылдамдатуда» уақыт өткізесіз.

Әдеттегі пайплайн: мәтінді шығарып аласыз (DOCX/PDF-тен, кейде OCR арқылы), кодировканы және даталарды бір қалыпқа келтіресіз, метадеректер қосасыз (түр, бөлім, келісімшарт нөмірі, дата, дереккөз) және құжаттарды bulk арқылы жібересіз.

Жүктеуді бақылауын жоғалтпай қалай тездету

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

Шардтар, қателер және переиндексация жоспары

«Шардтар тым көп» көбінесе баяулататын фактор: накладтар, балансировка қиындауы, сегменттердің көбеюі. Болжамды индекс өлшемін алдын ала бағалап, сақтықпен шард санын таңдаңыз, өсуге жеңілдік қалдырыңыз.

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

Ең бастысы — ребилдты есептеу. Егер кластер 70% жүктеме кезінде құлдыраса, қанша сағат жоғалтасыз? Өндірісте партия бойынша переиндексация жоспары және бақылау нүктелері болғаны пайдалы, сонда тоқтау орнына жалғастыруға болады.

Іздеудегі өнімділік: әдетте қай жерлер баяулайды

Корпоративтік іздеуде «баяу» деген кезде әдетте бірнеше себептің тізбегі бар: ауыр сұрау, индексте артық өрістер, баяу диск және кэшке жедел жадының жетіспеушілігі. Алдын ала 5–10 жиі кездесетін сценарийді сипаттап алыңыз: «фраза бойынша табу», «күн/түр бойынша сүзгілеу», «жаңалық бойынша сұрыптау», «фасеттер көрсету (бөлім/автор бойынша)». Бұл комбинациялардың әрқайсысының бағасы әр түрлі, ең қымбаттары — сұрыптау мен фасеттер ірі жиындарға қолданылғанда.

Күнделікті бақылау үшін мына базалық сигналдар жеткілікті: іздеу латенттігі (p50/p95) және таймауттар үлесі, CPU мен жады (heap) және GC паузалары, диск (оқу/жазу кешігулері және толу), индексация мен іздеу кезектері, сондай-ақ кэштердің «ыстықтығын» көрсететін жанама белгілер (латенттіктің секірістері).

«Баяу» деген нәрсені тапқанда болжам жасамаңыз — профилдеңіз. Көбінесе сұрау көп өрісті тартып алады, бірақ нәтиже үшін 3–4 өріс жеткілікті, немесе агрегациялар «барлық құжатқа» есептеледі, ал пайдаланушы ағымдағы фильтр бойынша ғана қарағысы келеді. Көбінесе жеткілікті: алдымен құқықтар мен даталар бойынша сүзгі, содан кейін мәтіндік іздеу және тек соңында фасеттер.

Сақтау медиумы да әсер етеді. SSD пиков кезінде іздеуді тұрақты ұстайды, HDD-де жауап уақытында «баспалдақтар» көбіне пайда болады. Практикалық тәсіл — жаңа және жиі сұранылатын құжаттар үшін ыстық сақтау, архив үшін суық сақтау, сығу және тұрақты snapshots.

Практикалық мысал: мемлекеттік органның келісімшарт архивінде «күн бойынша сұрыптау» және «филиал бойынша фасет» он млн-даған файлға өскенде баяулаған. Себебі дата өрісі жол ретінде сақталған әрі агрегация шектеусіз есептелген. Өріс түрін түзеп және артық агрегацияларды өшіргеннен кейін p95 бірнеше есе төмендеген.

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

Қате табулар мен тұзақтар

Ең қымбат қателік — «барлығын жай индексациялаймыз» деп бастау, кейін тазалау. 10+ ТБ архивте «кейін» дегені әдетте айлар бойы қолмен тазалау мен переиндексацияны білдіреді.

Көбінесе мәселе қозғалтқышта емес, деректер дайындау мен іздеу ережелерінде:

• Метадеректер схемасының болмауы (құжат түрі, нөмір, дата, контрагент, бөлім). Нәтижесінде маңызды белгілер мәтінде жоғалып қалады және табылмайды.
• Бір өрісте тілдер мен форматтарды араластыру. Қазақ, орыс және ағылшын әртүрлі анализаторларды талап етеді, ал PDF пен скандар мәтін сапасы бойынша әртүрлі нәтиже береді.
• Рұқсаттарды «кейінге қалдыру». Ағып кетулер сниппеттерден, бөлектеуден, автотолтырудан және тіпті нәтиже санынан болуы мүмкін, егер құқық сүзгісі everywhere қолданылмаса.
• CPU мен RAM-ды асыра бағалау, диск талаптарын төмен бағалау. Индексация мен агрегацияларда IOPS, жазу жылдамдығы және сегмент біріктіру тәртібі шешуші факторлар.
• Переиндексация және қалпына келтіру жоспарының жоқтығы. Кез келген мэппинг, анализатор немесе рұқсат моделі өзгерісі индексті толықтай қайта құруды талап етуі мүмкін.

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

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

Іске қоспас бұрын қысқа чек-лист

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

Алдымен негізгі картинаны бекітіңіз: не индекселейтінін, қалай өсетінін және пайдаланушылар үшін «жетістік» деген не екенін.

• Деректер және өсім: нақты архив көлемін, күтілетін өсу қарқынын, скандар үлесін және орташа құжат өлшемін есептеңіз. OCR-ға қиын аймақтарды (бұзылған мөрлар, мөртастар, қолжазбалар) белгілеңіз және осындай файлдардың санын алыңыз.
• Релеванттылық: қызметкерлерден 30–100 нақты сұрау жинап, әр сұрауға 5–10 эталон құжат таңдаңыз. Орнатуларға дейін және кейін метрикаларды алыңыз (мысалы, қажетті құжаттың топ-3-тегі үлесі).
• Рұқсаттар: рұқсат моделін қарапайым тілмен сипаттаңыз (пайдаланушы, топ, бөлім, рөл, жоба). Негативті тесттер өткізіңіз: «көрмеуі тиіс», «тек тақырыпты көре алады, қосымшаны емес». Нұсқалар, тіркемелер және мұрагерлікті тексеріңіз.
• Индексация жылдамдығы: нақты деректерден bulk жылдамдығын измереп, толық ребилд уақытын бағалаңыз. Дискілер, CPU және өңдеу кезектерінде (OCR, мәтін шығару, анализаторлар) тар шектеулерді анықтаңыз.
• Эксплуатация: мониторинг, бэкаптар, жаңартулар жоспарын және дереккөздер үшін жауапкершілікті орнатыңыз. Қайсыбір дереккөз қате файл берсе, пайплайнды кім түзететінін алдын ала шешіңіз.

Практикалық тест: бір бөлімді (мысалы, заң бөлімін) алып, олардың 1–2 жылдық архивін жүктеп, 3–5 қызметкерден типтік құжаттарды табуды сұраңыз (шарт, қосымша келісім, акт). Егер бір сұрау да «бөтен» құжаттарды көрсетсе немесе нәтиже индексті жаңартқаннан кейін «жылжып» кетсе — рұқсат моделін және тест әдіснамасын дұрыстаған дұрыс, кейіннен өндірісте жөндеуге қарағанда.

Тәжірибеден мысал: үлкен архивте шартты табу

Қаржы қызметкері аудит сұрауы бойынша қолтаңбасы бар қосымшасы бар шартты табуы керек. Архив үлкен, құжаттар әртүрлі жүйелер мен папкаларда, кейбірі скан. Іздеуіш жүйе компания ішінде орнатылған және тез әрі болжамды табуды қамтамасыз етуі тиіс.

Шындықта сұрау сирек дәл келеді. Қызметкер енгізеді: «Договор 18-04/23 ТОО Ромашка» немесе жай ғана «18-04 ромашка приложение». Нөмір әртүрлі бөлгіштермен жазылуы мүмкін (18/04-23, 18-04-2023), контрагент түрліше жазылған («ТОО Ромашка», «Romashka LLP») немесе қате болуы мүмкін. Сондықтан бастапқы 4–6 символға дейінгі үзінділер бойынша, қателерге төзімділікке, қысқартуларға (ТОО, LLP) және қосымша нөмірі бойынша іздеуге жүйені тексерген жөн.

Ең маңыздысы — рұқсаттар. Қаржышы басқа филиалдың заңгерлерінің шарттарын немесе HR құжаттарын көрмеуі тиіс, тіпті сұрау сәйкес келсе де. Бұл әр аккаунтпен бірдей сұраулар жасалып, нәтижелердің бірінші 10 ғана емес, жалпы табылған саны бойынша салыстырылып тексеріледі. Егер бір рөлде «124 табылды», ал басқа рөлде «130 табылды» болса, рұқсаттар барлық құжаттарға немесе барлық типтерге біркелкі қолданылмаған.

Тағы бір тексеріс — индексация уақыты. Соңғы 24 сағат ішінде қанша файл салынды, олардың қаншасы индекске түсті және іздеуде қанша уақыттан кейін қолжетімді болды. Егер бүгін 5 000 құжат жүктелсе, ал іздеу тек 3 000-ын көрсе, индекс «артта қалуда» және кешігу өседі.

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

Келесі қадамдар: пилот, қабылдау және енгізу

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

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

Сосын инфрақұрылым және қолдау басталады. 10+ ТБ архив үшін бастапқыда қайда бастапқы файлдар мен индекстер сақталатынын, бэкаптар қалай жасалатынын, кім сертификаттар мен парольдерді жаңартайтынын және рұқсат ережелерінің қалай өзгертілетінін шешіңіз. Регламенттерді енгізген дұрыс: қызмет көрсету терезелері, мониторинг, қалпына келтіру жоспары және жаңа дереккөздерді қосу процесі.

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

Қазақстанда мұндай жобалар жиі тек қозғалтқышты баптаумен шектелмей, сондай-ақ индекске, OCR-ға және сақтауға арналған инфрақұрылымды дұрыс ұйымдастыруды талап етеді. Осы жерде жүйелік интеграторды қосу логикалық: мысалы, GSE.kz серверлік бөлікті (S200 Series қоса) және контурды ұстауды жаба алады, ал сіз деректерге, рұқсаттарға және қабылдау тесттеріне шоғырланасыз.