Jump to content
Menü aufrufen
Toggle preferences menu
Persönliches Menü aufrufen
Nicht angemeldet
Ihre IP-Adresse wird öffentlich sichtbar sein, wenn Sie Änderungen vornehmen.

Unser Wiki ist seit dem 2. Oktober öffentlich lesbar. Mehr dazu.

Gkc24-Session: Unternehmenswissen im Griff: Chatten mit einem wissensbasierten LLM

Aus GfWM Wiki
Unternehmenswissen im Griff: Chatten mit einem wissensbasierten LLM
Art Session
KnowledgeCamp KnowledgeCamp 2024
Speaker:in Alexandra Klaffschenkel


Datum 10.10.2024
Zeit 17:00 bis 17:45 Uhr
Sprache Deutsch


KI-Unterstützung GPT-6.1 Sol

Aus dem Veranstaltungsprogramm

In dieser Session zeige ich, wie Unternehmen die Vorteile von Large Language Models (LLMs) nutzen können, ohne dabei auf externe Anbieter angewiesen zu sein. Durch das selbstgehostete LLM bleiben alle Daten im eigenen Haus, was nicht nur die Datensicherheit erhöht, sondern auch die Kontrolle über die Verfügbarkeit und Qualität der Informationen stärkt. Anhand eines praxisnahen Beispiels erläutere ich, wie man LLMs auf erschwinglicher Hardware betreiben kann und welche Möglichkeiten sich durch die Integration in bestehende Wissensmanagement-Systeme wie INTERGATOR ergeben. Ziel der Session ist es, die Teilnehmer für die Potentiale eines unternehmenseigenen LLM zu sensibilisieren und gemeinsam über die Herausforderungen und Chancen zu diskutieren. Das Format ist eine Mischung aus Impuls-Vortrag und offener Diskussion.

Disclaimer: Diese Seite ist KI-generiert, basierend auf einer KI-Zusammenfassung des Transkripts vom vorstehenden Youtube-Video!

Überblick

Alexandra Klaffschenkel zeigt, wie INTERGATOR Unternehmensdaten erschließt und gefundene Inhalte für Antworten eines Large Language Models bereitstellt. Im Mittelpunkt stehen die Verbindung von Suche und Sprachmodell, dokumentbezogene Zugriffsrechte sowie die Anpassung an Fachabteilungen und Anwendungsfälle. Die Diskussion behandelt außerdem Halluzinationen, Aktualisierung und selbst gehostete Modelle. Eine zentrale Erkenntnis lautet: Ein Chat erleichtert den Zugang zum Unternehmenswissen, ersetzt aber weder ein belastbares Berechtigungskonzept noch die notwendige Projektarbeit.

Aufbau und Perspektive der Session

Klaffschenkel gestaltet die Session mit wenigen Folien, einer Live-Demonstration und fortlaufenden Fragen aus dem Publikum. Sie knüpft an ihre Vorstellung des Unternehmensdaten-Chats im Vorjahr an und bittet die Teilnehmenden, Erfahrungen mit eigenen LLM- und RAG-Projekten einzubringen.

Als Key Account Managerin bei Interface projects nimmt sie bewusst die Perspektive einer Endanwenderin ein. Beschäftigte erwarteten zunehmend die einfache Bedienbarkeit, die sie von privaten Chat-Anwendungen kennen. Technische Details stehen für sie weniger im Vordergrund als die Frage, ob eine Lösung im Arbeitsalltag funktioniert. Bei mehreren Architekturfragen verweist sie deshalb auf einen möglichen technischen Vertiefungstermin.

Der angekündigte Ablauf umfasst die Entstehung der Lösung, das Chatten mit INTERGATOR, Erwartungen an LLMs, Erfahrungen des vergangenen Jahres und Vor- beziehungsweise Nachteile selbst gehosteter Modelle. Die tatsächliche Session entwickelt sich stark entlang der Publikumsfragen: Auf die Demonstration folgen Diskussionen über Retrieval, Berechtigungen, Datenqualität und Sicherheitsrisiken.

Unternehmenswissen erschließen statt Dokumente einzeln hochladen

Klaffschenkel beschreibt INTERGATOR als mehrstufige Lösung. Die Grundlage bildet eine Enterprise Search, die unterschiedliche Datenquellen über Konnektoren verbindet. Diese lesen neben Inhalten auch Rollen und Berechtigungen aus. Die Suche soll relevante Informationen aus vorhandenen Beständen auswählen, ohne dass Beschäftigte die passenden Dokumente selbst zusammensuchen und einzeln für eine Chat-Anfrage hochladen müssen.

Das Sprachmodell steht am Ende dieses Prozesses. Zunächst werden relevante Dokumente ermittelt. Anschließend gelangen nur die für die Frage benötigten Abschnitte als sogenannte Chunks an das LLM, das daraus eine natürlichsprachliche Antwort erzeugt. Klaffschenkel unterscheidet damit zwischen dem Auffinden von Wissen und seiner sprachlichen Darstellung.

In der Demonstration nutzt sie die fiktive Balsa AG, einen Hersteller von Schiffsmotoren. Sie übernimmt die Rolle einer neuen Vertriebsmitarbeiterin und fragt, welche Kunden bereits eine Antriebskette und eine Batterie gekauft haben. Das System nennt Kunden und zeigt die zugrunde liegenden Dokumente. Eine Nachfrage nach dem Nettopreis einer Batterie liefert im Beispiel 115 Euro; Klaffschenkel öffnet die entsprechende Quelle.

Die Demonstration veranschaulicht sowohl die dialogische Nachfrage als auch die Verbindung zwischen Antwort und Beleg. Als mögliche Quellen nennt sie unter anderem CRM-Systeme, SAP und Outlook-Nachrichten. Filter können die Suche zusätzlich beeinflussen.

Semantik und Relevanz müssen zum Anwendungsfall passen

Für die Verarbeitung einer Suchanfrage beschreibt Klaffschenkel ein Embedding-Modell, das ähnliche Begriffe, Synonyme und thematische Zusammenhänge erschließt. Neben Standardmodellen könne ein unternehmensspezifisches Modell eingesetzt werden, etwa bei zahlreichen internen Abkürzungen oder Eigennamen. Dafür sei eine gute Datengrundlage erforderlich.

Auf die Frage nach Dokumenten mit ähnlicher Sprache, aber unterschiedlichen Inhalten verweist sie auf das Preprocessing und die Nutzung von Metadaten. Die Unterscheidung werde nicht allein dem generierenden Sprachmodell überlassen. Auch Taxonomien und Klassifizierungen könnten im Projekt berücksichtigt werden.

Klaffschenkel erläutert außerdem die Vektorisierung von Texten und Dokumenten. Ihre zunächst zukunftsgerichtete Formulierung präzisiert sie auf Nachfrage: Entsprechende Verfahren würden bereits eingesetzt. Die technische Umsetzung bleibt in der Session allerdings nur skizziert.

Entscheidend sei das Relevanzranking. Eine breit angelegte Suche könne sehr viele Treffer liefern, darunter wenig hilfreiche Nachrichten. Deshalb müsse ein RAG-System auf eine Fachabteilung oder einen konkreten Anwendungsfall zugeschnitten werden. Dabei werde festgelegt, welche Datenquellen besonders wichtig sind und welche Inhalte höher gewichtet werden.

Eine allgemeine Lösung für alle Beschäftigten lehnt Klaffschenkel ausdrücklich ab. Vertrieb und Buchhaltung hätten unterschiedliche Informationsbedürfnisse. Ein Inhalt könne für eine Person zentral und für eine andere praktisch bedeutungslos sein.

Berechtigungen und Aktualisierung als Grundlage

Ein wiederkehrendes Thema ist die Übernahme bestehender Zugriffsrechte. Auf die Frage nach unterschiedlichen Rechtekonzepten, etwa in einem Abteilungslaufwerk und SAP, erklärt Klaffschenkel, dass neben dem Active Directory auch die Berechtigungen der jeweiligen Datenquelle ausgelesen würden. Die genaue technische Zuordnung erläutert sie nicht.

Nach ihrer Darstellung enthält der Volltextindex auch die Berechtigungen für einzelne Dokumente. Für seine Erstellung werden Dokumente eingelesen; anschließend werde der übrige eingelesene Dokumentbestand wieder gelöscht. Der Betrieb sei sowohl in der Cloud als auch on-premise möglich.

Änderungen werden durch eine je Datenquelle konfigurierbare Nachindexierung berücksichtigt. Diese prüfe neue, veränderte und gelöschte Dokumente sowie Änderungen an deren Berechtigungen. Für häufig wechselnde Inhalte könnten kurze Intervalle gewählt werden, für weitgehend unveränderte Archive längere. Dringende Sperren ließen sich auch manuell oder über Prozesse anstoßen.

Für den Chat bedeutet dies nach Klaffschenkels Darstellung: Unterschiedlich berechtigte Personen können auf dieselbe Frage unterschiedliche Antworten erhalten. Fehlen passende Informationen oder die erforderlichen Rechte, soll das System keine entsprechende Antwort liefern.

Dokumentierte Antworten statt eigenständiger Analysen

Klaffschenkel berichtet von hohen Erwartungen an LLMs. Viele Interessierte wünschten nicht nur Antworten aus vorhandenen Texten, sondern ein System, das selbstständig mitdenkt und Analysen erstellt. Diese Erwartung grenzt sie von der vorgestellten Lösung ab.

INTERGATOR liefere in der beschriebenen Basis Antworten auf Grundlage bereits dokumentierter Informationen. Eine Frage danach, mit welchem Lieferanten in einem bestimmten Jahr der größte Umsatz erzielt wurde, werde nicht beantwortet, wenn diese Erkenntnis nirgends im Bestand festgehalten ist. Die Lösung soll also nicht aus verstreuten Angaben selbstständig eine neue Auswertung ableiten.

Auch die Frage nach Halluzinationen führt zu einer Präzisierung. Zunächst erklärt Klaffschenkel, diese würden über die Konfiguration ausgeschlossen. Im weiteren Austausch wird jedoch festgehalten, dass sich das Risiko stark reduzieren, aber nicht vollständig ausschließen lasse. Sie bestätigt, dass Fehler weiterhin möglich sind und Menschen die Ergebnisse prüfen müssen.

Als risikomindernde Elemente nennt sie die Beschränkung auf eigene Daten, vorgegebene Rollen und Kontexte sowie die gezielte Auswahl von Dokumentabschnitten. Die Qualität der Quellen bleibt dabei eine Grenze: Enthalten die internen Dokumente falsche Informationen, kann die Lösung daraus keine verlässlich richtigen Antworten machen.

Unternehmensspezifische Modelle und selbst gehostete LLMs

Eine Frage aus einer EU-Organisation richtet sich auf Modelle, die mit eigenen Daten trainiert werden. Hintergrund sind Vorbehalte gegenüber Informationen aus dem Vortraining externer Modelle.

Klaffschenkel unterscheidet ein vollständiges LLM von einem kleineren Modell für Semantik und Retrieval, das sie als „Short Language Model“ bezeichnet. Für ein solches unternehmensspezifisches Modell nennt sie ungefähr 50.000 bis 100.000 hochwertige Dokumente, abhängig vom verfügbaren Inhalt. Weniger sei möglich; entscheidend sei guter, beschreibender Text.

Dieses Modell ersetze das LLM nicht. Es unterstütze die Erkennung sprachlicher und dokumentbezogener Zusammenhänge, während für die natürlichsprachliche Antwort weiterhin ein größeres Sprachmodell benötigt werde. Als aktuell mitgeliefertes, selbst hostbares Modell nennt sie Mistral Nemo.

Für den On-Premise-Betrieb führt Klaffschenkel drei Motive an:

  • Daten sollen innerhalb der eigenen Umgebung bleiben.
  • Eine organisatorische No-Cloud-Strategie soll eingehalten werden.
  • Anfrageabhängige Kosten externer Anbieter sollen vermieden werden.

Sie berichtet, dass Transaktionspreise im vergangenen Jahr gesunken seien, größere verarbeitete Textmengen die Kosten aber wieder erhöhen könnten. Ihre Kostenargumentation bezieht sich auf diese anfrageabhängigen Gebühren; konkrete Hardwarekosten oder ein vollständiger Betriebskostenvergleich werden nicht vorgestellt. Zugleich beschreibt sie den Modellmarkt als schnelllebig und damit als Herausforderung für die Auswahl.

Daten nicht pauschal bereinigen – Sicherheitsprobleme dennoch prüfen

Die Aussage, Unternehmen müssten ihre Daten vorab nicht aufräumen, löst deutlichen Widerspruch aus. Ein Teilnehmer warnt vor privaten personenbezogenen Daten in Laufwerken und unzureichenden Berechtigungen. KI könne vorhandene organisatorische Probleme sichtbarer machen, statt sie zu lösen.

Klaffschenkel präzisiert ihre Aussage: Gemeint sei, dass nicht sämtliche Dubletten, älteren Versionen oder vermeintlich irrelevanten Inhalte entfernt werden müssten. Metadaten, Versionsinformationen, Klassifizierung und projektspezifische Regeln könnten helfen, passende Inhalte auszuwählen. Auch die Bevorzugung neuerer Versionen müsse im Projekt festgelegt werden.

Ein korrektes Rollen- und Berechtigungskonzept bleibe dagegen notwendig. Als Beispiel schildert sie einen Kundenfall, in dem über Jahre vergebene Vertretungsrechte dazu geführt hätten, dass viele Beschäftigte auf Vorstandsverträge und Gehaltsinformationen zugreifen konnten. Nach dem Start der klassischen Suche sei diese Schwachstelle rasch sichtbar geworden.

Ein weiterer Publikumsbeitrag berichtet von einer Copilot-Pilotierung und unerwartet weitreichenden Ordnerfreigaben. Daraus ergibt sich die Forderung, solche Fallstricke vor einem umfassenden Rollout kennenzulernen. Klaffschenkel stimmt der Bedeutung dieser Vorarbeit zu.

Konsequenzen für Einführung und Nutzung

Die Diskussion mündet in mehrere ausdrücklich angesprochene Anforderungen:

  • Rollen und Berechtigungen müssen vor der Einführung geprüft und verlässlich eingerichtet sein.
  • Datenquellen und Relevanzranking müssen zum jeweiligen Anwendungsfall passen.
  • Aktualisierung, Versionsauswahl und Metadatenbehandlung sind Teil der Projektarbeit.
  • LLM-Antworten müssen trotz risikomindernder Maßnahmen kritisch hinterfragt werden.
  • Pilotierungen können helfen, unerwartete Freigaben und Zugriffslücken vor einem breiten Rollout zu erkennen.

Klaffschenkel betont abschließend, dass die Chat-Oberfläche nur einen Teil der Lösung bildet. Die eigentliche Grundlage ist die kontrollierte Erschließung des Unternehmenswissens. Dabei müsse auch geklärt werden, wie umfassend die Quellenabdeckung sein soll: Neben der Microsoft-Welt nennt sie SAP, CRM-, PLM- und E-Akten-Systeme als relevante Umgebungen. Ein bequem bedienbarer Chat allein löst diese Integrations- und Organisationsaufgaben nicht.

Cookies helfen uns bei der Bereitstellung von GfWM Wiki. Durch die Nutzung von GfWM Wiki erklärst du dich damit einverstanden, dass wir Cookies speichern.