Fluxos de trabalho do LLMOps no Azure Databricks

Este artigo complementa os fluxos de trabalho do MLOps no Databricks adicionando informações específicas aos fluxos de trabalho do LLMOps. Para mais detalhes, consulte O Grande Livro do MLOps.

Como o fluxo de trabalho do MLOps é alterado para LLMs?

Os LLMs são uma classe de modelos de PLN (processamento de linguagem natural) que superaram significativamente seus predecessores em tamanho e desempenho em uma variedade de tarefas, como resposta às perguntas abertas, resumo e execução de instruções.

O desenvolvimento e a avaliação de LLMs diferem de algumas maneiras importantes dos modelos de ML tradicionais. Esta seção resume brevemente algumas das principais propriedades de LLMs e as implicações para MLOps.

Principais propriedades de LLMs	Implicações para MLOps
Os LLMs estão disponíveis em várias formas. - Modelos proprietários e software de código aberto gerais que são acessados ​​usando APIs pagas. - Modelos de código aberto prontos para uso que variam de aplicativos gerais a específicos. - Modelos personalizados ajustados para aplicativos específicos. - Aplicativos pré-treinados personalizados.	Processo de desenvolvimento: os projetos geralmente se desenvolvem incrementalmente, começando por modelos existentes, de terceiros ou de código aberto e terminando com modelos personalizados ajustados.
Muitos LLMs usam consultas e instruções gerais de linguagem natural como entrada. Essas consultas podem conter prompts cuidadosamente elaborados para obter as respostas desejadas.	Processo de desenvolvimento: criar modelos de texto para consultar LLMs geralmente é uma parte importante do desenvolvimento de novos pipelines de LLM. Empacotamento de artefatos de ML: muitos pipelines de LLM usam LLMs existentes ou pontos de existentes de serviço de LLM. A lógica de ML desenvolvida para esses pipelines pode se concentrar em modelos de prompt, agentes ou cadeias em vez do próprio modelo. Os artefatos de ML empacotados 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 de LLM com contexto, você pode usar ferramentas adicionais, como bancos de dados de vetor, para pesquisar contexto relevante.
As APIs de terceiros fornecem modelos proprietários e de código aberto.	Governança de API: o uso da governança de API centralizada fornece a capacidade de alternar facilmente entre provedores de API.
Os LLMs são modelos de aprendizado profundo muito grandes, muitas vezes variando de gigabytes a centenas de gigabytes.	Infraestrutura de serviço: os LLMs podem exigir GPUs para serviço de modelo em tempo real e armazenamento rápido para modelos que precisam ser carregados dinamicamente. Compensações de custo/desempenho: como os modelos maiores exigem mais computação e são mais caros, 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 de ML tradicionais, pois muitas vezes não há uma única resposta "certa".	Comentários humanos: os comentários humanos são essenciais para avaliar e testar os LLMs. Você deve incorporar comentários do usuário diretamente no processo do MLOps, incluindo para teste, monitoramento e ajustes futuros.

Pontos em comum entre MLOps e LLMOps

Muitos aspectos dos processos de MLOps não são alterados para LLMs. Por exemplo, as diretrizes a seguir também se aplicam a LLMs:

• Use ambientes separados para desenvolvimento, preparo e produção.
• Usar GIT para controle de versão.
• Gerencie o desenvolvimento de modelos com o MLflow e use Modelos no Catálogo do Unity para gerenciar o ciclo de vida do modelo.
• Armazene dados em uma arquitetura do 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 definição de recursos, treinamento de modelo, inferência de modelo 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 do MLOps tradicional. Os diagramas mostram a arquitetura de produção para 1) um aplicativo RAG (geração aumentada de recuperação) usando uma API de terceiros e 2) um aplicativo RAG usando um modelo ajustado auto-hospedado. Ambos os diagramas mostram um banco de dados de vetor opcional – esse item pode ser substituído consultando diretamente o LLM por meio do ponto de extremidade deo Serviço de Modelo.

RAG com uma API de LLM de terceiros

O diagrama mostra uma arquitetura de produção para um aplicativo RAG que se conecta a uma API de LLM de terceiros usando modelos externos do 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 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 de LLM geralmente usam modelos existentes e pré-treinados selecionados de um hub de modelos interno ou externo. O modelo pode ser usado como está ou ajustado.

O Databricks inclui uma seleção de modelos de base pré-treinados e de alta qualidade no Catálogo do Unity e no Databricks Marketplace. Você pode usar esses modelos pré-treinados para acessar recursos de IA de última geração, economizando tempo e custos de criação de seus próprios modelos personalizados. Para obter detalhes, confira Modelos pré-treinados no Catálogo do Unity e no Marketplace.

Banco de dados vetoriais

Alguns aplicativos de LLM usam bancos de dados de vetor 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 busca em vetores integrada que permite que você use qualquer tabela Delta no Catálogo do Unity como um banco de dados de vetor. O índice de busca em vetores é sincronizado automaticamente com a tabela Delta. Para obter detalhes, confira Busca em Vetores.

Você pode criar um artefato de modelo que encapsula a lógica para recuperar informações de um banco de dados de vetor e fornece os dados retornados como contexto para o LLM. Em seguida, você pode registrar o modelo usando o modelo MLflow LangChain ou PyFunc.

Ajuste de LLM

Como os modelos de LLM são caros e demorados para criar 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 e a implantação de modelo são representados como Trabalhos do Databricks distintos. Validar um modelo ajustado antes da implantação geralmente é um processo manual.

O Databricks fornece o ajuste fino do modelo de base, que permite usar seus próprios dados para personalizar um LLM existente para otimizar seu desempenho para seu aplicativo específico. Para obter detalhes, consulte Ajuste fino do modelo de fundação.

Serviço de modelo

No RAG usando um cenário de API de terceiros, uma alteração de arquitetura importante é que o pipeline de LLM faz chamadas de API externas, desde o ponto de extremidade do Serviço de Modelo até as APIs de LLM internas ou de terceiros. Isso adiciona complexidade, latência potencial e gerenciamento de credenciais adicionais.

O Databricks fornece o Serviço de Modelo de IA do Mosaic, que fornece uma interface unificada para implantar, governar e consultar modelos de IA. Para obter detalhes, confira Serviço de Modelo de IA do Mosaic.

Comentários humanos no monitoramento e avaliação

Os loops de comentários humanos são essenciais na maioria dos aplicativos de LLM. Os comentários humanos devem ser gerenciados como outros dados, apropriadamente incorporados ao monitoramento com base no streaming quase em tempo real.

O aplicativo de revisão do Mosaic AI Agent Framework ajuda você a coletar comentários de revisores humanos. Para obter detalhes, confira Obter feedback sobre a qualidade de um aplicativo agenciado.