Fluxos de trabalho LLMOps no Azure Databricks
Este artigo complementa fluxos de trabalho MLOps em Databricks adicionando informações específicas aos fluxos de trabalho LLMOps. Para obter mais detalhes, consulte O Grande Livro dos MLOps.
Como o fluxo de trabalho MLOps muda para LLMs?
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, sumarização e execução de instruções.
O desenvolvimento e a avaliação de LLMs diferem em alguns aspetos importantes dos modelos tradicionais de ML. Esta seção resume brevemente algumas das principais propriedades dos LLMs e as implicações para MLOps.
| Principais propriedades dos LLMs | Implicações para MLOps |
|---|---|
| Os LLMs estão disponíveis em muitas formas. * Modelos proprietários e OSS gerais que são acessados usando APIs pagas. * Modelos de código aberto prontos para uso que variam de aplicações gerais a específicas. * Modelos personalizados que foram ajustados para aplicações específicas. * Aplicações pré-treinadas personalizadas. |
Processo de desenvolvimento: Os projetos geralmente se desenvolvem de forma incremental, começando com modelos existentes, de terceiros ou de código aberto e terminando com modelos personalizados ajustados. |
| Muitos LLMs tomam consultas e instruções gerais de linguagem natural como entrada. Essas consultas podem conter prompts cuidadosamente projetados para obter as respostas desejadas. | Processo de desenvolvimento: Projetar modelos de texto para consultar LLMs é muitas vezes uma parte importante do desenvolvimento de novos pipelines LLM. Empacotamento de artefatos de ML: Muitos pipelines LLM usam LLMs existentes ou pontos de extremidade de serviço LLM. A lógica de ML desenvolvida para esses pipelines pode se concentrar em modelos de prompt, agentes ou cadeias em vez do modelo em si. Os artefatos de ML embalados 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. | Servindo a infraestrutura: ao aumentar as consultas LLM com contexto, você pode usar ferramentas adicionais, como bancos de dados vetoriais, para pesquisar o contexto relevante. |
| APIs de terceiros fornecem modelos proprietários e de código aberto. | Governança de API: o uso de governança de API centralizada oferece a capacidade de alternar facilmente entre provedores de API. |
| LLMs são modelos de aprendizagem profunda muito grandes, muitas vezes 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 de servir, técnicas para reduzir o tamanho do modelo e a computação podem ser necessárias. |
| Os LLMs são difíceis de avaliar usando métricas tradicionais de ML, uma vez que muitas vezes não há uma única resposta "certa". | Feedback humano: O feedback humano é essencial para avaliar e testar LLMs. Você deve incorporar os comentários dos usuários diretamente no processo de MLOps, inclusive para testes, monitoramento e ajustes finos futuros. |
Semelhanças entre MLOps e LLMOps
Muitos aspetos dos processos MLOps não mudam para 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.
- Gerencie o desenvolvimento de modelos com MLflow e use 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 alterações.
- A estrutura modular do MLOps permanece a mesma, com pipelines para featurizaçã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 ajustado auto-hospedado. Ambos os diagramas mostram um banco de dados vetorial opcional — este item pode ser substituído consultando diretamente o LLM por meio do ponto de extremidade de serviço de modelo.
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 modelos externos Databricks.
RAG com um modelo de código aberto ajustado
O diagrama mostra uma arquitetura de produção para um aplicativo RAG que ajusta um modelo de código aberto.
Alterações de LLMOps na arquitetura de produção MLOps
Esta seção destaca as principais alterações na arquitetura de referência MLOps para aplicativos LLMOps.
Hub do modelo
Os aplicativos LLM geralmente usam modelos existentes e pré-treinados selecionados de um hub de modelo interno ou externo. O modelo pode ser usado no estado em que se encontra ou ajustado.
O Databricks inclui uma seleção de modelos de fundação pré-treinados e de alta qualidade no Unity Catalog e no Databricks Marketplace. Você pode usar esses modelos pré-treinados para acessar recursos de IA de última geração, economizando tempo e despesas para criar seus próprios modelos personalizados. Para obter detalhes, consulte Modelos pré-treinados no Unity Catalog and Marketplace.
Banco de dados vetorial
Alguns aplicativos LLM usam bancos de dados vetoriais para pesquisas rápidas de similaridade, por exemplo, para fornecer conhecimento de contexto ou domínio em consultas LLM. O Databricks fornece uma funcionalidade de pesquisa vetorial integrada que permite usar qualquer tabela Delta no Unity Catalog como um banco de dados vetorial. O índice de pesquisa vetorial é sincronizado automaticamente com a tabela Delta. Para obter detalhes, consulte Pesquisa vetorial.
Você 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 LLM. Em seguida, você pode registrar o modelo usando o modelo MLflow LangChain ou PyFunc flavor.
Ajuste fino LLM
Como os modelos LLM são caros e demorados para serem criados do zero, os aplicativos 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 implantação do modelo são representados como trabalhos distintos do Databricks. Validar um modelo ajustado antes da implantação geralmente é um processo manual.
A Databricks fornece o Mosaic AI Model Training, que permite que você use seus próprios dados para personalizar um LLM existente para otimizar seu desempenho para sua aplicação específica. Para obter detalhes, consulte Treinamento de modelo de IA em mosaico.
Modelo de serviço
No RAG usando um cenário de API de terceiros, uma alteração importante na arquitetura é que o pipeline LLM faz chamadas de API externas, do ponto de extremidade Model Serving para APIs LLM internas ou de terceiros. Isso adiciona complexidade, latência potencial e gerenciamento adicional de credenciais.
O Databricks fornece o Mosaic AI Model Serving, que fornece uma interface unificada para implantar, governar e consultar modelos de IA. Para obter detalhes, consulte Mosaic AI Model Serving.
Feedback humano na monitorização e avaliação
Os ciclos de feedback humano são essenciais na maioria das aplicações LLM. O feedback humano deve ser gerido como outros dados, idealmente incorporados na monitorização com base em streaming quase em tempo real.
O aplicativo de revisão do Mosaic AI Agent Framework ajuda você a coletar feedback de revisores humanos. Para obter detalhes, consulte Obter feedback sobre a qualidade de um aplicativo agentic.