Hoje em dia, a maioria dos nossos clientes está entusiasmada com os grandes modelos de linguagem (LLMs) e pensando em como a IA generativa poderia transformar seus negócios. No entanto, trazer tais soluções e modelos para as operações normais não é uma tarefa fácil. Nesta postagem, discutimos como operacionalizar aplicativos generativos de IA usando princípios de MLOps que levam a operações de modelo básico (FMOps). Além disso, nos aprofundamos no caso de uso de IA generativa mais comum de aplicativos de texto para texto e operações LLM (LLMOps), um subconjunto de FMOps. A figura a seguir ilustra os tópicos que discutimos.
Especificamente, apresentamos brevemente os princípios de MLOps e focamos nos principais diferenciais em comparação com FMOps e LLMOps em relação a processos, pessoas, seleção e avaliação de modelos, privacidade de dados e implantação de modelos. Isso se aplica a clientes que os utilizam imediatamente, criam modelos básicos do zero ou os ajustam. Nossa abordagem se aplica igualmente a modelos de código aberto e proprietários.
Resumo de operacionalização de ML
Conforme definido na postagem Roteiro básico de MLOps para empresas com o Amazon SageMaker, ML e operações (MLOps) é a combinação de pessoas, processos e tecnologia para produzir soluções de aprendizado de máquina (ML) com eficiência. Para conseguir isso, uma combinação de equipes e personas precisa colaborar, conforme ilustrado na figura a seguir.
Essas equipes são as seguintes:
- Equipe de análise avançada (data lake e data mesh) – Os engenheiros de dados são responsáveis por preparar e ingerir dados de diversas fontes, construir pipelines de ETL (extrair, transformar e carregar) para selecionar e catalogar os dados e preparar os dados históricos necessários para os casos de uso de ML. Esses proprietários de dados estão focados em fornecer acesso aos seus dados a diversas unidades de negócios ou equipes.
- Equipe de ciência de dados – Os cientistas de dados precisam se concentrar na criação do melhor modelo com base em indicadores-chave de desempenho (KPIs) predefinidos que funcionam em notebooks. Após a conclusão da fase de pesquisa, os cientistas de dados precisam colaborar com engenheiros de ML para criar automações para construção (pipelines de ML) e implantação de modelos em produção usando pipelines de CI/CD.
- Equipe de negócios – O proprietário do produto é responsável por definir o caso de negócios, os requisitos e os KPIs a serem usados para avaliar o desempenho do modelo. Os consumidores de ML são outras partes interessadas do negócio que usam os resultados da inferência (previsões) para orientar decisões.
- Equipe da plataforma – Os arquitetos são responsáveis pela arquitetura geral da nuvem do negócio e pela forma como todos os diferentes serviços estão conectados entre si. As PMEs de segurança revisam a arquitetura com base nas políticas e necessidades de segurança empresarial. Os engenheiros de MLOps são responsáveis por fornecer um ambiente seguro para cientistas de dados e engenheiros de ML produzirem os casos de uso de ML. Especificamente, eles são responsáveis pela padronização de pipelines de CI/CD, funções de usuários e serviços e criação de contêineres, consumo de modelos, testes e metodologia de implantação com base em requisitos de negócios e segurança.
- Equipe de risco e conformidade – Para ambientes mais restritivos, os auditores são responsáveis por avaliar os dados, o código e os artefatos do modelo e garantir que o negócio esteja em conformidade com as regulamentações, como a privacidade de dados.
Observe que várias personas podem ser cobertas pela mesma pessoa, dependendo do dimensionamento e da maturidade de MLOps do negócio.
Essas personas necessitam de ambientes dedicados para realizar os diversos processos, conforme ilustrado na figura a seguir.
Os ambientes são os seguintes:
- Administração da plataforma – O ambiente de administração da plataforma é o local onde a equipe da plataforma tem acesso para criar contas AWS e vincular os usuários e dados certos
- Data – A camada de dados, muitas vezes conhecida como data lake ou malha de dados, é o ambiente que engenheiros ou proprietários de dados e partes interessadas de negócios usam para preparar, interagir e visualizar os dados.
- Experimentação – Os cientistas de dados usam uma sandbox ou ambiente de experimentação para testar novas bibliotecas e técnicas de ML para provar que sua prova de conceito pode resolver problemas de negócios
- Construção de modelo, teste de modelo, implantação de modelo – O ambiente de construção, teste e implantação do modelo é a camada de MLOps, onde cientistas de dados e engenheiros de ML colaboram para automatizar e mover a pesquisa para produção
- Governança de ML – A última peça do quebra-cabeça é o ambiente de governança de ML, onde todos os modelos e artefatos de código são armazenados, revisados e auditados pelas personas correspondentes
O diagrama a seguir ilustra a arquitetura de referência, que já foi discutida em Roteiro básico de MLOps para empresas com o Amazon SageMaker.
Cada unidade de negócios tem seu próprio conjunto de contas de desenvolvimento (treinamento e construção de modelo automatizado), pré-produção (teste automático) e produção (implantação e serviço de modelo) para produzir casos de uso de ML, que recuperam dados de um data lake ou dados centralizado ou descentralizado. malha, respectivamente. Todos os modelos produzidos e automação de código são armazenados em uma conta de ferramentas centralizada usando a capacidade de um registro de modelo. O código de infraestrutura para todas essas contas é versionado em uma conta de serviço compartilhada (conta de governança analítica avançada) que a equipe da plataforma pode abstrair, modelar, manter e reutilizar para a integração na plataforma MLOps de cada nova equipe.
Definições de IA generativa e diferenças para MLOps
No ML clássico, a combinação anterior de pessoas, processos e tecnologia pode ajudá-lo a produzir seus casos de uso de ML. No entanto, na IA generativa, a natureza dos casos de utilização exige uma extensão dessas capacidades ou novas capacidades. Uma dessas novas noções é o modelo básico (FM). Eles são chamados assim porque podem ser usados para criar uma ampla gama de outros modelos de IA, conforme ilustrado na figura a seguir.
FM foi treinado com base em terabytes de dados e possui centenas de bilhões de parâmetros para poder prever a próxima melhor resposta com base em três categorias principais de casos de uso de IA generativa:
- Texto para texto – Os FMs (LLMs) foram treinados com base em dados não rotulados (como texto livre) e são capazes de prever a próxima melhor palavra ou sequência de palavras (parágrafos ou ensaios longos). Os principais casos de uso envolvem chatbots semelhantes aos humanos, resumo ou outra criação de conteúdo, como código de programação.
- Texto para imagem – Dados rotulados, como pares de , tem sido usado para treinar FMs, que são capazes de prever a melhor combinação de pixels. Exemplos de casos de uso são geração de design de roupas ou imagens imaginárias personalizadas.
- Texto para áudio ou vídeo – Dados rotulados e não rotulados podem ser usados para treinamento FM. Um exemplo principal de caso de uso de IA generativa é a composição musical.
Para produzir esses casos de uso generativos de IA, precisamos emprestar e estender o domínio MLOps para incluir o seguinte:
- Operações FM (FMOps) – Isso pode produzir soluções generativas de IA, incluindo qualquer tipo de caso de uso
- Operações LLM (LLMOps) – Este é um subconjunto de FMOps com foco na produção de soluções baseadas em LLM, como texto para texto
A figura a seguir ilustra a sobreposição desses casos de uso.
Em comparação com ML e MLOps clássicos, FMOps e LLMOps diferem com base em quatro categorias principais que abordamos nas seções a seguir: pessoas e processos, seleção e adaptação de FM, avaliação e monitoramento de FM, privacidade de dados e implantação de modelo, e necessidades de tecnologia. Abordaremos o monitoramento em uma postagem separada.
Jornada de operacionalização por tipo de usuário de IA generativa
Para simplificar a descrição dos processos, precisamos categorizar os principais tipos de usuários de IA generativa, conforme mostrado na figura a seguir.
Os tipos de usuário são os seguintes:
- prestadores – Usuários que constroem FMs do zero e os fornecem como produto para outros usuários (sintonizador e consumidor). Eles têm profundo conhecimento de ponta a ponta em ML e processamento de linguagem natural (PNL), além de habilidades em ciência de dados, além de equipes massivas de rotuladores e editores de dados.
- Afinadores finos – Usuários que treinam novamente (ajustam) os FMs dos fornecedores para atender aos requisitos personalizados. Eles orquestram a implantação do modelo como um serviço para uso dos consumidores. Esses usuários precisam de forte experiência completa em ML e ciência de dados e conhecimento de implantação e inferência de modelos. Também é necessário um forte conhecimento de domínio para ajuste, incluindo engenharia imediata.
- Consumidores – Usuários que interagem com serviços generativos de IA de provedores ou sintonizadores por meio de solicitações de texto ou de uma interface visual para concluir as ações desejadas. Não é necessário nenhum conhecimento de ML, mas, principalmente, desenvolvedores de aplicativos ou usuários finais com compreensão dos recursos do serviço. Somente engenharia imediata é necessária para obter melhores resultados.
De acordo com a definição e a experiência necessária em ML, o MLOps é necessário principalmente para provedores e sintonizadores, enquanto os consumidores podem usar princípios de produção de aplicativos, como DevOps e AppDev para criar aplicativos generativos de IA. Além disso, observámos um movimento entre os tipos de utilizadores, em que os fornecedores podem tornar-se afinadores para apoiar casos de utilização baseados numa vertical específica (como o setor financeiro) ou os consumidores podem tornar-se afinadores para obter resultados mais precisos. Mas vamos observar os principais processos por tipo de usuário.
A jornada dos consumidores
A figura a seguir ilustra a jornada do consumidor.
Conforme mencionado anteriormente, os consumidores são obrigados a selecionar, testar e utilizar um FM, interagindo com ele fornecendo insumos específicos, também conhecidos como solicita. Os prompts, no contexto da programação de computadores e da IA, referem-se à entrada que é fornecida a um modelo ou sistema para gerar uma resposta. Isso pode ser na forma de um texto, comando ou pergunta, que o sistema usa para processar e gerar uma saída. Os resultados gerados pelo FM podem então ser utilizados pelos usuários finais, que também deverão ser capazes de avaliar esses resultados para melhorar as respostas futuras do modelo.
Além desses processos fundamentais, notamos que os consumidores expressam o desejo de ajustar um modelo aproveitando a funcionalidade oferecida pelos sintonizadores. Tomemos, por exemplo, um site que gera imagens. Aqui, os usuários finais podem configurar contas privadas, fazer upload de fotos pessoais e, posteriormente, gerar conteúdo relacionado a essas imagens (por exemplo, gerando uma imagem representando o usuário final em uma motocicleta empunhando uma espada ou localizado em um local exótico). Neste cenário, a aplicação generativa de IA, concebida pelo consumidor, deve interagir com o backend do sintonizador fino através de APIs para entregar esta funcionalidade aos utilizadores finais.
No entanto, antes de nos aprofundarmos nisso, vamos primeiro nos concentrar na jornada de seleção do modelo, teste, uso, interação de entrada e saída e classificação, conforme mostrado na figura a seguir.
*Referência FM disponível em 15K
Etapa 1. Compreenda os principais recursos de FM
Há muitas dimensões que precisam ser consideradas ao selecionar modelos de fundação, dependendo do caso de uso, dos dados disponíveis, das regulamentações e assim por diante. Uma boa lista de verificação, embora não abrangente, pode ser a seguinte:
- FM proprietário ou de código aberto – Os modelos proprietários têm frequentemente um custo financeiro, mas normalmente oferecem melhor desempenho (em termos de qualidade do texto ou imagem gerada), sendo muitas vezes desenvolvidos e mantidos por equipas dedicadas de fornecedores de modelos que garantem um desempenho e fiabilidade ideais. Por outro lado, também vemos a adoção de modelos de código aberto que, além de serem gratuitos, oferecem benefícios adicionais por serem acessíveis e flexíveis (por exemplo, todo modelo de código aberto é ajustável). Um exemplo de modelo proprietário é o modelo Claude da Anthropic, e um exemplo de modelo de código aberto de alto desempenho é o Falcon-40B, em julho de 2023.
- Licença comercial – As considerações de licenciamento são cruciais ao decidir sobre um FM. É importante observar que alguns modelos são de código aberto, mas não podem ser usados para fins comerciais, devido a restrições ou condições de licenciamento. As diferenças podem ser sutis: o recém-lançado xgen-7b-8k-base O modelo, por exemplo, é de código aberto e comercialmente utilizável (licença Apache-2.0), enquanto a versão ajustada da instrução do modelo xgen-7b-8k-inst é liberado apenas para fins de pesquisa. Ao selecionar um FM para uma aplicação comercial, é essencial verificar o contrato de licença, compreender suas limitações e garantir que esteja alinhado com o uso pretendido do projeto.
- parâmetros – O número de parâmetros, que consistem nos pesos e vieses da rede neural, é outro fator chave. Mais parâmetros geralmente significam um modelo mais complexo e potencialmente poderoso, porque pode capturar padrões e correlações mais intricados nos dados. No entanto, a desvantagem é que ele requer mais recursos computacionais e, portanto, custa mais para ser executado. Além disso, vemos uma tendência para modelos mais pequenos, especialmente no espaço de código aberto (modelos que variam entre 7 e 40 mil milhões) que têm um bom desempenho, especialmente quando ajustados.
- Velocidade – A velocidade de um modelo é influenciada pelo seu tamanho. Modelos maiores tendem a processar dados mais lentamente (maior latência) devido ao aumento da complexidade computacional. Portanto, é crucial equilibrar a necessidade de um modelo com alto poder preditivo (geralmente modelos maiores) com os requisitos práticos de velocidade, especialmente em aplicações, como chatbots, que exigem respostas em tempo real ou quase em tempo real.
- Tamanho da janela de contexto (número de tokens) – A janela de contexto, definida pelo número máximo de tokens que podem ser inseridos ou gerados por prompt, é crucial para determinar quanto contexto o modelo pode considerar por vez (um token traduz aproximadamente 0.75 palavras para inglês). Modelos com janelas de contexto maiores podem compreender e gerar sequências de texto mais longas, o que pode ser útil para tarefas que envolvem conversas ou documentos mais longos.
- Conjunto de dados de treinamento – Também é importante entender em que tipo de dados o FM foi treinado. Alguns modelos podem ser treinados em diversos conjuntos de dados de texto, como dados da Internet, scripts de codificação, instruções ou feedback humano. Outros também podem ser treinados em conjuntos de dados multimodais, como combinações de dados de texto e imagem. Isto pode influenciar a adequação do modelo para diferentes tarefas. Além disso, uma organização pode ter preocupações com direitos autorais dependendo das fontes exatas nas quais um modelo foi treinado – portanto, é obrigatório inspecionar de perto o conjunto de dados de treinamento.
- Qualidade – A qualidade de um FM pode variar com base em seu tipo (proprietário vs. código aberto), tamanho e no que foi treinado. A qualidade depende do contexto, o que significa que o que é considerado de alta qualidade para um aplicativo pode não ser para outro. Por exemplo, um modelo treinado em dados da Internet pode ser considerado de alta qualidade para gerar texto conversacional, mas nem tanto para tarefas técnicas ou especializadas.
- Ajustável – A capacidade de ajustar um FM ajustando os pesos ou camadas do modelo pode ser um fator crucial. O ajuste fino permite que o modelo se adapte melhor ao contexto específico da aplicação, melhorando o desempenho na tarefa específica em questão. No entanto, o ajuste fino requer recursos computacionais adicionais e conhecimento técnico, e nem todos os modelos suportam esse recurso. Os modelos de código aberto são (em geral) sempre ajustáveis porque os artefatos do modelo estão disponíveis para download e os usuários podem estendê-los e usá-los à vontade. Às vezes, modelos proprietários podem oferecer a opção de ajuste fino.
- Habilidades existentes do cliente – A seleção de um FM também pode ser influenciada pelas habilidades e familiaridade do cliente ou da equipe de desenvolvimento. Se uma organização não tiver especialistas em IA/ML em sua equipe, um serviço de API poderá ser mais adequado para ela. Além disso, se uma equipe tiver ampla experiência com um FM específico, pode ser mais eficiente continuar a utilizá-lo em vez de investir tempo e recursos para aprender e se adaptar a um novo.
A seguir está um exemplo de duas listas, uma para modelos proprietários e outra para modelos de código aberto. Você pode compilar tabelas semelhantes com base em suas necessidades específicas para obter uma visão geral rápida das opções disponíveis. Observe que o desempenho e os parâmetros desses modelos mudam rapidamente e podem estar desatualizados no momento da leitura, enquanto outros recursos podem ser importantes para clientes específicos, como o idioma suportado.
A seguir está um exemplo de FMs proprietários notáveis disponíveis na AWS (julho de 2023).
A seguir está um exemplo de FM de código aberto notável disponível na AWS (julho de 2023).
Depois de compilar uma visão geral de 10 a 20 modelos candidatos em potencial, será necessário refinar ainda mais esta lista. Nesta secção, propomos um mecanismo rápido que produzirá dois ou três modelos finais viáveis como candidatos para a próxima ronda.
O diagrama a seguir ilustra o processo inicial de seleção.
Normalmente, os engenheiros de prompt, que são especialistas na criação de prompts de alta qualidade que permitem que os modelos de IA entendam e processem as entradas do usuário, experimentam vários métodos para executar a mesma tarefa (como resumo) em um modelo. Sugerimos que esses prompts não sejam criados instantaneamente, mas sejam sistematicamente extraídos de um catálogo de prompts. Este catálogo de prompts é um local central para armazenar prompts para evitar replicações, ativar o controle de versão e compartilhar prompts dentro da equipe para garantir consistência entre diferentes testadores de prompts nos diferentes estágios de desenvolvimento, que apresentaremos na próxima seção. Este catálogo de prompt é análogo a um repositório Git de um feature store. O desenvolvedor de IA generativa, que poderia ser potencialmente a mesma pessoa que o engenheiro imediato, precisa então avaliar o resultado para determinar se seria adequado para a aplicação de IA generativa que pretende desenvolver.
Passo 2. Teste e avalie o FM superior
Depois que a lista restrita for reduzida a aproximadamente três FMs, recomendamos uma etapa de avaliação para testar ainda mais as capacidades e a adequação dos FMs ao caso de uso. Dependendo da disponibilidade e da natureza dos dados de avaliação, sugerimos diferentes métodos, conforme ilustrado na figura seguinte.
O método a ser usado primeiro depende se você rotulou os dados de teste ou não.
Se você rotulou os dados, poderá usá-los para realizar uma avaliação do modelo, como fazemos com os modelos de ML tradicionais (insira algumas amostras e compare a saída com os rótulos). Dependendo se os dados de teste possuem rótulos discretos (como análise de sentimento positiva, negativa ou neutra) ou são texto não estruturado (como resumo), propomos diferentes métodos de avaliação:
- Métricas de precisão – No caso de resultados discretos (como análise de sentimento), podemos usar métricas de precisão padrão, como precisão, recall e pontuação F1
- Métricas de similaridade – Se a saída não for estruturada (como um resumo), sugerimos métricas de similaridade como ROUGE e similaridade de cosseno
Alguns casos de uso não permitem uma resposta verdadeira (por exemplo, “Criar um conto infantil para minha filha de 5 anos”). Nesses casos, torna-se mais desafiador avaliar os modelos porque você não possui dados de teste rotulados. Propomos duas abordagens, dependendo da importância da revisão humana do modelo versus avaliação automatizada:
- Humano no Loop (HIL) – Nesse caso, uma equipe de testadores imediatos revisará as respostas de um modelo. Dependendo de quão crítica é a aplicação, os testadores imediatos podem revisar 100% dos resultados do modelo ou apenas uma amostra.
- Avaliação baseada em LLM – Neste cenário, os testadores imediatos são substituídos por um LLM, idealmente um que seja mais poderoso (embora talvez mais lento e mais caro) do que os que estão sendo testados. O LLM revisará todas as respostas geradas pelo modelo e as pontuará. Este método pode resultar em qualidade inferior, mas é uma opção de avaliação mais barata e rápida que pode fornecer uma boa avaliação inicial do desempenho dos modelos.
Por exemplo, podemos usar o seguinte prompt de exemplo para um LLM, que inclui a consulta de entrada, a resposta do LLM e instruções: “Gostaríamos de solicitar seu feedback sobre o desempenho de um assistente de IA em resposta à pergunta do usuário exibida acima . Avalie a utilidade, relevância, precisão e nível de detalhes da resposta do assistente. O assistente receberá uma pontuação global numa escala de 1 a 10, sendo que uma pontuação mais elevada indica melhor desempenho global.”
Este prompt será enviado para outro LLM (o EvalLLM) para avaliação. A seguir está um exemplo onde a resposta do modelo Falcon-40B foi avaliada por um EvalLLM (neste caso Claude). Usamos a pergunta “E se o Canal de Suez nunca tivesse sido construído?” A resposta é a seguinte:
Pergunta: E se o Canal de Suez nunca tivesse sido construído?
falcon-40b-instruir
Se o Canal de Suez nunca tivesse sido construído, os navios teriam de viajar por África para navegar entre o Mediterrâneo e o Mar Vermelho. Isto acrescentaria tempo e distância significativos à viagem, tornando-a menos eficiente e mais cara. Além disso, sem o Canal de Suez, muitos países do Médio Oriente e do Norte de África teriam estado muito menos ligados ao resto do mundo, dificultando o desenvolvimento económico e cultural.
Revisão (Pontuação: 9/10)
A resposta do assistente é altamente relevante, precisa e detalhada. Fornece uma excelente resposta à hipotética questão do usuário sobre a inexistência do Canal de Suez. O assistente aponta correctamente as implicações nas viagens marítimas e o impacto económico e cultural no Médio Oriente e no Norte de África. No entanto, poderia ter elaborado mais detalhadamente as implicações geopolíticas ou o impacto nos padrões comerciais globais para uma resposta mais abrangente.
A figura a seguir ilustra o exemplo do processo de avaliação ponta a ponta.
Com base neste exemplo, para realizar a avaliação, precisamos fornecer os prompts de exemplo, que armazenamos no catálogo de prompts, e um conjunto de dados de avaliação rotulado ou não rotulado com base em nossos aplicativos específicos. Por exemplo, com um conjunto de dados de avaliação rotulado, podemos fornecer prompts (entrada e consulta), como “Dê-me o nome completo do PM do Reino Unido em 2023” e resultados e respostas, como “Rishi Sunak”. Com um conjunto de dados não rotulado, fornecemos apenas a pergunta ou instrução, como “Gerar o código-fonte para um site de varejo”. Chamamos a combinação de catálogo imediato e conjunto de dados de avaliação de catálogo de prompt de avaliação. A razão pela qual diferenciamos o catálogo de prompts e o catálogo de prompts de avaliação é porque o último é dedicado a um caso de uso específico, em vez de prompts e instruções genéricas (como resposta a perguntas) que o catálogo de prompts contém.
Com este catálogo de prompts de avaliação, a próxima etapa é enviar os prompts de avaliação aos principais FMs. O resultado é um conjunto de dados de resultados de avaliação que contém os prompts, as saídas de cada FM e a saída rotulada junto com uma pontuação (se existir). No caso de um catálogo de solicitações de avaliação não rotulado, há uma etapa adicional para um HIL ou LLM revisar os resultados e fornecer uma pontuação e feedback (conforme descrito anteriormente). O resultado final serão resultados agregados que combinam as pontuações de todos os resultados (calcular a precisão média ou classificação humana) e permitir aos utilizadores avaliar a qualidade dos modelos.
Após a recolha dos resultados da avaliação, propomos a escolha de um modelo baseado em diversas dimensões. Isso normalmente se resume a fatores como precisão, velocidade e custo. A figura a seguir mostra um exemplo.
Cada modelo possuirá pontos fortes e certas compensações ao longo destas dimensões. Dependendo do caso de uso, devemos atribuir prioridades variadas a essas dimensões. No exemplo anterior, optamos por priorizar o custo como o fator mais importante, seguido pela precisão e depois pela velocidade. Embora seja mais lento e não tão eficiente quanto o FM1, permanece suficientemente eficaz e significativamente mais barato para hospedar. Consequentemente, podemos selecionar FM2 como a melhor escolha.
Etapa 3. Desenvolva o back-end e o front-end do aplicativo de IA generativo
Neste ponto, os desenvolvedores de IA generativa selecionaram o FM certo para a aplicação específica, juntamente com a ajuda de engenheiros e testadores imediatos. A próxima etapa é começar a desenvolver o aplicativo generativo de IA. Separamos o desenvolvimento do aplicativo generativo de IA em duas camadas, um back-end e um front-end, conforme mostrado na figura a seguir.
No back-end, os desenvolvedores de IA generativa incorporam o FM selecionado nas soluções e trabalham em conjunto com os engenheiros de prompt para criar a automação para transformar a entrada do usuário final em prompts de FM apropriados. Os testadores de prompt criam as entradas necessárias no catálogo de prompt para testes automáticos ou manuais (HIL ou LLM). Em seguida, os desenvolvedores de IA generativa criam o encadeamento imediato e o mecanismo de aplicação para fornecer o resultado final. O encadeamento de prompts, neste contexto, é uma técnica para criar aplicativos LLM mais dinâmicos e com reconhecimento contextual. Ele funciona dividindo uma tarefa complexa em uma série de subtarefas menores e mais gerenciáveis. Por exemplo, se fizermos a um LLM a pergunta “Onde nasceu o primeiro-ministro do Reino Unido e a que distância esse lugar fica de Londres”, a tarefa pode ser dividida em prompts individuais, onde um prompt pode ser construído com base na resposta de uma avaliação prévia imediata, como “Quem é o primeiro-ministro do Reino Unido”, “Qual é o seu local de nascimento” e “A que distância esse lugar fica de Londres?” Para garantir uma certa qualidade de entrada e saída, os desenvolvedores de IA generativa também precisam criar o mecanismo para monitorar e filtrar as entradas do usuário final e as saídas do aplicativo. Se, por exemplo, o aplicativo LLM deveria evitar solicitações e respostas tóxicas, eles poderiam aplicar um detector de toxicidade para entrada e saída e filtrá-los. Por último, precisam de fornecer um mecanismo de classificação, que apoiará o aumento do catálogo de sugestões de avaliação com bons e maus exemplos. Uma representação mais detalhada desses mecanismos será apresentada em posts futuros.
Para fornecer a funcionalidade ao usuário final de IA generativa, é necessário o desenvolvimento de um site front-end que interaja com o back-end. Portanto, personas DevOps e AppDevs (desenvolvedores de aplicações na nuvem) precisam seguir as melhores práticas de desenvolvimento para implementar as funcionalidades de entrada/saída e classificação.
Além dessa funcionalidade básica, o frontend e o backend precisam incorporar o recurso de criação de contas de usuário pessoais, upload de dados, início de ajuste fino como caixa preta e utilização do modelo personalizado em vez do FM básico. A produção de um aplicativo generativo de IA é semelhante a um aplicativo normal. A figura a seguir descreve um exemplo de arquitetura.
Nesta arquitetura, os desenvolvedores de IA generativa, engenheiros imediatos e DevOps ou AppDevs criam e testam o aplicativo manualmente, implantando-o via CI/CD em um ambiente de desenvolvimento (AI App Dev generativo na figura anterior) usando repositórios de código dedicados e mesclando com o ramo de desenvolvimento. Nesta fase, os desenvolvedores de IA generativa usarão o FM correspondente chamando a API conforme fornecido pelos fornecedores de sintonizadores finos de FM. Em seguida, para testar o aplicativo extensivamente, eles precisam promover o código para a ramificação de teste, o que acionará a implantação via CI/CD no ambiente de pré-produção (Pré-produção generativa do aplicativo AI). Nesse ambiente, os testadores de prompts precisam testar uma grande quantidade de combinações de prompts e revisar os resultados. A combinação de prompts, resultados e revisão precisa ser movida para o catálogo de prompts de avaliação para automatizar o processo de teste no futuro. Após esse extenso teste, a última etapa é promover o aplicativo generativo de IA para produção via CI/CD, fundindo-se com o ramo principal (generative AI App Prod). Observe que todos os dados, incluindo o catálogo de prompt, dados e resultados de avaliação, dados e metadados do usuário final e metadados de modelo ajustados, precisam ser armazenados no data lake ou na camada de malha de dados. Os pipelines e repositórios de CI/CD precisam ser armazenados em uma conta de ferramentas separada (semelhante à descrita para MLOps).
A jornada dos provedores
Os provedores de FM precisam treinar FMs, como modelos de aprendizagem profunda. Para eles, o ciclo de vida e a infraestrutura de MLOps de ponta a ponta são necessários. Adições são necessárias na preparação de dados históricos, avaliação de modelos e monitoramento. A figura a seguir ilustra sua jornada.
No ML clássico, os dados históricos são geralmente criados alimentando a verdade por meio de pipelines ETL. Por exemplo, em um caso de uso de previsão de desligamento, uma automação atualiza uma tabela de banco de dados com base no novo status de um cliente para desligar/não desligar automaticamente. No caso dos FMs, eles precisam de bilhões de pontos de dados rotulados ou não. Em casos de uso de texto para imagem, uma equipe de rotuladores de dados precisa rotular pares manualmente. Este é um exercício caro que requer um grande número de recursos humanos. Amazon SageMaker Ground Truth Plus pode fornecer uma equipe de etiquetadores para realizar esta atividade para você. Para alguns casos de uso, esse processo também pode ser parcialmente automatizado, por exemplo, usando modelos do tipo CLIP. No caso de um LLM, como texto para texto, os dados não são rotulados. No entanto, eles precisam estar preparados e seguir o formato dos dados históricos não rotulados existentes. Portanto, editores de dados são necessários para realizar a preparação necessária dos dados e garantir a consistência.
Com os dados históricos preparados, o próximo passo é o treinamento e produção do modelo. Observe que as mesmas técnicas de avaliação que descrevemos para os consumidores podem ser usadas.
A jornada dos sintonizadores finos
Os sintonizadores finos visam adaptar um FM existente ao seu contexto específico. Por exemplo, um modelo FM pode resumir com precisão um texto de uso geral, mas não um relatório financeiro, ou não pode gerar código-fonte para uma linguagem de programação não comum. Nesses casos, os responsáveis pelo ajuste preciso precisam rotular os dados, ajustar um modelo executando um trabalho de treinamento, implantar o modelo, testá-lo com base nos processos do consumidor e monitorar o modelo. O diagrama a seguir ilustra esse processo.
Por enquanto, existem dois mecanismos de ajuste fino:
- Afinação – Usando um FM e dados rotulados, um trabalho de treinamento recalcula os pesos e tendências das camadas do modelo de aprendizagem profunda. Este processo pode ser computacionalmente intensivo e requer uma quantidade representativa de dados, mas pode gerar resultados precisos.
- Ajuste fino com eficiência de parâmetros (PEFT) – Em vez de recalcular todos os pesos e preconceitos, os investigadores demonstraram que, ao adicionar pequenas camadas adicionais aos modelos de aprendizagem profunda, podem alcançar resultados satisfatórios (por exemplo, LoRA). O PEFT requer menor poder computacional do que o ajuste fino profundo e um trabalho de treinamento com menos dados de entrada. A desvantagem é uma possível menor precisão.
O diagrama a seguir ilustra esses mecanismos.
Agora que definimos os dois principais métodos de ajuste fino, a próxima etapa é determinar como podemos implantar e usar o FM de código aberto e proprietário.
Com FMs de código aberto, os sintonizadores podem baixar o artefato do modelo e o código-fonte da web, por exemplo, usando o Hub de modelo de rosto de abraço. Isso lhe dá a flexibilidade de ajustar profundamente o modelo, armazená-lo em um registro de modelo local e implantá-lo em um Amazon Sage Maker ponto final. Este processo requer uma conexão com a internet. Para oferecer suporte a ambientes mais seguros (como para clientes do setor financeiro), você pode baixar o modelo localmente, executar todas as verificações de segurança necessárias e carregá-los em um bucket local em uma conta da AWS. Em seguida, os sintonizadores finos usam o FM do balde local sem conexão com a Internet. Isso garante a privacidade dos dados e os dados não viajam pela Internet. O diagrama a seguir ilustra esse método.
Com FMs proprietários, o processo de implantação é diferente porque os sintonizadores não têm acesso ao artefato do modelo ou ao código-fonte. Os modelos são armazenados em contas AWS e registros de modelos proprietários do provedor de FM. Para implantar tal modelo em um endpoint SageMaker, os sintonizadores podem solicitar apenas o pacote de modelo que será implantado diretamente em um endpoint. Este processo exige que os dados do cliente sejam usados nas contas proprietárias dos provedores de FM, o que levanta questões sobre dados confidenciais do cliente usados em uma conta remota para realizar ajustes finos e modelos hospedados em um registro de modelo que é compartilhado entre vários clientes. . Isto leva a um problema de multilocação que se torna mais desafiador se os provedores proprietários de FM precisarem atender a esses modelos. Se os sintonizadores finos usarem Rocha Amazônica, esses desafios foram resolvidos: os dados não viajam pela Internet e os provedores de FM não têm acesso aos dados dos sintonizadores. Os mesmos desafios se aplicam aos modelos de código aberto se os sintonizadores quiserem servir modelos de vários clientes, como o exemplo que demos anteriormente com o site para o qual milhares de clientes farão upload de imagens personalizadas. No entanto, estes cenários podem ser considerados controláveis porque apenas o afinador está envolvido. O diagrama a seguir ilustra esse método.
Do ponto de vista tecnológico, a arquitetura que um ajuste fino precisa suportar é semelhante à do MLOps (veja a figura a seguir). O ajuste fino precisa ser conduzido no desenvolvimento, criando pipelines de ML, como o uso Pipelines Amazon SageMaker; realizar pré-processamento, ajuste fino (trabalho de treinamento) e pós-processamento; e enviar os modelos ajustados para um registro de modelo local no caso de um FM de código aberto (caso contrário, o novo modelo será armazenado no ambiente proprietário de fornecimento de FM). Depois, na pré-produção, precisamos testar o modelo conforme descrevemos para o cenário dos consumidores. Por fim, o modelo será atendido e monitorado no prod. Observe que o FM atual (ajustado) requer endpoints de instância de GPU. Se precisarmos implantar cada modelo ajustado em um endpoint separado, isso poderá aumentar o custo no caso de centenas de modelos. Portanto, precisamos usar endpoints multimodelos e resolver o desafio da multilocação.
Os sintonizadores finos adaptam um modelo de FM com base em um contexto específico para usá-lo em seus propósitos comerciais. Isso significa que, na maioria das vezes, os sintonizadores também são consumidores necessários para oferecer suporte a todas as camadas, conforme descrevemos nas seções anteriores, incluindo o desenvolvimento generativo de aplicativos de IA, data lake e malha de dados, e MLOps.
A figura a seguir ilustra o ciclo de vida completo do ajuste fino de FM que os sintonizadores precisam para fornecer ao usuário final de IA generativa.
A figura a seguir ilustra as principais etapas.
As principais etapas são as seguintes:
- O usuário final cria uma conta pessoal e carrega dados privados.
- Os dados são armazenados no data lake e pré-processados para seguir o formato esperado pelo FM.
- Isso aciona um pipeline de ML de ajuste fino que adiciona o modelo ao registro do modelo,
- A partir daí, o modelo é implantado na produção com testes mínimos ou o modelo realiza testes extensivos com HIL e portas de aprovação manuais.
- O modelo ajustado é disponibilizado para os usuários finais.
Como essa infraestrutura é complexa para clientes não empresariais, a AWS lançou o Amazon Bedrock para aliviar o esforço de criação de tais arquiteturas e aproximar FMs ajustados da produção.
Personas e processos diferenciadores de FMOps e LLMOps
Com base nas jornadas anteriores do tipo de usuário (consumidor, produtor e sintonizador), são necessárias novas personas com habilidades específicas, conforme ilustrado na figura a seguir.
As novas personas são as seguintes:
- Rotuladores e editores de dados – Esses usuários rotulam dados, como pares ou preparar dados não rotulados, como texto livre, e ampliar a equipe de análise avançada e os ambientes de data lake.
- Afinadores finos – Esses usuários possuem profundo conhecimento em FMs e sabem ajustá-los, ampliando a equipe de ciência de dados que focará no ML clássico.
- Desenvolvedores de IA generativa – Eles têm profundo conhecimento sobre seleção de FMs, encadeamento de prompts e aplicações e filtragem de entradas e saídas. Eles pertencem a uma nova equipe – a equipe de aplicação de IA generativa.
- Engenheiros alertas – Esses usuários projetam os prompts de entrada e saída para adaptar a solução ao contexto e testar e criar a versão inicial do catálogo de prompts. Sua equipe é a equipe de aplicativos generativos de IA.
- Testadores de prompt – Eles testam em escala a solução generativa de IA (backend e frontend) e alimentam seus resultados para aumentar o catálogo imediato e o conjunto de dados de avaliação. Sua equipe é a equipe de aplicativos generativos de IA.
- AppDev e DevOps – Eles desenvolvem o front-end (como um site) da aplicação generativa de IA. Sua equipe é a equipe de aplicativos generativos de IA.
- Usuários finais de IA generativa – Esses usuários consomem aplicativos generativos de IA como caixas pretas, compartilham dados e avaliam a qualidade do resultado.
A versão estendida do mapa de processos MLOps para incorporar IA generativa pode ser ilustrada com a figura a seguir.
Uma nova camada de aplicativo é o ambiente onde desenvolvedores de IA generativa, engenheiros e testadores imediatos e AppDevs criaram o back-end e o front-end de aplicativos de IA generativa. Os usuários finais de IA generativa interagem com o front-end dos aplicativos de IA generativa por meio da Internet (como uma interface de usuário da web). Por outro lado, os rotuladores e editores de dados precisam pré-processar os dados sem acessar o backend do data lake ou da malha de dados. Portanto, uma UI web (site) com um editor é necessária para interagir de forma segura com os dados. O SageMaker Ground Truth fornece essa funcionalidade pronta para uso.
Conclusão
MLOps pode nos ajudar a produzir modelos de ML com eficiência. No entanto, para operacionalizar aplicações generativas de IA, são necessárias competências, processos e tecnologias adicionais, levando a FMOps e LLMOps. Neste post, definimos os principais conceitos de FMOps e LLMOps e descrevemos os principais diferenciais em comparação com as capacidades de MLOps em termos de pessoas, processos, tecnologia, seleção de modelo de FM e avaliação. Além disso, ilustramos o processo de pensamento de um desenvolvedor de IA generativa e o ciclo de vida de desenvolvimento de uma aplicação de IA generativa.
No futuro, nos concentraremos em fornecer soluções de acordo com o domínio que discutimos e forneceremos mais detalhes sobre como integrar o monitoramento FM (como toxicidade, preconceito e alucinação) e padrões arquitetônicos de fontes de dados privadas ou de terceiros, como Geração Aumentada de Recuperação (RAG), em FMOps/LLMOps.
Para saber mais, consulte Roteiro básico de MLOps para empresas com o Amazon SageMaker e experimente a solução ponta a ponta em Implementação de práticas de MLOps com modelos pré-treinados do Amazon SageMaker JumpStart.
Se você tiver quaisquer comentários ou perguntas, por favor, deixe-os na seção de comentários.
Sobre os autores
Dr. é arquiteto sênior de soluções especialista em operações e aprendizado de máquina da Amazon Web Services. A Sokratis se concentra em permitir que clientes corporativos industrializem suas soluções de aprendizado de máquina (ML), explorando os serviços da AWS e moldando seu modelo operacional, ou seja, a base de MLOps e o roteiro de transformação, aproveitando as melhores práticas de desenvolvimento. Ele passou mais de 15 anos inventando, projetando, liderando e implementando soluções inovadoras de ML e Internet das Coisas (IoT) de nível de produção ponta a ponta nas áreas de energia, varejo, saúde, finanças/bancários, esportes motorizados, etc. Sokratis gosta de passar seu tempo livre com a família e amigos, ou andando de moto.
Heiko Hotz é arquiteto de soluções sênior para IA e aprendizado de máquina, com foco especial em processamento de linguagem natural, grandes modelos de linguagem e IA generativa. Antes desta função, ele foi Chefe de Ciência de Dados do Atendimento ao Cliente da Amazon na UE. Heiko ajuda nossos clientes a ter sucesso em sua jornada de IA/ML na AWS e trabalhou com organizações em vários setores, incluindo seguros, serviços financeiros, mídia e entretenimento, saúde, serviços públicos e manufatura. Nas horas vagas, Heiko viaja o máximo possível.
- Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
- PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
- PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
- PlatãoESG. Automotivo / EVs, Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
- PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
- ChartPrime. Eleve seu jogo de negociação com ChartPrime. Acesse aqui.
- BlockOffsets. Modernizando a Propriedade de Compensação Ambiental. Acesse aqui.
- Fonte: https://aws.amazon.com/blogs/machine-learning/fmops-llmops-operationalize-generative-ai-and-differences-with-mlops/
- :tem
- :é
- :não
- :onde
- $UP
- 1
- 10
- 100
- 2023
- 23
- 7
- 75
- a
- habilidade
- Capaz
- Sobre
- acima
- RESUMO
- Acesso
- acessível
- acessando
- Conta
- Contas
- precisão
- preciso
- exatamente
- Alcançar
- ações
- atividade
- adaptar
- adaptação
- adicionar
- acrescentando
- Adição
- Adicional
- Adicionalmente
- Adicionais
- Adiciona
- administração
- Adoção
- avançado
- África
- Depois de
- Acordo
- AI
- IA e aprendizado de máquina
- Assistente de IA
- Modelos de IA
- Serviços de IA
- casos de uso ai
- AI / ML
- visar
- Alinha
- Todos os Produtos
- permitir
- permite
- juntamente
- já
- tb
- Apesar
- sempre
- Amazon
- Amazon Sage Maker
- JumpStart do Amazon SageMaker
- Amazon Web Services
- entre
- quantidade
- an
- análise
- analítica
- e
- e infra-estrutura
- Outro
- responder
- respostas
- qualquer
- api
- APIs
- app
- Aplicação
- Desenvolvimento de Aplicações
- aplicações
- Aplicar
- abordagem
- se aproxima
- apropriado
- aprovação
- aproximadamente
- arquitetos
- arquitetônico
- arquitetura
- SOMOS
- por aí
- AS
- Avaliando
- Assistente
- At
- auditadas
- auditores
- aumentado
- automatizar
- Automatizado
- Automático
- automaticamente
- Automação
- disponibilidade
- disponível
- média
- evitar
- AWS
- Backend
- Mau
- Equilíbrio
- baseado
- basic
- BE
- Porque
- tornam-se
- torna-se
- sido
- antes
- ser
- referência
- Benefícios
- MELHOR
- Melhor
- entre
- viés
- vieses
- bilhão
- bilhões
- Preto
- nascido
- pedir emprestado
- ambos
- bots
- Caixa
- caixas
- Ramo
- Quebra
- brevemente
- Trazendo
- Quebrado
- construir
- Prédio
- construído
- negócio
- mas a
- by
- calcular
- chamada
- chamado
- chamada
- CAN
- candidato
- candidatos
- capacidades
- capacidade
- capturar
- casas
- casos
- catálogo
- Categorias
- central
- centralizada
- certo
- desafiar
- desafios
- desafiante
- alterar
- chatbots
- mais barato
- Cheques
- escolha
- escolha
- clássico
- de perto
- mais próximo
- Vestuário
- Na nuvem
- código
- Codificação
- colaborar
- combinação
- combinações
- combinar
- como
- comentários
- comercial
- comercialmente
- comum
- comparar
- comparado
- completar
- realização
- integrações
- complexidade
- compliance
- compatível
- composição
- compreensivo
- poder computacional
- computador
- concentrar
- conceito
- conceitos
- Preocupações
- condições
- Conduzir
- conduzido
- conectado
- da conexão
- Consequentemente
- Considerar
- Considerações
- considerado
- consumir
- consumidor
- Consumidores
- consumo
- Recipiente
- contém
- conteúdo
- Criação de conteúdo
- contexto
- continuar
- ao controle
- conversação
- conversas
- direitos autorais
- Correspondente
- Custo
- dispendioso
- custos
- poderia
- países
- cobrir
- coberto
- crio
- criado
- cria
- Criar
- criação
- crítico
- crucial
- cultural
- Atual
- personalizadas
- cliente
- dados do cliente
- Atendimento ao Cliente
- Clientes
- dados,
- lago data
- Os pontos de dados
- Preparação de dados
- privacidade de dados
- ciência de dados
- banco de dados
- conjuntos de dados
- Descentralizada
- Decidindo
- decisões
- dedicado
- profundo
- mergulho profundo
- deep learning
- definido
- definição
- definição
- definições
- entregar
- mergulhar
- Demanda
- Dependendo
- depende
- retratando
- implantar
- implantado
- Implantação
- desenvolvimento
- descreve
- descrito
- descrição
- Design
- projetado
- concepção
- desejo
- desejado
- detalhado
- detalhes
- Determinar
- determinando
- Dev
- desenvolver
- desenvolvido
- Developer
- desenvolvedores
- em desenvolvimento
- Desenvolvimento
- equipe de desenvolvimento
- diferenças
- diferente
- diferenciar
- dimensões
- diretamente
- discutir
- discutido
- exibido
- distância
- mergulho
- diferente
- do
- INSTITUCIONAIS
- Não faz
- domínio
- domínios
- não
- down
- download
- distância
- dois
- dinâmico
- e
- cada
- Mais cedo
- Leste
- fácil
- Econômico
- editor
- Eficaz
- eficiente
- eficientemente
- esforço
- ou
- elaborada
- eleito
- permitir
- permitindo
- final
- end-to-end
- Ponto final
- energia
- engenheiro
- Engenharia
- Engenheiros
- Inglês
- aumentar
- garantir
- garante
- Empreendimento
- empresas
- Entretenimento
- Meio Ambiente
- ambientes
- igualmente
- especialmente
- essencial
- etc.
- EU
- avaliar
- avaliadas
- avaliação
- Mesmo
- Cada
- exemplo
- exemplos
- excelente
- animado
- Exercício
- existente
- existe
- Exótico
- espera
- caro
- vasta experiência
- experimentar
- experiência
- especialistas
- explorando
- estender
- estendendo
- extensão
- extenso
- Experiência Extensiva
- extensivamente
- extrato
- f1
- Rosto
- fator
- fatores
- Familiaridade
- família
- longe
- mais rápido
- Característica
- retornos
- alimentação
- Figura
- filtro
- filtragem
- final
- Finalmente
- financeiro
- relatório financeiro
- Setor financeiro
- serviços financeiros
- Primeiro nome
- caber
- Flexibilidade
- flexível
- Foco
- focado
- concentra-se
- focando
- seguir
- seguido
- seguinte
- segue
- Escolha
- Para os consumidores
- formulário
- formato
- Foundation
- quatro
- Gratuito
- amigos
- da
- frente
- Front-end
- Frontend
- cheio
- funcionalidade
- fundamental
- mais distante
- Além disso
- futuro
- Portões
- calibre
- Geral
- propósito geral
- geralmente
- gerar
- gerado
- gera
- gerando
- geração
- generativo
- IA generativa
- geopolítica
- ter
- Git
- dado
- dá
- Global
- comércio global
- Bom estado, com sinais de uso
- governo
- GPU
- Solo
- tinha
- mão
- Aproveitamento
- Ter
- ter
- he
- cabeça
- Saúde
- saúde
- ajudar
- ajuda
- SUA PARTICIPAÇÃO FAZ A DIFERENÇA
- Alta
- alta qualidade
- superior
- altamente
- sua
- histórico
- segurar
- hospedeiro
- hospedado
- Como funciona o dobrador de carta de canal
- Como Negociar
- Contudo
- HTML
- HTTPS
- humano
- Centenas
- i
- idealmente
- if
- ilustra
- imagem
- imagens
- imaginário
- Impacto
- executar
- implementação
- implicações
- importância
- importante
- melhorar
- in
- incluir
- inclui
- Incluindo
- incorporar
- Crescimento
- aumentou
- indicam
- indicadores
- Individual
- indústrias
- influência
- influenciado
- Infraestrutura
- do estado inicial,
- inovadores
- entrada
- inputs
- instância
- em vez disso
- instruções
- com seguro
- integrar
- Pretendido
- interagir
- interagindo
- interação
- interage
- Interface
- Internet
- conexão de internet
- internet das coisas
- para dentro
- introduzir
- investir
- envolvido
- envolvendo
- iot
- IT
- ESTÁ
- Trabalho
- viagem
- Viagens
- Julho
- apenas por
- Chave
- fator-chave
- Tipo
- Saber
- Conhecimento
- conhecido
- O rótulo
- Rótulos
- lago
- língua
- grande
- Maior
- Sobrenome
- Latência
- camada
- camadas
- principal
- Leads
- APRENDER
- aprendizagem
- Deixar
- emprestar
- menos
- Nível
- aproveitando
- bibliotecas
- Licença
- Licenciamento
- wifecycwe
- como
- gostos
- limitações
- LINK
- LLM
- carregar
- local
- localizado
- localização
- London
- longo
- mais
- diminuir
- máquina
- aprendizado de máquina
- moldadas
- a Principal
- a manter
- Maioria
- Fazendo
- manejável
- obrigatório
- manual
- manualmente
- fabrica
- muitos
- mapa,
- maciço
- maturidade
- máximo
- Posso..
- me
- significado
- significa
- mecanismo
- mecanismos
- Mídia
- Mediterrânico
- mencionado
- fusão
- malha
- metadados
- método
- Metodologia
- métodos
- Métrica
- Coração
- Médio Oriente
- poder
- mínimo
- ML
- MLOps
- modelo
- modelos
- Monitore
- monitorados
- monitoração
- mais
- mais eficiente
- a maioria
- na maioria das vezes
- Motorsports
- mover
- movido
- movimento
- muito
- múltiplo
- Música
- devo
- my
- nome
- natural
- Processamento de linguagem natural
- Natureza
- Navegar
- necessário
- você merece...
- necessário
- Cria
- negativo
- rede
- rede neural
- Neutro
- nunca
- Novo
- recentemente
- Próximo
- PNL
- não
- normal
- Norte
- notável
- número
- observar
- of
- oferecer
- oferecido
- frequentemente
- on
- Onboarding
- ONE
- queridos
- só
- aberto
- open source
- operando
- Operações
- ideal
- Opção
- Opções
- or
- organização
- organizações
- Outros
- Outros
- de outra forma
- A Nossa
- Fora
- Resultado
- saída
- Acima de
- global
- Visão geral
- próprio
- proprietário
- proprietários
- pacote
- pares
- parâmetros
- padrões
- Pessoas
- para
- Realizar
- atuação
- realização
- possivelmente
- pessoa
- pessoal
- Personalizado
- perspectiva
- fase
- Fotos
- peça
- oleoduto
- Lugar
- plataforma
- platão
- Inteligência de Dados Platão
- PlatãoData
- por favor
- ponto
- pontos
- políticas
- positivo
- possuir
- possível
- Publique
- POSTAGENS
- potencial
- potencialmente
- poder
- poderoso
- Prática
- práticas
- Precisão
- predizer
- predição
- Previsões
- preparação
- Preparar
- preparado
- preparação
- apresentado
- anterior
- anteriormente
- Prime
- primeiro ministro
- princípios
- Prévio
- Priorizar
- política de privacidade
- privado
- Problema
- processo
- processos
- em processamento
- Produzido
- produtor
- Produto
- Produção
- Programação
- projeto
- a promover
- prova
- prova de conceito
- oferece
- proprietário
- Prove
- fornecer
- fornecido
- provedor
- fornecedores
- fornece
- fornecendo
- propósito
- fins
- empurra
- quebra-cabeça
- qualidade
- questão
- Frequentes
- Links
- raises
- alcance
- variando
- rapidamente
- Taxa
- em vez
- classificação
- Leitura
- em tempo real
- razão
- receber
- recomendar
- Vermelho
- Reduzido
- refinar
- em relação a
- registros
- registro
- regulamentos
- relacionado
- liberado
- relevância
- relevante
- confiabilidade
- permanece
- remoto
- substituído
- Denunciar
- repositório
- representação
- representante
- solicitar
- pedidos
- requeridos
- Requisitos
- exige
- pesquisa
- pesquisadores
- Recursos
- respectivamente
- resposta
- respostas
- responsável
- DESCANSO
- restrições
- Restritivo
- resultar
- Resultados
- varejo
- reutilizar
- rever
- Comentários
- equitação
- certo
- roadmap
- Tipo
- papéis
- grosseiramente
- volta
- Execute
- corrida
- sábio
- mesmo
- sandbox
- Escala
- dimensionamento
- cenário
- cenários
- Ciência
- cientistas
- Ponto
- arranhar
- Scripts
- SEA
- Seção
- seções
- setor
- seguro
- firmemente
- segurança
- políticas de segurança
- Vejo
- busca
- selecionado
- selecionando
- doadores,
- envio
- senior
- enviei
- sentimento
- separado
- Seqüência
- Série
- servir
- serviço
- Serviços
- de servir
- conjunto
- vários
- formação
- Partilhar
- compartilhado
- navios
- Baixo
- rede de apoio social
- mostrando
- Shows
- lado
- periodo
- de forma considerável
- semelhante
- simplificar
- Tamanho
- Habilidades
- pequeno
- menor
- PME
- So
- solução
- Soluções
- RESOLVER
- alguns
- fonte
- código fonte
- Fontes
- Espaço
- especial
- especialista
- especializado
- específico
- especificamente
- velocidade
- gastar
- gasto
- Etapa
- Estágio
- partes interessadas
- padrão
- padronização
- começo
- Status
- Passo
- Passos
- loja
- armazenadas
- armazenar
- História
- pontos fortes
- mais forte,
- Subseqüentemente
- bem sucedido
- tal
- sugerir
- aptidão
- adequado
- resumir
- RESUMO
- ajuda
- Suportado
- suposto
- certo
- SWIFT
- .
- mesa
- Tire
- Tarefa
- tarefas
- Profissionais
- equipes
- Dados Técnicos:
- técnicas
- Tecnologias
- Tecnologia
- condições
- teste
- testado
- testadores
- ensaio
- do que
- que
- A
- O Futuro
- A fonte
- do Reino Unido
- o mundo
- deles
- Eles
- si mesmos
- então
- Lá.
- assim sendo
- Este
- deles
- coisas
- Pensando
- De terceiros
- isto
- aqueles
- Apesar?
- pensamento
- milhares
- três
- tempo
- para
- juntos
- token
- Tokens
- topo
- Temas
- para
- comércio
- tradicional
- Trem
- treinado
- Training
- Transformar
- Transformação
- viagens
- viaja
- Trend
- desencadear
- verdadeiro
- Verdade
- tentar
- dois
- tipo
- tipos
- tipicamente
- ui
- Uk
- compreender
- compreensão
- unidade
- unidades
- Atualizações
- Upload
- us
- utilizável
- Uso
- usar
- caso de uso
- usava
- Utilizador
- usuários
- usos
- utilização
- utilitários
- utilizado
- vário
- verificar
- versão
- Contra
- vertical
- via
- viável
- visualizar
- vs
- queremos
- foi
- we
- web
- serviços web
- Site
- BEM
- O Quê
- O que é a
- quando
- enquanto que
- se
- qual
- enquanto
- QUEM
- Largo
- Ampla variedade
- precisarão
- janela
- Windows
- de
- dentro
- sem
- Word
- palavras
- Atividades:
- trabalhar juntos
- trabalhou
- trabalhar
- trabalho
- mundo
- seria
- anos
- Produção
- Vocês
- investimentos
- zefirnet