Fluxo tradicional
- Abrir o sistema.
- Localizar a tela correta.
- Escolher tipo de lançamento.
- Preencher campos e relacionamentos.
- Conferir datas, status e valores.
- Salvar e depois localizar novamente para consulta.
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.
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.
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.
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.
flowchart LR
A["Usuário
texto • voz • imagem • PDF"] --> B["LLM / camada
semântica"]
B --> C["Intenção +
dados estruturados"]
C --> D["API REST
do sistema"]
D --> E{"Validações
de negócio"}
E -->|"válido"| F["Operação
idempotente"]
E -->|"incompleto"| G["Solicitar ou
inferir contexto"]
G --> B
F --> H["Banco relacional"]
H --> I["Auditoria +
operation_id"]
H --> J["Consulta pós-operação"]
J --> K["Resposta ao usuário"]
Extrai intenção, entidades, datas, valores, vínculos e contexto a partir da entrada humana.
A API REST[4] aplica schemas[14], regras do domínio, proteção contra duplicidade e consistência transacional.
Após a escrita, o registro pode ser consultado novamente para confirmar o estado persistido.
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.
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
A camada de aprendizado registra conhecimento derivado de interações anteriores e o reutiliza na análise de novas entradas. Em vez de depender exclusivamente do conhecimento genérico do modelo, o sistema pode recuperar experiências financeiras previamente validadas e inseri-las no contexto da nova solicitação.
Esse mecanismo é compatível com a ideia de RAG[1]Retrieval-Augmented Generation: recuperação de informação própria antes da geração ou classificação pelo modelo.: primeiro recuperar conhecimento relevante; depois usar esse conhecimento para orientar a inferência. O aprendizado, portanto, não significa necessariamente retreinar o LLM: significa construir uma memória externa, verificável e reutilizável.
flowchart TB
A["Nova entrada
texto • imagem • boleto • comprovante"] --> B["Extração e
normalização"]
B --> C["Construção de chave
e sinais de contexto"]
C --> D["Consulta à memória
financeira / RAG"]
D --> E["Exemplos anteriores
relevantes"]
D --> F["Regras e associações
aprendidas"]
E --> G["Contexto enriquecido"]
F --> G
B --> G
G --> H["LLM / classificador
assistido"]
H --> I{"Confiança /
validação"}
I -->|"aceito"| J["Operação financeira"]
I -->|"corrigido"| K["Correção do usuário"]
J --> L["Persistência
transacional"]
K --> M["Persistir novo
aprendizado"]
M --> D
L --> N["Auditoria e
reconsulta"]
O conhecimento aprendido deve permanecer fora dos pesos do modelo e dentro da infraestrutura controlada pelo sistema. Isso permite consultar, corrigir, versionar ou excluir associações sem depender de novo treinamento.
Uma correção útil deixa de ser apenas uma conversa passada. Ela pode se transformar em dado recuperável para futuras decisões.
FUNCAO interpretar_com_memoria(entrada): documento ← normalizar(entrada) # Recuperação antes da geração/classificação memoria ← buscar_aprendizados_relevantes( texto=documento.texto, fornecedor=documento.fornecedor, identificadores=documento.tokens ) contexto ← { "entrada_atual": documento, "experiencias_anteriores": memoria } resultado ← llm.interpretar(contexto) SE usuario_corrigir(resultado): salvar_aprendizado( origem=documento, correcao=resultado.corrigido, status="validado" ) RETORNAR resultado
Localizar conhecimento anterior relacionado à nova entrada.
Enviar ao modelo a entrada atual junto das experiências recuperadas.
Transformar correções úteis em memória persistente para usos seguintes.
A personalização ocorre pela recuperação de memória e pelo enriquecimento de contexto. Isso não implica, por si só, fine-tuning ou alteração dos pesos do modelo de linguagem. A distinção é importante porque mantém o comportamento aprendido auditável e reversível.
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.
erDiagram
PESSOAS ||--o{ CONTAS : possui
PESSOAS ||--o{ CARTOES : titular
CONTAS ||--o{ HISTORICO_SALDOS : registra
CONTAS ||--o{ AJUSTES_SALDO : recebe
CONTAS ||--o{ TRANSFERENCIAS : origem_destino
CARTOES ||--o{ FATURAS_CARTAO : gera
FATURAS_CARTAO ||--o{ LANCAMENTOS : agrupa
CONTAS ||--o{ LANCAMENTOS : movimenta
LANCAMENTOS ||--o{ PAGAMENTOS : liquida
VEICULOS ||--o{ MANUTENCOES : possui
MANUTENCOES ||--o{ ITENS_MANUTENCAO : detalha
LANCAMENTOS ||--o| MANUTENCOES : financia
LANCAMENTOS ||--o{ ANEXOS : documenta
MANUTENCOES ||--o{ ANEXOS : comprova
AI_OPERATIONS ||--o{ FINANCE_AUDIT_LOG : rastreia
LANCAMENTOS ||--o{ FINANCE_AUDIT_LOG : audita
CATEGORIAS ||--o{ LANCAMENTOS : classifica
APRENDIZADO_FINANCEIRO }o--|| CATEGORIAS : sugere
APRENDIZADO_FINANCEIRO }o--o| PESSOAS : personaliza
AI_OPERATIONS ||--o{ APRENDIZADO_FINANCEIRO : utiliza
PESSOAS {
int id PK
string nome
}
CONTAS {
int id PK
int pessoa_id FK
string tipo
decimal saldo
}
CARTOES {
int id PK
int pessoa_id FK
string nome
int dia_fechamento
int dia_vencimento
}
FATURAS_CARTAO {
int id PK
int cartao_id FK
date vencimento
decimal valor
string status
}
LANCAMENTOS {
int id PK
int conta_id FK
int fatura_id FK
string tipo
decimal valor
date data
date vencimento
string status
}
PAGAMENTOS {
int id PK
int lancamento_id FK
decimal valor
date data
}
VEICULOS {
int id PK
string nome
string placa
int ano
int quilometragem
}
MANUTENCOES {
int id PK
int veiculo_id FK
int lancamento_id FK
date data
int quilometragem
string fornecedor
}
ITENS_MANUTENCAO {
int id PK
int manutencao_id FK
string item
decimal valor
}
CATEGORIAS {
int id PK
string nome
string tipo
}
APRENDIZADO_FINANCEIRO {
int id PK
int categoria_id FK
int pessoa_id FK
string padrao
string contexto
string origem
string status
}
AI_OPERATIONS {
int id PK
string operation_id
string action
string status
}
FINANCE_AUDIT_LOG {
int id PK
string entidade
int entidade_id
string operacao
datetime criado_em
}
Lançamentos, pagamentos, contas, cartões e faturas representam os eventos econômicos.
Mantém histórico por veículo e granularidade de cada item trocado ou serviço realizado.
Comprovantes e imagens preservam a evidência associada ao registro correspondente.
Operações de IA e alterações relevantes podem ser rastreadas por identificadores próprios.
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.
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.
A despesa pode ser registrada como já paga e associada diretamente à conta que suportou a saída.
O valor sai de uma conta e entra em outra, preservando a neutralidade patrimonial da transferência interna.
Registro de eventos pagos, recebidos, pendentes ou provisionados, com datas econômicas e vencimentos.
Instituições, titulares, saldo inicial, histórico, ajustes e movimentações internas.
Compras agrupadas por ciclo, fechamento, vencimento, pendências e pagamento posterior.
Cadastro do veículo e contextualização de gastos sem retirar a despesa do núcleo financeiro.
Serviços, fornecedor, quilometragem e itens individualizados para consultas futuras de troca e manutenção.
Consulta e execução de operações por linguagem natural sobre a mesma API utilizada pelo restante da aplicação.
Recupera associações e correções já validadas para enriquecer novas interpretações e reduzir reclassificações repetitivas.
Extração estruturada de informações a partir de documentos e comprovantes para reduzir digitação manual.
Consultas sobre contas futuras, gastos por categoria, previsão de caixa e composição das despesas.
Identificação da operação, reconsulta do registro e trilha de auditoria para alterações relevantes.
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.
{
"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
}
}
Uma mesma solicitação não deve produzir múltiplos registros apenas porque houve repetição da chamada.
Operações relevantes deixam evidências suficientes para reconstruir o que ocorreu e em qual entidade.
Operações podem ser validadas antes da escrita quando o fluxo exigir conferência prévia.
Após a alteração, o estado persistido pode ser lido novamente em vez de confiar apenas na resposta da escrita.
A mesma lógica pode atender frontend, automações e interfaces baseadas em modelos de linguagem.
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 |
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.
Porque relações financeiras exigem consistência, integridade referencial e consultas reproduzíveis. A IA melhora a interface; ela não substitui essas propriedades.
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.
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.
O artefato oferece uma base concreta para Pesquisa e Desenvolvimento (P&D)[10] em interação humano-computador, sistemas de informação, recuperação aumentada por geração, automação financeira e confiabilidade de aplicações assistidas por modelos de linguagem.
Diferentemente de um protótipo exclusivamente demonstrativo, o sistema mantém persistência, regras de negócio, relacionamentos entre entidades, trilha de auditoria e mecanismos de reconsulta. Isso permite observar empiricamente onde a camada probabilística agrega valor e onde deve ser limitada por controles determinísticos.
Avaliar classificação sem memória versus classificação com recuperação de experiências anteriores, mantendo o mesmo conjunto de entradas.
Medir quantas sugestões exigem intervenção humana antes e depois da incorporação de memória validada.
Comparar tempo e número de interações para registrar ou localizar eventos por formulário convencional e por interface em linguagem natural.
Homologar jornadas completas por testes E2E[11], da interpretação da entrada à persistência e reconsulta do estado.
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.
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.