AI-Automatisierungen ohne Unternehmenskontext produzieren generische Ausgaben. Ihr Recipe kann eine großartige Wettbewerbsanalyse schreiben — aber es kennt Ihre Produktnamen nicht. Es kann eine Incident Response entwerfen — aber es hat keine Ahnung, was Ihr Runbook sagt. Es kann Kundenfeedback zusammenfassen — aber es kann nicht auf Ihre interne Taxonomie verweisen.
Wissensdatenbanken beheben das. Laden Sie Ihre Dokumente hoch, und JieGou injiziert relevante Inhalte in jede Recipe- und Workflow-Ausführung automatisch via Retrieval-Augmented Generation (RAG).
Wie Dokumente verarbeitet werden
Laden Sie Dateien in einem dieser Formate hoch: PDF, DOCX, CSV, XLSX, TXT, Markdown, HTML. Oder importieren Sie direkt von einer URL. Die Dateigrößenobergrenze pro Upload beträgt 10 MB, mit einem 1 MB Limit für extrahierten Inhalt nach dem Parsing.
Nach dem Upload durchlaufen Dokumente eine mehrstufige Verarbeitungspipeline:
1. Chunking. Dokumente werden mit einer zweistufigen Strategie aufgeteilt. Zuerst scannt das System nach # und ## Markdown-Überschriften und teilt an diesen Grenzen — das erhält die logische Struktur gut organisierter Dokumente. Für unstrukturierte Dokumente ohne Überschriften fällt es auf absatzbasiertes Splitting zurück. Die Ziel-Chunk-Größe beträgt ca. 40.000 Zeichen (~10K Tokens), mit einem Minimum von 4.000 Zeichen, um Fragmente ohne nützlichen Kontext zu vermeiden.
2. Zusammenfassung. Jeder Chunk erhält eine LLM-generierte Zusammenfassung von 200-400 Wörtern via Claude. Diese Zusammenfassungen dienen zwei Zwecken: Sie bieten Fallback-Kontext, wenn die Embedding-Suche keine Ergebnisse liefert, und sie geben dem Retrieval-System eine komprimierte Darstellung des Chunk-Inhalts.
3. Embedding. Jeder Chunk wird mit OpenAI text-embedding-3-small (1536 Dimensionen) eingebettet. Embeddings werden in Firestore zusammen mit dem Chunk-Inhalt und Metadaten gespeichert — keine externe Vektordatenbank erforderlich.
Wie Retrieval zur Ausführungszeit funktioniert
Wenn ein Recipe oder Workflow-Schritt ausgeführt wird, baut das System ein Kontextfenster aus Ihren Wissensdatenbanken:
- Ein Query-Embedding wird aus dem Prompt des Benutzers oder der Eingabe des Schritts generiert
- Kosinus-Ähnlichkeitssuche läuft gegen alle Chunk-Embeddings in den relevanten Wissensdatenbanken
- Chunks unter einem Mindest-Ähnlichkeitsschwellenwert von 0,3 werden verworfen
- Top-k-Auswahl wählt die besten Treffer innerhalb eines Token-Budgets — Standard ist 5 Chunks, 8.000 Tokens max
- Ausgewählte Chunks werden als XML-
<reference_documents>-Blöcke in den LLM-Prompt injiziert - Wenn keine Embeddings den Schwellenwert erreichen, fällt das System auf zusammenfassungsbasierten Kontext zurück
Embeddings werden in Firestore gespeichert und die Kosinus-Ähnlichkeit wird im Anwendungscode berechnet. Es gibt keine externe Vektordatenbank-Abhängigkeit. Das ist praktisch, weil Token-Budgets die Anzahl der Dokumente pro Abfrage begrenzen — Sie durchsuchen nie Millionen von Vektoren, nur die Dokumente in den Wissensdatenbanken Ihres Accounts.
Dreistufige Kontextauflösung
Nicht jede Ausführung braucht denselben Kontext. JieGou löst Wissensdatenbank-Dokumente aus drei Quellen auf, automatisch zusammengeführt und dedupliziert:
| Stufe | Wie es funktioniert | Wann verwenden |
|---|---|---|
| Explizite Dokument-IDs | Spezifische Dokument-IDs, die zur Ausführungszeit übergeben werden | Wenn Sie genau wissen, welche Dokumente relevant sind |
| Recipe/Workflow-verknüpft | Wissensdatenbanken, die über das knowledgeBaseIds-Feld verlinkt sind | Wenn bestimmte Docs immer ein spezifisches Recipe begleiten sollen |
| Auto-Kontext | Wissensdatenbanken mit isAutoContext: true, nach Abteilung eingegrenzt | Wenn Dokumente für jede Ausführung in einer Abteilung verfügbar sein sollen |
Auto-Kontext ist die leistungsstärkste Stufe. Markieren Sie Ihr Firmenwiki, Produktdokumentation oder Brand Guidelines als Auto-Kontext, und jedes Recipe in dieser Abteilung erhält relevante Chunks ohne manuelle Konfiguration.
Feedbackgesteuerte Relevanz
Wissensdatenbanken werden über die Zeit intelligenter. Wenn Benutzer Daumen-hoch- oder Daumen-runter-Feedback zur Qualität eines Runs geben, passt das System die Chunk-Relevanzscores für zukünftige Retrievals an.
Die Bewertung verwendet Laplace-Glättung: score = (ups + 1) / (ups + downs + 2). Das startet jeden Chunk bei einem neutralen 0,5 und passt basierend auf Evidenz an, wobei extreme Scores aus kleinen Stichproben vermieden werden.
Der resultierende Boost-Faktor reicht von 0,5x bis 1,5x, gespeichert in Redis mit einem 7-Tage-TTL. Chunks, die konsistent in hochwertigen Runs erscheinen, werden geboostet. Chunks, die in minderwertigen Runs erscheinen, werden herabgestuft. Über die Zeit werden die nützlichsten Inhalte häufiger ohne manuelle Kuratierung angezeigt.
Wissenserfassung: Aus guten Ausgaben lernen
Hier werden Wissensdatenbanken zum Schwungrad. Wenn eine Recipe-Ausführung positives Feedback erhält oder gut auf JieGous Quality Guard abschneidet, erfasst das System automatisch strukturiertes Wissen aus dieser Ausgabe.
Ein LLM extrahiert:
- Titel — ein beschreibender Name für das erfasste Wissen
- Schlüsselfakten — die wichtigen Behauptungen, Entscheidungen oder Erkenntnisse
- Entitäten — Personen, Produkte, Unternehmen und andere Eigennamen
- Themen-Tags — Kategorien für Retrieval-Matching
Das extrahierte Wissen wird in einer dedizierten “Automatisch erfasstes Wissen”-Datenbank mit isAutoContext: true gespeichert. Zukünftige Ausführungen in derselben Abteilung können dieses Wissen automatisch abrufen.
Das Ergebnis: Ihr AI-System lernt buchstäblich aus seinen eigenen guten Ausgaben. Eine gut ausgearbeitete Wettbewerbsanalyse heute wird abrufbarer Kontext für das Strategiebriefing von morgen.
Dokumentenfrische
Von URLs bezogene Dokumente können mit einer refreshIntervalDays-Einstellung für automatisches Neuladen konfiguriert werden. Wenn das System ein Dokument neu lädt, berechnet es einen SHA-256-Content-Hash und vergleicht ihn mit dem gespeicherten Hash. Wenn sich der Inhalt nicht geändert hat, stoppt die Verarbeitung.
Wenn sich der Inhalt geändert hat, werden nur die betroffenen Chunks neu verarbeitet — neue Embeddings und Zusammenfassungen werden inkrementell generiert, statt das gesamte Dokument neu zu verarbeiten. Das hält Ihre Wissensdatenbanken aktuell, ohne Rechenleistung für unveränderte Inhalte zu verschwenden.
Write-to-KB-Workflow-Schritt
Workflows können Ausgaben direkt in Wissensdatenbanken schreiben, mit dem dedizierten Write-to-KB-Schritttyp. Das ermöglicht Workflows, die über die Zeit Wissen ansammeln.
Ein Kundensupport-Triage-Workflow könnte ein Ticket lösen und dann die Lösungszusammenfassung in eine Wissensdatenbank schreiben. Wenn das nächste Mal ein ähnliches Ticket eintrifft, steht die Lösung als RAG-Kontext zur Verfügung. Ein wöchentlicher Marktforschungs-Workflow könnte seine Ergebnisse an eine Competitive-Intelligence-Wissensdatenbank anhängen, die mit jedem Run reichhaltiger wird.
Scoping und Zugriffskontrolle
Wissensdatenbanken werden pro Account eingegrenzt mit optionaler Abteilungsfilterung. Auto-Kontext-Wissensdatenbanken respektieren Abteilungsgrenzen — die internen Docs der Engineering-Abteilung gelangen nicht in die Recipe-Ausführungen des Marketings.
Dieses Scoping wird auf der Retrieval-Ebene durchgesetzt. Wenn die dreistufige Kontextauflösung läuft, werden Auto-Kontext-Wissensdatenbanken nach der Abteilung des ausführenden Benutzers gefiltert, bevor eine Embedding-Suche stattfindet.
Verfügbarkeit
Wissensdatenbanken mit RAG sind ab dem Pro-Tarif verfügbar. Automatisch erfasstes Wissen und der Write-to-KB-Workflow-Schritt sind ohne zusätzliche Kosten enthalten. Alle Features erkunden oder kostenlose Testversion starten.