RAG с FAISS: локальный векторный поиск без облака

RAG-разработка упирается в лимиты облачного поиска

На пилоте RAG-разработка выглядит безотказно: десятки тысяч фрагментов, ответы мгновенные, индекс пересобирается за минуты. Совсем другое поведение начинается на реальном корпусе, когда в базу знаний попадают миллионы фрагментов из регламентов, обращений и переписки. Здесь облачный индекс перестаёт быть нейтральной деталью — в дело входят лимиты на число обращений в секунду, на объём индекса в рамках тарифа и на частоту переиндексации.

Задержка ответа становится непредсказуемой. Часть запросов встаёт в очередь к внешнему сервису, часть повторяется после отказа по квоте, и верхняя граница времени ответа растягивается в разы, хотя среднее на графиках выглядит прилично. Для диалогового сценария, где человек ждёт ответа у экрана, значение имеет именно верхняя граница, а не средняя.

Вторая линия риска — данные за периметром. Чтобы поиск работал, наружу уезжают тексты внутренних документов, выдержки из учётных систем и переписка сотрудников. Формально это сторонний контур, который нужно согласовывать со службой безопасности, и на части проектов именно согласование останавливает внедрение.

Локальный векторный поиск снимает все три ограничения сразу: индекс лежит рядом с приложением, квоты на обращения к нему не действуют, а время ответа определяется ресурсами собственного узла, а не тарифом внешнего сервиса. Библиотека FAISS подходит для этого без оговорок — индекс живёт на диске и в памяти, сетевых вызовов на каждый запрос нет. Разбираем, как это закрывается на практике.

Что даёт локальный векторный индекс: скорость и контроль

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

FAISS закрывает эту задачу зрелой библиотекой: индекс собирается пакетно, держится в памяти процесса и опрашивается без сетевых переходов. Отсюда предсказуемое время отклика — доли секунды на запрос даже при заметном объёме корпуса, и оно не «плывёт» при росте числа одновременных пользователей.

Нагрузка на сервер смещается туда, где она ожидаема. Поиск по векторам обходится на порядок дешевле генерации ответа, поэтому узкое место — модель, а не извлечение. Если коллекция растёт, индекс делится на сегменты и опрашивается параллельно: пропускная способность масштабируется горизонтально, без обращения к чужому сервису за каждой операцией.

Индекс — это артефакт с версией, и это меняет работу с изменениями. Обновление корпуса идёт пересборкой в отдельной ветке, затем переключение одним действием; предыдущая версия остаётся на диске, откат занимает секунды. Воспроизводимость выдачи тоже становится свойством системы: одна версия индекса и одни параметры поиска дают один и тот же результат — жалобу на качество ответа можно разобрать, а не обсуждать.

Снимается и целый класс отказов: недоступность стороннего сервиса, изменение его условий, исчерпание лимита в пик. Ваш поиск не встанет вместе с чужим контуром — он встанет только вместе с вашим.

Варианты RAG-разработки: облако, локальный контур, гибрид

Схема развёртывания определяет, где хранятся эмбеддинги и векторный индекс, кто отвечает за их обновление и что произойдёт при отказе узла. Разница между вариантами не в качестве ответов, а в требованиях к приватности, частоте переиндексации и допустимой задержке выдачи.

На практике выбор сводится к трём вопросам: где по требованиям могут лежать данные, кто отвечает за обновление индекса после правок в документах и сколько времени допустимо между публикацией документа и его появлением в выдаче. Ответы на них отсекают лишние варианты до начала разработки — так схему не приходится менять на середине.

Как идёт внедрение: от аудита данных до запуска

Мы начинаем не с модели, а с корпуса документов: без разметки источников любой поиск отвечает наугад. Первый этап — аудит данных, и он заранее показывает, где объём работы будет большим, а где хватит быстрой настройки.

1. Аудит данных. Смотрим, что реально лежит в корпусе: форматы, дубликаты, устаревшие редакции, документы с ограничением доступа. На выходе — перечень источников с оценкой пригодности и пробелы, которые придётся закрыть.

2. Проектирование схемы индексации. Определяем, на какие фрагменты режем документы, с каким перекрытием и какие метаданные кладём рядом: раздел, дата, права доступа. Ошибка на этом шаге стоит дороже всего — её видно только при проверке.

3. Настройка поиска. Собираем локальный векторный индекс (FAISS) и добавляем фильтры по метаданным, чтобы сотрудник получал только разрешённые ему документы. Переиндексация идёт по регламенту, а не вручную.

4. Сборка ответа. Модель получает лишь найденные фрагменты и обязана ссылаться на источник. Если подходящего фрагмента нет — отвечает «в базе нет», а не достраивает факты.

5. Проверка качества ответов. Готовим набор эталонных вопросов с известными ответами и считаем долю верных, долю с корректной ссылкой и долю честных отказов. Порог задаём заранее: пока не пройден, в промышленную эксплуатацию не выводим.

6. Передача решения. Отдаём команде заказчика схему индекса, настройки, регламент обновления корпуса и инструкцию по разбору ошибок — дальше систему сопровождают без нас.

Каждый этап заканчивается артефактом, который можно проверить, а не устным статусом. Опишите задачу — вернёмся с оценкой и планом по этапам.

Что остаётся в контуре заказчика: конфигурации и регламенты

Передаём не набор файлов, а работающий контур: каждый артефакт можно открыть, применить и проверить без нашего участия. Ниже — что именно остаётся у вашей команды после сдачи, чтобы обновлять базу знаний, менять права и разбирать сбои своими силами.

• Рабочие конфигурации индекса — параметры разбиения документов на фрагменты, модель построения векторов, порог отсечения нерелевантных результатов и настройки переранжирования. Хранятся в системе контроля версий, изменения проходят ревью.
• Схема развёртывания — состав сервисов, точки взаимодействия, тома для индекса и исходных документов, порядок запуска на ваших серверах или в закрытом контуре без выхода во внешнюю сеть.
• Политики доступа к данным — какие коллекции документов попадают в индекс, разграничение по ролям, журнал запросов и правила обработки персональных и чувствительных фрагментов.
• Регламент обновления индекса — периодичность, инкрементальная догрузка против полной перестройки, окно, в котором поиск остаётся доступным, и порядок отката к предыдущему снимку.
• Инструкция по деградации — как перевести поиск в режим без переранжирования или на разбор по ключевым словам, если выросла нагрузка или отвалился узел с индексом.
• Документация решения — архитектурная схема, перечень точек отказа, известные ограничения качества на коротких и неоднозначных запросах, критерии, по которым считается, что ответ деградировал.
• Порядок эскалации — канал связи, состав дежурной смены с вашей стороны, сроки реакции и условия, при которых подключаемся наши инженеры.

Список закрывается приёмкой: вы запускаете развёртывание по инструкции на своём стенде, обновляете индекс по регламенту и воспроизводите один сбой. Если что-то не воспроизводится без нас — артефакт считаем неполным и дорабатываем.

Кейс: поиск по внутренней базе знаний в закрытом контуре

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

Что изменили

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

Метрики до и после

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

Чем векторный поиск отличается от полнотекстового

Полнотекстовый поиск опирается на инвертированный индекс: документ разбивается на слова, приводится к нормальной форме, и запрос ищет совпадение лексем. Он предсказуем и объясним — видно, по какому слову нашёлся фрагмент. Но стоит пользователю переформулировать вопрос синонимом или допустить опечатку, как выдача пустеет: совпадать словам просто не с чем.

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

Сравнение подходов сводится не к «что лучше», а к типу запроса. Там, где важна точность формулировки — артикул, номер договора, название, реквизит, — надёжнее полное совпадение слов. Там, где пользователь спрашивает своими словами и редко угадывает формулировку документа, выигрывает смысловой поиск.

В рабочем решении обе схемы не конкурируют, а дополняют друг друга. Полнотекстовый поиск забирает точные попадания и отсекает лишнее по метаданным, векторный добирает смысловые совпадения, а объединённый список пересортировывается, чтобы наверху оказался действительно нужный фрагмент. Так растут и полнота, и точность одновременно.

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

Технические вопросы, которые задают до старта

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

Как часто пересобирать индекс?

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

Какой запас по нагрузке останется?

Время ответа растёт нелинейно после определённого числа одновременных запросов, поэтому запас считаем не на глаз. Снимаем профиль на пиковом сценарии, разделяем индекс по коллекциям и добавляем реплики для чтения — держим запас в разы, а не в единицы процентов.

Что происходит после передачи?

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

Обсудим задачу и вернёмся с планом работ

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

• Данные. Объём корпуса, форматы (тексты, таблицы, сканы, переписка), частота обновлений и права доступа. От этого зависит логика нарезки документов на фрагменты и расписание переиндексации.
• Нагрузка. Сколько запросов в час, какая задержка ответа считается приемлемой, сколько одновременных сессий. Это определяет, держим мы индекс в оперативной памяти или разбиваем на шарды.
• Контур. Где физически лежат данные, допустим ли выход во внешнее облако, кто владеет ключами. Если выход запрещён, проектируем полностью локальный векторный поиск на серверах заказчика.
• Критерии приёмки. Набор эталонных вопросов с ожидаемыми ответами и источниками. Фиксируем долю корректных попаданий и долю ответов «не знаю» вместо выдумки — на этом строится приёмка.
• Роли. Кто со стороны заказчика даёт доступы к хранилищам, кто подтверждает качество разметки и кто принимает этапы. Без выделенного владельца данных сроки сдвигаются на этапе интеграции.
• Что присылаем в ответ. План работ по этапам с зависимостями, оценку сроков диапазоном, состав команды с зонами ответственности, схему контура и перечень рисков с планом на каждый.

Следующий шаг — короткий созвон по уточнениям, после которого вы получаете оценку и план в письменном виде. Опишите задачу: что за данные, какой объём и в каком контуре они должны остаться, — и мы вернёмся с конкретным предложением по этапам.