10 arquiteturas de plataforma de IA corporativa

• → time, aplicação, usuário
• → consulta a cota
• → dentro do limite
• → modelo escolhido
• → tokens de entrada e de saída
• → gasto por inquilino
• → excedeu

• Rede e entrega
• Segurança e identidade
• Conceito de arquitetura
• Compute
• IA e machine learning
• Analytics

Custo de IA é variável por uso, e sem atribuição por inquilino a única alavanca é cortar o uso. Porta única, identidade em cada chamada, cota preventiva e painel por dono — nessa ordem.

1. Toda chamada por uma porta. É o pré-requisito de tudo o resto: sem ponto único, a medição tem buracos e a cota é contornável.
2. Identidade de inquilino em cada chamada. Time, aplicação e usuário. Sem isso, o consumo é atribuível apenas à conta — que é o problema original.
3. Cota antes do gasto, não relatório depois. Cota é preventiva: ela impede o estouro. Relatório é detectivo: informa que aconteceu.
4. Tokens de entrada e de saída separados. Eles têm preços diferentes e otimizações diferentes: entrada se reduz com cache e contexto menor, saída com instrução de tamanho.
5. Custo visível ao dono é custo que cai. O time que vê o próprio gasto otimiza. A conta agregada não tem dono, e por isso não tem redução.

• → inquilino A
• → inquilino B
• → mesma família de modelo
• → mesma família de modelo
• → custo separado
• → custo separado
• → habilita a quebra

• IA e machine learning
• Compute
• Gestão e governança

Atribuir custo de inferência exige uma entidade etiquetável: o perfil de inferência por inquilino. Etiquetar o chamador não separa a chamada de modelo, e é por isso que a fatura chega agregada.

1. A chamada de modelo não herda etiqueta do chamador. É a descoberta que custa um trimestre: etiquetar a função não separa o consumo de inferência que ela provocou.
2. O perfil é a entidade etiquetável. Criar um perfil por inquilino dá ao faturamento algo a que atribuir. É o mecanismo, não uma convenção de nome.
3. A aplicação escolhe o perfil pelo inquilino. A decisão acontece no código, no momento da chamada. Errar o perfil é atribuir custo ao inquilino errado — e isso não se corrige depois.
4. A etiqueta precisa estar ativada no faturamento. Etiqueta existente e não ativada como etiqueta de alocação não aparece no relatório. É a pegadinha de configuração mais comum aqui.
5. O modelo continua sendo um só. Não há duplicação de infraestrutura: os perfis apontam para o mesmo modelo. O que muda é a contabilidade.

• → inquilino e caso de uso
• → viaja com a requisição
• → invocação + metadado
• → registros do dia
• → agregado por dia
• → desvio do padrão

• Compute
• Conceito de arquitetura
• IA e machine learning
• Armazenamento
• Analytics

Atribuição confiável se faz na chamada, com metadado que viaja junto da requisição — e por caso de uso, não só por inquilino, porque é o caso de uso que se otimiza.

1. O metadado viaja com a requisição. Ele é gravado junto da invocação, não correlacionado depois. Isso elimina a margem de erro da atribuição por horário.
2. Caso de uso, não só inquilino. Saber que o time X gastou não diz o que reduzir. Saber que foi o resumo automático de tickets diz.
3. O registro de invocação é a fonte. Ele traz tokens de entrada e de saída por chamada. É a granularidade que permite custo por caso de uso.
4. Agregar por dia, guardar o detalhe. O painel usa o agregado; a investigação usa o detalhe. Guardar só o agregado impede responder "qual chamada custou isso?".
5. Alarme relativo ao padrão do inquilino. Limite absoluto igual para todos alarma o time grande e ignora o pequeno que dobrou de consumo.

• → credencial do usuário
• → inquilino autenticado
• → assume o papel do inquilino
• → só a partição dele
• → chave com o inquilino no prefixo
• → trechos daquele inquilino

• Fora da AWS
• Segurança e identidade
• IA e machine learning
• Banco de dados

Em multi-inquilino, isolamento por contexto é instrução com taxa de falha. O que isola é identidade autenticada, credencial que assume papel por inquilino e partição de dado com o inquilino na chave.

1. O inquilino vem do token, nunca do corpo da requisição. Se chega no corpo, qualquer cliente se declara outro. A autenticação é a única fonte aceitável dessa informação.
2. Credencial por inquilino, não credencial da plataforma. O runtime assume um papel restrito à partição daquele cliente. É o que transforma isolamento lógico em isolamento imposto.
3. Prompt não isola nada. "Responda só sobre o cliente 42" é instrução. Permissão que não alcança os dados dos outros é garantia.
4. A chave de dado carrega o inquilino. Prefixo no identificador impede consulta acidental atravessar. É defesa em profundidade, junto da credencial.
5. Compartilhar infraestrutura é decisão de custo, não de isolamento. O reservatório reduz custo por cliente. O isolamento vem de identidade e permissão — e precisa ser explícito.

• → rota para o serviço
• → mesma rota
• → mesma rota
• → tráfego concentrado
• → chamada privada
• → nome resolve igual

• Rede e entrega
• IA e machine learning

Compartilhar endpoint e centralizar trânsito troca custo multiplicado por vinte e topologia combinatória por uma tabela de rotas — e transforma "quem alcança o quê" de projeto em consulta.

1. Endpoint criado uma vez, usado por todas. Vinte endpoints iguais custam vinte vezes e divergem em configuração. O compartilhamento elimina os dois problemas.
2. O concentrador dá um lugar para as rotas. Malha ponto a ponto entre vinte contas é combinatória. Concentrador troca isso por vinte ligações e uma tabela.
3. Resolução de nome compartilhada. Sem ela, cada conta configura o próprio nome e a mudança de endereço exige vinte alterações coordenadas.
4. A conta central é dona da rede, não do dado. A separação de responsabilidade é o que evita a conta de rede virar depósito de tudo.
5. Administrável significa auditável. Com um ponto de trânsito, "quem alcança o serviço de IA?" é uma consulta. Com vinte topologias, é um projeto.

• → vetor da pergunta
• → busca o mais próximo
• → distância
• → acerto: responde do cache
• → erro: gera
• → guarda
• → acerto e custo evitado

• Fora da AWS
• Conceito de arquitetura
• Banco de dados
• IA e machine learning

Cache semântico captura a variação de redação que o cache exato não pega, e a economia vem de o embedding ser muito mais barato que a geração. O limiar de similaridade é o parâmetro que precisa ser medido, não estimado.

1. Cache exato não pega variação de redação. É por isso que ele tem taxa de acerto quase nula em linguagem natural. O semântico compara sentido, não string.
2. O limiar é o parâmetro perigoso. Frouxo demais responde a pergunta errada com resposta parecida. Apertado demais não acerta nada. Ele se calibra medindo, não estimando.
3. Embedding é ordens de magnitude mais barato que geração. É o que faz a economia existir: paga-se um cálculo pequeno para evitar um grande.
4. Validade obrigatória. Resposta cacheada sobre política que mudou é resposta errada servida rápido. A validade precisa acompanhar o ritmo do acervo.
5. Medir acerto e custo evitado. Sem o número, o cache é fé. Com ele, dá para decidir se vale afrouxar o limiar — e quanto risco isso adiciona.

• → classe + confiança
• → simples
• → difícil
• → não resolveu
• → refaz no grande
• → mede o acerto

• IA e machine learning
• Compute
• Conceito de arquitetura

Roteamento por dificuldade é a maior alavanca de custo e introduz um componente que erra em silêncio. Ele precisa de conjunto de avaliação próprio e de escalonamento quando a resposta do modelo pequeno não atende.

1. O roteador é um componente com erro próprio. Ele acrescenta uma fonte de falha que não existia. E o erro dele é silencioso: a resposta sai, só é pior.
2. Conjunto de avaliação para o roteador. Perguntas rotuladas com a dificuldade real. Sem isso, não há como saber se ele está mandando caso difícil para o modelo pequeno.
3. Escalonamento como segunda chance. Quando a resposta do modelo pequeno não atende ao critério, refazer no grande custa duas chamadas — e ainda sai mais barato que usar o grande sempre.
4. Confiança baixa vai para o grande. Na dúvida, o caminho seguro é o modelo capaz. O ganho vem do volume claramente simples, não de forçar os casos limítrofes.
5. Medir qualidade junto com custo. Custo caindo com qualidade caindo não é otimização. As duas séries precisam ser lidas juntas.

• → casos + resposta esperada
• → o que conta como acerto
• → os mesmos casos
• → os mesmos casos
• → acerto, custo, latência
• → acerto, custo, latência

• Conceito de arquitetura
• IA e machine learning

A decisão de modelo se toma medindo na sua tarefa, com critério definido antes e os mesmos casos nos candidatos — em três eixos. Ranking público responde a outra pergunta.

1. Ranking público mede outro corpus. Ele responde "qual é melhor em média, em tarefas gerais". A sua pergunta é "qual é melhor na minha tarefa" — e as respostas divergem com frequência.
2. Critério de acerto definido antes. Decidir o que conta como acerto depois de ver os resultados é escolher o vencedor e chamar de medição.
3. Os mesmos casos nos dois candidatos. Comparar em conjuntos diferentes não compara nada. É o erro mais comum em avaliação caseira.
4. Três eixos: acerto, custo e latência. O melhor em acerto pode ser inviável em custo ou em prazo. A decisão é o ponto que atende ao requisito, não o topo de um eixo.
5. O conjunto fica, e serve para a próxima troca. O investimento no conjunto se paga na segunda decisão — e modelo novo aparece a cada poucos meses.

• → versão promovida
• → resolve para uma versão
• → prompt resolvido
• → com a versão
• → candidata
• → autoriza promover

• IA e machine learning
• Rede e entrega
• Compute
• Gestão e governança

Prompt muda mais que código e por mais gente: sem versão imutável, alias e registro da versão usada em cada chamada, investigar regressão é arqueologia de commit.

1. Prompt muda mais que código. E muda sem revisão, por quem não é engenheiro. É a razão de ele precisar de versionamento próprio em vez de viver dentro do código.
2. A aplicação referencia o alias. Trocar a versão em produção passa a ser mover um ponteiro — sem implantação e com reversão imediata.
3. A versão usada entra no registro da chamada. É o que transforma "a qualidade caiu na terça" em "a versão 7 entrou às 14h de terça".
4. Avaliar a candidata antes de promover. Prompt novo é mudança de comportamento. Compará-lo no mesmo conjunto é o que evita a regressão chegar ao usuário.
5. Versão imutável, não editável. Editar a versão em uso destrói a capacidade de comparar. Nova redação é nova versão.

• → sim: visual
• → não: código
• → chama passo específico
• → o desenho é a documentação
• → trecho testável isolado

• IA e machine learning
• Fora da AWS
• Compute
• Conceito de arquitetura

Fluxo visual e código não são níveis de maturidade: são uma troca entre visibilidade e controle. O padrão que sustenta é o híbrido — sequência visível chamando passos testáveis em código.

1. A troca é visibilidade por controle. O visual ganha em quem pode alterar e em documentação viva. Perde em versionamento, teste isolado e tratamento fino de erro.
2. O critério é estabilidade e simplicidade. Fluxo que muda toda semana por decisão de negócio: visual. Fluxo com muitos caminhos de erro e regra sutil: código.
3. Misturar é o padrão que funciona. Fluxo visual chamando passos em código junta as duas vantagens: a sequência é visível e alterável, a lógica difícil é testável.
4. Teste automatizado só existe do lado do código. É a perda mais séria do visual, e é ela que precisa ser pesada antes de mover lógica crítica para lá.
5. A visibilidade tem valor real. Em processo que várias áreas discutem, o desenho ser a documentação evita a divergência entre o que se pensa e o que roda.