Private-KI-Bridge & RAG
Ein LLM-Gateway und ein gemeinsamer Wissensspeicher für die ganze Flotte
Gebaut von Rogue AI · Gemeinsames LLM-Gateway + self-hosted RAG · Interne Infrastruktur
Als Rückgrat gebaut, an das sich jede andere App anschließt, und über mehrere Iterationen gehärtet, als weitere Apps dazukamen: Caching, eine Allowlist, Rate-Limits, Shared-Secret-Auth, Metriken und eine Retrieval-Schicht, hinzugefügt mit den wachsenden Anforderungen der Flotte.
Das Problem
Eine Flotte aus gut zwanzig Apps, die jede ein LLM aufruft, bedeutet zwanzig Kopien desselben Provider-Codes, zwanzig Stellen, an denen ein Key zu rotieren ist, und zwanzig Wege, Retrieval subtil falsch zu machen. Schlimmer noch: jede App, die Fragen über ihre eigenen Dokumente beantworten will, braucht ein Embedding-Modell, einen Vektor-Store, Chunking und Reranking, von denen nichts in die App selbst gehört. Die Aufgabe war, der ganzen Flotte einen Ort zu geben, an den sie Modellaufrufe schickt, und einen Ort, an dem sie Wissen speichert und durchsucht, lokal, ohne dass jede App diese Last trägt.
Was ich gebaut habe
Ein einziges self-hosted Gateway, mit dem jede App spricht, statt direkt mit einem Modell-Provider. Es leitet eine Anfrage über einen Schalter an lokales Ollama oder an Claude, cacht wiederholte Aufrufe, erzwingt eine Allowlist pro App und Rate-Limits hinter einem Shared Secret und stellt Metriken bereit. Daran angebunden ist eine gemeinsame Retrieval-Schicht: ein Qdrant-Vektor-Store, erreichbar über dasselbe Gateway, mit Chunk-beim-Ingest, Reranking und lokal erzeugten Embeddings. Apps schreiben und durchsuchen ihre eigenen Collections; das Gateway besitzt das Embedding-Modell, den Vektor-Store und die Retrieval-Qualität, damit die Apps es nicht müssen.
Architektur
Tech-Stack
Was zuerst gebrochen ist
- ▸
Ein Gateway schlägt SDK-Code pro App. An dem Tag, an dem sich ein Provider-Key oder eine Modell-ID ändert, ändert sie sich an einer Stelle, und jede App läuft ohne Redeploy weiter, weil keine einen eigenen Provider-Client hält.
- ▸
Retrieval-Qualität entscheidet sich an Chunking und Reranking, nicht an der Modellwahl. Chunk-beim-Ingest und einen Rerank-Schritt in die gemeinsamen Endpunkte zu verdrahten, hob die Antwortqualität für alle Verbraucher auf einmal, statt dass jede App es schlecht neu erfindet.
- ▸
Ein gemeinsamer Dienst ist ein gemeinsamer Schadensradius. Eine Allowlist, Rate-Limits pro App, ein Shared Secret und Fail-Closed-Defaults sind nicht mehr optional, sobald mehr als eine App von derselben Tür abhängt, denn der Preis eines Fehlers ist die ganze Flotte, nicht eine App.
Ergebnis
Jede App der Flotte leitet ihre Modellaufrufe und ihre Dokumentensuche über einen self-hosted Dienst, statt eigenen Provider-Code und einen eigenen Vektor-Store zu tragen. Ein Provider- oder Modellwechsel ist eine Ein-Zeilen-Änderung, die Retrieval-Qualität verbessert sich für alle Verbraucher auf einmal, und nichts, weder Prompts noch Dokumente, verlässt den Host. Es ist das gemeinsame Rückgrat, auf dem der produktisierte Private-KI-Stack aufbaut.
Ehrliche Grenzen
Das ist interne Infrastruktur, kein Produkt. Sie läuft in einem lokalen Labor als gemeinsamer Kern einer self-hosted Flotte, an localhost gebunden, hinter einem Shared Secret. Der ehrliche Kompromiss ist die Zentralisierung: jede App leitet ihre Modellaufrufe und ihr Retrieval über einen Dienst, die Bridge ist also zugleich der bequeme einzelne Kontrollpunkt und eine einzelne Abhängigkeit, abgefedert mit Caching und Fail-Closed-Defaults statt beseitigt.