Bonjour à tous,
J’essaie de créer un workflow avec le nœud agent IA, Ollama et PostgreSQL.
Tout fonctionne bien pour les deux premières questions qui nécessitent de générer une requête SQL. Mais à la troisième question qui nécessite des données de la base de données, Ollama génère correctement la requête SQL mais s’arrête et ne l’exécute pas sur le nœud GetData.
Veuillez partager votre workflow
Informations sur votre configuration n8n
- Version de n8n : 2.21.5
- Base de données (par défaut : SQLite) : SQLite
- Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
- Exécution de n8n via : Docker
- Système d’exploitation : Linux
@flipflip, tu peux essayer ça ?
Salut @flipflip
Je pense que le problème vient de ton paramètre numPredict: 1024 sur le nœud Ollama. Cela limite la réponse du modèle à 1024 tokens par tour. Après 2 requêtes, l’historique de ta conversation (appels d’outils, résultats, structures de tableau) s’agrandit, et le modèle manque de tokens de sortie avant de pouvoir terminer la génération de l’appel d’outil.
Deux choses à essayer :
-
Augmente numPredict à au moins 4096 dans les options du nœud Ollama.
-
Réduis contextWindowLength dans ta Postgres Chat Memory de 20 à quelque chose comme 5-10. Chaque message inclut les résultats complets des appels d’outils, donc 20 messages consomme rapidement ta fenêtre de contexte de 16384.
Combine ça avec les changements de system prompt de @kjooleng et ça devrait passer la 3e requête.
Fais-nous savoir si ça t’aide !
@flipflip
Vois si ça te convient :
GitLab MCP Server.json (5,0 KB)
Deux choses à vérifier : d’abord, regardez les paramètres du nœud AI Agent et vérifiez la valeur « Max Iterations » - les modèles Ollama épuisent parfois le budget d’itérations après traitement de 2 appels d’outils, ce qui expliquerait que l’agent génère le SQL sans suivre l’appel GetData. Augmentez-le à 15-20 et testez.
Deuxièmement, vérifiez comment votre nœud PostgreSQL est configuré en tant qu’outil. S’il utilise l’opération « Execute Query » et que le SQL est transmis via une expression comme {{ $fromAI('query') }}, assurez-vous que le nom du champ dans fromAI correspond exactement à ce que l’agent génère. Une non-concordance ici provoque l’exécution de l’outil mais renvoie rien, et Ollama s’arrête silencieusement plutôt que de réessayer.
Le coupable le plus probable ici est que qwen3:14b ne produit pas de manière fiable un appel d’outil approprié après avoir généré le SQL. Le nœud Agent LLM attend que le modèle de langage retourne un appel d’outil structuré — si le modèle écrit simplement le SQL en tant que texte brut et s’arrête, l’agent ne déclenche jamais le nœud getData. Il ne voit aucun appel d’outil, considère la tâche comme terminée et retourne une réponse vide.
Voici quelques solutions à essayer, dans cet ordre :
- Activez temporairement les étapes intermédiaires. Dans le nœud Agent, activez « Return Intermediate Steps » (Retourner les étapes intermédiaires). Réexécutez la même troisième question. Vous verrez exactement ce que l’agent a fait — s’il a appelé getData et avec quelle requête, ou s’il s’est arrêté après avoir généré le texte SQL. Cela vous dit immédiatement où se situe le problème.
- Vérifiez votre invite système. Si c’est juste un espace réservé « Mon invite », l’agent ne sait pas qu’il doit utiliser l’outil getData pour chaque demande de données. Ajoutez quelque chose d’explicite :
« Chaque fois que l’utilisateur pose une question qui nécessite des données de la base de données, vous devez appeler l’outil « getData » avec la requête SQL appropriée. Ne produisez pas SQL directement ; utilisez toujours l’outil. »
- Essayez un modèle compatible avec les appels de fonction. qwen3:14b peut ne pas avoir le support natif des appels de fonction dans Ollama, donc l’agent revient à un analyseur textuel qui est fragile. Remplacez-le par llama3.1:8b-instruct ou mistral:7b-instruct (tous deux confirmés pour fonctionner avec les appels d’outils via Ollama) et testez si la troisième requête s’exécute. Si c’est le cas, le modèle était le problème.
- Augmentez numPredict ou supprimez la limite. Votre numPredict est de 1024 jetons. Si la requête SQL plus la syntaxe d’appel d’outil dépasse cela, le modèle pourrait être coupé avant d’émettre le } final qui signale un appel d’outil. Définissez numPredict sur -1 (illimité) ou augmentez-le à 4096.
- Vérifiez la consommation mémoire de Postgres. Bien qu’il soit peu probable que cela provoque un arrêt brutal à exactement la 2e requête, une longue fenêtre de mémoire peut encombrer le contexte et confondre le modèle. Définissez temporairement contextWindowLength sur 5 et testez. Si la troisième requête fonctionne ensuite, vous pouvez l’ajuster à nouveau.
Commencez par #1 et #3 — ce sont les plus rapides à éliminer. Si vous voyez dans les étapes intermédiaires que l’agent n’appelle jamais l’outil, c’est un problème de sortie du modèle. Faites-nous savoir ce que vous trouvez.
Bonjour à tous,
avec les suggestions de @kjooleng et @houda_ben, j’ai réussi à résoudre le problème. Pour l’instant, je n’ai pas rencontré le souci à nouveau malgré 10 questions nécessitant un mélange de requêtes mémoire et base de données. Bien sûr, j’ai considérablement enrichi le prompt de base pour intégrer mes contraintes et exigences.
Merci à tous pour votre aide.