Подготовка данных для корпоративного ИИ: решение проблемы “первой мили”

В мире корпоративного искусственного интеллекта назревает проблема, и ИТ-руководители сталкиваются с дилеммой. Как улучшить результаты и снизить затраты на ИИ-инициативы, одновременно защитив корпоративный бренд? В конце концов, высшее руководство все чаще называет внедрение ИИ основным поводом для сокращения штата на 20% и более. Советы директоров и инвесторы компаний оказывают сильное давление на исполнительных руководителей, требуя показать финансовые и ощутимые выгоды от масштабных инвестиций в ИИ, которые обходятся крупным предприятиям более чем в 10 млн. долл. в год, пишет на портале BigDataWire Кумар Гошвами, соучредитель и генеральный директор Komprise.

В целом, пока сложно продемонстрировать окупаемость инвестиций в ИИ. Исследование MIT Research показало, что 95% пилотных проектов генеративного ИИ не приносят измеримой финансовой отдачи, а Gartner прогнозирует, что более 40% проектов агентного ИИ будут отменены к концу 2027 г.

Хотя существует множество факторов, объясняющих низкую рентабельность инвестиций и высокий уровень неудач, качество данных является постоянным препятствием, на которое указывают аналитики. Индустрия ИИ до сих пор фокусировалась на уровне рассуждений, в то время как уровню подготовки данных уделялось сравнительно меньше внимания.

Более того, подготовка данных часто обсуждается в терминах «последней мили»: разбить документы на фрагменты, сгенерировать вложения, загрузить векторную базу данных, построить конвейер поиска. Это предполагает, что к моменту попадания в конвейер данные чистые, классифицированные, управляемые и релевантные, но это в значительной степени не соответствует действительности. Исследования снова и снова показывают, что организации сталкиваются с проблемами, связанными с разрозненностью, управлением и общим качеством данных. Опрос Databricks показал, что только 37% руководителей считают свои приложения генеративного ИИ готовыми к внедрению в производство.

Этот разрыв — проблема «первой мили» ИИ: поиск данных, их понимание, классификация и определение того, что вообще не должно попадать в модель.

Проблема неструктурированных данных для ИИ

Если вы спросите поставщика облачных услуг или платформы LLM, как использовать неструктурированные данные, они почти всегда начнут с того, что посоветуют вам загрузить файлы в хранилище S3 или в озеро-хранилище (lakehouse) данных. Однако этот подход быстро меняется, поскольку объем файловых и объектных данных неуклонно растет, а затраты и риски безопасности для ИИ увеличиваются.

Неструктурированные данные, которые составляют от 80 до 90% новых корпоративных данных, растут примерно в три раза быстрее, чем структурированные данные, и теперь являются исходным материалом, необходимым для каждой корпоративной ИИ-инициативы. Тем не менее, большинство ИТ-команд по-прежнему не могут сказать вам, где все это хранится, каково его содержимое или как безопасно использовать это в ИИ.

Проблема обработки больших объемов неструктурированных данных многогранна, она охватывает следующее:

• файловые хранилища NAS, накопленные за многие годы, и объектные хранилища, распределенные по облачным провайдерам;

• миллиарды разнообразных файлов: документы, отсканированные PDF-файлы, чертежи САПР, архивы электронной почты, мультимедийные файлы, данные приборов и многое другое;

• широко распространены дубликаты, «осиротевшие», тривиальные и «зомби», или «мертвые» данные, засоряющие хранилище и ухудшающие видимость;

• несогласованная структура папок и отсутствие структуры, контекста и богатых метаданных, что затрудняет обнаружение и организацию неструктурированных данных;

• большая часть этих данных трудно поддается запросам, поскольку они не хранятся в базе данных, разбросаны по разрозненным хранилищам и имеют мало идентифицирующих характеристик.

Объяснение проблемы «первой мили»

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

Эта проблема выявлена ​​в исследовании Komprise «2026 State of Unstructured Data Management», согласно которому классификацию и маркировку неструктурированных данных назвали своей главной проблемой при подготовке данных для ИИ 56% директоров по ИТ-инфраструктуре, по сравнению с 41% годом ранее. Управление и безопасность заняли второе место с 46%.

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

Миф об «песочнице» ИИ. До недавнего времени большинство корпоративных ИИ-проектов представляли собой изолированные эксперименты или небольшие проверки концепций. При обработке 500 корпоративных документов их можно вручную выбрать, загрузить в хранилище данных и запустить конвейер RAG. Однако с расширением применения ИИ на более крупные задачи это не масштабируется для рабочих нагрузок, которые могут включать 100 000 или более файлов, с неизвестным процентом файлов, не подходящих для данной задачи.

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

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

Экономика владения. Бизнес-приложения, такие как CRM, ERP и системы взаимодействия с клиентами, влияющие на выручку, имеют финансовую историю и поддержку руководства, поэтому они бюджетируются. Неструктурированные данные в основном находятся в другой бюджетной строке: ИТ-инфраструктура и системы хранения, центр затрат без влияния на доходы. Поиск дубликатов, устаревших или регулируемых файлов, по общему мнению, является более сложной инженерной задачей, но у нее нет бизнес-спонсора в отличие от новой функции CRM. Однако ИТ-команды сейчас понимают, что ИИ зависит от высококачественных, управляемых данных, а подготовка данных требует значительных бюджетных затрат.

Lakehouse не решает проблему

ИИ повысил важность озера-хранилища данных — архитектуры, сочетающей в себе недорогое хранение в озере данных с управлением уровня хранилища данных. Тем не менее, у lakehouse есть ограничения, когда речь идет о курировании неструктурированных данных для ИИ.

Во-первых, lakehouse по-прежнему требует размещения необработанных данных где-то, прежде чем уровень управления сможет с ними работать. Большинство реализаций следуют поэтапной схеме, часто называемой «медальонной архитектурой», размещая необработанные данные в «бронзовом» слое, прежде чем они будут очищены и структурированы. Для строк, извлеченных из CRM, этот шаг обходится недорого. Для петабайтов файловых данных, распределенных по локальным NAS-серверам, нескольким облачным хранилищам и периферийным точкам, это не так, а большие объемы уже являются нормой.

Во-вторых, инструменты, созданные для перемещения данных на платформы, такие как ETL и ELT, не были разработаны для больших наборов неструктурированных данных, распределенных по разрозненным хранилищам.

Это обосновывает подход «нулевого перемещения»: индексировать и классифицировать данные там, где они хранятся, отфильтровывать избыточные, устаревшие, тривиальные (ROT) данные до их перемещения и перемещать только управляемое подмножество, необходимое для рабочей нагрузки. Lakehouse — прекрасное место назначения. Но требует предварительного решения о том, что там должно находиться.

Переход к нулевой фазе

Финансовые затраты на перемещение всего — это только половина проблемы. Другая половина проявляется в том, что производит система ИИ: ввод в модель низкокачественного или дублирующегося контента, как правило, приводит к заведомо неверному ответу. Существуют также затраты на управление. Контроль доступа на уровне файлов существует не просто так, и когда необработанные данные копируются целиком в новую среду, эти средства контроля не всегда переносятся вместе с ними.

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

Вот как развиваются рабочий процесс и набор инструментов для конвейеров обработки данных ИИ:

• инструменты обнаружения и классификации для поиска контента в разрозненных хранилищах;

• платформы управления неструктурированными данными для метаданных, политик и перемещения;

• уровни управления и контроля доступа для обеспечения безопасности и отслеживания происхождения данных;

• инструменты синтаксического анализа, оптического распознавания символов и обогащения для преобразования файлов в пригодный для использования контент;

• уровни поиска и векторного представления для обслуживания рабочей нагрузки ИИ.

В дальнейшем ИТ- и дата-командам необходимо рассматривать индексирование, поиск и классификацию данных как инфраструктуру, а не как второстепенный аспект. Это позволит организациям эффективно отсеивать дубликаты файлов, неавторитетные и нерелевантные данные, одновременно учитывая специфические требования к данным, которые не подпадают под действие нормативных требований и правил безопасности.

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

Предприятиям, которые хотят, чтобы ИИ работал в масштабе с достижимой окупаемостью инвестиций, в первую очередь необходимо ответить на вопрос: «Где хранятся наши неструктурированные данные, что в них содержится и как мы можем обеспечить их доставку с соблюдением принципов управления?», а не «Какую модель встраивания нам следует использовать?».