Система дополненного поиска ИИ

Система дополненного поиска ИИ в корпоративных проектах: от идеи к эксплуатации

Почему дополненный поиск важен для бизнеса

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

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

Как строится цикл разработки

Разработка RAG системы проходит через несколько этапов, каждый из которых имеет свои особенности и потенциальные сложности.

Аудит источников данных. Начинается с анализа доступных репозиториев: корпоративных wiki, PDF-отчетов, баз «1С» или старых таблиц Excel. Часто выясняется, что часть данных, например, бухгалтерские акты, хранится только в бумажном виде, что требует применения OCR и последующей обработки текста.

Подготовка эмбеддингов. Выбор модели для создания эмбеддингов (например, Sentence-Transformer, FastText или OpenAI embeddings) критически важен. Неправильно подобранная модель может привести к размытым эмбеддингам, из-за чего точность поиска падает до 45%.

Индексация. Создание векторного индекса (HNSW, IVF-PQ, ScaNN) зависит от типа данных. Для чистого текста лучше подходит HNSW, а для длинных юридических документов — IVF-PQ с предварительной разбивкой на фрагменты.

Работа с метаданными. При встраивании данных важно сохранять метаданные, такие как идентификатор документа, дата, департамент или тип источника. Пропуск, например, поля «конфиденциальность» может привести к утечке чувствительных данных в продакшене.

Создание API-слоя. Для взаимодействия с фронтенд-приложениями разрабатывается REST-эндпоинт (например, на FastAPI) или GraphQL-прослойка. Ошибки в аутентификации могут привести к отказу в доступе или переполнению логов ошибками.

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

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

Примеры из практики

Бухгалтерский архив на бумаге. Крупный производитель хотел ускорить ответы клиентской поддержки на вопросы вроде «Сколько было отгружено в июле 2022 года по контракту №12345?». Данные хранились в бумажных архивах. Мы внедрили OCR-пайплайн на базе Tesseract с кастомной постобработкой, преобразовали документы в текст и создали эмбеддинги с помощью Sentence-BERT-large. Это позволило находить точные данные за секунды вместо часов ручного поиска.

Выбор эмбеддинг-модели для юридических текстов. В юридическом департаменте требовались ответы по нормативным актам. Изначально использовалась модель OpenAI ada-002, но точность поиска не превышала 40% из-за длинных абзацев. Переход на Legal-BERT, обученный на судебных текстах, и использование Chunk-Splitter для разбивки документов на 512-токенные фрагменты повысил точность до 78% без изменений в инфраструктуре.

Метаданные и векторный индекс. Для отдела маркетинга был создан справочник рекламных кампаний с 10 миллионами записей. Использование HNSW-индекса с дополнительной фильтрацией по полям «тип кампании» и «регион» сократило количество ошибочных результатов в 10 раз, а время ответа снизилось до 120 мс даже при запросах через мобильное приложение.

Особенности хранения данных

Для эффективной работы системы важно правильно рассчитать объем хранилища. Как правило, для векторных представлений (эмбеддингов) требуется в 1,5–2 раза больше места, чем для исходных текстовых данных, что может составлять от 0,5 ГБ до нескольких гигабайт в зависимости от размерности эмбеддингов. Также необходимо предусмотреть место для резервных копий, хранения логов и удобный API для интеграции новых документов. Эти аспекты часто упускаются на этапе планирования, что приводит к проблемам при масштабировании.

Типичные ошибки и их предотвращение

Неправильный размер вектора. Высокая размерность эмбеддингов (например, 1536) увеличивает затраты на память и замедляет поиск. Для легких запросов стоит использовать модели с размерностью 384 и применять квантование (PQ) для более сложных задач.

Отсутствие фильтров по метаданным. Без фильтров поиск может выдавать документы из других департаментов, нарушая безопасность. Решение — добавить параметры фильтрации в запросы к индексу (поддерживаются FAISS или Milvus).

Частое переиндексирование. Пересоздание индекса для каждого нового документа снижает производительность. Лучше внедрить инкрементальное обновление с периодическим объединением данных.

Слабый мониторинг. Без контроля метрик задержки или точности поиска сложно вовремя заметить проблемы. Настройка дашбордов с Prometheus и Grafana (задержка, точность, использование RAM) помогает избежать сбоев.

Недостаточная очистка текста. Спецсимволы, таблицы или подписи ухудшают качество эмбеддингов. Необходимо применять предварительную обработку: удаление HTML, преобразование таблиц в CSV, нормализацию Unicode.

Перегрузка API. При пиковой нагрузке (например, 1000 запросов в секунду) возможны сбои. Введение ограничения скорости (rate-limiting) и горизонтальное масштабирование API решают проблему.