LLMOps e operação de IA em produção
Mantenham o vosso sistema de IA em produção estável e sem surpresas.
Já o entregaram. Agora tem de continuar a funcionar a 10x do tráfego, no modelo do próximo trimestre, sem um alerta às 2 da manhã. Isso é um trabalho diferente de o construir — e o que a maioria das equipas subfinancia.
Sinais acompanhados
- Dentro do alvo
- A vigiar
- Agir
- O que se mede
- Uma suite de evals corre em cada mudança de prompt e de modelo; em produção, uma amostra das respostas é pontuada.
- Quando muda de estado
- A vigiar: A pontuação da amostra desce face à linha de base.
- Agir: Uma mudança de prompt ou de modelo falha os evals.
- O que fazemos
- A mudança não chega aos utilizadores: o build falha. Numa troca de modelo, a versão nova fica atrás de um flag até os evals passarem.
- O que se mede
- Latência p50, p95 e p99 por funcionalidade de IA.
- Quando muda de estado
- A vigiar: O p95 aproxima-se do alvo acordado.
- Agir: O p95 fica acima do alvo de forma sustentada.
- O que fazemos
- Ver onde está o tempo — modelo, pesquisa ou rede — e atuar: caching, um modelo mais rápido para os pedidos simples, teste de carga antes do próximo pico.
- O que se mede
- Custo por pedido e por resultado, por funcionalidade, face ao teto acordado.
- Quando muda de estado
- A vigiar: O custo por pedido sobe sem o volume subir.
- Agir: O mês caminha para ultrapassar o teto.
- O que fazemos
- Encontrar a causa — prompt maior, mais chamadas, modelo mais caro — e corrigir com caching, routing por tier de modelo e orçamentos por pedido. Cada otimização fica documentada.
- O que se mede
- Taxa de erros e de fallbacks por funcionalidade, com alertas para quem está de serviço.
- Quando muda de estado
- A vigiar: Os fallbacks aumentam, mas o serviço continua a responder.
- Agir: A taxa de erros passa o limiar acordado no SLA.
- O que fazemos
- Runbook de on-call: degradação controlada, recuperação e aviso a quem precisa de saber. Depois, um postmortem e a correção para não se repetir.
Todos os meses: revisão da telemetria, do que foi entregue e do próximo backlog.
Estados e limiares de exemplo, não leituras de um sistema real. Os alvos de cada sistema saem da auditoria e da linha de base.
Trabalho selecionado
Caso de estudo· Estados Unidos
Saúde · Plataforma de decisão de nutrição de precisãoPlataforma de alimentação baseada em IA para uma empresa de MedTech neonatal dos EUA.
- Problema
- O cuidado de prematuros é implacável. A carga cognitiva é enorme.
- Abordagem
- O conjunto de dados é o núcleo de inteligência. A função da aplicação é torná-lo consultável no ponto de cuidado.
- Resultado
- De dados desconexos a inteligência acionável à cabeceira do doente.
- 94%Taxa de adesão ao protocolo após o lançamento
- 3×Tempo de decisão de alimentação mais rápido
- EpicEHR integrado via HL7 / FHIR
Caso de estudo· Luxemburgo
Right-On-Skill · Equipa tech nearshore para uma empresa de formação em IATech Lead + Frontend Developer a estender a equipa de engenharia de uma plataforma de formação em IA.
- Problema
- Escalar a equipa sem diluir a propriedade arquitetural.
- Abordagem
- Diagnosticamos antes de propor. Talento qualificado colocado em duas semanas, totalmente alinhado.
- Resultado
- Base arquitetural pronta a escalar. A camada de IA encaixa de forma limpa.
- 2 semanasDo briefing ao primeiro programador integrado
- 0CVs rejeitados — encaixe certo logo à primeira
- –70%Redução da dependência de fornecedores externos
- Latência medida por funcionalidade de IA
- p50/p95/p99
- Mudanças de prompt e modelo validadas por evals
- 100%
- Só engenheiros principais, sem juniores nem filas de pedidos.
- Sénior
- Duração da auditoria; linha de base nas primeiras semanas
- Dias
- Revisão da telemetria, do que foi entregue e do próximo backlog
- Mensal
Tudo o que precisam.Para correr sem surpresas.
Números reais em vez de dashboards de vaidade, qualidade medida em vez de assumida, mudanças validadas e um piso de fiabilidade — para o sistema aguentar 10x o tráfego e a fatura parar de subir.
Visibilidade e custo
Um dashboard de telemetria que é vosso
Custo ao vivo, latência (p50/p95/p99), taxas de erro e de fallback por funcionalidade de IA. Deixam de adivinhar sobre o vosso próprio sistema.
Uma fatura de IA que para de subir
Custo por pedido e custo por resultado medidos e a descer — ou mantidos estáveis à medida que o volume cresce — com cada otimização documentada.
Qualidade em cada mudança
Qualidade medida, não assumida
Uma suite de evals que valida cada mudança de prompt e de modelo, mais scoring amostrado em produção, para que a deriva (drift) seja um número apanhado, não um email de cliente.
Upgrades de modelo que não vos partem
Quando um fornecedor descontinua ou lança, voltamos a correr os evals e fazemos a troca atrás de um flag — sem regressão de qualidade, sem correrias.
Fiabilidade e margem
Um piso de fiabilidade
Fallbacks, retries, degradação controlada, um runbook de on-call e um postmortem depois de cada incidente. Menos alertas, recuperação mais rápida.
Margem provada antes de precisarem dela
Números de capacidade testados com carga e um plano de infraestrutura e quotas dimensionado para onde vão, para que o próximo 10x seja uma mudança de configuração, não uma reescrita.
Como trabalhamos.Auditado, depois operado.
Cinco passos de uma auditoria de produção a frio até um sistema que corre com cadência — com números reais antes de tocarmos seja no que for.
- 01AUDITARAuditoria de produção
Um engenheiro sénior revê o sistema ao vivo: o que está instrumentado, custo por pedido, perfil de latência, cobertura de evals, modos de falha, exposição a descontinuações. Recebem um documento de conclusões com riscos ordenados. Auditamos um sistema que não construímos.
- 02LINHA DE BASEInstrumentar e fixar a linha de base
Montamos a observabilidade e a bateria de evals — testes automáticos que medem a qualidade das respostas — para haver números reais antes de mudarmos seja o que for. Não se pode reivindicar 40% de corte de custo sem uma linha de base medida. Isto chega em dias, não em semanas.
- 03ESTABILIZAREstabilizar
Fechamos os riscos ordenados da auditoria — fallbacks, retries, os gates de evals, o runbook, os ganhos óbvios de custo. O objetivo é estancar a hemorragia e tornar os incidentes raros e recuperáveis.
- 04OPERAROperar com cadência
A monitorização está ativa, os evals validam cada mudança, os upgrades de modelo são tratados à medida que chegam e uma revisão mensal mostra a telemetria, o que foi entregue e o próximo backlog. O SLA está em vigor.
- 05OTIMIZAROtimizar e manter pronto para escalar
Continuamos a baixar o custo por resultado, a segurar a latência à medida que o volume cresce e a testar com carga antes de eventos de crescimento conhecidos. Se quiserem trazer a operação para dentro, o handover faz parte do acordo.
Não somos para todos.Somos para quem o quer estável e previsível.
Se algum destes vos soa familiar, devíamos falar.
Está em produção e já vos consome
Uma funcionalidade com LLM ao vivo, sem controlos por trás
O que enfrentam
- Uma fatura que sobe todos os meses
- Latência que é um mistério
- Queixas de qualidade a chegar dos clientes
O que procuram
Precisam de instrumentação e controlo de custos, não de uma reescrita.
Resultado
Um sistema que conseguem ver, com preço e sob controlo.
Construído connosco, operado por nós
Entregue connosco, um ou dois sistemas para manter
O que enfrentam
- Sem querer contratar uma equipa inteira de operações de IA
- Apenas um ou dois sistemas para manter vivos
- A querer os mesmos engenheiros que o definiram
O que procuram
Precisam de devolver a operação aos engenheiros que a entregaram, num acordo contínuo.
Resultado
Operação devolvida à equipa que a construiu, sem contratações novas.
Não vai aguentar o crescimento que vem aí
Um lançamento, um mercado ou 10x utilizadores à frente
O que enfrentam
- Um sistema que hoje está bem
- Um evento de crescimento que o vai partir
- Sem margem provada para o que vem aí
O que procuram
Precisam de testes de carga, dimensionamento de infraestrutura e trabalho de fiabilidade antes do evento de crescimento, não durante.
Resultado
O próximo 10x tratado antes de chegar, não durante a queda.
Os mesmos engenheiros séniores do início ao fim.
Perguntas frequentes
Começa com uma auditoria de produção de scope fixo, para que nenhum dos lados se comprometa às cegas. O acordo contínuo é mensal, dimensionado à superfície real do sistema — funcionalidades, tráfego, nível de SLA — não um headcount que se aluga. É mês a mês depois da estabilização; sem compromisso anual para começar.
A auditoria são dias. A instrumentação e a primeira baseline chegam nas primeiras semanas, por isso veem números reais cedo. Os SLAs são acordados à partida e ajustados ao que o sistema precisa — metas de resposta, de resolução e de uptime onde controlamos o suficiente do stack para nos comprometermos com uma.
Não reivindicamos uptime de partes do stack fora do nosso controlo, e dizemo-lo no SLA. Não corremos isto como uma fila de tickets com juniores. E se a auditoria concluir que a arquitetura não escala, dizemos-vos que precisa de uma reescrita em vez de faturar manutenção para sempre.
Os outros serviços levam um sistema até produção. Suporte & Escala é o único cujo trabalho inteiro é depois do lançamento — manter um sistema ao vivo fiável, barato e atual. Dois sinais: é o único serviço que aceitamos sobre um sistema que não construímos, e mede-se em SLAs cumpridos e custo a descer, não em funcionalidades entregues.
Comecem o deployment.
Falem diretamente com um engenheiro principal.
Sem equipa de vendas.
Sem workshops de discovery.
Sem circo de procurement.
Definimos, construímos e entregamos.
- Resposta num dia útil
- Diagnóstico feito por engenheiros
- Proposta por escrito
- Lisboa · fuso do Reino Unido
Sem compromisso. Só um engenheiro.