IA em produção
Desenvolvimento de IA: o seu primeiro fluxo no ar em 21 dias
Colocamos IA dentro dos sistemas que já tocam a sua empresa. Runtime de agente em Go, ferramentas tipadas para o seu ERP, o seu CRM, a sua fila de chamados e o seu mainframe, um passo de aprovação em tudo que escreve e uma suíte de avaliação no CI que quebra o build quando as respostas pioram. Qualquer stack, qualquer setor, de um fluxo só até uma plataforma que os seus próprios engenheiros tocam.
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
Como o trabalho anda
- 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.
- 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.
- 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.
- 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
| O que a plataforma faz e o que uma pessoa faz | Quem faz | Notas |
|---|---|---|
| Ler a base de código e achar os pontos de integração | Plataforma | Horas em um repositório que uma pessoa levaria uma semana lendo. |
| Escolher qual fluxo vem primeiro | Engenheiro | Volume, uma resposta verificável e alguém do seu lado que responda pelo resultado. |
| Escrever adaptadores para as suas APIs | Os dois | A 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órico | Os dois | Puxar os casos é automático. Decidir quais respostas antigas estavam certas não é. |
| Rodar regressões a cada commit | Plataforma | Uma queda quebra o build, do mesmo jeito que um teste unitário quebrado. |
| Decidir em que o agente pode escrever | Engenheiro | Seu 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 a plataforma devolve o mapa de módulos e a lista de código morto da sua base em poucos dias. O documento fica com você contratando a gente ou não, 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 mais ou menos quanto ele custa quando dá errado. Volta como construiríamos, quanto tempo leva e quanto custa, em até dois dias úteis.
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.