00:00:00 Lokadの設立物語と初期の年月
00:02:31 サプライチェーン最適化に関する誤解
00:04:31 既存のサプライチェーン理論は機能しなかった
00:06:32 予測の失敗の逆説
00:08:33 「何も予測しない」が競合他社を打ち負かす方法
00:10:25 既成の考えを拒否する課題
00:12:00 確率論的予測への転換
00:14:07 極端な需要シナリオの重要性
00:16:32 企業データ統合の複雑さ
00:20:55 紙上のサプライチェーンモデルが失敗する理由
00:27:30 企業AI導入におけるエンジニアリングの問題
00:35:00 COVID-19がサプライチェーンに与える影響
00:42:49 LLMはテキストベースであり、数学的ではない
00:50:25 金融業界の並行進化
01:09:00 Q&Aと最終的なコメント
サマリー
Joannes Vermorel、LokadのCEO兼創設者が、フランス語で講義を行い、サプライチェーン管理における自身の旅を共有しました。 Vermorelは、エコール・ノルマル・スペリウールを卒業した後にLokadを設立し、バイオインフォマティクスからサプライチェーンの課題に焦点を移しました。彼は、Lokadのプログラミング言語であるEnvisionの開発と、2007年以降の同社の進化について語りました。 Vermorelは、伝統的なサプライチェーン理論を批判し、それを占星術に例え、合意に挑戦する重要性を強調しました。彼は確率論的手法によるLokadの成功と、COVID-19がサプライチェーンのロボット化に与える影響を強調しました。 Vermorelは、伝統的な役割の陳腐化を予測し、学生たちに産業の革命を推進するよう奨励しました。
拡張サマリー
フランス語で学生たちに講義を行ったJoannes Vermorel、LokadのCEO兼創設者は、サプライチェーン管理の世界と自社の進化についての洞察を共有しました。 Vermorelは、自己紹介を行い、エコール・ノルマル・スペリウールを卒業後に設立したLokadの起源を振り返りました。最初はバイオインフォマティクスの論文を追求しようとしましたが、すぐにその分野は既に才能ある個人で溢れていることに気付きました。偶然にも、彼はサプライチェーン管理の課題に出会い、これが彼の新たな焦点となりました。
Vermorelは、Centraleの学生がサプライチェーン最適化のために彼が作成したプログラミング言語であるEnvisionを使用していることに驚きと喜びを表しました。彼は、Envisionの開発を振り返り、最初に書いたコンパイラがLokadのCTOであるVictor Nicoletによってすぐに優れたバージョンに置き換えられたことを述べました。 Envisionはその後、大幅に進化し、現在、バージョン6のリリース直前です。
Lokadの旅は2007年に始まり、2008年に正式に設立されました。しかし、EnvisionはLokadの存在から5年後の2013年に導入されました。 Vermorelは、新しいプログラミング言語を作成する決定が他のすべての選択肢を使い果たした後に行われたと説明しました。当初、彼はサプライチェーンが数十年の文献やSAP、Oracle、IBM、Microsoftなどの多くの競合他社が存在する確立された分野だと考えていました。成功の鍵は既存のサプライチェーン理論をウェブアプリケーションに再パッケージ化し、クライアントサーバーアプリケーションからクラウドベースのソリューションに移行することを活用することだと考えていました。
最初の自信にもかかわらず、Vermorelはすぐに確立された理論やモデルが期待通りに機能しないことに気づきました。彼は2011年に特に馬鹿げた経験を振り返り、Lokadがゼロの予測を提出してベンチマークに勝利し、競合他社を20％上回ったことを語りました。この経験から、Vermorelは伝統的なサプライチェーン理論の妥当性を疑い、それを天文学ではなく占星術に例えました。
科学における合意に挑戦する重要性を強調したVermorelは、広く受け入れられているが最終的に間違っている信念の例で歴史が満ちていることに言及しました。彼は、サプライチェーン自体は正当な分野である一方、それを支える古典的な理論が欠陥があると結論づけました。この認識は、バイアスのある予測や分位数予測などの代替アプローチを探求するきっかけとなり、これらがより効果的であることが証明されました。
Lokadのアプローチは、現実世界のサプライチェーン問題の複雑さに対処できなかった従来のモデルから確率的およびプログラム的な手法を取り入れるように進化しました。 Vermorelは、これらの課題に適した堅牢なプログラミング言語の重要性を強調し、Pythonなどの汎用言語の使用を批判しました。これは、さまざまな技術的問題によって失敗した取り組みが多かったためです。
講義では、COVID-19パンデミックの影響にも触れ、サプライチェーンのロボット化が加速していることを指摘しました。 Vermorelは、Lokadのソリューションが大規模なスケールで効果的であり、数十億ユーロ相当の在庫を最小限の人間介入で管理していることを述べました。この変化は、取引が主にアルゴリズムによるものになった金融業界の移行を反映しています。
Vermorelは、サプライチェーン管理の将来について議論し、在庫管理者や需要予測者などの伝統的な役割が、より多くの企業が自動化された意思決定プロセスを採用するにつれて時代遅れになると予測しました。彼は、この革命を推進するために受動的ではなく積極的に行動することを学生に奨励しました。
学生の質問に対応して、Vermorelは、技術的に強力な企業はLokadのソリューションを内部化する可能性があり、他の企業はおそらくこれらのサービスを外部委託し続けるだろうと説明しました。また、ChatGPTなどの大規模言語モデル（LLM）の制限にも言及し、その学習能力と記憶能力の欠如を指摘しました。
Vermorelは、市場の非合理性とサプライチェーン業界での失敗プロジェクトの持続性について振り返りました。過去の失敗にもかかわらず、競合他社が繰り返し莫大な資金を調達したエピソードを共有し、市場の混沌さを強調しました。これらの課題にもかかわらず、VermorelはLokadの業績とCentraleなどの名門機関の学生たちの間でのEnvisionの予想外の成功に誇りを表しました。彼は学生にLokadへの参加を検討するよう勧め、同社の採用活動を強調しました。
フルトランスクリプト
フランス語の元のスピーチが英語に翻訳されました。
Joannes Vermorel: 自己紹介をさせてください：私はJoannes Vermorel、Lokadの創設者です。私は学校を卒業したときに会社を設立しました。私はエコール・ノルマル・スペリウールに在籍し、バイオインフォマティクスの博士号を取得しましたが、最終的にはバイオインフォマティクスで興味深いことをしている人がたくさんいたため、私は必要とされていなかったかもしれません。偶然にも、私はこれらのサプライチェーンの問題に出会いました。今日Envisionを使っているのを見てとてもうれしいです。私がこの言語を作成したときには、12年前くらいで、Centraleの学生たちの前でこの言語について話すことになるとは、当時は想像もしていませんでした。
私が最初のEnvisionコンパイラを書いた後、Victor Nicolet—LokadのCTO—がそれを捨てて、すぐに2番目のコンパイラを書きました。そして今、あなたは基本的にバージョン5を使用していますが、バージョン6がリリースされる直前です。言語は大きく進化しました。しかし、あなたが取り組んだもの—あなたが見た部分—はLokadが始まった場所では全くありませんでした。実際、それはかなり遅れてやってきたものです。Lokadは2007年に始まり、2008年に法人化されましたが、Envisionは2013年頃のものです。ですので、Envisionが登場したときには、会社はすでに約5年の歴史がありました。
言語を作成するアイデアは、他のすべての代替手段を使い果たした後に生まれました。それは、先見の明のある創設者の計画ではなかったのです—単に、私たちが試した他のすべてが失敗したということです。
サプライチェーンに関して驚くべき点をお伝えするために：私が2008年にLokadを立ち上げたとき、私の見解は、サプライチェーンは確立された分野だということでした。何しろ、その分野には60年から70年の文献があり、文字通り何百万もの論文があります。Amazonで「サプライチェーンマネジメント」と入力すると、確認しましたが、そのトピックに関する現在利用可能な本は約1万冊あります。数十年にわたって、さらに多くの本が出版されてきましたが、その1万冊は現在も販売されているものです。非常に文書化された分野です。
私が始めたとき、大手の競合他社がいて、大手の名前がありました：SAP、Oracle、IBM、さらにはMicrosoft—サプライチェーンの主要なプレーヤーです。競合他社の総収益を合計すると、5兆ドルになります。それは重要なことです。私の最初の直感—結局間違っていたことがわかった完全に間違ったものでした—は、確立されたサプライチェーン理論を取り上げて、それを単にウェブアプリに再梱包すればいいというものでした。2008年でしたし、すべてのエンタープライズソフトウェアは、PCにインストールする「厚いクライアント」アプリから、「薄いクライアント」、つまりウェブアプリに移行していました。したがって、サプライチェーンソフトウェアをウェブアプリとして再構築する機会があり、クラウドホスティングを使用する可能性がありました。Lokadは非常に早くクラウドに移行しました。それは、古い、重いクライアントベースのシステムにまだとどまっている大企業に対して私たちにリードを与えるかもしれないということです。そして、サプライチェーンを最適化する方法を説明する本が文字通り何冊もあるように—MITのマニュアル、スタンフォードのマニュアル、カルテックのマニュアル—それらすべてを読みました、2、3人の教授によって書かれたこれらの1000ページの巨大な本にはすべての方程式が書かれています。
それらのアプローチをコーディングしましたが、何もうまくいきませんでした。興味深いことに、それはLokadの成長や顧客を持つことを妨げませんでした。スタートアップとしてお金を稼ぐには、実際に機能する製品が必要だと思うかもしれませんが、エンタープライズソフトウェアでは、全く機能しないものを販売しても、顧客を見つけることができます。奇妙に思えるかもしれませんが、それが現実です。実際のところ、企業が解決したい大きな問題がある場合、その問題を解決しようとする予算があります。この予算は巨大ではないかもしれません—特に製品が実際に機能していない場合—しかし、スタートアップにとっては、それらの金額は非常に大きく見えるかもしれません。カルフールのような巨大企業が「見てみるだけ」に10万ユーロを出すとしたら、カルフールにとっては何でもないかもしれませんが、小さな会社にとっては多額の金額です。
ですので、その非対称性を活用して、私は始めて、標準的なサプライチェーン理論を実装しようとしました：時系列予測、安全在庫、サービスレベルの最適化など。何もうまくいかず、全くうまくいきませんでした。私たちはクライアントとかなり分裂した議論をしました：「安全在庫の式を間違ってコーディングしたに違いない」と言われ、私たちは戻り、教科書の表から値を取り、パラメータを再確認しました—そしてそれは正確に記載されていたのです。つまり、理論は正しく実装されていましたが、結果はまったくナンセンスでした。
私は、ナンセンスの頂点が2011年の夏に訪れたと考えています。私たちは半ダースのソフトウェアベンダーと大きなRFPに参加しました。その半数はヨーロッパ人で、残りの半数はアメリカ人でした。Lokadはヨーロッパ人の中にいました。私の記憶では、ケースは約10のスーパーマーケット、1つあたり5,000のSKU、これらのスーパーマーケットはおそらく週に2〜3回補充されるため、数日先を予測する必要がありました。クライアントは、各店舗の日次製品レベルの予測に対してバックテストエラー基準を使用しました—基本的には予測と実際の間の絶対誤差です。Lokadはそのベンチマークで勝利しました—20%以上の精度向上で、他の競合を圧倒しました。私の秘密の方法？私はゼロを返しました。すべてにゼロを。私の「ゼロ予測」のおかげで、計算速度でも他の誰よりも勝ちました：ゼロを返すのは非常に速いです。そして他の人よりも20% 優れた予測精度を得ました。さらに、需要をゼロに予測すれば、店舗を補充しないので、2週間で店舗が空になり、これはあなたの予測と完全に一致します。私は統計の王でした。
明らかに、それは完全なナンセンスでした。しかし、すべてのサプライチェーンの教科書とクライアントの標準プロセスが推奨するアプローチを考えると、完全な不条理につながりました。私がそこから得た結論はかなり不安定でした。私たちは利益を上げ、成長している会社でしたが、私はただのスキームにつまずいた可能性があることを強制されました。何かを始めて、お金を稼ぐことができますが、それは純粋なナンセンスです。最初はただ単に経験が足りないだけかもしれません。しかし、一度気づいたら、続けますか？卒業して自分がやっていることがナンセンスだと気づいたら、続けますか？それは深い疑問を呼び起こしました。サプライチェーンは占星術かもしれませんか—占いの種類、天文学ではなく？
最終的に、私はサプライチェーンという分野は実在するが、標準的なサプライチェーン理論は基本的に占星術だと結論付けました。それがバグでした。70年以上の研究、100万以上の論文、何千人もの教授がすべて間違っていると受け入れるのは非常に難しいことです。必要な知的な傲慢さを想像してください。4人の異なる医師に診断が同じだと言われた場合、彼らが全員間違っていて自分が正しいと言うタイミングはいつですか？しかし、科学は合意に基づいて機能しません。1,000人が何かに同意しても、それが間違っている可能性があります。科学の歴史には、狂ったとわかったアイデアについて非常に広範な合意がある例がたくさんあります。科学の歴史を研究する人々の中には、ある時点でどの半分が間違っているかを知るのが難しいとさえ言う人もいます。
その結果、Lokadはそのベンチマークからその結論を得ました：主流の方法はナンセンスでした。私たちは他のものを探さなければなりませんでした。私たちの大きなブレークスルーは2012年初頭にやってきました。バイアスのある予測を追求することで、分位数予測として知られているものに取り組みました。当時、私は50人の従業員を常勤で雇用してバイアスを取り除くよう依頼されているクライアントがいました。ですので、彼らは私に尋ねました。「なぜバイアスのある予測が欲しいのですか？私たちはそれらをバイアスを取り除くために支払っています」と。新しい方法は手動で取り除くことができないほど多くのバイアスを追加したため、彼らはかなり警戒しました。しかし、「分位数予測」と呼べば、「バイアスのある予測」よりも科学的に聞こえます。しかし、実際には、分位数予測はただのバイアスのある予測です。
このアプローチを最初のeコマースクライアントと試しました。一晩で、全てにゼロを予測するなどのナンセンスな結果から、中途半端ながらも少しは理にかなったものに切り替わりました。それは驚くべきこととは聞こえないかもしれませんが、完全なナンセンスから単なる平凡さに移行することは大きな進歩でした。
それが私たちを教科書で見つかるすべてのサプライチェーンの仮定を見直すことに導き、基盤をすべて疑問視し、非常に不安定で基本的に間違っていることがわかりました。分位数予測はその単純なバージョンに過ぎません。これは極端な状況を特に考慮する統計ツールです。経済的には、サプライチェーンでは、お金が失われる極端な状況が問題です：予期せぬ高い需要による在庫切れ、予期せぬ低い需要による在庫過剰、予期せぬ長いリードタイムによる計画の破綻など。本当にあなたを傷つけるのは分布の中心ではなく、両端です。分位数予測はこれらの極端に焦点を当てたツールです。改善されたバージョンは確率予測であり、それがあなたが取り組んできたものです。そこでは完全な確率分布が得られます。2012年には、数百万のSKUにわたる確率分布を処理することは、SKUごとに単一の予測数値を生成するよりもはるかに重い作業でした。
一方、元々は価格設定のための内部プロジェクトコードネーム「Priceforge」として開発されたEnvisionは、新しいアプローチに対処するのに最適であることがわかりました。その前は、Lokadのアイデアは、企業向けソフトウェアに一般的なサプライチェーンソフトウェアを構築することでした。しかし、ソフトウェアパブリッシャーの観点からは混乱でした：機能を追加するにつれて、クライアントの環境からデータ構造へのデータマッピングがエンジニアリングの悪夢になります。
なぜかと言うと、クライアントのデータアーキテクチャは常にユニークです。あるクライアントのERPには、それぞれ50のフィールドを持つ10,000のテーブルがあり、多くは文書化されておらず、普通でない方法で使用されています。実際、2つまたは3つのERP、WMS、eコマースプラットフォームなどがあるかもしれません… そのエコシステムは複雑です。2つの企業が同じデータ定義を持っていることはありません。注文日などの簡単に見えるものでも、20の異なる定義があるかもしれません：レコードが作成された日、顧客が注文を確認した日、あなたが確認した日、支払いプロバイダーが承認した日、注文が出荷された日など。その他の潜在的なデータフィールドが1000個あるとしても、それをかけ合わせてください。
製品、SKU、バリアント、サプライヤー、場所などの定義が設定された「クラシック」なソフトウェアを作成した場合、それらの定義はクライアントの現実とはほとんど一致しません。たとえばアパレルでも、1つの企業はバリアントを純粋に色とサイズとして定義するかもしれませんが、別の企業は生地の組成も含めるかもしれません。また、食料品では、「賞味期限日」が絶対に販売できない日を意味する場合もあれば、店頭に陳列できない日を意味する場合もあります。微妙な違いが無限にあります。
したがって、標準的なサプライチェーン理論は不十分であることがわかりました。新しいものが必要でした：プログラム的なアプローチ。これはサプライチェーンの教科書が決して取り上げないものです。棚から出して使えるモデルは役に立ちません。なぜなら、現実世界はそのようなモデルに完全に適合しないからです。常に何かがあります - 最小注文数量、賞味期限の制約、配送スケジュールの制約。各企業の制約はユニークです。したがって、解決策はプログラム的であり、静的な数式ではありません。その次の問題は、サプライチェーンに適した正しいプログラミングパラダイムは何かということでしたか？
2012年には、「なぜPythonを使わないのか？」と言う人もいました。実際、その頃、私のアメリカのeコマースクライアントは皆そうしていました。その時期に私が見たほとんどのデータサイエンスの取り組みはPython（またはJava、C＃、後にJuliaでも同じ問題）のために失敗しました。そのパターンは次のようでした：3週間で、データサイエンスチームがいくつかのサプライチェーンの問題のための印象的なプロトタイプを構築します。その後、それを本番環境に導入したいと思いますが、1年後にはまだ本番環境に導入されていません。管理陣が忍耐を失い、プロジェクトをキャンセルし、それで終わりです。
なぜ失敗したのか？NullReferenceException、OutOfQuotaException、並行性の問題、互換性のないパッケージ、セキュリティ侵害、環境へのランサムウェアなどによる千切りの死。これらはすべて、サプライチェーンの問題そのものとは直接関係ありません。根本的な問題は、大規模な本番環境で汎用言語を使用すると、問題の攻撃面が非常に大きくなることです。たとえば、コードからファイルシステムに書き込むことができれば、コードをホストする環境を誤って破損させる可能性があります。並列でデータをギガバイト単位で処理している場合、これは簡単に起こります。ファイルが1つのプロセスによってロックされているか、ディスクの空き容量が不足している場合などです。これらのことは、夜中に必ず起こり、その場で修正する人は誰もいません。そして、朝になると、クライアントは怒っています。なぜなら、システムが午前2時に終了することを期待していたが、真夜中にクラッシュしたからです。
データサイエンスのデモでは、通常、ベビーシッターがスクリプトを起動し、クラッシュした場合は修正します。しかし、実際のサプライチェーンの自動化は毎日監視なしで実行する必要があります。実行時間は20分から2時間まで変動することもあり、これが本番環境を壊す原因となりました。これが2012年の問題でした：これらのデータサイエンスの取り組みは、サプライチェーンの論理そのものではなく、汎用言語の広範な複雑さのために本番環境で失敗しました。
これらすべてがLokadに、壊れやすいベビーシッタリングなしで大規模な日常業務を処理するのに十分に安全で専門化されたプログラム環境が必要だと気づかせました。さらに、高度な予測（確率的、分位数など）も行う必要があると認識した後、Envisionはこれらのワークフローを第一級市民として処理するように設定されました。たとえば、機械学習のための微分可能プログラミングを行いたい場合、一般的な言語にPyTorchのような別の「ミニ言語」を埋め込むことがあります。その結果、PythonとPyTorchコードの一部があり、PyTorchコードは基本的にコンパイルされていない文字列なので、間違いを犯しやすくなります。Pythonコード内にSQLクエリを混在させる場合も同様です。すべてが文字列なので、タイプミスは実行時にのみ発見されます。一方、Envisionはこれらの機能を組み込み機能として扱い、コンパイルチェックを行うことができます。
Lokadのアプローチは、ディープラーニングなどの進歩と並行して進化しました。ここでは、事前パッケージ化されたモデルのライブラリだけでなく、プログラムで独自のモデルを構築することができるようになりました。TensorFlowは基本的に計算グラフを構築するための言語です。モデルの「カタログ」に囚われることはありません。構造を構築します。Envisionもこれらのアイデアをネイティブに取り込むことができます。たとえば、最近は確率的最適化に取り組んでいます。ここに確率的最適化とは何かを知っている人はいますか？それは、結果が不確かな関数の最適化です。例えば、将来の需要が不明な場合に何単位購入するかを決定することです。これは古典的なサプライチェーンの課題です。制約が最小限の簡単なバージョンを見たことがありますが、実際のビジネスにはたくさんの制約があります：最小注文数、コンテナの充填率、カテゴリの制約、または複雑なカレンダー。さらに、コスト/利益関数が不確かです。これらは高度なプログラムの概念です。
結局、Envisionは機能を追加し続けました。今日までに、私たちはまた別の革命の門をくぐろうとしています：大規模言語モデル（LLM）。ChatGPTはおそらくおなじみです。おそらく、宿題をするために使用している人もいるでしょう。 （私はあなたを評価していないので、それを認めても構いません！）またはプロバージョンを購入しているかもしれません。私たちにとって興味深いのは、Lokadが供給チェーン企業には珍しい執筆文化を持っていることです。私たちは2つのレベルでテキストに頼っています。まず、Envisionコード自体です。これは、文字通り私たちが行っていることをエンコードしています。Excelで推奨注文を生成し、それを誰かが手作業で修正するプロセスは望ましくありません。私たちの目標は、最終的な数字が手動で変更されることなく自動的に生成されることです。変更が必要な場合は（初めは必要な場合もあります）、その変更はワークフローにキャプチャされ、クライアントと議論できるようになります。「生成されたものをなぜ修正したのですか？手動で編集が必要なくなるように何を変更できますか？」または、編集が実際に役立たなかったことがわかることもあります。その知識も取り入れることができます。
title: “JPMまたはJoint Process Manual”
“LLMs"には、テキストを処理するという特性がよく合っています。彼らは生の数値データにはあまり向いていません。ChatGPTに巨大な表をダンプしても、理にかなった回帰は得られません。ChatGPTは、回帰を行うPythonコードの断片しか生成できません。LLMs自体は、単なる巨大な次のトークン予測モデルであり、算術のために構築されていません。そのため、ChatGPTが基本的な数学に失敗するというジョークがあります。しかし、コードやテキストベースの指示を与えると、操作や生成にはかなり優れています。
それがLokadの立場です。私たちは、2020年から2021年のロックダウン中に証明されたように、数か月間人間の介入なしで実行できる高度なサプライチェーンの自動化を持っています。多くのクライアントが白カラー労働者を自宅に送り返したときでも、サプライチェーンは引き続き稼働する必要がありました。一方、倉庫やトラックのブルーカラー労働者は引き続き活動していました。Lokadはすでにほとんどリモートで機能していたため、サプライチェーンの科学者たちは自宅から仕事を続けることができました。それが本当のストレステストでした。私たちのレシピが日々の監督なしでどのように実行されるかを見るためのテストでした。多くの場合、大規模なクライアントは文字通り何百ものプランナーやマネージャー、またはアナリストを持っていましたが、突然そこにいなくなりましたが、サプライチェーンは引き続き稼働する必要がありました。
そして私たちにとって、それは驚くほどうまくいきました。私たちのクライアントの誰もそれで亡くなりませんでした。誰も消えませんでした。そこで疑問が生じます。500人の白カラー労働者なしで12か月または14か月間サプライチェーンを運営できるのであれば、本当に彼らを必要とする必要がありますか？これは、通常、完全に自動化されたシステムを完全に信頼することを恐れる企業があるため、そうできなかった実験でした。しかし、ロックダウンは実質的に彼らを自動化に頼るように迫り、大規模なサプライチェーンを最小限またはまったく手動介入なしで実行できることを証明しました。もちろん、数値レシピを改善する方法については引き続き議論しています。ゼロの協力ではありません。しかし、もはや大規模なチームが各店舗の各SKUに対して日々Excelの修正を行っているのを見ることはありません。
したがって、サプライチェーンの世界がどこに向かっているのかを考えてみると、私にとっては、20年前の金融業界で起こった変化に似ています。取引が電子化されたときの変化です。かつて朝の新聞を読んで、株を手動で買ったり売ったりする人間トレーダーは、大規模な自動化ポートフォリオを持つクオンツに置き換えられました。サプライチェーンでも同じ変革が起こっていると見ています。私たちはその古い夢、サプライチェーンの意思決定を機械化することを解決しました。それが1940年代、50年代、60年代のオペレーションズリサーチ（サプライチェーンの「祖先」）の元々の野望でした。時間の経過とともに、「オペレーションズリサーチ」は独自のサブディシプリンになり、ソルバーに焦点を当てていますが、初期のビジョンを見れば、それがサプライチェーンが望むものです。数学、数値最適化、リソース配分。Lokadではほぼ10年前にそのバージョンを達成しました。ロックダウンは、直接の監督なしに1年以上にわたって機能することを証明した、その規模で機能することを証明したものでした。
今日、多くのクライアントがシステムを完全に自動で実行させています。たとえば、大手フランスのeコマース小売業者であるCdiscountを挙げることができます。彼らの店舗在庫を完全に自動で処理しています。レシピを改善する方法についての議論は続いていますが、日々の「プラスまたはマイナスの単位」アプローチは終了しました。それは2020年に終了し、今も機能しています。
その結果、私は、Excelで1日に1000のSKUを見て、追加注文が必要かどうか、生産が必要か、在庫を移動するか、価格を変更するかなどを決定するために世界中で500万人の人々がいる時代が終わりに近づいていると考えています。在庫マネージャー、需要プランナー、サプライプランナー、カテゴリマネージャー、S&OPアナリストなど、さまざまな職種が同じ日常業務に集約されています。大規模な予算では、1人あたり100のSKUかもしれません。予算が小さい場合は、1人あたり5000のSKUかもしれません。いずれにしても、それが終わりに近づいていると信じています。
なぜ今なのか？何十年もの間、誰もそれらの意思決定をすべて自動化することができませんでした。しかし、ある程度の企業がそれができることを実証すると、他の企業も続くでしょう。大規模なマニュアル計画チームを維持するのは非常にコストがかかりますし、戦略的に方向転換するのは難しいです。複数の国で何百人ものプランナーを再教育する必要があり、20年間同じ日常のスプレッドシートルーチンを行ってきた各プランナーにとっては非常に遅いです。それを変えるのは非常に遅いです。しかし、プログラムだけで行けるようになれば、迅速に方向転換できます。
これが来ているのは、銀行業界で見た変化と同じです。以前は人々が一日中手動で取引していましたが、今ではほとんど自動化されています。私はサプライチェーンでも同じ機械化が進んでいると考えており、引退後に61年間働いた後でも、または法律がどのように変わるかに関係なく、標準的な実践になると信じています。古い方法に固執している多くの企業に出くわすかもしれませんが、その革命は進行中です。
だから私のメッセージは、この変化の積極的なドライバーになるか、ただの乗客になるかのどちらかです。あなたがセントラルの学生であることを考えると、あなたはおそらく観察者ではなく積極的なドライバーになる可能性があるでしょう。
よし、質問に移りましょう。私はあなたに50分間のモノローグを押し付けましたので、これについて質問があれば、どうぞ。
学生: はい、それはこれらの企業がLokadのようなソリューションに依存することを意味するのですか、それとも同様の技術を内部で開発できるのですか？
Joannes Vermorel: 両方が可能です。技術に精通した企業、例えば非常に大きなeコマース企業の場合、時々私たちにトレーニングを受けるためのチームを送り、Lokadが採用しているような慣行を内部化するという考えで。企業が強力なテック文化を持ち、すでに多くを社内で開発している場合、もちろんできます。しかし、彼らの文化が「難しいことはすべて外部委託する」というものであれば、おそらく外部委託するでしょう。全体として、私はほとんどの企業がLokadまたは他の専門プロバイダーと一緒に進むと考えています。もちろん、私は偏見がありますが、Lokadがそのソリューションの1つになると信じていますが、いずれにせよ、革命が起こっていると確信しています。
学生: LLMはエンジニアを置き換えないと言いましたが、LLMを使用しない人だけです。AIを制限する要因は何で、LLMを使用するエンジニアを超えることができないのですか？言い換えると、AIを使用するエンジニアを超えることを防ぐものは何ですか？
Joannes Vermorel: 私が確定的な答えを知っていたら、それは千億ドルの価値があるでしょう。数十年にわたり、人工知能の分野で多くの画期的な発見があり、それぞれが私たちが完全に理解していなかった知性の側面を明らかにしました。何度も何度も、私たちは「本当の」知性が何であるかについて誤解していたことに気づきます。
たとえば、1940年にどのようなものが優れた知性を示すか尋ねた場合、彼らは「行列の対角化ができる人」と言うかもしれません。エコール・ポリテクニークには、行列の対角化のための学科さえあり、知的な達成の頂点と考えられていました。今では、単純なコンピューターアルゴリズムでも行列の対角化ができます。私たちはそれを全く知的とは見なしません。
AIの歴史には20回のエピソードがあり、毎回、私たちが「知性」と考えていたものがそうではないことがわかります。大規模言語モデルには現在いくつかの目立つ欠点があります。使用中に実際には何も学習していません。それらは静的モデルです。プロンプトを与えると、継続を返しますが、それだけです。同じプロンプトをもう一度実行すると、同じ継続が得られます。彼らは会話から学びません。ファインチューニングはできますが、それは外部プロセスです。日々、記憶や持続的な改善はありません。演習を行う人間は何かを学びますが、LLMはそうではありません。同じシナリオを200回実行しても、知識は蓄積されません。
別の奇妙な側面は、LLMが必要とする膨大なデータ量です。子供は最大でも1,000時間の聴取で約3年で話すことを学びます。LLMは明らかにインターネット全体を読む必要があるようです—数十億のトークン。または自動運転車を考えてみてください：彼らは何百万マイルもの仮想または実際のマイルを走行して、人間が20時間のレッスンでマスターすることを学ぶために。なぜ「知性」にそんなに多くのデータが必要なのでしょうか？
ですから、何か根本的に欠けていると感じていますが、正確に何が欠けているのかはわかりません。おそらく、次のLLMのイテレーションや全く新しいアプローチがこれらの欠点を修正するでしょうが、それが明日か20年後か50年後かはわかりません。Yann LeCunのような一部の人々は、LLMアプローチ全体を捨てて他の方法を取るべきだと言っています。私はそんなに確信がありません。おそらく、LLMを微調整して問題を解決できるかもしれません。まだ誰も解決策を持っていないので、私たちは単にわかりません。
とにかく、これらは深刻な制限であり、比較的単純な仕事でもLLMが完全に人間を置き換えるのを阻止します。はい、LLMは使用しないエンジニアを置き換えるでしょうが、それらを使用するエンジニアを必要とする人々は不可欠なままです。
学生: 先ほど、Lokadは最初はうまくいかなかった製品でも利益を上げ続けたとおっしゃいましたが、それはどういうことですか？資金調達や補助金を受けたのですか？それとも他のサービスを提供していたのですか？
Joannes Vermorel: いいえ、補助金や外部資金はありませんでした。説明します：サプライチェーン市場はやや狂っています。競合他社の典型的なビジネスプランは1980年代以来、次のようになっています：ステップ1、多額の資金を調達—数千万。ステップ2、航空宇宙などの特定の垂直に焦点を当て、2〜3年間市場シェアを獲得します。ステップ3、200人の営業担当者を雇用し、市場の20%を獲得し、最終的には崩壊します。繰り返します。
それを常に見ています。Nikeのような巨大企業ですら、2004年には私たちの競合他社のサプライチェーンソフトウェアの失敗により破産寸前になりました。その「Nikeの惨事」は彼らのウィキペディアページに記録されています。彼らは基本的にNikeの生産を9か月間台無しにしました。その間、同じベンダーは多くの顧客を台無しにし、買収され、買収者は最終的に2億5000万ドルの損害を支払いました。私の経験では、エンタープライズソフトウェアでは、平凡でも通常は訴えられませんが、これらの人たちは本当にひどかったに違いありません。しかし、その実績にもかかわらず、彼らは単に新しい会社を立ち上げました—同じ人々—そしてさらに半分以上の10億ドルを調達しました。市場は決して学びません。
実際、私たちの多くのクライアントは、異なるベンダーとのサプライチェーンプロジェクトで半ダースの惨事を経験した後に私たちにやってきます。サプライチェーンの自動化は古い夢です。基礎となるデータは80年代や90年代以来デジタル化されているので、何十年もの間試行してきました。大企業が失敗プロジェクトの山を抱えているのは普通です。
それが私たちが活動している環境です。巨大な慣性があります。人々は忘れます。必要性は残りますので、何度も試みます。市場は遠くから見ると合理的に見えるかもしれませんが、これらの問題を修正するのは遅いです—特にエンタープライズソフトウェアのような不透明な領域では。壊滅的な実装さえも、クライアントはあなたの製品を選んだマネージャーが責められたくないため、結局はあなたに輝かしい事例研究を提供するかもしれません。皮肉なことに、惨事はマーケティングの物語として成功に変えられることがあります。そんなに乱雑になることがあります。
Joannes Vermorel: 他に質問はありますか？私が説明したことはすべて正常で合理的で、ビジネス界から期待されることですか？
わかりました。とにかく、Envisionスクリプトのコーディングに費やしていただいた時間に感謝します。Centralの学生がEnvisionを使っているのを見て、とても誇らしく思います。10年以上前に最初のコンパイラを書いたとき、いつかCentralの学生がそれを使っているのを見る日が来るとは思いもしませんでした。当時はリスクのある賭けでした。ビジネス計画にはEnvisionを使っていただくことは含まれていませんでしたが、それが実現してうれしいです。もしRémiやBasilがまだ言っていないなら、Lokadは採用しています。覚えておいてください！
