Корпоративный поиск по документам без ИИ: 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), тип документа (договор, акт, приказ), автор или владелец, дата документа и дата загрузки, подразделение или проект, номер (если есть) и статус (черновик, подписан, архив).

Со сканами лучше считать OCR отдельным этапом, а не «галочкой» в коннекторе. Удобно хранить два текста: сырой результат распознавания и очищенный. Добавьте признак качества распознавания, чтобы потом не спорить, почему «ничего не находится».

OCR: что проверить до массовой прогонки

Пара быстрых проверок на небольшой выборке экономит недели. Проверьте язык распознавания (ru, kz, en) и смешанные документы, наличие текстового слоя в PDF, типовые ошибки похожих символов (0/О, 1/I, ң/н), долю «мусорных» символов и пустых страниц.

Дальше идет нормализация: единая кодировка (обычно UTF-8), удаление управляющих символов, приведение дат и номеров к одному формату. Стоп-слова и «склейку» слов после OCR лучше не настраивать вслепую - сначала посмотрите, какие запросы реально вводят люди.

Отдельная боль - дубликаты и версии. Практичное правило: показывайте одну «главную» копию, а остальные прячьте под «похожие» или связывайте по версии (v1, v2, подписано). Для этого нужны стабильные идентификаторы: хеш содержимого, номер документа, пара (номер + дата) или ID из DMS.

Проектирование индекса под архив 10+ ТБ

Начните с грубой оценки объема. Для 10+ ТБ важны не только гигабайты, но и количество файлов, средний размер, доля сканов (PDF без текста), а также темпы роста архива. Два архива одинакового размера могут вести себя по-разному: миллион мелких файлов даст больше метаданных и больше операций индексации, чем сто тысяч крупных.

Стратегия с одним огромным индексом редко удобна. Обычно проще, когда индексы разделены по источникам (файловые шары, DMS, почта), по срокам хранения (активные годы и «история») или по типам (договоры, кадры, закупки). Так легче управлять правами, ретеншном, переиндексацией и переносом старых данных на более дешевое хранение.

Мэппинг и анализаторы для русского и казахского

Ошибки в мэппинге потом дорого исправлять. Сразу решите, какие поля будут полнотекстовыми, какие нужны только для фильтров, а какие - для сортировки. Для русского и казахского важно подобрать анализаторы: токенизацию, нормализацию, морфологию и аккуратные синонимы (без «раздувания» выдачи).

Отдельно продумайте поля для имен, ИИН/БИН, номеров договоров и дат: их лучше хранить как keyword/числа/даты, а не как текст.

Шарды, реплики и горячее-холодное хранение

Шардирование выбирайте не «по умолчанию», а под железо и рост. Старые документы можно держать в холодном слое, а свежие - в горячем, чтобы поиск по текущим делам оставался быстрым. Реплики повышают отказоустойчивость, но удваивают записи на диск и замедляют загрузку.

Чтобы не гадать, измеряйте с самого начала: скорость bulk-загрузки (документов в секунду), рост размера индекса относительно исходных данных, время обновления (когда документ начинает находиться), нагрузку на диски и очередь I/O, а также поведение на сканах после OCR (сколько текста получается).

Как проверять релевантность: простая методика тестов

Релевантность в корпоративном поиске ломается незаметно: вы меняете анализатор или добавляете новые поля, и вчерашний «правильный» документ уезжает на 30-е место. Поэтому нужен небольшой, но повторяемый тестовый набор, который прогоняют после каждого изменения.

Мини-набор тестов, который реально поддерживать

Начните с запросов людей, а не с теории. Соберите 30-100 запросов от разных ролей: бухгалтерия, юристы, закупки, ИТ, руководители. Сразу фиксируйте контекст: что человек хотел найти и как он формулирует запрос «по памяти».

Дальше по каждому запросу сделайте «эталон» на уровне здравого смысла: 3-10 документов, которые должны быть в топ-10, и 2-3 документа, которые появляться не должны (например, похожие шаблоны, устаревшие версии, нерелевантные филиалы).

Проверка может быть простой: сколько запросов вернули пусто, есть ли эталонные документы в топ-3 и топ-10, сколько времени и переформулировок нужно, чтобы открыть нужный файл, не «прыгают» ли результаты между запусками и после переиндексации, и почему тест провален (язык, синонимы, шум от метаданных).

Между прогонами меняйте только один параметр: анализатор для поля названия, веса полей (заголовок сильнее тела), небольшой буст по метаданным (тип документа, подразделение, дата).

«Опасные» запросы, которые надо вынести отдельно

Отдельным списком держите запросы, которые чаще всего ломают релевантность: короткие слова, аббревиатуры, номера договоров и счетов, опечатки. Примеры: «ДП-17/24», «акт КС2», «сч 4512», «ТЗ АСУП». Если такие запросы не работают, пользователи быстро теряют доверие к поиску, даже если длинные фразы ищутся хорошо.

Права доступа в выдаче: модели и проверка

В корпоративном поиске самая частая ошибка не в релевантности, а в том, что пользователь видит то, чего не должен. Утечка бывает не только через сам документ, но и через заголовок, сниппет, подсветку, автодополнение и даже «похожие запросы».

Сначала определите модель прав, которая реально живет в ваших системах. Обычно это ACL на документ, группы и роли (отдел, проект), наследование от папок или кейсов, плюс метки безопасности («ДСП», «конфиденциально»). Часто добавляются сроки действия доступа, чтобы права «сгорали» после закрытия проекта.

Как делать фильтрацию

Самый надежный путь - security trimming на уровне запроса: выдача всегда фильтруется по правам текущего пользователя. Варианты тоже встречаются (разнести данные по индексам/сегментам или делать pre-filter на стороне приложения), но с ними выше риск расхождений.

Чтобы фильтрация работала стабильно, права лучше хранить рядом с документом в индексе: список разрешенных групп/ролей, уровень доступа, возможные исключения, даты начала и окончания. Важно договориться об одном источнике прав (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 и сканы дают разное качество текста.
• Откладывание прав доступа «на потом». Утечки случаются через сниппеты, подсветку, автодополнение и даже счетчики результатов, если фильтр прав применен не везде.
• Переоценка 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) и сопровождение контура, а вам останется сосредоточиться на данных, правах и приемочных тестах.