Entwicklung eines generativen KI-Produkts: Was Sie zunächst wissen sollten

Einleitung

Generative KI lässt sich leicht ausprobieren, ist aber deutlich schwieriger in ein Produkt umzusetzen, auf das sich die Menschen verlassen können. Ein Team kann innerhalb weniger Tage ein Sprachmodell mit einer Chat-Oberfläche verknüpfen. Diese Oberfläche jedoch so zu gestalten, dass sie echte Kundenanfragen bearbeitet, Zugriffsberechtigungen beachtet, mit Unternehmensdaten arbeitet und sich von falschen Antworten erholt, ist eine ganz andere Sache.

Für Unternehmen, die generative KI für geschäftliche Anwendungen in Betracht ziehen, ist die erste Entscheidung nicht, welches Modell verwendet werden soll. Es geht vielmehr darum, ob das Problem überhaupt ein neues Produkt erfordert. Standard-KI-Tools decken möglicherweise den Großteil des Bedarfs ab, während eine maßgeschneiderte Implementierung sinnvoller ist, wenn bestehende Software den erforderlichen Workflow nicht unterstützen kann. Unternehmen, die Letzteres in Betracht ziehen, können sich an die Generative-KI-Ingenieure von SysGears wenden, um die technischen Anforderungen eines Produkts zu erörtern, das auf ihren speziellen Anwendungsfall zugeschnitten ist.

Ein generatives KI-Produkt umfasst weit mehr, als nur ein Modell hinter eine mit dem Firmenlogo versehene Benutzeroberfläche zu setzen. Das Modell mag zwar die Sprache verarbeiten, doch der Rest der Anwendung bestimmt, auf welche Informationen es zurückgreifen kann, ob es mit anderer Software interagieren kann und was passiert, wenn seine Antwort daneben liegt. Diese Entscheidungen beeinflussen die Nützlichkeit des Produkts ebenso stark wie die Wahl des Modells selbst.

Ein interner Assistent kann Mitarbeiter in die Irre führen, wenn er ein veraltetes Richtliniendokument abruft. Gewährt man ihm Zugriff auf Kundendaten, werden Zugriffsberechtigungen genauso wichtig wie die Qualität der Antworten. Kann die Anwendung zudem Datensätze ändern, könnte eine überzeugende, aber falsche Antwort echten Schaden anrichten.

Das sind keine Details, die man nach der Markteinführung noch nachbessern kann. Sie beeinflussen die Architektur, den technischen Aufwand und die Kosten für die KI-Entwicklung – einschließlich dessen, was nötig ist, um das Produkt am Laufen zu halten. Ein Unternehmen sollte diese Aspekte gründlich durchdenken, bevor es sich zur Entwicklung verpflichtet – solange noch Spielraum besteht, den Umfang einzugrenzen oder zu entscheiden, dass ein bestehendes Tool die Aufgabe erfüllen könnte.

Beginnen Sie mit einem Problem, das generative KI erfordert

Eine überzeugende Demo kann ein eigentlich recht gewöhnliches Geschäftsproblem verschleiern. Wenn Mitarbeiter beispielsweise zu viel Zeit mit der Suche in internen Dokumenten verbringen, reicht möglicherweise ein semantisches Suchsystem aus. Müssen sie hingegen lange Dokumente interpretieren, spezifische Details extrahieren und Antworten unter Verwendung von Informationen aus mehreren Quellen entwerfen, kann ein Sprachmodell einen wesentlich größeren Mehrwert bieten.

Diese Unterscheidung ist von Anfang an entscheidend. Generative KI macht sich dann bezahlt, wenn Software unübersichtliches, unstrukturiertes Material auswerten oder etwas entwerfen muss, das vom Kontext abhängt. Für eine Aufgabe, die festen Regeln unterliegt, ist ein gewöhnliches Skript jedoch oft kostengünstiger und zuverlässiger.

Nehmen wir einen Händler, der einen stetigen Strom von Produktanfragen bewältigen muss. Kunden beschreiben denselben Artikel auf unterschiedlichste Weise, sodass eine generative KI-Anwendung ihre Anfragen verstehen, die relevanten Spezifikationen abrufen und eine Antwort entwerfen könnte. Bei den Lagerbeständen sieht es anders aus. Diese müssen aus aktuellen Bestandsaufzeichnungen stammen, während ein angebotener Preis den Preisregeln des Unternehmens entsprechen muss – und nicht irgendeiner Zahl, die das Modell zufällig generiert.

Diese Arbeitsteilung sollte klar beibehalten werden: Das Modell soll sich um die Sprache kümmern, während vorhersehbare Abläufe nach Möglichkeit der herkömmlichen Software überlassen werden.

Bevor mit der Entwicklung begonnen wird, sollte genau festgelegt werden, was tatsächlich verbessert werden soll. Vielleicht benötigen Vertriebsmitarbeiter weniger Zeit, um ein Angebot zu erstellen; vielleicht erhalten Kunden eine Antwort, ohne auf einen Support-Mitarbeiter warten zu müssen. In jedem Fall sollte dokumentiert werden, wie der Prozess derzeit abläuft. Andernfalls könnte es passieren, dass ein Team die Einführung seiner neuen KI-Schnittstelle feiert, ohne zu wissen, ob sie die Arbeit tatsächlich erleichtert hat.

Selbst entwickeln oder kaufen: Wie viel Kontrolle benötigen Sie tatsächlich?

Die Entscheidung „Selbst entwickeln oder kaufen“ wird oft als Wahl zwischen vollständiger Eigenverantwortung und Bequemlichkeit dargestellt. In der Praxis gibt es jedoch mehrere Optionen dazwischen.

Standard-KI-Tools sind ein sinnvoller Ausgangspunkt, wenn ein Unternehmen vertraute Funktionen wie Schreibunterstützung, Besprechungsprotokolle, Dokumentenanalyse oder allgemeine Recherche benötigt. Diese Produkte erfordern in der Regel weniger Entwicklungsaufwand, und ihre Anbieter kümmern sich um einen Großteil der zugrunde liegenden Infrastruktur. Ein Unternehmen kann testen, ob Mitarbeiter eine Funktion nützlich finden, ohne zunächst ein eigenes Entwicklungsprojekt finanzieren zu müssen.

Probleme treten auf, wenn ein generisches Tool in einen Prozess integriert werden soll, für den es nicht konzipiert wurde. Es kann beispielsweise nicht mit einer Altsystem-Datenbank kommunizieren oder die richtigen Zugriffsberechtigungen anwenden, wenn Mitarbeiter unterschiedliche Rollen haben. Möglicherweise muss die Ausgabe zudem angepasst werden, bevor ein anderes Geschäftssystem sie nutzen kann. APIs und Konfigurationsoptionen können helfen, diese Lücken zu schließen, decken jedoch nicht unbedingt die Besonderheiten eines etablierten Arbeitsablaufs ab.

Ein maßgeschneidertes KI-Produkt ist dann besonders sinnvoll, wenn der Arbeitsablauf selbst einen Wettbewerbsvorteil darstellt, wenn bestehende Produkte eine wesentliche Anforderung nicht erfüllen können oder wenn die Anwendung eine enge Integration mit firmeneigenen Daten und internen Systemen erfordert.

Eine dritte Option besteht darin, eine eigene Anwendung rund um ein Modell zu entwickeln, das von einem externen Anbieter gehostet wird. Das Unternehmen entwickelt die Schnittstelle und die dahinterstehende Logik, bindet das System in seine bestehende Software ein und richtet eigene Verfahren zum Testen der Ergebnisse ein. Der Zugriff auf das Modell selbst erfolgt über eine API, sodass kein Grundmodell von Grund auf neu trainiert werden muss. Dies gibt dem Unternehmen Spielraum, das Produkt an seinen Arbeitsablauf anzupassen, auch wenn es weiterhin von der Preisgestaltung des Anbieters, der Modellverfügbarkeit und den Servicebeschränkungen abhängt.

Dieser letzte Unterschied verdient besondere Beachtung. Die Entwicklung einer maßgeschneiderten KI-Anwendung und die Entwicklung eines neuen KI-Modells sind unterschiedliche Vorhaben. Das Trainieren eines Basismodells erfordert erhebliche Rechenressourcen, spezialisiertes Fachwissen, geeignete Daten und kontinuierliche Experimente. Die meisten Unternehmen müssen diese Belastung nicht auf sich nehmen. Ein bestehendes Modell, ergänzt durch den Abruf aus Unternehmensdokumenten oder einen sorgfältig konzipierten Tool-Zugriff, kann ausreichend sein.

Wählen Sie die Architektur entsprechend den Arbeitsabläufen

Sobald der Business Case klar ist, besteht die nächste Herausforderung darin, zu entscheiden, wie die Anwendung funktionieren soll. Das Modell ist nur eine Komponente, und es ist möglicherweise nicht die Komponente, die den größten Teil der Entwicklungszeit in Anspruch nimmt.

Für einen Dokumentenassistenten ist „Retrieval-Augmented Generation“ (RAG) oft eine Überlegung wert. Anstatt sich ausschließlich auf das zu verlassen, was ein Modell während des Trainings gelernt hat, ruft die Anwendung relevante Passagen aus einer genehmigten Informationsquelle ab und bindet sie in die Eingabeaufforderung ein. Das Modell formuliert dann anhand dieses Materials eine Antwort.

Antworten, die auf internen Richtlinien oder aktuellen Produktinformationen basieren, können relevanter sein – vorausgesetzt, die Suche funktioniert wie vorgesehen. Das ist jedoch nicht selbstverständlich. Die Suche könnte ein veraltetes Dokument anzeigen, einen entscheidenden Vorbehalt übersehen oder dem Modell einen Textabschnitt liefern, den es anschließend falsch interpretiert.

Die Dokumentenabfrage muss für sich genommen getestet werden. Wie Dokumente in Abschnitte unterteilt werden, kann beeinflussen, was das System findet, und selbst ein gutes Suchergebnis ist nutzlos, wenn es aus einer Quelle stammt, die der Nutzer nicht sehen darf. Die Zugriffsrechte eines Mitarbeiters müssen sich auf den Abfrageprozess erstrecken und dürfen nicht außer Kraft gesetzt werden, nur weil eine Suche zufällig auf eingeschränktes Material gestoßen ist. Die Anwendung selbst muss die Autorisierung durchsetzen. Man sollte sich nicht darauf verlassen, dass ein Modell diese Entscheidung trifft.

Die Feinabstimmung dient einem anderen Zweck. Sie kann dabei helfen, das Verhalten eines Modells, das Antwortformat oder den Umgang mit wiederkehrenden Aufgabenmustern anzupassen, wenn geeignete Trainingsbeispiele verfügbar sind. Sie ist kein direkter Ersatz für die Informationsgewinnung, wenn das Hauptproblem der Zugriff auf sich ändernde Fakten ist. Ein Modell, das auf den Produktkatalog des letzten Jahres feinabgestimmt wurde, weiß nicht automatisch, was sich heute Morgen geändert hat.

Eine Eingabeaufforderung und eine Modell-API könnten alles sein, was eine Anwendung mit eng begrenztem Anwendungsbereich benötigt – zumindest zu Beginn. Das hängt davon ab, wie vorhersehbar die Eingaben sind und was das System mit seiner Ausgabe tun soll. Wenn jede Antwort anhand einer umfangreichen internen Dokumentation überprüft werden muss, kann ein Abruf erforderlich werden; bei einer einfacheren Aufgabe könnte dies lediglich zusätzlichen Aufwand bedeuten.

Halten Sie die erste Version schlank und testen Sie sie mit echten Anfragen, nicht nur mit aufpolierten Demo-Eingaben. Beobachten Sie, wie sie mit einer vagen Frage oder fehlenden Informationen umgeht. Wenn sie lieber blufft, anstatt eine Lücke zuzugeben, sollten Sie das beheben, bevor Sie weitere Komponenten hinzufügen.