Давление, связанное с необходимостью запустить ИИ-пилот, возникает раньше, чем у вас складывается полная картина ваших данных. У команды есть вариант использования, модель и дедлайн, и самый быстрый путь — направить модель на самую большую кучу релевантных на вид данных и посмотреть, что вернется.
Эта куча данных обычно является темной. Согласно последнему исследованию Omdia, посвященному готовности корпоративных данных, около половины опрошенных организаций сообщают, что темные данные составляют по меньшей мере половину всего хранимого ими объема. Где-то в них содержится материал, необходимый для пилота, и где-то в них содержится материал, из-за которого пилот может быть заблокирован юридическим отделом, службой безопасности или финансовым департаментом.
Правило их различения простое: разберитесь со своими данными, прежде чем готовить их для ИИ. На практике это четырехэтапная проверка готовности, которая должна предшествовать утверждению любого пилота: обнаружение, классификация, контекстуализация и — наконец — векторизация.
Что такое темные данные на самом деле и почему подход «скормить все модели» не работает
Темные данные — это информация, которую организации собирают, обрабатывают и хранят в ходе обычной деятельности, но редко используют для чего-либо еще. Большая их часть представляет собой неструктурированные данные (старые электронные письма, записи, документы, логи чатов и экспорты, которые никто не удалил). Значительная их доля является избыточной, устаревшей или тривиальной (подкатегория под названием «ROT»).
Однако часть этих данных представляет собой исторические знания, за возвращение которых бизнес был бы готов заплатить, а в эпоху ИИ это материал для обучения и поиска, которым вы уже владеете.
Рисунок 1. Более половины организаций, опрошенных Omdia, сообщили, что по меньшей мере 51% их хранимых данных являются «темными».
Проблема в том, что без надлежащего контекста мусорные (ROT) и пригодные к использованию записи могут выглядеть одинаково. Именно поэтому 76% ИТ-лидеров, опрошенных Omdia, называют темные данные серьезным бизнес-риском, которым они активно пытаются управлять, а 68% говорят, что управление данными — это самая сложная часть внедрения ИИ корпоративного уровня.
И поскольку сортировка — это сложно, распространенным обходным путем является просто пропустить ее, передать всю кучу модели и позволить поиску решать, что является релевантным. Этот обходной путь терпит неудачу четырьмя предсказуемыми способами:
- Вычислительные затраты растут с каждым нерелевантным документом в корпусе.
- Время отклика замедляется по мере роста индекса.
- Угроза безопасности возрастает с каждым конфиденциальным файлом, который попадает в эмбеддинги, поскольку документ, полный персональных или финансовых данных, становится доступным для поиска любому, кто может обратиться к ассистенту.
- Модель выдает уверенные, хорошо сформулированные ошибки, когда она опирается на устаревший черновик вместо актуальной записи.
Данные, готовые для ИИ, — это противоположность понятию «все данные». Это релевантный, регулируемый поднабор для конкретной рабочей нагрузки с достаточным количеством контекста, делающим его надежным. Это лишь малая доля того, что вы храните, и единственный способ найти ее — понять целое, прежде чем прикасаться к чему-либо из этого.
Шаг 1: Обнаружение того, что у вас есть на самом деле
Обнаружение — это инвентаризация. В архивах, хранилищах, экспортах SaaS и базах данных, с которыми соприкасается конкретный сценарий использования, вопрос всегда один: что там находится?
Хороший этап обнаружения говорит вам:
- Что там находится, в штуках и форматах
- Какая часть этого дублирована, пуста или повреждена
- Когда каждый элемент открывался в последний раз
- Какие локации содержат авторитетные записи, а какие — рабочие копии
Обнаружение должно охватывать всю инфраструктуру целиком, а не только то единственное место, которое назвала пилотная команда, поскольку записи в этом месте ссылаются на клиентов, продукты и кейсы, текущие версии которых находятся в другом месте.
Результатом является карта, с которой можно работать, и реальный объем практически всегда меньше «сырого». Для любого общего ресурса, который развивался без присмотра в течение десятилетия, один только показатель дублирования меняет всю картину.
Шаг 2: Классификация данных, а затем сортировка по ценности и риску
Классификация определяет, к какому типу данных относится каждый элемент и что он в себе несет. Это означает выявление персональной и регулируемой информации, маркировку всего, что подпадает под правила локализации или хранения, отделение авторитетных записей от черновиков и копий, а также запись происхождения (lineage), чтобы вы знали, какая версия заменяет какую. Этот процесс должен выполняться непрерывно, поскольку инвентаризационные данные устаревают на следующий день после их составления.
После завершения обнаружения и классификации вы можете разместить найденное на матрице, которую Omdia использует для темных данных, и отсортировать их по ценности для бизнеса и риску.
Рисунок 2. Оценка корпоративных данных по степени риска и ценности может помочь организациям определить, как ими управлять.
Не ко всем корпоративным данным следует относиться одинаково. Оценка данных по их ценности для бизнеса и риску может помочь вам определить следующий шаг:
- Высокая ценность, низкий риск: быстрая активация. Это авторитетные записи без конфиденциального контента. Именно это пилот должен увидеть в первую очередь.
- Высокая ценность, высокий риск: активация со строгим управлением. Сюда относятся авторитетные записи, содержащие персональные, финансовые или регулируемые данные. Они пригодны к использованию после настройки контроля доступа и происхождения.
- Низкий риск, низкая ценность: архивация или удаление для сокращения затрат. Это могут быть черновики, дубликаты или пустые папки.
- Низкая ценность, высокий риск: обеспечение безопасности или удаление. Это конфиденциальный контент, который не нужен для сценария использования — ответственность без какой-либо выгоды.
Теперь массив данных, поступивший в виде одного недифференцированного запроса, разбит на четыре категории, к каждой из которых прилагается свое решение.
Шаг 3: Добавление контекста, который модель не может вывести самостоятельно
Классификация говорит вам, что документ является авторитетным источником, содержащим персональные данные. Она не говорит вам, что эта запись принадлежит клиенту с тремя активными дополнениями, открытым эскалационным кейсом и продлением в следующем квартале. Эти взаимосвязи являются контекстом, и модель не может вывести их только из документа.
Добавление контекста означает сопоставление каждого актива данных с его реальным бизнес-значением и с другими активами, с которыми он связан. Когда кто-то спрашивает об обязательствах клиента, поиск возвращает действующее соглашение и вносящие в него изменения дополнения в правильном порядке, а не каждый документ, в котором упоминается имя клиента. Ответы становятся точнее, а контекстное окно уменьшается, что означает меньшие затраты на токены.
Результатом является набор взаимосвязей, которым может следовать поиск, благодаря чему каждый ответ исходит из актуальной записи и всего, что вносит в нее изменения.
Шаг 4: Векторизация только того, что прошло проверку, с сохранением привязанных правил
Теперь выполняйте эмбеддинг. Разбейте документы, прошедшие с шага первого по третий, на фрагменты, превратите фрагменты в эмбеддинги и проиндексируйте их так, чтобы модель выполняла поиск по смыслу. Все, что пилотная команда хотела сделать в первый день, происходит здесь, на основе корпуса, который уже прошел инвентаризацию, сортировку и связывание.
Первые три шага окупаются немедленно. Дубликаты и черновики не попадают в индекс, поэтому он меньше, его дешевле создавать, а запросы обрабатываются быстрее, и модель не может построить ответ на основе устаревшей версии. Теги классификации становятся поисковыми фильтрами: запрос от пользователя, у которого нет допуска к записи, возвращает отредактированный или скрытый ответ, а происхождение позволяет проследить любой ответ до его исходного фрагмента. Права исходных систем не переносятся в векторный индекс сами по себе. Их переносят теги.
Сделайте эмбеддинг сначала, а классификацию потом — и ничего из этого не будет существовать. Исправление этого потребует отбросить индекс и перестроить его заново.
На четвертом этапе создается управляемый индекс, который пилот считывает через API, и конвейер, который продолжает работать. Новые файлы проходят этапы с первого по третий перед тем, как они будут встроены, поэтому проверка продолжает защищать пилотный проект после запуска.
Выполните эти 4 шага на данных там, где они хранятся
Каждый из этих шагов предлагает сначала переместить данные: на платформу обнаружения, в lakehouse и в векторную базу данных с собственным хранилищем. Каждое перемещение создает копию, а каждая копия нуждается в собственной инвентаризации, классификации и средствах контроля доступа. Проверка, призванная уменьшить объем ваших скрытых данных (dark data), увеличивает его.
Вместо этого выполняйте их на месте. Обнаруживайте и классифицируйте данные там, где они находятся — в SaaS, облачных, локальных (on-prem) и устаревших системах, — не устанавливая ничего на источники. Создавайте векторные представления (embeddings) из используемых вами файловых хранилищ и хранилищ объектов без промежуточного копирования, чтобы данные оставались внутри среды, которая ими уже управляет.
Мы создали наши инструменты управления данными на основе этого принципа. Everpure Data Intelligence охватывает первые три шага во всей инфраструктуре и предоставляет граф знаний, лежащий в основе третьего шага. Everpure Data Stream выполняет четвертый шаг в ваших существующих хранилищах NFS и S3 и применяет средства контроля доступа на уровне источника перед созданием векторных представлений.
Белая книга «Take Control with AI-Ready Data» подробно описывает каждый шаг: от обнаружения до управляемой доставки, а также содержит вопросы, которые стоит задать относительно собственной инфраструктуры. Лучшими входными данными для вашего следующего пилотного проекта, вероятно, является скрытая половина ваших данных. Узнайте, какая именно, прежде чем его запустить.











