Поделиться через

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

Рекомендации

Ниже приведена сводка рекомендаций, приведенных в этой статье.

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

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

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

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

▪ Рекомендации по хранилищу компонентов
▪ Рекомендации по автономному выводу хранилища данных

Рекомендации по хранению агрегированных данных

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

Примечание.

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

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

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

Функциональные требования

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

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

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

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

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

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

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

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

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

    Управление жизненным циклом данных (DLM) — это процесс управления данными от его создания до удаления, с такими этапами, как сбор данных, хранение, использование, архивация и удаление.

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

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

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

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

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

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

  • Планируете ли вы проводить обучение с рабочими данными?

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

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

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

Нефункциональные требования

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

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

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

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

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

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

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

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

    Как правило, вам не нужно создавать резервные копии этих данных. Тем не менее, если стоимость агрегирования данных каждый раз с нуля значительно высока, можно рассмотреть возможность повторного копирования данных из резервной копии.

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

    Если достаточно надежности и производительности данных, рассмотрите влияние на затраты.

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

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

Рекомендации по обработке данных

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

  • Уровень приема

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

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

  • Уровень обработки

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

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

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

Примечание.

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

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

Функциональные требования

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

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

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

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

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

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

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

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

    В следующих статьях описаны конкретные аспекты.

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

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

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

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

    Другим примером является реализация RAG. Общий этап обработки — это блокирование, в котором документ делится на несколько блоков, и каждая блок-часть становится строкой в индексе. Он также сохраняет внедрения, которые служба OpenAI часто создает для этих блоков. В поисках искусственного интеллекта этот процесс управляется в рабочем процессе индексирования, независимо от того, используется ли OpenAI или Поиск ИИ Azure.

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

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

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

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

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

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

Нефункциональные требования

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

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

    Для этапов приема и обработки рассмотрите масштабируемость и скорость платформы для обработки задач. Например, вы ожидаете загрузить 10 терабайт данных ежедневно в индекс или для обучения модели. Платформа приема данных должна иметь возможность обрабатывать столько томов и с ожидаемой пропускной способностью. В этом случае использование Azure Logic Apps может оказаться невозможным, так как оно может завершиться сбоем в такой нагрузке. Вместо этого фабрика данных лучше подходит для этого масштаба обработки данных.

    Одним из способов обработки большого объема является параллелизм, так как он обеспечивает более эффективную обработку и обработку данных. Такие платформы, как Azure Databricks, могут управлять задачами, создавая несколько экземпляров для одного задания и эффективно распределяя нагрузку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функциональные требования

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

    Запросы, получаемые системой, по сути, являются поиском, и индекс должен поддерживать широкие возможности поиска. Для RAG поиск векторов не является неизменяемым, так как данные хранятся в виде вычисляемых векторов или внедрения, которые используются для поиска.

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

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

  • Поддерживает ли индекс многомодальные данные?

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

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

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

Нефункциональные требования

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Выполняют ли функции безопасности индекса, которые соответствуют проектированию данных безопасности?

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

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

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

Рекомендации по хранилищу компонентов

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

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

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

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

Рекомендации по автономному выводу хранилища данных

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

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

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

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

Ресурсы

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

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

Область разработки: MLOps и GenAIOps