I’m really struggling to build an automation in n8n that acts as an AI consulting a helpdesk. I’m using Olama with the models Qwen-2.5 14B and Qwen-3.0 14B, but it’s just not working—responses are inaccurate, and it fails to answer the questions. I’ve tried adding a bank dictionary, vectorizing the data, and using Qdrant, but I’m still stuck. I would really appreciate any kind advice or best practices. I’m honestly feeling a bit lost here, so any help would mean a lot.
Hi @Igor4 Welcome!!
I think (1) prompts, (2) few-shot examples, and (3) sampling settings like temperature, top_p definitely matter, but they usually do not fix the core problem by themselves.
For helpdesk-style RAG, the bigger issue is often retrieval quality and workflow design:
chunking
metadata
grounding
making sure the right context is passed in before the model answers.
In n8n, RAG is really about retrieving the right documents from a vector store first, then using the LLM on top of that.
So yes, I would look at prompt tuning and model parameters too, but I would focus first on the architecture and the quality of the retrieved context.
Read articles in:
for example:
2 « J'aime »
1 « J'aime »
Salut @Igor4, je suis heureux que ma réponse précédente t’ait aidé à clarifier les choses, et c’est une excellente question de suivi.
Oui, ton idée d’utiliser des vues SQL est une approche solide. Cela donne à l’IA une source de vérité plus contrôlée et structurée, au lieu d’exposer l’intégralité de la base de données. Dans de nombreux cas d’usage de style helpdesk (clients, tickets, services), cela peut améliorer à la fois la précision et la sécurité par rapport à un accès large à la BD ou à une dépendance sur la RAG seule sur les documents.
Du point de vue architectural, cela dépend de la façon dont ton système est conçu :
- Si les données nécessaires sont déterministes, tu sais déjà quoi récupérer, appeler la base de données en premier, puis transmettre des données nettoyées à l’IA est souvent mieux. Cela (1) réduit les appels d’outil, (2) améliore la latence et les coûts, et (3) limite les risques d’hallucination.
- Si le système a besoin de décider dynamiquement quelles données récupérer, laisser l’IA Agent interroger ces vues contrôlées est un bon modèle, mais la précision dépendra de (1) la conception du prompt, (2) les descriptions d’outils, et (3) le comportement du modèle.
Je vois les vues SQL et la RAG comme complémentaires : les vues pour les données opérationnelles structurées, la RAG pour les connaissances non structurées.
Dans les scénarios plus complexes, les modèles de planification en premier (comme la séparation du raisonnement de l’exécution d’outils), le ReWOO (abréviation de « Reasoning Without Observation »), peut aider, mais ils ne sont généralement nécessaires que lorsque les flux de travail deviennent plus agentiques.
Globalement, ton approche est solide et s’aligne bien avec la construction de systèmes fiables.
Pour approfondir, IBM propose un aperçu utile de 
l’architecture agentique et ReWOO.
Bonne construction de workflow 
1 « J'aime »
Le problème de précision vient généralement du fait que le système d’invite ne donne pas assez de structure au modèle. Voici quelques éléments qui m’ont aidé : d’abord, divisez vos instructions en étapes numérotées plutôt qu’un seul paragraphe, les modèles suivent les instructions ordonnées de manière plus fiable. Deuxièmement, ajoutez une section de format de sortie explicite à la fin de votre invite système afin que le modèle sache exactement quelle forme la réponse doit prendre. Troisièmement, baissez la température à 0 si vous avez besoin de sorties structurées cohérentes. À quoi ressemble votre invite système actuelle ?
1 « J'aime »