Das Problem: RAG, das nicht mithalten konnte
Wissensdatenbanken sind nur nutzlich, wenn die Suche schnell ist. Als wir RAG-Unterstutzung in JieGou einfuhrten, funktionierte die Pipeline — Dokumente wurden in Chunks aufgeteilt, Embeddings generiert und in Prompts injiziert. Aber die Performance erzahlte eine andere Geschichte.
Eine Wissensdatenbank mit 705 Dokumenten brauchte ~160 Sekunden, um relevanten Kontext abzurufen. Das bedeutete, dass jede Recipe-Ausfuhrung, jeder Workflow-Schritt und jede Agent-Konversation, die auf eine Wissensdatenbank zugriff, eine mehrminutige Verzogerung hinnehmen musste, bevor das LLM uberhaupt mit der Generierung begann.
Fur interaktive Anwendungsfalle — ein Kundenservice-Mitarbeiter, der eine Richtlinie nachschlagt, ein Vertriebsmitarbeiter, der mitten im Gesprach Produktspezifikationen abruft — sind 160 Sekunden inakzeptabel.
Wir mussten die Suchzeit auf unter eine Sekunde bringen, ohne die Infrastruktur-Komplexitat zu erhohen.
Phase 1: Firestore-native Vektorsuche
Der ursprungliche Sucheansatz lud alle Embeddings aus Firestore, berechnete die Kosinusahnlichkeit im Anwendungscode und gab die Top-k-Ergebnisse zuruck. Er war einfach und korrekt, skalierte aber linear mit der Dokumentenanzahl.
Die erste Optimierung bestand darin, die Ahnlichkeitssuche in Firestore selbst zu verlagern, unter Verwendung von Firestore Vector Search (basierend auf ScaNN-Indizierung). Anstatt alle 705 Embeddings in den Speicher zu laden und Distanzen zu berechnen, liessen wir Firestore die Nachste-Nachbarn-Suche nativ durchfuhren.
Was sich geandert hat
- Vorher: Alle Embeddings abrufen → Kosinusahnlichkeit in Node.js berechnen → sortieren → Top-k nehmen
- Nachher: Eine einzige Firestore-Abfrage mit
findNearest()→ gibt Top-k direkt zuruck
Dies eliminierte den O(n)-Datentransfer und die Berechnung. Firestores Vektorindex verwendet approximative nachste Nachbarn, was einen vernachlassigbaren Recall-Verlust gegen massive Geschwindigkeitsgewinne bei grosseren Sammlungen eintauscht.
Ergebnisse
Cold-Query auf 705 Dokumenten sank von ~160s auf ~10s. Eine 16-fache Verbesserung — aber immer noch zu langsam fur interaktive Workflows.
Phase 2: Hybride Suche mit Fallback
Nicht jede Abfrage profitiert gleichermassen von der Vektorsuche. Einige Wissensdatenbanken sind klein genug, dass Brute-Force schneller ist als der Overhead einer Vektorindex-Abfrage. Andere haben Dokumente, die sich nicht gut embedden lassen (Tabellen, Code-Snippets, strukturierte Daten).
Wir haben eine hybride Suchstrategie implementiert:
- Zuerst Vektorsuche versuchen — Wenn ein Firestore-Vektorindex existiert und die Wissensdatenbank Embeddings hat,
findNearest()verwenden - Auf Brute-Force zuruckfallen — Wenn die Vektorsuche fehlschlagt, nicht verfugbar ist oder zu wenige Ergebnisse liefert, Embeddings laden und Ahnlichkeit im Anwendungscode berechnen
- Zusammenfuhren und deduplizieren — Ergebnisse beider Pfade kombinieren, nach Dokument-ID deduplizieren, nach Ahnlichkeitswert neu sortieren
Der hybride Ansatz bedeutet, dass die Suche niemals fehlschlagt. Wenn Firestore-Vektorindizes noch nicht erstellt wurden (z.B. in einer neu bereitgestellten Umgebung), degradiert das System elegant zum ursprunglichen Brute-Force-Pfad.
Das usedVectorSearch-Flag
Jede Suchoperation enthalt jetzt einen usedVectorSearch-Boolean in ihrem Trace-Span. Damit konnen wir uberwachen, welche Abfragen den schnellen Pfad nutzen und welche auf den Fallback zugreifen, und Wissensdatenbanken identifizieren, die Index-Erstellung oder Re-Embedding benotigen.
Phase 3: Redis-Caching fur warme Abfragen
Die letzte Optimierung zielt auf wiederholte Abfragen ab — dieselbe Frage an dieselbe Wissensdatenbank innerhalb eines kurzen Zeitfensters. Das passiert in der Produktion standig:
- Mehrere Workflow-Schritte, die dieselbe FAQ-Wissensdatenbank abfragen
- Agent-Konversationen, die bei jeder Runde Kontext erneut abrufen
- Batch-Ausfuhrungen, bei denen 50 Elemente identische Referenzdokumente abfragen
Wir haben einen dokumentenbasierten Redis-Cache mit 10 Minuten TTL hinzugefugt:
- Vor der Ahnlichkeitssuche Redis auf gecachte Ergebnisse prufen, geschlusselt durch
(knowledgeBaseId, queryEmbeddingHash) - Bei Cache-Hit sofort zuruckgeben — uberhaupt keine Firestore-Abfrage
- Bei Cache-Miss die hybride Such-Pipeline ausfuhren und die Ergebnisse cachen
Ergebnisse
| Szenario | Vorher | Nachher |
|---|---|---|
| Cold-Query, 705 Dokumente | ~160s | ~10s |
| Warme Abfrage (Redis-Hit) | ~160s | <1s |
| Kleine KB (<50 Dokumente) | ~5s | ~2s |
| Batch von 50 Elementen, gleiche KB | ~8.000s gesamt | ~10s + 49x <1s |
Das Batch-Szenario ist der Bereich, in dem Caching den grossten Gewinn liefert. Das erste Element tragt die Cold-Query-Kosten; die verbleibenden 49 Elemente treffen Redis und kehren in Millisekunden zuruck.
Architektur: null externe Abhangigkeiten
Eine zentrale Design-Einschrankung war keine zusatzliche Infrastruktur. Viele RAG-Plattformen erfordern die Bereitstellung und Verwaltung einer dedizierten Vektordatenbank — Pinecone, Weaviate, Qdrant, Milvus. Jede davon fugt hinzu:
- Einen weiteren Service zum Deployen und Uberwachen
- Einen weiteren Satz von Zugangsdaten zur Verwaltung
- Eine weitere Abrechnungsdimension des Anbieters
- Einen weiteren Fehlermodus in Ihrer Pipeline
JieGous Ansatz verwendet nur Infrastruktur, die Sie bereits haben:
| Komponente | Zweck | Bereits vorhanden? |
|---|---|---|
| Firestore | Vektorindex + Dokumentenspeicher | ✅ Ihre primare Datenbank |
| Redis | Abfrageergebnis-Caching | ✅ Bereits fur Rate-Limiting und Sessions genutzt |
| Anwendungscode | Brute-Force-Fallback | ✅ Lauft in Ihren bestehenden Pods |
Kein Pinecone. Kein Weaviate. Keine neue Infrastruktur zum Bereitstellen, Absichern oder Bezahlen.
Was das fur Ihre Workflows bedeutet
Schnellere Recipe-Ausfuhrung
Jedes Recipe, das eine Wissensdatenbank nutzt, ruft Kontext fur warme Abfragen jetzt in unter einer Sekunde ab. Der “Denke nach…”-Spinner vor der Generierung ist fur wiederholte Anwendungsfalle verschwunden.
Praktische Batch-Verarbeitung
Batch-Ausfuhrungen, die Hunderte von Elementen gegen dieselbe Wissensdatenbank verarbeiten, sind jetzt realisierbar. Das erste Element warmt den Cache auf; der Rest fliegt durch.
Agent-Konversationen, die sich sofortig anfuhlen
Konversations-Agents fragen Wissensdatenbanken bei jeder Runde erneut ab. Mit Redis-Caching rufen die Runden 2 bis N Kontext in Millisekunden ab, anstatt die Ahnlichkeitssuche erneut auszufuhren.
Beobachtbare Suche
Das usedVectorSearch-Trace-Flag bedeutet, dass Sie genau sehen konnen, welcher Suchpfad bei jeder Ausfuhrung verwendet wurde. Wenn eine Wissensdatenbank konsistent auf Brute-Force zuruckfallt, wissen Sie, dass sie Aufmerksamkeit benotigt.
Jetzt ausprobieren
Wenn Sie bereits JieGou-Wissensdatenbanken verwenden, sind diese Optimierungen live — keine Konfigurationsanderungen erforderlich. Ihre bestehenden Wissensdatenbanken profitieren automatisch von Firestore-Vektorsuche und Redis-Caching.
Wenn Sie noch keine Wissensdatenbank eingerichtet haben:
- Gehen Sie zu Knowledge Bases in der JieGou-Konsole
- Laden Sie Dokumente hoch oder importieren Sie von einer URL
- Verknupfen Sie die Wissensdatenbank mit einem beliebigen Recipe oder Workflow
- Beobachten Sie, wie die Suche in unter einer Sekunde stattfindet
Die Kombination aus Firestore-nativer Vektorsuche, hybrider Suche und Redis-Caching bedeutet, dass Ihre AI-Automatisierungen unternehmensspezifischen Kontext erhalten, ohne den Latenz-Aufschlag — und ohne eine einzige zusatzliche Infrastruktur-Komponente verwalten zu mussen.