Olá a todos,
Estou tentando criar um fluxo de trabalho com o nó agente de IA, Ollama e PostgreSQL.
Tudo funciona bem nas duas primeiras perguntas que precisam gerar uma consulta SQL. Mas na terceira pergunta que precisa de dados do banco de dados, o Ollama gera a consulta SQL corretamente mas para e não a executa no nó GetData.
Por favor, compartilhe seu fluxo de trabalho
Informações sobre sua configuração n8n
- Versão n8n: 2.21.5
- Banco de dados (padrão: SQLite): SQLite
- Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
- Executando n8n via: Docker
- Sistema operacional: Linux
@flipflip , você pode tentar isso?
Oi @flipflip
Acho que a causa é sua configuração numPredict: 1024 no nó Ollama. Isso limita a resposta do modelo a 1024 tokens por turno. Após 2 consultas, seu histórico de conversa (chamadas de ferramentas, resultados, estruturas de tabelas) cresce, e o modelo fica sem tokens de saída antes de conseguir terminar de gerar a chamada de ferramenta.
Duas coisas para tentar:
-
Aumente numPredict para pelo menos 4096 nas opções do nó Ollama.
-
Reduza contextWindowLength do seu Postgres Chat Memory de 20 para algo entre 5-10. Cada mensagem inclui resultados completos de chamadas de ferramentas, então 20 mensagens consome sua janela de contexto de 16384 tokens rapidamente.
Combine isso com as mudanças de prompt do sistema de @kjooleng e deve passar da 3ª consulta.
Nos avise se isso ajudar !
@flipflip
veja se isso te atende:
GitLab MCP Server.json (5,0,KB)
Duas coisas que valem a pena verificar: primeiro, veja as configurações do nó AI Agent e verifique o valor de “Max Iterations” - modelos Ollama às vezes esgotam o orçamento de iterações após processar 2 chamadas de ferramentas, o que explicaria o agente gerar o SQL mas não prosseguir com a chamada GetData. Aumente para 15-20 e teste.
Segundo, verifique como seu nó PostgreSQL está configurado como ferramenta. Se estiver usando a operação “Execute Query” e o SQL for passado por meio de uma expressão como {{ $fromAI('query') }}, verifique se o nome do campo em fromAI corresponde exatamente ao que o agente está gerando. Uma incompatibilidade ali faz a ferramenta executar mas não retornar nada, e o Ollama silenciosamente para em vez de tentar novamente.
O culpado mais provável aqui é que o qwen3:14b não gera de forma confiável uma chamada de ferramenta adequada após gerar o SQL. O nó Agent espera que o LLM retorne uma chamada de ferramenta estruturada — se o modelo apenas escrever o SQL como texto simples e parar, o agente nunca dispara o nó getData. Ele não vê nenhuma chamada de ferramenta, considera a tarefa concluída e retorna uma resposta vazia.
Algumas coisas para tentar, em ordem:
- Ative as etapas intermediárias temporariamente. No nó Agent, ative “Return Intermediate Steps” (Retornar Etapas Intermediárias). Execute novamente a mesma terceira pergunta. Você verá exatamente o que o agente fez — se chamou getData e com qual consulta, ou se parou após gerar o texto SQL. Isso mostra imediatamente onde está a desconexão.
- Verifique seu prompt do sistema. Se for apenas um placeholder “My prompt” (Meu prompt), o agente não saberá que precisa usar a ferramenta getData para cada solicitação de dados. Adicione algo explícito:
“Sempre que o usuário fazer uma pergunta que exija dados do banco de dados, você deve chamar a ferramenta ‘getData’ com a consulta SQL apropriada. Não produza SQL diretamente; sempre use a ferramenta.”
- Tente um modelo com capacidade de function-calling. O qwen3:14b pode não ter suporte nativo de function-calling no Ollama, então o agente volta para um analisador baseado em texto que é frágil. Substitua por llama3.1:8b-instruct ou mistral:7b-instruct (ambos confirmados para funcionar com chamadas de ferramentas via Ollama) e teste se a terceira consulta é executada. Se for, o modelo era o problema.
- Aumente numPredict ou remova o limite. Seu numPredict é 1024 tokens. Se a consulta SQL mais a sintaxe de chamada de ferramenta excederem isso, o modelo pode ser interrompido antes de emitir o final } que sinaliza uma chamada de ferramenta. Defina numPredict para -1 (ilimitado) ou aumente para 4096.
- Verifique o consumo de memória do Postgres. Embora improvável causar uma parada exata na 2ª consulta, uma janela de memória longa pode poluir o contexto e confundir o modelo. Defina temporariamente contextWindowLength para 5 e teste. Se a terceira consulta funcionar, você pode ajustá-lo novamente.
Comece com #1 e #3 — essas são as mais rápidas de descartar. Se você ver nas etapas intermediárias que o agente nunca chama a ferramenta, é um problema de saída do modelo. Nos diga o que você descobrir.
Oi a todos,
com as sugestões de @kjooleng e @houda_ben, consegui resolver o problema. Por enquanto, não encontrei o problema novamente apesar de 10 perguntas que exigem uma mistura de consultas de memória e banco de dados. É claro que enriqueci bastante o prompt base para integrar minhas restrições e requisitos.
Obrigado a todos pela ajuda.