Do inglês ao SQL: Oracle APEX AI preenche a lacuna linguística
21 de junho de 2024Torne os desenvolvedores autônomos com as ferramentas de autoatendimento Kafka
22 de junho de 2024O casamento entre práticas de aprendizado de máquina e DevOps deu origem ao MLOps, um campo especializado focado na automatização do desenvolvimento, implantação e gerenciamento de modelos de ML em ambientes de produção. No entanto, um grande obstáculo para alcançar fluxos de trabalho de MLOps simplificados reside na separação tradicional entre DevOps e pipelines de aprendizado de máquina.
Este artigo explora o KitOps, um projeto de código aberto que preenche essa lacuna, permitindo que você aproveite seus pipelines de DevOps existentes para tarefas de MLOps por meio do uso de ModelKits. Um breve passo a passo e um exemplo de código no artigo demonstrarão como é fácil começar.
O gargalo dos fluxos de trabalho separados
A construção e implantação de aplicativos tradicionais normalmente segue um pipeline de DevOps bem definido. O código passa por controle de versão, testes automatizados e integração e entrega perfeitas. DevOps é uma prática aceita e comprovada para implantação de sistemas em escala. No entanto, os projetos de ML introduzem novas complexidades. Os modelos requerem conjuntos de dados, ambientes de treinamento, configurações e ferramentas de monitoramento específicos. Os cientistas de dados podem usar notebooks Jupyter e iterar no refinamento do modelo. Construir pipelines MLOps separados para gerenciar esses aspectos junto com pipelines DevOps existentes leva a várias ineficiências:
- Esforços sobrepostos: Manter pipelines separados significa duplicar esforços para tarefas como controle de versão, implantação e gerenciamento de configuração. Imagine gerenciar um pipeline DevOps para código de aplicativo e um pipeline MLOps separado para o modelo treinado, suas dependências e arquivos de configuração. Essa redundância aumenta a sobrecarga e introduz possíveis inconsistências entre os pipelines.
- Equipes isoladas: Pipelines separados podem levar a um ambiente de desenvolvimento isolado, onde os engenheiros de DevOps e ML trabalham isoladamente. A colaboração fica fragmentada, dificultando a comunicação e atrasando as implantações. Os cientistas de dados podem ter dificuldade para compreender as complexidades de implantação, enquanto os engenheiros de DevOps podem não ter conhecimento das necessidades específicas de trabalhar com modelos de ML.
- Curvas de aprendizagem mais acentuadas: A manutenção de pipelines MLOps diferentes exige que os engenheiros aprendam e gerenciem um conjunto mais amplo de ferramentas, aumentando a curva de aprendizado e atrasando a adoção do projeto devido às ineficiências nas operações. Isto pode ser uma barreira significativa para organizações novas no ML, retardando a sua capacidade de aproveitar o seu potencial.
Entre no KitOps: unificando o desenvolvimento com ModelKits
KitOps oferece uma solução elegante para essas discrepâncias, introduzindo o conceito de ModelKits. ModelKits são pacotes padronizados que encapsulam todos os componentes críticos de um projeto de ML:
- Modelo: O próprio modelo de ML treinado, normalmente salvo em um formato como pickle ou joblib como exemplos.
- Conjuntos de dados: Os dados usados para treinamento e potencialmente para teste e validação. Dependendo do tamanho do modelo e das considerações de privacidade de dados, os conjuntos de dados podem ser incluídos no ModelKit ou referenciados como locais externos.
- Código: O código-fonte usado para treinamento, pré-processamento dos dados e potencialmente servir o modelo para previsões. Isso pode incluir scripts Python para treinamento, manipulação de dados e inferência de modelos.
- Configuração: Arquivos de configuração para o ambiente do modelo, incluindo dependências (bibliotecas, estruturas), configurações de implantação (variáveis de ambiente) e configurações potencialmente de serviço (configurações de servidor, endpoints de API).
ModelKits são construídos usando um arquivo YAML chamado Kitfile, que define a localização de cada componente. Os Kitfiles estão em um formato familiar e flexível. Essa padronização permite que o KitOps se integre perfeitamente aos pipelines DevOps existentes, como um Dockerfile para conteinerização. Na verdade, os Modelkits são até compatíveis com OCI (consulte Open Container Initiative).
Este é um rápido instantâneo da aparência de um Kitfile de amostra:
manifestVersion: 1.0 package: name: AIProjectName version: 1.2.3 description: >- A brief description of the AI/ML project. authors: (Author Name, Contributor Name) code: - path: src/ description: Source code for the AI models. license: Apache-2.0 datasets: - name: DatasetName path: data/dataset.csv description: Description of the dataset. license: CC-BY-4.0 preprocessing: Preprocessing steps. model: name: ModelName path: models/model.h5 framework: TensorFlow version: 1.0 description: Model description. license: Apache-2.0 training: dataset: DatasetName parameters: learning_rate: 0.001 epochs: 100 batch_size: 32 validation: - dataset: DatasetName metrics: accuracy: 0.95 f1_score: 0.94
(De: kitops.ml/docs/kitfile/format.html#example)
O fluxo de trabalho de alto nível
Aqui está um detalhamento do fluxo de trabalho para usar ModelKits com KitOps:
- Pacote como kit de modelo: Os cientistas de dados podem usar a CLI do KitOps para empacotar todos os componentes do projeto em um ModelKit. O Kitfile define a estrutura e simplifica o controle de versão para todo o pacote. Isso garante que todos os elementos necessários para implantar e usar o modelo sejam agrupados. A marcação é um recurso integrado que ajuda a organizar os ModelKits em um repositório por meio de tags que podem ser referenciadas.
- Controle de versão e CI/CD: O ModelKit é controlado por versão em um repositório junto com o código da aplicação, garantindo um fluxo de desenvolvimento unificado. O pipeline de CI/CD (integração contínua e entrega contínua) existente em seu ecossistema DevOps capta alterações e aciona compilações e implantações. Isso aproveita sua infraestrutura existente para gerenciar alterações e implantações de código, agilizando o processo.
- Implantação com ferramentas existentes: KitOps funciona bem com tecnologias de conteinerização existentes, como Docker, para implantação de ModelKits. Isso permite que os SREs, por exemplo, usem ferramentas DevOps familiares para implantação em ambientes de produção como Kubernetes. A abordagem em contêiner garante um ambiente de implantação consistente e portátil, que se integrará bem com ferramentas de pipeline DevOps CI/CD, como Jenkins, GitLab, CircleCI, GitHub Actions e Azure DevOps.
Experimentando a CLI do KitOps
Agora que cobrimos os pontos principais do que é KitOps, vamos fazer uma abordagem prática para explorar alguns dos recursos e o uso da CLI no terminal de sua escolha. Para começar, existem duas opções. A primeira opção é clonar o repositório KitOps e construir o binário, assim:
git clone https://github.com/jozu-ai/kitops.git cd kitops go build -o kit
A segunda opção é simplesmente baixar o binário pré-construído para sua arquitetura aqui e extrair o arquivo compactado. Por exemplo:
curl -OL https://github.com/jozu-ai/kitops/releases/download/v0.2.4/kitops-darwin-arm64.zip unzip kitops-darwin-arm64.zip
Qualquer que seja a opção escolhida, mova o binário do kit para um local em seu PATH para que você possa emitir comandos. Este é um exemplo para Mac ou Linux:
sudo mv kit /usr/local/bin
A seguir, verifique a versão do kit do terminal para ver se está funcionando corretamente.
kit version
Você deverá ver uma saída como esta:
Version: 0.2.4-76ec9bc Commit: 76ec9bcf94e94177199522480871367138661125 Built: 2024-05-10T21:53:18Z Go version: go1.21.6
Existem vários comandos disponíveis com o KitOps CLI. Para este passo a passo, primeiro vamos nos aprofundar e descobrir quais Modelkits estão disponíveis em um repositório conhecido para modelos Llama 3:
kit list ghcr.io/jozu-ai/llama3
Vemos que existem vários ModelKits com várias tags:
REPOSITORY TAG MAINTAINER NAME SIZE DIGEST jozu-ai/llama3 8B-instruct-f16 Meta Platforms llama3 11.4 GiB sha256:995b9e0f87ddcdcaa59803a08986409b6e4cf2f8b071b064bca21e4e801566a3 jozu-ai/llama3 8B-text-f16 Meta Platforms llama3 11.4 GiB sha256:6b5b4a82ba3a73f00248b4431db738217e1978e316b2d4514b1bb887a11a0d84 jozu-ai/llama3 8B-instruct-q4_0 Meta Platforms llama3 4.1 GiB sha256:ccf9fb3d541c45a65dd99c7272a061776b8cb04d7635a5f844951b410b8ec2a7 ...
Vejamos um dos ModelKits com mais detalhes referenciando a tag e usando o comando info:
kit info --remote ghcr.io/jozu-ai/llama3:8B-instruct-q4_0
Aqui obtemos mais informações sobre o Modelkit, essencialmente o que foi definido no Kitfile.
manifestVersion: "1.0" package: name: llama3 version: 3.0.0 description: Llama 3 family of large language models (LLMs), a collection of pretrained and instruction tuned generative text models in 8 and 70B sizes. authors: (Meta Platforms, Inc.) model: name: llama3-8B-instruct-q4_0 path: ./llama3-8B-instruct-q4_0.gguf description: Llama 3 8B instruct model ...
A partir daqui, podemos descompactar o Modelkit do local remoto para o nosso sistema local para trabalhar com ele.
kit unpack ghcr.io/jozu-ai/llama3:8B-instruct-q4_0 -d ./unpacked ls ./unpacked
Observe os arquivos contidos no Modelkit, incluindo o próprio modelo. Neste ponto, vamos escrever um pequeno script Python para interagir com o modelo, verificando se obtemos uma resposta adequada de um determinado prompt. Crie um arquivo chamado prompt.py e certifique-se de ter a biblioteca llama_cpp instalada via pip.
import llama_cpp model_file = "llama3-8B-instruct-q4_0.gguf" prompt = "Hello, what model are you?" model = llama_cpp.Llama( model_path = model_file, verbose = False ) out = model.create_chat_completion( messages = ({"role": "user", "content": prompt}) ) print("===") print(prompt) print("---") print(out("choices")(0)("message")("content"))
A execução deste script produzirá a seguinte saída, mas pode ser um pouco diferente a cada vez.
python3 prompt.py === Hello, what model are you? --- I'm LLaMA, an AI chatbot developed by Meta AI that can understand and respond to human input in a conversational manner. I'm a large language model trained on a massive dataset of text from the internet, which allows me to generate human-like responses to a wide range of topics and questions. I'm constantly learning and improving my abilities based on the conversations I have with users like you!
A partir daqui, você pode decidir incluir este script no Modelkit adicionando-o ao Kitfile e, em seguida, usando o comando pack da CLI do KitOps para empacotar e marcar a nova versão. Isso poderia então ser comprometido com o repo. As possibilidades são inúmeras dependendo do fluxo que você pretende alcançar.
Nota rápida: Outra maneira simples de solicitar o modelo no Modelkit acima é usando o comando dev da CLI do KitOps. Isso abre uma interface simples de bate-papo baseada na web.
kit dev start
O chat pode então ser acessado em uma janela do navegador:
Para desligá-lo, basta digitar:
kit dev stop
Mais para descompactar
Como você pode ver no passo a passo acima, o KitOps torna o fluxo de trabalho do MLOps claro e direto. Ao unificar pipelines de DevOps e MLOps com KitOps, as equipes podem colher vários benefícios:
- Complexidade reduzida: Um único pipeline simplifica o processo de desenvolvimento, reduzindo despesas gerais e agilizando a colaboração entre equipes. Os engenheiros de DevOps e ML trabalham na mesma estrutura, promovendo melhor comunicação e compreensão.
- Tempo de lançamento no mercado mais rápido: Aproveitar as ferramentas e a infraestrutura DevOps existentes acelera as implantações e melhora a velocidade geral de entrega do projeto. Não há necessidade de aprender e gerenciar ferramentas MLOps separadas, permitindo que as equipes se concentrem na construção e melhoria do próprio modelo.
- Consistência Melhorada: Um pipeline unificado garante controle de versão e gerenciamento de configuração consistentes em todo o ciclo de vida do aplicativo e do modelo de ML. Isto reduz o risco de erros e inconsistências que podem surgir do gerenciamento de pipelines separados.
- Controle de versão e reversões de modelo: ModelKits são controlados por versão junto com o código do aplicativo. Isso permite rastrear alterações no modelo e suas dependências, facilitando reversões para versões anteriores, se necessário. Imagine encontrar um problema com um modelo recém-implantado. Com o controle de versão, você pode reverter facilmente para uma versão estável anterior usando seu pipeline de CI/CD existente.
- Teste A/B e experimentação: KitOps permite testes A/B contínuos de diferentes versões de modelos. Ao implantar vários ModelKits com modelos diferentes, você pode comparar o desempenho deles em um subconjunto do seu tráfego. Isso permite a tomada de decisões baseada em dados ao escolher o melhor modelo para implantação em produção.
- Governança e explicabilidade do modelo: O Kitfile pode ser usado para documentar a finalidade do modelo, os dados de treinamento usados e quaisquer metadados relevantes. Isto facilita a governança do modelo, fornecendo um local central para informações críticas para fins de auditoria e conformidade. Além disso, o KitOps pode ser integrado a ferramentas de explicabilidade do modelo para ajudar a compreender o processo de tomada de decisão do modelo.
Resumindo tudo
A separação dos pipelines DevOps e MLOps pode dificultar o desenvolvimento e a implantação eficientes de modelos de ML. KitOps oferece uma solução atraente de código aberto ao apresentar ModelKits, pacotes padronizados que encapsulam todos os componentes críticos de um projeto de ML. Isso permite que as organizações aproveitem seus pipelines e ferramentas DevOps existentes para tarefas de MLOps, levando à redução da complexidade, ao tempo de lançamento no mercado mais rápido, à consistência aprimorada e ao rastreamento simplificado durante todo o ciclo de vida do modelo de ML. À medida que o campo dos MLOps continua a evoluir, o KitOps apresenta uma abordagem poderosa para unificar o desenvolvimento e acelerar a adoção de soluções de machine learning. Confira o site KitOps para saber mais.
A postagem KitOps é a ferramenta de código aberto que transforma pipelines DevOps em pipelines MLOps apareceu pela primeira vez em The New Stack.