MLOps vs LLMOps: diferenças e primeiros passos em produção

Na comparação MLOps vs LLMOps, o ponto de partida para uma equipe de 3 pessoas que adota LLMOps é uma versão identificável da aplicação, uma avaliação que condicione a liberação, um trace que possa ser inspecionado e um rollback que possa ser executado. Acrescente roteamento, controles de gastos e guardrails a esse ciclo; invista em mais infraestrutura quando uma falha específica ou um problema de coordenação exigir.

O que você opera é a funcionalidade que chega ao cliente. Um assistente de atendimento pode dar uma resposta fluente enquanto busca o registro de outro cliente, aciona a ferramenta errada ou esgota o limite de novas tentativas. A disponibilidade do endpoint do modelo não diz se essa funcionalidade está funcionando.

Os recursos dos produtos e as orientações sobre dependências abaixo foram verificados na documentação oficial disponível em 23 de outubro de 2026. Os tamanhos de equipe e o exemplo de avaliação são cenários de planejamento, não limites dos fornecedores nem resultados medidos em produção.

O que é LLMOps?

LLMOps torna as mudanças em uma aplicação baseada em um grande modelo de linguagem observáveis, testáveis e reversíveis. A sigla vem de large language model operations, ou operações de grandes modelos de linguagem. Seu escopo inclui prompts, versões de modelos, avaliações, traces, custos, guardrails, gateways e as pessoas responsáveis quando algo falha.

Pense em uma ponte em uso. A estrutura importa, mas também importam as inspeções antes de alterações, os limites de tráfego, o monitoramento e a possibilidade de interditar um trecho perigoso. Comprar uma ponte mais resistente não elimina essas responsabilidades operacionais. Escolher um modelo mais capaz também não.

Para um assistente de atendimento, o ciclo operacional funciona assim: alterar as instruções de reembolso, avaliar a versão candidata com conversas representativas, liberá-la aos poucos, inspecionar os resultados e transformar as falhas em testes de regressão. Um teste de regressão verifica se uma falha antiga reaparece depois de uma nova mudança.

O ganho é poder responder de forma concreta a uma reclamação: qual versão atendeu à solicitação, o que aconteceu durante o processamento e o que pode ser alterado com segurança? A engenharia de prompt melhora uma instrução. LLMOps permite manter essa melhoria depois que ela chega aos usuários.

MLOps vs LLMOps: qual é a diferença?

LLMOps amplia as operações de machine learning, ou MLOps, para lidar com o comportamento de uma aplicação com LLM. Ambos precisam de versionamento, avaliação, controles de implantação e monitoramento. Nenhum dos dois é determinístico por natureza nem dispensa a engenharia de software convencional.

Na funcionalidade em produção considerada aqui, raramente você treina o modelo. Você escolhe um modelo existente e gerencia prompts, contexto, atualizações do modelo, acesso a ferramentas e o software ao redor. Já o MLOps voltado a treinamento também gerencia dados de treinamento, experimentos, artefatos de modelos e retreinamento. Se você faz fine-tuning de um modelo ou hospeda sua infraestrutura de inferência, essas responsabilidades passam a fazer parte do trabalho de LLMOps.

Comece pela falha que precisa resolver. A falta de conhecimento sobre a empresa pode exigir uma recuperação de informações melhor, ou seja, um processo que forneça documentos relevantes ao modelo. Falhas de comportamento recorrentes podem exigir mudanças no prompt ou, mais adiante, fine-tuning. Nenhum desses casos exige reconstruir uma plataforma de treinamento antes de operar a funcionalidade com responsabilidade.

Versione tudo o que vai para produção

A versão de um prompt só é útil se você consegue identificar os outros elementos que influenciaram seu comportamento. Registre um manifesto da versão: um pequeno inventário das configurações implantadas em conjunto:

• Revisão da aplicação, revisão do prompt e identificador do provedor/modelo selecionado.
• Configurações de geração e o identificador do modelo retornado pelo provedor, quando disponível.
• Configuração de recuperação de informações e revisão dos documentos ou do índice.
• Definições de ferramentas, esquemas de saída e política de autorização.
• Arquivo de versões fixadas das dependências e identidade da imagem implantada.
• Conjunto de dados de avaliação, critérios de pontuação e configuração do avaliador usados para aprovar a mudança.

Armazene o manifesto junto ao registro da implantação e inclua seu identificador nos traces de produção. Não coloque segredos nele. Selecione versões explícitas dos modelos quando o provedor oferecer essa opção e programe as migrações de acordo com os avisos de descontinuação.

Imagine um assistente de reembolso cujo prompt não mudou. Uma atualização dos documentos ainda pode fornecer uma nova política; uma mudança no esquema de uma ferramenta pode alterar os parâmetros aceitos por uma ação. Reverter apenas o prompt mantém as duas mudanças. Por isso, o destino do rollback deve identificar uma configuração compatível da aplicação, incluindo as versões relevantes da recuperação de informações e das políticas.

O Langfuse, plataforma de rastreamento e avaliação de aplicações, documenta o armazenamento centralizado de prompts, versionamento, rótulos de implantação e vínculos entre prompts e traces. Esses mecanismos ajudam a relacionar a revisão de um prompt aos seus resultados. Um rótulo de implantação continua sendo uma referência que pode mudar: registre a revisão usada em cada solicitação e submeta as alterações dessa referência à sua política de liberação. Gerenciamento de prompts no Langfuse.

Comece com os prompts no repositório que você já usa se a engenharia for responsável por todas as mudanças. Adicione um registro central de prompts quando pessoas de outras áreas precisarem editá-los com controle ou quando vários serviços precisarem da mesma revisão aprovada. O problema de coordenação deve justificar esse componente a mais.

Use avaliações para decidir o que pode ser liberado

Uma avaliação se torna um controle operacional quando seu resultado pode impedir uma liberação. Uma pontuação em um dashboard que ninguém precisa levar em conta é apenas uma medição.

Monte casos a partir de solicitações representativas, falhas conhecidas e tentativas de abuso, removendo ou substituindo dados sensíveis. Cada caso precisa de um resultado esperado ou de um critério específico. Por exemplo: identificar a política correta, citar as evidências fornecidas, retornar uma proposta de ação válida e recusar o acesso a um registro fora da conta de quem fez a solicitação. Reserve um conjunto separado de casos que os autores dos prompts não usem repetidamente para otimização.

Uma barreira de aprovação pequena e explícita

Suponha que você comece com 50 casos: 30 solicitações rotineiras, 10 casos extremos e 10 tentativas de abuso. É um exercício inicial ilustrativo, não uma afirmação de que 50 exemplos bastam para o seu nível de risco.

Use verificações determinísticas, regras com resultado definido de aprovação ou reprovação, para campos obrigatórios, argumentos permitidos nas ferramentas e limites de permissão. Use revisão humana e um modelo de linguagem como avaliador para qualidades como a fidelidade da resposta às evidências. Mantenha os critérios e a configuração desse avaliador fixos durante a comparação e confronte suas decisões com avaliações humanas em exemplos relevantes. O guia de LLM como avaliador explica essa etapa de calibração.

Uma versão candidata que melhora de 46/50 para 49/50, ou de 92% para 98%, ainda pode ser inaceitável se a falha restante expuser um registro privado. A qualidade agregada não deve esconder problemas em uma parcela crítica do tráfego.

Para esse exemplo, uma barreira de aprovação prática exige:

1. Nenhuma falha crítica nos testes de permissão e de ação.
2. Qualidade igual ou superior à referência aprovada em cada categoria importante de solicitação, com revisão dos casos incertos ou contestados.
3. Latência e uso de recursos dentro dos limites operacionais acordados para a funcionalidade.
4. A versão compatível anterior disponível e uma pessoa responsável pela decisão de reverter.

Repita os casos importantes ou próximos do limite de aprovação quando a variabilidade das respostas puder mudar a decisão. Passar nos testes selecionados fornece evidências sobre aquela versão, não a garantia de que a produção estará livre de falhas.

O LangSmith, plataforma de avaliação e observabilidade, documenta avaliações offline com conjuntos de dados selecionados e avaliações online de interações reais. As opções de avaliação incluem código, revisão humana, LLMs como avaliadores e comparação entre pares. A distinção importa na operação: as verificações offline decidem se uma versão candidata pode ser liberada; as online ajudam a detectar falhas que o conjunto de dados não capturou. Documentação de avaliação do LangSmith.

Depois da aprovação, direcione uma parcela limitada do tráfego à versão candidata e acompanhe as mesmas categorias que foram avaliadas. Trate uma nova rota de modelo ou uma alternativa de contingência como mudança de comportamento também. É preciso ter evidências antes que o tráfego de produção dependa dela.

Rastreie a solicitação e o resultado

Um trace deve explicar como uma solicitação chegou à resposta. Um span é uma operação dentro desse trace, como buscar documentos, chamar um modelo ou executar uma ferramenta.

Capture o identificador da versão, os metadados permitidos da solicitação, as referências de recuperação de informações, as chamadas aos modelos, as propostas e os resultados das ferramentas, as decisões de validação, as novas tentativas, os tempos e o uso de tokens. Registre qual rota foi escolhida e por quê. Relacione o trace ao resultado no produto: o cliente aceitou a resposta, precisou de uma correção ou teve de ser encaminhado a uma pessoa?

Uma resposta lenta sobre reembolso, por exemplo, pode passar pouco tempo no modelo e a maior parte do tempo tentando acessar um serviço de pedidos indisponível. Um gráfico de latência do modelo não explica isso. Um trace com a chamada ao serviço, as novas tentativas e o resultado final explica.

A documentação de rastreamento do Langfuse descreve prompts, respostas, uso de tokens, latência e etapas intermediárias de ferramentas ou de recuperação de informações. A documentação de conjuntos de dados também prevê a criação de casos a partir de traces de produção. Use essa conexão para que cada falha investigada melhore os critérios de aprovação da próxima versão. Rastreamento e conjuntos de dados.

Registre apenas o conteúdo que você tem permissão para reter. Oculte credenciais antes que a telemetria saia da aplicação, restrinja o acesso aos traces e defina o prazo de retenção de forma deliberada. Um registro de depuração pode conter as mesmas informações de clientes que o próprio produto. Quando não for adequado guardar o conteúdo completo, mantenha referências, decisões estruturadas e amostras aprovadas com dados sensíveis ocultados.

Defina os alertas a partir das ações necessárias: quem responde ao aumento de ações malsucedidas, novas tentativas em excesso, uso incomum de recursos ou queda na aceitação? Um sinal sem responsável não melhora a resposta a um incidente. Para aprofundar a escolha, consulte o guia de observabilidade por tamanho de equipe e a comparação entre LangSmith e Langfuse.

Controle o roteamento, as novas tentativas e os gastos

Antes de otimizar a escolha do modelo, estabeleça um teto para o trabalho que uma solicitação pode disparar. Limite o tamanho da saída, o tempo decorrido, as novas tentativas, o trabalho em paralelo e as etapas do agente. Atribua o uso a uma funcionalidade e a um tenant, isto é, um cliente ou uma organização que compartilha sua aplicação.

Cada componente tem uma função. Um gateway centraliza o acesso aos provedores de modelos. Um roteador seleciona um modelo ou uma implantação elegível. Um cache reutiliza um resultado anterior quando isso é válido. Nenhum deles define automaticamente a política de qualidade da sua aplicação.

O LiteLLM, gateway e proxy para modelos, documenta uma interface comum, autenticação, acompanhamento de gastos, orçamentos e balanceamento de carga. A documentação de roteamento cobre novas tentativas, alternativas de contingência e tempos limite. Use esses recursos como políticas explícitas: um endpoint indisponível pode justificar o uso de uma alternativa, mas apenas de uma rota cujo comportamento e cujos requisitos de tratamento de dados você tenha aprovado. Documentação do gateway e documentação de roteamento.

Teste os limites com solicitações simultâneas e com os endpoints que você usa. Diferencie um alerta de um controle que bloqueia a execução e verifique como o trabalho em andamento, as novas tentativas e as chamadas de contingência afetam o total. Mantenha um limite por solicitação na aplicação mesmo quando o gateway acompanha os gastos.

Comece o roteamento com uma regra restrita: envie uma categoria de solicitações claramente identificada e de baixo risco a um modelo menor somente depois que ele passar nas avaliações relevantes. Mantenha os casos ambíguos na rota aprovada com o modelo mais capaz. O guia de roteamento de modelos explica como testar essa política de seleção.

Adicione cache semântico, a reutilização baseada no significado em vez de texto idêntico, apenas onde perguntas equivalentes puderem compartilhar uma resposta com segurança. Uma explicação pública da central de ajuda é uma candidata inicial melhor do que um saldo de conta. Limite a reutilização por permissões, versões relevantes e atualidade dos dados; invalide o cache quando essas condições mudarem. Não execute novamente uma ação, como emitir um reembolso, a partir de uma resposta em cache. Examine os limites do cache semântico antes de adotá-lo.

Aplique guardrails antes da execução das ações

A aplicação deve decidir o que o solicitante pode fazer, mesmo quando o modelo propõe uma ação com confiança. Guardrails são verificações ou restrições sobre entradas, saídas e ações; um classificador de conteúdo é apenas uma parte desse trabalho.

Em um assistente de reembolso, valide a operação proposta e seus argumentos de acordo com as permissões do cliente autenticado antes de executar. Dê à ferramenta apenas as permissões necessárias. Exija uma revisão específica da ação quando a consequência justificar e valide as saídas novamente antes que cheguem a outro sistema. Trate documentos recuperados e saídas do modelo como conteúdo não confiável. Esses princípios seguem as orientações da OWASP para prevenir injeção de prompt.

Defina também o comportamento em caso de falha. Se uma verificação obrigatória de autorização estiver indisponível, a ação não deve prosseguir. O atraso de uma pontuação opcional de qualidade não precisa bloquear um rascunho inofensivo. Documente quais verificações devem bloquear a execução e quais permitem encaminhar o caso a uma pessoa.

Teste solicitações legítimas junto com ataques para evitar que um filtro abrangente demais desative o produto silenciosamente. O guia de guardrails para IA relaciona essas verificações aos pontos de controle que uma equipe pequena pode implementar primeiro.

Inclua os incidentes no ciclo de vida

Antes de escolher a ação de recuperação, determine se o incidente é uma regressão de comportamento, uma falha de serviço ou um comprometimento de segurança. Cada caso exige uma resposta diferente.

Para uma regressão de comportamento, interrompa a liberação gradual, preserve traces representativos, volte à última versão compatível e acrescente a falha ao conjunto de avaliação. Para uma indisponibilidade do provedor, use uma alternativa já avaliada ou uma resposta clara de falha temporária. Diante de uma suspeita de comprometimento, isole o ambiente de execução afetado e envolva a pessoa responsável pela segurança; mudar um prompt não restabelece a confiança no host.

O incidente do LiteLLM, com data e contexto

Em 21 de outubro de 2026, o LiteLLM informou que a versão 1.107.0 continha malware para roubo de credenciais e ferramentas de execução remota de código. As tags de contêiner afetadas incluíam v1.107.0, latest, main-latest e main-stable; o registro privado da versão empresarial não foi afetado. A tag oficial do código-fonte não continha os arquivos maliciosos: os artefatos distribuídos vieram de um repositório controlado pelo invasor. Relatório do incidente do LiteLLM.

O relatório alerta os usuários afetados para que não comecem com pip install, pois hooks de inicialização do Python podem executar o código malicioso novamente. A orientação prioriza reconstruir os ambientes e rotacionar as credenciais às quais o host comprometido tinha acesso. A investigação ainda constava como em andamento quando foi consultada para este artigo; em uma instalação afetada, siga os detalhes atuais do relatório sobre exposição e correção.

A lição operacional vai além desse gateway: registre e aprove o artefato que você implanta, não apenas a revisão do código-fonte que analisou.

Fixe as dependências sem paralisar a manutenção

Fixe as versões aprovadas das dependências e guarde seus hashes; fixe as imagens de contêiner pelo digest, o identificador do conteúdo da imagem. Uma instalação com verificação de hashes exige dependências com versões fixadas e hashes definidos, enquanto referências por digest evitam seguir silenciosamente uma tag de contêiner que muda. Orientações sobre pacotes Python e orientações para fixar imagens de contêiner.

Esses controles comprovam a identidade, não a ausência de código malicioso. Fixar um artefato malicioso preserva o artefato malicioso. Analise a procedência e os avisos de segurança, teste atualizações em isolamento e promova o mesmo artefato aprovado ao longo da implantação. Defina quem atualiza as versões fixadas para que a reprodutibilidade não se transforme em manutenção de segurança adiada indefinidamente.

Mantenha o roteiro de resposta a incidentes curto o suficiente para ser usado sob pressão: responsável, mecanismo de desligamento, inventário dos artefatos afetados, última versão aprovada, escopo das credenciais, canal de comunicação e condições para restabelecer o serviço. Ensaie o procedimento com falhas inofensivas.

Ferramentas de LLMOps: o mínimo para uma equipe de 3 pessoas

Use seu fluxo de implantação atual e um único lugar para inspecionar traces e resultados de avaliação. Adotar um produto separado para cada etapa do ciclo de vida aumenta o trabalho de integração antes de melhorar o controle.

São responsabilidades, não cinco contratações. As pessoas podem compartilhá-las; a atribuição de cada uma ainda deve ser explícita.

O Langfuse é uma opção enxuta para reunir traces, gerenciamento de prompts e conjuntos de dados em um só sistema, com possibilidade de hospedagem própria. Seu escopo documentado permite essa consolidação. O que ele não decide por você é o que conta como uma resposta aceitável ou quando uma liberação deve ser interrompida. Escopo documentado do Langfuse.

O LangSmith é uma opção quando experimentos offline, avaliação online e inspeção de traces de produção se encaixam no seu fluxo de trabalho. A documentação de observabilidade também descreve dashboards, alertas e feedback. A limitação prática é o mesmo problema de medição: uma aplicação bem instrumentada ainda pode ter um conjunto de dados pouco representativo. Escolha um sistema e faça com que as falhas identificadas levem a ações antes de duplicar a telemetria. Observabilidade no LangSmith.

Adicione o LiteLLM quando o acesso compartilhado a provedores e as políticas comuns justificarem operar um gateway. Uma única aplicação com um único provedor pode começar com controles no próprio backend. Quando vários serviços precisarem de credenciais, orçamentos ou rotas aprovadas consistentes, fica mais fácil justificar a centralização dessas políticas. Inclua o banco de dados, as credenciais e as atualizações do gateway no trabalho operacional.

O que muda em uma equipe de 30 pessoas?

Com 30 pessoas, o principal problema passa a ser coordenar mudanças entre os responsáveis. Mais dashboards não resolvem quem pode promover um prompt, aprovar uma alternativa de contingência ou inspecionar o trace de um cliente.

Mantenha os squads de produto responsáveis por seus conjuntos de dados, critérios de aceitação e resultados. Atribua a uma pessoa responsável pela plataforma a configuração do gateway compartilhado, a identidade das implantações, o acesso aos traces e a retenção. Defina quem aprova mudanças de modelos e políticas, quem recebe cada alerta e quem pode acionar o mecanismo de desligamento.

Padronize os metadados de versão e os campos dos traces para que seja possível acompanhar um incidente entre serviços. Separe os ambientes e os escopos de acesso dos clientes. Crie filas de revisão para avaliações contestadas. Programe verificações de descontinuação de modelos, avisos de segurança de dependências e desvio dos conjuntos de dados: mudanças nas solicitações que o produto recebe.

Quando vale a pena adotar uma plataforma de LLMOps?

Adote uma plataforma compartilhada quando falhas recorrentes de coordenação custarem mais do que operá-la: versões incompatíveis de prompts, infraestrutura de avaliação duplicada, políticas de acesso inconsistentes ou incidentes que atravessam os limites dos serviços sem um responsável.

O tamanho da equipe é um cenário de planejamento, não um limite técnico. Uma equipe pequena que executa ações de grande consequência pode precisar de controles rigorosos imediatamente; uma equipe maior com uma única funcionalidade interna de escopo limitado ainda pode precisar de poucas ferramentas. Dimensione os controles conforme o alcance dos danos possíveis e o problema de atribuição de responsabilidades.

Onde há exagero?

Treinar um modelo não é pré-requisito para começar. Se você usa um modelo hospedado, já tem um sistema para avaliar e operar. Monte o ciclo de liberação antes de decidir se o fine-tuning resolve uma falha comprovada.

Uma pontuação alta do avaliador não é um certificado universal de qualidade. Ela responde aos critérios fornecidos nos exemplos selecionados. Mantenha a revisão humana e as verificações determinísticas onde uma decisão errada tiver uma consequência clara.

O roteamento automático não torna todas as alternativas de contingência equivalentes. Uma rota pode mudar o comportamento da saída, o uso de ferramentas e o destino dos dados. Aprove essas mudanças de forma deliberada.

Observabilidade não é uma promessa de armazenar tudo. Traces úteis precisam de contexto suficiente para investigar uma falha, com acesso e ocultação de dados adequados a esse contexto.

Livro ou curso de LLMOps?

Escolha o material de estudo a partir da tarefa de produção que você ainda não consegue executar. Um livro pode ajudar a pensar a arquitetura; um curso é útil quando os exercícios fazem você criar um conjunto de dados, investigar traces, condicionar uma liberação à aprovação e se recuperar de uma falha. Um programa focado apenas em treinamento de modelos deixa lacunas importantes para uma funcionalidade baseada em API.

Por onde começar na segunda-feira

Se os clientes já dependem da funcionalidade, implemente agora os critérios de aprovação da liberação, as permissões das ações e o procedimento de recuperação. Se você tem apenas um protótipo isolado, sem dados de clientes nem ações externas, pode adiar gateways compartilhados e a administração da plataforma, mantendo os experimentos reproduzíveis.

1. 1

   Escolha uma funcionalidade e defina suas condições de falha

   Escolha o fluxo de produção mais importante. Registre os resultados aceitáveis, as ações proibidas, a pessoa responsável e as condições que devem impedir uma liberação.

2. 2

   Torne a versão atual identificável

   Registre o prompt, o modelo, o contexto, as ferramentas, a política e a identidade das dependências. Vincule esse registro a um trace de solicitação com os dados sensíveis ocultados.

3. 3

   Transforme falhas conhecidas em critérios de aprovação

   Monte casos de avaliação representativos, execute a versão atual como referência e exija revisão antes de aceitar uma regressão em uma categoria crítica.

4. 4

   Ensaie a recuperação

   Demonstre os procedimentos de rollback e desligamento em um ambiente seguro. Defina os responsáveis pela próxima investigação e pela revisão das atualizações de dependências antes de adicionar outra plataforma.

Perguntas frequentes sobre LLMOps

Qual é a diferença entre LLM e LLMOps?

Um LLM é o modelo que gera uma saída. LLMOps é a disciplina operacional que envolve a aplicação que o utiliza: controlar mudanças, verificar o comportamento, observar solicitações e se recuperar de falhas.

O que significa a sigla LLMOps?

LLMOps significa large language model operations, ou operações de grandes modelos de linguagem. Para uma equipe de aplicações, o escopo inclui os prompts, o contexto, as ferramentas e o processo de liberação que cercam o modelo.

Quais são as principais diferenças entre LLMOps e AgentOps?

AgentOps dá atenção adicional à execução em várias etapas: ações de ferramentas, estado persistente, permissões, limites de etapas e conclusão de tarefas. Um agente é um sistema que usa um modelo para escolher ações; essas ações devem fazer parte dos mesmos controles de liberação e de incidentes.

Qual é o melhor curso de LLMOps?

Para quem está no cenário deste artigo, vale escolher um curso cujo projeto avaliado inclua avaliação, rastreamento, implantação e recuperação. Um curso focado apenas em treinar um modelo não cobre as responsabilidades operacionais de uma funcionalidade que já está em produção.

Existe certificação gratuita de MLOps?

A disponibilidade e as condições do exame dependem da instituição; consulte a página atual da certificação antes de se inscrever. Uma certificação não é pré-requisito para implementar os controles de liberação descritos aqui.

Dá para aprender machine learning em 3 meses?

Use esse período para um projeto de aprendizado com escopo definido, não como promessa de domínio de produção. Para uma funcionalidade existente com LLM, um projeto útil é uma aplicação versionada, com avaliações, traces e um procedimento de recuperação demonstrado.

Trabalhar com machine learning paga bem?

A remuneração depende da função, da localização e da senioridade; o título de LLMOps, por si só, não determina o salário. Ao contratar, avalie se a pessoa consegue explicar uma falha de avaliação e operar com segurança a versão resultante.

É tarde demais para aprender Python aos 30 anos?

Não. Escolha um projeto prático pequeno e mantenha uma rotina de estudo. Você pode aprender o trabalho de desenvolvimento de aplicações necessário para esse ciclo de vida sem antes se tornar pesquisador de modelos.

Aprender IA e machine learning é muito difícil?

Depende do escopo. Operar uma funcionalidade que chama um modelo existente e pesquisar um novo modelo são projetos de aprendizado diferentes. Comece pelas responsabilidades de software e avaliação que sua funcionalidade já exige.

Para receber guias práticos sobre como desenvolver e operar funcionalidades de IA, assine a newsletter.