Платформа данных для рабочих нагрузок ИИ в Azure

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

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

• Может ли модель достичь ожидаемой производительности с помощью данных из одного источника?
• Предоставляет ли хранилище исходных данных возможности аналитики или поиска?
• Являются ли исходные данные уже структурированы и индексированы для поисковых систем на основе ИИ или векторного поиска?

Если ответ да для большинства этих вопросов, сложная архитектура может не потребоваться. Например, такие базы данных, как Azure Cosmos DB и База данных SQL Azure, уже поддерживают типы векторных данных и векторный поиск, но их необходимо включить и настроить. Эти возможности могут снизить потребность в отдельных индексировании или специализированных векторных базах данных, минимизируя перемещение данных при повышении производительности.

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

В этой статье приводятся рекомендации по выбору платформы данных для рабочих нагрузок, в которых данные должны храниться, обрабатываться или анализироваться. Основное внимание уделяется решениям, поддерживающим генерируемый ИИ (GenAI). Мы настоятельно рекомендуем понять принципы хорошего проектирования конвейера данных перед изучением технологических возможностей, которые описаны в этой статье. Дополнительные сведения см. в разделе "Проектирование данных по заземлениям".

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

Рекомендации по использованию платформы хранилища данных

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

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

Ниже приведены несколько вопросов, которые помогут вам выбрать технологию хранения данных.

Может ли платформа обрабатывать различные форматы данных?

Хранилище данных должно хранить различные форматы данных и при необходимости преобразовывать данные между ними.

Например, если конвейер приема добавляет данные из реляционной базы данных и JSON-файла, он должен поддерживать структурированные и полуструктурированные данные. Возможно, вы захотите преобразовать ваши данные в Delta формат, чтобы воспользоваться более широкими функциональными возможностями технологии Delta Lake. Платформа должна предоставлять встроенные средства для такого преобразования, чтобы не нужно писать пользовательский код.

Вы планируете хранить несколько версий данных?

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

Управление версиями имеет другие преимущества. В некоторых случаях может потребоваться отдельная копия данных для разных вариантов использования. Каждая копия может развиваться независимо, и платформа должна управлять версиями во всех копиях, чтобы сохранить контекст для моделей ИИ.

Есть ли у платформы встроенные возможности управления жизненным циклом данных?

Управление жизненным циклом данных (DLM) помогает управлять ростом от создания до удаления. Платформа должна автоматически удалять промежуточные копии, управлять архивными данными и поддерживать хранение нормативных требований при необходимости. Без этого данные могут увеличиваться неуправляемо и что ненужный объем может затруднить обработку. Например, для повышения качества данных может потребоваться повторно выполнить шаги предварительной обработки несколько раз. Платформа должна автоматически удалять промежуточные копии, если они больше не нужны.

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

Поддерживает ли платформа функции управления данными?

Аудит является важным аспектом для рабочих нагрузок ИИ. Платформа должна поддерживать тропы аудита для отслеживания доступа к данным, обеспечения конфиденциальности и происхождения данных документов. Он также должен поддерживать словарь данных или каталог, который управляет метаданными, типами данных, назначением и происхождением, особенно при получении данных из нескольких источников.

Сколько данных вы планируете хранить?

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

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

Важно ли это хранилище данных для надежности рабочей нагрузки?

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

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

У вас есть какие-либо ограничения затрат?

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

Необходимо ли поддерживать суверенитет данных или региональные требования к соответствию?

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

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

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

Варианты технологий

Рекомендации по использованию платформы обработки данных

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

Существует два места, где может произойти обработка:

• Уровень приема. Конвейер поглощения собирает данные из различных источников и перемещает их в агрегированное хранилище данных. Таким образом, он часто выполняет базовую предварительную обработку или форматирование, чтобы данные можно было запрашивать. Чтобы уменьшить потребность в пользовательском коде, лучше всего использовать платформу данных, которая обрабатывает максимальное количество этих данных. При оценке средств рассмотрите функции ETL или ELT, необходимые для поддержки рабочих нагрузок ИИ, таких как расширение данных.

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

К типичным задачам относятся:

• Распознавание сущностей и обогащение данных
• Интеграция дополнительных источников данных
• Выполнение подстановок и преобразований
• Очистка или удаление неуместных данных

Надежная платформа данных помогает эффективно автоматизировать и оркестрировать эти операции.

Что такое поддержка подключения к источникам данных?

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

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

Может ли платформа обрабатывать различные форматы данных?

Данные приходят во многих фигурах: структурированные (SQL, реляционные таблицы), полуструктурированные (JSON, XML, Parquet) и неструктурированные (документы, изображения) и потоковая передача (данные Интернета вещей). Выберите платформу, которая может обрабатывать форматы, необходимые для выполнения непосредственных и долгосрочных требований.

Предоставляет ли платформа функции для подготовки и повторного создания данных?

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

• Удаление повторяющихся и заполнение отсутствующих значений
• Выполняйте стемминг, нормализацию и другие основные задачи по очистке при планировании поддержки поиска с использованием ключевых слов или гибридного поиска (ключевое слово+вектор)
• Поддержка расширенных преобразований, таких как фрагментирование, обогащение и анализ документов

Если хранилище данных поддерживает эти операции на уровне системы, данные можно обрабатывать без перемещения. В противном случае используйте внешние инструменты, такие как Azure Databricks или Фабрика данных Azure для тяжелых преобразований.

В некоторых случаях вы можете делегировать часть этой ответственности платформе, которая поддерживает следующий этап. Типичным примером этого подхода является реализация RAG. Во время обработки документы делятся на небольшие блоки, при этом каждый блок хранится в виде отдельной строки в индексе. Затем эти блоки соединяются с векторными вложениями, часто создаваемыми с помощью службы OpenAI. В службе "Поиск ИИ Azure" этот процесс управляется как часть конвейера обогащения во время индексирования, где документы обрабатываются моделью внедрения (например, моделью внедрения OpenAI) для создания векторных представлений, которые затем хранятся в индексе.

Существует ли встроенный оркестратор для управления рабочими процессами?

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

• Поддержка зависимостей заданий и проверки последовательности выполнения
• Гибкое изменение рабочих процессов, которое позволяет легко настраивать без перезаписи больших частей кода.
• Возможности мониторинга и ведения журнала

Популярные средства включают Azure Data Factory с его богатым набором возможностей для управления рабочими процессами, а также Azure Databricks для более сложной оркестрации. Если затраты являются проблемой, Apache NiFi или Airflow могут быть более экономичными альтернативами.

Сколько данных вы ожидаете принять?

Оцените, сколько данных вы будете получать и с какой частотой будет происходить получение. Например, если вы ожидаете загрузить 10 терабайт данных ежедневно в индекс, платформа должна поддерживать строгую параллелизацию и распределенное выполнение. Для небольших рабочих нагрузок более простые инструменты, такие как Logic Apps, могут подойти, но для больших объемов лучше использовать Data Factory или Databricks. Для масштабируемости и пропускной способности рекомендуется:

• Объем данных и частота
• Допустимые требования к задержке
• Сложность задания

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

Какие возможности мониторинга вам нужны?

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

• Отслеживание хода выполнения задания
• Журналы, метрики и оповещения для понимания поведения конвейера
• Интеграция с более широким стеком мониторинга

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

Сколько надежности вы ожидаете от платформы обработки данных?

Выберите платформу, которая сводит к минимуму отдельные точки сбоя и поддерживает повторные попытки для неудачных задач. Например, размещение пользовательской логики обработки, вызываемой фабрикой данных в службе Azure Kubernetes (AKS), обычно обеспечивает более надежную надежность, чем размещение в Azure Logic Apps.

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

Существуют ли ограничения затрат?

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

Каковы требования безопасности рабочих процессов и данных, которые вы обрабатываете?

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

• Соответствует законам о местонахождении региональных данных. Возможно, вам потребуется запустить отдельные конвейеры для разных регионов, таких как один для Европы и другой для Америки, чтобы соответствовать местным нормативным требованиям.
• Поддерживает управление удостоверениями и доступом (IAM), чтобы гарантировать доступ только авторизованных удостоверений к заданиям или определенным шагам в рабочих процессах.
• Позволяет точно контролировать доступ на уровне рабочего процесса или шага.

Варианты технологий

Рекомендации по индексу поиска

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

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

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

Какие типы поиска поддерживают индекс поиска?

Каждый запрос к системе может привести к одному или нескольким запросам к индексу. Для извлечения с дополненным созданием (RAG) и других нагрузок, управляемых ИИ, векторный поиск является обязательным. Векторный поиск позволяет системе находить семантические точки данных с помощью внедренных выражений, а не точных совпадений ключевых слов.

Однако объединение векторного поиска с полнотекстовым поиском, фильтрацией и специальными типами данных (например, геолокацией) делает индекс гораздо более мощным.

Проектирование данных должно четко указать, какие типы поиска необходимы и как они должны работать вместе. Дополнительные сведения см. в разделе "Эффективный запрос" в конструкторе данных.

Как индекс обрабатывает многомодальные данные?

Рабочие нагрузки ИИ часто имеют дело с данными, которые включают не только текст, но и изображения, аудио или видео. Сам индекс не может напрямую понять изображения. Таким образом, прежде чем добавлять изображения в индекс, их необходимо преобразовать в текстовое представление (с помощью OCR или субтитров изображений), из которого создаются внедрения, или векторные внедрения можно создавать непосредственно из изображения с помощью моделей зрения. Затем индекс может выполнять векторный поиск, разрешая семантические запросы.

В этом случае индекс поиска должен иметь следующее:

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

Поддерживает ли индекс возможности автоматического обновления при изменении данных в источниках данных?

Автоматизация является ключом для поддержания свежести данных. Выберите индекс, поддерживающий автоматическое обновление или добавочное обновление при изменении базовых данных.

Если платформа не поддерживает это изначально, вам нужно будет разработать пользовательский процесс для обнаружения и отправки обновлений. Выгрузка этой ответственности на платформу может снизить эксплуатационные расходы и упростить обслуживание, особенно при росте объемов данных.

Может ли индекс выполняться с большими объемами данных?

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

Выбранная платформа должна иметь следующие возможности:

• Горизонтальное масштабирование по мере роста данных
• Поддержание производительности запросов при тяжелой нагрузке
• Хранение необработанных данных и связанных метаданных, обогащений и сущностей

Есть ли у индекса встроенные функции надежности?

Надежность индекса поиска должна соответствовать надежности конечной точки вывода данных, так как оба являются частью одного пути обработки в режиме реального времени.

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

• Возможности высокой доступности и зональной избыточности для устойчивости к сбоям в зонах и регионах.
• Автоматическое восстановление и простое перестроение индекса, чтобы предотвратить использование поврежденного индекса для вывода.
• Возможности индексных псевдонимов или свопа для обновлений без простоя.

Кроме того, изучите режимы сбоя системы или индикаторы стресса, такие как ограничение. Например, во время переиндексации фона пропускная способность может отпасть. Система обычно может обрабатывать 50 одновременных пользователей, но только 30 во время этого задания. Планы по времени и ресурсам для задач, учитывая как запросы фронтальной части, так и задачи по обслуживанию серверной части.

Каковы основные факторы стоимости этой технологии?

Затраты на индекс поиска обычно основаны на использовании, поэтому важно моделировать ожидаемый объем данных, частоту запросов и пропускную способность.

Большинство платформ индексов, таких как поиск ИИ Azure, — это предложения платформы как услуга (PaaS), где цены абстрагируются и представлены в единицах емкости, хранилища и использования функций.

Помните:

• Ограничения многоуровневого ценообразования и масштабирования
• Дополнительные затраты на расширенные функции (например, извлечение изображений или обогащение набора навыков)
• Неиспользуемые ресурсы на избыточно выделенных уровнях
• Сложность индекса (количество индексов и ограничения одновременных запросов)

Сведения о затратах, связанных с поисковым сервисом ИИ, см. в статье "Планирование и управление затратами на службу поиска ИИ".

Соответствуют ли функции безопасности индекса вашему проектированию данных по безопасности?

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

• Маскирование данных и удаление персонально идентифицируемой информации (PII)
• Управление удостоверениями клиента с помощью системы Microsoft Entra ID
• Элементы управления доступом на уровне документа для фильтрации результатов на основе удостоверения пользователя

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

С точки зрения безопасности сети индекс должен:

• Поддержка контроля исходящего трафика и сегментации сети
• Интеграция с частными сетями при выполнении вычислений в виртуальной сети
• Используйте управляемые удостоверения для аутентификации через Microsoft Entra ID
• Избегайте предоставления компонентов непосредственно в общедоступном Интернете

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

• Шифрование при хранении и передаче
• Строгие элементы управления доступом
• Подключение к частной сети, описанное выше
• Мониторинг встраивания конечных точек для аномалий или вмешательства

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

Варианты технологий

Рекомендации по обучению и тонкой настройке

При проектировании платформы данных для традиционных рабочих нагрузок машинного обучения (ML) или не-GenAI фокус перемещается с вывода в режиме реального времени на качество данных, воспроизводимость и разделение среды. Эти рабочие нагрузки используют хорошо структурированные агрегированные данные и часто включают дополнительные уровни, такие как хранилища функций и хранилища данных пакетного вывода, для оптимизации производительности модели и эффективности затрат.

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

Планируете ли вы проводить тренинг с производственными данными?

Развертывание моделей определяет, насколько тесно рабочие данные связаны со средой разработки. Существует два основных подхода к развертыванию:

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

• Развертывание кода. Модель обучена с помощью непроизводственных данных в разработке и взаимодействует только с реальными данными после развертывания в рабочей среде. Этот метод упрощает безопасность разработки, но может увеличить затраты на вычисления и хранение, так как обучение может повторяться в нескольких средах.

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

Вы приоритетите удобство работы над функциональностью?

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

Записные книжки отлично подходят для анализа аналитических данных, но они не являются фактором, определяющим для выбора платформы данных производственного класса. Вычислительные ресурсы ноутбука обычно находятся за пределами агрегирующего хранилища данных и интегрируются с внешними инструментами, такими как Azure Machine Learning или Databricks Workspaces.

Приоритет основных возможностей, таких как управление версиями данных, масштабируемость и безопасность, — по сравнению с удобствами.

Как обрабатывать и подготавливать данные?

В рабочих нагрузках машинного обучения шаблон обработки данных, который вы выбираете, оказывает большое влияние на гибкость и производительность.

• ETL (извлечение, преобразование, загрузка) — распространенный в традиционном хранилище данных, где ограничения схемы требуют преобразования данных перед загрузкой в целевую систему.
• ELT (Извлечение, загрузка, преобразование) — типично для озер данных или архитектуры lakehouse, где сначала загружаются необработанные данные, а затем они преобразуются с помощью таких инструментов, как Python или PySpark.
• EL (Извлечение, загрузка) — распространенные в шаблонах GenAI и RAG, где сначала хранятся документы или носители и выполняются нижестоящие преобразования (например, извлечение фрагментов текста или изображения).

ELT часто предпочтителен, так как он сохраняет необработанные данные и позволяет более гибкие преобразования во время подготовки модели.

Вам нужен магазин компонентов?

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

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

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

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

Следует ли использовать пакетное хранилище данных вывода?

В некоторых случаях можно повысить производительность и сократить затраты, выполнив вывод в пакетном режиме, то есть предварительно вычисляя результаты вывода и сохраняя их для последующего использования вместо вызова модели в режиме реального времени.

Этот подход может быть очень эффективным, если те же запросы или прогнозы запрашиваются многократно (например, создание часто задаваемых вопросов или стандартных рекомендаций).

Основные преимущества:

• Уменьшается задержка и улучшенная пользовательский интерфейс, результаты обрабатываются мгновенно.
• Упрощенная масштабируемость, так как вывод может быть пакетным и распределенным в автономном режиме.
• Улучшенная надежность, которая позволяет избежать загрузки в режиме реального времени на конечную точку вывода.
• Более низкие затраты на вычислительные ресурсы, связанные с пакетной обработкой, могут использовать оборудование более низкого уровня.
• Встроенная предварительная проверка, в которой результаты можно проверить на точность перед предоставлением пользователям.

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

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

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

Варианты технологий

Следующие шаги