Quer entender IA, mas não sabe por onde começar?

Se você precisasse separar milhares de fotos de gatos e cachorros, poderia começar tentando escrever regras: o formato da orelha, o tamanho do focinho, o tipo de pelo. Só que as fotos variam muito. Uma imagem pode estar escura, mostrar só parte do animal ou ter um ângulo diferente. Em vez de antecipar cada situação, você pode mostrar exemplos ao sistema para que ele encontre características que ajudam a distinguir os dois.

Esse é um exemplo de aprendizado de máquina, ou Machine Learning. Durante uma etapa chamada treinamento, o sistema ajusta seus cálculos usando os dados apresentados. Depois, você pode mostrar uma foto que não fazia parte daqueles exemplos e avaliar se ele consegue classificá-la. O resultado desse treinamento é um modelo: um conjunto de cálculos ajustados para realizar uma tarefa. Aprender, aqui, tem esse sentido específico; não significa aprender da mesma forma que uma pessoa.

Inteligência artificial é o campo mais amplo em que esse trabalho se encaixa. Ele reúne técnicas para tarefas como reconhecer imagens, trabalhar com linguagem e tomar decisões. Machine Learning é uma parte desse campo. Dentro dele está o Deep Learning, que usa redes neurais com várias camadas de processamento. Cada camada transforma a informação recebida e passa o resultado adiante. Juntas, essas transformações permitem representar relações complexas nos dados, como as características de uma imagem.

Já “generativa” descreve o que uma IA faz: produz conteúdo, como texto, imagem ou áudio, a partir de padrões aprendidos. Um sistema pode usar uma rede neural para classificar uma foto; outro pode usar esse tipo de técnica para gerar uma imagem. Ou seja, Deep Learning e IA generativa não são nomes intercambiáveis. Um descreve uma família de técnicas, e o outro, uma capacidade do sistema.

Eu começaria organizando esses nomes assim: IA é o campo; Machine Learning é uma maneira de construir sistemas que aprendem com dados; Deep Learning é uma família de técnicas dentro desse aprendizado; e geração é uma das capacidades que podemos desenvolver com elas. Essa relação ajuda você a entender o que uma ferramenta faz antes de comparar nomes de produtos. Agora vamos olhar para um tipo de modelo generativo que trabalha com texto.

Se eu começo a frase “hoje eu vou tomar um...”, você consegue pensar em várias continuações: café, suco, banho. Se antes eu disser que acabei de acordar e estou preparando o café da manhã, algumas dessas opções passam a fazer mais sentido. O texto que já existe muda as possibilidades do que pode vir depois. Essa relação é um ponto de partida para entender um grande modelo de linguagem, ou LLM, da expressão em inglês Large Language Model.

Um LLM passa por um treinamento com grandes quantidades de texto. Nesse processo, seus cálculos são ajustados para captar relações entre as partes desse material. Ele aprende padrões de linguagem, mas também relações que aparecem em explicações, conversas e código. Quando você faz uma pergunta, o modelo usa esses padrões e a informação disponível naquela interação para calcular possíveis continuações.

A resposta é construída aos poucos. O modelo calcula probabilidades para a próxima unidade de texto, uma delas é escolhida, essa unidade entra na sequência e o processo se repete. O que acabou de ser gerado passa a fazer parte do texto considerado no passo seguinte. A forma de escolher entre as possibilidades pode variar, então a resposta nem sempre será idêntica, mesmo diante de um pedido parecido.

Você vai ouvir bastante a expressão “prever a próxima palavra”. Ela ajuda a visualizar o processo, mas a unidade real se chama token e pode ser uma palavra ou apenas parte dela. Vamos detalhar isso no próximo conceito. Por enquanto, o que importa é perceber que a resposta inteira nasce dessa sequência de escolhas, levando em conta o que veio antes.

Esse funcionamento permite produzir respostas úteis, inclusive explicações e código. Ao mesmo tempo, uma continuação provável não é uma informação necessariamente verdadeira. O modelo pode escrever algo que combina muito bem com a pergunta sem ter uma fonte que comprove aquilo. Quando eu uso um LLM, considero tanto a qualidade da resposta quanto o que consigo conferir. No experimento a seguir, você vai construir uma frase e observar como cada escolha muda a continuação.

Quando você está trabalhando, precisa ter algumas informações à mão: o pedido que recebeu, um documento de apoio, talvez uma anotação do que já tentou. Com uma aplicação de IA, também é preciso definir que informação estará disponível para produzir a próxima resposta. Esse conjunto é o contexto. Ele pode incluir instruções, sua pergunta, partes da conversa e documentos que a aplicação entregou ao modelo.

Para processar um texto, o sistema primeiro o divide em unidades chamadas tokens. Uma palavra pode corresponder a um único token ou ser dividida em vários. Pontuação também pode fazer parte dessa divisão. Quem faz essa separação é o tokenizer, o componente que transforma o texto nessas unidades. Por isso, contar palavras ou caracteres não dá a contagem exata de tokens: a divisão depende do tokenizer usado pelo modelo.

A janela de contexto é o limite de informação que o modelo consegue considerar em uma interação. Pense no espaço disponível na sua mesa de trabalho: você precisa escolher quais papéis estarão ali quando for resolver o problema. No sistema, esse espaço é medido em tokens. As instruções, o histórico enviado e os resultados de ferramentas usam parte desse limite. Também é preciso respeitar os limites de tamanho da resposta que será gerada.

Isso explica uma diferença que costuma causar confusão: dar à aplicação acesso a uma pasta não significa que todos os arquivos já estejam no contexto. Ela pode ter permissão para abrir os arquivos e ainda precisar escolher quais ler e quais trechos enviar ao modelo. Da mesma forma, o fato de você ter dito algo no começo de uma conversa longa não garante que esse trecho continue sendo enviado em todas as próximas interações.

Mesmo quando tudo cabe na janela, mais informação pode atrapalhar. Ao preencher o contexto com documentos, conversas antigas e instruções de importâncias diferentes, você coloca materiais relevantes e irrelevantes disputando a atenção do modelo. Atenção, aqui, é o mecanismo usado para relacionar as partes do texto; não é uma atenção consciente como a nossa. O modelo pode dar peso a um detalhe secundário e deixar passar uma condição importante, inclusive por causa da posição em que ela aparece.

À medida que o contexto fica mais longo e cheio de ruído, o modelo pode ter mais dificuldade para recuperar a informação necessária e usá-la no raciocínio. Essa perda de desempenho varia conforme o modelo e a tarefa. Uma janela máxima maior oferece mais espaço, mas preencher esse espaço não garante uma resposta melhor. Eu procuro otimizar o contexto de cada tarefa: manter as instruções necessárias, selecionar os documentos pertinentes e trazer novos trechos conforme o trabalho pede.

Em projetos de programação, um arquivo AGENTS.md pode ajudar a orientar essa busca. Nas ferramentas que reconhecem esse arquivo, ele reúne instruções para o agente trabalhar no projeto. Além de regras gerais, pode indicar onde estão os documentos de cada área e quando consultá-los. Por exemplo: “Antes de alterar pagamentos, leia a documentação em docs/pagamentos; para mudanças na interface, consulte o guia de componentes”. Assim, você oferece um mapa para encontrar o contexto necessário, em vez de colocar toda a documentação em cada pedido.

O AGENTS.md também precisa ser objetivo. Se você copiar tudo para dentro dele, volta ao mesmo problema de excesso de contexto. A ideia é manter ali as orientações essenciais e os caminhos para os detalhes, que o agente pode buscar com as ferramentas disponíveis quando forem relevantes. Isso orienta o processo, mas ainda é preciso conferir se a documentação necessária foi consultada.

Para investigar um erro, por exemplo, eu começaria pela mensagem de erro, pelo comportamento esperado e pelo código relacionado. Se a investigação mostrar que uma regra de pagamentos está envolvida, esse é o momento de consultar sua documentação. Essa seleção pode reduzir custo em serviços cobrados por tokens e ajudar o modelo a trabalhar com informação mais pertinente. Economizar contexto não é retirar dados necessários: é escolher o que ajuda em cada etapa. O próximo experimento mostra uma divisão aproximada em tokens para você observar essa unidade.

Pense em como você começou a usar um chatbot com um modelo de linguagem. Você fazia uma pergunta, recebia uma resposta e decidia o que fazer com ela. Se pedisse uma correção de código, por exemplo, precisava copiar a sugestão, executar no seu projeto e voltar à conversa com o erro encontrado. O modelo ajudava a produzir a solução, mas várias etapas do trabalho ainda dependiam de você levar a informação de um lugar para outro.

Para entender a passagem desses chatbots aos agentes, vale observar o que foi sendo acrescentado às aplicações. Uma mudança importante foi conectar o modelo a ferramentas: funções que permitem pesquisar na internet, consultar um sistema, ler arquivos ou executar código. Quando o modelo solicita uma dessas operações, a aplicação a executa e devolve o resultado. Assim, ele passa a trabalhar também com informação obtida durante a tarefa, além do texto que você escreveu na conversa.

Outra mudança foi organizar essas ações em um ciclo. Em vez de terminar depois de uma resposta ou de uma consulta, o sistema pode devolver o resultado ao modelo para que ele decida como continuar. Se faltou informação, ele pode escolher uma nova busca. Se um teste falhou, pode usar a mensagem de erro para orientar outra tentativa. Isso permite executar tarefas com vários passos sem você precisar conduzir manualmente cada um deles.

É nesse funcionamento que entra a definição que vamos usar aqui: um agente de IA é um sistema que usa um modelo para escolher e executar ações em direção a um objetivo, observando os resultados para decidir os próximos passos. Nos agentes baseados em LLMs desta trilha, o modelo, as ferramentas e esse ciclo de decisão trabalham juntos. O agente pode agir com diferentes graus de autonomia, sempre dentro das capacidades e permissões que a aplicação oferece.

A ideia de agente já existia na inteligência artificial antes dos chatbots com LLMs. O que estamos acompanhando aqui é a evolução dessas aplicações de linguagem, que passaram a combinar conversa, ferramentas e execução de tarefas. E uma interface de chat pode continuar sendo a entrada para um agente: você conversa com o sistema, enquanto ele busca informações e realiza ações. O formato da tela, sozinho, não diz como o sistema funciona.

Mas conectar uma ferramenta não basta para caracterizar um agente. Imagine um programa que busca mensagens de atendimento, pede ao modelo para classificá-las e salva as categorias. Se a sequência é sempre buscar, classificar e salvar, quem controla as etapas é o programa. Já em um agente de atendimento, o modelo pode decidir consultar o histórico de um pedido e, conforme o resultado, pedir uma informação ou escolher outra consulta. A diferença está em quem decide como continuar.

Arquitetura de IA é a organização dessas peças: o modelo, as informações que ele recebe, as ferramentas disponíveis, as regras de execução e a forma de conferir o resultado. Eu gosto de começar pelo trabalho que precisa ser feito. Uma sequência conhecida pode ser atendida por uma automação; uma tarefa cujo caminho depende do que for descoberto pode se beneficiar de um agente. Entender essa evolução ajuda você a reconhecer o funcionamento por trás dos nomes. No próximo conceito, vamos olhar mais de perto para o ciclo que permite passar de uma instrução à execução.

Quando você pede uma alteração à IA, recebe o código, executa e encontra um erro, provavelmente volta à conversa para mostrar o que aconteceu. A IA propõe outra alteração e você testa de novo. Você já está conduzindo um ciclo: pedir, executar, observar o resultado e decidir a próxima tentativa. O trabalho vai além da primeira instrução enviada.

Essa instrução é o prompt. Ele pode descrever o objetivo, trazer restrições e explicar como a resposta deve ser entregue. Um bom prompt ajuda o modelo a entender a tarefa. Mas, quando a tarefa exige agir e verificar, a instrução inicial não contém tudo: parte da informação só aparece depois que uma ação acontece, como a mensagem de um teste que falhou.

Loop é o nome desse ciclo de execução e observação. Em um sistema com agente, uma ferramenta executa a ação escolhida pelo modelo e devolve o resultado. O modelo recebe essa informação no contexto e decide como continuar. Por exemplo: lê o código relacionado ao erro, propõe uma correção, executa os testes e usa a falha encontrada para revisar a tentativa. É uma sequência que pode se repetir até uma condição de encerramento.

Essa condição precisa ser definida. Para corrigir um erro, passar no teste que reproduz o problema pode ser parte da verificação, junto com conferir se o comportamento esperado foi atendido. Também é preciso limitar o número de tentativas, o tempo ou o custo, além de prever quando pedir sua ajuda. Sem isso, o sistema pode continuar gastando recursos em tentativas que não avançam.

Eu penso no prompt e no loop como partes do mesmo trabalho: a instrução orienta o que fazer, e o ciclo permite lidar com o que acontece durante a execução. O ganho está em usar o resultado de cada tentativa para decidir melhor a próxima. Esse mecanismo vai aparecer de novo quando juntarmos modelo, ferramentas e autonomia no conceito de agente.

Se você perguntar a uma IA qual é a regra de reembolso da empresa, de onde ela vai tirar essa informação? O modelo pode conhecer políticas parecidas, mas isso não significa que conheça o documento que vale ali. A resposta precisa se apoiar em uma fonte específica. É o mesmo cuidado que você teria ao consultar uma regra: encontrar o documento pertinente antes de afirmar o que ele permite.

RAG é a sigla em inglês para geração aumentada por recuperação. “Recuperação”, aqui, significa buscar informação em uma base de documentos. O sistema recebe a pergunta, procura trechos relacionados a ela e coloca esse material no contexto do modelo. Só então o modelo prepara uma resposta usando a pergunta e os trechos recebidos. O documento entra como informação para aquela resposta; esse processo não significa treinar o modelo de novo.

Uma base pode ter documentos longos demais para serem enviados inteiros a cada pergunta. Por isso, é comum organizá-los em trechos e selecionar os mais relevantes. A busca pode considerar o significado, além das palavras exatas: alguém que pergunta “como recebo meu dinheiro de volta?” pode precisar do trecho que fala em “reembolso”. É importante preservar informação suficiente para que uma condição ou exceção não fique separada da regra que ela modifica.

Depois da busca, a qualidade da resposta ainda depende do material selecionado. Um aviso antigo pode trazer um prazo que já mudou. Um trecho incompleto pode fazer parecer que uma regra vale para todos, quando há uma condição no parágrafo seguinte. E um documento relevante pode ser interpretado de forma errada pelo modelo. RAG oferece informação para trabalhar, mas não garante uma resposta correta.

Eu olho para esse processo em duas partes: conseguimos buscar a informação necessária e conseguimos responder de acordo com ela? Conferir a fonte, a data e os trechos que sustentam a resposta ajuda a avaliar as duas. Também é preciso respeitar quais documentos a pessoa tem permissão para acessar. No experimento, você vai escolher o contexto de uma pergunta e observar o efeito de fornecer informação atual, antiga ou que não responde à dúvida.

Até aqui, vimos que um modelo pode produzir texto e que a aplicação pode preparar informações para ele. Mas como uma IA passa de sugerir o que fazer para executar uma tarefa? Pense em um pedido como “investigue este erro e proponha uma correção”. Para avançar, o sistema precisa ler arquivos, consultar o resultado de testes e decidir o que vale tentar em seguida. Só escrever uma resposta inicial não conclui esse trabalho.

Um agente combina modelo, ferramentas e um loop de decisão. O modelo interpreta o objetivo e escolhe a próxima ação entre as que estão disponíveis. A aplicação executa essa ação por meio de uma ferramenta e entrega o resultado ao modelo. Com essa nova informação, ele pode escolher outra ação, pedir ajuda ou encerrar. É a decisão sobre como continuar, alimentada pelo que acabou de acontecer, que caracteriza esse comportamento.

Ferramenta, nesse caso, é uma capacidade que a aplicação oferece ao modelo para interagir com algo fora do texto que ele gera. Pode ser ler um arquivo, pesquisar documentos, consultar um sistema ou executar um teste. O modelo indica a operação que quer realizar e os dados necessários; quem realiza a operação é o software que implementa a ferramenta. A resposta dessa operação volta para o ciclo.

No exemplo do erro, o agente pode começar lendo um arquivo, perceber que precisa de outro, alterar o código e executar os testes. Se a execução revelar uma falha diferente, essa observação orienta a próxima tentativa. Em uma automação fixa, por outro lado, o programa já determina as etapas e o modelo pode apenas classificar ou escrever algo no meio delas. Ambos podem ser úteis, mas o controle do próximo passo é diferente.

A autonomia do agente depende das permissões e dos limites definidos pela aplicação. Ler um documento, editar um arquivo e publicar uma alteração são ações com consequências diferentes. Eu continuo responsável por decidir o que ele pode fazer e o que precisa de revisão. Também não confundo esse ciclo com aprendizado permanente: usar o resultado de uma ação no contexto não significa atualizar o treinamento do modelo. No experimento, vamos observar essas diferenças em situações concretas.

Imagine que você quer usar duas aplicações de IA para consultar os mesmos documentos da empresa. Se cada aplicação exigir uma integração completamente diferente com o sistema de documentos, esse trabalho precisa ser repetido. E, quando você acrescenta outros sistemas, como uma agenda ou uma base de código, o número de conexões para construir e manter aumenta. É esse problema de integração que o MCP ajuda a organizar.

MCP significa Model Context Protocol. É um padrão de comunicação que permite conectar aplicações de IA a dados e ferramentas externas. Pense em uma conexão com um formato combinado: os dois lados sabem como apresentar as capacidades disponíveis, fazer pedidos e devolver resultados. Isso facilita a integração entre aplicações e servidores compatíveis, em vez de cada par precisar inventar toda a comunicação do zero.

Existem papéis diferentes nessa conexão. A aplicação que você usa, como um assistente de programação, mantém um cliente MCP. O cliente se comunica com um servidor MCP, que oferece acesso a determinados recursos ou operações. Por exemplo, um servidor pode disponibilizar uma ferramenta de busca em documentos. A aplicação descobre essa capacidade, envia uma consulta e recebe o resultado para usar no trabalho com o modelo.

O protocolo organiza a troca de informação; as decisões sobre quando buscar e o que fazer com o resultado pertencem ao sistema que usa essa conexão. Por isso, MCP e agente não são a mesma coisa. Um agente pode usar ferramentas disponibilizadas por MCP, mas o protocolo não define por conta própria o objetivo, o loop de execução ou a ordem das tarefas.

Também é preciso configurar o acesso. Um padrão de comunicação não dá automaticamente permissão para ler qualquer documento ou executar qualquer operação. Eu separo essas decisões: quais capacidades o servidor oferece, quais a aplicação pode usar e quais ações precisam da sua confirmação. Assim fica mais claro o que o MCP resolve e quais responsabilidades continuam na arquitetura da aplicação.

Se um modelo consegue escolher uma ferramenta, quem prepara a lista de ferramentas disponíveis? Quem entrega o resultado da execução de volta a ele? Quem limita o custo e registra o que aconteceu? Essas funções precisam existir para o agente trabalhar. Ao comparar aplicações de IA, vale olhar também para esse sistema ao redor do modelo, porque ele influencia o que a aplicação consegue fazer.

Harness é o nome usado para esse ambiente de execução e controle. Ele organiza o contexto que chega ao modelo, disponibiliza ferramentas, aplica permissões e acompanha o ciclo de trabalho. Pense em uma oficina: a pessoa que realiza uma tarefa depende das ferramentas disponíveis, das instruções, das condições de segurança e de uma forma de conferir a entrega. No agente, essas condições são organizadas por software.

Orquestração é a coordenação das etapas e de quem participa de cada uma. Uma tarefa pode depender de outra: para implementar uma alteração, você precisa saber o comportamento esperado. Outras podem acontecer em paralelo: duas pesquisas independentes podem ser feitas ao mesmo tempo e reunidas depois. A coordenação define o que cada etapa recebe, o que entrega e quando a próxima pode começar.

Um grafo é uma maneira de representar essas relações. Você desenha pontos para as tarefas e ligações para mostrar as dependências. Isso ajuda a visualizar, por exemplo, que pesquisa e definição orientam a implementação, e que a revisão precisa examinar o resultado implementado. Essa estrutura pode coordenar um agente ou vários, dependendo do problema. Ter mais agentes não é um requisito para organizar bem o trabalho.

Eu procuro uma organização que permita entender onde uma informação se perdeu, verificar uma entrega e repetir uma etapa quando necessário. Dividir trabalho demais também tem custo: cada participante precisa receber contexto e seus resultados precisam ser reunidos. Harness e orquestração ajudam a estruturar esse processo, mas a escolha das etapas precisa fazer sentido para a tarefa que você quer resolver.

Se você pedir à IA “crie uma tela de cadastro”, ela terá de preencher várias decisões que ficaram abertas. Que dados serão pedidos? O que acontece se o e-mail já existir? A pessoa precisa confirmar o cadastro? A tela pode aparecer funcionando e ainda assim se comportar de uma forma diferente da que você precisava. O problema começa na distância entre o pedido e o comportamento esperado.

Vibe coding costuma descrever uma forma de construir em que você pede alterações, observa o resultado e vai ajustando, sem acompanhar em detalhe o código gerado. Isso permite experimentar uma ideia, mas também pode deixar decisões importantes escondidas na implementação. A aparência de que algo funciona não mostra, sozinha, como ele vai lidar com erros ou situações que você ainda não experimentou.

No desenvolvimento orientado por especificação, ou Spec-driven, você registra o que deve acontecer antes de implementar. A especificação descreve o problema, o comportamento esperado, as regras e os critérios para conferir a entrega. No cadastro, ela poderia dizer quais campos são obrigatórios, o que mostrar quando já existe uma conta e quais condições significam que a tarefa está concluída.

Esse documento dá ao trabalho um ponto de comparação: em vez de avaliar apenas se gostou do resultado, você verifica se ele atende ao que foi combinado. Quando há uma dúvida, ela pode ser resolvida antes de virar código. Se a decisão mudar, a especificação precisa acompanhar a mudança para continuar orientando a implementação e a revisão.

Para transformar esse cuidado em um procedimento que o agente consegue repetir, podemos usar Skills. No trabalho com agentes, uma Skill é um conjunto de instruções para uma tarefa ou um tipo de trabalho. Ela pode reunir orientações, exemplos, arquivos de apoio e scripts. Enquanto a especificação registra o que precisa ser entregue, a Skill orienta como conduzir uma etapa do trabalho, como esclarecer o pedido, implementar uma alteração ou revisar o resultado.

As Skills do Matt Pocock são uma forma de aplicar esse processo na prática. A coleção reúne procedimentos para esclarecer requisitos, transformar uma conversa em especificação, dividir o trabalho em tarefas, implementar e revisar. Você pode combinar essas orientações conforme a necessidade do projeto. A relação com Spec-driven está em usar o comportamento combinado como referência ao longo da execução, em vez de deixar cada etapa interpretar o pedido de um jeito diferente.

No exemplo do cadastro, você pode começar esclarecendo quais campos serão obrigatórios e como tratar um e-mail já registrado. Essas decisões entram na especificação. Na implementação, uma Skill orienta o agente a consultar as regras do projeto e trabalhar a partir desse documento. Na revisão, outra orienta a comparar o código com os critérios combinados e verificar os testes. A especificação dá a referência; as Skills ajudam a transformar essa referência em um processo de trabalho.

A Skill entra como orientação para o agente. Ela não é um modelo novo nem modifica automaticamente o treinamento do modelo que você está usando. Também não basta instalar uma coleção para garantir que o processo será seguido: o material precisa estar disponível, ser adequado à tarefa e ser usado com as ferramentas e permissões do projeto. Skills podem apoiar outras formas de trabalho além de Spec-driven; aqui, estamos usando esse recurso para organizar o desenvolvimento a partir de uma especificação.

Eu prefiro explicitar essas decisões em um tamanho proporcional à tarefa. Uma alteração pequena pode precisar de poucas linhas claras; um fluxo com várias regras pede mais detalhe. Também vale ler e adaptar as Skills antes de adotá-las. Escrever a especificação e usar uma Skill não torna o código automaticamente correto: testes e revisão continuam necessários. O ganho é ter uma base comum para pedir, construir e conferir a entrega.

Considere um sistema que recebe mensagens e precisa encaminhá-las para o atendimento certo: cobrança, suporte técnico ou outro assunto. Antes de preparar uma resposta, há uma decisão mais delimitada a tomar: em qual categoria essa mensagem se encaixa? O resultado necessário nessa etapa é uma escolha entre opções conhecidas.

Modelos de decisão, no uso que estamos discutindo aqui, são modelos voltados a esse tipo de classificação, triagem e encaminhamento. Eles recebem uma entrada e trabalham com alternativas definidas para produzir uma escolha. Um modelo pequeno e especializado pode realizar essa tarefa com menos tempo e custo do que usar um grande modelo de linguagem para gerar uma resposta extensa. Essa vantagem precisa ser avaliada para o caso em que ele será usado.

No atendimento, por exemplo, a mensagem chega, o modelo identifica a categoria e o sistema a envia ao fluxo correspondente. Depois disso, outra etapa pode consultar documentos ou preparar uma resposta com um LLM. A classificação e a geração de texto cumprem funções diferentes dentro do mesmo sistema. Assim, você pode escolher a peça adequada para cada parte do trabalho.

Ter um formato de saída previsível não significa que a decisão estará sempre correta. Uma mensagem pode misturar cobrança e problema técnico, ou não se encaixar bem nas categorias disponíveis. É preciso avaliar esses casos e definir como lidar com dúvida, erro e situações que exigem uma pessoa. O cuidado é ainda maior quando o encaminhamento tem consequências importantes.

Eu vejo esses modelos como mais uma possibilidade de arquitetura. Depois de entender modelos de linguagem, contexto, busca, agentes e organização do trabalho, você consegue perguntar o que cada etapa realmente precisa entregar. Às vezes será uma explicação, às vezes uma busca, às vezes uma ação ou uma classificação. Essa visão ajuda a escolher como usar IA a partir do problema que você quer resolver.