Сколько миллионов вы уже сожгли на промпт-инжиниринг, пытаясь отучить корпоративного ассистента выдумывать факты из воздуха? Пока ML-специалисты крутят температуру, переписывают системные инструкции и обвешивают пайплайн костылями вроде гипотетического поиска документов (HyDE) или сложного реранкинга через кросс-энкодеры, реальная проблема остаётся в тени. Ответ на вопрос, почему ваш RAG галлюцинирует — дело не в модели, а в данных: 8 признаков, что компания не готова к ИИ, которые мы разберём ниже, бьют по бюджетам сильнее любых аппаратных санкций.
В 99% случаев нейросеть работает идеально. Проблема в том, что RAG (Retrieval-Augmented Generation) — это предсказуемый математический пайплайн. Он берёт запрос, ищет по векторной базе куски текста с похожим косинусным расстоянием и скармливает их в контекст языковой модели. Если алгоритм достал из базы протухший статус заказа, противоречащие друг другу регламенты и кусок служебного лога с битой кодировкой — LLM прочитает эту помойку и сгенерирует абсолютно уверенную, грамматически безупречную ложь.
Вы пытаетесь лечить перелом подорожником. Модель честно обрабатывает хаос, который вы ей отгрузили.
Почему ваш RAG галлюцинирует — дело не в модели, а в данных: 8 признаков, что компания не готова к ИИ
Рынок завален историями, когда бизнес покупает «внедрение нейронки» за 5–8 миллионов рублей, а на выходе получает бота-шизофреника. Виноватым назначают опенсорсную LLM или «недостаточно умный» API. Начинается бесконечный ресёрч новых весов и файн-тюнинг ради файн-тюнинга.
Всё это — чистый карго-культ. Инженерия начинается не с выбора между Milvus и Qdrant, а с наведения жёсткого порядка в транзакционных системах. Если у вас нет фундамента, любая LLM превратится в высокоскоростной генератор убытков. Цена ошибки за последний год выросла кратно: на дефиците GPU переделка архитектуры под закрытый контур обходится дороже самого пилота. Хотите узнать, как гарантированно провалить проект и пойти писать объяснительную совету директоров? Сверяйтесь с симптомами. Вот диагностический фреймворк выживания.
- Одна сущность в пяти написаниях (отсутствие MDM). В вашей 1С крупный клиент записан как «ООО Ромашка», в CRM это «Ромашка ТД», в биллинге — «romashka_inc», а во внутренней wiki — просто «Ромашка». Единого справочника (Master Data Management) не существует. Что делает классический RAG? Семантический поиск и BM25 радостно тащат в контекст пять разных, логически не связанных кусков информации с разными идентификаторами. Языковая модель не обладает интуицией, чтобы понять, что это одна компания, и синтезирует Франкенштейна. Цена ошибки — сорванные сделки из-за того, что бот заявил сейлзу о нулевом LTV ключевого заказчика. Что чинить: внедрять системы entity resolution и склеивать дубли на уровне хранилища до того, как натравливать на базы алгоритмы векторизации.
- Батчевая загрузка и протухший контекст. Инфраструктура настроена так, что данные перетекают в хранилище монолитным батчем раз в сутки в три часа ночи. Для традиционной BI-аналитики это было нормой, но для реалтайм-ассистента это архитектурная смерть. Пользователь спрашивает о наличии серверов на складе, а RAG отвечает на основе вчерашнего слепка ERP. Серверы отгрузили клиенту два часа назад. Цена ошибки — возвраты платежей, штрафы за срыв SLA и убитая лояльность контрагентов. Что чинить: переводить потоки на Kafka, настраивать Debezium и внедрять CDC (Change Data Capture) прямо из логов БД. Контекст RAG обязан обновляться за миллисекунды.
- Никаких контрактов на данные (Data Contracts). Апстрим — например, инхаус-команда ERP — молча переименовал колонку `client_status` в `customer_state`. Никто никого не предупредил. Python-пайплайн подготовки контекста не упал с фатальной ошибкой, он просто начал заполнять отсутствующее поле значениями NULL. Индекс деградирует незаметно. Через две недели выясняется, что ИИ-помощник массово отказывает в обслуживании VIP-сегменту, потому что не видит их статусов. Цена ошибки — полная потеря доверия бизнеса к ИИ-инструментам. Что чинить: внедрять жёсткую валидацию схем на этапе ингестии. Любое неконтрактное изменение структуры в апстриме должно аппаратно ронять пайплайн с критическим алертом дежурному дата-инженеру.
- Отсутствие владельцев данных (Data Owners). Бот сгенерировал сложный многосоставной отчёт по цепочкам поставок за квартал. Кто в компании обладает квалификацией сказать, что цифры верные? Если у данных нет конкретного физического владельца, вам некому сдавать результаты работы. Инженеры будут вечно бегать между отделами логистики и финконтроля, пытаясь согласовать метрики точности. Цена ошибки — дорогостоящий пилот зависает в корпоративном чистилище навсегда. Что чинить: нет Data Owner с правом подписи и ответственностью за конкретный бизнес-домен — нет интеграции RAG в эту область.
- Мусорная разметка и неспособность построить eval. Вы не сможете победить галлюцинации LLM, если не умеете их автоматически измерять на масштабе. Оценка качества выдачи «на глаз» усилиями пары продактов — это профанация. Классические метрики вроде BLEU или ROUGE здесь абсолютно бесполезны. Если у вас нет ground truth (золотого датасета проверенных пар вопрос-ответ), вы не построите пайплайн LLM-as-a-judge для замера Faithfulness и Answer Relevance. Цена ошибки — любая смена весов модели или алгоритма чанкинга может бесшумно сломать логику ответов, и вы узнаете об этом только по мату клиентов в техподдержку. Что чинить: собирать, верифицировать и размечать датасет до написания первой строчки кода бэкенда.
- Иллюзия облака и игнорирование периметра. Типичная ошибка выжившего: интегратор собирает блестящий PoC на API проприетарных моделей, бизнес в восторге подписывает бюджет. А на этапе деплоя служба безопасности блокирует всё со ссылкой на 152-ФЗ, коммерческую тайну и требования ФСТЭК. Данные не могут покинуть контур предприятия. Когда мы в Morana Labs катили enterprise-поиск для закрытого контура одного промышленного холдинга, стало очевидно: развернуть 70B модель локально с latency меньше секунды — это спецификация конкретных GPU (уровня L40S или A100), которых в корпоративном ЦОДе физически нет. Цена ошибки — проект летит в мусорную корзину, потому что закупка серверов по параллельному импорту займёт девять месяцев и уничтожит экономику пилота. Что чинить: на нулевом этапе проектировать offline-ready архитектуру и резервировать вычислители под on-prem инференс.
- Архитектура полного реиндекса на каждый чих. Ваша корпоративная база знаний насчитывает десять миллионов документов. Рядовой сотрудник исправляет орфографическую ошибку в одном регламенте, и ваша система триггерит пересчёт эмбеддингов для всего монолита. Перестройка графов HNSW (Hierarchical Navigable Small World) ставит локальную инфраструктуру на колени, базы блокируются на запись, диски горят. Цена ошибки — дичайшие операционные расходы на вычислительные мощности и нулевая масштабируемость системы при росте нагрузки. Что чинить: проектировать сложную архитектуру инкрементальных (delta) обновлений, версионирование чанков и мягкое удаление неактуальных векторов без остановки read-запросов.
- Отсутствие профиля baseline. Как было до внедрения ИИ? Инженер техподдержки искал нужный лог 15 минут? Или 2 минуты? Если вы не замерили скорость бизнес-процессов «как есть» до начала разработки, вы никогда не докажете успешность интеграции. Вам буквально не с чем сравнивать. Цена ошибки — вы сделали технологически крутой продукт, но финансовый директор не согласовывает бюджет на развёртывание в прод, потому что ROI (окупаемость) подтвердить невозможно. Что чинить: профилировать операции и фиксировать baseline на уровне SLA до старта работ с машинным обучением.
Data readiness: диагностика вместо хайпа
Подготовка данных для тяжёлых ИИ-проектов — это не та задача, которую можно делегировать джуниору с туториалом по LangChain. Это суровый инфраструктурный хардкор на стыке high-load систем и распределённых баз. Если архитектура данных лежит в руинах, любая, даже самая продвинутая нейросеть будет лишь масштабировать этот хаос со скоростью тысяча токенов в секунду.
Чудес не предвидится. Если хотя бы три пункта из нашего диагностического списка совпадают с текущей реальностью вашей компании, нажимайте на тормоз. Вам слишком рано покупать графические ускорители и хантить специалистов по машинному обучению. Сначала придётся выполнить грязную работу: настроить стриминг событий, внедрить железобетонные контракты на схемы, настроить склейку сущностей и отстроить процессы разметки.
Успех индустриального ML определяется не количеством миллиардов параметров в весах модели, а качеством и предсказуемостью инженерного пайплайна, который её обслуживает. Data-readiness аудит, проведенный ДО старта разработки, покажет реальные узкие места, где система рухнет под боевой нагрузкой. Только трезвая оценка активов позволяет построить B2B-сервис, решающий задачи бизнеса, а не очередную технологическую игрушку, генерирующую правдоподобный бред за ваши деньги.