過去・現在・未来

 【 AI利用のインターフェースを劇的に変えるAI Assistant アプリ API編 】 このセッションでは、前回紹介したAI利用のインターフェースを劇的に変えるAI Assistant アプリ をどのように開発するのかを、Assistant APIのレベルで、少し詳しく紹介しようと思います。 はじめにAssistant APIの基本を、改めて確認します。 その後で、OpenAIが公開している、Assistants playgroundでのコードを見ていきたいと思います。 最後に、Assistantの内部で利用できる三つのツールを確認します。 Assistants playgroundサンプルコードは、次のような構成をしています。 　Step 1: Assistantを生成する 　Step 2: Threadを生成する 　Step 3: ThreadにMessageを追加する 　Step 4: Assistantを走らせる 　Step 5: Runのstatusをチェックする 　Step 6: AssistantのResponseを表示する 　サンプルの出力例 Toolsの説明は次のような構成です。 　Code Interpreter 　　Code Interpreterを有効にする 　　Code Interpreterにファイルを渡す 　Knowledge Retrieval 　　Retrievalを有効にする 　　Retrieval は、どう働くか？ 　　Retrieval用のファイルをアップロードする 　関数呼び出し 　　関数を定義する 　　Assistantから呼ばれた関数を読み込む 　　関数の出力をサブミットする このセッションは、あまりビデオでの短い講義には向いていません。是非、公開しているpdfファイルをゆっくりお読みください。 -------------------------------- ショートムービー「 GPTをAI Assistantアプリに カスタマイズする API編」を公開しました。 https://youtu.be/R9IPc17r6Po?list=PLQIrJ0f9gMcNtKtfdBjlaXfsG8hWl3cQm 「 GPTをAI Assistantアプリに カスタマイズする API編」のpdf資料 https://d

 【 AI利用のインターフェースを劇的に変えるAI Assistant アプリ 】 このセッションでは、OpenAi DevDayで発表された、GPTの能力をユーザーが開発したアプリの上で自由に生かすことを可能にするAssistant APIの概要を見ていきます。 また次回以降のセッションでは、OpenAIが同時に開発を進めていたAIのマルチモーダル化の成果を、今や、AI Assistant アプリの形で、ユーザーが利用できることを紹介したいと思います。 これまで、ChatGPTの利用のスタイルは、OpenAIのサイトにログインして直接ChatGPTと向き合って対話を続けること、具体的にはキーボードとスクリーンを通じてChatGPTとテキストを交換するのが基本でした。このスタイルが大きく変わろうとしています。 ユーザは、場合によればそのアプリの背後にAIがいることを全く意識せずに、普通のスマートフォンアプリと同じように画面タッチでボタンを押したり、スワイプしたりすればいいのです。僕が一番気に入っているインターフェースは、アプリに声で話しかけ、アプリが声で答えるというものです。 重要なことは、こうしたアプリを、OpenAIだけでなく開発者なら誰でも作成できるということです。OpenAIは、こうしたアプリの開発・流通を促進するためのマーケットを用意しています。 AI Assistant アプリ（これを、OpenAIはGPTsと呼んでいるようですが、ChatBotといういいかたもよく使われているようです）の登場は、一般のユーザーとAIとの距離をとても身近なものに劇的に変えるだけではありません。 それは、IT技術者・開発者とAIの距離を大きく変えるものです。 IT技術は・開発者は、これまで 、github copilot等を利用して、主要に開発支援ツールとしてAIを利用してきました。これからは、AIに支援された強力な独自のアプリを、自分の手で開発し、それを多数のユーザーが待つ市場に送り出すことができるのです。 このセミナーの前半では、人工知能技術の転換点を、翻訳モデル、大規模言語モデル、ChatGPTの三つに見てきたのですが、マルチモーダル化したAI Assistant アプリの登場が第四のマイルストーンになるのは確実だと、僕は考えています。 【 Assistant とは

【 画像処理でのGoogleとOpenAIのアプローチの違い 】 現在の人工知能技術の技術的な焦点の一つは、「Multimodalな人工知能」 の実現にあります。このセッションでは、大規模言語の上に Multimodalな人工知能を実現しようとする動きを紹介しようとおもいます。 マルチモーダルな人工知能とは、現在のテキスト中心の人間と人工知能のインターフェースを大きく変える「見ることも聞くことも話すこともできる」インターフェースを備えた人工知能のことです。 ただ、AIが「聞くこと話すこと」と比べて、AIが「見ること」を実現するのは技術的には様ざまな難しさがあります。ですから、マルチモーダルなAIを目指す技術の大きな関心は、AIが「見ること」の実現にむけられていると僕は考えています。 【 Vision Transformer とは何か？】 大規模言語モデルがMulti-Modal なAI に展開して上で、大きな役割を果たしたシステムがあります。それが、2021年に Google が発表した Vision Transformer です。 自然言語処理の世界では、Transformerベースの大規模言語モデルが大きな成功を収めていたのですが、画像情報処理の世界では、近年に至るまで CNN ( Convolution Neural Network )が主流でした。 それに対して、GoogleのVision Transformer は、大規模な画像情報処理の世界でも、CNNを全く利用せずに、Transformer だけで最先端のCNNのシステムを上回る性能を発揮できることを示しました。 このことは、Transformerをエンジンとする一つのシステムで、自然言語処理と画像処理のタイプの異なる二つの処理が同時に可能になることを意味しています。 Vision Transformer が、Multi-ModalなAIへの突破口となったというのは、そういうことです。 【 Vision Transformer のアーキテクチャー 】 Vision Transformerが自然言語だけではなく、画像も処理できるのは、次のような手法を用いているからです。 「元の画像を小さな画像パッチに分割し、これらのパッチの線形なembeddingのシーケンスをTransformerへの入力として提供

【 Interlude -- AIと人間の関係を考える 】 これまで、ChatGPTの成功に至るまでの大規模言語モデルの成立とその発展を、主要には技術的な関心から振り返ってきました。それは過去の歴史の話です。 後半では「マルチモーダル化」と「カスタム化」という二つのトピックスにフォーカスして、ChatGPTがどのように変わっていくのかということを考えたいのですが、そこでも具体的には技術的な話が中心になります。それはAI技術の現在の話になるでしょう。 AIの未来を考えようとすると、それを単なる技術予測として語るのは適切なものではないと思います。AI技術が人間と社会の未来に大きな影響を与えるだろうと考えるならなおさらのことです。それは技術だけの問題ではないからです。 興味深いのは、技術の側から見ても「単なる技術」というくくりはAIの「技術的予測」にとっても狭いものかもしれないと思えることです。 もしも、ChatGPTの成功の要因のひとつが、「人間のフィードバックからの強化学習」という「技術」の採用にあるのなら、それは、現在のAI技術は人間の介在を必要としていると考えることもできるはずです。そして、それは正しい認識だと僕は考えています。 【 AIの安全性をめぐって -- OpenAI の隠れた優位性 】 AIの安全性をめぐる議論は、まさに、AIと人間の接点の問題です。 この問題は、AI技術が社会的に受け入れられ、AIビジネスが経済的に成功するためにも、今以上に重要な課題になっていくと思います。AI開発の競争の焦点は、言語モデルの規模の大きさから、AIシステムの安全性に移っていくと思います。 AIの安全性をめぐる議論は、AIの危険性をめぐる議論に他なりません。 AIを安全なものにするためには、その危険性を知らないといけないはずです。 OpenAIについて、我々はその技術的優位性に目が行きがちなのですが、これらのAIを安全なものにする取り組みで、OpenAIが、圧倒的に進んでいることは注目に値します。 【 OpenAIの安全性への取り組み 】 OpenAIは、訓練用データから性的コンテンツを人手で除去し、不適切な回答を人間がチェックする安全に関連するRLHFトレーニングプロンプトの見直しを進めています。 また、社外の多数の専門家とも連携して、危険性の徹底的な洗い出しを行なって

 【 大規模言語モデルの基礎 】 このセッションでは、現在の大規模言語モデルの基礎となっている二つのアーキテクチャーを紹介します。 一つは、2017年にGoogleが発表したアーキテクチャー Transformerです。 もう一つは、2019年に Google が発表した「言語表現モデル」BERTです。 次回のセッションで紹介するChatGPTは、もちろんOpenAIのプロダクトですが、この時期のAI技術は、主要にGoogleによって推進されてきたことに留意ください。 【 TransformerとGoogleニューラル機械翻訳 】 Transformerは、GoogleのBERTやOpenAIのGPTといった現代の大規模言語モデルほとんど全ての基礎になっています。BERTの最後の文字 'T' も、GPTの'T'も"Transformer" アーキテクチャーを採用していることを表しています。 まず最初に確認したいのは、見かけはずいぶん違って見えますが、Transformer アーキテクチャーは、大きな成功を収めた2016年のGoogle ニューラル機械翻訳のアーキテクチャーから多くを学んでいるということです。 ポイントをあげれば、Encode-Decoder アーキテクチャーの採用、EncoderとDecoderの分離、両者をつなぐAttention Mechanismの採用、等々。 こうした、Google ニューラル機械翻訳のアーキテクチャーの特徴は、そのまま、Transformerのアーキテクチャーに引き継がれています。 それらの特徴の中で、Attentionこそが一番重要なのだというのが、Transformerの提案者の分析なのだと思います。 【 Attention Is All You Need 】 Transfomer を提案した 2017年のVaswani らの論文は、"Attention Is All You Need" と名付けられていました。 「現在優勢なシーケンス変換モデルは、エンコーダーとデコーダーを含む、複雑なリカレントまたはコンボリューション・ニューラルネットワークに基づいている。 また、最も優れた性能を持つモデルは、アテンション・メカニズムを通じてエンコーダーとデコー

 【 大規模言語モデルの母胎は「翻訳モデル」】 このセッションでは、大規模言語モデルの成立期の話をしようと思います。 まず、大まかな流れを見ておきましょう。 この時期の到達点を示すのは、2016年の「Google ニューラル機械翻訳」の登場なのですが、それに至る経過で重要な画期がいくつかあります。 一つが2014年の Ilya Sutskever らによる、ニューラルネットワークによる翻訳モデルの提案です。もう一つが、2016年の Bengioのグループによる Ilya翻訳モデルの批判と「Attention メカニズム」の提案です。 【  Ilyaの翻訳モデルと 文の意味のベクトル表現の発見 】 2014年に、Ilya Sutskever らは、シーケンスをシーケンスに変換するRNN(LSTM)の能力が、機械翻訳に応用できるという論文 を発表します。 「我々の方法では、入力のシーケンスを固定次元のベクトルにマップするのに、多層のLong Short-Term Memory（LSTM）を利用する。その後、別の深いLSTMが、このベクトルから目的のシーケンスをデコードする。」 「Sequence to Sequence」は、当時、非常に注目されたコンセプトだったのですが、それは、単なる文字列から文字列への変換・生成とも解釈できます。その本当の意味は、皆に明らかだった訳ではなかったようにも思えます。 それでは、翻訳モデルで二つのSequence を結びつけているのはなんでしょう。それは二つのSequenceが「同じ意味」を持つということです。 前段の入力のSequenceから作られ、後段の出力のSequenceを構成するのに利用される「固定次元のベクトル」とは、二つの文が「同じ意味」を持つことを表現している文の意味のベクトル表現に他なりません。 発見されたこの文の意味ベクトルは、次のセッションでに見る Transformer / BERT が作り上げる大規模言語モデルの世界で、本質的に重要な役割を果たすことになります。 【 Bahdanau たちの批判とAttentionメカニズムの登場 】 Ilya Sutskever らの翻訳システムでは、翻訳さるべき文は、Encoderで、一旦、ある決まった大きさの次元（例えば8000次元）を持つベクトルに変換されます。このベクトル

【 Tai-Danaeはどんな概念装置を利用したか？】  このセッションでは、大規模言語モデルの特徴を捉えるために、彼女がどのような概念装置を利用したかを見ていきたいと思います。 今回、紹介するのはその概略です。 【  DisCoCatモデルとの比較】 彼女の大規模言語モデルの数学モデルの概要を理解するには、を、それをDisCoCatのモデルと比較するのがわかりやすいと思います。 DisCoCatのモデルというのは、SyntaxとSemanticsの対応を次のように捉えるものです。 　　𝐹𝑢𝑛𝑐𝑡𝑜𝑟 𝐹 : 𝑃𝑟𝑒𝐺𝑟𝑜𝑢𝑝 →  𝐹𝑉𝑒𝑐𝑡  ここで 𝑃𝑟𝑒𝐺𝑟𝑜𝑢𝑝は、LambekのPregroup文法のカテゴリーで、𝐹𝑉𝑒𝑐𝑡は、意味を表現する有限ベクトル空間のカテゴリー、𝐹𝑢𝑛𝑐𝑡𝑜𝑟 𝐹 は、カテゴリーからカテゴリーへの一般的なFunctorです。 【 大規模言語モデルの訓練用データはPreGroupではない 】 大規模言語モデルに与えられる訓練用データは、ただの平文で、文法構造が Pregroup文法で解析済みのものではありません。 ただ、これまでそうした平文の集まりは、「何の構造もない」と言ってきたのですが、文をフレーズに、フレーズを語に分解して、それらの全体を考えてみます。文・フレーズ・文を、文字の並びとして考えてみると、これらの文字列の間には、単純ですが、ある関係があることがわかります。 それは、文字列xが文字列yに含まれるという関係です。これを 𝑥 ≤ 𝑦 と表すことにします。 例えば、   　　”blue” ≤ “small blue” ≤ “small blue marbles” という関係が成り立っています。 xがyの部分文字列であるという関係𝑥≤𝑦 をPreorderと言います。 𝑥 ≤ 𝑦 を𝑥→𝑦 で表すと、文字列の全体は、 𝑥→𝑦を射とするカテゴリーと考えることができます。 これを言語Lだと考えます。 言語は、Preorderを射とするカテゴリーということになります。 【 DisCoCatの意味を表現するFVectは？】 意味を表現するFVectは、どう変わったのでしょう？ 彼女のモデルでは、”語の意味は、それが引きつれ