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.

key propriedades dos LLMs	Implicações para os MLOps
Os LLMs estão disponíveis em várias formas. Modelos gerais proprietários e OSS que são acessados por meio de APIs pagas. Modelos de código aberto prontos para uso que variam de aplicativos gerais a específicos. Modelos personalizados que foram ajustados para aplicações específicas. Aplicativos personalizados pré-treinados.	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.

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.

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.

A Databricks inclui uma seleção de modelos básicos pré-treinados de alta qualidade no Unity Catalog e no Databricks Marketplace. O senhor pode usar esses modelos pré-treinados para acessar recursos de IA de última geração, economizando o tempo e as despesas de criar seus próprios modelos personalizados. Para obter detalhes, consulte Modelos pré-treinados em Unity Catalog e marketplace.

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 Databricks oferece uma funcionalidade de pesquisa vetorial integrada que permite que o senhor use 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 Vector Search.

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.

Databricks fornece o Mosaic AI Model treinamento, que permite que o senhor use seus próprios dados para personalizar um LLM existente e otimizar seu desempenho para sua aplicação específica. Para obter detalhes, consulte Mosaic AI Model treinamento.

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.

Databricks fornece Mosaic AI Model Serving, que oferece uma interface unificada para implantar, governar e consultar modelos de AI. Para obter detalhes, consulte Mosaic AI Model Serving.

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 Mosaic AI Agent Framework ajuda o senhor a obter feedback de revisores humanos. Para obter detalhes, consulte Obter feedback sobre a qualidade de um aplicativo agêntico.