Почему ИИ-агенты врут и путают данные. Разбираем архитектуру, которая это решает
Компания подключила ИИ-агента к своим документам. Первые недели все счастливы: агент отвечает по регламентам, находит нужные инструкции, экономит время. Потом база растет, документов становится тысячи, и агент начинает чудить.
Спросили про один жилой комплекс, он выдал телефон из другого. Попросили инструкцию по конкретной модели экскаватора, получили ответ по похожей, но другой. Люди злятся: ты же ИИ, как ты можешь такое выдавать?
Разберем, почему так происходит и как это решается архитектурно.
Как ломается простой RAG
RAG (Retrieval-Augmented Generation) работает в четыре шага: пользователь задает вопрос, система ищет похожие документы в базе, передает их нейросети, та формирует ответ. Не из головы, а на основе реальных данных.
Пока документов мало и они на разные темы, все отлично. Проблемы начинаются, когда документы похожи друг на друга.
Управляющая компания обслуживает десятки ЖК. В каждом почти одинаковый набор информации: отличия минимальны: другие телефоны, другая обслуживающая организация. Житель спрашивает, кому звонить по поводу протечки. Агент находит десяток похожих документов, берет данные не из того ЖК и выдает чужой номер.
Почему? Поиск работает по смысловой близости: текст переводится в числовые векторы, ищутся ближайшие. Когда документы на разные темы, перепутать их сложно. Но когда в базе 50 инструкций по ремонту похожих экскаваторов, все они оказываются рядом в векторном пространстве. Нейросеть получает кучу похожих текстов и собирает из них кашу.
Чем больше документов, тем хуже. Это не баг конкретной модели, а ограничение подхода.
Как выглядит RAG, который работает
Разница между демо и продакшн примерно как между прототипом и серийным автомобилем. Выглядит похоже, внутри совершенно другая инженерия.
Умная индексация
Когда документ попадает в базу, нельзя просто нарезать его на куски и закинуть в векторное хранилище. Нейросеть сама классифицирует документ (инструкция, регламент, контактная информация), извлекает ключевые сущности (модель техники, название ЖК, отдел) и формирует метаданные для фильтрации.
Перед добавлением система сверяет новый документ с тем, что уже есть. Если в одном регламенте написано одно, а в новом по той же теме другое, система сигнализирует. Без этого база со временем начинает противоречить сама себе.
Многоступенчатый поиск
Вместо одного запроса в базу работает цепочка. Сначала нейросеть разбирает запрос: что ищет пользователь, к какой категории это относится, нужна ли конкретная модель техники. Потом запрос уходит в базу с фильтрами, только по нужному разделу. Это сразу отсекает массу нерелевантных документов.
Дальше реранкер. Из нескольких сотен найденных документов он отбирает 10-15 самых подходящих. Это может быть отдельная модель, заточенная именно под переранжирование. И только после этого отфильтрованные документы попадают в основную нейросеть для генерации ответа. Со ссылками на источники, чтобы можно было проверить.
Права доступа
HR-документы видит только HR. Финансовые отчеты только руководство. При добавлении документа фиксируются права доступа, при каждом запросе бэкенд проверяет, кто спрашивает, и не отдает документы, к которым у пользователя нет доступа.
RAG не единственный инструмент
Задача бизнеса не "внедрить RAG", а сделать так, чтобы сотрудники быстро находили нужное в корпоративных данных. RAG - один из способов. Есть полнотекстовый поиск по подготовленному индексу (хорош для точных совпадений), гибридный подход (два параллельных поиска, результаты агрегируются), граф знаний (RAG плюс связи между документами).
Для каждой базы знаний работает свой набор инструментов. То, что отлично работает для IT-документации, может не подойти для каталога запчастей.
Автотестирование
Запустить и надеяться на лучшее - не вариант. Составляется таблица с вопросами и эталонными ответами. Система прогоняет все вопросы, ИИ-судья сравнивает ответ с эталоном и ставит оценку от 0 до 100.
Добавили новые документы, прогнали тесты, увидели падение точности с 85 до 72. Значит, что-то пошло не так. Разбираемся до того, как пользователи начнут жаловаться.
Сколько это стоит
Основная статья расходов - обращения к нейросети при генерации ответов. Эмбеддинг (индексация) стоит на порядок дешевле, его можно не учитывать.
Гибридный вариант: тяжелые операции (классификация, индексация) на локальной open source модели, финальную генерацию на мощной облачной. Экономия в разы.
Полностью локальный вариант: если данные не должны покидать контур компании (для многих это требование законодательства), все разворачивается на собственном сервере. Единовременные затраты на железо, зато никаких ежемесячных платежей за токены и никаких вопросов по трансграничной передаче данных.
Что из этого следует
"Мы подключили RAG" и "у нас работает база знаний" - разные вещи. Первое можно сделать за день. Второе требует проектирования: умная индексация, многоступенчатый поиск, реранкинг, контроль противоречий, права доступа, автотестирование.
Мало кто умеет собирать RAG так, чтобы он работал на десятках тысяч документов. Мы работаем с этой технологией на реальных проектах и знаем, где она ломается и как это чинить.
Если думаете о базе знаний для ИИ-агента, напишите нам. Начнем с аудита данных и подберем архитектуру под вашу задачу.
