Help Needed: AI Automation in n8n Not Responding Accurately.

Help me Build my Workflow
, ,
1

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.

2

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 „Gefällt mir“
4
1 „Gefällt mir“
5

Hallo @Igor4, ich freue mich, dass meine vorherige Antwort zur Klärung beigetragen hat, und das ist eine sehr gute Anschlussfrage.

Ja, deine Idee, SQL-Views zu verwenden, ist ein starker Ansatz. Das gibt der KI eine kontrolliertere und strukturiertere Informationsquelle, anstatt die gesamte Datenbank freizugeben. In vielen Helpdesk-ähnlichen Anwendungsfällen (Kunden, Tickets, Services) kann dies sowohl die Genauigkeit als auch die Sicherheit im Vergleich zu breitem DB-Zugriff oder dem reinen Verlassen auf RAG über Dokumente verbessern.

Aus architektonischer Perspektive hängt es davon ab, wie dein System aufgebaut ist:

  • Wenn die benötigten Daten deterministisch sind, du also bereits weißt, was zu abrufen ist, ist es oft besser, zuerst die Datenbank abzufragen und dann saubere Daten an die KI zu übergeben. Dies (1) reduziert Tool-Aufrufe, (2) verbessert Latenz und Kosten, und (3) begrenzt die Halluzinationschancen.
  • Wenn das System dynamisch entscheiden muss, welche Daten abgerufen werden, ist es ein gutes Muster, die KI Agent diese kontrollierten Views abfragen zu lassen, aber die Genauigkeit hängt von (1) Prompt-Design, (2) Tool-Beschreibungen und (3) Modellverhalten ab.

Ich sehe SQL-Views und RAG als komplementär: Views für strukturierte Betriebsdaten, RAG für unstrukturiertes Wissen.

In komplexeren Szenarien können Planning-First-Muster (wie die Trennung von Reasoning und Tool-Ausführung), etwa ReWOO (Kurzform für „Reasoning Without Observation’), hilfreich sein, werden aber normalerweise erst benötigt, wenn Workflows agentenähnlicher werden.

Insgesamt ist dein Ansatz solide und passt sehr gut zum Aufbau zuverlässiger Systeme.

Zum weiteren Lesen hat IBM einen nützlichen Überblick über :backhand_index_pointing_right: agentic architecture und :backhand_index_pointing_right: ReWOO.

Viel Spaß beim Workflow-Aufbau :clap:

1 „Gefällt mir“
6

Das Genauigkeitsproblem beruht normalerweise darauf, dass der System-Prompt dem Modell nicht genug Struktur bietet. Ein paar Dinge, die mir geholfen haben: Erstens, unterteile deine Anweisungen in nummerierte Schritte statt in einen Absatz – Modelle folgen geordneten Anweisungen zuverlässiger. Zweitens, füge am Ende deines System-Prompts einen expliziten Ausgabeformat-Abschnitt hinzu, damit das Modell genau weiß, wie die Antwort aussehen soll. Drittens, setze die Temperatur auf 0, wenn du konsistente strukturierte Ausgaben brauchst. Wie sieht dein aktueller System-Prompt aus?

1 „Gefällt mir“