Умный поиск по контенту с ИИ-поддержкой

Умный поиск по контенту с ИИ-поддержкой

Почему обычный поиск уже не справляется
Классический полнотекстовый поиск хорош для баз с десятками тысяч документов и простыми запросами. Но как только появляется сложный мультидоменный архив — от юридических договоров до технических спецификаций — и растёт число запросов, традиционные методы начинают тормозить.
Здесь на помощь приходит RAG (Retrieval-Augmented Generation) — технология, которая сначала находит релевантные фрагменты текста из огромного индекса, а затем генерирует ответы на естественном языке, опираясь на векторные представления данных.

Как мы создали реальный прототип

Работа с бумажным архивом бухгалтерии
Один из клиентов, крупный ритейлер, хотел интегрировать в базу знаний весь архив бухгалтерских справок. Проблема заключалась в том, что 70% документов были в виде сканированных PDF без текстового слоя. Мы выстроили процесс:
- Использовали Tesseract и кастомную языковую модель для извлечения текста.
- Разделили документы на блоки по 300–500 слов, сохранив метаданные: дату, тип отчёта, контрагента.
- Для векторизации выбрали модель Sentence-Transformers all-MiniLM-L6-v2, которая обеспечила баланс между скоростью и точностью для финансовой терминологии.

Первая попытка использовать универсальную модель bert-base-uncased провалилась: она оказалась слишком тяжёлой и не учитывала специфику бухгалтерского сленга, из-за чего время индексации выросло в 3–4 раза.

Выбор векторного индекса
Для базы с 10 миллионами текстовых фрагментов мы сравнили FAISS (Flat и IVF-PQ) и HNSW от nmslib. В итоге остановились на IVF-PQ с 256-ядерным кластером: поиск занимает около 15 мс, а индекс требует всего 1,2 ГБ памяти.

Изначально мы недооценили параметры nlist и nprobe. Слишком малое значение nlist делало стратификацию плоской, из-за чего поиск пропускал релевантные векторы.

Метаданные как ключ к точности
Мы добавили к каждому вектору метаданные: тип документа, регион, ответственного сотрудника. Это позволило фильтровать результаты на этапе генерации ответа, например, показывать только отчёты за последний квартал.

Ранее мы хранили метаданные в отдельной СУБД и делали объединение в реальном времени, но это увеличивало задержку запросов до 2 секунд. Встроив метаданные в векторный индекс, мы значительно ускорили процесс.

API и пользовательский интерфейс
Мы развернули REST-API с endpoint’ами /search и /ask на FastAPI, а для фронтенда использовали React с библиотекой Axios. Кэширование часто задаваемых вопросов через Redis снизило нагрузку на сервер.

Однако без ограничения количества запросов один активный пользователь смог отправить 500 запросов в секунду, что привело к сбою системы. Внедрение throttling решило проблему.

Хранение данных и инфраструктура
Коллеги из Data-Ops часто напоминают: на каждый гигабайт текста нужно закладывать 1,5–2 ГБ под индексы и логи. В нашем случае на 1 ГБ текста пришлось 2,2 ГБ с учётом индексов, кэшей и резервных копий. Лог-агрегаторы вроде ELK-stack оказались незаменимыми для отладки проблемных запросов.

Преимущества RAG в корпоративной среде
RAG меняет подход к работе с данными в разных сферах:
- Клиентская поддержка: быстрый доступ к FAQ, политикам и договорам сокращает время ответа на 30–40%.
- HR-отдел: автоматизированный поиск по резюме и справочникам упрощает подбор кандидатов.
- Юридический департамент: извлечение прецедентов из договоров снижает риск упущений.
- Бизнес-аналитика: генерация инсайтов из отчётов ускоряет анализ в 3–4 раза.
- ИТ-службы: поиск по логам и мануалам сокращает время диагностики инцидентов.

Типичные ошибки и как их избежать
- Неправильный размер текстовых фрагментов: слишком мелкие теряют контекст, слишком крупные замедляют поиск.
- Игнорирование очистки данных: HTML-теги и спецсимволы ухудшают качество векторов.
- Отсутствие обновления моделей: финансовый сленг меняется, поэтому эмбеддинг-модель нужно переобучать раз в полгода.
- Недостаточный мониторинг: метрики вроде задержки и точности поиска должны отображаться в реальном времени, например, в Grafana.
- Отсутствие запасного варианта: если RAG не уверен в ответе, лучше показать исходный документ, чем генерировать ошибку.

Рекомендации для успешного внедрения
- Проанализируйте данные: определите объём, типы файлов и необходимость OCR.
- Выберите подходящую эмбеддинг-модель, желательно доменно-специфичную.
- Настройте векторный индекс с учётом параметров nlist и nprobe.
- Обогатите векторы метаданными для быстрой фильтрации.
- Создайте надёжный API с кэшированием и защитой от перегрузки.
- Настройте мониторинг и регулярное переобучение модели раз в 3–6 месяцев.