Pular para o conteúdo principal
Pesquisa aplicada e desenvolvimento tecnológico

Inteligência Analítica aplicada à gestão financeira: da linguagem natural ao apoio à decisão

Uma aplicação em que texto, voz, imagens e documentos se tornam operações financeiras estruturadas — e em que correções anteriores podem ser recuperadas para contextualizar novas entradas.

O projeto explora uma arquitetura híbrida: a IA interpreta a intenção, uma camada de RAG[1] recupera conhecimento financeiro já validado, a API controla as operações, as regras de negócio determinam o efeito econômico e o banco relacional preserva estado, relacionamentos, memória e auditoria.

Entrada natural Texto, imagem e documentos
API própria Leitura e escrita controladas
Modelo relacional Contas, cartões, eventos e domínios
Rastreabilidade Auditoria e idempotência
RAG e aprendizado financeiro Experiências corrigidas podem ser persistidas e recuperadas em novas classificações. Ex.: um boleto identificado como “SESI” pode passar a carregar o contexto “Escola” nas próximas ocorrências compatíveis.
Problema e contribuição

Como reduzir a fricção operacional sem transferir à IA a verdade transacional?

Em vez de abrir formulários, localizar campos e digitar manualmente cada informação, o usuário pode descrever a operação. A camada de IA interpreta entidade, valor, data, forma de pagamento, conta, cartão, veículo, observações e demais atributos disponíveis; em seguida, utiliza endpoints da aplicação para consultar ou alterar o estado financeiro.

Fluxo tradicional

  1. Abrir o sistema.
  2. Localizar a tela correta.
  3. Escolher tipo de lançamento.
  4. Preencher campos e relacionamentos.
  5. Conferir datas, status e valores.
  6. Salvar e depois localizar novamente para consulta.

Fluxo assistido por IA

“Paguei R$ 785 no Pix pela manutenção do Voyage. O orçamento era R$ 835 e teve desconto.”

A intenção é decomposta em dados estruturados, validada contra o domínio disponível e enviada à operação adequada. O lançamento financeiro e o contexto especializado podem ser relacionados sem duplicar o impacto econômico.

Modelagem computacional

Como uma entrada informal se transforma em dado confiável

A camada generativa atua na interpretação. A persistência não depende de “memória do chatbot”: o estado real está no sistema financeiro e é recuperado novamente pela API sempre que necessário.

1. Interpretação

Extrai intenção, entidades, datas, valores, vínculos e contexto a partir da entrada humana.

2. Validação

A API REST[4] aplica schemas[14], regras do domínio, proteção contra duplicidade e consistência transacional.

3. Confirmação

Após a escrita, o registro pode ser consultado novamente para confirmar o estado persistido.

Engenharia em funcionamento

IA na borda; regras e verdade transacional no backend

A separação de responsabilidades é intencional. O modelo de linguagem (LLM[2]) pode interpretar frases ambíguas, mas não define sozinho saldo, vencimento, pagamento, transferência ou duplicidade. Essas decisões pertencem ao software determinístico.

Camada probabilística

  • • compreensão de linguagem natural;
  • • interpretação de comprovantes e documentos;
  • • associação contextual de categorias e entidades;
  • • escolha da ação disponível;
  • • síntese de respostas e análises.

Camada determinística

  • • validação dos dados recebidos;
  • • cálculo de efeitos financeiros;
  • • status pago, pendente e provisionado;
  • • idempotência[3] e bloqueio de duplicidade;
  • • persistência, auditoria e consultas.
fluxo_operacional.pseudo
FUNCAO executar_pedido(entrada):
    contexto ← interpretar_com_ia(entrada)

    operacao ← selecionar_action(contexto.intencao)
    payload  ← normalizar_campos(contexto)

    # A IA não escreve diretamente no SQL
    resultado ← api.validar_e_executar(
        operacao,
        payload,
        idempotency_key=gerar_operation_id()
    )

    SE resultado.ok:
        estado ← api.consultar_novamente(resultado.id)
        RETORNAR resumir_estado(estado)

    SENAO:
        RETORNAR resultado.erros
Modelo lógico relacional

O financeiro é o núcleo; memória e domínios especializados adicionam contexto

Uma compra de manutenção do veículo, por exemplo, não precisa existir duas vezes como despesa. O lançamento permanece no núcleo financeiro e o módulo de veículos registra o que foi feito, em qual veículo, quando, por quem e quais itens foram trocados, relacionando esse histórico ao evento financeiro correspondente.

Diagrama conceitual simplificado para apresentação da arquitetura. Além do núcleo financeiro e do módulo de veículos, ele explicita a camada de aprendizado financeiro usada para recuperar associações já validadas. Campos auxiliares foram omitidos para manter a leitura visual.

Financeiro central

Lançamentos, pagamentos, contas, cartões e faturas representam os eventos econômicos.

Domínio de veículos

Mantém histórico por veículo e granularidade de cada item trocado ou serviço realizado.

Documentos

Comprovantes e imagens preservam a evidência associada ao registro correspondente.

Auditoria[13]

Operações de IA e alterações relevantes podem ser rastreadas por identificadores próprios.

Semântica financeira

Compra, pagamento e saldo são eventos diferentes

Um dos pontos mais importantes da modelagem OLTP[5] é não confundir o fato econômico com seu instrumento de pagamento. Uma compra no cartão cria uma obrigação; o pagamento da fatura liquida essa obrigação e movimenta a conta; uma transferência apenas desloca saldo entre contas próprias.

Cartão de crédito

Compra agora, saída depois

A despesa pertence à fatura e pode permanecer pendente até sua liquidação. O saldo da conta bancária não deve cair no momento da compra.

Débito / Pix

Evento e liquidação próximos

A despesa pode ser registrada como já paga e associada diretamente à conta que suportou a saída.

Transferência

Sem receita ou despesa

O valor sai de uma conta e entra em outra, preservando a neutralidade patrimonial da transferência interna.

Capacidades do sistema

Um núcleo financeiro extensível por domínios

Receitas e despesas

Registro de eventos pagos, recebidos, pendentes ou provisionados, com datas econômicas e vencimentos.

Contas e saldos

Instituições, titulares, saldo inicial, histórico, ajustes e movimentações internas.

Cartões e faturas

Compras agrupadas por ciclo, fechamento, vencimento, pendências e pagamento posterior.

Veículos

Cadastro do veículo e contextualização de gastos sem retirar a despesa do núcleo financeiro.

Histórico de manutenção

Serviços, fornecedor, quilometragem e itens individualizados para consultas futuras de troca e manutenção.

Interface por IA

Consulta e execução de operações por linguagem natural sobre a mesma API utilizada pelo restante da aplicação.

RAG financeiro

Recupera associações e correções já validadas para enriquecer novas interpretações e reduzir reclassificações repetitivas.

Leitura documental

Extração estruturada de informações a partir de documentos e comprovantes para reduzir digitação manual.

Análise financeira

Consultas sobre contas futuras, gastos por categoria, previsão de caixa e composição das despesas.

Rastreabilidade

Identificação da operação, reconsulta do registro e trilha de auditoria para alterações relevantes.

Exemplo operacional

Uma única conversa pode alimentar duas visões do mesmo fato

O valor da manutenção interessa ao fluxo financeiro. Já os itens trocados interessam ao histórico técnico do veículo. O sistema pode preservar as duas perspectivas por relacionamento, sem contar a despesa duas vezes.

Perguntas que passam a ser possíveis: “Quanto gastei no Voyage este ano?”
“Quando troquei as pastilhas de freio?”
“Quem fez a última manutenção?”
“Qual era a quilometragem?”
“Existe comprovante anexado?”
exemplo_decomposicao.json
{
  "evento_financeiro": {
    "tipo": "despesa",
    "valor_original": 835.00,
    "valor_pago": 785.00,
    "forma_pagamento": "pix",
    "status": "pago"
  },

  "contexto_veiculo": {
    "veiculo": "Voyage",
    "tipo": "manutencao",
    "itens": [
      "item ou serviço 1",
      "item ou serviço 2"
    ]
  },

  "evidencia": {
    "anexo": true
  }
}
Engenharia do protótipo

O diferencial está na integração entre IA e software transacional

Idempotência[3]

Uma mesma solicitação não deve produzir múltiplos registros apenas porque houve repetição da chamada.

Auditoria[13]

Operações relevantes deixam evidências suficientes para reconstruir o que ocorreu e em qual entidade.

Dry-run[12]

Operações podem ser validadas antes da escrita quando o fluxo exigir conferência prévia.

Reconsulta

Após a alteração, o estado persistido pode ser lido novamente em vez de confiar apenas na resposta da escrita.

API[4] como contrato

A mesma lógica pode atender frontend, automações e interfaces baseadas em modelos de linguagem.

Domínios especializados

Novos módulos podem se relacionar ao núcleo financeiro sem redefinir a contabilidade de cada evento.

Componente Responsabilidade Papel da IA
Interface conversacional Receber intenção em linguagem natural Central
Extração documental Transformar conteúdo não estruturado em campos Central
Memória / RAG Recuperar experiências financeiras previamente validadas Contextualiza
API REST Contrato de leitura e escrita Consumidora
Regras financeiras Definir efeitos, estados e consistência Não decide
Banco relacional Persistência e relacionamentos Não acessa direto
Auditoria Rastrear operações e alterações Contextual
Perguntas frequentes

O que esta arquitetura demonstra

A IA grava diretamente no banco?

Não. A IA interpreta e aciona operações disponíveis. A API e o backend continuam responsáveis pela validação e persistência.

Por que usar banco relacional se há IA?

Porque relações financeiras exigem consistência, integridade referencial e consultas reproduzíveis. A IA melhora a interface; ela não substitui essas propriedades.

O sistema “aprende” com documentos?

Sim, por meio de memória externa e recuperação de experiências anteriores. Correções como a associação de um fornecedor ou documento a determinada categoria podem ser persistidas e reutilizadas em novas entradas. Isso é aprendizado por contexto e RAG, não necessariamente fine-tuning do modelo.

Por que separar manutenção do lançamento financeiro?

Porque são duas visões do mesmo evento. O núcleo financeiro responde quanto foi gasto; o domínio de manutenção responde o que foi trocado, quando, onde e em qual veículo.

Limitações metodológicas e roadmap evolutivo

O que ainda precisa ser medido e formalizado

Limitações atuais

  • A qualidade da recuperação depende da quantidade e representatividade das experiências previamente validadas.
  • A memória pode propagar classificações inadequadas se correções incorretas forem persistidas sem governança.
  • A avaliação científica do ganho proporcionado pelo RAG exige conjunto de teste controlado, métricas fixas e comparação com baseline sem memória.
  • Nem toda operação deve ser automatizada apenas porque pode ser interpretada por linguagem natural.

Vetor de evolução

  • Formalizar métricas de precisão, recuperação, taxa de correção e redução de esforço operacional.
  • Evoluir a memória financeira para recuperação semântica por embeddings[8] e similaridade cosseno[9], quando tecnicamente justificável.
  • Ampliar testes regressivos e cenários E2E sobre operações de escrita.
  • Incorporar mecanismos explícitos de confiança e escalonamento para validação humana em operações sensíveis.

O projeto combina sistema financeiro, IA e memória recuperável.

O núcleo permanece transacional e auditável; a IA interpreta; o RAG recupera experiências anteriores; e as correções do usuário podem alimentar uma memória financeira reutilizável. O resultado é uma interface que não apenas entende linguagem cotidiana, mas acumula contexto operacional ao longo do uso.

Python Flask REST API SQL LLM RAG Memória Financeira Automação Auditoria
Engenharia de Software e Pesquisa Aplicada

Artefato computacional em evolução contínua

A arquitetura, a modelagem de dados, a API, os fluxos de integração com IA e a organização dos módulos especializados formam um ambiente experimental voltado simultaneamente à resolução de um problema prático e à investigação de técnicas de interação entre modelos generativos e sistemas transacionais.

Referências e Glossário Técnico

  1. [1] RAG (Retrieval-Augmented Generation): arquitetura em que informações externas relevantes são recuperadas antes da inferência do modelo e adicionadas ao contexto, permitindo respostas orientadas por conhecimento específico sem exigir alteração dos pesos do LLM.
  2. [2] LLM (Large Language Model): modelo de linguagem treinado em grandes corpora para interpretar, completar e gerar sequências textuais, podendo atuar como camada de compreensão de linguagem natural.
  3. [3] Idempotência: propriedade pela qual a repetição da mesma operação lógica produz o mesmo efeito final, evitando duplicidades causadas por retries, reenvios ou chamadas repetidas.
  4. [4] API REST: interface de comunicação baseada em recursos e operações HTTP, utilizada como contrato entre a camada de IA, o frontend e as regras do backend.
  5. [5] OLTP (Online Transaction Processing): padrão de processamento orientado a transações pontuais, consistentes e de baixa latência, adequado a lançamentos, pagamentos, saldos e auditoria.
  6. [6] HITL (Human-in-the-loop): arquitetura em que uma pessoa participa da validação ou correção do resultado algorítmico antes de determinada decisão ser efetivada.
  7. [7] JSON-LD (JavaScript Object Notation for Linked Data): formato de dados estruturados utilizado para representar semanticamente entidades e relacionamentos em páginas web.
  8. [8] Embedding: representação vetorial de um texto ou entidade em espaço numérico, permitindo comparar proximidade semântica entre registros.
  9. [9] Similaridade cosseno: medida geométrica baseada no ângulo entre vetores, frequentemente utilizada para ranquear embeddings semanticamente próximos.
  10. [10] P&D (Pesquisa e Desenvolvimento): processo sistemático de investigação e construção tecnológica voltado à validação empírica de soluções, métodos ou artefatos inovadores.
  11. [11] E2E (End-to-End): teste que percorre a jornada completa do sistema, da entrada até o efeito persistido e sua posterior recuperação.
  12. [12] Dry-run: execução simulada de uma operação para validar payload, regras e efeitos esperados sem efetivar a alteração persistente.
  13. [13] Auditoria: registro estruturado de operações, atores, entidades e alterações capaz de reconstruir a sequência de eventos relevantes do sistema.
  14. [14] Schema: contrato formal que define campos, tipos, obrigatoriedade e restrições esperadas para uma estrutura de dados.
  15. [15] RDBMS (Relational Database Management System): sistema gerenciador de banco de dados baseado em tabelas relacionadas por chaves e restrições de integridade.