失敗事例を学習に生かす
このAIの学習手法をほかの領域に応用するうえでの課題は、コーディングと違って、成果を検証しにくい点にある。コードは動くか、動かないかのどちらかだ。しかし業界によっては、“正解”の定義はもっと曖昧である。カラナムは、Trajectoryのプラットフォームが提供する価値の一部は、AIモデルを企業ごとの具体的なニーズに合わせて最適化できるよう支援することにあると話す。
Trajectoryでは、OpenAIやAnthropicの既製モデルを使い始めるのではなく、顧客企業が開発を想定している特定のAI製品に合わせて事後学習したオープンソースモデルから始める。
AIカスタマーサポートエージェントを開発する顧客Decagonの場合、Trajectoryは、そのAIがうまく対応できなかった場面を記録する。たとえば、返品しようとした顧客の問い合わせに対応できず、人間の担当者に引き継がれたようなケースだ。そうした事例を使って、早ければ毎週、モデルに事後学習を施す。企業の製品にとって特に重要な特定のタスクでは、こうした事後学習済みモデルのほうが最先端AIラボのモデルより優れていると、Trajectory側は語る。
企業の経営層は、さまざまな業務にAIを使いたいと考えている。しかし現状、それを実現するには「フォワード・デプロイド・エンジニア（forward deployed engineers）」と呼ばれる開発者のチームを雇わなければならない場合が多い。これは企業に入り込んでAI製品の構築を支援するコンサルタントや技術担当者のことである。OpenAI、Anthropic、パランティアのような企業は、この需要を取り込もうと急いで体制を整えてきた。エラブドによると、Trajectoryの目標は自ら改善できる製品をつくることで、企業が自社のAIシステムの不具合に継続的に対応する社内開発者を必要としないようにすることだという。
Trajectoryによると、法人営業スタートアップのClayやリーガルAIスタートアップのHarveyをはじめ、すでに幅広い業界で顧客を獲得しているという。現在は主に、AIを事業の中核に据えた企業を顧客としているが、Trajectoryはいずれ、フォーチュン500に名を連ねる企業にも自社プラットフォームを売り込む計画である。
「真の継続学習」への課題
批判的に見れば、Trajectoryはまだ真の継続学習を実現していないとも言える。少なくとも、本来の意味での継続学習ではない。なにしろ、Trajectoryのモデルは現時点では週に一度しか更新されず、更新と更新の間は静的なままなのだ。
エラブドは、Trajectoryはまだ始まったばかりだと主張する。AI業界では、実際の利用経験をもとにAIを改善していく流れが広がりつつあるという。AIコーディングの分野ではすでにそうした動きが起きている。エラブドによると、Trajectoryの最終的な目標は、企業のAIモデルを毎日、あるいはそれ以上の頻度で更新できるプラットフォームを構築することだ。
「毎日では十分ではないかもしれません。毎時間かもしれませんし、やりとりが起きるたびかもしれません」とエラブドは言う。「もしかすると、すべての企業に必要なのは、たったひとつのAIではないのかもしれません。企業で働く一人ひとりに合わせて学習するAIをつくれる可能性だってあります」