AI-Piloten in der Supply Chain - Ep 159

00:00:00 Einführung in das Interview
00:01:01 Auswirkungen von KI auf traditionelle Arbeitsplätze
00:04:36 KI-Automatisierung in der Supply Chain
00:09:08 Notwendigkeit eines einheitlichen Systems im Jahr 2012
00:10:30 Wiederherstellung von Entscheidungen in Systemen
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 anderen Anbietern
00:23:06 Diskussion über LLM-Halluzinationen und Konfabulationen
00:30:38 Betonung von Fortschritt statt Perfektion in der KI
00:33:00 Abrufen fehlender Informationen und Bestellung ETA
00:36:17 Quantitative Aufgaben und LLMs in der Supply Chain
00:38:28 Zukunft der AI-Piloten in der Supply Chain
00:41:18 Wert von Gesprächen und Automatisierung von Aufgaben mit geringem Wert
00:44:57 Nutzung von AI-Piloten zur Reduzierung von Rückständen
00:49:00 AI-Pilot vs. Copilot und Lockdown-Szenario
00:53:36 Skepsis gegenüber konversationsbasierter KI und Prozessanalyse
00:57:18 Verständnis der Geschäftsrealität und KI, die Prozesse ersetzt
01:00:12 Herausforderungen bei der Open Source-Bereitstellung von Envision
01:06:21 KIs Ansatz für Engpässe und die Supply Chain
01:09:17 Ineffizienz von verbalen Befehlen und Automatisierung von Bestellungen
01:14:12 Supply Chain Scientist als Copilot für AI-Piloten
01:17:32 Überprüfung der Datenkorrektheit und Automatisierung von Überprüfungen mit LLMs
01:20:15 Envision für Git zugänglich machen
01:21:14 Kostenlose Ressourcen zum Erlernen von Envision

Zusammenfassung

In einem Dialog zwischen dem CEO von Lokad, Joannes Vermorel, und dem Leiter der Kommunikation, Conor Doherty, diskutieren sie die Auswirkungen von KI auf das Supply Chain Management. Vermorel hebt die Fortschritte in der KI und den großen Sprachmodellen hervor, die die Automatisierung von Aufgaben revolutioniert haben. Er stellt AI-Piloten vor, ein Angebot von Lokad, das die automatisierte Entscheidungsfindung und administrative Aufgaben ermöglicht, unterstützt durch Lokads proprietäre Programmiersprache Envision. Vermorel diskutiert auch das Potenzial von KI, Aufgaben im Zusammenhang mit Masterdaten zu automatisieren und vergleicht Lokads Ansatz mit dem von Wettbewerbern. Er prognostiziert, dass AI-Piloten zur Norm im Supply Chain Management werden und zu erheblichen Produktivitätssteigerungen führen. Das Gespräch endet mit einer Fragerunde.

Erweiterte Zusammenfassung

In einem kürzlichen Gespräch zwischen Conor Doherty, dem Leiter der Kommunikation bei Lokad, und Joannes Vermorel, dem CEO und Gründer von Lokad, ging es um die transformative Rolle der künstlichen Intelligenz (KI) im Supply Chain Management. Die Diskussion, eine Fortsetzung eines vorherigen Gesprächs über die Auswirkungen von KI auf die Beschäftigung, konzentrierte sich auf das Potenzial von KI als eigenständiger Pilot für die Entscheidungsfindung in der Supply Chain.

Vermorel begann damit, die bahnbrechenden Fortschritte der generativen KI und der großen Sprachmodelle (LLMs) im Jahr 2023 hervorzuheben. Diese Fortschritte haben die Automatisierung von Aufgaben revolutioniert, die Texte betreffen, wie z.B. das Lesen von E-Mails oder die Kategorisierung von Beschwerden. Das Jahr 2023 war besonders bedeutend, da es zu einer erheblichen Reduzierung der Betriebskosten von Techniken zur natürlichen Sprachverarbeitung für Unternehmen führte. Vermorel prognostizierte, dass dies zur Automatisierung vieler interner Supportfunktionen führen würde, wobei die Supply Chain Operations an vorderster Front stehen.

Vermorel stellte dann AI-Piloten vor, ein Angebot von Lokad, das den Entscheidungsprozess automatisiert und banale administrative Aufgaben erledigt. Er betonte den einzigartigen Ansatz von Lokad, 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 Chains gewidmet ist. Vermorel gab jedoch zu, dass Lokad in der Vergangenheit Schwierigkeiten hatte, Daten zu finden und mit verschiedenen SQL-Dialekten umzugehen.

Die Einführung von GPT-4, erklärte Vermorel, hat für Lokad einen Durchbruch bedeutet, da das Unternehmen dadurch in der Lage ist, die Komposition von SQL-Abfragen zu automatisieren. Diese Abfragen können dann von einem Supply Chain Scientist Korrektur gelesen und getestet werden, um Genauigkeit sicherzustellen. Diese Entwicklung, zusammen mit einer sicheren Cloud-to-Cloud-Verbindung, ermöglicht es dem Team von Lokads Supply Chain Scientists, die Daten der Kunden eigenständig zu verfolgen und somit Verzögerungen zu reduzieren.

Vermorel hob auch das Potenzial von LLMs hervor, viele Aufgaben im Zusammenhang mit Masterdaten zu automatisieren, einschließlich Umfragen, Überwachung und Verbesserung. Er verglich Lokads Ansatz mit dem von Wettbewerbern und stellte fest, dass Lokad in der Regel weniger Personen in eine Initiative einbezieht, wobei jede Person Kompetenzen entlang der gesamten Pipeline hat. Dies sei ein deutlicher Unterschied zu Wettbewerbern, die oft viele weitere Personen in eine Initiative einbeziehen, darunter Projektmanager, Berater, UX-Designer, Datenbankadministratoren, Netzwerkspezialisten und Programmierer.

Das Gespräch wechselte dann zur Rolle der Supply Chain Scientists bei der Validierung oder Überwachung von von LLMs generierten Skripten. Vermorel erkannte an, dass LLMs manchmal ungenaue oder “halluzinierte” Ergebnisse liefern können, diese jedoch in der Regel in die richtige Richtung gehen und mit einigen Iterationen durch eine Feedbackschleife korrigiert werden können. Er schlug vor, dass LLMs zwar Fehler machen können, aber dennoch einen großen Mehrwert bieten können und ihre Rate an falsch positiven und falsch negativen Ergebnissen gemessen werden kann.

Vermorel erklärte weiterhin die tägliche Orchestrierung zwischen dem Supply Chain Scientist, dem AI-Piloten und dem Kunden. Der AI-Pilot, der vom Supply Chain Scientist erstellt wird, kümmert sich um den täglichen Betrieb der Supply Chain und verwaltet die Feinheiten der Datenbereitstellung und der Kaufentscheidungen. Der Kunde wird in diesem Setup mit dem Kapitän verglichen, der die allgemeine strategische Ausrichtung vorgibt.

Im Hinblick auf die Erkenntnisse für Supply Chain-Praktiker und Führungsteams prognostizierte Vermorel, dass AI-Piloten in der Supply Chain-Management (SCM) in einem Jahrzehnt zur Norm werden. Er glaubt, dass dies zu einer massiven Produktivitätssteigerung führen wird, mit einer potenziellen Reduzierung der Mitarbeiterzahl um 90% für frühere Funktionen. Er ermutigte Supply Chain-Praktiker, mehr Zeit für strategisches Denken und tiefgehende Gespräche mit Lieferanten und Kunden aufzuwenden.

Das Gespräch endete mit einer Fragerunde, in der Vermorel Fragen zu einer Reihe von Themen beantwortete, darunter die Rolle von AI-Piloten bei der Reduzierung von IT-Rückständen, der Unterschied zwischen einem AI-Piloten und einem Co-Piloten, die Bedeutung der Prozessanalyse vor der Implementierung eines AI-Modells, Lokads Pläne, Envision open source zu machen, und wie AI zufällige Engpässe angeht. Er bestätigte auch, dass Lokad an einem Lokad-Co-Piloten arbeitet und Pläne hat, Envision benutzerfreundlicher mit GitHub zu gestalten.

Vollständiges Transkript

Conor Doherty: Willkommen bei Lokad Live. Mein Name ist Conor. Ich bin der Leiter der Kommunikation hier bei Lokad. Und ich bin im Studio mit Lokads Gründer, Joannes Vermorel.

Das heutige Thema ist, wie KI als eigenständiger Pilot für die Entscheidungsfindung in der Supply Chain fungieren kann. Fühlen Sie sich frei, Ihre Fragen jederzeit im YouTube-Chat zu stellen, und wir werden sie in etwa 30-35 Minuten beantworten.

Und damit, Joannes, KI-Piloten in der Supply Chain, mir fällt auf, dass dieses Gespräch sehr stark eine Fortsetzung dessen ist, was wir vor etwa vier Wochen hatten, wo wir über die Auswirkungen von KI auf die Beschäftigung und die Zukunft traditioneller Jobs im Vergleich zu KI in der Supply Chain gesprochen haben.

Bevor wir auf die Details von KI-Piloten eingehen, könnten Sie für diejenigen, die das nicht gesehen haben, eine Auffrischung geben, nur eine Zusammenfassung, wie ist unsere Perspektive auf traditionelle Jobs im Vergleich zu KI in der Supply Chain?

Joannes Vermorel: Die Auffrischung ist, dass es im Jahr 2023 einen Meilenstein erreicht hat. Dieser Meilenstein ist generative KI und genauer gesagt große Sprachmodelle (LLMs). In Bezug auf reine Forschung ist es nur eine Fortsetzung von fast vier bis fünf Jahrzehnten kontinuierlicher Verbesserung im maschinellen Lernen. Wenn man das aus einer Forschungsperspektive betrachtet, ist 2023 nur ein Jahr wie die anderen mit einer langen Reihe von Fortschritten. Und in den letzten zwei Jahrzehnten hat es relativ schnell Fortschritte gegeben.

Nun, im Jahr 2023 kommt auf den Markt verpackte generative KI für Bilder und vor allem für Texte. Und es gibt ein Produkt, das das populär gemacht hat, es ist ChatGPT von OpenAI. Was bedeutet das? Das bedeutet ganz speziell, insbesondere bei diesen großen Sprachmodellen, dass Sie eine universelle, geräuschresistente Vorlagenmaschine haben.

Das bedeutet, dass alle Arten von Schritten für Unternehmenssoftware, ich spreche im Kontext von Arbeitnehmern wie Büroangestellten in Unternehmensumgebungen, das bedeutet, dass alle Arten von Schritten, die in der Vergangenheit nicht automatisiert werden konnten, weil wir mit Text in irgendeiner Form umgehen mussten, das bedeutet, eine E-Mail lesen, eine Referenz oder einen Preis aus einer E-Mail extrahieren oder eine Menge oder die Art der Beschwerde oder Anfrage eines Partners oder Lieferantenkunden aus einer E-Mail kategorisieren, feststellen, ob ein Produktetikett unsinnig ist, zum Beispiel wenn die Produktbeschreibung buchstäblich fehlt, okay, wir haben ein Problem, all diese Dinge konnten in der Vergangenheit nicht einfach erledigt werden. Sie konnten auf andere Weise erledigt werden, aber sie konnten nicht einfach automatisiert werden.

Wenn wir zum Beispiel fünf Jahre in die Vergangenheit zurückgehen müssten, war Text Mining bereits eine Sache. Es war bereits möglich, Textklassifikatoren zu haben und alle Arten von natürlichsprachlichen Verarbeitungstechniken zu verwenden, aber sie waren kostspielig. 2023 war ein Meilenstein, weil all diese Probleme aufgrund des erreichten Verpackungsgrads mit GPT-4, das im Wesentlichen über eine API bereitgestellt wurde, bedeuteten, dass alle diese NLP-Techniken, natürlichsprachlichen Verarbeitungstechniken, ihre Betriebskosten für Unternehmen um den Faktor 100, wenn nicht sogar 1.000, reduziert wurden. Das bedeutet nicht nur die Kosten, sondern auch die Art des Zeitrahmens, der benötigt wird, um die Sache einzurichten.

Die Quintessenz und das ist meine Vorhersage, ist, dass viele Supportfunktionen in Unternehmen, die nur interne Funktionen sind, die Daten eingeben und eine Ausgabe für andere Abteilungen produzieren, automatisiert werden. Die Supply Chain steht an vorderster Front, weil es sich nicht genau um eine kundenorientierte Funktion handelt. Es ist eine sehr interne Funktion, eine wichtige, aber interne Funktion. Und so waren die Fälle, in denen große Sprachmodelle der fehlende Baustein waren, um den Großteil der alltäglichen Abläufe in der Supply Chain weitgehend zu automatisieren.

Lokad automatisiert die quantitative Analyse und den quantitativen Entscheidungsprozess seit einem Jahrzehnt, aber es gibt viele alltägliche Abläufe, die davor kommen und viele alltägliche Abläufe, die danach kommen, und das ist derjenige, der dank großer Sprachmodelle automatisiert werden kann, und zwar schnell und kostengünstig.

Conor Doherty: Nun, vielen Dank. Und wir haben bereits ein Video, in dem wir, glaube ich, anderthalb Stunden zu diesem Thema gesprochen haben, daher werde ich heute nicht mehr darauf eingehen, aber das bildet den Rahmen für den Rest des Gesprächs. Ich lade alle herzlich ein, die mehr darüber erfahren möchten, das vorherige Video anzusehen. Nun, in diesem Zusammenhang, wie passen KI-Piloten in alles, was Sie gerade gesagt haben? Was sind sie? Was tun sie in der Realität?

Joannes Vermorel: KI wird im Allgemeinen seit den letzten zwei Jahrzehnten von Anbietern konsequent als Schlagwort und Oberbegriff verwendet, um das zu werfen, was sie hatten. Wenn ich also von KI-Piloten spreche, handelt es sich dabei sehr stark um ein Angebot von Lokad. Es ist eine Weiterentwicklung des Angebots, wahrscheinlich das größte, das wir seit Jahren hatten. Und worin besteht der Unterschied? Nun, der Unterschied besteht darin, dass ein KI-Pilot etwas ist, eine Softwarekomponente, was wir eine Reihe von numerischen Rezepten nennen, die nicht nur den Entscheidungsprozess ausführen, also den rein quantitativen Aspekt der Supply Chain, also buchstäblich herausfinden, wie viel bestellt werden soll, wo der Bestand zugeordnet werden soll, ob die Preise erhöht oder gesenkt werden müssen, wie genau die Produktion mit allen Schritten geplant werden soll, usw.

Das haben wir bereits gemacht, plus alles, was davor und danach in Bezug auf alltägliche bürokratische Aufgaben kommt, die größtenteils das Management von Stammdaten vor der Datenanalyse und dann die Ausführung der Entscheidung betreffen, die möglicherweise unstrukturierte Kanäle wie E-Mails umfasst, in denen Sie beispielsweise eine E-Mail an einen Lieferanten senden möchten, um etwas zu beschleunigen oder im Gegenteil eine Bestellung zu verschieben.

Und das Wesentliche dieses Angebots sind natürlich große Sprachmodelle, die Lokad nicht erfunden hat, die wir seit 14 Monaten intensiv nutzen, etwas mehr als das jetzt. Und der Schlüsselgedanke bei der Art und Weise, wie Lokad arbeitet, ist, dass ein Supply Chain Scientist in der Lage sein sollte, die volle Verantwortung für eine Initiative zu übernehmen.

Bei sehr großen Unternehmen können wir mehrere Personen für den Fall haben, aber im Gegensatz zu den meisten unserer Konkurrenten sind sie in der Regel nicht spezialisiert. Es ist also nicht so, dass wir ein Team von drei Personen mit Herrn Database, Herrn Algorithms und Herrn UI und UX User Experience haben. Das ist absolut nicht die Art und Weise, wie Lokad arbeitet. Ein Supply Chain Scientist ist in der Lage, alles von Anfang bis Ende zu tun.

Und das ist einer der Gründe, warum Lokad die Technologie so entwickelt hat, wie sie es getan hat, und wir haben unsere eigene Programmiersprache, eine domänenspezifische Programmiersprache namens Envision, die sich der prädiktiven Optimierung von Lieferketten widmet. Es mag sehr seltsam klingen, eine maßgeschneiderte Programmiersprache entwickelt zu haben, aber das Wesentliche ist, dass wir, und das ist eine Entscheidung, die ich 2012 getroffen habe, wirklich etwas Einheitliches brauchten, damit eine Person das Ganze von Anfang bis Ende erledigen konnte.

Bis vor ein paar Jahren bestand das wirklich darin, die Rohdaten aus den ERPs, CRMs, EDI und all diesen transaktionalen Systemen zu erhalten, diese mit einer Reihe von Tabellenkalkulationen für alle strukturierten Daten zu vervollständigen, die leider Teil der Schatten-IT anstelle der regulären IT sind, und dann die numerischen Entscheidungsrezepte zu erstellen. Und das war die Aufgabe des Supply Chain Scientists, all das zu tun, dann alle Instrumente einschließlich Dashboards und Berichte zu erstellen, um sich selbst davon zu überzeugen, dass die Zahlen korrekt waren, aber auch um unsere eigenen Kunden von der Gültigkeit dessen zu überzeugen, was wir tun, plus alle Instrumente zur Überwachung der Qualität der Entscheidungen im Laufe der Zeit, plus die Verbindung, um die Daten aus den Systemen herauszuholen, aber auch die Entscheidungen wieder in die Systeme einzuspeisen.

Das war der Umfang, den Lokad hatte, und es gab zwei Dinge, die wir nicht wirklich tun konnten. Erstens mussten wir die Empfänger der Daten sein, wir konnten nicht wirklich nach den Daten suchen. Und wenn ich von Suche spreche, konnte der Supply Chain Scientist die Daten anfordern, wir haben die IT-Abteilungen unserer eigenen Kunden nicht gebeten, irgendwelche ausgefallenen Transformationen durchzuführen, das war einfach nur das Dumpen der Tabellen, sozusagen, wissen Sie, select star from table, bam, das machen Sie einmal am Tag und Sie sind fertig. Also das waren einfach super einfache Extrakte, aber trotzdem war es größtenteils die IT-Abteilung unserer Kunden, die das gemacht hat.

Von den Supply Chain Scientists wurde nicht erwartet, dass sie in der Anwendungslandschaft unserer Kunden nach den Daten suchen, die die Initiative benötigte. Der Grund dafür war sehr einfach, es gibt etwa 20 SQL-Dialekte da draußen, also Oracle SQL, Microsoft SQL Server T-SQL-Dialekt, MySQL, PostgreSQL, DB2 von IBM usw. Es gibt also etwa 20 SQL-Dialekte. Bis vor ein paar Jahren hätte ein Supply Chain Scientist immense Schwierigkeiten gehabt, selbst wenn das, was diese Person erreichen wollte, äußerst einfach war, wie zum Beispiel nur eine einzelne Tabelle abzurufen. Das Problem war, dass diese Person buchstäblich Stunden damit verbracht hätte, online nach trivialen Abfragen zu suchen, und immer wenn es eine Fehlermeldung gab, wäre es wieder diese Person gewesen, auch wenn diese Person im Allgemeinen 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 ist das Problem mit ChatGPT gelöst. ChatGPT ist als Assistentprogrammierer nicht von Natur aus super geeignet, um komplexe Apps zu erstellen, aber wenn es darum geht, super einfache SQL-Abfragen in Dutzenden von Dialekten zu erstellen, ist es super schnell. Ein Supply Chain Scientist wird eine SQL-Abfrage anfordern, die erstellt werden soll. Diese Person ist auch intelligent und wird die Abfrage Korrektur lesen, um sicherzustellen, dass sie die Absicht widerspiegelt. Es geht nur darum, das Hindernis des Entdeckens der Syntax zu entfernen, aber sobald Sie die korrekte Syntax haben, die Ihnen präsentiert wird, ist es ziemlich selbsterklärend.

Wenn Sie es selbst ausprobieren möchten, fragen Sie ChatGPT einfach nach einer Anleitung, um git auf Ihrem Computer einzurichten und ein git-Repository einzurichten, oder was auch immer Sie sehen werden, welche Art von qualitativ hochwertiger Antwort Sie erhalten können.

Das ist wirklich ein Game Changer, denn das bedeutet, dass Lokad, das Supply Chain Scientists ausbildet, plötzlich die Verantwortung für die Datensuche übernehmen kann. Und ich weiß, dass wir durch ChatGPT die Werkzeuge haben, um sicherzustellen, dass wir uns nicht überfordern, indem wir sagen, dass wir nach den Daten suchen werden. Es ist ein Game Changer. Anstatt IT zu bitten, uns die Daten zu schicken, können wir einfach eine IP-Adresse auf die Whitelist setzen und dann eine sehr sichere Cloud-to-Cloud-Verbindung herstellen und das Team der Supply Chain Scientists ihre eigenen Daten verfolgen lassen.

Warum macht das einen so großen Unterschied? Nun, die Realität ist, dass selbst wenn Lokad nur Tage Arbeit für eine bestimmte Initiative benötigt, wir von vielleicht 10 bis 20 Tagen Arbeit für eine bedeutende Initiative sprechen, um die 20 bis 50 Tabellen zu erhalten, die wir benötigen. Es geht nur darum, die Tabelle abzurufen, ohne sie zu durchqueren, ohne Verknüpfungen, ohne ausgefallene Filterung, es ist sehr einfach. Das Problem ist jedoch, dass viele unserer Kunden ihre eigenen IT-Abteilungen haben, die riesige Rückstände haben. Ich meine buchstäblich Jahre an Rückständen, und wenn Sie drei Jahre Rückstand haben, selbst wenn Lokad nur 10 Tage verlangt, sind es 10 Tage plus drei Jahre Rückstand. Selbst wenn wir uns nicht genau am Ende der Warteschlange befinden, wenn wir uns nur in der Mitte der Warteschlange befinden, können diese 10 Tage Arbeit von der IT überall ein Jahr dauern, um erledigt zu werden. Und das war, würde ich sagen, eine Frustration, die wir hatten, dass die Mehrheit der Verzögerungen, die wir hatten, von der IT kam, die nicht inkompetent oder langsam war, sondern einfach so viel Rückstand hatte, dass es sehr schwierig für sie war, diese 10 Tage zuzuweisen.

Hier haben wir also etwas, bei dem wir anstelle von 10, 20 Tagen Arbeit von etwas sprechen, das vielleicht weniger als ein Tag Arbeit ist, etwas wie nur ein paar Stunden, um einen sehr sicheren, engen Zugriff auf die wenigen Systeme zu öffnen, die wir benötigen. Und dann werden die Supply Chain Scientists selbst die Tabelle überwachen, die Datenextraktionslogik einrichten und sicherstellen, dass die Datenextraktionen wirklich, würde ich sagen, leicht sind.

Die Art und Weise, wie wir das tun können, besteht in der Regel darin, die Leistung zu überwachen. Wenn die Leistung der Datenbank abfällt, bedeutet dies, dass auf der Datenbank viel los ist, und daher möchten Sie in der Regel den Druck verringern und Ihren eigenen Datenabrufprozess verzögern. Denn typischerweise müssen wir bei Lokad die Daten täglich aktualisieren, aber es ist nicht super dringend. Ich meine, es hängt wieder davon ab. Es gibt Situationen, in denen wir wirklich enge Zeitpläne haben, aber sehr häufig, was die Lieferketten betrifft, ist es kein Problem, den Abruf um 30 Minuten zu verzögern, nur weil es gerade eine Aktivitätsspitze in dieser Datenbank gibt.

Der erste Block der Verpflichtung besteht darin, die Daten selbst zu verfolgen und damit die Hauptursache für Verzögerungen zu beseitigen und die Initiativen erheblich zu beschleunigen. Nochmals, diese Verzögerungen wurden sehr häufig zum Hauptteil der Verzögerung für die gesamte Lokad-Initiative, um in die Produktion zu gehen, indem sie auf IT warteten, um diese Tage zu zuweisen.

Der zweite Block der Verpflichtung ist die Verbesserung der Stammdaten. Und auch hier, in der Vergangenheit, wenn Sie vor einem Katalog stehen, in dem sich zum Beispiel 100.000 Produktbeschreibungen befinden, von denen einige Müll sind, wissen Sie vielleicht, 1%. Es ist viel Arbeit, diese 100.000 Referenzen durchzugehen, die Beschreibungen oder Produktbezeichnungen zu identifizieren, die falsch sind, oder manchmal kann es nur ein Preis sein, der völlig inkonsistent mit der Beschreibung ist. Wenn es heißt, eine Schraube und der Preis beträgt 20.000 Dollar, ist es wahrscheinlich nicht nur eine Schraube, es ist wahrscheinlich etwas anderes, usw. Es gab viele grundlegende Plausibilitätsprüfungen, bei denen es offensichtlich und einfach erscheint, aber es war sehr schwierig, das zu automatisieren, und es gab häufig keine andere Möglichkeit, als eine Person die Einträge zu überprüfen, um nach wirklich schlechten Dingen zu suchen.

Mit einem LLM und möglicherweise einem LLM, der auch Bilder verarbeiten kann, können Sie viele Dinge tun, wenn es darum geht, alles zu überwachen, zu überwachen und zu verbessern, was mit Stammdaten zusammenhängt. Im speziellen Fall von Lokad ist der Teil der Stammdaten erforderlich, um die Supply Chains zu steuern.

Conor Doherty: Nun, da gibt es viel, danke. Ich habe viele Fragen, auf die ich eingehen möchte. Ich werde einen kleinen Schritt zurückgehen, denn wenn ich das alles zusammenfassen kann, beschreiben Sie, und korrigieren Sie mich, wenn ich falsch liege, einen Supply Chain Scientist mit Zugang zu einem guten LLM, mit dem eine enorme Menge Arbeit erledigt werden kann. Arbeit, die bis zu diesem Moment viel Zeit in Anspruch genommen und viele Menschen involviert hätte. Nun, in einem nicht-Lokad-ähnlichen Setup, wie viele weitere Personen wären involviert? Wie viele weitere Finger im Spiel wären da? Und dann können Sie über die Effizienz sprechen, aber nur in Bezug auf die Anzahl der Mitarbeiter, was ist der Unterschied zwischen Supply Chain Scientists mit LLM und zum Beispiel S&OP?

Joannes Vermorel: Unsere Kunden sind in der Regel erstaunt darüber, dass selbst eine große Initiative nur aus zwei oder drei Personen besteht, und immer die gleichen. Wir haben Lokad, und ich bin sehr stolz darauf, dass Lokad als Arbeitgeber es schafft, die Leute eine ganze Weile zu halten. Also, das Fazit ist, dass Lokad in der Regel zu 1% von Anfang bis Ende ist. Wenn wir mehrere Personen haben, dann nur, um Redundanz zu haben. An einem Tag konzentrieren Sie sich auf diesen Teil der Pipeline und ich mache diesen anderen Teil der Pipeline, und am nächsten Tag wechseln wir. Es ist nicht so, dass die Leute sich nicht spezialisieren, jede Person hat eine Kompetenz in der gesamten Pipeline. Es gibt einige Variationen und einige Leute haben eine besondere Spezialität, aber trotzdem können die Menschen wirklich gegeneinander austauschbar sein.

Unsere Wettbewerber sind da ganz anders. Selbst eine kleine Initiative umfasst buchstäblich ein halbes Dutzend Personen. Sie haben den Projektmanager, der nur da ist, um die anderen Jungs zu koordinieren, dann haben Sie den Berater, den UX-Designer, den Konfigurator, den Datenbankadministrator, den Netzwerkspezialisten und möglicherweise einen Programmierer, einen Softwareingenieur für die nicht nativen Anpassungen. Nochmals, Lokad ist eine programmatische Plattform, die meisten unserer Wettbewerber haben keine programmatische Plattform. Also, wann immer Sie etwas haben möchten, das programmatisches Verhalten hat, müssen Sie einen vollwertigen Softwareingenieur haben, der mit einer allgemeinen Programmiersprache wie Java oder Python die fehlenden Teile implementiert. Also, Lokad ist wirklich nicht so. Ich würde sagen, unsere Wettbewerber, in der Regel von vornherein, sind es ein Dutzend. S&OP-Initiativen können mehrere Dutzend Menschen umfassen, aber es sind nicht unbedingt viele verschiedene Fähigkeiten, es sind meistens verschiedene Personen aus verschiedenen Abteilungen und sehr häufig ist es nicht sehr IT-getrieben.

Also, Lokad wäre, wenn ich sage eine Person gegen ein Dutzend, vergleiche ich das mit unseren Wettbewerbern, die APS, erweiterte Planungssysteme oder Bestandsoptimierungssysteme verkaufen, diese Art von Unternehmenssoftware.

Conor Doherty: Danke. Und um auf einen anderen Punkt zurückzukommen, den Sie am Anfang erwähnt haben, als Sie über Supply Chain Scientists gesprochen haben, haben Sie das Beispiel verschiedener SQL-Dialekte gegeben und dann den Supply Chain Scientist, der möglicherweise nicht fließend in diesem spezifischen Client-Dialekt ist, würde die Skripte validieren oder überwachen, die automatisch generiert wurden, weil LLMs gelegentlich Halluzinationen haben.

Nun, zu diesem Punkt hinzu, LLMs halluzinieren sehr oft. Nun, es verbessert sich, aber Sie können einen LLM mit einem Textstück fragen: “Finde dieses versteckte Wort, kannst du es sehen?” und er wird ja sagen, nun, es ist nicht da. Ich weiß, es ist nicht da, du weißt, es ist nicht da. Wie können Sie also bei der Nutzung von LLMs in automatisierter Weise Sicherheit und Qualitätskontrolle in großem Maßstab gewährleisten und überwachen?

Joannes Vermorel: Halluzinationen oder Konfabulationen, wie ich sie lieber nenne, treten wirklich auf, wenn Sie den LLM als Wissensbasis für alles verwenden. Wenn Sie LLMs wie eine Wissensbasis für alles verwenden, dann passiert das. Wenn Sie nach medizinischen Papieren fragen und sagen: “Geben Sie mir eine Liste von Papieren zu dieser Pathologie”, wird es Ihnen etwas geben, das in die richtige Richtung geht. Die Autoren existieren häufig, sie haben veröffentlicht, sie haben Dinge, die in diesem Bereich waren, sie haben veröffentlichte Papiere, die in die gleiche Richtung gehen, aber nicht ganz. Das ist wieder so, als ob Sie einen Wissenschaftler bitten würden, sich Dinge aus dem Stegreif zu merken.

Es ist sehr schwierig, würden Sie sagen, und wenn Sie sagen, dass Sie es tun müssen, würden sie wahrscheinlich etwas vorbringen, das halbwegs plausibel ist, mit korrekten Namen von Kollegen oder Forschern, korrekten halbkorrekten Titeln, das sind die Arten von Dingen. Das ist also eine Situation, in der Sie Konfabulationen bekommen, aber Sie betteln gewissermaßen darum. Ich meine, Sie bitten LLMs, sich wie eine Datenbank für alles zu verhalten, also ist es sehr schwierig, Sie werden dieses Problem haben.

Das Gleiche gilt für die SQL-Dialekte, Sie versuchen es und Sie bekommen etwas, das ungefähr richtig ist. Wenn Sie zum Beispiel sagen: “Ich möchte eine Tabelle lesen”, wird es ein “select star from table” machen und so weiter. Es wird Ihnen nicht, wenn Sie zum Beispiel mit GPT-4 fragen, eine Tabelle zu lesen, “drop table” geben. Es kann Ihnen eine Syntax geben, die etwas unzureichend ist, also testen Sie Ihre SQL-Abfrage und Sie erhalten eine Fehlermeldung und Sie machen eine kleine Anpassung und es funktioniert. Aber sehen Sie, es ist immer noch in die richtige Richtung. Wenn Sie die Datenbank lesen möchten, wird es keinen Befehl erzeugen, der eine Tabelle löscht oder die Berechtigungsraten der Datenbank ändert.

Das Gleiche gilt, wenn Sie nach erfundenem Wissen fragen. Wenn Sie zum Beispiel fragen: “Okay, ich habe einen industriellen Kompressor mit 20 Kilowatt Leistung, wie hoch ist der Preis dafür?” Wenn Sie GPT fragen, sagt es wahrscheinlich etwas wie 10.000 $. Es schätzt etwas ab. Das ist buchstäblich erfunden. Es ist plausibel, aber ist es korrekt? Wahrscheinlich nicht, und es hängt von Hunderten von Varianten ab, weil es so viele verschiedene Kompressoren für verschiedene Situationen gibt.

Die Quintessenz ist, dass Konfabulationen nicht zufällig auftreten. Es gibt wirklich spezifische Arten von Aufgaben, bei denen sie viel häufiger auftreten. Also würde ich sagen, wenn Sie darum bitten, wenn Sie den LLM wie eine Datenbank für alles verwenden, dann ist es besser, doppelt zu überprüfen. Es kann äußerst nützlich sein, es gibt Ihnen zum Beispiel für die SQL-Dialekte einen Hinweis auf die Art von Schlüsselwörtern, die Sie verwenden sollten, wie die Syntax aussieht, und es kann einen kleinen Fehler machen, ein Komma vergessen oder so etwas, aber mit ein paar Iterationen werden Sie es richtig machen. Besonders, weil Sie, sobald Sie die SQL-Abfrage haben, sie tatsächlich auf der Datenbank testen können, Sie werden die Ausgabe sehen und validieren, also haben Sie eine sofortige Rückkopplung, um das zu validieren.

Wenn Sie beispielsweise ungewöhnliche Produktetiketten erkennen möchten, Produktetiketten, die verdächtig aussehen, wie diese Produktbeschreibung fehlt, das ist Ihr Produktetikett, okay, das ist offensichtlich falsch. Aber Sie können alle Arten von Fehlern haben. Zum Beispiel können Sie ein Produktetikett haben, das “tournevis cruciforme” sagt, es ist auf Französisch und das Problem ist, dass es nur auf Französisch ist, es ist ein Schraubendreher mit einem Phillips-Kopf, glaube ich. Und wiederum können Sie nach Dingen fragen, aber irgendwann ist es nicht perfekt, es ist eine Entscheidungssache. Ein Mensch würde genauso einen Fehler machen, also können Sie nicht erwarten, dass der LLM ein Orakel ist, das in der Lage ist, jede Frage richtig zu beantworten. Irgendwann, wenn Sie eine Aufgabe wie die Überprüfung der 100.000 Produkte Ihres Katalogs auf Anomalien in den Etiketten durchführen, wird der LLM falsch positive und falsch negative Ergebnisse haben, genauso wie ein Mensch. Aber das Interessante ist, dass Sie tatsächlich die Rate der falsch positiven und falsch negativen Ergebnisse messen können und dann entscheiden können, ob es sich lohnt oder nicht. Und sehr oft bekommen Sie etwas, das ziemlich gut ist, etwas, das Ihnen einen großen Mehrwert bietet, auch wenn es immer noch einige Fehler macht.

Conor Doherty: Fortschritt, nicht Perfektion.

Joannes Vermorel: Genau. Wenn Sie Ihre Probleme mit den Stammdaten um 90% reduzieren können, indem Sie etwas verwenden, das sehr günstig ist und innerhalb von buchstäblich Stunden unbeaufsichtigt wieder ausgeführt werden kann, ist das sehr gut.

Conor Doherty: Es gibt auch den Wert der Zeit, die nicht damit verbracht wurde, dies manuell zu tun, sondern stattdessen etwas anderes zu tun, das Wert generiert oder hinzufügt. Also gibt es direkte und indirekte Treiber für den Wert.

Joannes Vermorel: Außerdem ist die Realität die, dass wenn Sie eine super repetitive Aufgabe eine Stunde lang machen, können Sie ein bestimmtes Qualitätsniveau erreichen. Wenn Sie das jedoch 100 Stunden lang machen, die Stunde 67, meine ich, Menschen sind typischerweise keine konstanten Leistungsmaschinen. Nach ein paar Stunden würde die Konzentration nachlassen und die Anzahl der falsch positiven und falsch negativen Ergebnisse würde wahrscheinlich sprunghaft ansteigen, selbst bei einem ziemlich gewissenhaften Mitarbeiter.

Conor Doherty: Danke. Und ich möchte daran denken, dass wir tatsächlich einige Fragen aus dem Publikum haben, die sich mit Dingen befassen, die ich fragen wollte, also werde ich einige Dinge überspringen, aber sie werden in den Fragen des Publikums behandelt. Aber ein letzter Gedanke hier, wenn Sie über die Supply Chain Scientists, den AI Pilot und wir werden später in den Fragen darauf zurückkommen, aber die Supply Chain Scientists, ein AI Pilot und der Kunde, wie funktioniert diese Orchestrierung tatsächlich im täglichen Betrieb? Hat der Kunde Zugang, interagiert er mit dem LLM?

Joannes Vermorel: Typischerweise sehen wir es so, dass alle numerischen Rezepte, die von Supply Chain Scientists zusammengestellt werden, der AI Pilot sind. Das ist das Ding, das die Supply Chain täglich steuert. Es läuft unbeaufsichtigt und generiert die Entscheidungen. Mit LLMs werden jedoch die Feinheiten der Datenvorbereitung und der PO-Entscheidungen behandelt. Zum Beispiel wäre die Vorentschiedung, Lieferanten nach ihren MQS zu fragen. Sie müssen diese Informationen abrufen, sie fehlen oder sind nicht auf dem neuesten Stand, Sie müssen das ändern. LLMs können Ihnen dabei helfen. Die Nachentscheidung wäre das Senden einer E-Mail, um nach einer ETA (geschätzte Ankunftszeit) für Bestellungen zu fragen, wenn Sie kein EDI haben oder wenn Sie keine Brücke haben, oder um eine Bestellung zu beschleunigen oder zu verschieben. Das sind die Art von Feinheiten, die danach kommen, bei denen Lokad die Entscheidung generieren kann, eine Bestellung zu beschleunigen, aber nicht die Feinheiten erledigen kann, die darin bestehen, eine E-Mail zu verfassen und zu senden.

All das ist im Wesentlichen der AI Pilot und das ist das große numerische Rezept, das den Prozess von Anfang bis Ende durchführt. All das wird vom Supply Chain Scientist implementiert. Das ist also eine Erweiterung des Aufgabenbereichs für Lokad. Der Supply Chain Scientist ist eigentlich der Co-Pilot. Und denken Sie wirklich daran, wenn ich Pilot sage, meine ich wirklich einen automatisierten Piloten in einem Flugzeug. Und übrigens, heutzutage werden die schwierigsten Manöver in Flugzeugen mit Autopilot durchgeführt. Wenn Sie sehr beängstigende Flughäfen haben, wie den alten Flughafen von Hongkong, mit einem neuen, der viel einfacher ist, aber sie haben einen, der buchstäblich mitten in Hochhäusern liegt, dann ist der Autopilot für diese Manöver obligatorisch. Also wird es gemacht, es ist die Maschine den ganzen Weg, die Leute überwachen nur.

Also hier ist der Supply Chain Scientist, der die numerischen Rezepte entwickelt und sie sind der Co-Pilot. Sie entscheiden, sie navigieren im Wesentlichen, um die Dinge zu lenken, und dann entwickeln sie den Plan und den Kursplan für den Piloten. Aber grundsätzlich spielt der Supply Chain Scientist die Rolle des Co-Piloten, er denkt voraus und stellt sicher, dass der Pilot so reibungslos wie möglich arbeiten kann. Aber grundsätzlich ist der Pilot, nicht der Co-Pilot, für alle hochfrequenten Anpassungen verantwortlich. Und dann wäre der Kunde die Rolle des Kapitäns.

Sie wissen schon, ein bisschen wie in der alten Fernsehserie Star Trek, wo der Kapitän auf dem Stuhl sitzt und den Crewmitgliedern hochrangige Anweisungen gibt. Also gibt der Kunde in diesem Setup die Strategie und die allgemeine Richtung vor. Dann ist es die Aufgabe des Supply Chain Scientists, das umzusetzen, und die Aufgabe des Piloten besteht darin, alle Mikroanpassungen vorzunehmen, die für die Lieferkette erforderlich sind, und dann die Lieferkette selbst auszuführen.

Conor Doherty: Und das ist auch, um es noch einmal klarzustellen, zusätzlich zu all den automatisierten quantitativen Aufgaben, die bereits erledigt werden. Sie werden seit Jahren erledigt. Also für den Fall, dass jemand zuhört und denkt: “Oh, das sind nur die qualitativen Aufgaben”, wir sprechen von Anfang bis Ende. Ja, quantitativ, wie die Faktorisierung von wirtschaftlichen Treibern, die Generierung von Zuweisungen, Einkäufen, Preisgestaltung, das ist auch bereits KI-gesteuert und automatisiert.

Der Supply Chain Scientist überwacht also beide Arten von Konsolen, die quantitativen und die qualitativen.

Joannes Vermorel: Genau. Und der Grund, warum Lokad dieses AI-Schlüsselwort schließlich übernommen hat, das ist ein Oberbegriff, war, weil wir jetzt LLMs hinzufügen, wir hatten bereits maschinelles Lernen mit differenzierbarer Programmierung und stochastischer Optimierung, aber jetzt fügen wir LLMs hinzu. Und das ist also buchstäblich ein sehr umfassendes Toolkit.

Der Effekt ist buchstäblich, dass Lieferketten für Wochen unbeaufsichtigt laufen können. Die Leute sind überrascht, wie lange man mit diesen wirtschaftlichen Treibern tatsächlich vollständig unbeaufsichtigt arbeiten kann. Das Schöne daran ist, dass Sie keine Art von Mikroanpassungen vornehmen müssen. Zum Beispiel sind Anpassungen an die Prognose für die meisten unserer Kunden vollständig nicht vorhanden. Und die meisten anderen Anpassungen werden ebenfalls vollständig automatisch durchgeführt, wie die Einführung von neuen Produkten, die Ausphasung von alten Produkten, die Einführung neuer Lieferanten und die Ausphasung von nicht leistungsfähigen Lieferanten.

All das ist sozusagen Business as usual, und wenn die Rezepte richtig gemacht sind, erfordern sie bereits in der Vergangenheit nicht viele Eingriffe. Aber mit diesem KI-Piloten, der LLMs umfasst, kann die Hinzufügung eines neuen Lieferanten in den Mix, all diese Dinge können noch weniger manuelle Eingriffe erfordern als zuvor.

Conor Doherty: Okay, Joannes, danke. Wir sind jetzt etwa 40 Minuten dabei. Es gibt Fragen, auf die wir eingehen müssen, also werde ich uns jetzt darauf zusteuern. Aber bevor wir das tun, als eine Art Zusammenfassung oder abschließender Gedanke, wieder im Kontext des viel größeren Gesprächs, das wir vor einem Monat hatten und das wir heute haben, 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 Handlungsaufruf oder das Mitnahme für sie?

Joannes Vermorel: Ich glaube, dass diese Vision von KI-Piloten in etwa einem Jahrzehnt der Normalfall sein wird, vielleicht unter einem anderen Namen. Vielleicht wird es der Normalfall sein und die Leute werden einfach “Supply Chain” sagen und nicht “KI-Piloten für die Supply Chain”. Und es wird sozusagen offensichtlich sein, dass die Supply Chain diese KI-Piloten hat. Genauso wie man bei einem Computer nicht sagt, dass man eine CPU hat, dass man Speicher hat, es ist selbstverständlich, dass man eine CPU in seinem Computer hat, also erwähnt man das nicht einmal.

Meine Meinung ist, dass solche Funktionen in etwa einem Jahrzehnt umfassend automatisiert sein werden und Lokad, mit diesen KI-Piloten, ein Paketangebot ist, das dies einfach mit einem Supply Chain Scientist umsetzt. Für unsere Kunden bedeutet dies, dass sich die Supply-Chain-Praxis in ihrer Natur ändert. Es bedeutet, dass sie diese KI-Piloten haben, die viel Bandbreite freisetzen können. Und wir haben bereits die Bandbreite für den Entscheidungsprozess oder die komplexe Berechnung freigesetzt. Aber jetzt befreien wir auch die Zeit, die für die Überwachung der Liste der SKUs, der Liste der Lieferanten, der Liste der Kunden aufgewendet wurde, um die Stammdaten korrekt, sauber und vernünftig zu halten. All das verschwindet auch und beseitigt die Notwendigkeit für manuelle Eingriffe, die sehr häufig nicht einmal wirklich quantitativer Natur waren. Man musste ein Etikett reparieren, einen Eintrag reparieren, ein Duplikat entfernen oder so etwas. All das, wiederum, wird von Lokad erledigt.

Das Fazit ist also, dass es eine massive Produktivitätssteigerung ist. Ich denke, dass wir mit einigen Kunden buchstäblich diese 90%ige Reduzierung bei den Kopfzahlen für die wiederkehrenden Aufgaben erreichen. Die Realität ist, dass Sie jetzt mehr Zeit haben und tatsächlich das tun können, was viel schwieriger zu automatisieren ist, und ich glaube, dass das mehr Wert schafft. Das bedeutet, dass Sie sorgfältig über die Strategie nachdenken, viel mehr Zeit damit verbringen, über die Optionen nachzudenken, was Sie erkunden sollten, anstatt Ihre Zeit wieder auf Tabellenkalkulationen zu verschwenden.

Denken Sie also viel und intensiv über die schwierigen Probleme nach und sprechen Sie dann mit Lieferanten und Kunden und führen Sie echte, tiefgehende Gespräche, damit Sie Ihre eigene Supply Chain organisieren können, um Ihren Lieferanten zufrieden zu stellen und sie bereit sind, Ihnen bessere Preise zu geben, Sie werden eine bessere Qualität, bessere Zuverlässigkeit usw. haben. Wenn Sie sich so organisieren, dass Sie den Bedürfnissen Ihrer Lieferanten gerecht werden, mag es ein wenig anders klingen, wo man sagt: “Oh Lieferanten, ich bin der Kunde, sie müssen sich mir anpassen.” Aber wenn Sie Ihre Lieferanten besser unterstützen können, ist es eine Teamarbeit und Sie können mehr Zuverlässigkeit und bessere Preise haben.

Und Sie können den gleichen Aufwand auch mit Ihrem Kunden betreiben, denn auch hier sollte eine Zusammenarbeit stattfinden. Und auch hier bedarf es vieler intelligenter Diskussionen, die über das hinausgehen, was diese LLMs heutzutage leisten können. Ich glaube, dass Lokad in der Lage ist, die Aufgaben zu automatisieren, die wir mögen, die von geringem Wert sind und banale Verwaltungsaufgaben, und dass wir Menschen die hochrangigen, halbstrategischen Aufgaben erledigen lassen können. Ich sage halbstrategisch, weil Sie sich mit einem Kunden nach dem anderen unterhalten und dann die Strategie entwickeln, die alles zusammenfasst, eine Vision erstellt und dann die Supply Chain-Führung unterstützt, damit sie eine sehr klare, fundierte Strategie für ihr Unternehmen haben.

Conor Doherty: Um das noch einmal anhand von zwei Beispielen zu verdeutlichen: Die Entscheidungen auf niedriger Ebene, bei denen man eine Excel-Tabelle durchgeht und sagt: “Oh, es steht in Farben, dass es schwarz sein muss”, und das dann korrigiert, sind trivial, banal und nicht Ihre Zeit wert. “Sollte ich ein Lager in Hamburg eröffnen?” Das ist strategisch.

Joannes Vermorel: Ja, das ist strategisch. Das Problem ist auch, dass es so viele Optionen gibt. Man könnte sagen, ein Lager, sollte ich kaufen, sollte ich mieten, welche Art von Verträgen, welcher Grad der Mechanisierung, brauche ich einen Vertrag für die Ausrüstung, damit ich sie zurückgeben kann, sollte ich die Ausrüstung leasen oder nicht. Ich meine, es gibt hunderte von Fragen und sehr oft haben all diese Fragen, wenn die Leute 99% ihrer geistigen Kapazität für Verwaltungsaufgaben aufwenden müssen, keine Zeit mehr für diese großen Fragen.

Sehen Sie, wenn ich das Parkinson’sche Gesetz anwenden würde, würden die Leute sagen, ich habe viele Unternehmen gesehen, bei denen, wenn ich die Gesamtsumme der Minuten berechnen würde, die für so etwas wie ABC-Klassen aufgewendet wurden, jedes Jahr von Menschenjahren die Rede wäre. Und wenn es darum geht, über ein neues Lager zu entscheiden, sprechen wir von Wochen. Aber sehen Sie das Ungleichgewicht, bei dem Menschen buchstäblich Jahre ihrer Zeit für etwas völlig Unsinniges wie ABC-Klassen aufwenden. Und wenn es darum geht, eine Investition von 50 Millionen Euro für die Eröffnung eines Lagers zu tätigen, dauert es buchstäblich Wochen und dann wird eine Entscheidung getroffen. Sehen Sie, es sollte andersherum sein.

Conor Doherty: Gut, vielen Dank dafür. Damit werde ich zu den Fragen aus dem Publikum übergehen. Vielen Dank. Sie können sie bis zum Ende einreichen. Also, Joannes, das kommt von Massimo. Könnten Sie bitte näher erläutern, wie IT KI-Piloten nutzen kann, um den Rückstand abzubauen, und warum Sie glauben, dass dieser Ansatz vorgeschlagen werden sollte?

Joannes Vermorel: KI-Piloten sollen nicht dazu dienen, den Rückstand der IT abzubauen. Es geht darum, mit der Tatsache umzugehen, dass die IT jahrelangen Rückstand hat. Unser Plan bei Lokad besteht nicht darin, den Rückstand der IT abzubauen. Es erfordert, die IT so neu zu denken, wie es Amazon getan hat. Das wäre eine andere Episode. Ich würde sagen, suchen Sie nach dem Memo von Jeff Bezos aus dem Jahr 2002 über die APIs bei Amazon. Das Fazit ist, dass alle Abteilungen in einem modernen Unternehmen tonnenweise Software benötigen. Jede einzelne Abteilung - Marketing, Finanzen, Buchhaltung, Supply Chain, Vertrieb - sie alle wollen tonnenweise Software-Tools und all das fällt auf die Schultern der IT. Die IT bricht darunter zusammen.

Also, 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 davon befreien können, sich um Lokad zu kümmern. Das Ergebnis ist, dass wir von 10 bis 20 Tagen Arbeit von der IT benötigen, um die Initiative zur Quantitativen Supply Chain auf den Weg zu bringen, die Pipeline aufzubauen, auf nur noch wenige Stunden reduzieren können. Also, wir lösen nicht den Rückstand. Die IT macht das, was die IT macht. Sie können auch von LLMs profitieren, aber in ihrem Fall sind die Situationen viel vielfältiger, viel schwieriger.

Also ist mein Vorschlag nicht, dass LLMs IT tatsächlich dabei helfen können, ihre Rückstände zu reduzieren. Es ist nur eine Möglichkeit für Lokad, in diesem speziellen Fall zu sagen: “Anstatt 20 weitere Tage zum Rückstand hinzuzufügen, fügen wir einfach etwa vier Stunden hinzu und sind fertig.” So gehen wir mit dem Rückstand um. Und dann im Allgemeinen ist die Lösung für diese jahrelangen Rückstände, dass jede einzelne Abteilung den Großteil der Softwareangelegenheiten internalisieren muss. Sie sehen, die jahrelangen Rückstände entstehen, weil Unternehmen insgesamt zu viel von der IT verlangen. Jede Abteilung - Marketing, Vertrieb, Buchhaltung und dergleichen - sollte digitale Praktiken haben. Sie sollten die IT nicht bitten, all diese Probleme für Sie zu lösen. Sie sollten digitale Experten in jedem Bereich haben, die das tun. 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. Sie können “berühmtes Memo Bezos” eingeben, weil er im Wesentlichen sagte: “Sie haben zwei Wochen Zeit, um einen Plan zu haben, damit jede Abteilung alle Ihre Daten offenlegen kann, damit wir diese Art von Siloing und Machtspielen im Unternehmen, bei Amazon, nicht haben.”

Und Bezos schloss mit den Worten: “Jeder einzelne Manager, der keinen Plan auf meinem Schreibtisch hat, wird entlassen oder so etwas.”

Conor Doherty: Okay, vielen Dank. Dieser nächste Kommentar ist eigentlich 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. Dies ist von Jesse. “Ein Supply Chain Scientist plus ein LLM klingt immer noch wie ein Copilot. Also, grenzen Sie noch einmal den AI-Piloten vom Copiloten ab.”

Joannes Vermorel: Der Grund, warum wir sagen, dass es ein Pilot ist, ist, dass wir einige Kunden haben, bei denen für Wochen alle Entscheidungen generiert und dann unbeaufsichtigt ausgeführt werden. Und wenn ich unbeaufsichtigt sage, meine ich das auch so. Während der Lockdowns von 2020 hatten wir sogar ein Unternehmen, bei dem 14 Monate lang alle Angestellten im Büro zu Hause waren, nicht arbeiteten und vom Staat bezahlt wurden, weil der Staat in Europa Subventionen gab. Mehrere Staaten gaben Subventionen, um im Grunde genommen zu Hause zu bleiben und nicht zu arbeiten. Und so war die Situation. Also, das hatten wir und wenn Sie eine Supply Chain haben, die 14 Monate lang ziemlich unbeaufsichtigt arbeitet, nenne ich das einen Piloten, keinen Copiloten. Wenn niemand die von dem System generierten Zahlen überwacht, denke ich wirklich, dass es ein Pilot ist.

Aber damals haben wir keinen 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 eine sehr hohe Reife in Bezug auf EDI-Integration und dergleichen hatte. Also waren die Art von Dingen, die vorher und nachher benötigt wurden, sehr, sehr begrenzt.

Wie auch immer, zurück zur Frage des Copiloten. Die meisten Konkurrenten von Lokad sagen, dass sie einen Copiloten haben. Und das ist wirklich etwas ganz anderes. Lokad, der Supply Chain Scientist, verwendet eine Programmiersprache. Wenn wir also einen LLM verwenden, dann um uns dabei zu helfen, Teile eines Programms zu generieren. Dafür verwenden wir ihn.

Also wird LLM verwendet, um im Wesentlichen Teile von Programmen zu generieren, die die SQL-Dialekte sein können, die ein paar andere Dinge sein können. Und dann entwickeln wir den Piloten und dann läuft der Pilot unbeaufsichtigt.

Unsere Konkurrenten, insbesondere diejenigen, die behaupten, konversationelle KI, konversationelle Benutzeroberfläche, auf den Markt zu bringen, tun etwas völlig anderes. Was sie tun, ist typischerweise die erweiterte Generierung von Abruf (RAG). Also was sie tun, ist, dass sie eine Aufforderung zusammenstellen. Das machen wortwörtlich alle unsere Konkurrenten, die behaupten, dass sie derzeit KI mit LLM im Bereich der Supply Chain machen. Sie stellen, sagen wir, ein Dutzend Aufforderungen zusammen, die zu verschiedenen Szenarien passen. Dann fügen sie nach der Aufforderung Daten aus der Datenbank ein, zum Beispiel grundlegende deskriptive Statistiken. Sie fügen also ein paar Dutzend Zahlen ein, durchschnittliche Verkäufe in der letzten Woche, im letzten Monat, im letzten Jahr oder so, grundlegende Statistiken, die zum Szenario passen. Und dann fügen sie die zusätzliche Abfrage des Benutzers hinzu und dann vervollständigt der LLM die Antwort.

Sie sehen also, LLMs dienen nur der Textvervollständigung. Sie stellen einen Text zusammen und er wird vervollständigt. Und die erweiterte Generierung von Abruf, der Abrufteil besteht nur darin, einige Zahlen aus der Datenbank abzurufen und dann zusammenzustellen. Aber das Fazit ist, dass Sie jetzt etwas haben, worauf Sie eine Frage stellen können. Aber die Realität ist, dass Sie, wenn Sie nicht ahnungslos sind, die Zahlen direkt vom Bildschirm ablesen können. Es gibt keine Magie. Also sieht der LLM die Zahlen genauso wie Sie sie in Ihrem Bericht sehen können. Grundsätzlich kann er nur Fragen beantworten, die bereits von einem Dashboard beantwortet werden können.

Ja, wenn Sie mit der Definition jeder Zahl nicht wirklich vertraut sind, kann er Ihnen das klären. Aber Sie können auch, das ist es, was Lokad tut, eine Art Spickzettel haben, der Ihnen die einzeilige Beschreibung zu jedem Dashboard gibt, für jede Zahl, die auf dem Dashboard vorhanden ist. Und das erfüllt effektiv die gleiche Rolle, ohne dass KI involviert ist.

Also, das Fazit ist, ich bin sehr, sehr skeptisch gegenüber diesen konversationellen KI, diesen Copiloten, weil sie im Wesentlichen Gimmicks sind, die auf bestehende Systeme aufgesetzt werden, die niemals für irgendeine Art von maschinellem Lernen entwickelt wurden, nicht einmal für die klassische Art von maschinellem Lernen, geschweige denn für LLMs.

Deshalb sage ich, meines Wissens machen alle unsere Konkurrenten Copiloten, bei denen sie im Wesentlichen etwas haben, sagen wir, einen Chatbot, der über Dashboards liegt. Aber er automatisiert nichts. Er ermöglicht es Ihnen nicht, irgendeine Art von KI-Piloten zu automatisieren. Es ist, ja, ein Gimmick auf einem Legacy-System.

Conor Doherty: Okay, danke. Ich werde weitermachen. Das kommt von Kyle. “Können Sie bitte die Bedeutung der Prozessanalyse vor der Einführung eines KI-Modells diskutieren?” Ich werde es im Kontext der Supply Chain betrachten.

Joannes Vermorel: So überraschend es auch sein mag, die Prozessanalyse ist sehr wichtig. Aber nicht unbedingt in der Art und Weise, wie die Leute denken. Die Realität ist, dass Unternehmen, insbesondere in der Supply Chain, vier oder fünf Jahrzehnte Zeit hatten, um viele erfundene Prozesse zu erfinden. Und ich sage “erfunden” absichtlich. Die Supply Chain ist ein Spiel der Bürokratie. Sie hat einen bürokratischen Kern. Das Spiel der Supply Chain in den letzten fünf Jahrzehnten war eine Möglichkeit, die Arbeit zu organisieren, weil man nicht eine Person haben kann, die sich um alle SKUs, alle Lagerhäuser, alle Standorte, alle Produkte kümmert. Also muss man das Problem aufteilen und erobern, die Arbeitsbelastung auf Dutzende, möglicherweise Hunderte von Menschen für große, sehr große Unternehmen verteilen.

So kommt es dazu, dass 90% Ihrer Prozesse nur die aufgetretenen Komplikationen widerspiegeln, die sich daraus ergeben, dass die Arbeitsbelastung auf viele Menschen verteilt ist. Sie sehen also zufällige Prozesse, keine wesentlichen Prozesse. Daher würde ich sagen, ja, Sie müssen die Prozessanalyse durchführen, aber seien Sie vorsichtig, 90% der bestehenden Prozesse lösen nicht das grundlegende Problem, dem Ihre Supply Chain gegenübersteht, sondern zufällige Probleme, die durch die Tatsache entstehen, dass Sie viele Menschen benötigen, um das 10%ige Problem zu lösen, das angegangen werden muss.

In Branchen wie der chemischen Verarbeitung, in denen es viele Flüsse und Abhängigkeiten gibt, ist es sehr kompliziert. Wenn Sie zum Beispiel chemische Reaktionen haben, entstehen Nebenprodukte. Also, jedes Mal, wenn Sie eine Verbindung herstellen, produzieren Sie etwas anderes. Dieses etwas anderes kann verkauft oder für einen anderen Prozess verwendet werden. Sie müssen das alles koordinieren. Sie haben tonnenweise Einschränkungen, Sie haben Prozesse, die in Chargen ablaufen, und Prozesse, die kontinuierlich ablaufen. Es ist sehr kompliziert.

Aber die Realität ist, dass sich die meisten Prozesse anstatt auf die Physis des Problems zu konzentrieren, die Tatsache, dass Sie in einer Prozessindustrie zum Beispiel chemische Reaktionen haben, die sehr spezifische Eingänge und Ausgänge haben und all das sehr, sehr klar definiert und bekannt ist. Anstatt sich auf die Basisschicht der physischen Realität Ihres Unternehmens zu konzentrieren, könnte die Prozessanalyse nur Prozesse rückwärts entwickeln, die verschwinden, wenn Sie den AI-Piloten einrichten.

Das Interessante ist, dass Sie bei der Durchführung eines AI-Piloten diesen Ansatz der Aufteilung und Eroberung nicht mehr benötigen. Es handelt sich um einen einheitlichen Satz numerischer Rezepte, die das Problem von Anfang bis Ende lösen. Alle diese Koordinationsprobleme, die durch so viele Prozesse gelöst wurden, sind einfach verschwunden.

Meine Erfahrung ist, dass 90% dieser Prozesse am Ende einfach verschwinden werden. Deshalb sage ich, es ist sehr wichtig, den Fokus auf die physische Basisschicht Ihrer Supply Chain zu behalten, anstatt sich auf die erfundenen Prozesse zu konzentrieren, die nur dazu dienen, zahlreiche Teams zu koordinieren. Diese Dinge werden nicht aufgerüstet, sie werden durch den AI-Piloten ersetzt.

Conor Doherty: Danke. Und tatsächlich liefert ein Beispiel, das Sie in dieser Antwort genannt haben, einen schönen Übergang hier. Also, von einem Zuschauer Durvesh, haben Sie Pläne, Envision für Bildungs- oder Kleinunternehmenszwecke als Open Source freizugeben? Und kann es mit Regeln programmiert werden, um B2B-Unternehmen wie die Chemiebranche, die umfangreiche manuelle Eingaben erfordern, zu unterstützen?

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 haben domänenspezifische Sprachen (DSLs), aber sie sind nicht öffentlich dokumentiert. Dassault Systèmes hat ein anderes Unternehmen namens Quintiq gekauft. Damals kam es mit einer DSL, die nicht öffentlich dokumentiert ist. Es gibt also buchstäblich in der Supply Chain-Branche andere Unternehmen, die DSLs haben und die nicht öffentlich sind. Bei Lokad dokumentieren wir alles öffentlich und wir haben eine kostenlose Sandbox-Umgebung für Envision. Wir haben sogar kostenlose Workshops zur Verfügung, damit Sie Envision tatsächlich unterrichten oder lernen können, mit Übungen. Also machen wir viel mehr.

Nun, wenn es darum geht, eine Sprache als Open Source freizugeben, ist das Teil des Plans, aber es ist noch zu früh. Warum? Weil Envision sich noch in einer schnellen Entwicklung befindet. Sie sehen, eines der Probleme, die Sie haben, wenn Sie einen Compiler als Open Source freigeben, ist, dass der Compiler ein Softwareprogramm ist, das es Ihnen ermöglicht, Ihr Skript in etwas auszuführen, das ausgeführt wird. Sobald Sie Ihren Compiler als Open Source freigeben, bedeutet das, dass die Leute 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 im Laufe des letzten Jahrzehnts Hunderte Male die Envision-Programmiersprache geändert hat. Diese Sprache ist nicht stabil. Wenn Sie sich mein Buch, das Buch zur Quantitativen Supply Chain, ansehen, das jetzt etwa sechs Jahre alt ist, hat sich die Syntax von Envision dramatisch weiterentwickelt. Sie können einen Blick auf veraltete Syntax werfen, die in Envision nicht mehr existiert.

Und wie gehen wir mit dieser ständigen Änderung der Syntax um? Nun, jede Woche bei Lokad haben wir wöchentliche Veröffentlichungen am Dienstag und was wir anwenden, sind automatisierte Umformungen für alle Envision-Skripte, die auf den Lokad-Plattformen betrieben werden. Es ist also eine der wichtigsten Eigenschaften von Envision, sehr, ich würde sagen, eine sehr hohe Affinität zur statischen Analyse zu haben. Und statische Analyse ist übrigens ein Teilbereich des Sprachdesigns und der Sprachanalyse. Wenn ich von Sprache spreche, meine ich Computersprache, die es Ihnen ermöglicht, Eigenschaften von Programmen zu haben, ohne sie auszuführen. Und durch statische Analyse können wir buchstäblich automatisch ein vorhandenes Skript von der alten Syntax in die neue Syntax umschreiben. Und das machen wir automatisch am Dienstag. Und in der Regel, wenn wir ein Upgrade durchführen, haben wir für ein paar Tage sowohl die alte als auch die neue Syntax, die akzeptiert werden. Wir führen die automatisierten Umformungen durch und dann, wenn wir sehen, dass die alte Syntax nicht mehr existiert, sperren wir mit einem Feature-Flag die Tatsache ein, dass nur die neue Syntax existiert.

Und Lokad hat bereits über 200 dieser automatisierten Umformungen bereitgestellt. Normalerweise machen wir das so, dass wir jeden Dienstag eine Veröffentlichung machen, aber normalerweise haben wir etwa zwei Umformungen pro Monat und das machen wir seit einem Jahrzehnt. Solange dieser Prozess läuft, können wir bei Lokad Envision nicht realistisch als Open Source veröffentlichen. Es wird zur gegebenen Zeit kommen, aber ich möchte nicht den massiven Fehler von Python wiederholen. Das Upgrade von Python 2 auf Python 3 hat der Python-Community ein Jahrzehnt gedauert und es war unglaublich schmerzhaft. Ich meine, Unternehmen haben Jahre für das Upgrade gebraucht, es war ein Albtraum, der ein Jahrzehnt dauerte. Das war wirklich, wirklich falsch. Selbst Microsoft hat mit dem Upgrade von C# und dem .NET-Framework auf .NET Core ein halbes Jahrzehnt gedauert und das war sehr schmerzhaft. Das ist also wieder das Problem, dass Sie, sobald Sie einen Compiler haben, der als Open Source in freier Wildbahn ist, den Code nicht kontrollieren. Wenn Sie also Änderungen an der Sprache vornehmen möchten, müssen Sie mit Ihrer Community zusammenarbeiten. Das macht den Prozess super langsam, super schmerzhaft und am Ende eliminieren Sie nie wirklich alle schlechten Funktionen Ihrer Sprache.

Wenn wir uns Python anschauen, die Art und Weise, wie zum Beispiel objektorientierte Programmierung in Python eingeführt wurde, die Syntax, ah, sie ist umständlich. Man kann wirklich spüren, dass Python nicht mit objektorientierter Programmierung im Hinterkopf entworfen wurde. Es war eine spätere Ergänzung in den späten 90er Jahren und die Syntax ist irgendwie Mist und jetzt ist sie für immer da. Und übrigens, jede einzelne Sprache hat das. In C# haben Sie das Schlüsselwort “volatile”, das keine Funktion mehr hat. C++ ist für immer mit Mehrfachvererbung festgefahren. Das war ein Fehler. Die Mehrfachvererbung zu haben, war eine schlechte Designentscheidung, die alles kompliziert, usw. Die einzige Möglichkeit, diese großen Fehler zu vermeiden, Lokad, wir haben viele große Fehler im Design von Envision gemacht, aber wir beheben sie nach und nach und wir sind immer noch im Prozess, besonders wenn neue Paradigmen hinzukommen. Zum Beispiel war differentiable programming ein großes neues Paradigma und wir mussten die Sprache selbst neu konstruieren, um dieses Paradigma zu ermöglichen.

Übrigens gibt es einen großen Vorschlag für Swift, der von Apple vorgeschlagen wurde, um differentiable programming zu einer First-Class-Citizen in Swift zu machen. Aber es wird wahrscheinlich nicht so bald passieren. Es ist wie eine große, große Überarbeitung. Im Moment ist die Sprache, die am nächsten daran ist, differentiable programming als First-Class-Citizen zu haben, Julia, und selbst dort gibt es viel Klebeband.

Conor Doherty: Vielen Dank nochmal. Es sind noch drei weitere zu bearbeiten. Der nächste ist von Victor. Es geht im Allgemeinen um KI. Wie geht KI mit zufälligen Engpässen um, wenn sie auf großen Datensätzen arbeitet, um plausible Szenarien oder wiederkehrende Probleme vorherzusagen?

Joannes Vermorel: Seien wir klar, wenn wir von KI sprechen, handelt es sich um eine Sammlung von Techniken. Bei Lokad haben wir typischerweise LLMs, differentiable programming und stochastische Optimierung. Differentiable programming dient dem Lernen, stochastische Optimierung dient der Optimierung unter Einschränkungen in Anwesenheit von Unsicherheit, das probabilistische Modell, das typischerweise mit differentiable programming regressiert wird, und LLMs dienen als universeller, geräuschresistenter Template-Engine.

Wenn Sie die Supply Chain mit probabilistischen Werkzeugen angehen, verschwinden die meisten Aufgaben, die durch diese Frage angedeutet werden, einfach. Das ist das Schöne an probabilistischen Prognosen, diese Prognosen sind nicht genauer, sie sind einfach viel widerstandsfähiger gegenüber dem Umgebungsrauschen der Supply Chain. Wenn Sie probabilistische Prognosen mit stochastischer Optimierung kombinieren, eliminieren Sie weitgehend die Notwendigkeit manueller Eingriffe. Und wenn ich “weitgehend” sage, meine ich für die meisten Kunden, dass es das vollständig beseitigt. Und jetzt bleiben uns Aufgaben, bei denen wir Text durchgehen und damit umgehen müssen, und das sind LLMs. Und nochmals, was ich beschrieben habe, ist Lokad, wir haben diese KI-Piloten, die wirklich automatisiert sind, und wenn es einen manuellen Eingriff gibt, dann geht es nicht darum, einen bürokratischen Eintrag im System zu machen, sondern um eine strategische Überarbeitung des numerischen Rezepts einzugeben, das typischerweise eine grundlegende Änderung der Logik selbst ist, um die überarbeitete Strategie widerzuspiegeln. Es wird keine Kleinigkeit sein, sondern in der Regel etwas, das grundlegend ist und die Struktur der implementierten Logik verändert.

Conor Doherty: Dieser hier ist von Ahsan. Könnten Sie bitte erklären, wie KI, speziell, eine Bestellung beschleunigen würde? Wäre sie in der Lage, Transaktionen im ERP-System aufgrund von verbalen Befehlen auszuführen?

Joannes Vermorel: Verbale Befehle sind nicht der richtige Ansatz für dieses Problem. Wenn Sie schnellere Dateneingaben wünschen, ist die Sprache ein sehr niedrigbandbreitiger Kanal. Sie tippen schneller als Sie sprechen, es sei denn, Sie sind sehr schlecht im Tippen. Daher ist dies nicht die Art von Gewinn, den Sie erzielen können. Wenn Ihre Benutzeroberfläche richtig mit einer Tastatur gestaltet ist, sind Sie schneller als mit Sprachbefehlen. Das weiß ich sehr gut, denn vor 20 Jahren habe ich bei AT&T Labs an der Spitze von spracherkennungssystemen gearbeitet. Es gab viele Anwendungen, bei denen es nicht funktioniert hat. Die Spracherkennung funktionierte, aber die Realität war, dass Ihre Hände auf der Tastatur einfach schneller waren. Die Situationen für die Sprache waren entweder schmutzige Hände oder beschäftigte Hände. Ansonsten ist die Tastatur einfach schneller.

Zurück zur Frage, zunächst möchten Sie die Bestellungen filtern. Hier haben wir einen Entscheidungsprozess, bei dem Sie entscheiden möchten, welche Bestellungen beschleunigt werden müssen. Das ist klassisches Lokad, das ist ein reiner Entscheidungsprozess, quantitativ. Sie müssen entscheiden, ob diese laufende Bestellung eine Anfrage zur Beschleunigung des Prozesses rechtfertigt oder nicht. Das würden wir mit differenzierbarer Programmierung, stochastischer Optimierung tun. So treffen wir die richtigen Entscheidungen.

Sobald wir das haben, haben wir automatisch jeden Tag die Entscheidungen für die Bestellungen. Es geht nicht darum, dass jemand mündliche Befehle dafür gibt. Es wird Teil der Reihe von numerischen Rezepten sein, mit denen wir die optimierten Bestellungen berechnen. Im Laufe der Zeit stellen wir fest, dass einige Bestellungen zu viel oder zu wenig sind, und wir werden um eine Verschiebung oder Beschleunigung bitten. Der Teil des LLM besteht nur darin, diese quantitative Entscheidung zu nutzen, bei der Sie eine binäre Flagge haben, die “bitte beschleunigen” sagt, um eine E-Mail mit einem entsprechenden Kontext zu generieren, sie an den Lieferanten zu senden mit etwas wie “bitte bestätigen Sie, dass Sie dies tun 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 automatisiert den Chat mit dem Lieferanten. Die KI geht nicht darum, die Bestellung zu beschleunigen. Das ist eine reine quantitative Entscheidung, die mit quantitativen Werkzeugen, differenzierbarer Programmierung, 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 verwendet.

Wenn Sie an Sprachbefehle denken, wird es nicht funktionieren. Es ist viel zu langsam. Ich hatte das Privileg, mit den Teams zusammenzuarbeiten, die vor 20 Jahren die ersten spracherkennungssysteme in Serienproduktion auf den Markt gebracht haben. Aber das Fazit ist, dass Sie diese KI-Technologien dafür nicht verwenden werden. Sprachbefehle haben nicht die Bandbreite, um das zu tun, was Sie tun möchten.

Conor Doherty: In diesem Zusammenhang haben wir umfangreiche Videomaterialien zu stochastischer Optimierung und differenzierbarer Programmierung. Wir gehen nicht näher darauf ein, da es sich um eine dreiteilige Serie (Teil 1, Teil 2 und Teil 3) zur differenzierbaren Programmierung handelt, aber wir ignorieren sie nicht. Sie wurden bereits behandelt und ich bitte die Zuschauer, die mehr darüber erfahren möchten, diese anzusehen und dann diese Teile zusammenzufügen.

Letzte Frage, und sie kommt von Isaac. Als Kunde, der derzeit Envision lernt, interessiere ich mich für seine Integrationsmöglichkeiten, insbesondere mit GitHub. Könnten Sie über das Potenzial von Envision sprechen, die GitHub-Integration zu unterstützen, insbesondere für Anwendungen wie das Erklären von Codeblöcken in natürlicher Sprache oder das Identifizieren von Änderungen zwischen Versionen? Gibt es schließlich Pläne, in naher Zukunft einen Envision Copilot einzuführen?

Joannes Vermorel: Die kurze Antwort lautet ja, ja und ja. Die Zeitleisten variieren sehr stark, je nachdem von welchen Komponenten wir sprechen. Wir arbeiten bereits daran, LLMs zu verwenden, um im Wesentlichen einen Copilot wie den GitHub Copilot zu erstellen, aber das wird der Lokad Copilot für Envision-Codes sein. Das sehr interessante daran ist, dass wir aufgrund der Tatsache, dass es sich um eine DSL handelt, bei der wir die Kontrolle haben, vollständige Kontrolle über die Schulungsmaterialien haben. Das ist sehr cool, denn das bedeutet, dass wir am Tag, an dem es uns erfolgreich gelingt, diesen LLM in die Produktion zu bringen, immer wenn wir die Syntax ändern, unseren Schulungsprozess mit der aktualisierten Syntax erneut ausführen werden und immer einen Copilot haben werden, der Ihnen die aktuelle Envision-Syntax gibt. Im Gegensatz zum GitHub Copilot, der Ihnen eine Python-Syntax, eine C#-Syntax, eine Java-Syntax gibt.

Denn sehen Sie, Java gibt es schon seit 25 Jahren, Python gibt es schon seit mehr als 30 Jahren, C# gibt es seit 22 Jahren oder so. Wenn Sie also den GitHub Compiler bitten, Code für Sie zu schreiben, ist das Problem, dass er Ihnen eine Version dieser Sprachen gibt, die halbwegs aktuell ist, aber nicht wirklich super aktuell. Und manchmal möchten Sie die aktuelle Version nicht, weil Ihre Umgebung nicht mit diesen super aktuellen Versionen übereinstimmt, die Sie noch nicht unterstützen.

Wir arbeiten an einer ganzen Reihe von übernatürlichen Funktionen wie “Kommentiere meinen Code”, “Erkläre meinen Code”, “Vervollständige meinen Code”. Wir denken auch über viele erweiterte Codeaktionen nach, die sehr spezifisch für die Workflows sind, die innerhalb von Lokad stattfinden. Zum Beispiel arbeiten wir daran, die automatische Generierung von Dashboards für die Datenintegrität zu automatisieren. Das ist eine sehr typische Aufgabe.

Dashboards für die Datenintegrität sind im Wesentlichen Instrumente, die überprüfen, ob die von uns aufgenommenen Daten in Ordnung sind. Und wir haben viele Tricks und Know-how, worauf wir achten müssen, weil die Art von Problemen, die Sie in Daten von ERPs finden, irgendwie immer die gleichen sind. Wenn wir Daten auf Korrektheit überprüfen, die aus einem ERP stammen, haben wir Supply Chain Scientists, die buchstäblich unsere eigenen Schulungsmethoden entwickelt haben, um zu wissen, wonach wir suchen müssen, und wir haben unsere eigenen Rezepte, also menschliche Rezepte, was sollte ich implementieren, was sollte ich überprüfen, und wir könnten das weitgehend mit den LLMs automatisieren. Das ist etwas, woran Lokad gerade arbeitet.

Wir arbeiten an einem Lokad Copilot. Um Envision benutzerfreundlicher mit GitHub zu machen, haben wir bereits eine Open-Source-Erweiterung für Visual Studio Code veröffentlicht. Sie können bereits Envision-Code in ein Git-Repository einfügen. Sie erstellen einfach eine .nvn-Datei, committen und sind fertig. Wenn Sie den Code mit einer schönen Code-Färbung bearbeiten möchten, benötigen Sie eine Visual Studio Code-Erweiterung. Wenn Sie nach der Lokad Visual Studio Code-Erweiterung für Envision suchen, finden Sie eine, die komplett Open Source ist und Code-Färbung bietet.

In Zukunft planen wir, den Envision-Code, der sich in einem Lokad-Konto befindet, als Git-Repository freizugeben. Die Art und Weise, wie der Envision-Code in einem Lokad-Konto gespeichert ist, ist ziemlich ähnlich wie in einem Git-Repository. Er ist in etwa genauso versioniert. Er ist nicht genau so organisiert wie Git, ich werde jetzt nicht zu weit in die technischen Gründe gehen. Git ist sehr sprachunabhängig. Wenn Sie nur mit einer bestimmten Sprache arbeiten, können Sie intelligenter sein und Dinge tun, die im Allgemeinen nicht möglich sind. Aber das Fazit ist, dass der Envision-Code vollständig versioniert ist. Wir könnten ein Git-Repository freigeben, mit dem Sie Ihren gesamten Code aus einem Lokad-Konto in ein Git-Repository exportieren können, und vielleicht später auch den umgekehrten Weg gehen, um eine Zwei-Wege-Synchronisation zu haben. Git ist ein dezentrales System, bei dem jedes Git-Repository wie das Ganze ist, Sie haben eine vollständige Kopie und können also Änderungen von einem Remote-Repository abrufen, aber Ihre Änderungen an ein Remote-Repository senden. Und so werden wir wahrscheinlich zu einem bestimmten Zeitpunkt zuerst den Export einführen und dann den Reimport einführen, aber das wird Zeit brauchen. Wir sind noch nicht so weit. Es ist Teil der Roadmap, aber wir haben noch keinen Zeitplan dafür.

Conor Doherty: Es ist erwähnenswert, dass einige Leute in den Kommentaren gesagt haben, dass sie Envision lernen. Wir produzieren eine Reihe von Tutorials in Zusammenarbeit mit der University of Toronto und einigen anderen, die sich in der Pipeline befinden. Es gibt kostenlose Ressourcen und wir können Antworten geben, wenn die Leute es wünschen. Für alle, die lernen möchten, stecken unsere Supply Chain Scientists viel Mühe in diese Workshops. Sie sind frei 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 zur Verfügung stellen.

Conor Doherty: Das sind alle Fragen, Joannes. Vielen Dank für Ihre Zeit und vielen Dank fürs Zuschauen. Ich hoffe, es war nützlich und wir sehen uns das nächste Mal.