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 Me gusta
1 me gusta
Hola @Igor4, ¡me alegra que mi respuesta anterior te haya ayudado a aclarar las cosas, y esta es una excelente pregunta de seguimiento!
Sí, tu idea de usar vistas SQL es un enfoque muy sólido. Le proporciona al AI una fuente de verdad más controlada y estructurada, en lugar de exponer la base de datos completa. En muchos casos de uso tipo helpdesk (clientes, tickets, servicios), esto puede mejorar tanto la precisión como la seguridad en comparación con el acceso amplio a BD o confiar únicamente en RAG sobre documentos.
Desde una perspectiva arquitectónica, depende de cómo esté diseñado tu sistema:
- Si los datos necesarios son determinísticos, ya sabes qué obtener, llamar a la base de datos primero y luego pasar datos limpios al AI suele ser mejor. (1) reduce las llamadas a herramientas, (2) mejora la latencia y el costo, y (3) limita las posibilidades de alucinación.
- Si el sistema necesita decidir dinámicamente qué datos recuperar, entonces permitir que el Agente AI consulte esas vistas controladas es un buen patrón, pero la precisión dependerá de (1) el diseño del prompt, (2) las descripciones de herramientas, y (3) el comportamiento del modelo.
Veo las vistas SQL y RAG como complementarias: vistas para datos operacionales estructurados, RAG para conocimiento no estructurado.
En escenarios más complejos, los patrones de planificación primero (como separar el razonamiento de la ejecución de herramientas), como ReWOO (abreviatura de ‘Reasoning Without Observation’), pueden ayudar, pero generalmente solo se necesitan cuando los flujos de trabajo se vuelven más agénticos.
En general, tu enfoque es sólido y se alinea bien con la construcción de sistemas confiables.
Para más información, IBM tiene una descripción útil de 
agentic architecture y ReWOO.
Feliz construcción de flujos de trabajo 
1 me gusta
El problema de precisión generalmente se reduce a que el aviso del sistema no le da suficiente estructura al modelo. Algunas cosas que me ayudaron: primero, divide tus instrucciones en pasos numerados en lugar de un párrafo, los modelos siguen instrucciones ordenadas de manera más confiable. Segundo, añade una sección de formato de salida explícita al final de tu aviso del sistema para que el modelo sepa exactamente qué forma debe tener la respuesta. Tercero, reduce la temperatura a 0 si necesitas salidas estructuradas consistentes. ¿Cómo se ve tu aviso del sistema actual?
1 me gusta