Ir para o conteúdo

IA em produção

Desenvolvimento de IA: o seu primeiro fluxo no ar em 21 dias

Seu ERP sabe tudo e não te conta nada. Sua fila de chamados é respondida por gente redigitando o que outro sistema já tinha dito. Colocamos IA dentro desses sistemas: runtime de agente em Go, ferramentas tipadas para o ERP, o CRM, a fila de chamados e o mainframe, um passo de aprovação em tudo que escreve e uma suíte de avaliação no CI que quebra o build no dia em que as respostas piorarem. Primeiro fluxo no ar em vinte e um dias. Qualquer stack, qualquer setor.

Pedir orçamentoQuatro telas, uns dez minutos. Um engenheiro lê e responde, normalmente no mesmo dia.

21 dias até o primeiro fluxo em produção


A linha riscada é a parte que a maioria dos pilotos pula, e é por isso que ninguém lá dentro sabe dizer se o modelo piorou na semana passada.

Protótipo

Um notebook que funciona com dados de demo e uma API fechada de fornecedor.

  • spec.docxWord
  • proof-of-conceptPython · notebook
  • vendor APIclosed
  • evalnone

Produção

Um serviço com ferramentas para chamar, testes que ele pode reprovar e traces que dá para pesquisar.

  • agent runtimeGo
  • tool layerTypeScript
  • eval harnessCI gate
  • tracesOpenTelemetry

21 dias até o primeiro fluxo em produção

A linha riscada é a parte que a maioria dos pilotos pula, e é por isso que ninguém lá dentro sabe dizer se o modelo piorou na semana passada.

Como o trabalho anda

A mesma ordem em todo projeto. Os dois primeiros passos são o que torna o terceiro demonstrável.
  1. 01dias 1–2

    Escolher um fluxo

    Um processo com volume e com resposta certa. Medimos quanto ele custa hoje em minutos e em erros, porque é contra esse número que o resultado vai ser julgado.

  2. 02dias 2–6

    Montar o conjunto de avaliação primeiro

    Algumas centenas de casos reais do seu próprio histórico, cada um com a resposta que a sua equipe deu. É a parte sem brilho do projeto e a razão de tudo o que vem depois poder ser provado em vez de discutido.

  3. 03dias 5–16

    Construir o runtime e as ferramentas

    Runtime de agente em Go, adaptadores tipados para os seus sistemas, um passo de aprovação em tudo que escreve. As avaliações rodam a cada commit desde o primeiro dia.

  4. 04dias 14–21

    Subir e entregar

    Traces, um runbook e um dia com os seus engenheiros para que eles mudem prompts e ferramentas sem nos ligar. A entrega faz parte do preço.

O que a plataforma faz e o que uma pessoa faz

A plataforma carrega a metade mecânica em velocidade de máquina. Os nossos engenheiros ficam com as decisões que custam dinheiro quando saem erradas.
Em uma base documentada a plataforma carrega mais disso; em uma de vinte anos, os nossos engenheiros carregam mais. A data que demos vale nos dois casos.
O que a plataforma faz e o que uma pessoa fazQuem fazNotas
Ler a base de código e achar os pontos de integraçãoPlataformaHoras em um repositório que uma pessoa levaria uma semana lendo.
Escolher qual fluxo vem primeiroEngenheiroVolume, uma resposta verificável e alguém do seu lado que responda pelo resultado.
Escrever adaptadores para as suas APIsOs doisA plataforma rascunha a partir do contrato da API. Uma pessoa corrige aquilo em que o contrato mentiu.
Montar o conjunto de avaliação a partir do seu históricoOs doisPuxar os casos é automático. Decidir quais respostas antigas estavam certas não é.
Rodar regressões a cada commitPlataformaUma queda quebra o build, do mesmo jeito que um teste unitário quebrado.
Decidir em que o agente pode escreverEngenheiroSeu risco, sua decisão, registrada por escrito antes de qualquer coisa rodar.

Quem você tem no projeto

Dezenas de migrações nas costas e mais de dez anos dentro de sistemas dos outros. Os engenheiros que colocaram serviços em Go e TypeScript em produção ao lado de COBOL, RPG, VB6, Delphi e PHP são os mesmos que constroem a camada de agentes. É por isso que a nossa IA termina dentro dos sistemas que carregam o seu dinheiro, e não ao lado deles.


Dê acesso de leitura e em poucos dias a plataforma devolve o mapa de módulos e a lista de código morto da sua própria base. O documento é seu, e é a forma mais rápida de ver como trabalhamos.

Perguntas que engenheiros fazem

Isso é um wrapper em cima de uma API de chat?
Tem um modelo ali dentro, do mesmo jeito que tem um banco de dados dentro do seu sistema de cobrança. O trabalho é a camada de ferramentas, os portões de aprovação e as avaliações que dizem quando uma atualização de modelo piorou as coisas. Chamar a API é a parte barata. O que você paga é por saber quando a resposta está errada.
O que acontece quando o modelo muda embaixo da gente?
A suíte de avaliação roda contra o modelo candidato antes de qualquer troca. Se a nota cai, você fica no modelo antigo até os prompts e as ferramentas alcançarem.
Onde o nosso código roda enquanto vocês trabalham nele?
No ambiente que você exigir, inclusive inteiramente dentro da sua rede ou da sua conta de nuvem. Já trabalhamos sob VPN de cliente, em máquinas de build sem saída para a internet e em hardware que nunca deixou o prédio. Os detalhes vão para o contrato.
De quem é o que vocês constroem?
Seu. Repositórios comuns em Go e TypeScript, bibliotecas comuns, nenhuma chamada de runtime de volta para nós. A nossa plataforma é como trabalhamos. Ela não vira algo que você acaba alugando.
Nosso time consegue manter isso depois?
É para isso que serve a entrega, e é por isso que a camada de ferramentas é tipada e os prompts moram em controle de versão em vez de um console de fornecedor. Os seus engenheiros mudam a definição de uma ferramenta, rodam as avaliações de novo e sobem, sem a gente na sala.

Mande o fluxo

Diga qual processo você automatizaria primeiro e quanto ele custa quando dá errado. Em até dois dias úteis volta a resposta: como construímos, quanto tempo leva e quanto custa.

Pedir orçamento

Quatro telas: o sistema, o que dói, onde você quer chegar, como falar com você. Nenhuma call é marcada a não ser que você peça.