Modulkonfiguration
Knowledge Gaps
Wie Gfacility einen fehlenden Artikel erkennt: eine Suche mit null Treffern, als Verhalten protokolliert, pro Thema geclustert und erst sichtbar, sobald mindestens zwei verschiedene Nutzer daran scheitern.
Aktualisiert am 14. Aug. 2026
Konfiguration · Module · Wissensdatenbank
Die meisten Wissensdatenbanken scheitern lautlos. Niemand legt ein Ticket an mit dem Text “eurer Dokumentation fehlt eine Seite zum VPN-Passwort”: Menschen suchen, finden nichts und fragen stattdessen eine Kollegin. Knowledge Gaps machen aus diesem unsichtbaren Moment einen messbaren. Jede Suche in Gfacility, die null Treffer liefert, wird protokolliert, und sobald genug Menschen am selben Punkt scheitern, erscheint das Thema auf einer Prioritätenliste für eure Redaktion.
Der Auslöser ist Verhalten, kein Urteil. Eine Lücke entsteht, weil eine Suche keine Treffer ergeben hat, nicht weil eine KI selbst bewertet, ob die Antwort gut genug war.
Wann gilt etwas als Lücke?
Null Treffer, messbar
Der Auslöser ist objektiv und reproduzierbar: die Suche lieferte nichts. Kein Modell bewertet die Qualität einer Antwort.
Ein geteiltes Problem, keine Einzelperson
Mindestens zwei verschiedene Nutzer müssen auf dasselbe Thema stoßen, bevor es als Lücke sichtbar wird.
Rauschen herausgefiltert
Buchstabenweises Tippen, wiederholte Suchen und Tippfehler werden zusammengeführt, damit die Liste Themen zeigt und keine Tastenanschläge.
Eine Liste, kein Prozess
Es entsteht kein Ticket und es startet kein Workflow. Ihr bekommt ein priorisiertes Backlog von Themen zum Dokumentieren.
Wo ein Fehltreffer erfasst wird
Drei Stellen in Gfacility protokollieren einen Fehltreffer in Echtzeit:
Suchleiste der Wissensdatenbank
Die Suchleiste, in der Nutzer selbst nach einem Artikel suchen.
Find-Panel und KI-Chat
Das Suchfeld im Find-Panel und im KI-Chat, wo Fragen in natürlicher Sprache gestellt werden.
"Nicht hilfreich"
Explizites Feedback zu einem angezeigten Artikel: eine Antwort war da, sie hat aber nicht geholfen.
Der Prozess in sechs Schritten
| Schritt | Was passiert |
|---|---|
| 1. Erfassung | In Echtzeit. Eine Suche mit null Treffern, in der Wissensdatenbank oder im Find-Panel / KI-Chat, wird als Fehltreffer protokolliert, ebenso explizites "Nicht hilfreich"-Feedback zu einem Artikel. |
| 2. Normalisierung | Der Suchtext wird bereinigt: Satzzeichen entfernt, Kleinschreibung, Stoppwörter raus. Reste unter drei Zeichen werden ignoriert. |
| 3. Rauschunterdrückung | Dieselbe Person, die innerhalb von zehn Minuten denselben Begriff sucht, erzeugt keine zweite Zeile. Type-ahead (buchstabenweises Tippen) wird erkannt und zu einer Suche zusammengeführt. |
| 4. Clustering | Beim Reporting werden Tippfehler und Varianten desselben Themas per Fuzzy-Matching über Textähnlichkeit zusammengeführt, sodass "vpn passwort zurücksetzen" und "passwort zurücksetzen" als dieselbe Lücke zählen. |
| 5. Datenschutzschwelle | Erst wenn mindestens zwei verschiedene Nutzer auf dasselbe Problem stoßen, wird daraus eine sichtbare Lücke. Eine Einzelperson mit einem Tippfehler zählt nicht, anonyme Suchen zählen grundsätzlich nicht. |
| 6. Ergebnis | Eine Prioritätenliste: welchen Themen erkennbar Dokumentation fehlt, wie oft das vorkommt und welche exakten Suchbegriffe verwendet wurden. |
Privacy by Design
Die Schwelle in Schritt 5 ist der Kern des Entwurfs, kein technisches Detail. Eine einzelne Suche sagt etwas über eine Person; dieselbe Suche von zwei verschiedenen Personen sagt etwas über eure Dokumentation. Gfacility zeigt nur das Zweite.
Mindestens zwei Nutzer
Unterhalb der Schwelle wird nichts angezeigt, damit der Bericht nie als Suchverlauf einer einzelnen Person lesbar ist.
Anonyme Suchen zählen nicht
Eine Suche ohne bekannten Nutzer kann nicht mitzählen, weil sich nicht feststellen lässt, dass zwei verschiedene Personen beteiligt sind.
Was eure Redaktion bekommt
Das Ergebnis ist bewusst klein: kein Ticket, kein Workflow, keine Freigabekette. Genau die drei Dinge, die ihr braucht, um zu entscheiden, was als Nächstes geschrieben wird.
Thema
Das geclusterte Thema, das gesucht und nicht gefunden wurde.
Häufigkeit
Wie oft es vorkommt, damit die größte Lücke zuerst geschrieben wird und nicht die lauteste Anfrage.
Exakte Suchbegriffe
Die Wörter, die wirklich getippt wurden, also die Wörter, die der neue Artikel in Titel und Tags verwenden sollte.
Diese Suchbegriffe sind der praktische Teil: ein Artikel, der die Formulierung eurer Kolleginnen und Kollegen trägt, wird von den Matching-Regeln aus 4.2 Wissensdatenbank gefunden und erscheint automatisch, wenn das nächste Mal jemand dazu ein Ticket anlegt.
Welche Entscheidungen trefft ihr?
Wer prüft die Liste, und wie oft?
Ein fester Termin (monatlich oder pro Sprint) schlägt den spontanen Blick, denn Häufigkeit wird erst über einen Zeitraum aussagekräftig.
Artikel schreiben oder Auffindbarkeit reparieren?
Gibt es den Inhalt schon, ist die gesuchte Formulierung als Tag oft die schnellere Lösung.
In welcher Sprache wird gesucht?
Die Suchbegriffe zeigen es. In internationalen Teams spricht das für eine Übersetzung statt für einen neuen Artikel.
Welche Lücken füllt ihr bewusst nicht?
Manche Suchen zeigen auf ein ganz anderes System. Diese Grenze einmal zu dokumentieren, ist auch eine Antwort.