Ähnliche Textstellen sind noch keine Antwort.
Die technische Grundidee eines Retrieval-Systems ist überschaubar: relevante Informationen suchen und sie einer Antwort als Kontext bereitstellen. Die Qualität im Unternehmen entscheidet sich aber an den Stellen, die eine einfache Suche noch nicht abdeckt.
Ein Dokument kann veraltet sein. Zwei Quellen können unterschiedliche Regeln beschreiben. Eine Person darf möglicherweise nur einen Teil der gefundenen Daten sehen. Solche Fälle sind normale Eigenschaften von Unternehmenswissen.
Zugriff vor Antwort.
Berechtigungen müssen bereits die Suche begrenzen. Ein System sollte vertrauliche Textstellen gar nicht erst in den Modellkontext aufnehmen, wenn die fragende Person sie nicht lesen darf. Quellen anschließend aus der Antwort auszublenden, reicht nicht.
Quellen mit Kontext.
Eine zitierte Quelle ist nützlich, wenn sie eine konkrete Aussage nachvollziehbar macht. Dazu gehören die passende Textstelle, der Dokumenttitel und – sofern vorhanden – Version, Gültigkeit und Verantwortlichkeit.
Ein gutes Knowledge System weiß auch, wann seine Quellen nicht ausreichen.
Widersprüche sichtbar machen.
Wenn eine ältere Arbeitsanweisung drei Tage und ein neuerer Beschluss zwei Tage nennt, sollte das System den Widerspruch benennen. Es darf ihn nur auflösen, wenn es eine belastbare Regel für Priorität und Gültigkeit gibt. Das Erstellungsdatum allein muss dafür nicht genügen.
Evaluation mit echten Fragestellungen.
Die Prüfung braucht mehr als schöne Beispielantworten. Ein Testset sollte bekannte Fragen, nicht beantwortbare Fragen, Berechtigungsgrenzen und widersprüchliche Quellen enthalten. Geprüft werden sowohl die gefundenen Informationen als auch die daraus formulierte Antwort.
Im Knowledge-Lab sind genau diese Situationen mit wenigen synthetischen Dokumenten bewusst sichtbar. Die deterministische Demo veranschaulicht Quellen und Unsicherheit; eine produktive Umsetzung benötigt ein eigenes Retrieval- und Evaluationssystem.