Google
Cloud Platform
Amazon Web Services
Microsoft AzureLLMOps fluxo de trabalho on Databricks
Este artigo complementa o MLOps fluxo de trabalho em Databricks, acrescentando informações específicas ao LLMOps fluxo de trabalho. Para obter mais detalhes, consulte The Big Book of MLOps.
Como o fluxo de trabalho do MLOps muda para os LLMs?
Os LLMs são uma classe de modelos de processamento de linguagem natural (NLP) que superaram significativamente seus antecessores em tamanho e desempenho em uma variedade de tarefas, como resposta a perguntas abertas, resumo e execução de instruções.
O desenvolvimento e a avaliação dos LLMs diferem em alguns aspectos importantes dos modelos tradicionais de ML. Esta seção resume brevemente algumas das propriedades key dos LLMs e as implicações para MLOps.
key propriedades dos LLMs |
Implicações para os MLOps |
|---|---|
Os LLMs estão disponíveis em várias formas.
|
Processo de desenvolvimento: Os projetos geralmente são desenvolvidos de forma incremental, começando com modelos existentes, de terceiros ou de código aberto e terminando com modelos personalizados e ajustados. |
Muitos LLMs aceitam consultas e instruções gerais em linguagem natural como entrada. Essas consultas podem conter prompts cuidadosamente projetados para obter as respostas desejadas. |
Processo de desenvolvimento: A criação de um padrão de texto para consulta de LLMs costuma ser uma parte importante do desenvolvimento do novo pipeline LLM. Empacotamento de artefatos ML: Muitos pipelines do LLM usam LLMs existentes ou endpoints de atendimento do LLM. A lógica do ML desenvolvida para esses pipelines pode se concentrar em padrões, agentes ou cadeias rápidas em vez do próprio modelo. Os artefatos do ML pacote e promovidos à produção podem ser esses pipelines, em vez de modelos. |
Muitos LLMs podem receber prompts com exemplos, contexto ou outras informações para ajudar a responder à consulta. |
Infraestrutura de serviço: Ao aumentar as consultas LLM com contexto, o senhor pode usar ferramentas adicionais, como bancos de dados vetoriais, para pesquisar o contexto relevante. |
As APIs de terceiros fornecem modelos proprietários e de código aberto. |
Governança de API: O uso da governança centralizada de API permite alternar facilmente entre os provedores de API. |
Os LLMs são modelos de aprendizagem profunda muito grandes, geralmente variando de gigabytes a centenas de gigabytes. |
Infraestrutura de serviço: Os LLMs podem exigir GPUs para servir modelos em tempo real e armazenamento rápido para modelos que precisam ser carregados dinamicamente. Compensações de custo/desempenho: Como modelos maiores exigem mais computação e são mais caros para servir, podem ser necessárias técnicas para reduzir o tamanho do modelo e a computação. |
Os LLMs são difíceis de avaliar usando métricas tradicionais de ML, pois geralmente não há uma única resposta "certa". |
Feedback humano: O feedback humano é essencial para avaliar e testar os LLMs. O senhor deve incorporar o feedback do usuário diretamente no processo de MLOps, inclusive para testes, monitoramento e ajustes futuros. |
Pontos em comum entre MLOps e LLMOps
Muitos aspectos dos processos de MLOps não mudam para os LLMs. Por exemplo, as seguintes diretrizes também se aplicam aos LLMs:
Use ambientes separados para desenvolvimento, preparação e produção.
Use o Git para controle de versão.
Gerenciar o desenvolvimento de modelos com MLflow e usar Models in Unity Catalog para gerenciar o ciclo de vida do modelo.
Armazene dados em uma arquitetura lakehouse usando tabelas Delta.
Sua infraestrutura de CI/CD existente não deve exigir nenhuma alteração.
A estrutura modular do MLOps continua a mesma, com pipeline para caracterização, treinamento de modelos, inferência de modelos e assim por diante.
Diagramas de arquitetura de referência
Esta seção usa dois aplicativos baseados em LLM para ilustrar alguns dos ajustes na arquitetura de referência dos MLOps tradicionais. Os diagramas mostram a arquitetura de produção para 1) um aplicativo de geração aumentada de recuperação (RAG) usando uma API de terceiros e 2) um aplicativo RAG usando um modelo de ajuste fino auto-hospedado. Ambos os diagramas mostram um banco de dados vetorial opcional - esse item pode ser substituído pela consulta direta ao site LLM por meio do modelo servindo endpoint.
Alterações do LLMOps na arquitetura de produção do MLOps
Esta seção destaca as principais alterações na arquitetura de referência do MLOps para aplicativos LLMOps.
Cubo do modelo
Os aplicativos LLM geralmente usam modelos pré-treinados existentes, selecionados de um hub de modelos interno ou externo. O modelo pode ser usado como está ou ajustado.
Banco de dados vetorial
Alguns aplicativos de LLM usam bancos de dados de vetores para pesquisas rápidas de similaridade, por exemplo, para fornecer contexto ou conhecimento de domínio em consultas de LLM.
O senhor pode criar um artefato de modelo que encapsula a lógica para recuperar informações de um banco de dados vetorial e fornece os dados retornados como contexto para o site LLM. O senhor pode então log o modelo usando o MLflow LangChain ou o modelo PyFunc.
Ajuste fino do LLM
Como os modelos de LLM são caros e demorados para serem criados do zero, os aplicativos de LLM geralmente ajustam um modelo existente para melhorar seu desempenho em um cenário específico. Na arquitetura de referência, o ajuste fino e a implementação do modelo são representados como trabalhos distintos do Databricks. A validação de um modelo ajustado antes de ser implantado geralmente é um processo manual.
Servindo modelo
No RAG usando um cenário API de terceiros, uma mudança arquitetônica importante é que o LLM pipeline faz chamadas externas API, do modelo servindo endpoint para o LLM APIs interno ou de terceiros. Isso aumenta a complexidade, a possível latência e o gerenciamento adicional de credenciais.