00:00:00 Einführung in das Interview
00:01:00 Rinats Lokad-Reise und supply chain Herausforderungen
00:03:59 Lokads Entwicklung und Simulations-Einblicke
00:07:07 Simulationskomplexitäten und agentenbasierte Entscheidungen
00:09:15 Einführung von LLMs und Simulationsoptimierungen
00:11:18 ChatGPTs Einfluss und Modellkategorien
00:14:14 LLMs als kognitive Werkzeuge in Unternehmen
00:17:10 LLMs zur Verbesserung der Kundeninteraktionen und Listings
00:20:30 Die begrenzte Rolle von LLMs bei supply chain Berechnungen
00:23:07 LLMs verbessern die Kommunikation in supply chains
00:27:49 ChatGPTs Rolle in der Datenanalyse und bei Erkenntnissen
00:32:39 LLMs’ Textverarbeitung und Herausforderungen bei quantitativen Daten
00:38:37 Optimierung der Enterprise-Suche und abschließende KI-Erkenntnisse
Zusammenfassung
In einem kürzlichen Dialog sprach Conor Doherty von Lokad mit Joannes Vermorel und Rinat Abdullin über den Einfluss generativer KI auf supply chains. Vermorel, Lokad’s CEO, und Abdullin, ein technischer Berater, diskutierten die Entwicklung von time series Vorhersagen zur Nutzung großer Sprachmodelle (LLMs) wie ChatGPT. Sie untersuchten das Potenzial von LLMs, Aufgaben zu automatisieren, die Produktivität zu steigern und bei data analysis zu unterstützen, ohne Arbeitsplätze zu ersetzen. Während Vermorel in der Planung vorsichtig mit LLMs umging, erkannten beide deren Nutzen bei der Erstellung von Lösungen an. Das Interview unterstrich die transformative Rolle der KI im supply chain management und die Bedeutung, LLMs mit spezialisierten Tools zu integrieren.
Erweiterte Zusammenfassung
In einem kürzlichen Interview führte Conor Doherty, der Leiter der Kommunikation bei Lokad, eine anregende Diskussion mit Joannes Vermorel, dem CEO und Gründer von Lokad, und Rinat Abdullin, einem technischen Berater bei Trustbit und ehemaligen CTO von Lokad. Das Gespräch drehte sich um das aufstrebende Feld der generativen KI und ihre Auswirkungen auf supply chain management.
Rinat Abdullin, der auf seine Zeit bei Lokad zurückblickte, erinnerte an die frühen Herausforderungen, denen sich das Unternehmen gegenübersah, insbesondere bei der Angleichung von Technologie an Kundenbedürfnisse und der Vermittlung komplexer supply chain Daten auf eine verständliche und vertrauenswürdige Weise. Joannes Vermorel bestätigte, dass Lokads Wurzeln im time series forecasting lagen, einem kritischen Element der supply chain Optimierung.
Im Verlauf des Dialogs ging Abdullin auf die Entwicklung der Lokad-Technologie ein und hob die Spannung zwischen der Erklärbarkeit und der Leistung von machine learning Modellen hervor. Er teilte seine Erfahrungen mit der Nutzung von Simulationen, um komplexe Systeme zu entmystifizieren, was den Weg für optimierte Rechenmethoden ebnete.
Das Gespräch wandte sich dann großen Sprachmodellen (LLMs) zu, wobei Vermorel ihren jüngsten Popularitätsschub bemerkte. Abdullin teilte seine frühen Erfahrungen mit Sprachmodellen und deren Entwicklung zu benutzerfreundlichen Tools wie ChatGPT. Er betonte das transformative Potenzial von LLMs und verglich sie mit einer persönlichen Abteilung von Assistenten, die in der Lage ist, eine Vielzahl von Aufgaben zu erfüllen, von der Erstellung von Dokumenten bis hin zur Automatisierung der Suche nach Informationen in großen Daten silos.
Abdullin sprach Bedenken an, dass LLMs Arbeitsplätze ersetzen könnten, und stellte fest, dass sie die Effizienz der Mitarbeiter steigern, anstatt sie zu ersetzen. Er nannte Beispiele, bei denen die Produktivität um das Zehn- bis Hundertfache gesteigert wurde. Er bemerkte außerdem, dass supply chains LLMs nur zögerlich angenommen haben, während Marketingabteilungen sie schnell für Kundeninteraktionen und Kostensenkungen genutzt haben.
Joannes Vermorel erläuterte das Potenzial von LLMs zur Automatisierung offener Kommunikation mit supply chain Partnern, zur Zeitersparnis bei routinemäßigen E-Mails und zur Fokussierung auf komplexere Aufgaben. Er lobte LLMs für ihre sprachliche Finesse bei der Anpassung des Tons in der Kommunikation, eine Aufgabe, die für Menschen zeitaufwändig sein kann.
Abdullin hob ChatGPTs fortschrittliche Fähigkeiten in der Datenanalyse hervor, die es Geschäftsführern ermöglichen, komplexe Daten ohne Programmierkenntnisse zu analysieren. Allerdings blieb Joannes Vermorel skeptisch gegenüber generativer KI in der supply chain Planung und betonte, dass LLMs eher dafür geeignet sind, einmalige Analysen und Berichte zu erstellen.
Rinat Abdullin schlug vor, LLMs in Verbindung mit spezialisierten Tools für bessere Ergebnisse einzusetzen, insbesondere an der Schnittstelle zwischen numerischen, textuellen und Code-Domänen. Joannes Vermorel stimmte zu und erklärte, dass LLMs eher dazu geeignet sind, Programme zur Problemlösung zu erstellen, als diese direkt zu lösen.
Abschließend forderte Rinat Abdullin Unternehmen auf, LLMs zu nutzen, da sie in Kombination mit spezialisierten Tools einen erheblichen Mehrwert bieten können. Conor Doherty beendete das Interview, indem er Joannes und Rinat für ihre Einblicke in das dynamische Feld der generativen KI und ihre Rolle bei der Gestaltung der Zukunft des supply chain management dankte.
Vollständiges Transkript
Conor Doherty: Willkommen zurück bei Lokad TV. Die Fortschritte in generativer KI in den letzten 12 Monaten sind eine außergewöhnliche Demonstration technologischen Fortschritts. LLMs, oder große Sprachmodelle, haben sich innerhalb eines Jahres von einer Nische zum Mainstream entwickelt. Hier, um die Bedeutung zu erklären, insbesondere im supply chain Kontext, ist Lokads allererster CTO, Rinat Abdullin. Rinat, willkommen bei Lokad.
Rinat Abdullin: Es ist mir eine Freude und eine Ehre, wieder zurück zu sein. Ich war bei Lokad, als es gerade in einem kleinen, winzigen Raum, glaube ich, an der Universität begann. Und von all den Unternehmen, mit denen ich seitdem gearbeitet habe, darunter sieben Startups, war Lokad der herausforderndste und lohnendste Ort in meinem Leben.
Conor Doherty: Du musst nichts Direktes über Joannes sagen, aber wenn du sagst, es sei das Herausforderndste gewesen, was genau machte Lokad so herausfordernd? Und im Gegensatz dazu, welche Schwierigkeiten erwarten zukünftige Projekte?
Rinat Abdullin: Wir waren damals ein Startup, und es war eine interessante Kombination, zu versuchen, eine Übereinstimmung zwischen den Technologien und dem, was der Kunde wollte und tatsächlich benötigte, zu finden. Dieses Dreieck auszubalancieren, war immer eine Herausforderung, weil die Technologien damals noch in den Kinderschuhen steckten. Wir waren einer der ersten großen Azure-Kunden und bauten gerade eine skalierte Bibliothek zum Verarbeiten zahlreicher time series von Kunden auf. Es gab keinen Support; alles musste von Grund auf neu entwickelt werden, und diese Reise dauerte viele Jahre. Sie setzte sich mit der Erstellung einer maßgeschneiderten DSL fort, um Experten bei Lokad zu befähigen, und läuft noch immer. Das ist ein Teil des Dreiecks. Der zweite Teil bestand darin, dass Kunden bessere Zahlen wollen; sie möchten, dass ihr Geschäft auf eine vorhersehbare Weise läuft, ohne eingefrorenes Geld im Inventar. Gleichzeitig sollen diese Zahlen verständlich sein, denn wenn man den Kunden Zahlen präsentiert, die aus einer magischen Blackbox kommen, könnten die Führungskräfte sagen: „Ja, es funktioniert“, aber die supply chain Experten in den lokalen warehouses würden sagen: „Ich verstehe diese Zahlen nicht. Ich traue den Formeln nicht, und mein Bauchgefühl, gestützt auf 10-20 Jahre Erfahrung, sagt mir, dass es nicht funktionieren wird, also werde ich es ignorieren.“ Und man kann offensichtlich nicht alle entlassen.
Joannes Vermorel: Wenn ich Rinat zuhöre, arbeiteten wir früher mit time series, stimmt das?
Rinat Abdullin: Ja, Lokad wurde buchstäblich als time series forecasting Service gegründet, also kenne ich mich ein wenig mit time series aus, auch wenn wir diesen Weg Jahre später verließen. Wir arbeiteten mit time series, und sie sind ein sehr grundlegender Baustein. Die von mir erwähnte Spannung bezüglich der Erklärbarkeit wurde zwar schließlich angegangen, allerdings mehr als ein Jahrzehnt nachdem Lokad gegründet wurde. Wir mussten differentiable programming annehmen, damit wir schließlich Modelle hatten, die machine learning waren, aber erklärbar. Es kam sehr spät. Jahrelang hatten wir die Wahl zwischen crude Modellen, die White-Box-Charakter hatten, aber nicht sehr gut waren, oder machine learning Modellen, die besser, aber Black-Boxen waren und eine Menge betrieblicher Probleme verursachten. Manchmal waren sie in keiner Hinsicht natürlicherweise besser in allen Dimensionen des Problems. Das war ein enormer Kampf, und die Lokad-Reise war fast ein Jahrzehnt steiniger Aufstiege. Ich absolvierte die ersten fünf Jahre dieser Aufstiege, und dann gab es andere, die weiter für die restlichen kämpften. Es war eine sehr lange Reihe massiver Probleme, die angegangen werden mussten.
Conor Doherty: Danke, Rinat. Wenn wir erklären wollen, was Lokad macht, geschieht dies durch eine Reihe sehr langer Artikel, Vorträge und Diskussionen wie diese. Aber wenn man in diesem Kontext machine learning als White-Box darstellen möchte, wie gehst du das an?
Rinat Abdullin: Einer der Ansätze, der ziemlich gut funktionierte, als ich half, einen Hackathon für ein internationales Logistikunternehmen zu erstellen, war über Simulationen. Wenn man von internationaler Logistik spricht, spielen viele Variablen eine Rolle. Man hat Fracht, die zwischen mehreren Standorten mit verschiedenen Transportmitteln befördert werden muss. Es gibt Transportunternehmen und verschiedene andere Firmen, die auf dem freien Markt um Frachtlieferungen von Standort A zu Standort B konkurrieren. Dann gibt es noch die tatsächlichen Lieferwege wie Straßen, Schienennetze, vielleicht auch die letzte Meile irgendwo. Wenn Lastwagen Fracht zwischen diesen Standorten transportieren, kommt es zu Verzögerungen, Staus, und die Fracht könnte außerhalb der Arbeitszeiten in einem Lager eintreffen oder der Entladebereich des Lagers könnte überfüllt sein.
Wir wollten all diese Komplexität auf eine Weise modellieren, die für Studenten oder Neueinsteiger im Unternehmen zugänglich ist. Was wir getan haben, war ziemlich brutal. Es ist vielleicht sehr ähnlich dazu, wie antike Forscher versuchten, die Zahl pi zu modellieren, indem sie eine Münze in einer Simulation warfen. Also bauten wir eine virtuelle Karte von Europa mit Hauptstraßen, und in dieser virtuellen Karte hatten die Straßen Längen, die Zeit verging, Lastwagen fuhren hin und her, und Transportunternehmen konnten entscheiden, welche Fracht sie abholen und ob sie pünktlich geliefert wird. Das war der Einstiegspunkt für die Hackathon-Teilnehmer, da sie Agenten programmieren konnten, die Entscheidungen trafen wie: “Ich bin Lastwagenfahrer A, und ich werde diese Fracht von Standort A zu Standort B abholen.” Aber es gab einen Trick: Wenn ein Lastwagen Fracht von einem Standort zu einem anderen transportiert, kostet das, wie in der realen Welt, Geld. Um Geld zu verdienen, muss man Steuern zahlen, für Treibstoff bezahlen und sicherstellen, dass der Fahrer sich ausruht.
Da es sich um eine Simulation handelt, benötigt man keine komplexen Formeln; man setzt die Realität gewissermaßen brute-force um. Man führt sie einfach wie ein Batch-Skript für NPCs oder ein Spiel sequentiell aus, und man kann viele erklärbare Regeln auf einem Blatt Papier festhalten. Diese gesamte Welt war für die Menschen so nachvollziehbar, dass wir tatsächlich zwei Schwierigkeitsgrade entwickelten. Im ersten Level fuhren die Unternehmen einfach Lastwagen, um möglichst viel Geld zu verdienen. Im zweiten Level stiegen die Benzinpreise etwas, die Unternehmen mussten die CO2-Emissionen ausgleichen, und Lastwagenfahrer konnten müde werden. Wenn der Lastwagenfahrer länger als 12 oder 14 Stunden unterwegs war, nahm die Unfallgefahr zu. Bei einem Unfall geht der Lastwagenfahrer in die Ruhephase, und die Maschine tut im Wesentlichen nichts, was im Grunde Zeitverschwendung ist. Wir bauten diese Umgebung auf, die Teilnehmer konnten ihre Agenten codieren, und wenn man eine ereignisdiskrete Simulation in beschleunigtem Tempo ausführt, vergehen im Wesentlichen Monate virtueller Zeit in Sekunden realer Zeit.
Wir konnten schnell viele Simulationen starten und sagen: “Hey Teams, die Entscheidungen, die eure Agenten in dieser virtuellen Welt getroffen haben, dies war die lead time Verteilung, dies war die Preisverteilung, dies waren die Margen, dies war die Anzahl der Unfälle, die eure Agenten hatten.” Das ist im Wesentlichen der Ansatz, den ich normalerweise verfolge, wenn ich eine komplexe Umgebung zu erklären versuche. Man beginnt zuerst mit der Simulation, weil sie spielartig ist, es ist einfach, die Regeln zu erklären, und man muss keine differentiable programming einsetzen. Aber wenn man diese Simulation ausführt, handelt es sich im Grunde um eine Monte-Carlo-Analyse, die die Abhängigkeiten in komplexen Systemen verfolgt. Das bedeutet, dass man zum Beispiel in einigen Fällen keine einfache Verteilung außen erhält, sondern aufgrund von Wechselwirkungen zwischen mehreren Elementen des Systems Interferenzmuster in den äußeren Verteilungen entstehen. Es sieht aus wie eine Blackbox, aber die Menschen können die Regeln verstehen, sie können die Spielregeln ändern, und dann, wenn ein Unternehmen schließlich versteht, wie diese Umgebung funktioniert und es mit den in einer langsamen Art hervortretenden Zahlen zufrieden ist, weil Simulationen immer noch Zeit benötigen, gibt es eine Möglichkeit, die Berechnungen zu optimieren, indem man sagt: “Okay, dies sind die Zahlen, die wir aus der Simulation erhalten, und wechseln jetzt direkt zu differentiable programming mit den Wahrscheinlichkeiten, um die gleichen Zahlen, aber auf schnellere Weise zu erhalten.” Es ist einfach eine Performance-Optimierung. So würde ich das normalerweise angehen.
Joannes Vermorel: Was sehr interessant ist, dass im vergangenen Jahr eine neue Klasse von Tools, LLMs, verfügbar geworden ist – und das ist besonders spannend, weil es buchstäblich eine ganze Klasse von Technologien ist, die es schon seit etwa einem halben Jahrzehnt gibt, die aber sehr nischenspezifisch waren und deren Potenzial nur von Experten wirklich begriffen werden konnte, da es damals vor allem um das Potenzial ging. Vielleicht, Rinat, wie siehst du den Wandel, der durch die Einführung dieser Klasse von LLM-Tools bewirkt wird? Wie vergleichst du das? Wir hatten unterschiedliche Klassen von Tools fürs maschinelle Lernen in Unternehmen, wie Klassifikation, Regression, Monte-Carlo-Simulationen. Es waren Klassen von Tools, die man kombinieren konnte – und jetzt haben wir eine ganz andere Klasse von Tools, nämlich LLMs. Für das Publikum, das mit LLMs außer ChatGPT vielleicht nicht vertraut ist: Wie fasst man das im Kontext von enterprise software, also in Unternehmens-Workflows? Was ist deine übergeordnete Vision dazu?
Rinat: Ich beschäftige mich schon seit 2015 mit Sprachmodellen, noch bevor der Chatbot herauskam und sie populär machte. Du hast recht, sie waren wirklich nischenspezifisch. Sie wurden in Sprachübersetzern, zur Spracherkennung und in Sprachmodellen eingesetzt, die Rechtschreibfehler korrigieren oder dabei helfen, Texte in großen Korpora zu finden. Als sie dann durch ChatGPT populär wurden, schoss ihre Beliebtheit in die Höhe. Ein Grund dafür ist, dass sie darauf trainiert wurden, hilfreich und folgsam gegenüber Menschen zu sein.
Und genau deshalb sind sie manchmal so nervig, denn wenn man Ergebnisse vom Modell erhalten möchte und es anfängt, sich zu entschuldigen – indem es immer wieder sagt “Es tut mir leid” – kann das frustrierend sein. In meinem Denken teile ich Modelle im Großen und Ganzen in zwei Kategorien auf. Eine Kategorie von Modellen arbeitet hauptsächlich mit Zahlen – also sprechen wir von Regressionen, Monte-Carlo-Simulationen, neuronalen Netzen. Die andere Kategorie, die der der großen Sprachmodelle, arbeitet zwar auch mit Zahlen, jedoch auf der Oberfläche mit Text, mit großem unstrukturiertem Text, und genau darin liegt ihr zentraler Nutzen.
Diese Modelle erlauben es, eine Maschine oder Automatisierung direkt in menschliche Interaktionen einzubinden. Zum Beispiel muss man bei Regressionen oder Zeitreihen das Modell irgendwo in die digitalen Geschäftsprozesse integrieren – es gibt auf der einen Seite eine Datenbank, in der Mitte eine Prognose-Engine und vielleicht auf der anderen Seite eine Datenbank, ein CRM oder ERP. Im besten Fall erhält man einen Bericht, es bleiben aber Zahlen. Mit LLMs fügt man sie direkt in den Kern des Geschäftsprozesses, in den Mittelpunkt menschlicher Workflows ein. Dies eröffnet so viele Möglichkeiten, vor allem, weil man etwas umsetzen kann, das vor einem Jahrzehnt völlig unmöglich oder extrem teuer gewesen wäre, ohne großen Aufwand. Zum Beispiel habe ich persönlich, wenn ich mit LLMs arbeite, schon jetzt das Gefühl, meine eigene private Abteilung von Assistenten zu besitzen. Sie sind polyglott, sie beherrschen den gesamten Stack, sind vielleicht manchmal naiv, aber auch intelligent und werden sich niemals beklagen. Wenn man sie beispielsweise bittet, einen Button in einem Layout zu verschieben oder einen Brief an einen Richter in Deutschland neu zu formulieren – sie sind äußerst hilfreich, folgsam, manchmal etwas dumm, aber sie können Großartiges leisten. In unternehmerischen Anwendungsfällen von LLMs, die ich gesehen habe, geschieht dies meist im Rahmen dessen, was sie als Business Digitalization bezeichnen. Es hilft Unternehmen, Workflows zu automatisieren, die sich ums Auffinden von Text in umfangreichen Korpora drehen. Ein Unternehmen hat beispielsweise viele Daten, seine Wissensdatenbanken existieren, sind aber im Wesentlichen isolierte Silos. Es könnten RFCs, Fragebögen oder eine Wikipedia sein, die niemand wirklich aktuell hält – und dann muss man Aktivitäten erledigen, bei denen man Informationen an obskuren Stellen finden muss. Das erfordert Zeit, Mühe und vor allem kognitive Energie. Was LLMs leisten können, ist, dass sie vorbereitende Arbeit übernehmen. Sie können Artikel entwerfen, Recherchen zu den unternehmensinternen Daten durchführen und sagen: “Okay, du stellst diese Antwort für das Unternehmen zusammen, basierend auf deinen Unternehmens-Workflows und den codierten Vorgaben – hier ist mein Entwurf.” Für jeden Punkt dieser Antwort-Checkliste können sie aufzeigen, woher sie die Information haben. So muss die Person nicht mehr die Routinetätigkeiten erledigen und kann sich der intellektuell anspruchsvolleren Aufgabe widmen, zu überprüfen, ob das Modell etwas richtig erfasst hat. Das ermöglicht eine massive Effizienzsteigerung im Unternehmen. Als ChatGPT erschien, hatten viele Menschen wirklich Angst, dass LLMs und KI ihre Jobs übernehmen würden – aber das tun sie nicht. Glaub mir, ich unterstütze Kunden schon seit geraumer Zeit dabei, Produkte zu entwickeln, die von LLMs und ML angetrieben werden, und es erfordert enormen Aufwand, etwas zu schaffen, das einen Menschen ersetzen kann. Das ist nahezu unmöglich. Aber was LLMs tun können, ist, die bestehenden Mitarbeiter um ein Vielfaches – manchmal sogar 10- bis 100-mal – effizienter zu machen. Das sind Ausnahmen. Sie machen die Menschen einfach effizienter, doch sie können niemals den Menschen ersetzen. Es müssen stets Menschen im Prozess involviert bleiben.
Conor: Wenn ich an diesem Punkt anknüpfen darf – denn der Kontext der Diskussion ist generative KI, LLMs im supply chain Kontext – klingt es, Rinat, nach dem, was du sagst, so, als ob LLMs allgemein Produktivitätssteigerer sein werden. Aber siehst du spezifische Anwendungsfälle innerhalb der supply chain oder ist es lediglich, wie du sagtest, “Ich habe ein Team von Polyglotten, ich muss diese RFP in 10 Sprachen übersetzen”?
Rinat: Nach meiner Erfahrung sind supply chains etwas träge darin, LLMs im Kernprozess zu implementieren. LLMs schleichen sich vielmehr von außen heran. Ein typisches Beispiel ist, dass Marketingabteilungen in der Regel die ersten Anwender sind. Wenn ein Unternehmen – sagen wir, im Kundenkontakt – an der Schnittstelle zwischen dem Unternehmen und den Nutzern, den Kunden, agiert, habe ich die größte Akzeptanz beobachtet. Beispielsweise gibt es Marktplätze, die Produkte an ihre Kunden verkaufen, und sie möchten diese Interaktion angenehmer gestalten und vielleicht die Kosten für den Kundenkontakt senken.
Es ist bereits recht gut möglich, Systeme zu entwickeln, die automatisch die Produktkataloge einzeln durchsuchen – unermüdlich, rund um die Uhr, 24/7 – und feststellen: “Okay, dies ist ein Produkt, aber es wurde vom vendor of the supply chain falsch eingegeben.” Warum? Weil ich das Internet durchforstet habe, die Spezifikationen dieses Produkts gefunden habe, die ähnlich sind, auch die PDF-Beschreibung vom Hersteller habe ich entdeckt – und nach meiner Einschätzung hat etwa die Hälfte des Internets diese Nummer richtig, während du sie falsch hast. Das sind die Referenzen. Bitte entscheide, ob du eine automatische Korrektur vornehmen möchtest. “Oh, lieber Manager, ich habe gesehen, dass du diese Produktbeschreibung bzw. Produkteigenschaft korrigiert hast. Möchtest du, dass ich die Produktbeschreibung neu generiere – mit der aktualisierten Nummer, also nicht nur der Nummer, sondern auch dem Text?” Und währenddessen habe ich drei Produktbeschreibungen erstellt, sodass du diejenige auswählen kannst, die am sinnvollsten ist. Ich habe auch einen SEO-Marketingtext erstellt, die Keywords in deinem Publishing-Engine aktualisiert und zusätzlich einen Twitter- sowie LinkedIn-Beitrag generiert.
Und dann kommt einer der schönsten Aspekte: Du erstellst auch eine LLM-unterstützte, verborgene Beschreibung, die für die semantische Suche verwendet wird. Was bedeutet das? Wenn ein Kunde einer Modeplattform nach einem Kleidungsstück sucht, wird er nicht immer explizit nach beispielsweise einem Boho-Stil-Hemd mit Drachenmotiven in Größe M und unter 10 Dollar suchen. Stattdessen denkt er vielleicht: “Ich gehe heute Abend auf eine Party, und meine Freunde sind da – was kann ich tragen, das zu meinen Shorts passt?” Wenn du Produktbeschreibungen und semantische Erklärungen hast, die von den LLMs aus dem Produkt extrahiert wurden, und du danach suchst – allerdings nicht den kompletten Text, denn wer weiß schon, wie Leute „boho“ schreiben – sondern du nutzt eine embedding-basierte Suche, die im Grunde eine vektorbasierten Suche ist, bei der anhand der Textbedeutung gesucht wird und nicht anhand der exakten Formulierungen, dann erhältst du Ergebnisse, die von außen betrachtet fast magisch wirken, weil das Modell anfängt, Dinge vorzuschlagen, die du eigentlich beabsichtigt hast, und nicht das, was du buchstäblich gesagt hast.
Conor: Danke, Rinat. Joannes, was meinst du dazu? Wenn ich supply chains beobachte, scheint es, als ob sie ziemlich geteilt funktionieren. Etwa die Hälfte der Leute arbeitet mit Tabellenkalkulationen, während der Rest sich mit alltäglicher Kommunikation mit Partnern, Lieferanten, Kunden und so weiter beschäftigt. Bei den Tabellenkalkulationen geht es im Grunde darum, die Mengenentscheidung zu automatisieren – das macht Lokad nun schon seit einem Jahrzehnt. Der zweite Teil war bislang kaum automatisiert, da es vor dem Aufkommen von LLMs keine wirklich plausible technologische Lösung dafür gab.
Joannes Vermorel: Das bedeutet, dass die Dinge, die Kommunikation erfordern – bei einem straffen Workflow lassen sie sich automatisieren, etwa über EDI, um eine Bestellung zu übermitteln. Da hätten wir eine Brücke, die die Bestellung übermittelt, und anschließend ein nicht-textbasiertes Problem. Aber genau das meinen die Leute nicht, wenn sie sagen, dass sie die Hälfte ihrer Zeit mit Tabellenkalkulationen und die andere Hälfte mit der Verwaltung von Partnern, Kunden, Transportunternehmen und Lieferanten verbringen. Es geht mehr darum, “Könntet ihr diese Bestellung beschleunigen – und wenn ja, zu welchem Preis?” Es ist viel unschärfer und offener formuliert.
Man muss diesen Sonderfall erfassen und eine E-Mail dazu schreiben, um im Grunde den Sachverhalt zu klären – was beabsichtigt ist, was auf dem Spiel steht – und das dauert eine halbe Stunde. Dann wiederholst du das mit einer anderen Situation, einem anderen Problem, und schreibst eine weitere E-Mail. Am Ende hast du eine Einkaufsabteilung, in der jeder während eines achtstündigen Arbeitstages vier Stunden mit Tabellenkalkulationen und vier Stunden mit dem Schreiben von 20 E-Mails an 20 Partner verbringt. Hier sehe ich ein enormes Verbesserungspotenzial. Lokad automatisiert buchstäblich bereits den ersten Teil, aber mit LLM gibt es ein enormes Potenzial, den zweiten Teil weitgehend – wenn auch nicht vollständig – zu automatisieren. Im Grunde ermöglicht es, dass Menschen Unterstützung erhalten, um automatisch Kompositionen von Mitteilungen zu erstellen, die dann an die Partner gehen. Das LLM wurde eingesetzt, um eine einigermaßen kontextualisierte Version der Problemstellung und der Erwartungen an den Partner bereitzustellen.
Wenn die Problemstellung klar definierte Grenzen hat, dann hast du EDI – es wird einfach zu einem Bestandteil eines voll mechanisierten Workflows. Aber ich spreche vom Rest, von den Dingen, die nicht ganz passen, wie etwa wenn du 1.000 Einheiten bestellst und 1.050 geliefert werden. Du wirst die Bestellung nicht ablehnen, weil 50 Einheiten zu viel geliefert wurden – du magst diesen Lieferanten, nimmst die Lieferung an, validierst sie, empfängst sie und bezahlst für 1.050 Einheiten statt 1.000. Aber du möchtest deinem Lieferanten auf höfliche Weise vermitteln, dass du es vorziehst, wenn er sich an die ursprüngliche Vereinbarung hält, nämlich 1.000 Einheiten zu liefern und nicht 1.050. Da liegt eine gewisse Nuance darin, dass man den Workflow nicht stören will; es ist quasi korrekt, dennoch will man kommunizieren, dass es nicht in Ordnung ist, immer 5 % mehr zu liefern, nur damit der Lieferant ein wenig mehr berechnen kann.
Genau hierin glänzen LLMs – in dieser Art von weicher Kommunikation, bei der eine Botschaft vermittelt werden muss. Es würde Zeit kosten, die Formulierungen so auszubalancieren, dass sie nicht zu aggressiv sind, aber der Partner dennoch versteht, dass du stark darauf bestehst, dass die ursprünglich vereinbarte Menge strikt eingehalten wird. Es ist die Art von Sache, bei der jemand eine Stunde lang an der E-Mail feilen kann, nur um diesen Teil zu formulieren – und genau hier sind moderne LLMs hervorragend, wenn es darum geht, Texte um einen kleinen Tonfall zu verändern, sei es ein wenig aggressiver, etwas sanfter oder unterstützender.
Es würde dich vielleicht 20 Minuten kosten, eine halbe Seite zu bearbeiten, während ein LLM dies buchstäblich in Sekunden erledigen kann. Genau hier erzielt man einen massiven Produktivitätszuwachs bei diesen feinfühligen Abstimmungen, für die Menschen buchstäblich Stunden investieren. Wenn man das ein wenig hochrechnet: Stell dir ein Unternehmen vor, das tagsüber tausende solcher Kommunikationen zu Randfällen hat. Das ist eine neue Fähigkeit, die LLMs mitbringen. Für Geschäftsinhaber und Stakeholder, um das Gesamtbild zu erfassen, braucht es zwar Aufwand, aber jetzt haben wir LLMs, die hervorragend dafür geeignet sind, riesige Mengen unstrukturierter Texte zu scannen und Muster zu erkennen. Stell dir vor, ein LLM könnte Hunderte von Berichten, E-Mails oder Hin-und-Her-Kommunikationen darüber lesen, dass niemals zusätzlich 5 % versendet werden sollen, und am Ende des Tages eine prägnante Zusammenfassung für die Führungskräfte liefern mit der Aussage: “Hey, es scheint ein wiederkehrendes Muster zu geben, dass immer mehr Lieferanten in der letzten Woche versuchen, uns mehr Lagerbestand zu schicken.”
Wie du weißt, verfügt ChatGPT über eine erstaunliche Fähigkeit namens Advanced Data Analytics – und das ist buchstäblich, als hätte man eine Abteilung von Datenanalysten unter eigener Kontrolle. Sie sind keine supply chain Experten, daher wirst du in diesem Bereich weiterhin Lokad benötigen, aber du kannst ihnen einfache Fragen stellen wie: “Hier ist meine Datenbankdatei, hier ist meine Excel-Datei – führe eine Analyse für mich durch und erkenne die Trends.” Das Erstaunliche daran ist, dass das hauptsächlich online möglich ist. Du kannst es nicht lokal oder über die API ausführen, aber ChatGPT entwickelt Theorien, schreibt Code, führt diesen aus, stößt vielleicht auf Fehler, behebt sie, gibt die Ergebnisse aus und erstellt sogar ein Diagramm für dich. Der gesamte Ablauf – vom Moment, in dem du ihm eine Excel-Tabelle und eine Frage sendest, bis hin zu dem schönen Diagramm – ist vollautomatisiert. Es korrigiert sich selbst, behebt sich selbst, und du erhältst ansprechende Ergebnisse. Das gibt den Geschäftsentscheidungsträgern die Möglichkeit, Daten selbstständig zu analysieren, auch wenn diese in komplexen Systemen gespeichert sind, sie eigenständig zu visualisieren, ohne dass sie Python, JavaScript, C oder SQL kennen müssen. Ich denke, das wirkt wirklich befähigend, eröffnet neue Geschäftsmöglichkeiten und schafft zusätzlichen Geschäftswert.
Conor: Vor etwa sechs Monaten hatten wir eine Diskussion über generative KI und ihre Rolle in der supply chain, und insgesamt waren wir etwas skeptisch. Wenn du hörst, was in den letzten sechs Monaten in Bezug auf die Fortschritte beschrieben wurde, hast du immer noch dieselbe Perspektive oder bist du etwas offener geworden?
Joannes: Meine Haltung bleibt in bestimmten Aspekten tief skeptisch. Mein Skeptizismus war im Wesentlichen eine Reaktion auf die meisten Wettbewerber von Lokad, die sagen: “Wir werden ChatGPT einfach direkt auf Terabytes von Transaktionsdaten anwenden, und es wird funktionieren.” Meiner Meinung nach nein, das glaube ich nicht. Ich bin immer noch sehr skeptisch, denn es ist buchstäblich nicht so. Wenn du sagst, dass du ein paar Tabellen mit Schemata auflisten oder das Tool das Schema der Datenbank automatisch analysieren lassen kannst, um einfache Analysen wie die durchschnittliche Warenkorbgröße zu berechnen, dann ist das ein vollkommen anderes Konzept. Früher musste so etwas über das business intelligence Team laufen. Ich spreche von grundlegenden Dingen wie: Was ist die durchschnittliche Warenkorbgröße, wie lange halten wir Kunden im Durchschnitt, wie viele Einheiten haben wir in Deutschland verkauft – sehr grundlegende Fragen. In großen Unternehmen gibt es normalerweise Dutzende von Mitarbeitern in BI-Abteilungen, die den ganzen Tag disposable Reports erstellen. Für solche Dinge glaube ich, dass LLMs wirklich helfen können, aber das ist absolut nicht das, was unsere Wettbewerber vorschlagen. Sie sagen: “Ihr habt diese Modelle, ihr gebt ihnen eure Terabyte-Datenbank, gewährt ihnen Zugang zu Twitter und Instagram, und ihr erhaltet eure Planung, eure Entscheidungen, alles – und das ist völlig automatisiert.” Ich sage nein, nicht einmal annähernd. Wir befinden uns in der Fantasiewelt.
Rinat: In Bezug auf deine Reaktion auf diese Herausforderung habe ich zwei Gedanken, die ich teilen möchte. Erstens: Zum Prozess, LLMs zur Verarbeitung großer Datenmengen zu nutzen – ich arbeite schon seit einiger Zeit mit verschiedenen LLMs. Eine der ersten Fragen, die Kunden in der Regel stellen, ist, ob sie etwas wie ChatGPT lokal auf ihren Räumlichkeiten ausführen können. Um das zu beantworten, muss man die LLMs in verschiedenen Konfigurationen benchmarken und die Kosten ermitteln. LLMs sind ziemlich teuer. Um einen Megabyte Text durch die LLMs zur Vorhersage zu schicken, könnte es je nach Modell ein paar Euro kosten. Wenn du es lokal mit den besten verfügbaren Modellen betreiben möchtest, könnte es dich 10 € oder vielleicht 20 € kosten.
Und genau das macht GPT-3.5; es ist sehr günstig. Aber der Punkt ist: Es ist nicht einmal möglich, Terabytes oder Petabytes an Daten durch die LLMs zu leiten. Zweitens: LLMs sind schrecklich im Umgang mit Zahlen. Wenn jemand ein LLM auffordert, mathematische Berechnungen durchzuführen oder Primzahlen aufzulisten, ist das ein Missbrauch. LLMs sind linguistische Modelle; sie verfügen über ein großes Wissensspektrum und sind sehr intelligent, obwohl sie immer noch Einschränkungen haben. Du fragst ein LLM nicht nach einem mathematischen Problem; stattdessen bittest du es, das Problem zu formulieren, und dann wird die Berechnung an einen spezialisierten Python-Kernel oder Ähnliches weitergereicht, der viel besser arbeitet, als wenn man die Operation an ein LLM delegiert.
Die interessantesten Dinge geschehen an der Schnittstelle zwischen verschiedenen Domänen. Zum Beispiel haben wir auf der einen Seite die riesige numerische Domäne, auf der anderen Seite Text oder weiche und unscharfe Randfälle und als dritten Teil Code. Code ist weder Zahlen noch Text; er ist strukturiert und überprüfbar, und LLMs sind außerordentlich gut darin. Das schafft neue Anwendungsfälle, die für die supply chain relevant sein könnten, und treibt die Anwendbarkeit von Lösungen wie Lokad noch weiter voran.
Zum Beispiel habe ich einen Fall, in dem ich LLMs einsetze, um große Textmengen zu parsen – außerhalb der standardmäßigen LLM-Fähigkeiten – indem ich das Problem an das LLM formuliere. Etwa indem ich Texte in Hunderten von Gigabytes an Geschäftsberichten weltweit finde oder dabei helfe, ein numerisches Problem zu lösen, ohne die eigentliche Berechnung durchzuführen. Du entwickelst eine Theorie, wie du es angehen kannst, weil du intelligent bist, die Hintergrundgeschichte kennst – und das sind die Kontrollmechanismen, die ich dir gebe.
Wenn es darum geht, in einer riesigen Datenbank zu suchen, bitte ich das LLM in einer bestimmten Syntax, embedding-Suchen zu erstellen, an denen ich arbeiten werde, um eine Liste von Stopwörtern oder eine Whitelist von Keywords zu generieren, die unterstützend wirken. Dann übernimmt ein anderes System, das speziell dafür zuständig ist und sehr gut im skalierbaren Verarbeiten ist, diese gut formulierte Anfrage vom LLM und führt sie aus. Dort liegt der beste Teil, denn LLMs sind in der Lage, Suchen zu verfeinern.
Du gehst zurück zum LLM und sagst: “Das war mein ursprüngliches Problem, das ist, was du darüber gedacht hast, das ist die Abfrage, die du erstellt hast, und das ist der Müll, den es zurückgegeben hat. Bitte passe es an.” Da die Arbeit mit LLMs quasi kostenlos ist, iterierst du vielleicht zehnmal – vielleicht machst du einen chain of thought, vielleicht einen tree of thought, mit guten und schlechten Entscheidungen –, und dann wird es besser. Das Gleiche gilt für die numerischen Domänen. Zum Beispiel möchten Supply Manager eine Idee entwickeln, wie sie ihre Bestände besser ausbalancieren können. Theoretisch können sie sagen: “Hier ist eine kleine Simulation meiner Umgebung, die vielleicht gut genug ist, und so kannst du sie anpassen. Bitte führe jetzt fuzzy constraint solving durch und versuche, Ideen zu entwickeln, die mir helfen könnten, meine Bestände besser auszugleichen.”
Dies ist die Möglichkeit, die sich eröffnet, wenn man beginnt, mehrere Domänen zu verbinden: numerisch, Code und Text, und dabei die besten verfügbaren Werkzeuge für jede Domäne gemeinsam einsetzt.
Conor: Danke, Rinat. Joannes, was ist deine Meinung dazu?
Joannes: Nur um es für das Publikum klarzustellen: Das Interessante ist, dass man bei vielen Problemen, wenn man sie mit einem LLM angeht, sagt: “Bitte erstelle ein Programm, das das Problem löst.” Du wirst nicht sagen: “Ich möchte, dass du das Problem löst.” Stattdessen sagst du: “Erstelle ein Programm, und danach werde ich das Programm analysieren.” Es gibt noch weitere Tricks, wie zum Beispiel, dem LLM einen Compiler zu geben, um zu überprüfen, ob das Programm kompiliert, oder ein Tool, das es dir ermöglicht, das Programm kurz auszuführen, um zu prüfen, ob die Ausgabe Sinn ergibt.
Es geht nicht darum, dass das LLM das Problem direkt löst; es wird vermittelt. Das LLM erzeugt ein Programm und übergibt es anschließend an etwas anderes, das weiterhin textuelle Ausgaben liefert – denn wenn du einen Compiler verwendest, wird dieser versuchen, das Programm zu kompilieren. Funktioniert es nicht, liefert der Compiler eine Fehlermeldung. LLMs bearbeiten Fehlermeldungen gerne und beheben die damit verbundenen Probleme. Wir bewegen uns hier stark im Bereich Text.
Für die supply chain werden die meisten Situationen vermittelt sein. Wir wollen, dass das LLM das Programm erstellt, das unser Vorhaben löst. Zum Beispiel wird das LLM beim ursprünglichen Problem, den Umsatz in Belgien für das letzte Jahr für Kunden ab 1 Million EUR zu ermitteln, nicht die Daten direkt aus der Datenbank entnehmen. Es wird eine SQL-Abfrage erstellen, die von der Datenbank selbst ausgeführt wird. Wieder: Vermittlung.
Was bedeutet das für Unternehmenssoftware? Verfügt ihr in eurer Unternehmenssoftware-Umgebung über Plattformen, die eure supply chain-Ausführung – zumindest die Entscheidungsebene – mit programmierbarer Fähigkeit unterstützen? Das LLM wird nicht die Rohtransaktionsdaten verwerten, um die Ausgabe zu erzeugen; es nimmt die Problemstellung, erstellt ein Programm, und es ist sehr vielseitig in der Art des Programms, das es erstellen kann. Aber dann muss in eurer Umgebung etwas das Programm ausführen. Welche Art von Programmierumgebung könnt ihr dem LLM bieten?
Die meisten klassischen Unternehmenssoftwares bieten überhaupt keine Umgebung. Sie haben lediglich eine Datenbank mit einer Sprache, die du verwenden kannst – aber der einzige Weg, um mit einem großen ERP, das dazu dienen soll, deine Bestände zu optimieren, zu interagieren, besteht darin, die minimalen und maximalen stock levels oder die safety stock Parameter Produkt für Produkt manuell einzustellen. Das LLM kann dir das Rezept nennen, das du anwenden musst, aber wenn du es umsetzen möchtest, musst du die manuellen ERP-Einstellungen durchlaufen. Falls das ERP eine API bietet, kann es ein Programm erstellen, das dir ermöglicht, dies im großen Maßstab über die API zu tun – aber es ist immer noch sehr umständlich im Vergleich zu einer nativen programmierbaren Lösung. Es wird weiterhin durch das Framework vermittelt.
Es erfordert einige tiefgreifende Veränderungen und führt die Programmierbarkeit der Lösung als “first-class citizen” ein. Schmuddeliger Selbstplug: Lokad hat eine programmierbare Plattform. Wir haben das nicht speziell für LLMs entwickelt – es war so ziemlich ein Glücksfall –, aber wir haben es schon vor 10 Jahren umgesetzt, um dieses programmierbare Denken als Kern der Plattform und als erstklassig zu etablieren. Das war Zufall, nicht eine visionäre Einsicht darüber, was in einem Jahrzehnt mit LLMs passieren würde.
Conor: Danke, Joannes. Ich bin mir der Zeit aller bewusst, daher werde ich, wie üblich, an dich zurückgeben, Rinat, für einen abschließenden Gedanken. Gibt es etwas, das du allen Zuschauern sagen möchtest?
Rinat: Es gab in der Vergangenheit ein paar Blasen, wie die Dotcom-Blase und die Finanzblase. LLMs und KI könnten ebenfalls eine Blase sein – oder auch nicht. Sogar meine Mutter weiß von ChatGPT und weiß, wie man es benutzt, was interessant ist. Ich ermutige jeden, keine Angst vor unseren Maschinenherrschern zu haben, denn Skynet wird nicht so einfach funktionieren. Als jemand, der versucht, diese Systeme in der Produktion zu stabilisieren, weiß ich, dass es viel Aufwand bedeutet und es nicht zuverlässig einfach funktioniert. Also erstens, hab keine Angst vor LLMs, und zweitens, nimm sie einfach an. LLMs plus Menschen und Unternehmen können viel mehr Wert schaffen, besonders wenn sie durch spezialisierte Werkzeuge wie Lokads Forecasting ergänzt werden, die sich wirklich gut in die Umgebung einfügen.
Conor: Danke, Rinat. Joannes, vielen Dank für deine Zeit. Rinat, vielen Dank, dass du wieder bei uns bist. Und danke an alle fürs Zuschauen. Wir sehen uns beim nächsten Mal.
