00:00:00 インタビューの紹介
00:01:01 AIが伝統的な仕事に与える影響
00:04:36 サプライチェーンにおけるAIの自動化
00:09:08 2012年における統一システムの必要性
00:10:30 システムへの意思決定の再注入
00:13:08 AIにおける幻覚問題の回避
00:16:11 ITの遅れによる影響と遅延
00:20:04 Lokadと他のベンダーのセットアップの比較
00:23:06 LLMの幻覚と誤認識についての議論
00:30:38 AIにおける進歩の重要性
00:33:00 情報の不足と注文のETAの取得
00:36:17 サプライチェーンにおける数量的なタスクとLLM
00:38:28 サプライチェーンにおけるAIパイロットの将来
00:41:18 会話の価値と低価値タスクの自動化
00:44:57 バックログの削減におけるAIパイロットの活用
00:49:00 AIパイロット vs 共同運転者とロックダウンシナリオ
00:53:36 会話型AIとプロセス分析への懐疑心
00:57:18 ビジネスの現実とAIによるプロセスの置換の理解
01:00:12 Envisionのオープンソース化の課題
01:06:21 AIのボトルネックとサプライチェーンへのアプローチ
01:09:17 口頭命令の非効率性と注文の自動化
01:14:12 AIパイロットの共同運転者としてのサプライチェーン科学者
01:17:32 データの正確性のチェックとLLMによる自動化チェック
01:20:15 Envisionをgitに対応させる
01:21:14 Envisionを学ぶための無料リソース
要約
LokadのCEOであるJoannes Vermorelとコミュニケーション担当のConor Dohertyの対話の中で、彼らはAIがサプライチェーン管理に与える影響について議論しています。Vermorelは、タスクの自動化を革新したAIと大規模な言語モデルの進歩について強調しています。彼はAIパイロットを紹介し、Lokadの独自のプログラミング言語であるEnvisionによって支援された意思決定と事務作業の自動化を行うLokadの提供を紹介しています。Vermorelはまた、AIがマスターデータに関連するタスクの自動化を行う潜在能力についても議論し、Lokadのアプローチを競合他社と対比しています。彼はAIパイロットがサプライチェーン管理の標準となり、生産性の大幅な向上をもたらすと予測しています。対話はQ&Aセッションで締めくくられます。
詳細な要約
Lokadのコミュニケーション担当であるConor DohertyとLokadのCEOであるJoannes Vermorelの最近の対話では、人工知能（AI）がサプライチェーン管理における変革的な役割について探求しました。このディスカッションは、AIが雇用に与える影響についての以前の対話の続きであり、サプライチェーンの意思決定のためのスタンドアロンパイロットとしてのAIの潜在能力に焦点を当てていました。
Vermorelは、2023年における生成型AIと大規模な言語モデル（LLM）の画期的な成果を強調しました。彼は、これらの進歩によって、電子メールの読み取りや苦情の分類など、テキストを含むタスクの自動化が革新されたと説明しました。2023年は、企業における自然言語処理技術の運用コストの大幅な削減が見られたため、特に重要な年でした。Vermorelは、これにより多くの内部サポート機能が自動化され、サプライチェーンの運用が先駆けとなると予測しました。
Vermorelは、意思決定プロセスを自動化し、日常的な事務作業を処理するLokadの提供であるAIパイロットを紹介しました。彼は、Lokadの独自のアプローチを強調しました。サプライチェーンサイエンティストがイニシアチブを完全に所有することができると述べました。これは、Lokadの予測最適化に特化したプログラミング言語であるEnvisionによって実現されています。ただし、Vermorelは、Lokadが以前にデータの収集やさまざまなSQLの方言に対処するのに苦労したことを認めました。
Vermorelは、GPT-4の導入により、LokadがSQLクエリの作成を自動化できるようになったと説明しました。これらのクエリは、サプライチェーンサイエンティストによって校正され、精度を確保するためにテストされます。この開発に加えて、安全なクラウド間接続により、Lokadのサプライチェーンサイエンティストチームはクライアントのデータを自分たちで追跡することができ、遅延を減らすことができます。
Vermorelは、LLMがマスターデータに関連する多くのタスクを自動化する潜在能力にも言及しました。これには、調査、監視、改善などが含まれます。彼は、Lokadのアプローチを競合他社と対比し、通常、イニシアチブに関与する人数が少なく、各人がパイプライン全体にわたる能力を持っていると述べました。これは、プロジェクトマネージャー、コンサルタント、UXデザイナー、データベース管理者、ネットワークスペシャリスト、プログラマーなど、多くの人々がイニシアチブに関与する競合他社とは対照的です。
対話は、LLMによって生成されたスクリプトをサプライチェーンサイエンティストが検証または監視する役割について話し合うことに移りました。Vermorelは、LLMが時に不正確なまたは「幻覚的な」結果を生成することがあるが、これらは通常方向性が正しく、フィードバックループを数回繰り返すことで修正できると認めました。彼は、LLMが間違いを comitすることがある一方で、それらはまだ多くの価値を提供し、偽陽性と偽陰性の割合を測定できると提案しました。
Vermorelは、サプライチェーンサイエンティスト、AIパイロット、およびクライアントの間の日常的なオーケストレーションについてさらに説明しました。サプライチェーンサイエンティストによって作成されたAIパイロットは、サプライチェーンの日常業務を管理し、データの準備と発注の決定を処理します。このセットアップでは、クライアントは船長に例えられ、全体的な戦略的な指示を与えます。
サプライチェーンの実践者や経営陣にとってのまとめとして、Vermorelは、10年後にはAIパイロットがサプライチェーン管理の標準になると予測しました。これにより、以前の機能における人員の90%削減の可能性を含む、大幅な生産性向上がもたらされると彼は信じています。彼は、サプライチェーンの実践者に対して、戦略的思考とサプライヤーやクライアントとの深い対話により多くの時間を費やすことを奨励しました。
会話はQ&Aセッションで締めくくられ、VermorelはAIパイロットの役割、ITのバックログ削減におけるAIパイロットとコパイロットの違い、AIモデルを実装する前のプロセス分析の重要性、LokadがEnvisionをオープンソース化する計画、AIがランダムなボトルネックにどのように対処するかについての質問に答えました。また、彼はLokadがLokadコパイロットに取り組んでおり、EnvisionをGitHubとより親しみやすくする計画もあることを確認しました。
フルトランスクリプト
Conor Doherty: Lokadライブへようこそ。私の名前はConorで、私はLokadのコミュニケーション担当です。そして、スタジオにはLokadの創設者であるJoannes Vermorelがいます。
今日のトピックは、AIがサプライチェーンの意思決定のためのスタンドアロンのパイロットとして機能する方法です。YouTubeのチャットでいつでも質問を投稿してください。30〜35分後に回答します。
それでは、Joannes、サプライチェーンにおけるAIパイロットについては、私たちが約4週間前に行ったものと非常に関連していると思います。AIが雇用や伝統的な仕事の将来に与える影響について話しました。
AIパイロットの具体的な内容に入る前に、伝統的な仕事とサプライチェーンにおけるAIについての私たちの見解を簡単にお伝えいただけますか？前回見ていなかった方のために、エグゼクティブサマリーをお願いします。
Joannes Vermorel: リフレッシャーとして、2023年にはほぼ画期的なことが実現しました。この画期的なことは、生成型AI、具体的には大規模言語モデル（LLM）です。純粋な研究の観点から見ると、これは機械学習のほぼ40〜50年にわたる継続的な改善の一環です。研究の観点から見ると、2023年は他の年と同じで、長い進歩の連続です。過去20年間は比較的早いペースで進歩してきました。
さて、2023年に市場に登場したのは、画像やテキストのためのパッケージ化された生成型AIです。そして、その中で最も人気のある製品はOpenAIのChatGPTです。それは具体的には、特に大規模な言語モデルにおいて、ユニバーサルノイズレジリエンステンプレートマシンを持っているということです。
つまり、企業ソフトウェアの文脈で話しているのは、企業環境の白カラー労働者のような労働者を指していますが、過去に自動化できなかったような手順がすべて自動化できるということです。つまり、メールを読み取り、メールから参照や価格、数量を抽出したり、パートナーやサプライヤークライアントからのクレームやリクエストの種類を分類したり、製品ラベルが意味をなさないかどうかを判断したりすることです。たとえば、製品ラベルが文字通り製品の説明がない場合、問題があります。過去にはこれらのようなことは簡単にはできませんでした。他の方法でできることはありましたが、簡単に自動化することはできませんでした。
5年前にさかのぼってみましょう。テキストマイニングはすでに存在していました。テキスト分類器を持つことや、さまざまな自然言語処理技術を使用することはすでに可能でしたが、コストがかかりました。2023年は画期的な年でした。なぜなら、GPT-4をAPIを介して提供することで達成されたパッケージングの度合いにより、すべてのNLP技術の運用コストが企業にとって100倍から1000倍に削減されたからです。つまり、コストだけでなく、設定にかかる時間も削減されました。
したがって、私の予測として、データを受け取り、他の部門に出力を生成するだけの企業の多くのサポート機能が自動化されるでしょう。サプライチェーンは顧客に直接関与しない機能ですので、最前線にあります。それは非常に内部の機能であり、重要な機能ですが、内部のものです。そして、それによって、大規模な言語モデルが供給チェーンのほとんどの日常業務を大幅に自動化するための欠けていた要素となりました。
Lokadは10年間、数量分析と数量的意思決定プロセスを自動化してきましたが、それ以前に行われる日常業務やそれ以降に行われる日常業務がたくさんあります。そして、それが大規模な言語モデルによって自動化されるものであり、迅速かつ安価に行われるものです。
Conor Doherty: それでは、ありがとうございます。私たちはすでにそのトピックについて1時間半ほど話したビデオがありますので、今日はそれ以上の時間を割くことはありませんが、それが今後の会話の土台を築いています。それについてもっと聞きたい方は、前のビデオをご覧ください。さて、それに関連して、AIパイロットは、先ほどお話ししたすべてにどのように組み込まれるのでしょうか？それらは何ですか？現実ではどのような役割を果たしていますか？
Joannes Vermorel: AIは一般的にはベンダーによって過去20年間一貫して使用されてきましたが、それは彼らが持っていたものを投げるためのキャッチフレーズや総称的な用語でした。ですので、私がAIパイロットと言うと、それはLokadの提供の一部です。それは提供の進化であり、数年来の最大のものです。そして、その違いは、AIパイロットがソフトウェアの一部であるということです。私たちが数値レシピのシリーズと呼ぶものであり、それは意思決定プロセスを実行するだけでなく、サプライチェーンの純粋な数量的側面です。つまり、正確にどれだけ注文するか、在庫をどこに割り当てるか、価格を上げるか下げるか、どのように生産をスケジュールするかなど、すべてのステップを正確に把握することです。
これは私たちがすでに行っていたことですが、データ分析の前に行われるほとんどがマスターデータ管理に関連する日常的な事務作業や、データ分析の実行の前後に来るものであり、それにはメールなどの非構造化チャネルも含まれます。たとえば、何かを迅速に依頼するためにサプライヤーにメールを送信したり、逆に注文を延期したりするためにメールを送信したりする場合です。
そして、この提供の要点は、もちろんLokadが発明した大規模な言語モデルです。私たちは14か月以上、それを広範に使用してきました。そして、Lokadが運営する方法の鍵となる洞察は、イニシアチブ全体を完全に所有できるサプライチェーンサイエンティストがいるべきだということです。
大規模な企業では、複数の人々が関与する場合もありますが、私たちの競合他社のほとんどとは異なり、彼らは通常、専門化されていません。私たちの運営方法は、3人のチーム（データベース担当者、アルゴリズム担当者、UIおよびUXユーザーエクスペリエンス担当者）を組むわけではありません。それはLokadの運営方法ではありません。サプライチェーンサイエンティストは、最初から最後まですべてを行うことができます。
それがLokadが独自の技術を開発した理由の1つであり、私たちが独自のプログラミング言語、Envisionというドメイン固有のプログラミング言語を持っている理由です。独自のプログラミング言語を作成することは非常に奇妙に聞こえるかもしれませんが、その要点は、私たちが2012年に決定したことです。私たちは、1人の人間が最初から最後まですべてを行うことができるように、統一されたものが本当に必要でした。
数年前までは、ERPs、CRMs、EDIなどのトランザクションシステムから生のトランザクションデータを取得し、それに加えて通常のITではなくシャドウITの一部である構造化データのスプレッドシートの配列を完全に組み合わせ、意思決定の数値レシピを作成していました。これはサプライチェーンの科学者の責任であり、それに加えてダッシュボードやレポートなどのすべての計測機器を作成し、数字が正しいことを確認するだけでなく、自社のクライアントにも私たちの取り組みの妥当性を保証するためのものでした。さらに、時間の経過に伴う意思決定の品質を監視するための計測機器、システムからデータを取り出すための配管、そして意思決定をシステムに再注入するための配管もありました。
それがLokadの範囲であり、私たちが本当にできなかった2つのことがありました。まず、データの受信者でなければなりませんでした。データを探すことは本当にできませんでした。そして、私が言う「探す」とは、サプライチェーンの科学者がデータを要求することができ、私たち自身のクライアントのIT部門に特別な変換を依頼することはありませんでした。それはほとんどテーブルをダンプするだけのものでした。一日に一度やるだけで終わりです。非常にシンプルな抽出でしたが、それでも私たちのクライアントのIT部門がそれを行っていました。
サプライチェーンの科学者は、イニシアチブが必要とするデータをクライアントのアプリケーション環境で探すことは期待されていませんでした。その理由は非常に単純で、20以上のSQL方言が存在するからです。例えば、Oracle SQL、Microsoft SQL Server T-SQL方言、MySQL、PostgreSQL、IBMのDB2などがあります。だから、20以上のSQL方言があります。数年前までは、サプライチェーンの科学者は非常に苦労していました。たとえこの人が達成したかったことが非常に簡単で、単に単一のテーブルをダンプするだけであっても、この人は文字通り数十時間をオンラインで検索して、些細なクエリを作成するために時間を費やさなければなりませんでした。そして、エラーメッセージがあるたびに、この人がそれに対処しなければなりませんでした。この人が一般的にSQLデータベースに精通しているとしても、知らないシステムの方言に対処するのは非常に困難なことでした。
2023年、ChatGPTによって、この問題は解決されました。ChatGPTはアシスタントプログラマーとしてはあまり高度ではありませんが、数十の方言で非常にシンプルなSQLクエリを作成する際には非常に高速です。サプライチェーンの科学者はSQLクエリの作成を要求します。この人はまた知識があり、クエリが意図を反映していることを校正します。構文を発見するという障壁を取り除くだけですが、正しい構文が提示されれば、それはほぼ自己説明的です。
自分自身でテストしてみたい場合は、ChatGPTに自分のマシンにgitをセットアップし、gitリポジトリをセットアップするように歩き回ってもらうように依頼してみてください。どのような高品質な回答が得られるかを見ることができます。
それは本当にゲームチェンジャーです。これにより、サプライチェーンの科学者をトレーニングしているLokadは、データを探す責任を負うことができます。そして、私たちはChatGPTを通じて、データを探しに行くということに過度に取り組むことはないようにツールを持っていることを知っています。これはゲームチェンジャーです。ITにデータを送ってもらうのではなく、IPアドレスをホワイトリストに登録し、非常に安全なクラウド間接続を確立し、サプライチェーンの科学者のチームに自分たちのデータを追いかけさせることができます。
なぜそれが大きな違いを生むのでしょうか？実際のところ、Lokadが特定のイニシアチブに必要な作業日数は数日であるとしても、必要な20〜50のテーブルを取得するためには、おそらく10〜20日の作業が必要です。テーブルをダンプするだけで、結合やフィルタリングなどは行われません。非常にシンプルですが、問題は、多くのクライアントが自社のIT部門を持っており、巨大なバックログを抱えているということです。文字通り数年のバックログがあります。3年分のバックログがある場合、Lokadがたった10日を要求しているとしても、それは10日プラス3年分のバックログです。したがって、私たちがキューの最後に置かれるわけではないとしても、キューの中間にいる場合、ITからの10日間の作業は1年かかるかもしれません。私たちが抱えていた不満は、遅延の大部分がITからのものであり、彼らが無能で遅いわけではないということです。ただ、彼らは非常に多くのバックログを抱えていたため、それらの10日間を割り当てることが非常に困難でした。
ここでは、10〜20日間の作業を要求する代わりに、わずか1日未満、数時間で済むようなものについて話しています。必要なシステムへの非常に安全で厳格なアクセスを開くだけで、サプライチェーンの科学者自身がテーブルを調査し、データ抽出ロジックを設定し、データ抽出が本当に軽微であることを確認します。
これを行う方法は、通常、パフォーマンスを監視することです。データベースのパフォーマンスが低下すると、データベースで多くの処理が行われていることを意味し、自分自身のデータ取得プロセスを遅延させる必要がある場合があります。通常、Lokadではデータを毎日更新する必要がありますが、非常に緊急性があるわけではありません。もちろん、状況によりますが、サプライチェーンに関しては、データの取得を30分遅らせても、データベース上でのアクティビティが急増しているだけであれば、問題ありません。
最初のコミットメントのブロックは、データを追いかけることであり、遅延の主な原因を排除し、イニシアチブを大幅に加速させることです。再度、これらの遅延は、Lokadのイニシアチブ全体のプロダクションへの移行の遅延の大部分が、ITがこれらの日数を割り当てるのを待っているだけであることが非常に頻繁にありました。
2番目のコミットメントのブロックは、マスターデータの改善です。過去において、カタログには10万の製品説明がある場合、そのうちの1%はゴミです。これらの10万の参照を調べ、説明や製品ラベルが間違っているものを特定する作業は非常に大変でした。時には、価格が説明とまったく矛盾している場合もあります。例えば、ネジと書かれていて価格が2万ドルの場合、それはおそらくただのネジではなく、他の何かです。これらは明らかでシンプルな作業ですが、自動化するのは非常に困難であり、本当に悪いものを探すためにエントリをスクリーニングするためには、人が行うしかない場合が頻繁にありました。
LLM（おそらく画像も処理できるLLM）を使用すると、マスターデータに関連する調査、監視、および改善に関して多くのことができます。Lokadの場合、サプライチェーンのパイロットに必要なマスターデータの部分です。
Conor Doherty: それはたくさんのことがありますね、ありがとうございます。追加の質問がたくさんあります。私は少し立ち戻りますが、あなたが説明していることを簡単にまとめると、もし私が間違っていたら訂正してください、1人のサプライチェーンサイエンティストが1つの優れたLLMにアクセスできれば、多くの作業ができるということです。この瞬間までには多くの時間と多くの人々が関与する作業が必要でした。では、Lokadのスタイルではないセットアップの場合、関与する人々はどれくらい増えるのでしょうか？関与する人々はどれくらい多くの仕事をするのでしょうか？そして、効率について話すことができますが、単に人数に関して言えば、サプライチェーンサイエンティストと、例えばS&OPとの違いは何ですか？
Joannes Vermorel: 私たちのクライアントは、大規模なイニシアチブでさえも2〜3人であることに驚いています。そして、常に同じ人々です。私たちはLokadを持っていますし、Lokadとして、私たちは長い間人々を維持することができることを非常に誇りに思っています。つまり、Lokadは通常、始まりから終わりまで1%です。複数の人々がいる場合、それは再び冗長性を持つためです。ある日はパイプラインのこの部分に集中し、私は別のパイプラインのこの部分を行います。そして次の日には切り替えます。人々が専門化していないわけではありませんが、各人はパイプライン全体にわたる能力を持っています。いくつかのバリエーションや、特定の専門性を持つ人々もいますが、全体として、人々は本当に他の人の代わりになることができます。
競合他社は非常に異なります。小規模なイニシアチブでも、文字通り数人が関与します。プロジェクトマネージャーが他の人々を調整するためにいるでしょうし、コンサルタント、UXデザイナー、設定者、データベース管理者、ネットワークスペシャリスト、そしてネイティブでないカスタマイズのためのプログラマー、ソフトウェアエンジニアが必要になるかもしれません。再び、Lokadはプログラム可能なプラットフォームですが、私たちの競合他社のほとんどはプログラム可能ではありません。したがって、プログラム的な振る舞いを持つものを望む場合、JavaやPythonのような汎用プログラミング言語を使用して実装するために、フルフレッジのソフトウェアエンジニアが必要です。ですから、Lokadは本当にそうではありません。私たちの競合他社は、デフォルトで数人です。S&OPのイニシアチブには数十人が関与する場合もありますが、それほど多くの異なるスキルが必要ではなく、ほとんどが異なる部門の人々であり、頻繁にIT主導ではありません。
ですから、Lokadは、1人対数十人という比較を言っているのは、APS（高度な計画システム）や在庫最適化システムなどのエンタープライズソフトウェアを販売している競合他社と比較しています。
Conor Doherty: ありがとうございます。サプライチェーンサイエンティストについて話し戻すと、SQLの方言の例を挙げ、特定のクライアントの方言に堪能であるかどうかを持つサプライチェーンサイエンティストが、自動生成されたスクリプトを検証または監視するという例を挙げました。なぜなら、LLMは時折幻覚を見ることがあるからです。
実際、LLMは非常に頻繁に幻覚を見ます。改善はされていますが、テキストの一部でLLMに「この単語を見つけて、隠れているのを見つけられますか？」と尋ねると、「はい」と答えることがありますが、実際には存在しません。私もそれが存在しないことを知っていますし、あなたもそれが存在しないことを知っています。スケールでLLMを活用する際にセキュリティと品質管理をどのように確保しますか？
Joannes Vermorel: 幻覚、または私が好むところの「confabulations（思い込み）」は、LLMをすべての知識ベースとして使用する場合に実際に起こります。もしLLMをすべての知識ベースとして使用する場合、それは起こります。医学の論文を求めて「この病理学に関する論文のリストを教えてください」と尋ねると、方向性は正しいものを返します。著者は頻繁に存在し、彼らは出版物を持っており、この分野に関連するものや同じようなものを出版していますが、完全には一致しません。これは、科学者に頭の上にあることを覚えてもらうようなものと考えてください。
それは非常に困難です。もしやらなければならないと言った場合、彼らはおそらく、同僚や研究者の正しい名前、正しい半正確なタイトルなど、半ば信憑性のあるものを考え出すでしょう。それが思い込みが生じる状況ですが、それを求めているのです。つまり、LLMにすべてのデータベースのように振る舞うように求めているので、非常に困難で、このような問題が発生するでしょう。
SQLの方言でも同じことが起こります。試してみると、このようなものが得られますが、それはおおよそ正しいものです。例えば、「テーブルを読みたい」と尋ねると、「select star from table」ということを行います。GPT-4でテーブルを読むように頼むと、「テーブルを削除する」とは返ってきません。少し不適切な構文を返すかもしれませんので、SQLクエリをテストするとエラーメッセージが表示され、少し調整すれば動作します。しかし、それでも方向性は正しいです。データベースを読むように頼むと、テーブルを削除するコマンドやデータベースの権限を変更するコマンドは生成されません。
作り話の知識を求める場合も同じです。例えば、「20キロワットの工業用圧縮機の価格はいくらですか？」と尋ねると、GPTはおそらく1万ドルのような回答をします。これは完全に作り上げられたものです。それは妥当な推測ですが、正しいですか？おそらくそうではなく、さまざまな状況によって異なります。
つまり、思い込みはランダムに起こるわけではありません。特定の種類のタスクでは、より頻繁に発生します。ですので、LLMをすべての知識ベースとして使用する場合、二重チェックする方が良いと言えます。それは非常に役立つことがあります。例えば、SQLの方言の場合、使用すべきキーワードや構文の見本を提供してくれます。少し間違いがあるかもしれませんが、数回の反復を経て正しい結果が得られます。特に、SQLクエリを持っている場合、実際にデータベースでテストすることができ、出力を確認して検証することができます。つまり、瞬時に検証するためのフィードバックループがあります。
例えば、不正な製品ラベル、この製品の説明が欠落しているなど、怪しい製品ラベルを検出したい場合、それはあなたの製品ラベルです。それは明らかに間違っています。しかし、さまざまな種類の間違いがあります。例えば、「tournevis cruciforme」というフランス語の製品ラベルがあります。これはフランス語で、おそらくPhillipsヘッドのドライバーです。そして、再び、あなたは何かを求めることができますが、ある時点で完璧ではありません。これは判断の問題です。人間も同じように間違いを comit することがありますので、LLMがすべての質問に正確に答えることができるエンドゲームの神託であることを期待することはできません。ある時点で、カタログの10万個の製品を異常なラベルでレビューするなどのタスクを行っている場合、LLMも人間と同様に誤検知と誤検出を行うでしょう。しかし、興味深いことに、誤検知と誤検出の割合を実際に測定し、それがそれに値するかどうかを判断することができます。そして非常に頻繁に、まだいくつかの間違いを comit しているものの、かなりの価値を提供してくれるものが得られます。
Conor Doherty: 進歩は完璧ではなくてもいい。
Joannes Vermorel: まさにその通りです。もし非常に安価で数時間で再実行できるもので、マスターデータの問題を90%削減できるなら、それは非常に良いことです。
Conor Doherty: それに加えて、手動で行わなかった時間の価値もあります。他の価値を生み出すか追加することができるかもしれません。したがって、価値の直接的および間接的な要素があります。
Joannes Vermorel: さらに、1時間にわたって非常に繰り返しの多いタスクを行う場合、一定の品質レベルを持つことができます。しかし、100時間続けると、通常、人間は一定のパフォーマンスを維持することはできません。数時間後には、集中力が低下し、誤検知や誤検出の量が急増する可能性があります。それは、非常に熱心な従業員であっても同様です。
Conor Doherty: ありがとうございます。実際には、観客からの質問がいくつかあり、私が尋ねる予定だったことに対処する質問が実際にありますので、いくつかのことをスキップしますが、観客の質問でそれらが取り上げられます。しかし、最後にここで考えておきたいことは、サプライチェーンサイエンティスト、AIパイロット、そして後で質問に戻ってきますが、サプライチェーンサイエンティスト、AIパイロット、およびクライアントのオーケストレーションは実際に日常的にどのように機能するのでしょうか？クライアントはアクセス権を持っていますか？LLMとやり取りしますか？
Joannes Vermorel: 通常、サプライチェーンサイエンティストによって構成される数値レシピ全体がAIパイロットと見なされます。これは、サプライチェーンを日々パイロットするものです。それは無人であり、意思決定を生成します。そして、LLMはデータの準備とPOの意思決定の細部も処理します。たとえば、事前の意思決定では、MQSをサプライヤーに要求します。この情報を取得する必要があります。情報が欠落しているか最新ではない場合は、変更する必要があります。LLMはその手助けをすることができます。事後の意思決定では、EDIがない場合やブリッジがない場合に、注文のETA（到着予定時刻）を尋ねるためのメールを送信したり、注文を急ぐように依頼したり、延期したりすることになります。これは、Lokadが注文を急ぐように依頼する意思決定を生成するが、ただ単にメールを作成して送信する細部ではありません。
これらすべてがほぼAIパイロットであり、プロセスを終端まで実行する大規模な数値レシピです。これらすべてはサプライチェーンサイエンティストによって実装されます。したがって、これはLokadのスコープの拡張です。サプライチェーンサイエンティストは実際には共同パイロットです。そして、私がパイロットと言うとき、私は本当に航空機の自動パイロットのことを指しています。ちなみに、現在の航空機では、最も難しい機動はオートパイロットで行われます。香港の旧空港のような非常に怖い空港では、新しい空港の方が簡単ですが、高層ビルの中にある空港もあります。その場合、オートパイロットはその機動のために必須です。それは機械がすべて行います。人間は単に監視するだけです。
したがって、サプライチェーンサイエンティストは数値レシピを設計し、共同パイロットとしての役割を果たします。彼らは方向を決定し、事前に考えて、パイロットができるだけスムーズに操作できるように計画とコースを設計します。しかし、基本的には、高頻度の調整はパイロットが行い、共同パイロットではありません。そして、クライアントはキャプテンの役割を果たします。
昔のテレビシリーズ、スタートレックのように、キャプテンが椅子に座ってクルーに超高レベルの指示を与えるようなものです。したがって、このセットアップでは、クライアントが戦略を提供し、全体的な指示を与えます。それから、サプライチェーンサイエンティストがそれを実装し、パイロットの役割は、サプライチェーンに必要なすべてのマイクロ調整または日常的な意思決定を実行するだけです。
Conor Doherty: そして、これはまた、明確にするために言っておくと、すでに行われているすべての自動化された数量的なタスクに加えてのことです。それらは何年も前から行われています。ですので、もし誰かが聞いていて、「ああ、それは単なる質的なタスクだ」と思っているなら、私たちはエンド・トゥ・エンドで話しています。はい、経済ドライバーの要素化、割り当ての生成、購買、価格設定など、量的なタスクもすでにAIによって駆動されて自動化されています。
したがって、サプライチェーンサイエンティストは、数量的なものと質的なものの両方を監督しています。
Joannes Vermorel: まさにその通りです。Lokadが最後にこのAIキーワードを受け入れ始めた理由は、私たちがLLMを追加しているからです。私たちはすでに異なるプログラミングと確率的最適化による機械学習を持っていましたが、今はそれにLLMを追加しています。それによって、非常に完全なツールキットができました。
その結果、クライアントにとっては、数週間にわたって監視なしで実行できるサプライチェーンが実現します。経済ドライバーがあると、実際にはどれだけ長い間でも完全に監視なしで運用できることに人々は驚くでしょう。その美しいところは、予測の微調整などを行う必要がないことです。たとえば、予測の調整は、ほとんどのクライアントにとって完全に存在しないものです。その他のほとんどの調整も完全に自動化されています。例えば、新製品の導入、旧製品の段階的廃止、新しいサプライヤーの導入、パフォーマンスの低いサプライヤーの段階的廃止などです。
したがって、すべてがいつものように進行し、レシピが正しく行われていれば、過去に比べて多くの介入は必要ありませんでした。しかし、このAIパイロットにLLMが含まれているため、新しいサプライヤーを組み合わせるなど、これらのことは以前よりもさらに手動の介入が少なくなる可能性があります。
Conor Doherty: オーケー、ジョアネス、ありがとうございました。約40分間お話ししてきましたので、質問に移りたいと思います。しかし、それに入る前に、先月の大きな会話の文脈と今日の会話の文脈で、サプライチェーン実践者と、平均的な通常のサプライチェーン実践者を監督するエグゼクティブチームの両方にとって、まとめや締めくくりの考えとして、行動への呼びかけやまとめは何ですか？
Joannes Vermorel: 私は10年後には、AIパイロットというビジョンが、別の名前の下であるかもしれませんが、当たり前のことになると思います。おそらくそれが当たり前になり、サプライチェーンと言うだけで、AIパイロットのことを言わなくなるでしょう。サプライチェーンにはAIパイロットがあるということが当然のことになるでしょう。コンピュータと言うときに、CPUがあるとかメモリがあるとは言わないでしょう。コンピュータにはCPUがあるということが当然のことなので、それを言及する必要もありません。
私の考えでは、10年後には、これらの機能は広範に自動化され、LokadではAIパイロットを備えたパッケージが提供されています。私たちのクライアントにとって、それはサプライチェーンの実践が変わることを意味します。彼らはAIパイロットを持っていて、多くの帯域幅を解放することができます。私たちはすでに意思決定プロセスや複雑な計算のための帯域幅を解放していました。しかし、今では、SKUのリスト、サプライヤーのリスト、顧客のリストを監視するために費やされていた時間も解放されます。これにより、マスターデータを正確でクリーンで健全に保つために頻繁に行われていた手動の介入の必要性もなくなります。ラベルを修正したり、エントリを修正したり、重複を削除したりする必要がありました。これらすべても、再びLokadが対応します。
つまり、これは大幅な生産性の向上です。一部のクライアントでは、繰り返しのタスクにおける人員削減が実際に90%に達しています。現実的には、今ではより多くの時間があり、自動化が困難な作業に取り組むことができます。そして、それがより多くの価値を生み出すと私は信じています。つまり、戦略について注意深く考え、スプレッドシートに時間を浪費する代わりに、どのようなオプションを探索すべきかを考えるためには、より多くの時間を費やすことができます。
ですので、困難な問題について長時間考え、サプライヤーや顧客と話し合い、自社のサプライチェーンを整理してサプライヤーを満足させることで、より良い価格を得ることができます。品質が向上し、信頼性が向上します。サプライヤーのニーズに合わせて自社を組織することで、逆に聞こえるかもしれませんが、“サプライヤーに合わせる"ことができれば、チームの努力となり、信頼性と価格が向上します。
同様の取り組みを顧客とも行うことができます。また、それには多くの知的な議論が必要です。これは、現在のLLMでは提供できないようなものです。ですので、Lokadでは、私たちは低価値な細部や日常的な事務作業を自動化し、人々には高レベルな準戦略的な仕事をしてもらいたいと考えています。私は準戦略的と言っていますが、一度に1人のクライアントと話し、それを要約し、ビジョンを作り、サプライチェーンのリーダーシップをサポートする戦略を実行します。これにより、彼らの会社に対して非常に明確で根拠のある戦略を持つことができます。
Conor Doherty: ですので、2つの例を挙げて概念化するために再度言いますが、低レベルの決定は、Excelスプレッドシートを通じて行われるもので、「黒であるべき」と書かれているブロックを見つけて自動修正するようなものです。それは些細であり、日常的であり、時間の価値はありません。一方、「ハンブルクに倉庫を開設すべきか？」というのは戦略的な問題です。
Joannes Vermorel: はい、それは戦略的な問題です。さらに問題なのは、選択肢が非常に多いということです。倉庫を買うべきか、借りるべきか、どのような契約を結ぶべきか、機械化の程度はどうすべきか、機器のための契約を結ぶ必要があるのか、機器をリースすべきかどうかなど、何百もの質問があります。そして非常に頻繁に、これらすべての質問は、人々が99%の精神的な帯域幅を事務作業に費やさなければならないため、これらの大きな問題に時間を割く余裕がありません。
Joannes Vermorel: わかりますか、もし私がパーキンソンの法則を適用すると、人々は言うでしょう、「ABCクラスのようなものに費やされる時間の合計を計算した場合、毎年、ABCクラスに投資される人年がかかる」と。そして新しい倉庫を決めるときには、数週間の時間がかかります。しかし、人々がABCクラスのような完全に無意味なことに集合的に何年もの人間の時間を費やすという不均衡が見えます。そして5000万ユーロの投資で倉庫を開くときには、数週間の時間がかかり、それからバムという決定が下されます。逆になっているのがわかりますか。
Conor Doherty: わかりました、ありがとうございます。それでは、オーディエンスの質問に移ります。私が止めるまで、どんどん質問を送ってください。では、ジョアネス、これはマッシモからの質問です。AIパイロットを活用してバックログを減らす方法について詳しく説明していただけますか？また、なぜこのアプローチを提案するべきだと考えているのですか？
Joannes Vermorel: AIパイロットは、ITのバックログを減らすことについてではありません。それは、ITが数年にわたるバックログを抱えているという事実に対処するためのものです。私たちの計画は、LokadではITのバックログを減らすことではありません。それは、AmazonがやったようにITを再考することを必要とします。それは別のエピソードになるでしょう。AmazonのAPIに関するジェフ・ベゾスの2002年のメモを探してみてください。要するに、現代の企業のすべての部門が大量のソフトウェアツールを必要としています。マーケティング、ファイナンス、会計、サプライチェーン、販売のすべての部門が、大量のソフトウェアツールを求めていますが、それらすべてがITの肩にかかっています。ITはそれに耐えられなくなっています。
ですので、私のポイントは、Lokadではサプライチェーンの専門家です。私たちはマーケティングや販売、会計などのすべてのことに取り組むつもりはありません。私たちが言っているのは、LLMを使えば、LokadのケアをITから解放できるということです。要するに、Quantitative Supply Chainのイニシアチブを立ち上げ、パイプラインを構築するためにITから必要な作業量が10から20日間必要だったところを、わずか数時間で済ませることができるのです。ですので、私たちはバックログを解決しているわけではありません。ITはITの仕事をします。彼らもLLMを利用することができますが、彼らの場合、状況ははるかに多様で、はるかに困難です。
ですので、私の提案は、LLMが実際にITがバックログを削減するのに役立つというものではありません。これは、Lokadの場合に限定して、バックログに20日間追加する代わりに、わずか4時間追加するという方法です。それが私たちがバックログに対処する方法です。そして、より一般的には、バックログの解決策は、すべての部門がほとんどのソフトウェアを内部化する必要があるということです。企業全体で求められているものがITに対してあまりにも多すぎるのです。マーケティング、販売、会計など、すべての部門にデジタルの専門家が必要です。それらの問題をすべてITに解決してもらう必要はありません。それを行うために、各分野にデジタルの専門家を配置すべきです。これが、ジェフ・ベゾスが2002年のメモで述べた本質です。もし私が間違っていなければ、彼は「各部門がすべてのデータを公開できるようにするための計画を2週間以内に私の机に持ってくる」と言っていました。それによって、会社内でのこのようなシーローや権力闘争が行われないようにするのです。
ベゾスは締めくくって、「2週間以内に私の机に計画がないすべてのマネージャーは解雇されるか何かだ」と言っていました。
Conor Doherty: なるほど、ありがとうございます。次のコメントは、質問としては聞いていなかったので、コメントとして書かれていますが、質問として受け取ってください。これはジェシーからのものです。「1人のサプライチェーン科学者と1つのLLMはまだコパイロットのように聞こえます。ですので、AIパイロットとコパイロットを区別して説明してください。」
Joannes Vermorel: パイロットと言っている理由は、いくつかのクライアントでは数週間にわたって、すべての意思決定が生成され、その後無人で実行されているからです。そして、無人であるというのは本当に無人であるという意味です。2020年のロックダウン中、ヨーロッパではいくつかの国が補助金を提供して、実質的に家にいて働かないようにしていました。そして、そのような状況でした。ですので、私たちは14ヶ月間、補助金を受けて在宅勤務をしているホワイトカラー労働者がいる企業もありました。ですので、私たちはそれをパイロットと呼んでいます。システムによって生成された数値を監視する人がいない場合、私は本当にそれをパイロットと考えています。
しかし、当時はLLMを使用していませんでした。そして、データはクリーンであり、このマスターデータ管理を改善する必要性もありませんでした。そして、そのクライアントはEDI統合などにおいて非常に高い成熟度を持っていました。ですので、前後に必要だったことは非常に限られていました。
とにかく、コパイロットの問題に戻りましょう。Lokadの競合他社のほとんどは、彼らがコパイロットを行っていると言っています。そして、彼らがそれを行う方法はまったく異なります。Lokadのサプライチェーン科学者はプログラミング言語を使用しています。ですので、LLMを使用するのは、プログラムの一部を生成するためです。それが私たちがそれを使用する目的です。
ですので、LLMは、SQLの方言やその他のいくつかのプログラムの一部を生成するために使用されます。そして、私たちはパイロットを設計し、パイロットを無人で実行します。
特に、市場に会話型AI、会話型UI、ユーザーインターフェースを導入すると言っている競合他社は、まったく異なることをしています。彼らが行っているのは、通常、検索補完生成（RAG）です。彼らはプロンプトを作成します。これは、現在のサプライチェーン領域でAIをLLMと一緒に行っているすべての競合他社です。彼らは、さまざまなシナリオに合う数個のプロンプトを作成します。そして、プロンプトの後に、データベースから取得したデータを挿入します。基本的な記述統計情報などです。ですので、いくつかの数値を挿入します。例えば、過去1週間、過去1ヶ月、過去1年の平均販売など、シナリオに合った基本的な統計情報です。そして、ユーザーからの追加のクエリを追加し、LLMが回答を完成させます。
ですので、これは再び、LLMはテキストの補完についてです。テキストを作成して補完します。そして、検索補完生成では、検索部分はデータベースから数値を取得し、それを組み合わせます。しかし、結局のところ、質問をすることができるようになったとしても、画面から数値を直接読むことができるなら、魔法はありません。ですので、LLMは、あなたがレポートで見ることができるように、数値を見るだけです。基本的には、ダッシュボードで簡単に答えられる質問のみに答えることができます。
ですので、もし数値の定義に本当に詳しくない場合、それを明確にすることができます。しかし、Lokadが行っているのは、ダッシュボード上に表示されるすべての数値に対して、1行の説明を付けたチートシートを作成することです。これにより、まったく同じ役割を果たすことができますが、AIは関与していません。
ですので、結論として、私は会話型AIやコパイロットに非常に懐疑的です。なぜなら、それらは実際には既存のシステムの上に重ねられたギミックであり、機械学習システムのために設計されたことがないシステムです。古典的な機械学習でさえも、LLMなどは考慮されていません。
ですから、私の知る限り、競合他社はすべて、ダッシュボードの上に配置されたチャットボットのようなコパイロットを使用しています。しかし、それは何の自動化も行いません。AIパイロットを自動化することはできません。それは、レガシーシステムの上にあるギミックです。
Conor Doherty: では、ありがとうございます。次の質問はKyleさんからです。「AIモデルを導入する前に、プロセス分析の重要性について話していただけますか？」サプライチェーンの文脈でお願いします。
Joannes Vermorel: 驚くべきことに、プロセス分析は非常に重要です。ただし、人々が考える方法とは必ずしも同じではありません。実際のところ、特にサプライチェーンでは、企業は数十年以上にわたって多くのでっち上げのプロセスを考案してきました。そして、私は「でっち上げ」という言葉を意図的に使用しています。サプライチェーンは官僚制のゲームです。それには官僚制の核があります。過去50年間のサプライチェーンのゲームは、労働力を組織化するための方法でした。1人の人間がすべてのSKU、すべての倉庫、すべての場所、すべての製品を扱うことはできません。したがって、問題を分割して解決する必要があります。大規模な企業では、数十人、おそらく数百人にわたって作業量を分散させる必要があります。
そのため、作業量が多くの人々に分散されることによって生じる偶発的な問題を反映したプロセスが90％を占める状況になります。つまり、本質的な問題ではなく、偶発的な問題です。ですので、プロセス分析を行う必要があると言えますが、注意が必要です。既存のプロセスの90％は、サプライチェーンが直面している基本的な問題に対処していません。代わりに、解決すべき問題の10％に対処するために必要な多くの人々によって作成された偶発的な問題です。
化学プロセスなどの産業では、多くのフローと依存関係が存在するため、非常に複雑です。たとえば、化学反応がある場合、副産物が発生します。したがって、化合物を生成するたびに、他の何かも生成されます。この他の何かは販売されるか、別のプロセスで使用されます。それらをすべて調整する必要があります。制約がたくさんあり、バッチで動作するプロセスと連続的に動作するプロセスがあります。非常に複雑です。
しかし、現実の問題の物理的側面に焦点を当てる代わりに、プロセス分析はAIパイロットを設定するときに消えてしまうプロセスを逆にエンジニアリングする可能性があります。
興味深いことに、AIパイロットスタイルで行うと、もはやこの分割して征服するアプローチは必要ありません。それは、問題を終端まで解決する統一された数値レシピのセットです。多くのプロセスによって解決されていたすべての調整問題は消えてしまいます。
私の経験では、これらのプロセスの90％は終了時には存在しなくなるでしょう。そのため、サプライチェーンの基本的な物理的レイヤーに鋭い焦点を当てることが非常に重要です。多くのチームを調整するために存在するでっち上げのプロセスではありません。これらのものはアップグレードされるのではなく、AIパイロットによって置き換えられます。
Conor Doherty: ありがとうございます。実際に、その回答で挙げた例がここでうまくつながります。Durveshさんからの質問です。「教育や中小企業向けにEnvisionをオープンソース化する予定はありますか？また、化学などのB2Bビジネスに利益をもたらすためのルールをプログラムできますか？」
Joannes Vermorel: はい、いずれEnvisionをオープンソース化する予定があります。しかし、まずなぜオープンソース化するのかを説明させてください。エンタープライズソフトウェアの世界では、Envisionの公開ドキュメントがあります。私の同僚のほとんどはドメイン固有の言語（DSL）を持っていますが、公開されていません。ダッソーシステムズは別の会社であるQuintiqを買収しました。その時、DSLが付属していましたが、公開されていません。したがって、サプライチェーンの領域では、DSLを持つ他の企業があり、それらは公開されていません。Lokadでは、すべてを公開文書化しており、Envisionのための無料のサンドボックス環境も提供しています。さらに、無料のワークショップもありますので、実際にEnvisionを教えたり学んだりすることができます。私たちはもっと多くのことをしています。
さて、言語をオープンソース化するときは、計画の一部ですが、まだ早いです。なぜなら、Envisionはまだ急速に進化しているからです。コンパイラをオープンソース化すると、Lokadの場合、Envisionコードを実行する人々が実際に野生で操作することを意味します。そして、Lokadはそれらのスクリプトを自動的にアップグレードする可能性を失います。実際、過去10年間でLokadは何百回もEnvisionプログラミング言語を変更してきました。この言語は安定していません。私の本であるQuantitative Supply Chain bookを見てみると、Envisionの構文は劇的に進化しています。Envisionにはもはや存在しない遺伝的な構文をのぞいてみることができます。
では、この構文の絶え間ない変化にどのように対処するのでしょうか？Lokadでは、毎週火曜日に週次リリースを行っており、Lokadプラットフォームで操作されるすべてのEnvisionスクリプトに対して自動的な書き換えを適用しています。Envisionの非常に高い静的解析への親和性は、Envisionの主要な特性の1つです。静的解析は、言語設計と言語解析の分野の一部です。言語とは、コンピュータ言語のことで、プログラムを実行せずにプログラムの特性を持つことができます。静的解析を通じて、古い構文から新しい構文に自動的にスクリプトを書き換えることができます。そして、それを火曜日に自動的に行っています。通常、アップグレードを行うと、古い構文と新しい構文の両方が数日間受け入れられます。自動的な書き換えを行い、古い構文がもはや存在しないことがわかったら、フィーチャーフラグを使用して新しい構文のみが存在することを確認します。
Lokadでは、既に200以上の自動書き換えを展開しています。通常、火曜日にリリースを行いますが、月に2回程度の書き換えを行っており、それを10年間続けてきました。このプロセスが進行している限り、Lokadは現実的にEnvisionをオープンソース化することはできません。それは適切な時期になるでしょうが、Pythonの大きな過ちを繰り返したくありません。Python 2からPython 3へのアップグレードは、Pythonコミュニティにとって10年かかり、非常に苦痛なものでした。企業は何年ものアップグレードに取り組み、10年間にわたる悪夢でした。それは本当に、本当に間違っていました。Microsoftでも、C#から.NETコアへのアップグレードには半年の歳月がかかり、大変な苦痛でした。これは、コンパイラが野生でオープンソース化されると、コードを制御できなくなるという問題です。したがって、言語に変更を加えるためには、コミュニティと協力する必要があります。これにより、プロセスは非常に遅く、非常に苦痛になり、最終的には言語のすべての悪い機能を完全に排除することはできません。
title: “Pythonの設計ミスとAIの進化”
L5 Pythonの場合、例えばオブジェクト指向プログラミングが導入された方法、構文は、ああ、非常に使いにくいです。Pythonはオブジェクト指向プログラミングを意識して設計されていないことが感じられます。それは後の時期の追加であり、構文はある意味でひどいものであり、今後もそのままです。それに、どの言語にも同じようなものがあります。C#では、もはや目的を果たさないキーワードであるvolatileがあります。C++は永遠に多重継承に取り残されています。それは間違いでした。多重継承を持つことは、すべてを複雑にする悪い設計の決定でした。私たちはLokadでEnvisionの設計に多くの大きなミスをしましたが、それらを修正しました。そして、私たちはまだプロセス中です。特に新しいパラダイムが導入される場合、例えば、微分可能プログラミングは大きな新しいパラダイムであり、言語自体をこのパラダイムに対応させるために再設計する必要がありました。
Conor Doherty: ありがとうございます。まだ3つ残っています。次はVictorさんからの質問です。AIについての幅広い質問です。AIは、大量のデータセットを操作して、可能性のあるシナリオや再発する問題を予測するため、ランダムなボトルネックにどのように対処しますか？
Joannes Vermorel: はっきり言っておきましょう、AIと言っても、それはいくつかの技術の集合です。Lokadでは、通常、LLMs、微分可能プログラミング、確率的最適化を使用しています。微分可能プログラミングは学習に使用され、確率的最適化は不確実性の存在下で制約条件を最適化するためのものです。確率モデルは通常、微分可能プログラミングで回帰されます。LLMsは、この普遍的でノイズに強いテンプレートエンジンです。
サプライチェーンに確率的なツールを適用すると、この質問で示唆されているほとんどのタスクは解決されます。確率的な予測の美しいところは、それらの予測がより正確であるわけではなく、サプライチェーンの周囲の雑音に対して非常に強靭であることです。確率的な予測を確率的最適化と組み合わせると、ほとんどの場合、手動介入の必要性はほぼ完全になくなります。そして、私が「ほぼ」と言うとき、ほとんどのクライアントにとって、それは完全になくなります。そして、今私たちは、テキストを読み解き、それに対処する必要があるタスクだけが残ります。それがLLMsです。そして、再度言いますが、私が説明したのはLokadです。私たちには本当に自動化されたAIパイロットがあり、手動介入がある場合、それはシステムへの事務的な入力ではなく、数値レシピの戦略的な見直しを入力することであり、通常はロジック自体を根本的に変更して見直しの戦略を反映させるものです。それは、些細なことではありません。通常、実施されるのは、非常に基本的なことであり、実装されたロジックの構造を変えるものです。
Conor Doherty: 次はAhsanさんからの質問です。AI、具体的には、どのように注文を迅速化するのでしょうか？音声コマンドに基づいてERPシステムでトランザクションを実行できるのでしょうか？
Joannes Vermorel: 音声コマンドはこの問題には適していません。もし高速なデータ入力が必要な場合、音声は非常に低帯域幅のチャネルです。タイプする方が話すよりも速く入力できます（もしタイピングが得意ならば）。ですので、音声コマンドでは得られない利点です。キーボードを使用したUIが適切に設計されている場合、音声コマンドよりも速くなります。私はこれを非常によく知っています。20年前、私はAT&T Labsで本格的な音声認識システムの開発に取り組んでいました。音声認識は機能していましたが、現実的にはキーボードでの入力の方が速かったのです。音声の利点は、手が汚れているか、忙しい場合にあります。それ以外の場合、キーボードの方が速いのです。
質問に戻りますが、まず注文をフィルタリングしたいと思います。ここでは、進行中の注文に対して迅速化の要求をするかどうかを決定する意思決定プロセスがあります。それが典型的なLokadであり、純粋な定量的な意思決定プロセスです。はいかいいえかを決める必要があります。この注文は進行中のプロセスを迅速化するための要求を正当化するのでしょうか。私たちはそれを微分可能プログラミング、確率的最適化で行います。それによって正しい意思決定に至ります。
それができたら、毎日自動的に注文の意思決定が行われます。それは、音声で注文を指示する人がいるわけではありません。最適化された注文を計算するための数値レシピの一部になります。時間が経つにつれて、いくつかの注文が予測を超えたり、予測を下回ったりすることに気付き、それに応じて延期または迅速化を要求します。LLMの部分は、この定量的な意思決定を使用して、「迅速化してください」というバイナリフラグを持つ適切な文脈の電子メールを生成し、サプライヤーに送信することです。そして、サプライヤーは応答して「はい」「いいえ」「できるかもしれない」「これが提供できるものです」と言うでしょう。
LLMはサプライヤーとのチャットを自動化します。AIは注文を迅速化することを決定するものではありません。それは純粋に定量的な意思決定であり、定量的なツール、微分可能プログラミング、確率的最適化でアプローチする必要があります。LLMはサプライヤーとの対話のために存在し、頻繁にメールのような非構造化のチャネルを使用します。
もし音声コマンドを考えているなら、それはうまくいきません。あまりにも遅いです。私は20年前に市場に最初の本格的な音声認識システムをもたらしたチームと一緒に働く特権を持っています。しかし、結論として、それらのAI技術をそれに使用することはありません。音声コマンドには、望んでいることを行うための帯域幅がありません。
Conor Doherty: 関連する話題として、確率的最適化と微分可能プログラミングについては、豊富なビデオリソースがあります。これらについては詳しく説明しませんが、それらは3部作（part 1、part 2、part 3）で取り上げられています。しかし、それらを無視しているわけではありません。それらはカバーされており、それらについてさらに学びたいと思う視聴者には、それらを確認してこれらのピースを組み合わせるようにお願いします。
最後の質問は、Isaacさんからです。Envisionを学んでいる現在の顧客として、GitHubとの統合機能に興味があります。EnvisionがGitHubの統合をサポートする可能性について、特に自然言語でコードブロックを説明したり、バージョン間の変更を特定したりするアプリケーションについて話していただけますか？最後に、近い将来にEnvisionコパイロットを導入する予定はありますか？
Joannes Vermorel: 簡単に言えば、はい、はい、そしてはいです。タイムラインは、話しているコンポーネントによって非常に異なります。GitHubコパイロットのようなもの、つまりEnvisionコードのLokadコパイロットを使用するためのLLMの使用に関しては、すでに取り組んでいます。非常に興味深いことは、トレーニング資料を完全に制御できるDSLであることです。それは非常にクールです。なぜなら、このLLMを本番環境に正常に導入できた日には、構文を変更するたびに、更新された構文でトレーニングプロセスを再実行し、常に最新のEnvision構文を提供するコパイロットを持つことができるからです。GitHubコパイロットはPythonの構文、C#の構文、Javaの構文を提供しますが、Envisionコパイロットは常に最新のEnvision構文を提供します。
なぜなら、Javaは25年以上、Pythonは30年以上、C#は22年以上存在しているからです。ですので、GitHubコンパイラにコードを書かせるときの問題は、最近のそれらの言語の一つのフレーバーを提供することですが、実際には最新のものではありません。そして、時には最新のフレーバーは必要ありません。なぜなら、環境がまだサポートしていない最新のバージョンと一致していないからです。
私たちは、コメントを付ける、コードを説明する、コードを補完するなど、非常に自然な機能のシリーズに取り組んでいます。また、Lokad内で発生するワークフローに非常に特化した多くの拡張コードアクションについても考えています。たとえば、データヘルスダッシュボードの自動生成を自動化することに取り組んでいます。それは非常に典型的なタスクです。
データヘルスダッシュボードは、私たちが取り込むデータが正常であることを確認するためのツールです。そして、ERPのデータには常に同じような問題がありますので、私たちはそれを確認するためのノウハウとチェック方法を持っています。ERPからの正確なデータをチェックするとき、私たちのサプライチェーン科学者は、実際には、何を探すべきかを知るための独自のトレーニング方法を持っています。そして、私たちは自分たちのレシピ、つまり人間のレシピで、何を実装すべきか、何をチェックすべきかを大部分を自動化することができます。これは、Lokadで進行中のプロジェクトです。
私たちはLokadコパイロットに取り組んでいます。EnvisionをGitHubとより親和性のあるものにするために、すでにオープンソースのVisual Studioコード拡張機能をリリースしています。Envisionコードをgitリポジトリに入れることができます。.nvnファイルを作成し、コミットするだけです。コードを編集する場合は、Visual Studioコード拡張機能が必要です。Lokad Visual Studioコード拡張機能 for Envisionを探すと、完全にオープンソースのものがあり、コードの色付けができます。
将来的には、LokadアカウントにあるEnvisionコードをgitリポジトリとして公開する予定です。Envisionコードは、Lokadアカウントに格納される方法は、ほぼgitリポジトリと同じです。バージョン管理もほぼ同じです。ただし、gitとは少し異なる方法で組織されていますが、技術的な理由についてはあまり詳しくは触れません。Gitは言語に対して非常に中立的です。特定の言語のみを扱う場合、一般的な場合では不可能なさまざまなことを行うことができます。しかし、Envisionコードは完全にバージョン管理されています。Lokadアカウントからgitリポジトリにコードをエクスポートすることができ、後で逆の方法での2方向の同期も可能です。Gitは分散システムであり、各gitリポジトリはまるごとのものです。完全なコピーがあり、リモートリポジトリから変更を取得したり、変更をリモートリポジトリに送信したりすることができます。したがって、いずれ導入するかもしれませんが、まずはエクスポートを導入し、その後に再インポートを導入する予定ですが、それには時間がかかります。ロードマップの一部ですが、まだタイムラインはありません。
Conor Doherty: コメントでEnvisionを学んでいると言っている人もいることを指摘しておく価値があります。私たちはトロント大学との共同で一連のチュートリアルを作成しており、他にもいくつかのパイプラインがあります。無料のリソースもあり、質問にも回答できます。学びたい人のために、私たちのサプライチェーン科学者はそれらのワークショップに多くの努力を注いでいます。ウェブサイトで自由に利用できます。
Joannes Vermorel: サプライチェーン科学者になることに興味がない人々のために、LokadはAIパイロットオファリングの一環としてサプライチェーン科学者を提供することができます。
Conor Doherty: これで質問は以上です、Joannes。お時間をいただき、ありがとうございました。そして、ご視聴いただき、ありがとうございました。役に立てたことを願って、また次回お会いしましょう。
