AI Por Dentro: De Tokens a Agents

Seu agent de diagnóstico vai bem numa interação. Aí o mesmo alerta volta na semana seguinte e ele zera a memória. Não lembra que já investigou. Não lembra que a causa raiz era aquele cronjob que explode memória toda quarta às 3h da manhã. Agent sem memória é como engenheiro que perde o caderno toda segunda. Sabe trabalhar. Só reaprende as mesmas coisas o tempo todo. O mapa pro profissional de infra Conceito de Memória O que faz Equivalente em infra Short-term memory Contexto da conversa atual Buffer de request (dados in-flight) Long-term memory Informações que persistem entre sessões Database, persistent storage Episodic memory Lembranças de interações passadas Logs, audit trail Semantic memory Conhecimento geral acumulado Knowledge base, wiki Working memory O que está “ativo” na cabeça do agent Cache, working set State Configuração atual do agent Estado do pod, configmap Consistency Garantia de que memória é correta Consistency model do banco Por que memória é difícil em agents LLMs são stateless. Cada request é independente. O modelo não “lembra” nada entre chamadas. Toda memória é simulada via contexto. ...

No post anterior, eu destrinchei como agents funcionam: LLM, tools e loop. Agora a conversa muda de nível. O problema não é fazer um demo de 5 minutos. É projetar um agent que aguente produção, rode 24/7 e não precise de babá. Continua sendo design de sistema, com as perguntas de sempre: quais são os requisitos, quais os failure modes, como escala e como monitora? As 5 decisões de design Projetar um agent normalmente vira 5 decisões: ...

Terça-feira, 14h. Seu colega mostra um demo: ele pede pro “agent” verificar o status de 5 servidores, identificar qual tem mais CPU usage, e criar um ticket pra investigação. O agent faz tudo sozinho. Sem scripts. Sem runbooks. Seu primeiro pensamento: “Isso é só um LLM chamando APIs, certo?” Sim. E não. O conceito é simples. A parte trabalhosa é fazer isso funcionar com segurança e previsibilidade em produção. É aí que mora a engenharia de verdade. ...

O time de ML treinou um modelo que funciona no notebook. Accuracy de 94%. Todo mundo comemora. Aí vem a parte menos glamourosa: colocar isso em produção. “Dá pra colocar isso numa API com 99.9% de uptime, latência < 200ms e 10K requests por segundo?” É aqui que system design de ML cai no colo de infra. A boa notícia é que a maior parte do problema parece familiar. Serving, rollout, observabilidade e capacity planning continuam sendo trabalho de sistema distribuído. O pedaço realmente diferente existe, mas é menor do que o hype sugere. ...

Você mudou o system prompt. O time de ML acha que ficou melhor. Mas “achar” não é métrica. Em infra, você não faz deploy sem rodar tests. Em AI, o equivalente é evals. LLM Evals são testes automatizados que medem a qualidade das respostas do modelo. É o seu test suite pro AI. Sem evals, toda mudança no pipeline (prompt, modelo, RAG, chunking) é um deploy no escuro. tl;dr: Evals são o baseline que separa melhoria real de opinião. Monte um golden dataset pequeno, rode métricas simples primeiro e compare toda mudança de prompt, modelo ou RAG antes de subir pra produção. ...

Você monta um pipeline de RAG, conecta no Azure OpenAI, e as respostas saem meia-boca. Genéricas. Às vezes o modelo ignora o contexto. Às vezes inventa. O modelo pode ser ótimo, mas a forma como você monta o input pesa muito no resultado. Context engineering é a disciplina de montar esse input de forma que o modelo entregue o que você precisa. Não é só “prompt engineering” com nome bonito. É trabalho de estrutura, constraints e trade-offs. ...

O VP de produto chega na daily: “Quero que o chatbot responda perguntas sobre nossa documentação interna. Tem 2000 páginas de runbooks, políticas, e procedimentos. O ChatGPT não sabe nada disso.” O time de ML responde: “Vamos implementar RAG.” Todo mundo faz que sim com a cabeça. Você fica com a tarefa de provisionar a infra. Antes de subir recurso, vale entender o que RAG realmente faz por dentro. tl;dr: RAG é pipeline de indexação + retrieval + prompt. O que mais quebra em produção é chunk ruim, busca ruim e custo do LLM, não falta de fine-tuning. ...

O time de ML acabou de te pedir um “vector database” em produção. Você sabe operar PostgreSQL, Redis, Cosmos DB. Mas isso? É um banco de dados ou um índice de busca? Precisa de backup? Tem replicação? Qual o modelo de consistência? Aqui dentro: o que é, como funciona por dentro, e como operar em produção. tl;dr: vector database, na prática, é um motor de busca por similaridade com índice ANN. O custo mora em RAM, recall, rebuild de índice e operação de busca, não só em “guardar vetores”. ...

Segunda-feira, 9h. Você pede pro chatbot um resumo do incidente da madrugada. Ele responde com educação, parece confiante e ainda improvisa quando não sabe. Esse comportamento não aparece por acaso: um modelo base sem alignment só completa texto estatisticamente provável. tl;dr: Reward, policy, RLHF e DPO ajudam a explicar por que um LLM ajustado parece prestativo, verboso ou confiante demais. Se você entende esse pipeline, entende melhor o comportamento do modelo em produção. ...

Sexta-feira, 17h. Você recebe um ticket do time de data science: “O modelo está retornando respostas cortadas. Parece que o context window encheu. Pode aumentar?” Você olha pro ticket. Context window? Aumentar como? Isso é configuração de infra ou limitação do modelo? É memória? É disco? Onde isso vive? Se você já passou por isso, esse post é pra você. Aqui dentro: o que cada peça de um Large Language Model faz, explicado pra quem entende de sistemas. Não pra virar ML engineer, mas pra ter vocabulário e contexto pra resolver problemas reais no dia a dia. ...