00:00:00 Einführung in das Interview
00:01:01 Auswirkungen der KI auf traditionelle Arbeitsplätze
00:04:36 KI-Automatisierung in supply chain
00:09:08 Notwendigkeit eines einheitlichen Systems im Jahr 2012
00:10:30 Entscheidungen wieder in Systeme einspeisen
00:13:08 Vermeidung des Halluzinationsproblems in der KI
00:16:11 Auswirkungen und Verzögerungen aufgrund von IT-Rückständen
00:20:04 Vergleich von Lokad und den Setups anderer Anbieter
00:23:06 Diskussion über LLM-Halluzinationen und Konfabulationen
00:30:38 Fortschritt über Perfektion bei KI betonen
00:33:00 Abrufen fehlender Informationen und Bestell-ETA
00:36:17 Quantitative Aufgaben und LLMs in supply chain
00:38:28 Zukunft von AI Pilots in supply chain
00:41:18 Wert von Gesprächen und Automatisierung geringwertiger Aufgaben
00:44:57 Einsatz von AI Pilots zur Reduzierung von Rückständen
00:49:00 AI Pilot vs. Copilot und Lockdown-Szenario
00:53:36 Skepsis gegenüber konversationaler KI und Prozessanalyse
00:57:18 Verständnis der geschäftlichen Realität und KI, die Prozesse ersetzt
01:00:12 Herausforderungen beim Open Sourcing von Envision
01:06:21 Ansatz der KI zu Engpässen und supply chain
01:09:17 Ineffizienz verbaler Befehle und Automatisierung von Bestellungen
01:14:12 Supply Chain Scientist als Copilot für AI Pilot
01:17:32 Überprüfung der Datenkorrektheit und Automatisierung von Prüfungen mit LLMs
01:20:15 Envision git-freundlich machen
01:21:14 Kostenlose Ressourcen zum Erlernen von Envision
Zusammenfassung
In einem Dialog zwischen Lokads CEO Joannes Vermorel und Kommunikationsleiter Conor Doherty diskutieren sie die Auswirkungen von KI auf supply chain management. Vermorel hebt die Fortschritte in KI und großen Sprachmodellen hervor, die die Automatisierung von Aufgaben revolutioniert haben. Er stellt AI Pilots vor, ein Angebot von Lokad, das Entscheidungsfindung und Verwaltungstätigkeiten automatisiert, ermöglicht durch Lokads proprietäre Programmiersprache Envision. Vermorel erörtert außerdem das Potenzial der KI zur Automatisierung von Aufgaben im Zusammenhang mit Stammdaten und vergleicht Lokads Ansatz mit dem der Wettbewerber. Er prognostiziert, dass AI Pilots in supply chain management zur Norm werden und zu erheblichen Produktivitätssteigerungen führen. Das Gespräch endet mit einer Q&A-Sitzung.
Ausführliche Zusammenfassung
In einem kürzlichen Gespräch zwischen Conor Doherty, Kommunikationsleiter bei Lokad, und Joannes Vermorel, CEO und Gründer von Lokad, tauchte das Duo in die transformative Rolle der künstlichen Intelligenz (KI) im supply chain management ein. Die Diskussion, eine Fortsetzung eines früheren Gesprächs über die Auswirkungen von KI auf die Beschäftigung, konzentrierte sich auf das Potenzial der KI, als eigenständiger Pilot für die Entscheidungsfindung in der supply chain zu fungieren.
Vermorel begann damit, das bahnbrechende Erreichen generativer KI und großer Sprachmodelle (LLMs) im Jahr 2023 hervorzuheben. Diese Fortschritte, erklärte er, haben die Automatisierung von Aufgaben, die Textverarbeitung beinhalten – wie das Lesen von E-Mails oder das Kategorisieren von Beschwerden – revolutioniert. Das Jahr 2023 war besonders bedeutsam, da es zu einer erheblichen Senkung der Betriebskosten von Natural Language Processing-Techniken für Unternehmen führte. Vermorel sagte voraus, dass dies zur Automatisierung vieler interner Supportfunktionen führen werde, wobei supply chain operationen an vorderster Front stünden.
Vermorel stellte daraufhin AI Pilots vor, ein Angebot von Lokad, das den Entscheidungsfindungsprozess automatisiert und alltägliche Verwaltungstätigkeiten übernimmt. Er hob Lokads einzigartigen Ansatz hervor, bei dem ein Supply Chain Scientist die volle Verantwortung für eine Initiative übernehmen kann. Dies wird durch Lokads proprietäre Programmiersprache Envision ermöglicht, die der prädiktiven Optimierung von supply chain gewidmet ist. Allerdings gab Vermorel zu, dass Lokad zuvor Schwierigkeiten mit der Datensuche und dem Umgang mit verschiedenen SQL-Dialekten hatte.
Die Einführung von GPT-4, erklärte Vermorel, war ein Wendepunkt für Lokad, der es dem Unternehmen ermöglichte, die Erstellung von SQL-Abfragen zu automatisieren. Diese Abfragen können dann von einem Supply Chain Scientist gegengeprüft und getestet werden, um Genauigkeit sicherzustellen. Diese Entwicklung, verbunden mit einer sicheren Cloud-to-Cloud-Verbindung, ermöglicht es Lokads Team von Supply Chain Scientists, die Daten der Kunden eigenständig zu verfolgen und so Verzögerungen zu reduzieren.
Vermorel hob außerdem das Potenzial von LLMs hervor, viele Aufgaben im Zusammenhang mit Stammdaten zu automatisieren, einschließlich Erfassung, Überwachung und Verbesserung. Er stellte Lokads Ansatz dem der Wettbewerber entgegen und erklärte, dass bei Lokad in der Regel weniger Personen in eine Initiative eingebunden werden, wobei jede Person über Kompetenzen entlang des gesamten Ablaufs verfügt. Dies, so argumentierte er, steht im krassen Gegensatz zu Wettbewerbern, die oft viel mehr Personen in eine Initiative einbeziehen, darunter Projektmanager, Berater, UX-Designer, Datenbankadministratoren, Netzwerkspezialisten und Programmierer.
Das Gespräch wechselte dann zur Rolle von Supply Chain Scientists bei der Validierung oder Überwachung von durch LLMs generierten Skripten. Vermorel räumte ein, dass LLMs manchmal ungenaue oder „halluzinierte“ Ergebnisse liefern können, diese in der Regel jedoch richtungsweisend korrekt sind und mit einigen Iterationen durch eine Feedback-Schleife korrigiert werden können. Er schlug vor, dass, obwohl LLMs Fehler machen können, sie dennoch einen großen Mehrwert bieten, und dass ihre Rate an Fehlalarmen und Fehlklassifikationen messbar ist.
Vermorel erklärte weiter das tägliche Zusammenspiel zwischen dem Supply Chain Scientist, dem AI Pilot und dem Kunden. Der AI Pilot, vom Supply Chain Scientist erstellt, übernimmt den täglichen Betrieb der supply chain, indem er die Details der Datenaufbereitung und Bestellentscheidungen verwaltet. Der Kunde wird in diesem Szenario mit einem Kapitän verglichen, der die übergeordnete strategische Ausrichtung vorgibt.
Hinsichtlich der Erkenntnisse für supply chain Praktiker und Führungsteams prognostizierte Vermorel, dass in einem Jahrzehnt AI Pilots in Supply Chain Management (SCM) zur Norm werden. Dies, so glaubt er, werde zu einer massiven Produktivitätssteigerung führen, mit einer potenziellen Reduzierung der Belegschaft um 90% in den bisherigen Funktionen. Er ermutigte supply chain Praktiker, mehr Zeit in strategisches Denken und vertiefte Gespräche mit Lieferanten und Kunden zu investieren.
Das Gespräch endete mit einer Q&A-Sitzung, in der Vermorel Fragen zu einer Reihe von Themen beantwortete, darunter die Rolle von AI Pilots bei der Reduzierung von IT-Rückständen, der Unterschied zwischen einem AI Pilot und einem Copilot, die Bedeutung der Prozessanalyse vor der Implementierung eines KI-Modells, Lokads Pläne, Envision open source zu machen, und wie KI zufällige Engpässe angeht. Er bestätigte außerdem, dass Lokad an einem Lokad Copilot arbeitet und plant, Envision GitHub-freundlicher zu gestalten.
Vollständiges Transkript
Conor Doherty: Willkommen bei Lokad live. Mein Name ist Conor. Ich bin der Head of Communication hier bei Lokad. Und im Studio ist Lokads Gründer Joannes Vermorel zu Gast.
Das heutige Thema ist, wie KI als eigenständiger Pilot für die Entscheidungsfindung in der supply chain fungieren kann. Zögern Sie nicht, jederzeit Ihre Fragen im YouTube-Chat zu stellen, und wir werden in etwa 30-35 Minuten darauf eingehen.
Und damit, Joannes, kommt mir in den Sinn, dass AI Pilots in supply chain eine Erweiterung des Gesprächs sind, das wir vor etwa vier Wochen hatten, in dem wir über die Implikationen von KI auf die Beschäftigung und die Zukunft traditioneller Arbeitsplätze versus KI in supply chain sprachen.
Bevor wir auf die Details von AI Pilots eingehen, könntest du für alle, die das nicht gesehen haben, eine kurze Auffrischung, also eine Zusammenfassung in Kürze, geben, wie unsere Perspektive auf traditionelle Arbeitsplätze versus KI in supply chain aussieht?
Joannes Vermorel: Die Auffrischung besteht darin, dass im Wesentlichen im Jahr 2023 ein Meilenstein erreicht wurde. Dieser Meilenstein ist die generative KI und, genauer gesagt, große Sprachmodelle (LLMs). Aus rein forschungswissenschaftlicher Sicht ist dies lediglich eine Fortsetzung von fast vier bis fünf Jahrzehnten kontinuierlicher Verbesserungen im Bereich des maschinellen Lernens. Betrachtet man das aus der Forschungsperspektive, ist 2023 nur ein weiteres Jahr in einer langen Reihe von Fortschritten. Und in den letzten zwei Jahrzehnten gab es einen relativ rasanten Fortschritt.
Nun, im Jahr 2023 kommt paketierte generative KI für Bilder und, was noch wichtiger ist, für Texte auf den Markt. Und es gibt ein Produkt, das das populär gemacht hat, nämlich ChatGPT von OpenAI. Was bedeutet das? Es bedeutet ganz konkret, insbesondere bei jenen großen Sprachmodellen, dass man eine universelle, rauschresistente rauschresistent Vorlagemaschine hat.
Das bedeutet, dass alle Arten von Schritten in Unternehmenssoftware – ich spreche hier im Kontext von Angestellten, also White-Collar-Arbeitern in Unternehmensumgebungen – gemeint sind, die in der Vergangenheit nicht automatisiert werden konnten, weil man mit Text in jeglicher Form umgehen musste, das heißt, eine E-Mail lesen, eine Referenz oder einen Preis aus einer E-Mail extrahieren, eine Menge oder die Art der Beschwerde bzw. Anfrage von einem Partner, Lieferanten oder Kunden kategorisieren, feststellen, ob eine Produktbezeichnung unsinnig ist, beispielsweise wenn die Produktbeschreibung buchstäblich fehlt – okay, wir haben ein Problem – all diese Dinge konnten in der Vergangenheit nicht einfach automatisiert werden. Es gab alternative Wege, sie zu erledigen, aber sie ließen sich nicht leicht automatisieren.
Wenn wir etwa fünf Jahre in die Vergangenheit blicken, war Text Mining bereits etabliert. Es war schon möglich, Textklassifikatoren zu verwenden und alle möglichen Techniken der natürlichen Sprachverarbeitung einzusetzen, aber sie waren kostspielig. 2023 war ein Meilenstein, weil all diese Probleme dank des Verpackungsgrades, der im Wesentlichen mit GPT-4 über eine API erreicht wurde, dazu führten, dass die Betriebskosten all dieser NLP-Techniken – Techniken der natürlichen Sprachverarbeitung – für Unternehmen um den Faktor 100, wenn nicht 1.000 gesenkt wurden.
Was bedeutet, dass nicht nur die Kosten, sondern auch der Zeitrahmen für die Einrichtung drastisch reduziert wurden. Letztlich, und das ist meine Vorhersage, werden viele Unterstützungsfunktionen in Unternehmen, die ausschließlich interne Funktionen sind, also Daten aufnehmen und für andere Bereiche einen Output erzeugen, automatisiert werden. supply chain steht an vorderster Front, da es nicht direkt eine kundenorientierte Funktion ist. Es ist vielmehr eine interne Funktion, wenn auch eine wichtige. Und so waren es große Sprachmodelle, die fehlende Zutat, um den Großteil der alltäglichen Abläufe in supply chain weitgehend end-to-end zu automatisieren.
Lokad automatisiert seit einem Jahrzehnt die quantitative Analyse und den quantitativen Entscheidungsfindungsprozess, aber es gibt viele alltägliche Abläufe, die davor und viele, die danach stattfinden – und genau diese lassen sich dank großer Sprachmodelle schnell und kostengünstig automatisieren.
Conor Doherty: Nun, danke. Und wir haben bereits ein Video, in dem wir, denke ich, etwa eineinhalb Stunden über dieses Thema gesprochen haben, sodass ich heute nicht weiter darauf eingehen werde, aber das bildet die Grundlage für den Rest des Gesprächs. Ich lade alle herzlich ein, die mehr darüber erfahren möchten, sich das vorherige Video anzusehen. In diesem Zusammenhang: Wie passen AI Pilots in all das, was du gerade gesagt hast? Was sind sie? Was bewirken sie in der Realität?
Joannes Vermorel: KI wurde im Allgemeinen in den letzten zwei Jahrzehnten von Anbietern konsequent als Schlagwort und Sammelbegriff verwendet, um das zu beschreiben, was sie hatten. Wenn ich also von AI Pilots spreche, handelt es sich um ein Angebot von Lokad. Es ist eine Weiterentwicklung des Angebots, vermutlich das größte, das wir seit Jahren haben. Und was ist der Unterschied? Nun, der Unterschied besteht darin, dass ein AI Pilot etwas ist, ein Stück Software, das wir als eine Reihe numerischer Rezepte bezeichnen, die nicht nur den Entscheidungsfindungsprozess ausführen – also den rein quantitativen Aspekt von supply chain, also buchstäblich berechnen, wie viel bestellt werden muss, wo der Bestand zugeteilt wird, ob die Preise erhöht oder gesenkt werden müssen, wie die Produktion mit allen Schritten genau geplant wird usw.
Das, was wir bereits taten, plus alles, was davor und danach kommt in Form von alltäglichen Verwaltungstätigkeiten, die größtenteils das Stammdatenmanagement vor der Datenanalyse umfassen, und anschließend die Umsetzung der Entscheidung, die unstrukturierte Kommunikationswege wie beispielsweise E-Mails beinhalten kann, in denen man einen Lieferanten anweist, etwas zu beschleunigen oder im Gegenteil eine Bestellung zu verschieben.
Und der Kern dieses Angebots sind offensichtlich große Sprachmodelle, die Lokad nicht erfunden hat, die wir seit 14 Monaten – mittlerweile etwas länger – intensiv nutzen. Und die zentrale Erkenntnis der Arbeitsweise von Lokad ist, dass ein einzelner Supply Chain Scientist in der Lage sein sollte, die volle Verantwortung für eine Initiative zu übernehmen.
Bei sehr großen Unternehmen mag es sein, dass wir mehrere Personen einsetzen, aber im Gegensatz zu den meisten unserer Wettbewerber sind diese in der Regel nicht spezialisiert. Es ist also nicht so, dass wir ein Team von drei zusammenstellen – bestehend aus Mr. Database, Mr. Algorithms und Mr. UI und UX, der Benutzererfahrung. Das entspricht überhaupt nicht der Arbeitsweise von Lokad. Ein Supply Chain Scientist ist in der Lage, alles von Anfang bis Ende zu erledigen.
Und das ist einer der Gründe, warum Lokad die Technologie so entwickelt hat, wie sie es tut, und warum wir unsere eigene Programmiersprache haben – eine domänenspezifische Programmiersprache namens Envision, die der prädiktiven Optimierung von supply chain gewidmet ist. Es mag seltsam klingen, eine maßgeschneiderte Programmiersprache entwickelt zu haben, aber der Kernpunkt ist: Wir, und das war eine Entscheidung, die ich bereits 2012 getroffen habe, brauchten wirklich etwas Einheitliches, damit eine Person das Ganze von Anfang bis Ende erledigen kann.
Bis vor einigen Jahren bedeutete das wirklich, die rohen Transaktionsdaten aus den ERPs, CRMs, EDI und all den transaktionalen Systemen zu erhalten, diese mit einer Vielzahl von Tabellenkalkulationen für all die strukturierten Daten zu vervollständigen, die leider Teil der Shadow IT statt der regulären IT sind, und dann die zahlenbasierten Entscheidungsrezepte zu entwickeln. Und das war die Aufgabe des Supply Chain Scientist, all dies zu erledigen, anschließend alle Instrumente einschließlich Dashboards und Berichte zu erstellen, um sicherzustellen, dass er oder sie sich selbst davon überzeugt, dass die Zahlen korrekt waren, aber auch um unsere eigenen Kunden von der Gültigkeit dessen, was wir tun, zu beruhigen, plus all die Instrumente, um die Qualität der Entscheidungen über die Zeit zu überwachen, sowie die Infrastruktur, um die Daten aus den Systemen herauszuholen, aber auch, um die Entscheidungen wieder in die Systeme einzuspeisen.
So war der Umfang, den Lokad hatte, und es gab zwei Dinge, die wir wirklich nicht tun konnten. Erstens mussten wir der Empfänger der Daten sein, wir konnten die Daten nicht wirklich jagen. Und wenn ich jage sage, konnte der Supply Chain Scientist die Daten anfordern; wir baten die IT-Abteilungen unserer Kunden nicht darum, irgendeine ausgeklügelte Transformation vorzunehmen – es ging einfach nur ums Abrufen der Tabellen, also, “select star from table”, zack, das macht man einmal am Tag und fertig. Es waren also super einfache Extraktionen, aber dennoch wurde dies im Wesentlichen von der IT-Abteilung unserer Kunden durchgeführt.
Von den Supply Chain Scientists wurde nicht erwartet, dass sie in der anwendungsspezifischen Landschaft unserer Kunden die Daten aufspüren, die die Initiative benötigte. Der Grund dafür ist ganz einfach: Es gibt etwa 20 verschiedene SQL-Dialekte, also Oracle SQL, den T-SQL-Dialekt von Microsoft SQL Server, MySQL, PostgreSQL, DB2 von IBM etc. Es gibt also so etwas wie 20 SQL-Dialekte. Bis vor wenigen Jahren hätte ein Supply Chain Scientist enorm zu kämpfen gehabt, allein schon deshalb, dass selbst, wenn das, was diese Person erreichen wollte, äußerst unkompliziert war – beispielsweise nur eine einzelne Tabelle zu dumpen –, das Problem darin bestand, dass diese Person buchstäblich zig Stunden online verbracht hätte, um triviale Abfragen zusammenzustellen, und wann immer eine Fehlermeldung auftrat, wäre es wieder diese Person gewesen. Selbst wenn sie generell mit SQL-Datenbanken vertraut war, war es, würde ich sagen, ein massives Hindernis, sich mit Dialekten von Systemen auseinanderzusetzen, die man nicht kannte.
2023, mit ChatGPT, ist das Problem gelöst. ChatGPT, als assistierender Programmierer, ist nicht von Natur aus besonders gut darin, dir beim Erstellen anspruchsvoller Anwendungen zu helfen, aber wenn es darum geht, super einfache SQL-Abfragen in Dutzenden von Dialekten zu erstellen, ist es extrem schnell. Ein Supply Chain Scientist wird anfordern, dass eine SQL-Abfrage erstellt wird. Diese Person ist auch intelligent und wird die Abfrage Korrektur lesen, um sicherzustellen, dass sie die beabsichtigte Funktion widerspiegelt. Es geht lediglich darum, das Hindernis der Syntaxfindung zu beseitigen, doch sobald dir die korrekte Syntax präsentiert wird, ist alles ziemlich selbsterklärend.
Wenn du es selbst ausprobieren möchtest, frage einfach ChatGPT, ob es dir eine Anleitung zum Einrichten von git auf deinem Rechner und zum Erstellen eines git-Repositories oder Ähnlichem geben kann – du wirst sehen, welche Art von hochqualitativer Antwort du erhalten kannst.
Das ist wirklich ein Wendepunkt, denn das bedeutet, dass plötzlich Lokad, das Supply Chain Scientists ausbildet, die Verantwortung für das Jagen der Daten übernehmen kann. Und ich weiß, dass wir dank ChatGPT über die Werkzeuge verfügen, sodass wir uns nicht zu sehr verpflichten, zu behaupten, dass wir die Daten jagen werden. Es ist ein Game Changer. Anstatt die IT zu bitten, uns die Daten zu senden, können wir einfach eine IP-Adresse in die Whitelist aufnehmen lassen und dann eine sehr sichere Cloud-to-Cloud-Verbindung herstellen, sodass das Team der Supply Chain Scientists seine eigenen Daten verfolgen kann.
Warum macht das so einen Unterschied? Nun, die Realität ist, dass selbst wenn Lokad für eine gegebene Initiative nur wenige Arbeitstage benötigt – wir sprechen von vielleicht 10 bis 20 Arbeitstagen für eine umfangreiche Initiative, um die 20 bis 50 Tabellen zu erhalten, die wir brauchen, es sich dabei lediglich um das einfache Abrufen der Tabelle handelt, ohne Joins, ohne fancy Filter –, das Problem darin bestand, dass viele unserer Kunden ihre eigenen IT-Abteilungen haben, die enorme Rückstände besitzen. Ich meine buchstäblich jahrelange Rückstände, und wenn man beispielsweise drei Jahre Rückstand hat, dann bedeuten 10 Tage plus drei Jahre Rückstand, dass selbst, wenn wir nicht ganz am Ende der Warteschlange stehen, diese 10 IT-Arbeitstage fast ein Jahr in Anspruch nehmen können. Das war, würde ich sagen, eine Frustration, die wir hatten: Der Großteil der Verzögerungen kam nicht daher, dass die IT inkompetent oder langsam war, sondern weil sie so viele Rückstände hatte, die es ihnen extrem erschwerten, diese 10 Tage freizumachen.
Hier haben wir also den Fall, dass anstatt 10, 20 Arbeitstage anzufordern, wir über etwas sprechen, das vielleicht weniger als einen Arbeitstag in Anspruch nimmt – so etwas wie nur ein paar Stunden, um einen sehr sicheren, straffen Zugang zu den wenigen Systemen zu eröffnen, die wir benötigen. Und dann werden die Supply Chain Scientists selbst die Tabelle analysieren, die Logik der Datenauszüge aufsetzen und sicherstellen, dass diese wirklich, würde ich sagen, eine leichte Wirkung haben.
Die Art und Weise, wie wir das erreichen können, besteht typischerweise darin, die Performance zu überwachen. Wann immer die Leistung der Datenbank nachlässt, bedeutet das, dass in der Datenbank viel los ist, sodass man typischerweise den Druck abbauen und den eigenen Datenabrufprozess verzögern möchte. Denn bei Lokad müssen die Daten normalerweise täglich aktualisiert werden, aber es ist nicht von höchster Dringlichkeit. Ich meine, es kommt immer auf die Situation an. Es gibt Fälle, in denen wir wirklich enge Zeitpläne haben, aber sehr häufig – was supply chains betrifft – ist es unproblematisch, wenn wir den Abruf um 30 Minuten verzögern, nur weil gerade ein Aktivitätsspitzenwert in dieser Datenbank vorliegt.
Der erste Schritt der Verpflichtung besteht darin, die Daten selbst zu jagen und somit die häufigste Ursache für Verzögerungen zu beseitigen sowie die Initiativen erheblich zu beschleunigen. Wiederum machten diese Verzögerungen sehr häufig den Großteil der Gesamtdauer der Lokad-Initiative bis zur Produktionsreife aus, weil man einfach darauf wartete, dass die IT diese Tage zuweisen konnte.
Der zweite Schritt der Verpflichtung ist die Verbesserung der Stammdaten. Und auch hier war es früher so, dass man, wenn man mit einem Katalog von sagen wir 100.000 Produktbeschreibungen konfrontiert war, von denen einige Müll waren – vielleicht 1 % –, eine Menge Arbeit hatte, diese 100.000 Referenzen durchzugehen, die Beschreibungen oder Produktbezeichnungen zu identifizieren, die fehlerhaft sind oder bei denen manchmal nur ein Preis vorhanden ist, der völlig inkonsistent mit der Beschreibung ist. Wenn beispielsweise “Schraube” steht und der Preis bei 20.000 Dollar liegt, dann ist es vermutlich nicht einfach nur eine Schraube, sondern wahrscheinlich etwas anderes, usw. Es gab viele grundlegende Plausibilitätsprüfungen, die offensichtlich und simpel erschienen, die aber sehr schwer zu automatisieren waren, sodass es häufig keine Alternative gab, als jemanden zu beschäftigen, der die Einträge überprüft und nach wirklich fehlerhaften Daten sucht.
Mit einem LLM – und potenziell einem LLM, das auch Bilder verarbeiten kann – kannst du viel erreichen, was das Untersuchen, Überwachen und Verbessern von allem angeht, was mit Stammdaten zu tun hat. Im speziellen Fall von Lokad ist es der Stammdatenanteil, der für die Steuerung der supply chains benötigt wird.
Conor Doherty: Nun, da gibt es viel, danke. Ich habe viele Fragen, denen ich gerne nachgehen möchte. Ich werde einen kleinen Schritt zurücktreten, denn wenn ich all das, was du beschreibst, zusammenfasse – korrigiere mich, falls ich falsch liege –, kann mit einem Supply Chain Scientist, der Zugang zu einem guten LLM hat, eine enorme Menge an Arbeit erledigt werden. Arbeit, die bis zu diesem Moment viel Zeit in Anspruch genommen hätte und an der viele Menschen beteiligt gewesen wären. Nun, in einem Setup, das nicht im Lokad-Stil ist, wie viele zusätzliche Personen wären involviert? Wie viele mehr Hände wären im Spiel? Und da kannst du auch über die Effizienz sprechen, aber rein bezogen auf die Mitarbeiterzahl: Was ist der Unterschied zwischen Supply Chain Scientists mit LLM und, ich weiß nicht, S&OP zum Beispiel?
Joannes Vermorel: Unsere Kunden sind in der Regel verblüfft darüber, dass selbst eine große Initiative nur von zwei oder drei Personen durchgeführt wird – und immer dieselben. Wir haben Lokad, und ich bin sehr stolz darauf, dass Lokad als Arbeitgeber es schafft, Mitarbeiter ziemlich lange zu halten. Also lautet das Fazit, dass Lokad typischerweise 1 % von Anfang bis Ende benötigt. Wenn wir mehrere Personen haben, dient das vor allem der Redundanz. An einem Tag konzentriert man sich auf diesen Teil der Pipeline und ich auf einen anderen, und am nächsten Tag wechseln wir. Es ist nicht so, dass sich die Leute nicht spezialisieren; jeder hat Kompetenzen im gesamten Prozess. Es gibt gewisse Unterschiede und manche haben besondere Spezialgebiete, aber insgesamt können sich die Mitarbeiter wirklich gegenseitig ersetzen.
Unsere Wettbewerber hingegen – das ist ganz anders. Selbst eine kleine Initiative umfasst buchstäblich ein halbes Dutzend Personen. Es gibt den Projektmanager, der nur da ist, um die anderen zu koordinieren, dann den Berater, den UX-Designer, den Konfigurator, den Datenbankadministrator, den Netzwerkspezialisten und potenziell einen Programmierer, einen Software Engineer für die kundenspezifischen Anpassungen, die nicht nativ sind. Noch einmal: Lokad ist eine programmatische Plattform, während die Plattformen der meisten unserer Wettbewerber es nicht sind. Wann immer du also etwas in programmatischem Verhalten benötigst, musst du einen vollwertigen Software Engineer beschäftigen, der mit einer universellen Programmiersprache wie Java oder Python buchstäblich die fehlenden Teile implementiert. Lokad ist also wirklich nicht so. Ich würde sagen, unsere Wettbewerber kommen per se auf etwa ein Dutzend. S&OP-Initiativen können mehrere Dutzend Personen umfassen, aber es sind nicht unbedingt so viele verschiedene Fähigkeiten – es sind meist einfach verschiedene Personen aus unterschiedlichen Abteilungen, und sehr häufig ist es nicht besonders IT-orientiert.
Also, wenn ich von einer Person im Vergleich zu einem Dutzend spreche, beziehe ich mich auf unsere Wettbewerber, die APS (advanced planning systems) oder Bestandsoptimierungssysteme – also diese Art von Unternehmenssoftware – verkaufen.
Conor Doherty: Danke. Und um auf einen weiteren Punkt zurückzukommen, den du am Anfang erwähnt hast, als du von Supply Chain Scientists sprachst – du hast das Beispiel verschiedener SQL-Dialekte genannt – und dann der Supply Chain Scientist, der möglicherweise mit dem spezifischen Dialekt des Kunden nicht fließend ist, die automatisch generierten Skripte validieren oder überwachen würde, weil LLMs gelegentlich halluzinieren.
Naja, in dieser Hinsicht halluzinieren LLMs sehr oft. Es wird zwar besser, aber du kannst ein LLM mit einem Textabschnitt fragen: “Finde dieses versteckte Wort, siehst du es?” und es wird bejahen, obwohl es gar nicht dort ist. Ich weiß, dass es nicht da ist, du weißt, dass es nicht da ist. Wie kannst du in großem Maßstab Sicherheit gewährleisten und gleichzeitig die Qualitätskontrolle überwachen, wenn du LLMs automatisiert einsetzt?
Joannes Vermorel: Halluzinationen – oder, wie ich sie lieber nenne, Konfabulationen – treten wirklich dann auf, wenn du das LLM als Wissensbasis für alles verwendest. Wenn du LLMs so behandelst wie eine allumfassende Datenbank, dann passiert das auch. Fragst du beispielsweise nach medizinischen Artikeln und sagst: “Gib mir eine Liste von Artikeln über diese Pathologie”, wird dir etwas geliefert, das in etwa korrekt ist. Die Autoren existieren häufig, sie haben veröffentlicht, sie haben Arbeiten in diesem Bereich – sie haben Artikel publiziert, die in dieselbe Richtung gehen, aber nicht ganz. Denk also daran, als ob du einen Wissenschaftler darum bittest, sich Dinge aus dem Gedächtnis abzurufen.
Es ist sehr schwierig, würdest du sagen, und wenn du darauf bestehst, dass es getan werden muss, würden sie wahrscheinlich etwas halbwegs Plausibles mit korrekten Namen von Kollegen oder Forschern, mit korrekten oder halb korrekten Titeln hervorbringen – so etwas eben. Das ist eine Situation, in der du Konfabulationen bekommst, aber du bittest ja quasi darum. Ich meine, du forderst LLMs auf, sich wie eine Datenbank von allem zu verhalten, also ist das sehr schwierig und du wirst dieses Problem haben.
Das Gleiche gilt für die SQL-Dialekte: Du probierst es aus und erhältst etwas, das annähernd korrekt ist. Fragst du beispielsweise “Ich möchte eine Tabelle auslesen”, wird es ein “select star from table” oder Ähnliches liefern. Es wird dir nicht – wenn du zum Beispiel mit GPT-4 bittest, eine Tabelle auszulesen – “drop table” zurückgeben. Es mag eine Syntax liefern, die ein wenig unzureichend ist, sodass du deine SQL-Abfrage testest, eine Fehlermeldung erhälst und eine kleine Anpassung vornimmst, bis es funktioniert. Aber siehst du, es ist immer noch in die richtige Richtung. Wenn du die Datenbank auslesen möchtest, wird es keinen Befehl erzeugen, der eine Tabelle löscht oder die Berechtigungen der Datenbank verändert.
Das Gleiche gilt, wenn du nach erfundenem Wissen fragst. Wenn du beispielsweise sagst: “Okay, ich habe einen industriellen Kompressor mit 20 Kilowatt Leistung – was ist der Preis dafür?” und du fragst GPT, wird es wahrscheinlich etwas wie 10.000 Dollar sagen. Es schätzt einfach nur irgendetwas – das ist buchstäblich erfunden. Es ist plausibel, aber ist es korrekt? Wahrscheinlich nicht, und es hängt von hunderten von Varianten ab, da es so viele verschiedene Kompressoren für unterschiedliche Situationen gibt.
Also, letztlich treten Konfabulationen nicht zufällig auf. Es gibt wirklich spezifische Aufgaben, bei denen sie viel häufiger vorkommen. Daher würde ich sagen, wenn du danach verlangst, wenn du das LLM wie eine Datenbank von allem verwendest, ist es besser, noch einmal nachzuprüfen. Es kann extrem nützlich sein – es gibt dir zum Beispiel bei den SQL-Dialekten einen Hinweis darauf, welche Schlüsselwörter du verwenden solltest, wie die Syntax aussieht, und es mag einen kleinen Fehler machen, ein Komma vergessen oder Ähnliches, aber mit ein paar Iterationen wirst du es richtig hinbekommen. Vor allem, weil du, sobald du die SQL-Abfrage hast, diese tatsächlich an der Datenbank testen kannst, die Ausgabe siehst und validierst – so hast du eine sofortige Rückkopplungsschleife.
Wenn Sie beispielsweise verrückte Produktetiketten erkennen wollen – Etiketten, die verdächtig aussehen, weil beispielsweise die Produktbeschreibung fehlt – dann ist das Ihr Produktetikett, okay, das ist offensichtlich falsch. Aber es kann allerlei falsch laufen. So kann es zum Beispiel ein Produktetikett geben, auf dem “tournevis cruciforme” steht, was auf Französisch ist, und das Problem ist, dass es nur auf Französisch verfasst ist – es ist, glaube ich, ein Schraubendreher mit Phillips-Kopf. Und nochmals: Man kann um vieles bitten, aber irgendwann ist es nicht perfekt, es ist eine Ermessensfrage. Ein Mensch würde denselben Fehler machen, weshalb man nicht erwarten kann, dass das LLM ein allwissendes Orakel ist, das jede Frage korrekt beantwortet. Wenn Sie beispielsweise 100.000 Produkte in Ihrem Katalog auf Anomalien in den Etiketten überprüfen, wird das LLM, ganz wie ein Mensch, sowohl Fehlalarme als auch falsch-negative Ergebnisse produzieren. Das Interessante daran ist, dass Sie die Rate von Fehlalarmen und falsch-negativen Ergebnissen messen und dann entscheiden können, ob es sich lohnt oder nicht. Und sehr häufig erhalten Sie etwas, das ziemlich gut ist – etwas, das Ihnen viel Wert bietet, auch wenn es doch noch Fehler macht.
Conor Doherty: Fortschritt, nicht Perfektion.
Joannes Vermorel: Genau. Wenn Sie Ihre Stammdatenprobleme um 90 % reduzieren können – mit etwas, das sehr günstig ist und buchstäblich innerhalb von Stunden unbeaufsichtigt erneut ausgeführt werden kann – ist das wirklich hervorragend.
Conor Doherty: Zudem ergibt sich ein Mehrwert aus der Zeit, die Sie nicht für manuelle Tätigkeiten aufwenden, sondern anderweitig in etwas investieren können, das Wert schafft. Es gibt also sowohl direkte als auch indirekte Faktoren, die diesen Mehrwert bewirken.
Joannes Vermorel: Außerdem ist die Realität, dass, wenn Sie eine stark repetitive Aufgabe für eine Stunde ausführen, ein gewisses Qualitätsniveau erreicht wird. Tun Sie dies jedoch über 100 Stunden – ab spätestens Stunde 67, denn in der Regel sind Menschen keine Maschinen mit konstanter Leistung –, sinkt die Konzentration, und die Anzahl der Fehlalarme und falsch-negativen Ergebnisse wird wahrscheinlich in die Höhe schießen, selbst bei einem ziemlich gewissenhaften Mitarbeiter.
Conor Doherty: Vielen Dank. Und ich möchte darauf aufmerksam machen, dass wir tatsächlich einige Fragen aus dem Publikum haben, die Dinge ansprechen, die ich eigentlich stellen wollte – daher lasse ich manche Punkte weg, die aber in den Publikumsfragen beantwortet werden. Ein letzter Gedanke: Wenn Sie über die Supply Chain Scientists, den AI Pilot – worauf wir später in den Fragen zurückkommen – und den Kunden sprechen, wie funktioniert diese Orchestrierung im täglichen Geschäft? Hat der Kunde Zugriff? Interagiert er mit dem LLM?
Joannes Vermorel: In der Regel sehen wir es so, dass all die numerischen Rezepte, die von Supply Chain Scientists erstellt werden, den AI Pilot bilden. Das ist das System, das die supply chain täglich steuert. Es läuft unbeaufsichtigt und generiert die Entscheidungen. Mit LLMs werden zudem die Details der Datenaufbereitung und der Bestellentscheidungen (PO-Entscheidungen) übernommen. So könnte beispielsweise die Vorentscheidung darin bestehen, Lieferanten nach ihrem MQS zu fragen. Diese Information muss abgefragt werden, falls sie fehlt oder nicht aktuell ist – LLMs können hier unterstützen. Die Nachentscheidung bestünde dann darin, eine E-Mail zu versenden, um eine ETA (Estimated Time of Arrival) für Bestellungen anzufragen, falls kein EDI eingerichtet ist oder keine Bridge vorhanden ist, oder um zu beschleunigen bzw. zu verschieben. Genau solche Details folgen danach, wobei Lokad die Entscheidung zur Beschleunigung einer Bestellung generieren kann, ohne sich um die bloße E-Mail-Erstellung und -Versendung zu kümmern.
All das bildet sozusagen den AI Pilot und ist das große numerische Rezept, das den gesamten Prozess von Anfang bis Ende steuert. All dies wird vom Supply Chain Scientist umgesetzt. Das bedeutet eine Erweiterung des Aufgabenbereichs von Lokad. Der Supply Chain Scientist ist tatsächlich der Copilot. Und denken Sie dabei: Wenn ich von einem Piloten spreche, meine ich sozusagen einen automatisierten Piloten in einem Flugzeug. Übrigens werden in heutigen Flugzeugen die schwierigsten Manöver im Autopiloten durchgeführt. Haben Sie beispielsweise sehr herausfordernde Flughäfen wie den alten Flughafen Hongkong – während ein neuer wesentlich einfacher ist, aber es gibt einen Flughafen, der buchstäblich zwischen Hochhäusern liegt – dann ist der Autopilot für diese Manöver unerlässlich. Es wird also komplett maschinell ausgeführt, während die Menschen lediglich überwachen.
Hier entwickelt der Supply Chain Scientist die numerischen Rezepte und fungiert als Copilot. Er trifft Entscheidungen, übernimmt im Wesentlichen die Navigation, um die Prozesse zu steuern, und erarbeitet den Plan sowie den Kurs für den Piloten. Grundsätzlich spielt der Supply Chain Scientist die Rolle des Copiloten, bestimmt die Richtung, denkt voraus und sorgt dafür, dass der Pilot so reibungslos wie möglich operieren kann. Aber bei allen hochfrequenten Anpassungen ist es letztlich der Pilot, nicht der Copilot. Der Kunde übernimmt dann die Rolle des Kapitäns.
Sozusagen, wie in der alten Fernsehserie Star Trek, wo der Kapitän im Stuhl sitzt und der Crew sehr oberflächliche Anweisungen gibt. In diesem Szenario gibt der Kunde die Strategie und die übergeordneten Richtlinien vor. Es ist dann die Aufgabe des Supply Chain Scientist, das umzusetzen, während der Pilot lediglich all die notwendigen Mikroanpassungen bzw. täglichen Entscheidungen für die supply chain ausführt.
Conor Doherty: Und dies gilt – nochmals zur Klarstellung, da wir nicht darüber gesprochen haben – zusätzlich zu all den automatisierten quantitativen Aufgaben, die bereits seit Jahren erledigt werden. Falls also jemand zuhört und denkt: „Ach, das sind nur die qualitativen Aufgaben“, sprechen wir hier von einem End-to-End-Prozess. Ja, quantitativ – wie das Factoring von economic drivers, die Generierung von Allokationen, Einkauf, Preisfestsetzung – all das wird bereits von KI gesteuert und automatisiert.
So überwacht der Supply Chain Scientist beide Arten von Systemen – die quantitativen und die qualitativen.
Joannes Vermorel: Genau. Und der Grund, warum Lokad endlich diesen KI-Begriff als Oberbegriff angenommen hat, liegt darin, dass wir nun LLMs in den Mix einwerfen. Wir hatten bereits maschinelles Lernen mit differentiable programming und stochastische Optimierung, aber jetzt setzen wir LLMs obendrauf. Damit verfügen wir buchstäblich über ein sehr vollständiges Werkzeugset.
Die Folge ist, dass supply chains bei unseren Kunden wochenlang unbeaufsichtigt laufen können. Die Leute sind erstaunt, wie lange – wenn man diese wirtschaftlichen Treiber hat – man tatsächlich völlig unbeaufsichtigt operieren kann. Das Schöne daran ist, dass keine Mikroanpassungen notwendig sind. Zum Beispiel sind Anpassungen an der Prognose bei den meisten unserer Kunden völlig überflüssig. Und die meisten anderen Anpassungen erfolgen ebenfalls vollständig automatisch, wie etwa die Einführung von new products, das Ausmustern alter Produkte, die Einführung neuer Lieferanten und das Aussortieren nicht leistungsfähiger Lieferanten.
All das ist sozusagen Geschäftsalltag, und wenn die Rezepte korrekt erstellt sind, bedurfte es in der Vergangenheit schon nicht allzu vieler Eingriffe. Aber mit diesem AI Pilot, der LLMs einschließt, kann beispielsweise das Hinzufügen eines neuen Lieferanten all diese Prozesse noch weiter automatisieren und den manuellen Aufwand reduzieren.
Conor Doherty: Okay, Joannes, danke. Wir waren etwa 40 Minuten unterwegs. Es gibt noch Fragen, auf die wir eingehen müssen, daher lenke ich uns jetzt in diese Richtung. Aber bevor wir dazu kommen, möchte ich nochmals zusammenfassen oder einen abschließenden Gedanken äußern – im Kontext der viel umfangreicheren Diskussion, die wir vor einem Monat führten und die wir heute fortsetzen: Was ist das Fazit sowohl für den supply chain Praktiker als auch für die Führungsteams, die den durchschnittlichen, normalen supply chain Praktiker überwachen? Was ist der Aufruf zum Handeln oder die wesentliche Erkenntnis für sie?
Joannes Vermorel: Ich glaube, dass diese Vision der AI Pilots – vielleicht unter einem anderen Namen – in einem Jahrzehnt zur Norm wird. Vielleicht wird es so, dass die Leute einfach von supply chain sprechen und nicht von AI Pilots für die supply chain. Und es wird ganz selbstverständlich sein, dass die supply chain über diese AI Pilots verfügt. So wie bei einem Computer: Man sagt nicht, „Ich habe eine CPU, ich habe Speicher“ – es ist selbstverständlich, dass ein Computer eine CPU hat, und man erwähnt das gar nicht erst.
Meiner Meinung nach werden in etwa einem Jahrzehnt diese Funktionen umfassend automatisiert sein, und Lokad bietet mit diesen AI Pilots ein Paket an, das dies zusammen mit einem Supply Chain Scientist umsetzt. Für unsere Kunden bedeutet das, dass sich die Praxis in der supply chain grundlegend ändert. Es bedeutet, dass sie über diese AI Pilots verfügen, die viel Kapazität freisetzen. Wir haben bereits Kapazitäten im Entscheidungsprozess bzw. bei komplexen Berechnungen freigesetzt. Aber nun befreien wir auch die Zeit, die bisher für die Überwachung der Liste der SKUs, der Lieferanten und der Kunden aufgewendet wurde, nur um die Stammdaten korrekt, sauber und ordentlich zu halten. All das fällt weg und macht manuelle Eingriffe überflüssig, die sehr häufig nicht einmal wirklich quantitativ waren. Man musste ein Etikett korrigieren, einen Eintrag berichtigen, ein Duplikat entfernen oder Ähnliches. All das übernimmt, erneut, Lokad.
Das Fazit ist also, dass es eine massive Produktivitätssteigerung darstellt. Ich denke, mit einigen Kunden erreichen wir buchstäblich eine 90%-ige Reduktion des Personalaufwands für repetitive Aufgaben. Die Realität ist, dass Sie nun mehr Zeit haben, um sich tatsächlich den Aufgaben zu widmen, die viel schwieriger zu automatisieren sind, und ich glaube, das schafft mehr Wert. Das heißt, Sie sollten intensiv über Ihre Strategie nachdenken und viel mehr Zeit in die Abwägung von Optionen investieren – was sollten Sie erkunden, anstatt erneut Ihre Zeit mit Tabellenkalkulationen zu vergeuden.
Verbringen Sie also viel Zeit damit, sich intensiv mit den schwierigen Problemen auseinanderzusetzen, sprechen Sie mit Lieferanten und Kunden und führen Sie wirklich tiefgehende Gespräche, damit Sie Ihre eigene supply chain so organisieren können, dass Sie Ihre Lieferanten zufriedenstellen – sodass diese bereit sind, Ihnen bessere Preise, höhere Qualität, mehr Zuverlässigkeit etc. zu bieten. Wenn Sie sich so organisieren, dass Sie die Bedürfnisse Ihrer Lieferanten berücksichtigen, mag es auf den ersten Blick widersprüchlich klingen – als ob man sagen würde: „Oh Lieferanten, ich bin der Kunde, ihr müsst euch anpassen.“ Aber wenn Sie Ihre Lieferanten besser unterstützen können, ist es eine Teamleistung und Sie erreichen mehr Zuverlässigkeit und bessere Preise.
Und denselben Aufwand können Sie auch mit Ihrem Kunden betreiben, denn es sollte dieselbe Zusammenarbeit erfolgen. Wiederum erfordert das viele intelligente Diskussionen, und solche Dinge liegen momentan weit über dem, was LLMs leisten können. Deshalb bin ich der Meinung, dass wir bei Lokad die Aufgaben, die wir als geringwertige Details und alltägliche Verwaltungsaufgaben ansehen, automatisieren können, sodass sich die Menschen auf hochrangige, halbstaatlich-strategische Tätigkeiten konzentrieren. Ich sage „halbstaatlich-strategisch“, weil Sie mit je einem Kunden sprechen und anschließend eine Strategie entwickeln – all das zusammenfassen, eine Vision kreieren und dann das Management der supply chain unterstützen, sodass es eine klare und fundierte Strategie für das Unternehmen hat.
Conor Doherty: Nochmals, um zwei Beispiele zur Veranschaulichung zu nennen: Die Entscheidungen auf niedrigster Ebene, wie das Durchgehen einer Excel-Tabelle und das Feststellen, dass ein farbig markierter Block schwarz sein muss – quasi eine automatische Korrektur –, das ist trivial, alltäglich und nicht Ihre Zeit wert. „Sollte ich ein warehouse in Hamburg eröffnen?“ – das ist strategisch.
Joannes Vermorel: Ja, das ist strategisch. Außerdem besteht das Problem darin, dass es so viele Optionen gibt. Man könnte zum Beispiel sagen: Bei einem Lager – sollte ich es kaufen oder mieten, welche Vertragsbedingungen, welcher Automatisierungsgrad, benötige ich einen Vertrag für die Ausrüstung, um sie zurückzugeben, oder sollte ich die Ausrüstung leasen? Es gibt buchstäblich Hunderte von Fragen, und sehr häufig, wenn Menschen 99 % ihrer mentalen Kapazität in administrative Aufgaben investieren müssen, bleibt kaum noch Zeit für die wirklich wichtigen, großen Fragen.
Sehen Sie, wenn ich das Parkinsonsche Gesetz anwende, würde man sagen: Ich habe viele Unternehmen gesehen, bei denen, wenn ich die Gesamtdauer der auf etwas wie ABC classes verwendeten Minuten berechne – jedes Jahr sprechen wir hier von in Menschenjahren gemessenen Investitionen in ABC-Klassen – während für die Entscheidung über ein neues Lager Wochen an Zeit benötigt werden. Dabei wird das Missverhältnis deutlich: Für etwas, das völlig unsinnig ist wie ABC-Klassen werden buchstäblich über Jahre hinweg menschliche Ressourcen aufgewendet, während für eine 50-Millionen-Euro-Investition zur Eröffnung eines Lagers buchstäblich Wochen vergehen – und dann, zack, wird eine Entscheidung getroffen. Es sollte genau umgekehrt sein.
Conor Doherty: In Ordnung, vielen Dank dafür. Damit werde ich jetzt zu den Publikumsfragen übergehen. Vielen Dank – reichen Sie diese gerne ein, bis ich im Grunde stoppe. Also, Joannes, hier ist eine Frage von Massimo: Könnten Sie bitte erläutern, wie die IT AI Pilots nutzen kann, um den Rückstau zu reduzieren, und warum Sie glauben, dass dieser Ansatz vorgeschlagen werden sollte?
Joannes Vermorel: AI Pilots geht nicht darum, die Rückstände der IT zu reduzieren. Es geht darum, mit der Tatsache umzugehen, dass die IT jahrelangen Rückstand hat. Unser Plan bei Lokad zielt also nicht darauf ab, den IT-Rückstau zu verringern. Es erfordert, dass man die IT so neu denkt wie Amazon es getan hat – das wäre dann eine weitere Episode. Ich würde sagen, sehen Sie sich das Memo von Jeff Bezos aus dem Jahr 2002 bezüglich der APIs bei Amazon an. Letztlich braucht jede Abteilung in einem modernen Unternehmen Unmengen an Software. Jede einzelne Division – Marketing, Finanzen, Buchhaltung, supply chain, Vertrieb – will Unmengen an Software-Tools, und all das lastet auf der IT. Die IT gerät unter dieser Last ins Straucheln.
Mein Punkt ist, dass wir bei Lokad Supply Chain Spezialisten sind. Wir werden uns nicht um alles für Marketing, Vertrieb, Buchhaltung und dergleichen kümmern. Was wir sagen, ist, dass wir mit LLMs die IT entlasten können, die sich um Lokad kümmert. Letztendlich gehen wir von einem Bedarf von, sagen wir, 10 bis 20 Arbeitstagen der IT aus, um die die Quantitative Supply Chain-Initiative in Gang zu bringen und die Pipeline aufzubauen – und das verkürzt sich auf nur wenige Stunden. Also lösen wir nicht den Rückstand; die IT macht, was sie machen muss. Auch sie können von LLMs profitieren, allerdings sind deren Anwendungsfälle deutlich vielfältiger und schwieriger.
Also, mein Vorschlag ist nicht, dass LLMs der IT tatsächlich dabei helfen können, ihre Rückstände drastisch zu reduzieren. Es ist nur eine Möglichkeit für Lokad, in diesem speziellen Fall zu sagen: “Nun, anstatt dem Rückstand weitere 20 Tage hinzuzufügen, fügen wir stattdessen etwa vier Stunden hinzu und sind fertig.” So gehen wir mit dem Rückstand um. Und allgemeiner lautet die Lösung für diese jahrelangen Rückstände, dass jede einzelne Abteilung den Großteil der Softwarearbeit intern leisten muss. Sehen Sie, die jahrelangen Rückstände bedeuten, dass Unternehmen insgesamt zu viel von der IT verlangen. In jeder Abteilung – Marketing, Sales, Buchhaltung und so weiter – sollten digitale Praktiken vorhanden sein. Man sollte die IT nicht bitten, all diese Probleme für einen zu lösen. Stattdessen sollten in jedem Bereich digitale Experten vorhanden sein, um das zu erledigen. Und das ist genau der Kern dieses Memos von 2002 – wenn ich mich nicht irre – von Jeff Bezos an sein Team. Es ist ein sehr berühmtes Memo. Man kann “famous memo Bezos” eingeben, denn im Wesentlichen sagte er: “Ihr habt zwei Wochen Zeit, einen Plan vorzulegen, mit dem jede Abteilung in der Lage ist, all eure Daten offenzulegen, damit wir nicht diese Art von siloing und Machtspielen im Unternehmen, bei Amazon, haben.”
Und Bezos schloss mit den Worten: “Jeder einzelne Manager, der in zwei Wochen keinen Plan auf meinem Schreibtisch hat, wird gefeuert oder so ähnlich.”
Conor Doherty: Okay, nun danke. Dieser nächste Kommentar – und es ist eine Frage, die ich nicht gestellt habe, weil ich gesehen habe, dass sie in den Kommentaren erwähnt wurde, also ist sie als Kommentar formuliert, aber nehmen Sie sie als Frage – stammt von Jesse. “Ein Supply Chain Scientist plus ein LLM klingt dennoch wie ein Copilot. Also, grenzt bitte AI Pilot von Copilot ab.”
Joannes Vermorel: Der Grund, warum wir sagen, dass es ein Pilot ist, liegt darin, dass wir einige Kunden haben, bei denen über Wochen hinweg alle Entscheidungen generiert und dann unbeaufsichtigt ausgeführt wurden. Und wenn ich unbeaufsichtigt sage, meine ich es wirklich so. Während der Lockdowns 2020 hatten wir sogar ein Unternehmen, in dem 14 Monate lang alle Büroangestellten buchstäblich zu Hause blieben, nicht arbeiteten und vom Staat bezahlt wurden, weil der Staat in Europa Subventionen gewährte. Mehrere Staaten gewährten im Wesentlichen Subventionen, um zu Hause zu bleiben und nicht zu arbeiten. Und so war die Situation. Also hatten wir das, und wenn man eine supply chain hat, die über 14 Monate nahezu unbeaufsichtigt operiert, nenne ich das einen Pilot, nicht einen Copilot. Wenn niemand da ist, um die vom System generierten Zahlen zu überwachen, denke ich wirklich, dass es ein Pilot ist.
Aber damals haben wir kein LLM verwendet. Und es war eine Situation, in der die Daten sauber waren und es keinen dramatischen Bedarf gab, dieses Master Data Management zu verbessern. Und das war ein Kunde, der in Bezug auf EDI-Integration und dergleichen eine sehr hohe Reife aufwies. Daher waren die vor und nach dem Einsatz benötigten Maßnahmen sehr, sehr begrenzt. Jedenfalls zurück zur Frage des Copiloten. Die meisten Wettbewerber von Lokad behaupten, dass sie einen Copiloten anbieten. Und tatsächlich – und das ist etwas völlig Anderes – verwendet Lokad, der Supply Chain Scientist, eine Programmiersprache. Also, wenn wir ein LLM einsetzen, dann um Programmteile zu generieren, um uns bei der Erstellung von Programmstücken zu unterstützen. Dafür nutzen wir es. So wird das LLM im Wesentlichen dazu verwendet, Programmteile zu generieren, die beispielsweise SQL-Dialekte oder noch einige andere Dinge sein können. Und danach entwickeln wir den Pilot, und der Pilot läuft unbeaufsichtigt.
Also wird das LLM im Wesentlichen dazu verwendet, Elemente von Programmen zu generieren, die zum Beispiel SQL-Dialekte oder noch einige andere Dinge sein können. Danach entwickeln wir den Pilot, und der Pilot läuft unbeaufsichtigt.
Unsere Wettbewerber, besonders jene, die behaupten, sie würden konversationelle KI, konversationelle UI und Benutzeroberflächen auf den Markt bringen, machen etwas völlig anderes. Was sie typischerweise tun, ist Retrieval Augmented Generation (RAG). Das heißt, sie erstellen ein Prompt. Das ist buchstäblich alles, was unsere Wettbewerber, die derzeit in der supply chain AI tätig sind, machen: Sie erstellen, sagen wir, ein Dutzend Prompts, die zu verschiedenen scenarios passen. Danach fügen sie Daten aus der Datenbank hinzu, die grundlegende deskriptive Statistiken enthalten können. Sie würden also ein paar Dutzend Zahlen einfügen – etwa den durchschnittlichen Umsatz der letzten Woche, des letzten Monats, des letzten Jahres oder was auch immer –, also grundlegende Statistiken, die zum Szenario passen. Und dann fügen sie die zusätzliche Anfrage des Nutzers hinzu, woraufhin das LLM die Antwort vervollständigt.
Sehen Sie, auch hier geht es bei LLMs im Grunde nur um die Textergänzung. Man verfasst einen Text, und dieser wird ergänzt. Und bei Retrieval Augmented Generation besteht der Retrieval-Teil lediglich darin, einige Zahlen aus der Datenbank abzurufen und sie zusammenzustellen. Letztlich erhalten Sie zwar etwas, bei dem Sie eine Frage stellen können, aber die Realität ist, dass, wenn Sie nicht ahnungslos sind, Sie die Zahlen direkt vom Bildschirm ablesen können. Es gibt keinen Zauber. Das LLM sieht die Zahlen also genauso, wie Sie sie in Ihrem Bericht sehen. Grundsätzlich kann es nur Fragen beantworten, die unmittelbar von einem Dashboard beantwortet werden können.
Also ja, wenn Sie mit der Bedeutung jeder einzelnen Zahl nicht wirklich vertraut sind, kann es dies für Sie erläutern. Aber man kann auch – und genau hier macht Lokad es so – quasi einen Spickzettel haben, der zu jedem Dashboard die einzeilige Beschreibung zu jeder Zahl liefert, die dort auftaucht. Und das erfüllt effektiv exakt dieselbe Funktion, ganz ohne KI.
Also, zusammenfassend bin ich äußerst skeptisch gegenüber diesen konversationellen KIs, diesen Copiloten, da sie im Wesentlichen Spielereien sind, die über bestehende Systeme gelegt werden, welche niemals für irgendeine Art von Machine-Learning-System entwickelt wurden – nicht einmal für das klassische Machine Learning, geschweige denn für LLMs.
Deshalb sage ich, dass meines Wissens alle unsere Wettbewerber Copiloten einsetzen, bei denen es im Grunde einen Chatbot gibt, der über Dashboards liegt. Aber er automatisiert nichts. Er ermöglicht es nicht, irgendeinen AI Pilot zu automatisieren. Es ist also ein Gimmick, das auf einem Altsystem aufgesetzt wurde.
Conor Doherty: Okay, nun danke. Ich mache weiter. Dies ist von Kyle: “Können Sie bitte die Kritikalität der Prozessanalyse besprechen, bevor ein AI-Modell eingeführt wird?” Ich betrachte das im Kontext der supply chain.
Joannes Vermorel: So überraschend es sein mag, die Prozessanalyse ist sehr wichtig. Aber nicht unbedingt in der Art und Weise, wie viele Menschen meinen, dass es so sei. Die Realität ist, dass insbesondere in supply chains Unternehmen vier oder fünf Jahrzehnte Zeit hatten, um zahlreiche ausgedachte Prozesse zu erfinden. Und ich sage “ausgedacht” absichtlich. Supply chain ist ein Spiel der Bürokratie. Es hat einen bürokratischen Kern. Das Spiel der supply chain in den letzten fünf Jahrzehnten war ein Weg, die Arbeit zu organisieren, da man nicht eine einzige Person haben kann, die sich um alle SKUs, alle Lagerhäuser, alle Standorte, alle Produkte kümmert. Man muss das Problem also teilen und erobern, indem man die Arbeitsbelastung auf Dutzende, möglicherweise Hunderte von Mitarbeitern bei großen, sehr großen Unternehmen verteilt.
So landet man in einer Situation, in der 90% der Prozesse lediglich die auftretenden Komplikationen widerspiegeln, die daraus resultieren, dass die Arbeitslast auf viele Personen verteilt ist. Sehen Sie, es handelt sich um zufällige Prozesse und nicht um essentielle Prozesse. Daher würde ich sagen, ja – die Prozessanalyse ist notwendig, aber Vorsicht: 90% der bestehenden Prozesse adressieren nicht das grundlegende Problem, mit dem Ihre supply chain konfrontiert ist, sondern zufällige Probleme, die dadurch entstehen, dass viele Menschen benötigt werden, um die 10% des Problems zu lösen, die tatsächlich angegangen werden müssen.
In Industrien wie der chemischen Verarbeitung, wo es zahlreiche Ströme und Abhängigkeiten gibt, ist es sehr kompliziert. Zum Beispiel, wenn chemische Reaktionen stattfinden, entstehen Nebenprodukte. Wann immer Sie eine Verbindung herstellen, produzieren Sie etwas anderes. Dieses Etwas kann verkauft oder für einen anderen Prozess genutzt werden. All dies muss koordiniert werden. Es gibt Unmengen an Einschränkungen, Prozesse, die in Chargen ablaufen, und Prozesse, die kontinuierlich arbeiten. Es ist äußerst komplex.
Aber die Realität ist, dass sich die meisten Prozesse – anstatt sich auf die physische Basis des Problems zu konzentrieren, also darauf, dass man in einer Prozessindustrie chemische Reaktionen hat, die sehr spezifische Eingaben und Ausgaben besitzen und all das sehr, sehr klar definiert und bekannt ist – darauf konzentrieren, lediglich Prozesse rückzuentwickeln, die verschwinden, sobald Sie den AI Pilot einführen.
Das Interessante ist, dass, wenn man es im AI Pilot-Stil angeht, man diesen Divide-and-Conquer-Ansatz nicht mehr benötigt. Es ist ein einheitliches Set numerischer Rezepte, das das Problem von Anfang bis Ende löst. So sind all die Koordinationsprobleme, die zuvor durch zahlreiche Prozesse gelöst wurden, einfach verschwunden.
Meine Erfahrung zeigt, dass 90% dieser Prozesse einfach verschwunden sein werden, wenn wir fertig sind. Deshalb sage ich, dass es äußerst wichtig ist, einen starken Fokus auf die grundlegende physische Ebene Ihrer supply chain zu legen – und nicht auf die ausgedachten Prozesse, die lediglich dazu dienen, zahlreiche Teams zu koordinieren. Diese werden nicht aufgerüstet, sondern durch den AI Pilot ersetzt.
Conor Doherty: Danke. Und tatsächlich bietet ein Beispiel, das Sie in dieser Antwort genannt haben, einen schönen Übergang hierher. Also, an den Zuschauer Durvesh: Habt ihr Pläne, Envision für Bildungszwecke oder den Einsatz in kleinen Unternehmen als Open Source freizugeben? Und kann es so programmiert werden, dass es B2B-Unternehmen, etwa in der Chemiebranche, die umfangreiche manuelle Eingaben erfordern, zugutekommt?
Joannes Vermorel: Ja, wir haben Pläne, Envision irgendwann als Open Source freizugeben. Aber lassen Sie mich zuerst erklären, warum. In dieser Welt der Unternehmenssoftware haben wir eine öffentliche Dokumentation für Envision. Die meisten meiner Kollegen besitzen domänenspezifische Sprachen (DSLs), aber diese sind nicht öffentlich dokumentiert. Dassault Systèmes hat ein weiteres Unternehmen namens Quintiq aufgekauft. Damals kam es mit einer DSL, die nicht öffentlich dokumentiert wurde. Es gibt also buchstäblich in der supply chain-Branche andere Unternehmen, die DSLs besitzen, die aber nicht öffentlich zugänglich sind. Bei Lokad dokumentieren wir alles öffentlich und wir haben eine kostenlose Sandbox-Umgebung für Envision. Wir bieten sogar kostenlose Workshops an, mit denen Sie Envision anhand von Übungen lehren oder erlernen können. Also tun wir noch viel mehr.
Wenn es darum geht, eine Sprache Open Source freizugeben, gehört das zwar zum Plan, aber es ist noch zu früh. Warum? Weil Envision sich noch in einer rasanten Entwicklung befindet. Sehen Sie, eines der Probleme, wenn Sie einen Compiler Open Source machen, ist, dass der Compiler ein Softwareprogramm ist, das es Ihnen ermöglicht, Ihr Skript in etwas umzuwandeln, das ausgeführt werden kann. Sobald Sie Ihren Compiler als Open Source freigeben, bedeutet das, dass Menschen Envision-Code – im Fall von Lokad – in freier Wildbahn betreiben werden. Und Lokad verliert die Möglichkeit, diese Skripte automatisch zu aktualisieren. Die Realität ist, dass Lokad in den letzten zehn Jahren die Envision-Programmiersprache Hunderte Male modifiziert hat. Diese Sprache ist nicht stabil. Wenn Sie mein Buch betrachten, die Quantitative Supply Chain, das jetzt etwa sechs Jahre alt ist, hat sich die Syntax von Envision dramatisch weiterentwickelt. Man kann einen Blick auf veraltete Syntax werfen, die in Envision nicht mehr existiert.
Und wie gehen wir mit diesem ständigen Wandel der Syntax um? Nun, jede Woche bei Lokad veröffentlichen wir dienstags neue Releases, und was wir anwenden, sind automatisierte Umschreibungen für alle Envision-Skripte, die auf den Lokad-Plattformen betrieben werden. Es ist also eine der Schlüssel-Eigenschaften von Envision, dass es, würde ich sagen, eine sehr hohe Affinität zur statischen Analyse besitzt. Und statische Analyse ist übrigens ein Zweig des Sprachdesigns und der Sprach-Analyse. Wenn ich von Sprache spreche, meine ich die Computersprache, die es ermöglicht, Eigenschaften von Programmen zu ermitteln, ohne sie auszuführen. Und mithilfe statischer Analyse können wir buchstäblich ein bestehendes Skript automatisch von der alten in die neue Syntax umschreiben. Das erledigen wir automatisch am Dienstag. Und typischerweise, wenn wir ein Upgrade durchführen, gibt es für einige Tage sowohl die alte als auch die neue Syntax, die beide akzeptiert werden. Wir führen die automatisierten Umschreibungen durch und dann, wenn wir feststellen, dass die alte Syntax nicht mehr existiert, sperren wir mit einem Feature-Flag die Tatsache, dass nur noch die neue Syntax vorhanden ist.
Und bei Lokad haben wir bereits über 200 dieser automatisierten Umschreibungen implementiert. Normalerweise veröffentlichen wir jeden Dienstag, typischerweise haben wir etwa zwei Umschreibungen pro Monat, und das machen wir seit einem Jahrzehnt. Solange dieser Prozess andauert, können wir Envision realistisch gesehen nicht als Open Source freigeben. Es wird zu gegebener Zeit kommen, aber ich möchte den massiven Fehltritt von Python nicht wiederholen. Das Upgrade von Python 2 auf Python 3 hat der Python-Community ein Jahrzehnt gekostet und war unglaublich schmerzhaft. Unternehmen mussten jahrelange Upgrades hinnehmen – es war ein Albtraum, der ein Jahrzehnt andauerte. Das war wirklich, wirklich falsch. Sogar Microsoft benötigte mit dem Upgrade von C# im .NET Framework auf .NET Core ein halbes Jahrzehnt, und das war ein großes, großes Problem. Und das ist wiederum das Dilemma, dass, sobald ein Compiler als Open Source in der freien Wildbahn vorliegt, man keine Kontrolle über den Code hat. Wenn Sie Änderungen an der Sprache vornehmen möchten, müssen Sie mit Ihrer Community zusammenarbeiten. Das macht den Prozess super langsam, super schmerzhaft, und letztlich beseitigt man nie wirklich alle schlechten Eigenschaften der Sprache.
Wenn wir uns Python anschauen – beispielsweise, wie die objektorientierte Programmierung in Python eingeführt wurde, die Syntax, äh, sie ist umständlich. Man merkt wirklich, dass Python nicht mit objektorientierter Programmierung im Sinn entwickelt wurde. Es war eine spätere Ergänzung in den späten 90ern, und die Syntax ist irgendwie miserabel, und nun ist sie für immer da. Und übrigens, jede einzelne Sprache hat das. In C# gibt es beispielsweise das Schlüsselwort volatile, das keinen wirklichen Zweck mehr erfüllt. C++ ist für immer an die Mehrfachvererbung gebunden. Das war ein Fehler. Mehrfachvererbung war eine schlechte Designentscheidung, die alles verkompliziert, usw. Der einzige Weg, diese großen Fehler zu vermeiden – bei Lokad haben wir in der Gestaltung von Envision viele große Fehler gemacht, aber wir beheben sie nacheinander, und wir befinden uns immer noch im Prozess, insbesondere wenn neue Paradigmen auftauchen. Zum Beispiel war differentiable programming ein großes neues Paradigma, und wir mussten die Sprache selbst neu konzipieren, um diesem Paradigma gerecht zu werden.
Übrigens gibt es einen großen Mega-Vorschlag für Swift, von Apple vorgeschlagen, differentiable programming zu einem erstklassigen Bestandteil in Swift zu machen. Aber es wird wahrscheinlich nicht so bald geschehen. Es ist ein großes, großes Überarbeiten. Momentan ist die Sprache, die am ehesten differentiable programming als erstklassigen Bestandteil besitzt, Julia – und selbst dort wird viel mit Klebeband gearbeitet.
Conor Doherty: Nochmals vielen Dank. Es sind noch drei mehr zu bearbeiten. Die nächste kommt von Victor. Dieses handelt im Großen und Ganzen von KI. Wie geht KI mit zufälligen Engpässen um, wenn sie auf großen Datensätzen operiert, um plausible Szenarien oder wiederkehrende Probleme vorherzusagen?
Joannes Vermorel: Lassen Sie uns klarstellen, wenn wir von KI sprechen, handelt es sich um eine Sammlung von Techniken. Bei Lokad verwenden wir typischerweise LLMs, differentiable programming und stochastische Optimierung. Differentiable programming dient dem Lernen, stochastische Optimierung dazu, unter Unsicherheiten und unter Einschränkungen zu optimieren, das probabilistische Modell, das typischerweise mittels differentiable programming regressiert wird, und LLMs fungieren als universelle, rauschresistente Vorlagen-Engine.
Wenn Sie die supply chain mit probabilistischen Werkzeugen angehen, verschwinden die meisten der in dieser Frage angedeuteten Aufgaben. Das ist das Schöne an der probabilistischen Prognose – diese Vorhersagen sind nicht genauer, sie sind einfach wesentlich widerstandsfähiger gegenüber dem Umgebungsrauschen der supply chain. Wenn Sie probabilistische Prognosen mit stochastischer Optimierung koppeln, wird der Bedarf an manuellen Eingriffen weitgehend eliminiert. Und wenn ich „weitgehend“ sage, meine ich, dass es für die meisten Kunden vollständig entfällt. Nun bleiben Aufgaben übrig, bei denen es darum geht, durch Texte zu gehen und damit umzugehen – das sind die LLMs. Und nochmals, was ich beschreibe, ist Lokad: Wir haben diese AI Piloten, die wirklich automatisiert arbeiten, und wenn ein manueller Eingriff erforderlich ist, geschieht dies nicht etwa, um eine buchhalterische Eingabe im System vorzunehmen, sondern um eine strategische Überarbeitung des numerischen Rezepts einzugeben, was in der Regel eine tiefgreifende Änderung der Logik selbst darstellt, um die überarbeitete Strategie widerzuspiegeln. Es wird nicht, wissen Sie, eine kleine Sache sein. Es wird in der Regel etwas Fundamentales sein, das die Struktur der implementierten Logik ändert.
Conor Doherty: Diese Frage stammt von Ahsan. Könnten Sie bitte erklären, wie KI konkret eine Bestellung beschleunigen würde? Wäre sie in der Lage, Transaktionen im ERP-System anhand von Sprachbefehlen auszuführen?
Joannes Vermorel: Sprachbefehle sind nicht der richtige Ansatz für dieses Problem. Wenn Sie schnellere Dateneingaben wünschen, ist die Stimme ein sehr bandbreitenarmer Kanal. Man tippt schneller als man spricht, es sei denn, man ist sehr schlecht im Tippen. Das ist also nicht der Gewinn, den Sie erzielen können. Wenn Ihre Benutzeroberfläche korrekt mit einer Tastatur gestaltet ist, sind Sie schneller als mit Sprachbefehlen. Das weiß ich nur zu gut, denn vor 20 Jahren arbeitete ich bei AT&T Labs an der Spitze produktionsreifer Spracherkennungssysteme. Es gab zahlreiche Anwendungen, bei denen es nicht funktionierte. Die Spracherkennung funktionierte, aber in Wirklichkeit waren Ihre Hände auf der Tastatur einfach schneller. Die Situationen, in denen Sprache zum Einsatz kam, waren entweder schmutzige Hände oder beschäftigte Hände. Ansonsten ist die Tastatur einfach schneller.
Zurück zur Frage: Zuerst möchten Sie die Bestellungen filtern. Hier haben wir einen Entscheidungsprozess, bei dem Sie bestimmen wollen, welche Bestellungen beschleunigt werden müssen. Das ist klassisch Lokad, ein reiner, quantitativer Entscheidungsprozess. Sie müssen ja oder nein entscheiden, ob diese laufende Bestellung eine Beschleunigung des Prozesses rechtfertigt. Wir würden dies mit differentiable programming und stochastischer Optimierung angehen. So gelangen wir zu den richtigen Entscheidungen.
Sobald das vorliegt, haben wir automatisch täglich die Entscheidungen für die Bestellungen. Es geht nicht darum, jemanden zu haben, der dafür mündliche Anweisungen gibt. Es wird Teil des Satzes numerischer Rezepte sein, mit denen wir die optimierten Bestellungen berechnen. Mit der Zeit stellen wir fest, dass einige Bestellungen überschossen oder unterschritten wurden, und wir werden darum bitten, diese gegebenenfalls zu verschieben oder zu beschleunigen. Der Teil des LLM besteht lediglich darin, diese quantitative Entscheidung – bei der Sie so etwas wie eine binäre Markierung haben, die sagt “bitte beschleunigen” – zu nutzen, um eine E-Mail mit einem passenden Kontext zu generieren, die an den Lieferanten gesendet wird, etwa mit “bitte bestätigen, dass Sie es können”, und dann wird der Lieferant hoffentlich bestätigen und sagen “ja”, “nein”, “vielleicht kann ich” oder “das ist, was ich anbieten kann”.
Das LLM wird den Chat mit dem Lieferanten automatisieren. Die KI dient nicht dazu, darüber zu entscheiden, eine Bestellung zu beschleunigen. Das ist eine rein quantitative Entscheidung, die mit quantitativen Werkzeugen, differentiable programming und stochastischer Optimierung angegangen werden muss. Das LLM ist für die Interaktion mit dem Lieferanten da, der häufig einen unstrukturierten Kanal wie E-Mail nutzt.
Wenn Sie an Sprachbefehle denken, wird das nicht funktionieren. Es ist viel zu langsam. Ich hatte das Privileg, mit den Teams zusammenzuarbeiten, die vor 20 Jahren buchstäblich die ersten produktionsreifen Spracherkennungssysteme auf den Markt brachten. Aber die Quintessenz ist: Sie werden diese KI-Technologien dafür nicht nutzen. Sprachbefehle haben nicht die nötige Bandbreite, um das zu leisten, was Sie erreichen wollen.
Conor Doherty: In diesem Zusammenhang, wenn wir über stochastische Optimierung und differentiable programming sprechen, haben wir umfangreiche Videoressourcen zu diesen Themen. Wir gehen nicht darauf ein, da es sich um eine dreiteilige Serie handelt (Teil 1, Teil 2 und Teil 3) über differentiable programming, aber wir ignorieren diese nicht. Sie wurden behandelt und ich weise die Zuschauer, die mehr darüber erfahren möchten, freundlich darauf hin, sich diese anzusehen und dann diese Teile miteinander zu verknüpfen.
Letzte Frage, und sie stammt von Isaac. Als Kunde, der derzeit Envision lernt, interessiere ich mich für dessen Integrationsmöglichkeiten, insbesondere mit GitHub. Könnten Sie das Potenzial erörtern, dass Envision die GitHub-Integration unterstützt, insbesondere für Anwendungen wie das Erklären von Code-Blöcken in natürlicher Sprache oder das Identifizieren von Änderungen zwischen Versionen? Abschließend, gibt es Pläne, in naher Zukunft einen Envision Copilot einzuführen?
Joannes Vermorel: Kurz gesagt: Ja, ja und ja. Die Zeitpläne variieren erheblich, je nachdem, über welche Komponenten wir sprechen. Bei der Nutzung von LLMs, um im Wesentlichen einen Copiloten zu realisieren – ähnlich wie der GitHub Copilot, aber das wird der Lokad Copilot für Envision-Codes sein – arbeiten wir bereits daran. Das äußerst Interessante ist, dass es sich um eine DSL handelt, über die wir die Kontrolle haben, wir haben also vollständige Kontrolle über die Trainingsmaterialien. Das ist sehr cool, denn das bedeutet, dass an dem Tag, an dem es uns gelingt, dieses LLM in Produktion zu bringen, wann immer wir die Syntax ändern, wir unseren Trainingsprozess mit der aktualisierten Syntax neu starten und immer einen Copiloten haben, der Ihnen die aktuelle Envision-Syntax liefert. Im Gegensatz zum GitHub Copilot, der Ihnen eine Python-Syntax, eine C#-Syntax, eine Java-Syntax anbietet.
Wie Sie sehen, existiert Java seit 25 Jahren, Python seit mehr als 30 Jahren, C# seit etwa 22 Jahren oder so. Wenn Sie also den GitHub-Compiler bitten, Code für Sie zu schreiben, besteht das Problem darin, dass er Ihnen eine halbaktuelle Variante dieser Sprachen liefert, aber nicht wirklich den allerneuesten Stand. Und manchmal möchten Sie nicht die neueste Variante, weil Ihre Umgebung nicht mit diesen superaktuellen Versionen übereinstimmt, die Sie noch nicht unterstützen.
Wir arbeiten an einer ganzen Reihe von sehr innovativen Funktionen wie “Kommentiere meinen Code”, “Erkläre meinen Code”, “Vervollständige meinen Code”. Außerdem denken wir an viele erweiterte Code-Aktionen, die sehr spezifisch für die Arbeitsabläufe bei Lokad sind. Zum Beispiel arbeiten wir daran, die Erstellung von Datengesundheits-Dashboards zu automatisieren. Das ist eine sehr typische Aufgabe.
Datengesundheits-Dashboards sind im Wesentlichen Instrumente, die überprüfen, ob die Daten, die wir aufnehmen, stimmig sind. Und wir verfügen über reichlich Erfahrung und Know-how, was zu prüfen ist, denn die Art von Problemen, die man in den Daten von ERPs findet, ist in der Regel immer gleich. Wenn wir Daten aus einem ERP auf Korrektheit überprüfen, haben wir Supply Chain Scientists kultiviert – im wahrsten Sinne des Wortes, wir haben unsere eigenen Trainingsmethoden, um zu wissen, worauf man achten muss, und wir haben unsere eigenen Rezepte, also menschliche Rezepte, was ich implementieren sollte, was ich prüfen sollte, und wir könnten das weitgehend mit den LLMs automatisieren. Das ist also etwas, das bei Lokad in Arbeit ist.
Wir arbeiten an einem Lokad Copilot. Um Envision freundlicher zu GitHub zu machen, haben wir bereits ein open-source Visual Studio code extension veröffentlicht. Sie können bereits Envision-Code in ein git repository einbinden. Sie erstellen einfach eine .nvn-Datei, committen diese und fertig. Wenn Sie den Code mit schöner Syntaxhervorhebung bearbeiten möchten, benötigen Sie eine Visual Studio code extension. Wenn Sie nach der Lokad Visual Studio code extension für Envision suchen, gibt es eine, die komplett open source ist und Ihnen Syntaxhervorhebung bietet.
In Zukunft planen wir, den Envision-Code, der in einem Lokad-Konto gespeichert ist, als ein git repository bereitzustellen. Die Art und Weise, wie der Envision-Code in einem Lokad-Konto gespeichert ist, ähnelt im Wesentlichen einem git repository. Er wird im Wesentlichen auf dieselbe Weise versioniert. Er ist nicht exakt so organisiert wie git, aber ich werde nicht zu sehr auf die technischen Gründe eingehen. Git ist sehr sprachagnostisch. Wenn Sie sich ausschließlich mit einer bestimmten Sprache befassen, können Sie intelligenter vorgehen und allerlei Dinge tun, die im Allgemeinen nicht möglich sind. Aber letztlich ist der Envision-Code vollständig versioniert. Wir könnten ein git repository bereitstellen, das es Ihnen ermöglicht, Ihren gesamten Code aus einem Lokad-Konto in ein git repository zu exportieren und möglicherweise später auch umgekehrt, um eine zweiseitige Synchronisation zu ermöglichen. Git ist ein dezentrales System, bei dem jedes git repository wie das Ganze ist – Sie haben eine vollständige Kopie und können Änderungen von einem Remote-Repository abrufen, aber auch Ihre Änderungen an ein Remote-Repository senden. Und so werden wir irgendwann, vermutlich zunächst den Export und dann den Reimport einführen, aber das wird Zeit in Anspruch nehmen. Wir sind noch nicht so weit. Es ist Teil der Roadmap, aber wir haben noch keinen Zeitplan dafür.
Conor Doherty: Es sei darauf hingewiesen, dass einige Personen in den Kommentaren erwähnt haben, dass sie Envision erlernen. Wir produzieren eine Reihe von Tutorials, die in Zusammenarbeit mit der University of Toronto und einigen anderen in der Pipeline erstellt werden. Es gibt kostenlose Ressourcen, und wir können Antworten geben, wenn Menschen welche wünschen. Für alle, die lernen möchten, haben unsere Supply Chain Scientists viel Mühe in diese Workshops gesteckt. Diese sind kostenlos auf unserer Website verfügbar.
Joannes Vermorel: Für diejenigen, die nicht daran interessiert sind, selbst Supply Chain Scientists zu werden, kann Lokad den Supply Chain Scientist als Teil des AI Pilot-Angebots bereitstellen.
Conor Doherty: Das waren alle Fragen, Joannes. Vielen Dank für Ihre Zeit und vielen Dank fürs Zuschauen. Ich hoffe, es war hilfreich, und bis zum nächsten Mal.
