00:00:00 インタビューの紹介
00:01:00 RinatのLokadでの歩みとサプライチェーンの課題
00:03:59 Lokadの進化とシミュレーションの洞察
00:07:07 シミュレーションの複雑性とエージェントベースの意思決定
00:09:15 LLMsの紹介とシミュレーション最適化
00:11:18 ChatGPTの影響とモデルの種類
00:14:14 企業における認知ツールとしてのLLMs
00:17:10 LLMsによる顧客交流とリスティングの向上
00:20:30 供給チェーンの計算におけるLLMsの限定的な役割
00:23:07 供給チェーンにおけるコミュニケーション改善に寄与するLLMs
00:27:49 データ分析と洞察におけるChatGPTの役割
00:32:39 LLMsのテキスト処理と定量データの課題
00:38:37 企業向け検索の洗練とAI洞察のまとめ
要約
最近の対話において、LokadのConor DohertyはJoannes VermorelおよびRinat Abdullinと、生成AIが供給チェーンに与える影響について議論しました。Vermorel（LokadのCEO）と技術コンサルタントであるAbdullinは、時系列予測から、ChatGPTのような大規模言語モデル（LLMs）の活用へと進化する過程について議論しました。彼らは、LLMsがタスクを自動化し、生産性を向上させ、職を奪うことなくデータ分析を支援する可能性を探求しました。Vermorelは計画におけるLLMsの利用に慎重でしたが、どちらもソリューションの構築におけるその有用性を認めました。このインタビューは、供給チェーン管理におけるAIの革新的な役割と、専門ツールとのLLMs統合の重要性を浮き彫りにしました。
詳細な要約
最近のインタビューで、Lokadの広報責任者であるConor Dohertyは、LokadのCEO兼創業者であるJoannes Vermorel、およびTrustbitの技術コンサルタントであり元Lokad CTOであるRinat Abdullinと共に、示唆に富む議論を交わしました。この対話は、急成長する生成AIの分野と、それが供給チェーン管理にもたらす影響に焦点を当てました。
Rinat AbdullinはLokadでの勤務を振り返り、特に技術を顧客のニーズに合わせ、複雑な供給チェーンデータを理解しやすく信頼性のあるものにするという初期の課題について語りました。Joannes Vermorelは、Lokadのルーツが時系列予測にあること、これは供給チェーン最適化における重要な要素であることを確認しました。
対話が進むにつれ、AbdullinはLokadの技術進化について掘り下げ、machine learningモデルの説明可能性と性能との間の緊張関係を浮き彫りにしました。彼は、複雑なシステムの謎を解くためにシミュレーションを活用した経験を共有し、それがより最適化された計算手法への道を切り開いたと述べました。
その後、対話は大規模言語モデル（LLMs）に移り、Vermorelはその最近の人気急上昇に触れました。Abdullinは、言語モデルとの初期の経験や、それがChatGPTのような使いやすいツールへと進化した経緯を共有しました。彼は、LLMsの変革的な可能性を強調し、文書作成から大規模データsilos内の情報検索の自動化まで、さまざまなタスクを遂行できる個人的なアシスタント部門に例えました.
Abdullinは、LLMsが雇用を奪うのではなく、従業員の効率を向上させると主張し、その懸念に対処しました。彼は、生産性が10倍から100倍に向上した例を挙げました。また、供給チェーンがLLMsの採用に慎重である一方で、マーケティング部門は顧客との交流やコスト削減のために迅速に活用していることにも言及しました.
Joannes Vermorelは、サプライチェーンパートナーとのオープンエンドなコミュニケーションの自動化、定型的なメールでの時間節約、そしてより複雑なタスクへの注力におけるLLMsの可能性について詳しく述べました。彼は、コミュニケーションのトーンを調整する際の言語的な巧妙さにおいて、LLMsの優秀さを称賛しました.
Abdullinは、ChatGPTの高度なデータ分析能力を強調し、これによりビジネスの意思決定者がプログラミングスキルを必要とせずに複雑なデータを解析できるようになると述べました。しかし、Joannes Vermorelは、サプライチェーン計画における生成AIに対して懐疑的な見解を維持し、LLMsは使い捨ての分析や報告書の作成により適していると強調しました.
Rinat Abdullinは、LLMsが数値、テキスト、およびコードの各ドメインが交差する領域で、より良い結果を得るために専門ツールと併用できると提案しました。Joannes Vermorelはこれに同意し、LLMsは問題を直接解決するのではなく、問題解決のためのプログラム作成に適していると明言しました.
締めくくりとして、Rinat Abdullinは、LLMsが専門ツールと組み合わせることで大きな価値をもたらすため、企業がこれを積極的に取り入れるよう促しました。Conor Dohertyは、動的な生成AI分野とそれが供給チェーン管理の未来を形作る役割についてのJoannesおよびRinatの洞察に感謝の意を表し、インタビューを締めくくりました.
完全な書き起こし
Conor Doherty: Lokad TVへようこそ。過去12ヶ月における生成AIの進歩は、技術的発展の驚異的な成果です。大規模言語モデル（LLMs）は、わずか一年足らずでニッチな存在から主流へと変貌しました。この重要性、特に供給チェーンの文脈において説明するために、Lokad初のCTOであるRinat Abdullinが登場します。Rinat、Lokadへようこそ.
Rinat Abdullin: 戻ってこれて光栄です。私は、Lokadが大学の小さな部屋で始まった頃に在籍していました。そして、これまでに関わった7つのスタートアップを含む全ての企業の中で、Lokadは私の人生で最も挑戦的でやりがいのある場所でした.
Conor Doherty: Joannesについて直接言及する必要はありませんが、もしそれが最も挑戦的だったと言うなら、具体的に何がLokadをそんなにも挑戦的にしたのでしょうか？それに対して、今後のプロジェクトの難しさはどのようなものでしょうか？
Rinat Abdullin: 当時、私たちはスタートアップであり、技術と顧客が望むかつ必要とするものとのマッチを見つけるという興味深い組み合わせでした。この三角関係のバランスを取ることは常に挑戦であり、当時の技術はまだ未熟でした。私たちはAzureの最初の大口顧客の一社であり、顧客からの大量の時系列データを処理するためのスケールアウトライブラリの構築を始めたばかりでした。サポートもなく、全てをゼロから作り上げなければならず、その道のりは何年もかかりました。それは、Lokadの専門家を支援するためのカスタムDSLの作成へと続き、現在も進行中です。それが三角関係の一部です。第二の要素は、顧客がより良い数字を求め、在庫に資金が固定されることなく、予測可能にビジネスが運営されることを期待している点です。同時に、もし魔法のようなブラックボックスから出た数字を顧客に提供した場合、経営陣は「うまくいっている」と言うかもしれませんが、現地のwarehousesの供給チェーン専門家は「この数字が理解できない。数式を信頼できず、10～20年の経験に基づく直感では、うまくいかないと判断するので、無視する」と言うでしょう。そして、もちろん全員を解雇するわけにはいきません。これら三つのバランスを取ることは、Lokadや、それ以降私が関わってきた全ての顧客との間で常に大きな課題でした.
Joannes Vermorel: Rinatの話を聞く限り、かつては時系列データを扱っていたのですね、ということでしょうか？
Rinat Abdullin: はい、Lokadは文字通り時系列予測サービスとして創業されたため、時系列に関しては多少の知識があります。たとえその後その道を離れたとしてもです。私たちは時系列を扱い、それは非常に基本的な構成要素となっています。私が述べた説明可能性に関する緊張状態も、Lokad創業から十年以上経ってやっと解決された問題です。differentiable programmingを採用し、機械学習でありながら説明可能なモデルを実現しました。しかし、それは非常に遅れてのことでした。何年もの間、crudeなホワイトボックスであってあまり良くないモデルと、より優れているがブラックボックスの機械学習モデルという選択を迫られ、多くの運用上の問題が生じました。時には、問題の全ての側面で自然に優れているとはいえないこともありました。それは非常に大きな苦闘であり、Lokadでの道のりはほぼ十年にわたる困難の連続でした。最初の5年間は私が苦闘し、その後、他の多くの人々がその戦いを継続しました.
Conor Doherty: ありがとう、Rinat。話を戻すと、Lokadが何をしているかを説明する際、非常に長い記事、講義、そしてこのような議論を通じて説明しています。しかし、この文脈で機械学習をホワイトボックス化しようとする場合、どのようにアプローチしているのですか？
Rinat Abdullin: 国際物流企業のためのハッカソンを支援していた際、非常に効果的だったアプローチの一つはシミュレーションを通じて行う方法でした。国際物流と言えば、多くの変数が絡みます。複数の輸送手段を用い、複数の場所間で貨物を輸送する必要があり、トラック運送会社やその他の企業が場所Aから場所Bへの貨物輸送でオープンマーケットで競い合っています。さらに、実際の配送経路として道路、鉄道網、あるいはラストマイル配送なども存在します。トラックがこれらの場所間で貨物を運ぶと、遅延や交通渋滞が発生し、貨物が営業時間外に倉庫に到着したり、倉庫の荷下ろしエリアが混雑したりすることがあります.
私たちは、このすべての複雑さを、学生や新入社員にも理解しやすい形でモデル化したいと考えました。私たちが行ったことはかなり過激でした。これは、古代の研究者がシミュレーションを用いてコインを投げ、円周率を求めようとした方法に非常に似ています。そこで、主要道路を備えたヨーロッパの仮想地図を作成し、その中で道路には長さが設定され、時間が経過し、トラックが往復し、運送会社がどの貨物を選び、時間通りに配送するかを決定できるようにしました。これがハッカソン参加者の入り口となり、彼らは「私はトラック運転手A。場所Aから場所Bへこの貨物を運ぶ」といった意思決定を行うエージェントをコーディングできたのです。しかし、ここには一つのトリックがありました。実世界と同様、トラックがある場所から別の場所へ貨物を運ぶ際には費用がかかるのです。収益を上げるためには、税金、燃料代、そして運転手の休息が必要です.
シミュレーションであるため、複雑な数式は不要で、現実をブルートフォース的に再現できます。まるでNPCやゲームに対してバッチスクリプトを連続実行するかのように、数多くの説明可能なルールを紙に書き出せるのです。この全体の世界は人々に非常に理解されやすかったため、実際に難易度の異なる2つのレベルを作成しました。第一のレベルでは、企業は単にトラックを運転しながら最大の利益を追求します。第二のレベルでは、ガソリン価格がやや上昇し、企業はCO2排出の補償を余儀なくされ、トラック運転手は疲労する可能性がありました。運転手が12時間または14時間以上運転すると事故のリスクが高まります。事故が発生すると、運転手は休息に入り、その車両は稼働せず、時間が無駄になってしまいます。こうした環境を構築し、参加者は自分のエージェントをコーディングでき、離散イベントシミュレーションを加速して実行することで、実際の数秒で数か月分の仮想時間を体験することができました.
私たちは多数のシミュレーションを迅速に回し、「皆さん、あなたのエージェントがこの仮想世界で下した意思決定は、これがリードタイムの分布、これが価格分布、これがマージン、そしてこれが事故件数です」とフィードバックできました。これが、複雑な環境を説明する際に私が通常取るアプローチそのものです。まずシミュレーションから始めるのは、ゲームのようでルールの説明が容易であり、微分可能プログラミングを用いる必要がないからです。しかし、このシミュレーションは本質的に、複雑なシステム内の依存関係を追跡するモンテカルロ解析であり、場合によっては外部に単純な分布が現れず、システムの複数要素間の干渉によって外部分布に干渉パターンが現れるのです。一見ブラックボックスに見えますが、ルールを理解すればプレイのルールを変更でき、例えば、企業がこの環境の仕組みを最終的に理解し、シミュレーションが時間を要するためにゆっくりと出てくる数字に満足した場合、その結果を基に、確率を用いた微分可能プログラミングに直接切り替えることで、同じ数字をより迅速に算出する方法で計算を最適化することが可能となります。これは単なるパフォーマンス最適化に過ぎません。これが私が通常採用するアプローチです.
Joannes Vermorel: 非常に興味深いのは、過去1年の間にLLMsという新たなツール群が利用可能になった点です。これは、実際には半世紀近く存在しているにもかかわらず、これまで非常にニッチで、潜在能力については専門家だけが理解できる技術群でした。さて、Rinat、LLMsというこのツール群を導入することで、どのような変化が生じるとお考えですか？企業向けには、分類、回帰、モンテカルロシミュレーションなど、組み合わせ可能な機械学習ツールの各クラスが存在していましたが、今や全く異なる新たなクラス、LLMsが登場しています。ChatGPT以外のLLMsにあまり馴染みのない聴衆に向けて、enterprise softwareや企業のワークフローの文脈で、これらをどう理解すればよいでしょうか？その全体像についてのあなたの高いビジョンを教えてください。
Rinat: 私はチャットボットが登場し人気になる前の2015年から言語モデルに関わってきました。ご指摘の通り、当時は非常にニッチで、翻訳、音声認識、スペルミス修正、もしくは大規模コーパス内のテキスト検索などに利用されていました。しかし、ChatGPTの登場により、その人気は急上昇しました。一因として、モデルが人々に有用で従順になるよう訓練されていたことが挙げられます。
そして、それが時に非常に苛立たしい理由にもなります。なぜなら、モデルから結果を引き出そうとすると、何度も「申し訳ありません」と謝ることがあり、イライラさせられるからです。私の考えでは、モデルを大まかに二つのカテゴリに分けています。一つは回帰、モンテカルロ、ニューラルネットワークなど、主に数字を扱うモデルです。もう一つは大規模言語モデル、つまりLLMsで、これらも数字を扱いますが、表面上は大量の無構造なテキストを扱い、そこに本来の使いやすさがあるのです。
これらのモデルは、機械や自動化システムを人間との直接のやりとりに組み込むことを可能にします。たとえば、回帰や時系列分析の場合、モデルはビジネスのデジタルプロセスの中間に組み込む必要があり、一方にデータベース、中央に予測エンジン、そしてもう一方にデータベースやCRM、ERPなどがあります。最良の場合、レポートが得られますが、それは単なる数字です。しかし、LLMsでは、ビジネスプロセス、すなわち人間のワークフローの真ん中に直接組み込むことが可能になります。
これにより、特に10年前には全く不可能あるいは費用がかさんだことが、ほとんど手間をかけずに実現できるため、無限の可能性が生まれます。例えば、LLMsを活用すると、あたかも自分専用のアシスタント部門を手に入れたかのような感覚になります。彼らは多言語に精通し、フルスタックで、時には素朴な面もありますが、知的で決して文句を言いません。たとえば、レイアウトのボタンを移動したり、ドイツの裁判官に宛てた手紙を書き直したりするのに非常に役立つのです。
私が見た企業でのLLMsの採用事例では、ほとんどが「ビジネスのデジタル化」と呼ばれる分野に集中しています。これは、巨大なコーパス内のテキスト探索を中心としたワークフローの自動化を助けるものです。たとえば、企業は膨大なデータや知識ベースを保有していますが、これらは基本的にサイロ化されており、RFC、アンケート、または誰も更新しないWikipediaのようなものかもしれません。必要な情報を探し出すために、多大な時間、労力、そして特に認知的エネルギーが必要となるのです。
LLMsが果たす役割は、いわば準備作業を担うことです。彼らは記事の草稿を作成したり、企業のプライベートデータを調査して「こちらが企業のワークフローと定型プロンプトに基づいた回答の草稿です」といったドラフトを提示したりできます。そして、その回答チェックリストの各項目について、情報の出所を示すこともできるため、担当者は日常のルーチン作業から解放され、モデルが正確に動いているかを確認する、より知的な作業にシフトできるのです。これにより企業の効率性を飛躍的に高めることが可能になります。
ChatGPTが登場した際、多くの人々はLLMsやAIが自分の仕事を奪うのではと恐れましたが、実際にはそうではありません。私が長年、LLMsや機械学習を活用した製品開発に携わってきた経験から言えば、人間を完全に置き換えるものを作るのは非常に困難であり、ほぼ不可能に近いのです。しかし、LLMsは既存の従業員をより効率的にすることができ、場合によっては10倍から100倍の効率向上を実現することもあります。これは例外的なケースですが、あくまで人間の効率を上げるものであり、人間そのものを置き換えることはできません。常に人が介在する必要があるのです。
Conor: この点についてもう少し掘り下げさせてください。議論の文脈は生成AI、すなわちサプライチェーンにおけるLLMsです。Rinat、あなたのお話からすると、LLMsは全般的に生産性向上の推進力となるように思えます。しかし、サプライチェーンにおいて特定のユースケースがあるとお考えですか？それとも、「多言語対応のチームがあって、このRFPを10言語に翻訳できる」といった一般論に留まるのでしょうか？
Rinat: 私の経験では、サプライチェーンはプロセスの核心部分でLLMsを採用するのがやや遅れる傾向にあります。むしろ、LLMsは外部から徐々に浸透していくものです。よく見られるのは、マーケティング部門が最初の採用者となるケースです。例えば、企業がユーザーに直面する際、企業と顧客との接点で最も顕著な採用が見られます。製品を顧客に販売するマーケットプレイスなどでは、顧客とのインタラクションをより魅力的にし、かつその対応コストを下げたいと考えるのです。
実際、製品カタログを24時間年中無休でひとつひとつ自動的にクロールし、「これは製品ですが、サプライチェーンのベンダーが誤って入力しています」と判定するシステムを構築することは十分に可能です。なぜなら、インターネットを隅々まで探索し、その製品の仕様を示す情報を見つけ、類似する製品の情報や製造業者のPDF説明と照合し、私の判断ではインターネット上の半数近くが正しい値を示しているのに対し、あなたの値が間違っていると判断できるからです。そして、「マネージャー、私はこの製品説明や製品プロパティの修正を確認しました。更新された数字とともに、製品説明を再生成しましょうか？数字だけでなくテキストも含めて」と提案できます。同時に、意味の通る3種類の製品説明、SEO向けのマーケティングテキスト、パブリッシングエンジンのキーワード更新、さらにはTwitterやLinkedInでの告知文も生成するのです。
また、サプライチェーンにおける顧客と小売業者の接点として、マーケットプレイス上の製品リストも挙げられます。例えば、あなたが多数のマーケットプレイスと連携するベンダーであり、カタログが1万点に及ぶ（車や航空機の部品のように微妙なバリエーションがある）製品群で構成されている場合、そのプロセスの自動化は特に在庫が頻繁に変動する際に有効です。実際にそのような事例も見たことがあります。例えば、製品の画像が数枚あって、特にファッションや再利用製品の場合には非常にうまく機能します。画像認識を通じて、訓練されたファッションやスタイリングの知識を活かし、テキストや説明文を抽出し、画像の枠を自動でリサイズし、それらから消費者向けの説明文を生成するのです。
そして、最も素晴らしい部分が後に続きます。LLMを活用して、セマンティック検索用の隠し説明文を生成するのです。これは、例えばファッションプラットフォームの顧客が、「ドラゴンが描かれたボヘミアンスタイルのMサイズで、10ドル未満のシャツ」と具体的なキーワードで探すのではなく、「今夜パーティーに行くので、ショーツに合う服は何がいいだろう」といった曖昧な表現で検索する場合に、その意味に基づいて最適な結果を返すということです。もし、製品説明とともに、LLMから抽出されたセマンティックな解説文があれば、全文検索ではなく埋め込み（ベクトル）ベースの検索により、テキストの正確な表現ではなくその意味に沿った結果が得られ、外見上、まるで魔法のようにユーザーの意図に沿った提案がされるのです。
Conor: ありがとう、Rinat。Joannes、あなたはどう思いますか？私がサプライチェーンを観察すると、作業はほぼ半々に分かれています。半分はスプレッドシートでの作業、残りの半分はパートナー、顧客、運送業者、サプライヤーとの日常的なコミュニケーションです。スプレッドシートの方は、Lokadがこの10年間で自動化してきた数量決定の部分です。後者は、LLMsが登場するまで自動化が難しいとされてきた部分です。
Joannes: つまり、コミュニケーションが必要な部分については、非常に厳密なワークフローであればEDIを通じて自動化可能でした。たとえば、注文を伝達するEDIの橋渡しがあり、その後は非テキスト的な問題になります。しかし、実際に人々が「半分はスプレッドシート、残りの半分はパートナー、顧客、運送業者、サプライヤーの管理に費やしている」と言う場合、それは単にオーダーの処理だけではなく、「この注文を早く処理してほしい。もし可能なら、どの価格で処理できるか？」といった、より曖昧でオープンな問題を指しているのです。
誰かがこの特例についてメールを書き、意図や重要な点を明確にするのに30分かかる。そして、別のケース、別の問題でまたメールを書けば、購買部門では8時間の勤務のうち、4時間をスプレッドシートに、残りの4時間を20通のメール作成に費やすことになるのです。ここに大きな改善の余地があると私は考えます。Lokadは既に最初の部分を自動化していますが、LLMを利用することで、第二の部分を大部分、しかし完全ではないものの自動化する大きな可能性があるのです。言い換えれば、従業員がパートナーに送るコミュニケーションの自動作成において支援を提供できるのです。LLMは、問題の状況とパートナーに期待する内容を適切に文脈化した形で提示するために使われています。
もし問題の記述が明確な境界を持っていれば、EDIのように完全に自動化されたワークフローの一部となるでしょう。しかし、私が言及しているのは、例えば1,000ユニットを注文して1,050ユニットが届くような、完全には整合しないケースです。50ユニット多く届いたからといって、注文自体を拒否するわけではありません。お気に入りのサプライヤーであれば、1050ユニットを受け入れ、検証し、支払いも行います。しかし、同時に、元々の合意である1000ユニットに忠実であってほしいと、丁寧にサプライヤーに伝えたいのです。常に5％多く納品されることは好ましくないという微妙なニュアンスを伝える場合です。
このような、微妙なコミュニケーションを要する状況において、LLMsは真価を発揮します。表現をバランス良く調整するのに時間がかかるかもしれませんが、相手に対して強く出すぎず、それでいて最初に合意した数量を厳守してほしいという意思を伝える文章を、LLMなら数秒で生成できます。LLMの知性は、全体像や大局を把握するという点では必ずしも超人的ではありませんが、文章の表現をやや攻撃的に、あるいは柔らかく、または支援的に変換する点においては非常に優秀です。
半ページ分の文章を作成するのに20分かかるところを、LLMなら数秒で生成できます。これは、何時間もかかるような微妙な表現の調整において大幅な生産性向上をもたらす事例です。さらに、1日に何千ものこのような微妙なコミュニケーションが必要な企業を想像してみてください。これは、LLMsがもたらす新たな能力なのです。 サプライチェーンの経営者や関係者が大局を把握するためには多大な労力が必要ですが、LLMは大量の非構造化テキストを高速にスキャンし、パターンを見出すことに非常に長けています。たとえば、LLMが数百のレポートやメール、そのやり取りを読み込み、「どうやら最近、サプライヤーがますます多くの在庫を送ろうとしている傾向がある」といった簡潔な要約を経営陣に提供できるのです。 ご存知のとおり、ChatGPTには高度なデータ分析という驚異的な機能があり、まるであなたの下にデータアナリスト部門がいくつもあるかのようです。彼らはサプライチェーンの専門家ではないため、そこにLokadが必要になるでしょうが、たとえば「こちらが私のデータベースファイルです。Excelファイルです。分析を実行し、トレンドを見つけてください」といったシンプルな質問をすることが可能です。これは主にオンライン上で実現可能な驚くべき点です。ローカルやAPIでは実行できないものの、ChatGPTは理論を構築し、コードを書き、実行、エラーを修正し、結果を出力し、さらにはチャートまで自動で生成します。Excelスプレッドシートと質問を送ってから美しいチャートが出来上がるまでの一連の流れが完全に自動化され、自己修正、自己修復しながら素晴らしい結果をもたらすのです。これにより、複雑なシステムに保存されたデータであっても、ビジネスの意思決定者が自らデータを解析し、Python、JavaScript、C、SQLの知識がなくても視覚化する能力が飛躍的に向上します。私は、これが非常に力を与えるものであり、新たなビジネスチャンスを開拓し、新たなビジネス価値を創出すると考えています。
Conor: 約6ヶ月前、私たちは生成系AIとサプライチェーンにおけるその役割について議論を交わし、全体的にやや懐疑的でした。ここ最近の6ヶ月間での進歩について聞くと、今も同じ視点をお持ちですか、それとも少し軟化されましたか?
Joannes: 私の立場は依然として、いくつかの点で非常に懐疑的です。私の懐疑心は、本質的には「我々はChatGPTをテラバイト単位の取引データに直接適用すればうまくいく」というLokadの大多数の競合他社に対する反応でした。私の考えは、いや、そうは思いません。実際、それは全く違うのです。もし、できることがスキーマ付きのいくつかのテーブルをリストアップすることや、ツールがデータベースのスキーマを自動で探知して平均バスケットサイズのような使い捨て分析を計算することであれば、それは全く別の命題です。以前は、これらはビジネスインテリジェンスチームを通して実行されなければなりませんでした。つまり、平均バスケットサイズが何か、顧客を平均してどれくらい保持しているか、ドイツで何ユニット販売したか―非常に基本的な質問です。大企業では、BI部門に数十人が常に使い捨てレポートを作成しています。この種のことについては、LLMが本当に役立つと考えていますが、それは決して競合他社が提案しているものではありません。彼らは「これらのモデルがあれば、テラバイトのデータベース、TwitterやInstagramへのアクセスを与えれば、計画も意思決定もすべて自動化できる」と言います。私は、いや、全然そんなことはない、と言いたいのです。幻想の世界にいるのと同じです。
Rinat: この課題に対するあなたの返答について、私からは二つの考えを共有させていただきます。まず、LLMを用いて大量のデータを処理するプロセスについてですが、私は既に様々なLLMを長い間使ってきました。顧客が最初に尋ねる質問の一つは、ChatGPTのようなものを自社内で実行できるかどうかというものです。それに答えるには、LLMを異なる構成でベンチマークし、コストを算出する必要があります。LLMは非常に高価です。予測のために1メガバイトのテキストをLLMで処理すると、モデルによっては数ユーロかかります。もし最良のモデルでローカルに実行しようとすれば、€10あるいは€20かかるかもしれません。
そして、それがGPT-3.5のやっていることです；非常に安価です。しかし、要点は、テラバイトやペタバイトのデータをLLMに通すことはそもそも不可能だということです。第二に、LLMは数字に関しては非常に苦手です。もし誰かがLLMに数学的計算をさせたり、素数を列挙させたりするならば、それは誤用です。LLMは言語モデルであり、膨大な知識ベースを持ち非常に知的ですが、それでも限界があります。数学の問題をLLMに解かせるのではなく、問題の表現を頼み、計算そのものは専門のPythonカーネルなど、LLMでは到底及ばないものに任せるべきです。
異なる領域の接点で最も興味深いことが起こります。例えば、一方に広大な数値領域があり、もう一方にテキストや曖昧なエッジケースがあり、第三の要素としてコードがあります。コードは数字でもテキストでもなく、構造化されながらも検証可能であり、LLMはそれを扱うのが非常に得意です。これにより、サプライチェーンに適用可能な新たなケースが創出され、Lokadのようなソリューションの適用範囲がさらに拡大します。
例えば、LLMの能力を超えて大量のテキストを解析する一つの方法として、問題をLLMに問いかけることで対応している例があります。全世界の数百ギガバイトにおよぶ年次報告書からテキストを抽出する場合や、実際の計算を行わずに数値問題の解決を支援する場合などです。あなたは知性を働かせ、背景を理解しているため、どのようにアプローチすべきかの理論を構築します―これが私が与えるコントロールです。
巨大なデータベースを横断する検索について話す際、私は特定の構文でLLMに埋め込み検索を考案させ、ストップワードのリストや効果を高めるキーワードのホワイトリストを作成させます。そして、スケールでの処理に非常に優れた専用の別のシステムが、LLMからの整ったリクエストを受け取り実行します。ここで最も素晴らしいのは、LLMが検索を洗練させる能力を持っている点にあります。
あなたは再びLLMに戻り、「これが私の元々の問題で、これがあなたの意見、このクエリを作成した結果、そしてこれが返されたゴミのような結果です。どうか調整し、適応してください」と伝えます。LLMとの作業はほぼ無料で、10回程度繰り返すうちに、チェーン・オブ・ソートやツリー・オブ・ソートなど、良い判断と悪い判断を経てどんどん改善されていきます。これは数値領域にも同様に当てはまります。例えば、サプライマネージャーは在庫をより良くバランスさせる方法を模索します。理論上は、「これは私の環境の小規模なシミュレーションで、十分かもしれない。これが調整の方法です。今、ファジー制約解法を実行して、在庫バランスを向上させるためのアイデアを出してください」と求めることができます。
これは、数値、コード、テキストという複数の領域を橋渡しし、それぞれで利用可能な最良のツールを組み合わせることで生まれる可能性です。
Conor: ありがとう、Rinat。Joannes、この件についてのご意見はいかがですか?
Joannes: 聴衆の皆さんに明確にしておくと、多くの問題に対してLLMに取り組む際の望ましい方法は、「問題を解決するプログラムを作成してください」と依頼することです。「問題を解いてほしい」とは言いません。「プログラムを作成して、その後私がそのプログラムを理解する」というのです。さらに、プログラムが正しくコンパイルされるかを確認するためのコンパイラをLLMに与えたり、出力が妥当かをチェックするためにプログラムを実行するツールを提供するなどの工夫もあります。
問題をLLMが直接解くのではなく、仲介されるのです。LLMはプログラムを生成し、その後、テキスト出力である何か別のものを利用します。なぜなら、コンパイラを使えばそのプログラムをコンパイルし、うまくいかなければエラーメッセージを返すからです。LLMはエラーメッセージを処理し、関連する問題を修正することが大好きです。私たちは非常にテキストの領域に深く関わっています。
サプライチェーンの場合、ほとんど全ての状況が仲介されます。私たちは、解決すべき問題に対応するプログラムをLLMに作成してもらいたいのです。例えば、昨年ベルギーで1百万ユーロ以上のクライアントの売上高を求めるという最初の問題では、LLMはデータベースから直接データを取り出すのではなく、データベース自体が実行するSQLクエリを作成します。これもまた仲介の一例です。
これはエンタープライズソフトウェアにとってどういう意味を持つでしょうか? あなたのエンタープライズソフトウェア環境の一部として、少なくとも意思決定層においてサプライチェーンの実行をプログラム的にサポートするプラットフォームが用意されていますか? LLMは生の取引データから直接出力を生成するのではなく、問題文をもとにプログラムを生成し、その生成されるプログラムの種類において非常に柔軟です。しかし、その後は環境内の何かがそのプログラムを実行しなければなりません。どのようなプログラミング環境をLLMに提供できるのでしょうか?
多くの従来型エンタープライズソフトウェアは、全くプログラミング環境を提供しません。彼らは、使える言語を備えたデータベースを持っているだけですが、例えば在庫最適化を行う大規模ERPと対話する唯一の方法は、製品ごとに在庫レベルの最小値と最大値、または安全在庫パラメータを手動で設定することです。LLMは、適用すべきレシピを教えることができますが、それを実際に適用するには、手動のERP設定を経なければなりません。もしERPがAPIを提供していれば、APIを通じて大規模に実行できるプログラムを作成することもできますが、ネイティブなプログラム的解決策と比べると、依然として非常に不格好です。結局、フレームワークを通じた仲介が必要になるのです。
これは根本的な変革を必要とし、ソリューションのプログラム可能性を第一級の存在として導入します。遠慮なく申し上げますが、Lokadはプログラム的プラットフォームを有しています。これはLLMのために作ったのではなく、ほぼ偶然の産物ですが、10年前にこのようなプログラム的な考え方をプラットフォームの核として、第一級の存在として取り入れたのです。これは、LLMについて10年後に何が起こるかという先見の明によるものではなく、偶然の結果でした。
Conor: ありがとう、Joannes。皆さんのお時間を考慮し、慣例に従い、Rinat、締めのご意見をお願いします。視聴中の皆さんに何か伝えたいことはありますか?
Rinat: 過去には、ドットコム・バブルや金融バブルのようないくつかのバブルがありました。LLMやAIもまたバブルであるかもしれませんし、そうでないかもしれません。私の母でさえChatGPTとその使い方を知っているというのは興味深いことです。私は皆さんに、機械の覇権を恐れないよう促します―Skynetが簡単に機能するわけではありません。生産環境でこれらを安定させようとする者としては、多大な努力が必要で、容易に信頼性が得られるものではないのです。ですから、まずLLMを恐れず、次にただ受け入れるのです。LLMと人間、そしてビジネスが組み合わされば、特にLokadの予測のような、環境にしっかり組み込まれる専門ツールによって、はるかに大きな価値を生み出すことができます。
Conor: ありがとう、Rinat。Joannes、本当にありがとうございました。Rinat、再びご参加いただきありがとうございました。そして皆さん、ご視聴ありがとうございました。次回お会いしましょう。
