Искусственный интеллект без иллюзий: как не сжечь бюджет компании на хайпе (Часть 2)

Это вторая часть цикла публикаций, где мы говорим не о теории искусственного интеллекта ^[1], а о суровой реальнос��и его внедрения в бизнес. В первой части ^[2] мы обсуждали стратегические ловушки, а теперь настал черед уровня данных, который оказался для нас минным полем.

Мы быстро поняли, что успех LLM (будь то дообучение модели или создание RAG-системы) зависит не только от сложности алгоритмов и продуманности уровней, а еще и от того, что мы в эту модель «скармливаем». И здесь нас ждал целый ряд неприятных сюрпризов.

Проблема №1: Иллюзия полноты. «А где словарь?»

Казалось бы, у компании — гигантская база знаний: тысячи документов, нормативных актов (НПА), инструкций. Идеальное сырье для ИИ? Не совсем. Мы столкнулись с коварной проблемой логической неполноты. Данные, даже структурированные, часто ссылаются друг на друга, содержат внутренние сокращения и термины, смысл которых раскрывается в отдельных глоссариях.

С чем мы боролись: Модель, не видя связей между документами из разных доменов, начинала путаться. Два очень похожих по тексту НПА из разных сфер интерпретировались ею одинаково, что вело к фундаментальным ошибкам. Отсутствие «словаря терминов» в общей структуре данных резко снижало качество ответов. Мы осознали: нужен не просто архив файлов, а цельный, связанный корпус знаний. Без специального механизма обеспечения полноты данные остаются набором разрозненных текстов, а не надежной базой для ИИ.

Проблема №2: Бег на месте. Данные устарели быстрее, чем мы настроили пайплайн

В динамичном бизнесе нормативная база и условия оказания услуг меняются постоянно. Мы обнаружили, что часть данных, загруженных в систему, уже неактуальна. Представьте: чат-бот на сайте уверенно рассказывает клиенту об условиях услуги, которые изменились вчера. Последствия — введенные в заблуждение клиенты, репутационный ущерб и финансовые риски.

Наш урок: Неактуальные данные не просто бесполезны — они опасны. LLM, сталкиваясь с противоречиями между старой и новой информацией в своей «памяти», начинает «галлюцинировать», выдавая непредсказуемые и ошибочные ответы. Гарантировать актуальность оказалось задачей, сравнимой с обслуживанием движущегося поезда.

Проблема №3: Хаос. Внутренние противоречия сводят модель с ума

Качество — это не только свежесть и полнота, но и внутренняя гармония. Мы недооценили критическую важность согласованности данных. Внутри одного набора могли соседствовать разные форматы дат, кодировки, стили изложения. Но хуже того — в логических бизнес-процессах, выстроенных на основе нормативов, мы находили прямые противоречия между документами.

Вопрос, который нас преследовал: Что должна выдать модель, если в ее основе лежат взаимоисключающие указания? Ответ: ничего хорошего. Она либо выбирала случайный вариант, либо генерировала третий, придуманный, что было неприемлемо для репутации компании.

Проблема №4: Ответственность растворилась в data lineage

Самое сложное началось, когда мы попытались навести порядок. Мы решили внедрить инструменты контроля качества данных. И столкнулись с главным организационным барьером: непонятно, кто отвечает за истину.

Данные в компании проходят долгий путь: они рождаются в одном отделе, обогащаются в другом, трансформируются в третьем, оседают в различных хранилищах (в том же Hadoop). Когда в финальной точке обнаруживается проблема (неполнота, противоречие), начинается бесконечный поиск виноватого. Кто сгенерировал ошибку ^[3]? Кто ее усугубил при трансформации? Куда смотрела мастер-система? Как нет мастер-система? Ответственные за отдельные узлы этого тракта данных найти удавалось, но общая картина и единый «хозяин» качества данных отсутствовали. Без этого любой фреймворк проверки качества висел в воздухе.

Итог наших испытаний

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

В следующей, заключительной части, мы расскажем о том, к какому решению мы пришли. Речь пойдет о фреймворке, который объединяет принципы «Фабрики Данных», архитектуру Data Mesh для распределения ответственности, инструменты отслеживания происхождения данных (Data Lineage) и, наконец, встроенные инструменты проверки их качества.

До встречи!