Compartilhar via


Plataforma de dados para cargas de trabalho de IA no Azure

Escolher uma plataforma de dados envolve entender os desafios de dados exclusivos que essas soluções trazem. As soluções genai, especialmente aquelas criadas com modelos de base, dependem de dados diversos e de alta qualidade, acesso rápido a armazenamentos de dados escalonáveis que dão suporte à pesquisa de vetores. A meta é atender a essas necessidades sem adicionar complexidade desnecessária à sua arquitetura. Entender os princípios do design efetivo do pipeline de dados é essencial antes de avaliar as opções da plataforma.

Ao avaliar as opções de plataforma, comece perguntando se você realmente precisa de componentes adicionais. Arquiteturas mais simples geralmente são mais rápidas de implantar, mais fáceis de gerenciar e mais econômicas. Pergunte a si mesmo:

  • O modelo pode alcançar seu desempenho esperado usando dados de uma única fonte?
  • O armazenamento de dados de origem já fornece os recursos de análise ou pesquisa de que você precisa?
  • Os dados de origem já estão estruturados e indexados para AI ou pesquisa de vetor?

Se a resposta for sim para a maioria dessas perguntas, uma arquitetura complexa pode não ser necessária. Por exemplo, bancos de dados como o Azure Cosmos DB e o Banco de Dados SQL do Azure já dão suporte a tipos de dados de vetor e pesquisa de vetor nativamente, mas precisam ser habilitados e configurados. Esses recursos podem reduzir a necessidade de indexação separada ou bancos de dados de vetor especializados, minimizando a movimentação de dados e melhorando o desempenho.

À medida que sua carga de trabalho cresce e os dados vêm de várias fontes, a decisão da plataforma se torna mais complexa. Talvez seja necessário considerar soluções que dão suporte a pipelines ETL ou ELT, índices de pesquisa especializados e armazenamento escalonável para grandes conjuntos de dados. Cada funcionalidade adicionada deve servir a uma finalidade clara em vez de simplesmente expandir a pilha de tecnologia.

Este artigo fornece diretrizes sobre como escolher uma plataforma de dados para cargas de trabalho em que os dados precisam ser armazenados, processados ou analisados. O foco é em soluções que dão suporte à GENAI (IA generativa). É altamente recomendável que você entenda os princípios de um bom design de pipeline de dados antes de explorar os recursos tecnológicos descritos neste artigo. Para obter mais informações, consulte Design Fundamental de Dados.

Para obter recomendações específicas para treinamento de modelo discriminativo e ajuste fino, consulte considerações sobre a plataforma de dados de treinamento.

Considerações sobre a plataforma de armazenamento de dados

Em cargas de trabalho de IA, os dados geralmente passam por vários estágios de armazenamento e processamento, guiados por pipelines que conectam cada etapa. Um estágio importante é o armazenamento de dados que contém informações coletadas e combinadas de várias fontes. Esse repositório permite processar e refinar os dados até que estejam prontos para o próximo estágio.

Observação

Talvez você não precise desse componente em sua arquitetura. Em alguns casos, você pode acessar dados diretamente dos sistemas de origem. No entanto, isso pode levar a problemas de desempenho e pode sobrecarregar esses sistemas com consultas de IA. Também pode causar desafios de acesso ou confiabilidade. Para evitar esses problemas, geralmente é melhor copiar os dados para um repositório dedicado para agregação e processamento.

Ao escolher uma plataforma para este repositório, verifique se ela segue os mesmos padrões de segurança que seus sistemas de origem, é econômica e funciona bem com tarefas de processamento ETL, ELT ou EL. Suas opções podem variar de soluções de armazenamento simples a plataformas de dados em grande escala, dependendo das suas necessidades de volume de dados e desempenho. Procure uma opção de armazenamento confiável, escalonável e que forneça um bom valor para sua carga de trabalho.

Aqui estão algumas perguntas para ajudar a orientar sua escolha de tecnologia de armazenamento de dados.

A plataforma pode lidar com diferentes formatos de dados?

Seu armazenamento de dados deve ser capaz de armazenar uma variedade de formatos de dados e, quando necessário, converter dados entre eles.

Por exemplo, se o pipeline de ingestão trouxer dados de um banco de dados relacional e de um arquivo JSON, ele deverá dar suporte a dados estruturados e semiestruturados. Talvez você queira converter seus dados no formato Delta para habilitar a funcionalidade mais avançada que a tecnologia Delta Lake fornece. A plataforma deve fornecer ferramentas internas para esse tipo de transformação para que você não precise escrever código personalizado.

Você espera armazenar várias versões dos dados?

Os dados mudam ao longo do tempo, tanto nos valores como na estrutura, e os sistemas de origem geralmente armazenam apenas o estado atual. Se você precisar de contexto histórico, escolha uma plataforma de dados que dê suporte ao controle de versão. Sem ele, talvez seja necessário duplicar conjuntos de dados, o que adiciona complexidade.

O controle de versão tem outros benefícios. Em alguns casos, talvez você precise de cópias separadas de dados para diferentes casos de uso. Cada cópia pode evoluir de forma independente e a plataforma deve gerenciar o controle de versão em todas as cópias para preservar o contexto para seus modelos de IA.

A plataforma tem funcionalidades internas de gerenciamento de ciclo de vida de dados?

O DLM (gerenciamento de ciclo de vida de dados) ajuda a controlar o crescimento da criação à exclusão. Sua plataforma deve remover automaticamente cópias intermediárias, gerenciar dados arquivados e dar suporte à retenção regulatória quando necessário. Sem isso, os dados podem crescer incontrolavelmente e esse volume desnecessário pode dificultar o processamento. Por exemplo, talvez seja necessário executar novamente as etapas de pré-processamento várias vezes para melhorar a qualidade dos dados. A plataforma deve remover automaticamente cópias intermediárias quando elas não forem mais necessárias.

Em outros casos, talvez seja necessário reter dados para conformidade ou auditorias. Procure opções de armazenamento que dão suporte a camadas frias ou arquivadas para dados raramente acessados a um custo menor.

A plataforma dá suporte a recursos de governança de dados?

A auditabilidade é um aspecto importante para cargas de trabalho de IA. Sua plataforma deve manter trilhas de auditoria para acompanhar o acesso aos dados, garantir a privacidade e documentar as origens dos dados. Ele também deve dar suporte a um dicionário ou catálogo de dados que gerencia metadados, tipos de dados, finalidade e linhagem, especialmente quando os dados são provenientes de várias fontes.

Quantos dados você espera armazenar?

As cargas de trabalho de IA geram grandes volumes de dados, que podem crescer ainda mais com várias versões e metadados extras. Sua plataforma de dados deve ser dimensionada com eficiência para armazenamento e taxa de transferência, manipulando altas taxas de ingestão, gravações simultâneas e processamento intensivo sem degradação de desempenho.

Ao escolher uma plataforma, considere todo o fluxo de trabalho, pois a ingestão e o processamento geralmente ocorrem ao mesmo tempo. O sistema deve dar suporte ao processamento paralelo e à movimentação frequente de dados e fornecer telemetria para fornecer informações claras sobre o desempenho de leitura e gravação.

Esse armazenamento de dados é fundamental para a confiabilidade da carga de trabalho?

Escolha uma plataforma que dê suporte à confiabilidade e escalabilidade por meio de replicação ou várias instâncias. Muitos armazenamentos de Big Data usam controladores que distribuem o processamento automaticamente e fornecem failover quando uma instância fica indisponível.

Os dados também precisam ser duráveis e acessíveis. Verifique se a plataforma garante a integridade dos dados, fornece APIs acessíveis e dá suporte a recursos de backup ou restauração se a recompilação de dados do zero for dispendiosa.

Você tem restrições de custo?

Depois que os requisitos de confiabilidade e desempenho forem atendidos, considere como otimizar os custos. Para muitas cargas de trabalho de IA, um modelo de gravação única e leitura múltipla é suficiente e ajuda a controlar as despesas. Os dados de aterramento devem ser econômicos para armazenar e recuperar, mesmo que não exijam o mesmo nível de capacidade de resposta que um banco de dados de produção. A meta é equilibrar o custo, a eficiência e o desempenho.

Você precisa dar suporte à soberania de dados ou aos requisitos de conformidade regional?

Para cargas de trabalho que lidam com dados regulamentados ou confidenciais, considere a implantação em uma nuvem soberana, como o Azure Governamental, o Microsoft Azure operado pela 21Vianet ou outras Nuvens de Parceiros Nacionais. Esses ambientes são projetados para atender aos requisitos estritos de residência, privacidade e conformidade de dados, garantindo que o armazenamento, o processamento e o acesso de dados permaneçam dentro de jurisdições específicas.

Nuvens soberanas fornecem maior controle e independência sobre seus dados, o que geralmente é um requisito para setores como governo, defesa ou bancos. No entanto, tenha em mente que alguns recursos avançados de IA e plataforma de dados ainda podem não estar disponíveis nessas regiões. Examine a disponibilidade do serviço antes de projetar sua arquitetura.

Use o Microsoft Purview para manter o controle de catalogação, classificação e linhagem de dados entre esses ambientes. Para cargas de trabalho altamente confidenciais, considere o uso de computação confidencial e chaves gerenciadas pelo cliente para fortalecer a proteção de dados. Você deve verificar se sua implantação está alinhada com as regulamentações regionais.

Opções de tecnologia

Função Tecnologias recomendadas Alternativas/Ferramentas Complementares
Armazenamento de dados de vários formatos Azure Data Lake Storage Gen2, Microsoft Fabric Lakehouse, Azure Databricks Lakehouse Armazenamento de Blobs do Azure, Azure Synapse Analytics, data warehouse local
Controle de versão e linhagem de dados Microsoft Fabric Lakehouse, Azure Data Lake Storage Gen2 (com Delta Lake), Azure Databricks (Delta Lake) Git LFS, DVC (controle de versão de dados), Apache Iceberg
DLM (gerenciamento de ciclo de vida de dados) Azure Data Lake Storage Gen2 (políticas de ciclo de vida), Azure Blob Storage (camadas), Azure Databricks (otimização de tabelas) Amazon S3 (políticas de ciclo de vida), Google Cloud Storage
Governança e catalogação de dados Microsoft Purview, Azure Databricks Unity Catalog Apache Atlas, DataHub, Collibra
Armazenamento de dados de alto volume Azure Data Lake Storage Gen2, Azure Synapse Analytics, Azure Databricks Lakehouse Armazenamento de Blobs do Azure, HDFS do Hadoop, Amazon S3

Considerações sobre a plataforma de processamento de dados

A plataforma de processamento de dados desempenha um papel fundamental na preparação e transformação de dados para que ela esteja pronta para uso downstream, seja indexação, análise ou outro caso de uso do RAG.

Observação

Para o "GenAI" (Inteligência Artificial Generativa) e o RAG (geração aumentada por recuperação), é útil entender a diferença entre os processos ETL, ELT e EL.

  • ETL: Extraia, transforme e carregue, normalmente para data warehousing tradicional.
  • ELT: Extraia, carregue e transforme, comum para data lakes e ferramentas de Big Data, como o PySpark.
  • EL: Extração e carregamento, usado em cenários RAG onde os documentos são armazenados inicialmente e, em seguida, são realizadas transformações como segmento de texto ou extração de imagem posteriormente.

Há dois locais em que o processamento pode acontecer:

  • Camada de ingestão. O fluxo de ingestão coleta dados de várias fontes e os move para o armazenamento de dados agregados. Ao longo do caminho, ele geralmente executa pré-processamento básico ou formatação para que os dados sejam consultáveis. Para reduzir a necessidade de código personalizado, é melhor usar uma plataforma de dados que lida com o máximo possível disso. Ao avaliar as ferramentas, considere os recursos ETL ou ELT necessários para dar suporte às cargas de trabalho de IA, como aumento de dados.

  • Camada de processamento. Depois que os dados chegam ao repositório de agregação, normalmente, ele precisa de processamento mais profundo antes de estar pronto para indexação ou uso em modelos de IA. Esses pipelines devem oferecer níveis semelhantes de confiabilidade e escalabilidade como a camada de ingestão, mas o foco muda para transformar e remodelar os dados.

As tarefas típicas incluem:

  • Reconhecimento e enriquecimento de entidade
  • Integrando fontes de dados adicionais
  • Executando pesquisas e transformações
  • Limpar ou excluir dados irrelevantes

Uma plataforma de dados forte ajuda a automatizar e orquestrar essas operações com eficiência.

Qual é o suporte para se conectar a fontes de dados?

A plataforma deve se conectar facilmente às fontes de dados das quais você espera ingestão, sejam bancos de dados relacionais, fontes de Big Data ou armazenamento de blobs.

Procure conectores predefinidos e integrações de baixo código. Idealmente, você deseja conectores baseados em configuração ou arrastar e soltar que dão suporte a pesquisas, cópia de dados e governança.

A plataforma pode processar vários formatos de dados?

Os dados vêm em muitas formas: estruturados (SQL, tabelas relacionais), semiestruturados (JSON, XML, Parquet) e não estruturados (documentos, imagens) e streaming (dados IoT). Escolha uma plataforma que possa lidar com os formatos que seu caso de uso requer considerando requisitos imediatos e de longo prazo.

A plataforma oferece recursos para preparação e redimensão de dados?

Antes que seus dados estejam prontos para indexação ou consumo de modelo, eles precisam ser limpos, enriquecidos e remodelados. Suas estratégias de design de dados devem descrever explicitamente os requisitos. Uma boa plataforma deve:

  • Remover duplicatas e preencher os valores faltantes
  • Manipular tarefas de stemming, normalização e outras tarefas de limpeza básica ao planejar dar suporte à pesquisa por palavra-chave ou híbrida (palavra-chave+vetor).
  • Suporte a transformações avançadas, como agrupamento, enriquecimento e análise de documentos

Se o armazenamento de dados oferecer suporte a essas operações nativamente, você poderá processar dados no local sem movê-los. Caso contrário, use ferramentas externas como o Azure Databricks ou o Azure Data Factory para transformações pesadas.

Em alguns casos, você pode optar por externalizar parte dessa responsabilidade para a plataforma que dá suporte ao próximo estágio. Um exemplo comum dessa abordagem é a implementação de RAG. Durante o processamento, os documentos são divididos em partes menores, com cada parte armazenada como uma linha separada no índice. Essas partes são então emparelhadas com inserções, muitas vezes geradas por meio de um serviço OpenAI. No Azure AI Search, esse processo é orquestrado como parte do pipeline de enriquecimento durante a indexação, em que os documentos são processados por um modelo de inserção (como um modelo de inserção OpenAI) para gerar representações de vetor armazenadas no índice.

Há um orquestrador interno para gerenciar fluxos de trabalho?

Normalmente, o processamento de dados ocorre como trabalhos modulares que precisam de coordenação complexa. Sua plataforma deve incluir um orquestrador para definir, agendar e monitorar esses fluxos de trabalho. Procurar por:

  • Suporte para dependências de tarefas e verificações que confirmam a sequência de execução
  • Modificação flexível de fluxos de trabalho que permite ajustes fáceis sem reescrever grandes partes do código.
  • Funcionalidades de monitoramento e registro em log

As ferramentas populares incluem o Azure Data Factory para seu conjunto de recursos avançado para gerenciamento de fluxo de trabalho ou o Azure Databricks para orquestração mais complexa. Se o custo for uma preocupação, o Apache NiFi ou o Airflow poderão ser alternativas mais econômicas.

Quantos dados você espera ingerir?

Estima a quantidade de dados que você ingerirá e a frequência de ingestão. Por exemplo, se você espera carregar 10 terabytes de dados diariamente em um índice, a plataforma deverá dar suporte à paralelização forte e à execução distribuída. Para cargas de trabalho menores, ferramentas mais simples como Aplicativos Lógicos podem funcionar, mas para volumes mais altos, o Data Factory ou o Databricks são mais adequados. Para escalabilidade e taxa de transferência, considere:

  • Volume e frequência de dados
  • Requisitos de latência toleráveis
  • Complexidade do trabalho

Por exemplo, a limpeza de dados envolve validar e potencialmente substituir campos inválidos ou mascarar informações confidenciais. Essas tarefas, embora básicas, exigem recursos significativos porque cada linha é processada individualmente, o que aumenta o tempo total.

Quais recursos de monitoramento você precisa?

Os pipelines de processamento de dados devem ter recursos de monitoramento e fornecer insights sobre o desempenho e o status dos trabalhos do pipeline. Sua plataforma deve fornecer:

  • Acompanhamento do progresso do trabalho
  • Logs, métricas e alertas para compreender o comportamento do pipeline
  • Integração com o seu stack de monitoramento mais amplo

Identifique quaisquer lacunas na telemetria interna e determine qual monitoramento adicional você precisa implementar. Esse monitoramento pode envolver a adição de log ou métricas personalizadas para capturar detalhes específicos sobre as etapas do trabalho.

Quanta confiabilidade você espera da plataforma de processamento de dados?

Escolha uma plataforma que minimize pontos únicos de falha e dê suporte a novas tentativas para tarefas com falha. Por exemplo, hospedar a lógica de processamento personalizada invocada do Data Factory no AKS (Serviço de Kubernetes do Azure) normalmente oferece confiabilidade mais forte do que hospedá-la nos Aplicativos Lógicos do Azure.

Se os seus dados forem atualizados com pouca frequência e você realizar o processamento através de processamento em lote semanal, falhas ocasionais podem ser aceitáveis. Mas, para cenários de IA em tempo real, você precisará de maior confiabilidade.

Há restrições de custo?

O objetivo é evitar o excesso de engenharia e escolher uma plataforma que atenda às suas necessidades hoje, deixando espaço para dimensionamento. Por exemplo, se você não precisar dos recursos avançados do Databricks, o Data Factory poderá oferecer uma opção mais acessível. Ferramentas de software livre, como Airflow ou NiFi, podem reduzir ainda mais os custos.

Quais são os requisitos de segurança nos fluxos de trabalho e nos dados que você processa?

Os requisitos de segurança, privacidade e residência de dados devem orientar sua escolha. Idealmente, a plataforma deve fornecer suporte integrado para esse isolamento que permita um gerenciamento de dados eficiente e seguro. No mínimo, certifique-se de que a plataforma:

  • Atende às leis de residência de dados regionais. Talvez seja necessário executar pipelines separados para diferentes regiões, como um para a Europa e outro para a América, para atender aos regulamentos de conformidade locais.
  • Dá suporte ao IAM (gerenciamento de identidade e acesso) para garantir que apenas as identidades autorizadas tenham acesso a trabalhos ou etapas específicas nos fluxos de trabalho.
  • Permite o controle de acesso refinado no fluxo de trabalho ou no nível da etapa.

Opções de tecnologia

Função Tecnologias recomendadas Alternativas/Ferramentas Complementares
Limpeza de dados Azure Data Factory, Azure Databricks, Microsoft Fabric Dataflows Apache NiFi, Apache Airflow
Transformação de dados Azure Databricks, Azure Synapse Analytics, Engenharia de Dados do Microsoft Fabric Azure Data Factory Pipelines (Linhas de Processos)
Enriquecimento de dados Inteligência de Documentos de IA do Azure, Serviço OpenAI do Azure, Pesquisa de IA do Azure APIs personalizadas do Python ou serviços de IA de terceiros
Orquestração de fluxo de trabalho Pipelines do Azure Data Factory, Tarefas do Databricks Apache Airflow, Apache NiFi
Fluxos de trabalho RAG Serviço Azure OpenAI, Azure AI Search, Azure Databricks Ciência de dados do Microsoft Fabric

Considerações para um índice de pesquisa

Um índice de pesquisa armazena os dados contextuais ou de fundamentação enviados, junto com o prompt, para o ponto de extremidade de inferência de um modelo. As consultas de índice são um componente crítico na preparação dos dados enviados para o modelo nas solicitações de inferência e devem fornecer desempenho de baixa latência.

Ao contrário dos pipelines de ETL orientados em lote, esse índice deve dar suporte à inferência em tempo real, o que significa que o alto desempenho e a confiabilidade não são negociáveis. Ele é criado para cargas de trabalho de IA e dá suporte a recursos como indexação de palavra-chave, filtragem e pesquisa baseada em vetor, que vão além do que os armazenamentos de dados tradicionais fornecem.

O design ideal é um armazenamento de dados de alto desempenho, otimizado para leituras, que pode lidar com consultas imprecisas ou difusas enquanto ainda retorna resultados relevantes. Escolha a tecnologia de índice que tem esses pontos em mente.

Quais tipos de pesquisa o índice de pesquisa dá suporte?

Cada solicitação para o sistema pode resultar em uma ou mais consultas para o índice. Para RAG (geração aumentada de recuperação) e outras cargas de trabalho controladas por IA, a pesquisa de vetor é necessária. A pesquisa de vetor permite que o sistema localize pontos de dados semanticamente semelhantes usando inserções em vez de correspondências exatas de palavra-chave.

No entanto, combinar a pesquisa de vetor com a pesquisa de texto completo, filtragem e tipos de dados especiais (como localização geográfica) torna o índice muito mais poderoso.

Seu design de dados deve especificar claramente quais tipos de pesquisa são necessários e como eles devem trabalhar juntos. Para obter mais informações, consulte Consulta eficiente no design de dados.

Como o índice lida com dados multimodal?

As cargas de trabalho de IA geralmente lidam com dados que incluem não apenas texto, mas também imagens, áudio ou vídeo. O índice em si não consegue entender diretamente as imagens. Portanto, antes de adicionar imagens ao índice, elas precisam ser convertidas em uma representação baseada em texto (usando OCR ou legenda de imagem), da qual as inserções são geradas ou as inserções de vetor podem ser geradas diretamente da imagem usando modelos de visão. Em seguida, o índice pode executar a pesquisa de vetor, permitindo consultas semânticas.

Nesse caso de uso, o índice de pesquisa deve ter:

  • Suporte à pesquisa de vetor para armazenar e consultar inserções (vetores numéricos) derivados da imagem.
  • Integração com APIs externas e serviços de IA para extrair ou enriquecer dados durante o processo de indexação.
  • Capacidade de armazenar campos extraídos (texto, marcas, legendas, inserções) em campos de esquema apropriados como metadados para pesquisa e filtragem.

O índice dá suporte a recursos de atualização automática quando os dados nas fontes de dados são alterados?

A automação é fundamental para manter a atualização de dados. Selecione um índice que dê suporte a atualizações automáticas ou atualizações incrementais quando os dados subjacentes forem alterados.

Se a plataforma não oferecer isso nativamente, você precisará implementar um processo personalizado para detectar e enviar atualizações por push. Descarregar essa responsabilidade para a plataforma pode reduzir a sobrecarga operacional e simplificar a manutenção, especialmente à medida que os volumes de dados aumentam.

O índice pode ser executado com grandes volumes de dados?

O índice deve ser dimensionado com eficiência à medida que o volume de dados aumenta. Para cargas de trabalho que implementam o RAG, cada documento geralmente é dividido em várias partes, o que aumenta significativamente a quantidade de dados armazenados.

Sua plataforma escolhida deve ser capaz de:

  • Escalar horizontalmente à medida que os dados crescem
  • Manter o desempenho da consulta sob alta carga
  • Armazenar tanto dados brutos quanto metadados relacionados, enriquecimentos e entidades

O índice tem recursos internos de confiabilidade?

A confiabilidade do índice de pesquisa deve refletir a do endpoint de inferência, pois ambos fazem parte do mesmo caminho de processamento em tempo real.

Cada etapa deve atender a expectativas semelhantes de disponibilidade e desempenho. Para fazer isso, ao escolher a plataforma de dados, procure:

  • Recursos de alta disponibilidade e redundância de zona para sobreviver a interrupções zonais e regionais.
  • Recuperação automática e fácil recompilação de índice para impedir o uso de um índice corrompido para inferência.
  • Capacidades de aliasing e troca de índices para habilitar atualizações sem tempo de inatividade.

Além disso, entenda os modos de falha do sistema ou indicadores de estresse, como estrangulamento. Por exemplo, durante a reindexação em segundo plano, a taxa de transferência pode cair. O sistema normalmente pode lidar com 50 usuários simultâneos, mas apenas 30 durante esse trabalho. Planeje o tempo de trabalho e a capacidade adequadamente, contabilizando consultas front-end e tarefas de manutenção de back-end.

Quais são os principais fatores de custo dessa tecnologia?

Os custos de índice de pesquisa normalmente são baseados em uso, portanto, é importante modelar o volume de dados esperado, a taxa de consulta e a taxa de transferência.

A maioria das plataformas de índice, como o Azure AI Search, são ofertas de PaaS (Plataforma como Serviço), em que os preços são abstraídos e apresentados em unidades de capacidade, armazenamento e uso de recursos.

Lembre-se de:

  • Preço de camada e limites de dimensionamento
  • Custos extras de recursos avançados (por exemplo, extração de imagem ou enriquecimento do conjunto de habilidades)
  • Capacidade não utilizada em camadas superprovisionadas
  • Complexidade do índice (número de índices e limites de consulta simultâneos)

Para entender os custos associados ao AI Search, consulte Planejar e gerenciar os custos de um serviço do AI Search.

Os recursos de segurança do índice satisfazem o seu design de dados de segurança?

Seu design de dados deve especificar claramente os requisitos de segurança e privacidade, e seu índice deve dar suporte total a eles. Ao trabalhar em ambientes de desenvolvimento ou teste que usam dados reais, verifique se o índice está em conformidade com as políticas de controle de acesso e rastreabilidade. Procure recursos como:

  • Mascaramento de dados e remoção de PII
  • Gerenciamento de identidade do cliente por meio da ID do Microsoft Entra
  • Controles de acesso no nível do documento para filtrar resultados com base na identidade do usuário

Se a plataforma não der suporte nativo a elas, considere implementar filtros no nível da consulta como um fallback. Para obter mais informações, consulte Filtros de segurança para cortar resultados no AI Search.

Do ponto de vista de segurança de rede, o índice deve:

  • Suporte ao controle de saída e à segmentação de rede
  • Integrar com redes privadas quando a computação for executada em uma rede virtual
  • Usar identidades gerenciadas para autenticação por meio da ID do Microsoft Entra
  • Evite expor componentes diretamente à Internet pública

As inserções ainda poderão expor informações confidenciais se não estiverem protegidas corretamente. Os riscos incluem inversão de inserção (reconstrução de texto original de vetores), envenenamento de dados (inserção de vetores mal-intencionados) e acesso não autorizado a repositórios de inserção ou backups. Para atenuar esses riscos, aplique medidas de segurança como:

  • Criptografia em repouso e em trânsito
  • Controles de acesso estritos
  • Conectividade de rede privada discutida acima
  • Monitorar os endpoints de incorporação para anomalias ou adulterações

Semelhante a outros tipos de dados, tenha processos para remover dados confidenciais ou pessoais. Trate os índices de vetor como armazenamentos de dados confidenciais que exigem o mesmo nível de segurança e governança que outros sistemas de produção.

Opções de tecnologia

Função Tecnologias recomendadas Alternativas/Ferramentas Complementares
Pesquisa de vetor e pesquisa semântica Azure AI Search, Azure Cosmos DB (pesquisa de vetor), Banco de Dados do Azure para PostgreSQL (pgvector) Pinecone, Weaviate, Chroma, Qdrant
Pesquisa de texto completo e indexação de palavra-chave Pesquisa de IA do Azure  Elasticsearch, Apache Solr, Pesquisa de Texto Completo no Banco de Dados SQL do Azure
Processamento de dados multimodal Azure AI Search (com conjuntos de habilidades), Azure AI Document Intelligence, Azure AI Vision Processamento personalizado com APIs OpenAI, Amazon Textract
Atualização e indexação automáticas de dados Azure AI Search (com indexadores), gatilhos do Azure Data Factory Soluções de sondagem personalizadas, Apache NiFi, captura de dados alterados
Alta disponibilidade e confiabilidade Azure AI Search (redundância de zona), Azure Cosmos DB (distribuição global) Implantações de várias regiões, balanceadores de carga, Gerenciador de Tráfego do Azure
Aliás de índice e atualizações sem interrupção Azure AI Search (aliases de índice), Azure Cosmos DB Padrões de implantação azul-verde, lógica de roteamento personalizado
Segurança em nível de documento e controle de acesso Azure AI Search (filtros de segurança), integração da ID do Microsoft Entra Camadas de autorização personalizadas, segurança em nível de linha em bancos de dados
Segurança de rede e acesso privado Link Privado do Azure, integração de Rede Virtual, Identidades Gerenciadas Gateways de VPN, Firewall do Azure, grupos de segurança de rede personalizados

Considerações sobre treinamento e ajuste fino

Ao projetar sua plataforma de dados para cargas de trabalho tradicionais de ML (machine learning) ou não GenAI, seu foco muda da inferência em tempo real para a qualidade dos dados, a reprodutibilidade e a separação do ambiente. Essas cargas de trabalho dependem de dados agregados bem estruturados e geralmente envolvem camadas adicionais, como repositórios de recursos e armazenamentos de dados de inferência em lotes, para otimizar o desempenho do modelo e a eficiência de custo.

É altamente recomendável que você entenda os princípios de um bom design de pipeline de dados antes de explorar os recursos tecnológicos descritos neste artigo. Para obter mais informações, consulte o design de dados de treinamento.

Você planeja realizar treinamento com dados de produção?

Como você implanta seus modelos determina como os dados de produção estão firmemente associados ao seu ambiente de desenvolvimento. Há duas abordagens de implantação principais:

  • Implantação de modelo. O modelo é treinado ou ajustado usando dados de produção durante o desenvolvimento. Essa abordagem pode melhorar a relevância do modelo, mas exige controles de segurança fortes, já que dados confidenciais estão sendo usados fora da produção.

  • Implantação de código. O modelo é treinado usando dados de não produção em desenvolvimento e só interage com dados reais depois de implantado em produção. Esse método simplifica a segurança de desenvolvimento, mas pode aumentar os custos de computação e armazenamento, pois o treinamento pode precisar ser repetido em vários ambientes.

Independentemente da abordagem, sua plataforma de dados deve separar claramente os ambientes de desenvolvimento e produção, garantindo o isolamento e o controle de acesso adequados.

Você está priorizando a conveniência em relação à funcionalidade?

Ao escolher uma plataforma de dados para ML, não tome a decisão com base apenas no suporte do notebook.

Os notebooks são ótimos para análise de dados exploratórios, mas não são um fator decisivo para selecionar uma plataforma de dados de nível de produção. Os recursos de computação do notebook geralmente ficam fora do repositório de dados de agregação e são integrados a ferramentas externas, como o Azure Machine Learning ou os Workspaces do Databricks.

Priorizar recursos principais, como controle de versão de dados, governança, escalabilidade e segurança, em vez de recursos de conveniência.

Como você processará e preparará seus dados?

Nas cargas de trabalho de ML, o padrão de processamento de dados escolhido tem um grande impacto na flexibilidade e no desempenho.

  • ETL (Extrair, Transformar, Carregar) – comum no data warehousing tradicional, em que as restrições de esquema exigem que você transforme dados antes de carregá-los no sistema de destino.
  • ELT (Extrair, Carregar, Transformar) – típico para data lakes ou arquitetura lakehouse, em que os dados brutos são carregados primeiro e depois transformados usando ferramentas como Python ou PySpark.
  • EL (Extrair, Carregar) – comum em padrões GenAI e RAG, em que você armazena documentos ou mídia primeiro e executa transformações downstream (como agrupamento de texto ou extração de imagem) mais tarde.

O ELT geralmente é preferencial, pois preserva dados brutos e permite transformações mais flexíveis durante a preparação do modelo.

Você precisa de um repositório de recursos?

Geralmente, é benéfico introduzir um repositório de recursos como uma camada de dados intermediária entre o armazenamento de dados agregado e o ambiente de treinamento.

Um repositório de recursos atua como um catálogo de recursos coletados, completo com metadados, como linhagem de recursos, tempo de geração e origem. É o lugar perfeito para manter dados de treinamento "dourados" que podem ser reutilizados em vários modelos ou experimentos.

Repositórios de recursos gerenciados, como o do Azure Machine Learning, integram-se diretamente ao MLflow e a outras ferramentas de ciclo de vida de ML. Elas habilitam a reprodutibilidade, a governança e o controle de versão para seus recursos.

Trate o repositório de recursos como um repositório de dados confidenciais por conta própria com controles de acesso, criptografia e auditoria adequados.

Você deve considerar o uso de um armazenamento de dados para inferência em lote?

Em alguns casos, você pode melhorar o desempenho e reduzir custos executando inferências em lote, ou seja, pré-computando resultados de inferência e armazenando-os para uso posterior em vez de chamar o modelo em tempo real.

Essa abordagem pode ser altamente eficaz quando as mesmas consultas ou previsões são solicitadas repetidamente (por exemplo, gerando perguntas frequentes ou recomendações padrão).

Entre os principais benefícios estão:

  • Latência reduzida e melhor experiência do usuário, os resultados são atendidos instantaneamente.
  • Escalabilidade mais fácil porque a inferência pode ser processada em lotes e distribuída offline.
  • Confiabilidade aprimorada que evita colocar a carga em tempo real no endpoint de inferência.
  • Custos de computação mais baixos resultantes do processamento em lote podem utilizar hardware de nível mais baixo.
  • Pré-validação interna em que os resultados podem ser verificados quanto à precisão antes de serem expostos aos usuários.

No entanto, essa abordagem funciona melhor quando um percentual significativo de previsões é reutilizado. Se sua carga de trabalho envolve principalmente consultas exclusivas, manter um repositório de inferência em lote pode não valer a complexidade.

O armazenamento de dados de inferência em lote deve ser otimizado para operações de leitura, escalonável o suficiente para lidar com grandes conjuntos de dados e integrado ao armazenamento de dados agregado.

As tecnologias que se encaixam nesse padrão incluem o Azure Cosmos DB para acesso rápido, distribuído globalmente, ou o Armazenamento de Tabelas do Azure para cargas de trabalho de leitura pesadas, mais simples e de baixo custo.

Opções de tecnologia

Função Tecnologias recomendadas Alternativas/ferramentas complementares
Armazenamento de dados agregado Azure Data Lake Storage Gen2, Microsoft Fabric Lakehouse, Azure Synapse Analytics Armazenamento de Blobs do Azure, Banco de Dados SQL, data warehouse local
Processamento e transformação de dados (ETL/ELT) Azure Data Factory, Azure Databricks (PySpark, SQL), Engenharia de Dados do Microsoft Fabric Apache Airflow, Apache NiFi, Synapse Pipelines
Ambiente de desenvolvimento e treinamento Azure Machine Learning (com integração do MLflow), Workspaces do Azure Databricks JupyterHub, Kubeflow, Amazon SageMaker
Repositório de recursos Repositório de Recursos do Azure Machine Learning, Repositório de Recursos do Databricks Festa (software livre), Tecton
Inferência em lote Azure Cosmos DB, Armazenamento de Tabelas do Azure Banco de Dados SQL do Azure, PostgreSQL, Cache Redis
Registro de modelo e acompanhamento de experimentos MLflow (integrado ao Azure Machine Learning ou ao Databricks) Weights & Biases, Neptune.ai, DVC
Orquestração e automação Pipelines de Azure Data Factory, Pipelines de Azure Machine Learning Fluxo de ar do Apache, Prefeito
Segurança e controle de acesso Microsoft Entra ID (Azure AD), Azure Key Vault, Identidades Gerenciadas HashiCorp Vault, AWS IAM

Próximas etapas