How to RAG without RAG

Seit vielen Jahren schon bin ich in Sachen "Data & Analytics" unterwegs: Klassisches Data Warehouse, saubere Datenmodelle, Reports & Dashboards – das ist meine Welt. Was ich allerdings nie war: ein klassischer Programmierer.

Umso spannender waren für mich die beim letzten CI-Hackathon gemachten Erfahrungen: Mit heutigen (KI-)Tools lassen sich in sehr kurzer Zeit funktionierende Prototypen bauen, die echten Mehrwert für Fachbereiche liefern – auch ohne tief in die Programmierung einzusteigen.

Wer sich aktuell mit KI im Unternehmenskontext beschäftigt, kommt an RAG (Retrieval-Augmented Generation) kaum vorbei. Die Idee ist bestechend: Ein LLM soll nicht nur basierend auf seinem Trainingswissen antworten, sondern sich kontextabhängig relevantes, unternehmensspezifisches Wissen "dazuholen".

In der Praxis bedeutet das aber auch: Zusätzliche Infrastruktur (Vektordatenbanken, Pipelines), neue Betriebs- und Governance-Fragen und nicht zuletzt einen nicht zu unterschätzenden Implementierungsaufwand.

Unsere Leitfrage im Hackathon war daher bewusst pragmatisch: Wie weit kommen wir, ohne gleich ein vollwertiges RAG-System aufzubauen? Welche Lücken lassen sich mit Bordmitteln, Workflows und etwas Kreativität schließen?

Wir setzen bei einem unserer Kunden mit Pyramid Analytics eine Reporting-Plattform ein, die bei den Anwender*innen sehr beliebt ist, weil sie in überzeugender Weise, den Selfservice-Ansatz unterstützt. Gleichwohl ist Pyramid im deutschsprachigen Raum noch nicht sehr weit verbreitet, was dazu führt, dass beispielsweise die LLM-Unterstützung beim Codieren mit der Pyramid-eigenen Skriptsprache (PQL) sehr rudimentär ist. 

Ein weiteres Problem, jedoch universell für alle Reporting-Plattformen: Der Zuschnitt der Datengrundlage bzw. der semantischen Datenmodelle. Wir stellen viele kleine Datenmodelle bereit, um die Komplexität innerhalb des Modells gering zu halten. Dafür stehen die Anwender*innen dann oft vor der Frage, welches Datenmodell die Reportinganforderung am besten abbilden kann. Die Antwort dazu ist nicht immer eindeutig, da es in den Modellen Überschneidungen gibt und unterschiedliche Modelle unterschiedliche Aspekte eines Geschäftsfalls beleuchten. 

In beiden Fällen – Programmierunterstützung für eine nicht sehr weit verbreitete Skriptsprache und Hilfe bei der Auswahl spezifischer Modelle – sind LLMs allein überfordert. Ein RAG-System würde hier zuverlässig unterstützen, wäre aber sicher auch etwas überdimensioniert. Deshalb: "How to RAG without RAG?"

Unser erster Ansatz war ein lokales Setup mit Podman und n8n. Podman ist ein Container-Manager ähnlich wie Docker, der Anwendungen isoliert und portabel ausführen kann. n8n ist ein Workflow-Tool, vergleichbar mit Windows Power Automate. Beides ist schnell installiert und eignet sich hervorragend zum Experimentieren. 

Wir haben ein LLM, hier ein in unserer Azure-Umgebung deploytes GPT-Modell, angesprochen und mit Zusatzwissen versorgt, also mit Übersichten und Erläuterungen zu unseren Datenmodellen sowie mit der Pyramid-Dokumentation und Syntax-Referenz zu PQL. n8n diente dabei als Orchestrator, der anhand des von uns aufgebauten Workflows den Ablauf von der Anfrage bis zur Antwort dirigierte: Dokumente einlesen, Inhalte extrahieren, Entscheidungen treffen, Informationen weiterreichen…

Die Arbeit mit dem graphischen Workflow-Tool macht Spaß und bringt schnelle Erfolge. n8n ist allerdings auch nicht selbsterklärend, ohne Erfahrung fehlen insbesondere die grundlegenden Konzepte: Welcher Knoten kommt wann? Muss ich jede Workflowabweichung vorausdenken und implementieren? Wo speichere ich Zwischenergebnisse? Muss ein Dokument explizit geparst werden? 

Sehr hilfreich dabei: Natürlich KI selbst! Beispiel-Workflows im JSON-Format konnten direkt importiert und angepasst werden. Der Durchstich ist damit gelungen – aber: Für eine echte Produktivsetzung wären deutlich mehr Inhalte, saubere Prozesse und eine Integration in die bestehende Infrastruktur nötig.

Im n8n-Workflow haben wir Wissen aus Dokumenten extrahiert, in Embeddings überführt und in eine Vektor-Datenbank geschrieben. Konzeptionell sind das zentrale Bausteine eines RAG-Systems. Aber: Das Retrieval war noch nicht automatisiert und dynamisch bei jeder Nutzerfrage. Chunking-Strategien, Re-Indexierung, Ranking und Monitoring fehlten ganz. Die Orchestrierung erfolgte bewusst leichtgewichtig über regelbasierte Workflows, nicht über dedizierte RAG-Frameworks.

Es war ein "Proto-RAG" oder "RAG-light" – pragmatisch und durchaus einen Mehrwert liefernd. Es wurde aber auch klar, dass dieser Ansatz nicht einfach hochskaliert werden kann, um eine produktiv einsetzbare Lösung zu erhalten.

Da bei uns Copilot als Unternehmens-LLM gesetzt ist, haben wir parallel einen zweiten Weg getestet, die Erstellung eines Agents über Copilot Studio. Ein Agent ist ein vordefinierter Abfrageassistent, der fachliches Wissen aufnehmen und Nutzer*innen kontextbezogene Antworten liefern kann. Wir haben zwei Agenten gebaut, einen für die PQL-Programmierunterstützung und einen für die Erläuterungen zu unseren Datenmodellen.

Die Erstellung und das Testen der Agenten verliefen überraschend reibungslos. Man muss hier nicht in Workflows denken, sondern den Assistenten wie in einem Briefing mit allen Informationen versorgen, die er für die zu erwartenden Anfragen benötigt. Dazu gehören natürlich die Verlinkung oder explizite Bereitstellung des spezifischen Wissens, vor allem aber die Definition eines geeigneten Pre-Prompts als Kern des Briefings. 

Die Qualität der Antworten hängt stark vom Pre-Prompting ab – und hier liegt auch das größte Optimierungspotenzial: So konnte über integrierte Few-Shot-Beispiele die PQL-Syntax in den Antworten des Agenten stark verbessert werden.

Der große Vorteil dieses Copilot-Ansatzes: Ein Agent ist wirklich sehr leichtgewichtig, und er ist nahtlos in eine bestehende Microsoft-Landschaft integriert, so dass unternehmensspezifische Dokumentationen im Zugriff sind, ohne dass sie dem Agenten explizit bereitgestellt werden müssen.  

Was mich persönlich am meisten beeindruckt hat: Wie schnell heute vorzeigbare Ergebnisse entstehen können. Und wie niedrig die Einstiegshürde ist – selbst für jemanden ohne klassischen Entwicklerhintergrund.

Gleichzeitig bleiben die klassischen Fragen aus der DWH-Welt aktuell:

• Datenqualität und Dokumentation bleiben der Engpass – auch für KI.
• Betrieb, Wartung und Governance entscheiden darüber, ob ein Prototyp zur Lösung wird.
• Nicht jede Organisation braucht sofort ein vollwertiges RAG-System – aber jede sollte verstehen, wann es sinnvoll wird.

Der CI-Hackathon hat gezeigt: "To RAG without RAG" funktioniert – zumindest für den Einstieg. Podman & n8n bieten maximale Freiheit fürs Experimentieren, Copilot Studio punktet mit Integration und Einfachheit. Mit überschaubarem Aufwand lassen sich KI-gestützte Nutzererlebnisse schaffen, die Fachbereiche spürbar entlasten und neugierig machen. Gleichzeitig wird auch deutlich, wo die Grenzen liegen und was ein echtes RAG-System darüber hinaus leisten kann. Und manchmal beginnt Innovation genau dort: Nicht mit der perfekten Architektur, sondern mit der richtigen Frage.