Векторная база для on-prem RAG: выбор под закрытый контур

Почему выбор векторной БД для on-prem RAG часто буксует

В открытой среде многие начинают с мысли: «возьмем самую популярную базу и повторим чужой рецепт». Для on-prem это редко работает. В закрытом контуре важны не столько красивые бенчмарки, сколько то, как система живет неделями без доступа к облачным сервисам, маркетплейсам и «быстрым фиксам».

Первая причина пробуксовки - разрыв между пилотом и эксплуатацией. На тестовом наборе в 50 тысяч документов все летает. А после запуска внезапно выясняется, что векторная база для on-prem RAG упирается в RAM, а не в CPU: индексы раздуваются, кэш вытесняет полезные данные, появляются непредсказуемые задержки.

Вторая причина - забытые «скучные» требования: диски, бэкапы и восстановление. В пилоте редко проверяют, сколько места займут индексы через 3-6 месяцев, как долго идет пересборка, что происходит при сбое питания или падении узла. А именно тут всплывают дорогие сюрпризы: долгое восстановление, невозможность точечного отката, сложность консистентных бэкапов без остановки сервиса.

Третья причина - бизнес ждет предсказуемости. В закрытом контуре обычно важнее стабильная работа, понятная стоимость владения и контроль данных, чем максимум скорости в идеальных условиях. Выбор тормозит до тех пор, пока требования не оформлены как SLA и ограничения инфраструктуры. Например, если кластер стоит на локальных серверах, заранее становится критично, какие диски нужны, как устроена репликация и сколько оперативной памяти придется закладывать «в запас».

Как устроен on-prem RAG и какую роль играет векторная БД

On-prem RAG - это когда поиск по вашим документам и генерация ответа работают внутри закрытого контура, без передачи данных во внешние сервисы. В типовой схеме есть два режима: загрузка (индексация) и ответы на запросы (поиск и генерация).

При загрузке документы забирают из файлового хранилища, почты или внутренних систем, очищают, режут на фрагменты и считают для них эмбеддинги. Затем эмбеддинги вместе с исходным текстом (или ссылкой на него) сохраняют в хранилище. Здесь и нужна векторная база: она хранит векторы, строит индекс для быстрого поиска и помогает отбирать фрагменты по метаданным (тип документа, подразделение, гриф, дата).

Рядом почти всегда есть еще три компонента: сервис эмбеддингов (иногда на GPU), LLM для финального ответа и приложение-оркестратор, которое управляет пайплайном и правами доступа.

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

Если RAG разворачивается на собственных стойках, роль векторной БД становится еще заметнее: она во многом определяет, выдержит ли система пики и насколько предсказуемо переживет сбои.

Что описать до сравнения: данные, SLA и ограничения

Сравнение векторных БД легко сводится к спору «кто быстрее». Но без описания данных и правил эксплуатации цифры из тестов мало что значат. Один и тот же движок может быть отличным для регламентов и неудобным для потока тикетов.

Начните со сценариев. Например: сотрудники ищут по внутренним регламентам (обновления редкие, важна точность), база знаний ИТ (обновления раз в день), обращения и тикеты (постоянная запись, нужен свежий контент). Эти сценарии задают требования к скорости индексации, задержке обновлений и качеству фильтров.

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

SLA лучше записать коротко: время ответа для 95% запросов и пиковая нагрузка (QPS), допустимый простой и окна обслуживания, требования к восстановлению (RPO и RTO).

Наконец, продумайте изоляцию в закрытом контуре. Сколько будет коллекций и команд, нужны ли разные права доступа, требуются ли фильтры по подразделениям или уровням секретности. Эти детали заранее покажут, нужна ли многоарендность, строгая модель ролей и как вы будете разделять данные без ручной «акробатики».

Скорость: на что смотреть в тестах

Скорость в RAG редко сводится к одной цифре. Для векторной базы для on-prem RAG важно понять не только, как быстро находится «похожее», но и что происходит при реальных фильтрах, обновлениях и параллельной нагрузке.

В тестах фиксируйте p50 и p95. p50 показывает «обычный» запрос, p95 - хвост, где пользователи чаще всего замечают проблемы. Добавьте QPS при целевой точности и время построения индекса после загрузки или переиндексации.

Отдельно проверьте фильтры по метаданным. В закрытом контуре почти всегда нужно отбирать по отделу, грифу, проекту, языку, дате. Фильтры могут резко замедлять поиск, если выполняются «поверх» результатов или если структура индекса к ним не готова. Поэтому измеряйте скорость не на «голых» векторах, а на запросах с типовыми условиями.

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

Для пилота держите константами железо, датасет и набор запросов. Например, для закрытого контура в госорганизации: 70% запросов с фильтром по подразделению и уровню доступа, 30% - без фильтра.

В протоколе достаточно нескольких метрик: p50/p95 на чтение (с фильтрами и без), QPS при целевой нагрузке, время загрузки и построения индекса, деградация во время импорта/обновлений, CPU и диск в пике.

Потребление RAM: как оценить заранее и не промахнуться

В on-prem проектах память часто становится главным ограничением: докупить диски обычно проще, чем пересогласовать профиль сервера из-за нехватки RAM. Поэтому векторную базу для on-prem RAG стоит оценивать по памяти еще до пилота.

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

Что уточнить у решения

Спросите прямо: индекс всегда в RAM или возможен memory-mapped режим (часть данных отображается с диска и подгружается по мере надобности). Второй вопрос - можно ли ограничить кэши и задать лимиты памяти, чтобы база не вытесняла другие сервисы на узле.

Оценку порядка можно начать так: объем «сырых» векторов примерно равен N x D x B, где N - число векторов, D - размерность, B - байт на число (4 для float32, 2 для float16). Дальше добавьте запас на индекс и служебные структуры.

Практичные правила:

• на индекс и overhead часто уходит 1.5-4x от объема векторов;
• умножайте итог на число реплик (у каждой свой индекс);
• оставляйте 20-30% RAM под ОС и кэши, иначе система станет нестабильной.

Компромисс простой: экономия памяти обычно означает более медленный поиск или чуть хуже качество (например, сильнее сжатие и «легче» индекс). Лучше заранее решить, что важнее для вашего SLA, чем потом лечить нехватку RAM в проде.

Диски и хранение: требования, о которых часто забывают

Для векторной базы для on-prem RAG диск почти так же важен, как CPU. Типичная ошибка выглядит так: на демо все быстро, а после загрузки реальных данных система начинает «думать» при вставке новых документов, пересборке индекса и восстановлении после сбоя.

Смотрите не только на емкость, но и на поведение диска под нагрузкой. Векторные индексы делают много мелких чтений, а при обновлениях добавляют заметную запись. Поэтому важны IOPS и задержка, а также ресурс записи (TBW) и качество контроллера. На дешевых SSD можно упереться не в объем, а в задержки и износ.

NVMe особенно выигрывает при высоком параллелизме: много запросов на поиск плюс фоновая запись (ингест, компактизация, merge сегментов). Если запросов мало и обновления редкие, хороший SATA SSD может быть достаточным, а бюджет лучше потратить на резерв и бэкапы.

Рост хранения часто недооценивают: индекс может увеличиваться не строго линейно из-за сегментов, настроек графа и служебных структур. Планируйте место с запасом и учитывайте все части: базу и индексы, WAL и служебные файлы, временные файлы при сборке/компактизации, реплики, бэкапы и место под восстановление.

Бэкапы и восстановление: как избежать сюрпризов

В on-prem проектах бэкап часто считают «делом админов», а потом выясняется, что восстановление занимает часы или что копия не содержит индекс. Для векторной базы это особенно больно: потеря индекса означает долгую пересборку и простой.

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

Частота бэкапов должна идти от RPO/RTO, а не от привычки. Если коллекции обновляются раз в сутки, ежедневной полной копии может хватить. Если документы и эмбеддинги меняются весь день, нужны более частые точки восстановления и понятный план.

Чтобы копии не были «бумажными», сделайте проверку восстановления регулярной: раз в месяц поднимайте тестовый стенд и восстанавливайтесь из последнего бэкапа; проверяйте не только данные, но и поиск (запросы, фильтры, качество выдачи); замеряйте реальное время восстановления и сравнивайте с RTO; храните рядом версии конфигурации и схемы.

В закрытом контуре держите копии минимум в двух местах: на отдельном хранилище и на носителе, изолированном от рабочей сети (на случай шифровальщика). Доступ - по принципу минимальных прав, с журналированием операций и отдельными учетными данными для процедур восстановления.

Репликация и отказоустойчивость: что выбрать для on-prem

В on-prem RAG сбой векторной БД быстро превращается в простой всего поиска: ответы «пустеют», а пользователи теряют доверие. Отказоустойчивость лучше проектировать сразу, а не добавлять потом, когда база уже выросла.

Минимальный набор, который действительно помогает в инцидентах: репликация между узлами (на разные серверы), автоматическое переключение на живой узел, механизм защиты от «двух правд» (кворум или аналог), наблюдаемость (статус реплик и задержки в метриках и логах).

Дальше начинается компромисс между консистентностью и доступностью. В аварии (например, потеря сети между двумя стойками) строгая консистентность может остановить запись, зато исключит расхождения. Более доступный режим позволит продолжить работу, но потом придется разруливать конфликты. Для закрытых контуров в госсекторе и финансах чаще выбирают предсказуемость и строгие правила, даже ценой временной паузы.

Помните, что репликация умножает ресурсы: две реплики - это примерно вдвое больше диска и, как правило, заметно больше RAM, потому что индексы и кэши живут на каждом узле.

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

Эксплуатация и безопасность в закрытом контуре

В закрытой сети векторную базу для on-prem RAG оценивают не только по скорости. Важно, как она ведет себя каждый день: кто и что может увидеть, что попадет в журналы, как обновляться без интернета и как быстро дежурная смена поймет, что что-то пошло не так.

Начните с изоляции. Проверьте, есть ли проекты или неймспейсы, роли и права, и можно ли разделить доступ не только к коллекциям, но и к метаданным. Частый риск - когда пользователю видны служебные поля (источники, теги, идентификаторы), хотя доступа к документам у него нет.

Дальше - аудит. Уточните, логируются ли чтение, запись, удаление, изменения схемы и ошибки авторизации. Заранее решите, сколько хранить журналы (7, 30, 180 дней) и где именно, чтобы расследования не упирались в нехватку диска.

Процесс обновлений в закрытом контуре должен быть повторяемым: завоз пакетов в репозиторий внутри периметра, проверка зависимостей и совместимости версий, тест на стенде, затем окно на проде.

Мониторинг лучше строить вокруг простых графиков: RAM и рост кэшей, заполнение диска и скорость I/O, латентность поиска (p95/p99), ошибки и таймауты. В проектах для госорганизаций требования к RBAC и аудит-логам часто оказываются важнее «плюс 10% к скорости».

Удобство сопровождения: что экономит время каждый месяц

Даже если в тестах вы выиграли по скорости, в проде чаще всего решает эксплуатация: насколько легко поставить, обновлять и чинить базу без доступа в интернет и без лишних зависимостей. Векторная БД становится частью цепочки поиска и напрямую влияет на качество ответов.

Что спросить до выбора

Перед пилотом соберите ответы на практичные вопросы и попросите показать это на стенде, а не в презентации: как устроена установка (один бинарник или набор сервисов), есть ли зависимость от 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 живет в цикле «загрузка данных - индексация - поиск - обновления - бэкапы - восстановление». Если база быстро ищет, но медленно грузит новые документы, тяжело бэкапится или требует сложной ручной поддержки, вы потеряете предсказуемость.

Вторая ошибка - не закладывать рост. Коллекции обычно растут быстрее планов: появляются новые версии документов, письма, сканы после распознавания. Плюс данные дублируются: реплики, отдельные окружения для теста, временные индексы при перестроении. То, что «влезало» на старте, через 6-12 месяцев начинает давить по дискам и памяти.

Третья ошибка - тестировать без метаданных. В проде почти всегда нужны ограничения вроде «только для филиала», «только документы после даты», «только тип: приказ». Эти фильтры меняют и задержку, и точность, поэтому сравнение без них дает красивую, но неверную картину.

Четвертая ошибка - путать требования к RAM и к диску. Если индексу нужно держать структуру в памяти, добавление диска не лечит ситуацию: база замедляется из-за упора в RAM и кэш. Проверьте, что именно хранится в памяти, что на диске, и как поведение меняется при нехватке RAM.

И, наконец, не проверять восстановление. Бэкап делают «для галочки», но ни разу не поднимают систему из него на чистой машине. Простой тест: смоделируйте сбой узла, восстановите базу, убедитесь, что права доступа, метаданные и индексы вернулись, а RAG продолжил отвечать в рамках SLA.

Пошаговый план выбора и чеклист для пилота

Выбор векторной базы для on-prem RAG проще вести как небольшой инженерный проект: понятные входные данные, пилот на своем железе, фиксированные результаты. Так вы не купите решение, которое красиво выглядит в демо, но в эксплуатации упирается в RAM, диск или сложное сопровождение.

Рабочая последовательность обычно такая: описать нагрузки (размер коллекции, прирост, целевой p95, окно индексации и бэкапов, доступность), отобрать 2-3 кандидата по ограничениям закрытого контура (on-prem, нужная ОС, минимум внешних зависимостей), провести пилот на своей инфраструктуре и данных, оценить эксплуатацию (мониторинг, алерты, обновления, роли, аварийное восстановление), сделать расчет ресурсов и стоимости владения на 6-12 месяцев с учетом роста.

Чтобы результаты были сравнимыми, заранее договоритесь о критериях успеха. Например: «p95 поиска не хуже 250 мс при 95% запросов, восстановление из бэкапа не дольше 60 минут, есть понятная схема репликации».

Для протокола пилота хватит короткого чеклиста: p95 latency на типовых запросах под параллельной нагрузкой, рост индекса и время переиндексации, RAM на узел в steady state и при пиках (индексация, compaction), требования к SSD/NVMe и что происходит при деградации диска, рабочий restore и выбранная схема репликации (что именно теряем при сбое).

Финальный выбор удобно оформить таблицей критериев с весами, списком рисков и планом масштабирования. А следующий шаг после выбора софта - утвердить серверную конфигурацию и контур развертывания для пилота и прода. Если проект упирается в подбор on-prem железа и дальнейшую эксплуатацию, такие задачи часто закрывают через системного интегратора и производителя инфраструктуры уровня GSE.kz (gse.kz), особенно когда важны поставка, интеграция и поддержка внутри Казахстана.