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 sugestões cuidadosamente projetadas para induzir 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 artefactos de ML: Muitos pipelines LLM usam LLMs existentes ou endpoints 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 que são embalados e destinados à produção podem ser estas 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 Modelos no Unity Catalog para gerenciar o ciclo de vida do modelo.
• Armazene dados numa arquitetura de 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 ao consultar diretamente o LLM através do endpoint 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 afinado

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.

Centro de Modelos

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, veja Modelos pré-treinados no Unity Catalog e no 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.

Aperfeiçoar o Modelo de Linguagem de Grande Escala (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.

O Databricks fornece o ajuste fino do modelo básico, que permite que você use seus próprios dados para personalizar um LLM existente para otimizar seu desempenho para seu aplicativo específico. Para obter detalhes, consulte Afinação de Modelos de Fundação.

Serviço de Modelo

No RAG, ao usar um cenário de API de terceiros, uma alteração importante na arquitetura é que o pipeline LLM faz chamadas externas de API, desde o endpoint de Model Serving até às 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 incorporado na monitorização com base em transmissão em tempo quase real.

O aplicativo de revisão do Mosaic AI Agent Framework ajuda você a coletar feedback de revisores humanos. Para obter detalhes, consulte Usar o aplicativo de revisão para avaliações humanas de um aplicativo de IA de geração.