Enterprise RAG Projekt: RAG und Agenten auf Azure

Robin, Pexon Consulting | 8 Min. Lesezeit

TL;DR

In einem anonymisierten Enterprise RAG Projekt haben wir für einen Großkunden ein produktives KI-System auf Azure gebaut: RAG über interne Dokumente, orchestrierte Agenten mit Tool-Calling, PGVector als Vektor-Store, alles mit CI/CD und Compliance. Pexon liefert solche Systeme vom Konzept bis in den Betrieb, als 6-Wochen-Pilot.

Die Ausgangslage

Ein Kunde im Enterprise-Umfeld hatte die typische Situation: viel internes Wissen, verteilt über Dokumente und Systeme, und erste KI-Experimente, die im Prototyp-Stadium hängen geblieben waren. Ein Skript hier, ein Notebook dort, nichts davon betriebsreif. Was fehlte, war nicht die Idee, sondern der Weg vom Experiment zu einem System, dem man produktiv Arbeit anvertrauen kann.

Der Auftrag war entsprechend klar umrissen: die Konzeption, Entwicklung und Integration produktiver KI-Lösungen auf Basis von Large Language Models, remote, auf Deutsch, im Azure-Ökosystem des Kunden. Kein Forschungsprojekt, sondern Software, die in die bestehende Landschaft passt und Bestand hat.

Was wir im Enterprise RAG Projekt gebaut haben

Kern der Lösung war ein RAG-System über die internen Dokumente des Kunden, ergänzt um eine Agenten-Schicht, die mehr kann als nur nachschlagen. Die Bausteine im Überblick:

• RAG über interne Daten: Dokumente werden aufbereitet, in PGVector als Vektor-Store abgelegt und über eine Retrieval-Schicht durchsuchbar gemacht. Relationale Daten in PostgreSQL und die Vektorsuche liegen dabei bewusst nah beieinander.
• Agent-Orchestrierung: Statt eines einzelnen Prompts koordinieren mehrere Agenten die Aufgabe, mit Tool-Calling für den Zugriff auf externe Services und Systeme. Wie so eine Orchestrierung sauber aufgebaut wird, beschreiben wir in der AI Agent Orchestrierung.
• Saubere Schnittstellen: API-Design nach modernen Architekturprinzipien, damit sich die KI-Services in die bestehende Systemlandschaft einfügen statt daneben zu stehen.

Ein vereinfachter Blick auf die Retrieval- und Tool-Logik in Python:

# RAG-Retrieval aus PGVector, dann Agent mit Tool-Calling
from openai import AzureOpenAI

def suche_kontext(frage, embedder, db):
    vektor = embedder.embed(frage)
    # nächste Nachbarn aus PGVector holen (Cosine-Distanz)
    return db.query(
        "SELECT text FROM wissen ORDER BY embedding <=> %s LIMIT 5", [vektor]
    )

def beantworte(frage, client, tools):
    kontext = suche_kontext(frage, embedder, db)
    return client.chat.completions.create(
        model="gpt-4-1",                       # Azure OpenAI Deployment
        messages=[{"role": "user", "content": f"{kontext}nnFrage: {frage}"}],
        tools=tools,                           # Tool-Calling für externe Services
    )

Wie wir gearbeitet haben

Der Unterschied zwischen einem Demo und einem Produktivsystem liegt nicht im Modell, sondern im Drumherum. Deshalb war Software-Qualität von Anfang an Teil der Arbeit, nicht ein nachgelagerter Schritt: Testautomatisierung, CI/CD über GitLab, technische Konzepte, die auch der nächste Entwickler versteht.

Genauso wichtig war die Compliance-Seite. Ein KI-System, das auf interne Daten zugreift, muss Datenschutz-, Security- und Compliance-Anforderungen erfüllen, bevor es in Produktion geht, nicht danach. Rechte, Nachvollziehbarkeit und der saubere Umgang mit sensiblen Daten waren Teil der Architektur. Unsere klare Position: Wer diese Schicht ans Ende schiebt, baut ein System, das im Review durchfällt.

Das Ergebnis

Am Ende stand kein Notebook, sondern ein produktives System: eine zentrale, durchsuchbare Wissensbasis über die internen Dokumente, Agenten, die definierte Aufgaben mit Tool-Zugriff übernehmen, und ein Betrieb, der über CI/CD wartbar bleibt. Der Kunde ist damit von verstreuten Experimenten zu einer Plattform gekommen, auf der weitere Anwendungsfälle aufsetzen können.

Genau das ist der Punkt eines guten KI-Projekts: nicht die einzelne beeindruckende Demo, sondern die tragfähige Basis. Wie eine RAG-Engine mit tiefem Dokumentverständnis dabei hilft, zeigt unser Beitrag zu RAGFlow.

Häufig gestellte Fragen

Was war der Kern des Projekts?

Ein produktives RAG-System über interne Unternehmensdokumente auf Azure, ergänzt um eine Agenten-Schicht mit Tool-Calling. Statt isolierter Prototypen entstand eine wartbare Plattform mit CI/CD, sauberen Schnittstellen und eingebauter Compliance, auf der weitere Anwendungsfälle aufsetzen.

Warum PGVector und nicht eine dedizierte Vektordatenbank?

Weil relationale Daten und Vektorsuche beim Kunden nah beieinander lagen und PostgreSQL bereits im Einsatz war. PGVector hält beides in einem System, was Betrieb und Governance vereinfacht. Bei sehr großen oder spezialisierten Workloads kann eine dedizierte Vektordatenbank sinnvoller sein, das entscheidet der Anwendungsfall.

Wie stellt ihr sicher, dass so ein System betriebsreif ist?

Über Software-Qualität von Anfang an: Testautomatisierung, CI/CD, saubere technische Konzepte und eine Architektur, die Datenschutz und Compliance einbaut statt nachrüstet. Der Unterschied zwischen Demo und Produktion liegt genau in dieser Disziplin, nicht im gewählten Modell.

Was kostet ein solches Enterprise RAG Projekt?

Das hängt vom Umfang ab. Ein produktionsnaher erster Anwendungsfall lässt sich als 6-Wochen-Pilot aufsetzen, der eine belastbare Basis liefert. Der Ausbau auf weitere Anwendungsfälle folgt anschließend. Die laufenden Kosten sind vor allem Azure-Betrieb und Wartung.

Lässt sich das auch souverän ohne US-Cloud umsetzen?

Ja. In diesem Projekt lief die Lösung im Azure-Ökosystem des Kunden. Wo echte Datenhoheit gefordert ist, bauen wir dieselbe Architektur mit self-hosted Open-Weight-Modellen auf eigener Infrastruktur. Der Aufbau bleibt gleich, nur die Modellschicht wechselt.

Nächster Schritt

Sie haben internes Wissen, das eine KI erschließen soll, und wollen kein weiteres Experiment, sondern ein System, das trägt? Wir klären in einem kurzen Gespräch, welcher Anwendungsfall bei Ihnen den größten Hebel hat und wie der Weg in Produktion aussieht.

Verwandte Themen