LLMOps 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.
principais 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 de linguagem natural como entrada. Essas consultas podem conter solicitações cuidadosamente projetadas 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 índices 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 da 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 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 diretrizes a seguir 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.
RAG com uma API LLM de terceiros
O diagrama mostra uma arquitetura de produção para um aplicativo RAG que se conecta a uma API LLM de terceiros usando Databricks External Models.
RAG com um modelo de código aberto ajustado
O diagrama mostra uma arquitetura de produção para um aplicativo RAG que faz o ajuste fino de um modelo de código aberto.
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.
Hub de modelos
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.
Índice vetorial
Alguns aplicativos LLM usam índices vetoriais para pesquisas rápidas de similaridade, por exemplo, para fornecer contexto ou conhecimento de domínio em consultas LLM. O Databricks fornece uma funcionalidade de pesquisa de AI integrada que permite usar qualquer tabela Delta no Unity Catalog como um índice. O índice de pesquisa AI é sincronizado automaticamente com a tabela Delta. Para obter detalhes, consulte Pesquisa de AI.
É possível criar um artefato de modelo que encapsule a lógica para recuperar informação de um índice de Pesquisa de AI e forneça os dados retornados como contexto ao LLM. O modelo pode então ser registrado usando a variante de modelo MLflow LangChain ou 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 no site LakeFlow. 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 adiciona complexidade, latência potencial e gerenciamento adicional de credenciais.
Feedback humano no monitoramento e na avaliação
Os loops de feedback humano são essenciais na maioria dos aplicativos LLM. O feedback humano deve ser gerenciado como outros dados, idealmente incorporado ao monitoramento com base na transmissão em tempo quase real.
O aplicativo de revisão do MLflow ajuda você a coletar feedback de revisores humanos. Para obter detalhes, consulte Coletar feedback e criar datasets.