TypeChat: チャットベースのAIプラットフォーム
(microsoft.github.io)- 既存アプリに自然言語入力を組み込む際の最大の難しさは、ユーザーの意図をソフトウェアが信頼できる構造に変換することであり、TypeChat はこの点を TypeScript の型で解決しようとするライブラリ
- LLM の自由形式のテキスト応答はパースが不安定なため、TypeChat は応答を JSON に誘導し、スキーマ検証を組み合わせてアプリが処理可能なデータにする
- TypeScript の型は JSON 構造を精密に表現でき、LLM が学習過程で多く接してきた形式でもあるため、応答スキーマとして活用しやすい
- 応答が型と一致しない場合は、TypeScript コンパイラのエラーを再びフィードバックして修正できるため、後処理やユーザー確認の前に 型安全性 を高められる
- TypeChat は
npm install typechatでインストールでき、MIT ライセンスのオープンソースとして公開されており、OpenAI API と Azure OpenAI サービスの統合も提供する
自然言語の要求をアプリが処理できるデータに変換する
- 最新の大規模言語モデルはチャットアシスタントには簡単に組み込めるが、既存アプリのインターフェースに自然言語を安定して統合することは別の課題である
- TypeChat はユーザーの要求をアプリが処理できる形に変換し、開発者とユーザーの双方が信頼できる動作を実現することに焦点を当てている
- 公開されたライブラリはコードベースの 型定義 を使って構造化された AI 応答を取得し、型安全性を目指す
- インストールは次のコマンドで可能
npm install typechat
自然言語のパースではなく JSON と型を使う
- LLM は基本的に英語のような 自然言語 の会話向けに最適化されているため、「箇条書きで答えよ」のようなルールをプロンプトに入れても、一般的なソフトウェアが安定してパースするのは難しい
- JSON で答えるよう求めれば、概ねアプリが扱いやすい形の応答を生成できる
- 例では、「blueberry muffin」1 個と「grande latte」1 杯の注文が、
items配列を持つ JSON に変換される
- 例では、「blueberry muffin」1 個と「grande latte」1 杯の注文が、
- 単純な例は構造を誘導する助けにはなるが、AI が何を返すべきかを十分に定義できず、検証基準も提供できない
TypeScript の型を応答スキーマとして使う
- TypeChat は TypeScript の型 をプロンプトに含め、LLM が返すべき JSON 構造を案内する
- 例示スキーマの
Response型にはitems: Item[]が含まれ、Itemはname、quantity、任意のsize、notesフィールドを持つ - TypeScript は JSON を精密に記述するのに適しており、LLM が多くの型定義に触れてきたため、応答形式を誘導するのに有用である
- 応答が型に一致しない場合は、有効な TypeScript コードである型定義を基準に TypeScript コンパイラ が検証する
- コンパイラのエラーフィードバックは応答の修正を促すために活用され、型に合った応答を得る流れをより堅牢にする
TypeChat の使い方と例
- TypeChat はユーザーの意図を構造化された応答へ変換する データスキーマ 方式に利用できる
- 例のコードでは、ユーザー入力文の感情を
negative、neutral、positiveのいずれかに判定するSentimentResponseインターフェースを定義している createLanguageModel(process.env)で環境変数ベースの言語モデルを作成し、スキーマファイルを読み込んだ後、createJsonTranslator<SentimentResponse>でトランスレータを生成するtranslator.translate(request)が成功すればresponse.data.sentimentを出力し、失敗すればエラーメッセージを出力する- データスキーマに加えて、API スキーマ を使って基本的なプログラムを構成することもできる
- 使い方は docs と examples で確認できる
2件のコメント
笑、ニュースを見て投稿しようと思ったのに、AIにはかなわないね
Hacker Newsの意見
ここにどんな付加価値があるのか、いまいち分からない
LLMに送る中核メッセージはここにある: https://github.com/microsoft/TypeChat/blob/main/src/typechat...
結局のところ、固定プロンプトで構造化データを返させ、少しの自動化とベンダーロックインを載せた形に見える。こうしたLLMライブラリの大半は下位APIを包んだ雑なAPIに近く、同じことをするスクリプトは簡単に作れるし、モデルやユーザー要件が変わるほどその方が柔軟だ
たとえばプロンプトを変えたりPythonクラスを使ったりしたいなら、こうしたライブラリと、API呼び出し・テキストテンプレートをユーザー側に押し上げる方式(https://github.com/hofstadter-io/hof/blob/_dev/flow/chat/llm...)との間には作業量の差が大きい
https://github.com/microsoft/TypeChat/blob/main/src/typechat...
同じアイデアを試した経験からすると、2のヒューリスティックは比較的単純な型、つまり深くネストしていないレコードや配列、限定的な型変数の使用では驚くほどよく機能する。LLMに比較的単純な型の値を返すようプロンプトするだけでも有用なアプリケーションは作れるし、このライブラリにはそのリクエストパターンを自前で実装する必要を減らし、TypeScriptコードベースとの標準的な統合を提供するという価値がある
それでもライブラリを使う方向が正しい気はするので、どのアプローチが十分成熟するかを引き続き見守っている
たとえば製品についての自由記述アンケート回答が1000件あるなら、スキーマを作ってそれぞれに
TypeChatを走らせれば、その自由記述に対するデータセットを得られる。ものすごく有用だ理解できない点が1つある
有効な応答が来ることを願い、最後の段階でバリデーターを付けて誤った応答を検知し、モデルにどうか望む文法で答えてくれと頼むような複雑な手順を、なぜ踏むのか分からない
要求した形式に合うトークンだけをサンプリングすれば、有効なJSON文法を保証できる。毎回スコアが最も高いトークンを貪欲に選ぶ代わりに、要求形式に合致するトークンの中で最もスコアが高いものを選べばいい
MicrosoftのGuidanceはすでにこうしている: https://github.com/microsoft/guidance
ただ、OpenAIは全トークンの完全なスコアは公開せず、最高スコアのトークンだけを公開しているようだ。ローカルでモデルを回すならGuidanceを使うのは簡単で、JSONが毎回正しいことを保証できるし、生成もより速いのに不思議だ
それに、そのやり方ではTypeScript型の複雑さ全体を表現するのは難しそうだ
[0] https://www.snopes.com/fact-check/brown-out/
モデルが本当は別のトークンを入れたがっているのに、無理やり
{を入れさせると、その後に生成されるテキストの品質が落ちるかもしれない。確信はなく、ただ思いつきとして言っているだけだオープンソースLLMをJSONパース用にファインチューニングしたことがあるが、誘導トークンサンプリングなしでも用途によっては70Bパラメータは過剰かもしれない。もっと小さなモデルでもかなり良い結果を見たし、小型モデルのファインチューニングと誘導トークンサンプリングを組み合わせると面白そうだ
ただし、非常に汎用的なアプリケーションにはファインチューニングが完全ではないかもしれない。学習データセットで想定していない入力が来ると困る
もちろんWebでは話にならない。マウスでいくつかの商品をクリックする方がずっと簡単だ
https://github.com/ggerganov/llama.cpp/pull/1773
何かを思いつくと、Anders Hejlsberg がもう作ってしまっている気がする
構造化されたリクエストとレスポンスは、LLM の次の進化として 100% 正しい。人々はすでにチャットボットに飽きつつあるし、テキスト解析やプロンプトの心配なしに、どんなバックエンドでも接続できるようになればすごいことになる
TypeChat は正しい方向に進んでいるように見える。「この JSON 入力を、可能なら利用可能なアクションのどれかに合わせろ」といった追加レイヤーも想像できる
ボット、つまり LLM などが実際のコード層をつなぎ合わせる、すっきりしたハイブリッドな未来が見える。あるときは収集・タグ付けの一部になり、あるときは入力に応答する一部になる、といった具合だ
全体として非常に興味深い分野だが、すべての動きが速すぎて、まだ深く掘り下げてはいない。賢い人たちがたくさん取り組んでいるので、少し落ち着くのを待つ必要があると感じる。それでも、自分が夢見ていたホームインターフェースは、もう作れる段階に来ている気がする
たとえば Java コンシューマーの周辺で頻繁に変わる API ペイロードを追ってみるといい。銀行業界、巨大な JSON ペイロード、Java バックエンド環境の中で正気を保つために、別途 NodeJS 層を作った
マッピングは、LLM が真価を発揮できる分野だ
熱い見方をするなら、私たちは徐々に AI の道具化段階に入っている。ここでは実際の価値創出はあまりないと人々が気づきつつあるが、AI にあまりにも多くの資金が投じられているので、引き続きお金が流れ込んでいる。学術論文を書くにも都合のいいテーマで、LangChain はほとんど冗談のようなものなのにシードで 1000 万ドルを調達した
DeFi/crypto は 2 年前にこの段階を通った。数年間、奇妙なリムボ状態が続いたあと、AI は製品ではなく機能であり、適用範囲は限定的で、世界を救うものではないと人々はゆっくり気づくだろう。あらゆるエッジケースのせいで自動運転車は実現できず、人を殺しかねないので手術にも使えないだろう
Copilot のような最も有用な AI ツールでさえ、せいぜい周辺的に役立つ程度だと私はずっと言ってきた。よくても Google で何度かクリックする手間を減らすだけで、エージェントはまったく「知的」ではない。数年前にはチャットボット[1]でも似たようなバブルがあり、今では誰も気にしていない。「メタバース」はもっと短命だったが、同じ群集心理が働いていた。「次の本命」だともてはやされて、そうではないとわかる、という流れだ
[1] https://venturebeat.com/business/facebook-opens-its-messenger...
自動運転車や手術のような、AI における最も難しい適用例だけを持ち出している。大多数の人の仕事は生死に関わるものではないので、自動化に非常に向いている。生死に関わる職業に人間の要素が残るとしても、AI エージェントで補強される可能性は高い。たとえば手術は人間が行うとしても、医師や看護師が AI と一緒に診断することが義務になるかもしれない
数年前のチャットボットバブルと今を本気で比較しているのか？ ChatGPT は数か月でユーザー 1 億人に到達し、本当に多くの人が使ってみた。数年前のチャットボットバブルは、そこまでの存在感はまったくなかった
Copilot などが周辺的にしか役立たないというのは、今見ているのが最悪のバージョンだからだ。ChatGPT は私の人生を変えたし、まだコード実行すらしていない。Code Interpreter はそれをするが、まだ試していない
2030 年ごろには、人間はおそらくもうコードをタイピングせず、機械にプロンプトを与えて AI エージェントを指揮するようになっているだろう。そのころには、ほとんどの仕事も自動化されている可能性が高い
AI は単なる流行ではなく、あらゆる産業を変える。そしてその変化は、人々が思っているよりはるかに速い。メタバースと比べて AI の含意を矮小化する冷笑は不合理で想像力に欠ける。特に AI エージェントの面では、やるべきことがまだ多いのは確かだが、私たちはおそらく人々が考えるよりずっと早くそこに到達し、その波及効果は巨大だ
ただし AlphaGo は、悪手を「幻覚」していた状態から世界最高の棋士になるまで、そう長くはかからなかった。言語モデルでもこれが可能なら、GPT-x が今の議論をすべて吹き飛ばしてしまうかもしれない
GPT-4 は、熟練者が自分の技能はおおむね通用するものの、ドメイン知識が弱い周辺作業をこなすときに非常に役立つ
私は 10 年間コードを書いてきて、最近初めて機械学習を学んでいるところだが、毎日 GPT-4 を使っていて、とても満足している
もちろん粗い部分が時々気になることはある。私にとっては対処可能なレベルで、大きな負担ではない。無視したり回避したりすることにも慣れたし、こうしたツールを使うには確かに技術が要る
提供される価値は今後も増え続けると思う。まだ低い位置の果実も中くらいの高さの果実も、取り尽くされてはいない
現代の AI、実際にはたいてい LLM は、ほぼすべての経済部門に即座に幅広く適用できる。だからこそ、すでに多くの人が機能を作って公開している。この技術には非常に大きな価値がある。世界を完全に変えるかといえばそうではないが、新しい製品カテゴリを生み出し、既存製品の能力の大きな部分を根本的に改善するには十分だ
Apple、Google、Amazon、Microsoftの音声アシスタントのうち、なぜまだLLMをサービスに統合したものがなく、OpenAIはなぜ独自の音声アシスタントを出していないのかが分からない。
また、RSSのようにWebサイトがAI対話用の標準URLを公開し、TypeChatでインターフェースを公開すれば、かなりそこへ近づける気がする
ただし、音声ベースのLLMよりも、実際に行動を実行する能力の価値のほうがはるかに大きい。Alexaを例にすると、スマートホーム制御を予測可能でデバッグ可能な形で処理するシステムが必要になる。でないと人は苛立つ。
間違いなく可能だとは思うが、現在のAlexaやSiri、あまり使われないCortanaのようなシステムは、何年も前のより非力なモデルの上に、さまざまなフックやAPIを使うルールやソフトウェアを積み重ねている。動くようにするには、現在の品質を保ったまま改善しつつ、同時にシステムの主要部分を作り直さなければならないので、時間がかかる。
しかも、こうしたアシスタントは実際には利益を生まず、たいてい赤字になる。スマートフォンやショッピングなど別の形で収益化したり事業を押し進めたりできる大企業にしか価値がなく、スタートアップがやる動機は小さい。
以前CortanaとAlexaの両方で働いていて、LLMの進歩を踏まえて最初から新バージョンを作ることもかなり考えた。技術は全体として直感的だったし、今なら可能になった新しいユースケースのアイデアもあったが、成り立つビジネスモデルを見つけられなかった。なので今は完全に別の仕事をしている
ただ、そのためにクラウドベースのAPIを使うのは不安すぎるので、家の中のサーバーで動くものがほしい。同時に、音声認識と応答時間が非常に速く、待たされている感じがまったくしない必要がある。
個人アシスタントのDIYの試みは何度か見たが、いつもかなり大きな遅延があって、頻繁に使うとすぐにいらいらしそうだ
{ "name": "grande latte" }のような応答を受け取りやすいという話がある。でも、型が
Item = { name: string; ... size?: string; }なら、これでどうやってname: "grande latte"を避けられるのかよく分からない。例の応答には
"size": 16が入っていて「かなり素晴らしい」と言っているが、実際には要求した型すら返していない。おそらく例のタイプミスだと思うし、そうならアイデア自体は良さそうだsizeが誤ってnumberに指定された別のスキーマを使っていた。スキーマは変更したが、プロンプトを再実行しておらず、今は修正されているはずそもそも
nameの文字列フィールド自体を欲しくない可能性が高い。{ name: “the brown one”, size: “the espresso cup”, … }のような値が返るのを防げず、これは元の文字列をパースするのと同じくらい悪い。おそらく、各フィールドについて既知の値を表す大きな文字列ユニオン型が欲しいはずだ。そうすればLLMにその中から当てさせられる。
しかし、なぜそれを型構文に縛る必要があるのかも疑問だ。ランタイムデータを使ってそのようなユニオン型を構成できるZodのようなもののほうが適しているように見える。
数量は正の整数で分数であってはならない、といった制約も必要だ。もちろんJSON値を後で検証することはできるが、そうするとユーザーは2種類のエラーを見ることになる。1つはLLMが流暢な人間の口調で出すエラーで、もう1つは「数量の値が大きすぎます」のような妙に技術的なエラーだ。
こういうことを表現する場所として、型構文は不適切に見える
提供されたコードだけでは、システムが「grande」を16にマッピングする方法はないし、16が他の場所で使われているようにも見えない
型チェックを通る何かを吐き出すまでLLMを繰り返し実行し、エラーメッセージで再度プロンプトを与える方式のように見える。
かわいいアイデアだし動きそうではあるが、大きなモデルと長い入力プロンプトではコストがかさむ可能性がある。あらゆるシナリオの解決策ではなさそうだ
[1]: https://github.com/microsoft/guidance
市場が構造化出力を求めているのだから、モデル側もそちらに改善されていくだろうというのは、かなり妥当な仮定でもある
今週、Laravel PHP向けにこれと非常によく似ているものの、よりスコープの小さいものを作って公開した: https://github.com/adrenallen/ai-agents-laravel
エンジニアは、与えられたLLMで新しい「ボット」を簡単に立ち上げられるべきだと思う。関数をChatGPTが理解できる形に変換し、応答を処理して再度パースするという退屈な作業が多い
こうしたシステムを使えば、実際のPHPコードを書いて明確なコメントをいくつか追加することに集中でき、そうすればボットはどんな作業でもそのコードをツールとしてすぐ使える
また、このやり方はコード共有をはるかに容易にする。誰かが関数を書けば、新しいボットに持ち込んですぐ使える。「LLMが使って理解できるように変換する層」をなくしてくれる点がすばらしく、ビルド速度も大きく向上する
まだ完璧ではないが、お互いのコードをもっと活用するには、結局すべてがこの方向に進むと思う。今日のコーディングでパッケージマネージャーを使うやり方を考えると、AI専用ツール向けのパッケージマネージャーがあってほしい。「天気を取得する」ライブラリをインストールして自分のボットに追加すれば、天気を取得できるようになる、という感じだ
ちょっと待って、これはTypeScriptの型定義に対してオブジェクトをランタイム検証しているのか？ 独立したライブラリや機能として配布できるなら、TypeScriptコードベースでのAPIレスポンスのペイロード検証などにとって完全にゲームチェンジャーになり得る
https://github.com/microsoft/TypeChat/blob/4d34a5005c67bc494...
ここで
guidance[0]を使っていないのは非常に意外だ必須フィールドの補完を提案できるので、検証[1]の必要性を減らせて、結果的にGPU時間も節約できそうだ
きっと理由はあるのだろうが、ぜひ知りたい
余談だが、まさにこういうものを作っていたところにMicrosoftが急に現れて、自分の昼飯をかっさらっていった感じだ
[0] https://github.com/microsoft/guidance
[1] https://github.com/microsoft/TypeChat/blob/main/src/typechat...