Konzept
Durchsuchbare Wissensquellen für deine Tools.
Eine Knowledge Base (KB) ist eine Sammlung durchsuchbarer Text-Fragmente. Das Modell kann sie nicht direkt lesen — es ruft ein Such-Tool auf, bekommt die passenden Abschnitte zurück und arbeitet damit.
Das ist das klassische RAG-Muster (Retrieval-Augmented Generation): Retrieval liefert die relevanten Passagen, das Modell generiert die Antwort darauf. TaskMonkey macht das Retrieval mit MySQL-Volltext-Suche statt mit Vektor-Embeddings — für die meisten Business-Wissensbasen (FAQ, Handbücher, Produktkatalog) ist das schnell und präzise genug, besonders bei deutschen Texten mit eindeutigen Fachbegriffen.
Wann brauchst du eine KB?
Immer dann, wenn:
- Du stabiles, wiederverwendbares Wissen hast (Produktkatalog, FAQ, Dokumentationen, Policies)
- Das Wissen zu groß ist, um im Prompt zu leben
- Das Wissen sich ändert, aber nicht oft
Schlechte Kandidaten:
- Hochvolatile Daten (Bestände, Preise) — dafür sind APIs besser
- Sehr kleine Datenmengen — lass das Modell sie im Prompt lernen
Aufbau
Eine KB besteht aus zwei Ebenen:
Knowledge Base
├── Source 1 (URL, Datei, DB-Dump)
│ ├── Entry 1.1
│ ├── Entry 1.2
│ └── ...
└── Source 2
├── Entry 2.1
└── ...
- Source: Die Quelle — typisch eine URL (z. B. deine öffentliche FAQ-Seite) oder eine hochgeladene Datei.
- Entry: Ein einzelner durchsuchbarer Abschnitt. Beim Import wird die Source in Entries zerschnitten — typisch pro Überschrift oder pro Absatz.
Das Modell sieht nur Entries, nie ganze Sources.
Suche
Das Modell ruft ein Such-Tool auf:
getKnowledge(query: "Retourenfrist")
Die KB liefert die Top-N Entries mit Relevanz-Score zurück. Das Modell bekommt Titel, Kurz-Snippet und Volltext.
Wo du eine KB anlegst
In der UI: /manage/knowledge-bases/add. Felder:
- Name der KB (intern)
- Beschreibung (optional)
Nach dem Anlegen fügst du Sources hinzu.
Wie das Modell sie nutzt
Du schreibst einen Tool-Handler, der in der KB sucht, und hängst das Tool an den passenden Task:
'tools' => [
'searchProductKnowledge' => [
'extends' => 'getKnowledge',
'description' => 'Durchsucht unseren Produktkatalog-Wissenspool.',
'args_fixture' => ['query' => 'Tomaten'],
],
],
extends: getKnowledge zieht die Basis-Implementation aus der Shared-Library. Du überschreibst nur description und optional options (Limit, Score-Schwelle).
Beispielablauf
- Kunde fragt: „Wie lange kann ich was zurückgeben?"
- Modell ruft
searchProductKnowledge(query: "Rückgabe Frist")auf. - KB liefert zwei Entries: „Retouren-Richtlinie" und „Umtausch FAQ".
- Modell formuliert aus den Inhalten eine passende Antwort.
Mehrere KBs pro Workspace
Möglich und sinnvoll: getrennte KBs für Produktkatalog, FAQ, interne Prozesse. Jede bekommt ein eigenes Such-Tool — das Modell wählt anhand der Beschreibung die richtige.
'searchFaq' => [
'extends' => 'getKnowledge',
'description' => 'Kunden-FAQ durchsuchen (Öffnungszeiten, Kontakt, Versand, Rückgabe).',
],
'searchInternalHandbook' => [
'extends' => 'getKnowledge',
'description' => 'Internes Mitarbeiter-Handbuch (Urlaub, IT, Prozesse).',
],
Weiter
- Sources und Entries — wie Inhalte reinkommen
- In Chats nutzen — das Such-Tool anbinden und tunen