
Fundamentos de IA - Parte 4: Construindo Aplicações Reais de IA
Nos artigos anteriores, aprendemos como um LLM gera texto e como técnicas como RAG e CAG o ajudam a responder perguntas usando conhecimento externo. Neste ponto, nosso Planejador de Viagens alimentado por IA pode responder perguntas como "Estou visitando o Japão por 7 dias. Sugira um itinerário." ou "Recomende ramen vegetariano perto da Estação de Tóquio." Isso é útil, mas ainda é apenas um chatbot.
E se o usuário pedir para "Reservar o voo mais barato de Mumbai para Tóquio.", "Qual é o clima em Quioto neste fim de semana?", ou "Lembre-se de que eu prefiro comida vegetariana e sempre escolho um assento na janela."? Um LLM não pode executar essas ações por si só. Para construir aplicações de IA reais e prontas para produção, precisamos conectar o modelo ao mundo exterior. Vamos ver como isso funciona.
Chamada de Ferramenta (Chamada de Função): Deixando a IA Usar Ferramentas Externas
Suponha que o usuário pergunte: "Qual é o clima em Quioto amanhã?" Como o LLM não sabe a previsão de amanhã, nossa aplicação pode fornecer ao modelo uma API de clima. O fluxo de trabalho é simples: o LLM entende o pedido, determina que precisa da ferramenta de clima, chama a API de Clima (via a aplicação cliente), recebe os dados climáticos ao vivo e gera a resposta final fundamentada.
Usuário ──► LLM entende o pedido ──► Aplicação chama API ──► App envia resultados ──► Resposta LLM
É crítico entender que o LLM não está chamando a API diretamente. Ele simplesmente emite instruções estruturadas (tipicamente JSON) dizendo à aplicação cliente: "Para responder a isso, preciso que você chame a função de clima com o parâmetro localização='Quioto'." Sua aplicação executa a chamada real da API e alimenta o resultado de volta ao modelo.
Essa capacidade é chamada de chamada de função ou chamada de ferramenta. A ferramenta pode ser qualquer coisa: uma API de clima, um serviço de reserva de voos, um calendário, um banco de dados, um gateway de pagamento ou um sistema interno da empresa. O LLM atua como o tomador de decisões (determinando qual ferramenta usar e quando), enquanto sua aplicação atua como o executor.
💡 Conclusão do Desenvolvedor
Pense no LLM como um tomador de decisões, não um executor. Sua aplicação continua responsável por chamar APIs, lidar com autenticação, validar entradas e gerenciar falhas.
Memória: Lembrando o Usuário
Se um usuário interagiu com nosso Planejador de Viagens antes, queremos recordar suas preferências: que ele prefere comida vegetariana, viaja de trem, escolhe assentos na janela e não gosta de voos pela manhã. Quando ele pede para "Planejar minha viagem ao Japão," o planejador pode automaticamente incorporar essas escolhas. É aqui que a memória entra. Aplicações de IA geralmente utilizam dois tipos de memória:
- Memória de Curto Prazo: Este é o histórico de mensagens da conversa ativa atual. O modelo pode conectar mensagens porque elas permanecem dentro da janela de contexto ativa. Uma vez que a conversa termina ou a janela de contexto é limpa, essa informação é perdida.
- Memória de Longo Prazo (Persistente): Isso armazena informações entre conversas (por exemplo, companhia aérea favorita, restrições alimentares, aeroporto de origem). Ao contrário da memória de curto prazo, essa informação é armazenada fora do modelo - tipicamente em um banco de dados - e injetada de volta em prompts futuros quando relevante.
💡 Conclusão do Desenvolvedor
Os LLMs não lembram permanentemente os usuários por conta própria. A memória persistente de longo prazo é uma característica em nível de aplicação (salvando dados em um banco de dados e carregando-os no contexto) em vez de uma capacidade inerente do modelo.
MCP (Protocolo de Contexto do Modelo): Padronizando Conexões
À medida que as aplicações de IA crescem, os desenvolvedores enfrentam um desafio: cada ferramenta requer uma integração personalizada. Conectar um LLM ao Google Calendar, Slack, GitHub, Jira, PostgreSQL e bancos de dados de viagens externos usando diferentes wrappers personalizados pode rapidamente levar a um código bagunçado.
O Protocolo de Contexto do Modelo (MCP) padroniza essa integração. Assim como o USB serve como um padrão universal permitindo que um computador se conecte a qualquer teclado, mouse ou disco sem precisar de conectores de hardware personalizados, o MCP padroniza como os modelos descobrem, acessam e consultam ferramentas externas. Em vez de reescrever endpoints de wrappers personalizados para cada ferramenta, os desenvolvedores escrevem servidores MCP que expõem capacidades em um formato padronizado.
💡 Conclusão do Desenvolvedor
O MCP não substitui APIs; ele padroniza o esquema e a camada de transporte, tornando muito mais fácil para as aplicações de IA descobrirem e aproveitarem-nas.
Agentes de IA: Fluxos de Trabalho Orquestrados
Quando um usuário diz: "Planeje uma viagem de 5 dias ao Japão em outubro. Reserve voos, recomende restaurantes vegetarianos, verifique o clima e crie um itinerário no calendário." ele não está pedindo uma resposta simples. Ele está pedindo uma sequência de tarefas:
- Pesquisar guias de viagem usando RAG/CAG.
- Verificar previsões do tempo via ferramentas.
- Pesquisar voos e hotéis.
- Filtrar por restrições alimentares usando memória.
- Criar um cronograma no calendário.
- Montar uma resposta de itinerário unificado.
A combinação de raciocínio, uso de ferramentas, memória e conhecimento externo trabalhando em um ciclo para alcançar um objetivo de múltiplas etapas é o que chamamos de agente de IA. Um agente não é um novo tipo de modelo; é um sistema de orquestração construído em torno de um LLM.
💡 Conclusão do Desenvolvedor
A maioria dos agentes de IA em produção são frameworks de orquestração de wrappers (como LangChain, AutoGen ou máquinas de estado personalizadas) projetados para coordenar decisões de modelos e saídas de ferramentas - eles não são bases de código autônomas mágicas.
LLM vs. SLM: Escolhendo a Escala Certa
Embora tenhamos nos concentrado principalmente em LLMs, você também encontrará o termo SLM (Modelo de Linguagem Pequeno). A diferença é principalmente a escala:
| LLM (Modelo de Linguagem Grande) | SLM (Modelo de Linguagem Pequeno) |
|---|---|
| Tamanhos de parâmetros enormes (70B+) | Tamanhos de parâmetros menores (1B - 8B) |
| Altos requisitos de computação/GPU | Leve, pode muitas vezes ser executado localmente |
| Raciocínio complexo excepcional | Otimizado para tarefas focadas e específicas |
| Alta latência de API e custos | Inferência mais rápida e mais barato para hospedar |
Por exemplo, um assistente de suporte ao cliente focado em responder perguntas frequentes pode funcionar perfeitamente em um SLM, economizando custos e latência massivos em comparação com um enorme LLM.
💡 Conclusão do Desenvolvedor
Sempre avalie o menor modelo que pode resolver seu problema de forma confiável. Executar um SLM otimizado leva a melhor latência, menores custos de computação e maior controle.
Modelos Fechados vs. Modelos Abertos
- Modelos Fechados: Modelos proprietários oferecidos exclusivamente via APIs em nuvem (como modelos da OpenAI, Anthropic ou Google). Você não pode acessar os pesos subjacentes do modelo, mas obtém capacidades de ponta com zero sobrecarga de hospedagem.
- Modelos de Pesos Abertos: Modelos que tornam seus pesos treinados publicamente disponíveis (como o Llama da Meta ou o Gemma do Google). Isso permite que os desenvolvedores hospedem, executem e ajustem modelos em seus próprios servidores ou hardware local, oferecendo total privacidade e controle de personalização ao custo da gestão da infraestrutura de hospedagem.
Modelos Multimodais: Além do Texto
Modelos de IA modernos não estão mais limitados ao processamento de texto;
Empresas brasileiras podem se beneficiar ao integrar LLMs com APIs para automatizar serviços e melhorar a experiência do cliente. O uso do MCP pode simplificar a integração de diferentes ferramentas, aumentando a eficiência operacional. Isso é crucial para se manter competitivo na era digital.

