AI который анализирует документы перед генерацией ответа

AI, который анализирует документы перед тем, как ответить: практический взгляд

Почему анализ документов это важно

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

Опыт разработки и эксплуатации

Интеграция с архивом бухгалтерии
В одном из проектов мы интегрировали систему с архивом бухгалтерских отчётов за пять лет. Большая часть документов оказалась в виде бумажных сканов, а не PDF. Мы создали pipeline: распознавание текста (OCR), разделение на абзацы (чанк-инг) и создание эмбеддингов с использованием модели sentence-transformers (all-MiniLM-L6-v2). Проблема возникла из-за низкого качества сканов: в текстах появлялись “мусорные” символы, что снижало точность поиска. Решением стало добавление предобученного denoising-autoencoder для очистки текста.

Выбор модели эмбеддингов
Для юридических документов, таких как контракты и соглашения, требовался более точный семантический анализ. Мы протестировали три модели: SBERT-large, Universal Sentence Encoder и кастомный эмбеддер на базе FinBERT. Лучший результат показал FinBERT, но только после дообучения на нашем корпусе из примерно 200 тысяч предложений. Важно найти баланс: модели с большим числом параметров увеличивают нагрузку на сервер и заполняют логи при индексации.

Метаданные как ускоритель
В проекте для службы поддержки телеком-компании запросы часто зависели от номера телефона, даты обращения и типа услуги. Мы выделили эти данные в отдельный полутекстовый индекс (Elastic с типом nested). Сначала фильтрация велась по метаданным, а затем — векторный поиск по содержимому. Это сократило время отклика с 2,3 до 0,8 секунды.

Векторный индекс и его типы
Для небольших объёмов данных (менее 10 миллионов документов) подходит Flat-индекс, но он требует много памяти. IVF-PQ — компромисс между скоростью и качеством, подходящий для больших архивов, например, банковских. HNSW обеспечивает высокую точность при ограниченной памяти и часто используется в задачах, где важна точность, например, в патентных базах.

Хранилище и масштабирование
Для хранения векторных представлений и оригинальных файлов мы использовали PostgreSQL с расширением pgvector и объектное хранилище MinIO. Объём данных увеличивается в 1,5–2 раза из-за хранения эмбеддингов, оригиналов и индексов. Поэтому важно заранее предусмотреть резерв по CPU, RAM и IOPS, чтобы избежать сбоев.

Маленькое отступление
Часто в планах проектов упоминается необходимость предусмотреть достаточно места для хранения данных, но забывают про удобство работы с системой. Например, аналитикам нужен удобный UX-поток для запросов через API. Если добавить слой аутентификации без кеширования, запросы будут “тормозить”, а логи заполнятся ошибками 403 Forbidden. Для бизнес-пользователей, работающих через фронт-дешборд, стоит внедрить лёгкий токен-кеш (например, Redis) и механизм обновления токенов.

Частые ошибки и как их избежать

Недостаточная предобработка OCR
Мусор в тексте из-за плохого распознавания снижает качество эмбеддингов. Решение: добавить пост-OCR-чекер, использовать tesseract с проверкой орфографии.

Слишком “тяжёлая” модель эмбеддингов
Модели с высокими требованиями к GPU приводят к сбоям в продакшене. Решение: тестировать лёгкие модели, такие как distil-bert или MiniLM, и применять оптимизацию через ONNX.

Игнорирование метаданных
Поиск только по векторам даёт много нерелевантных результатов. Решение: внедрить поиск и хранить метаданные отдельно.

Неправильный тип векторного индекса
Неподходящий индекс замедляет запросы. Решение: оценить объём данных и выбрать между IVF-PQ или HNSW.

Отсутствие мониторинга
Ошибки в пайплайне остаются незамеченными. Решение: настроить Prometheus и Grafana для отслеживания задержек и ошибок.

Слишком “глубокий” RAG-промпт
Превышение лимита токенов у LLM обрезает важную информацию. Решение: ограничить количество чанков (top-k = 5–10) и использовать summarizer перед отправкой.

Плюсы RAG в корпоративных сценариях

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