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:
Oi @Igor4, fico feliz que minha resposta anterior tenha ajudado a esclarecer as coisas, e esta é uma pergunta de acompanhamento muito boa.
Sim, sua ideia de usar visualizações SQL é uma abordagem muito forte. Ela oferece à IA uma fonte de verdade mais controlada e estruturada, em vez de expor o banco de dados completo. Em muitos casos de estilo helpdesk (clientes, tickets, serviços), isso pode melhorar tanto a precisão quanto a segurança em comparação com acesso amplo ao BD ou dependência apenas de RAG sobre documentos.
De uma perspectiva arquitetural, depende de como seu sistema é projetado:
- Se os dados necessários forem determinísticos, você já sabe o que buscar, chamar o banco de dados primeiro e depois passar dados limpos para a IA geralmente é melhor. Isso (1) reduz chamadas de ferramentas, (2) melhora latência e custo, e (3) limita as chances de alucinação.
- Se o sistema precisar decidir dinamicamente quais dados recuperar, permitir que o Agente de IA consulte essas visualizações controladas é um bom padrão, mas a precisão dependerá de (1) design de prompt, (2) descrições de ferramentas e (3) comportamento do modelo.
Vejo visualizações SQL e RAG como complementares: visualizações para dados operacionais estruturados, RAG para conhecimento não estruturado.
Em cenários mais complexos, padrões de planejamento primeiro (como separar raciocínio da execução de ferramentas), como ReWOO (abreviação de ‘Reasoning Without Observation’), podem ajudar, mas geralmente são necessários apenas quando fluxos de trabalho se tornam mais agênticos.
No geral, sua abordagem é sólida e se alinha bem com a construção de sistemas confiáveis.
Para leitura adicional, a IBM tem uma visão geral útil de
arquitetura agêntica e
ReWOO.
Feliz construção de fluxo de trabalho ![]()
O problema de precisão geralmente se resume ao prompt do sistema não dar ao modelo estrutura suficiente. Algumas coisas que me ajudaram: primeiro, divida suas instruções em etapas numeradas em vez de um parágrafo, modelos seguem instruções ordenadas de forma mais confiável. Segundo, adicione uma seção de formato de saída explícito no final do seu prompt do sistema para que o modelo saiba exatamente qual forma a resposta deve ter. Terceiro, reduza a temperatura para 0 se você precisar de saídas estruturadas consistentes. Como é seu prompt do sistema atual?