Do dado estruturado à resposta contextualizada: construindo o EDU com Python, Streamlit, Ollama e Llama 3.2

A Inteligência Artificial Generativa tornou relativamente simples criar um chatbot.

Uma interface, uma pergunta, uma chamada para um Large Language Model e uma resposta.

Mas existe uma diferença importante entre conversar com um LLM e construir uma aplicação de IA capaz de utilizar informações relevantes sobre determinado contexto.

Foi justamente essa diferença que procurei explorar no desenvolvimento do EDU — Agente Financeiro Inteligente com IA Generativa, projeto desenvolvido como desafio do Bootcamp GenAI da DIO em parceria com o Bradesco.

O objetivo não era construir um “consultor financeiro com IA”.

Era investigar uma questão mais interessante:

Como transformar dados estruturados em contexto para que um LLM produza respostas mais relevantes, mantendo limites claros sobre aquilo que ele deve ou não fazer?

A resposta passou por Python, Streamlit, Ollama, Llama 3.2, Pandas, dados em JSON e CSV, Prompt Engineering, guardrails e, principalmente, Context Engineering.

Do dado à resposta contextualizada

Uma resposta gerada por IA depende não apenas do modelo utilizado, mas também das informações que chegam até ele.

Se perguntarmos simplesmente:

“Como está minha reserva de emergência?”

um modelo sem informações adicionais não conhece renda, patrimônio, objetivo financeiro ou reserva atual daquele usuário.

O problema, portanto, não é necessariamente o modelo.

Falta contexto.

No EDU, organizei quatro fontes de dados demonstrativos:

Perfil do Investidor
      +
Transações Financeiras
      +
Histórico de Atendimento
      +
Produtos Financeiros

Cada uma desempenha um papel diferente.

O perfil contém informações como renda, objetivo financeiro, patrimônio, reserva atual e perfil de investidor.

As transações permitem observar movimentações e categorias de despesas.

O histórico registra interações anteriores.

E a base de produtos fornece informações educativas sobre diferentes produtos financeiros.

Separadamente, são apenas dados.

Quando selecionados, organizados e incorporados à interação com o modelo, passam a formar contexto.

A arquitetura do EDU

A aplicação foi construída com uma arquitetura relativamente simples:

Usuário
 ↓
Streamlit
 ↓
Pergunta
 ↓
Dados Estruturados
 │
 ├── Perfil
 ├── Transações
 ├── Histórico
 └── Produtos
 ↓
Context Engineering
 ↓
System Prompt + Guardrails
 ↓
Ollama
 ↓
Llama 3.2
 ↓
Resposta Contextualizada
 ↓
Usuário

A interface é construída em Streamlit, enquanto o processamento dos dados tabulares utiliza Pandas.

Para inferência, optei por Ollama com Llama 3.2, executado localmente.

Essa escolha também trouxe outra dimensão interessante para o projeto: experimentar uma aplicação de IA Generativa sem depender de uma API externa para a inferência do LLM.

Context Engineering: o ponto central

Uma das partes mais importantes do projeto é a construção do contexto.

Conceitualmente, o processo funciona assim:

Dados
 ↓
Seleção
 ↓
Organização
 ↓
Contextualização
 ↓
Prompt
 ↓
LLM

Parece uma diferença pequena, mas muda bastante a forma de pensar uma aplicação de IA.

Em vez de perguntar apenas:

“Qual prompt devo escrever?”

passamos a perguntar:

“Quais informações o modelo precisa receber para responder adequadamente?”

Essa segunda pergunta aproxima muito mais o desenvolvimento de IA de problemas reais de negócio.

Nem todo dado precisa entrar no contexto

Outro aprendizado importante foi perceber que construir contexto não significa despejar todos os dados disponíveis no prompt.

No EDU, estabeleci limites para determinadas fontes:

Transações → até 10 registros
Histórico → até 5 registros
Produtos → até 5 produtos

Isso introduz um princípio importante:

Mais contexto não significa necessariamente melhor contexto.

Precisamos considerar relevância, tamanho, redundância e finalidade.

Em aplicações maiores, essa questão se torna ainda mais importante.

Imagine uma empresa com milhares de clientes, milhões de transações e anos de interações armazenadas.

Não seria razoável simplesmente colocar tudo no prompt.

Precisaríamos determinar qual informação recuperar, quando recuperar e por que ela é relevante para aquela interação.

É exatamente aí que começam a aparecer conceitos como recuperação de informação, embeddings, busca semântica, bancos vetoriais e RAG.

Guardrails: dizer ao modelo o que ele não deve fazer

O domínio financeiro introduz outro problema.

Um protótipo educacional não deveria se apresentar como responsável por aconselhamento financeiro individual.

Por isso, o EDU utiliza um SYSTEM_PROMPT que estabelece regras para o comportamento do agente.

Entre elas:

• não recomendar investimentos específicos;
• manter o foco em educação financeira e finanças pessoais;
• utilizar os dados fornecidos como contexto;
• utilizar linguagem simples;
• reconhecer quando determinada informação não está disponível.

A lógica pode ser representada assim:

Pergunta
 ↓
Regras
 ↓
Contexto
 ↓
LLM
 ↓
Resposta

Existe, entretanto, uma distinção importante.

Os guardrails desta versão são predominantemente baseados em instruções no prompt.

Isso não equivale a possuir uma camada independente e determinística de segurança.

Em uma aplicação real, especialmente em um domínio sensível como finanças, seria necessário pensar também em validação de entrada, classificação de intenção, validação de saída, políticas de acesso, observabilidade e governança.

Essa diferença entre protótipo funcional e arquitetura de produção precisa ser explícita.

Por que usar um LLM local?

Para o projeto, utilizei Ollama executando o Llama 3.2:1b.

A aplicação se comunica com o Ollama localmente:

Python / Streamlit
      ↓
   Ollama
      ↓
 Llama 3.2
      ↓
 Local Inference

Essa arquitetura permite experimentar algumas características interessantes.

Uma delas é maior controle sobre onde ocorre a inferência.

Outra é a possibilidade de testar modelos diferentes sem estruturar toda a aplicação em torno de um único provedor externo.

Isso não significa que “local” seja automaticamente melhor que “cloud”.

Existem trade-offs envolvendo hardware, desempenho, qualidade do modelo, manutenção, escalabilidade e segurança.

Mas, como exercício de arquitetura, trabalhar com um Local LLM acrescentou uma dimensão importante ao projeto.

A interface também faz parte da solução

O EDU utiliza os componentes conversacionais do Streamlit:

st.chat_input()
st.chat_message()

e mantém as mensagens durante a sessão utilizando:

st.session_state

Isso cria uma experiência semelhante a um chat.

Mas existe uma lição importante aqui:

um agente não é apenas o LLM.

A experiência completa envolve:

Interface
  +
Dados
  +
Contexto
  +
Regras
  +
Modelo
  +
Tratamento de Erros
  =
Aplicação de IA

O modelo é uma parte fundamental, mas é apenas uma parte da arquitetura.

Tratamento de erros também importa

Outro aspecto que procurei incluir foi o tratamento de situações em que algo não funciona como esperado.

A aplicação considera problemas como:

• arquivo inexistente;
• JSON inválido;
• erro na leitura dos dados;
• Ollama indisponível;
• erro de conexão;
• timeout;
• resposta HTTP inesperada.

Em projetos demonstrativos, é fácil concentrar toda a atenção no cenário ideal:

Pergunta → LLM → Resposta

Aplicações reais precisam pensar também em:

Pergunta
 ↓
Algo falhou?
 ↓
Como detectar?
 ↓
Como tratar?
 ↓
O que mostrar ao usuário?

Essa mudança de perspectiva é importante quando começamos a sair de notebooks experimentais para aplicações.

O que eu faria na próxima versão

O EDU ainda é um protótipo.

E isso também ajuda a visualizar claramente seu roadmap.

Uma evolução natural seria incorporar RAG — Retrieval-Augmented Generation.

Hoje o contexto é montado diretamente a partir dos dados disponíveis.

Uma arquitetura futura poderia funcionar assim:

Pergunta
 ↓
Busca / Recuperação
 ↓
Informação Relevante
 ↓
Contexto
 ↓
LLM
 ↓
Resposta

Com uma base maior:

Documentos
 ↓
Chunking
 ↓
Embeddings
 ↓
Vector Database
 ↓
Semantic Search
 ↓
Contexto Recuperado
 ↓
LLM

Outras evoluções seriam:

• embeddings;
• banco vetorial;
• seleção dinâmica de contexto;
• FastAPI;
• Docker;
• persistência das conversas;
• testes automatizados;
• avaliação de respostas;
• logging estruturado;
• observabilidade;
• guardrails independentes;
• comparação entre diferentes LLMs locais.

O principal aprendizado

O desenvolvimento do EDU reforçou uma percepção que considero cada vez mais importante quando trabalhamos com IA Generativa:

A qualidade de uma aplicação com LLM não depende apenas da qualidade do modelo. Depende também da qualidade do contexto que construímos ao redor dele.

Escolher um modelo maior pode melhorar determinadas respostas.

Mas, se a aplicação não souber quais dados fornecer, quais informações recuperar, quais regras estabelecer e qual problema está tentando resolver, teremos apenas um modelo sofisticado respondendo a perguntas com pouco contexto.

Por isso, vejo uma sequência interessante:

Dados
 ↓
Contexto
 ↓
Inteligência
 ↓
Resposta
 ↓
Ação

E talvez seja justamente essa a ponte mais interessante entre Data e Generative AI.

Durante muito tempo discutimos como transformar dados em informação e informação em insight.

Com os LLMs, surge uma nova camada:

como transformar dados e conhecimento em contexto para Inteligência Artificial?

Foi essa pergunta que procurei começar a responder com o EDU.

🔗 Projeto no GitHub

O código, os dados demonstrativos, a arquitetura e a documentação completa do projeto estão disponíveis no meu GitHub:

MCLG1661 / Agente-Finaceiro-Inteligente-com-IA-Generativa

O projeto foi desenvolvido como Desafio Final do Bootcamp GenAI — DIO / Bradesco, com orientação do professor Venilton Falvo Jr.

⚠️ Disclaimer

O EDU é um projeto educacional e experimental.

Os dados utilizados são demonstrativos e a aplicação não deve ser utilizada para aconselhamento financeiro, recomendação individual de investimentos ou tomada de decisões financeiras reais.

Se você também está desenvolvendo aplicações com IA Generativa, deixo uma pergunta:

No seu projeto, quanto da qualidade da resposta vem do modelo — e quanto vem do contexto que você construiu para ele?

Marcus Guedes

Marketing | Data Science | Inteligência Artificial | Gestão de Projetos

#GenerativeAI #ContextEngineering #LLM #Ollama #Llama #Python #Streamlit #DataScience #ArtificialIntelligence #PromptEngineering #DIO