TSの父による新しいプロジェクトTypechatはフロントエンドの未来を告げる

みなさんこんにちは、カソンです。

過去 2 年間、フロントエンド コミュニティ全体が主に 2 つの理由で不安を感じていました。

1. 景気低迷で就職が困難に
2. AIGCが業界の将来に与える影響

1点目ですが、全体的な環境はこんな感じで特に不満はありません。 2 番目の不安は、「未知への恐怖」によって引き起こされます。

つまり、AIGC（人工知能生成コンテンツ）が業界の現状を変えることは誰もが知っているが、その変化の仕方が「エンジニアに取って代わる」ものなのか、「エンジニアを助ける」ものなのかはわかっていないということでしょうか。

最近、TypeChat[1]のリリースにより、フロントエンドの今後の開発方向性がより明確になりました。近い将来、AIGCはエンジニアに取って代わるのではなく、エンジニアの強力なアシスタントとなるでしょう。

なぜそう言うのでしょうか?この記事では、以下の観点から説明します。

• LLM（大規模言語モデル）の現在の問題
• TypeChat とは何ですか? また、上記の問題をどのように解決しますか?
• TypeChatの仕組み
• TypeChatがフロントエンド業界に与える影響

LLMの問題点

LLM の最も広く使用され、人気のあるアプリケーション シナリオは、「チャット アシスタント」(chatGPT など) です。

「チャット アシスタント」シナリオの特徴は、ユーザーが自然言語を入力し、モデルが自然言語を出力することです。

自然言語対話

モデルが自然言語のみを出力できる場合、その適用シナリオは「チャットアシスタント」に限定されます。結局のところ、「自然言語」は LLM の入力としてのみ使用でき、他のアプリケーションには使用できません。

たとえば、インターネット上の有名人に関するすべてのコメントを定期的にクロールし、コメントの感情が肯定的であるかどうかを分析し、最終的にインターネット全体での有名人の総合評価を計算する世論監視アプリケーションを作成したいと考えています。アプリケーションの実装のアイデアは次のとおりです。

1. ウェブ全体から音声データをクロールする
2. 音声データを一つ一つ解析し「感情がポジティブかどうか」の判断を出力
3. すべてのスピーチに対応する感情を数える
4. 結果を分析する

2 番目のステップでは、入力された音声の感情が肯定的かどうかを LLM に判断させることができます。

「ジ兄さんは2年半もの間、一生懸命練習してきました」と入力すると、LLM はこの文章の感情が肯定的であると判断して、私に返信することがあります。

• この文章の感情は肯定的です。
• 結果は良好
• これは前向きな会話です
• ...または他の長ったらしい答え

上記の結果はすべて「感情がポジティブである」ということを表現していますが、出力結果も自然言語で記述されており、結果の文章構造が安定していないため、統計のための第3ステッププログラムに出力することはできません。

幸いなことに、LLM は次のような構造化データ (JSON など) やコードを出力することもできます。

• 他のアプリケーションの仕様に準拠したJSONを出力できれば、他のアプリケーションが直接読み込んで利用することができる
• 他のアプリケーションの呼び出しを満たすコードを出力できれば、他のプログラムを直接呼び出すことができます（RPC通信経由）

たとえば、上記の問題に対して、LLM に結果を JSON 形式で出力させます。可能な出力は次のようになります。

 // 可能的结果{"result": "positive"} // 可能的结果{"emotion": "positive"} // 可能的结果{"sentiment": "good"}

プログラムは JSON を読み取ることができますが、出力フィールドが不安定になる可能性があります。 3 番目のステップの統計プログラムが結果フィールドをカウントしますが、2 番目のステップの出力結果は感情フィールドであり、これは使用できないとします。

「ユーザーが自然言語を入力し、LLMが安定した構造化データまたは関数呼び出しを出力する」という問題を解決するために、openAIは関数呼び出し[2]という新しい機能を立ち上げました。

openAI API を呼び出すと、パラメータが次の順序で渡されます。

• 自然言語で記述された要件
• 出力結果関数の型定義

LLM は型定義に準拠した関数呼び出しを出力します。

たとえば、次のように入力します。

• 要件: 「ジ兄さんは2年半の間一生懸命練習してきました」という感情が肯定的であるかどうかを判断する
• 関数定義:

 { "name": "mark_sentiment", "description": "标记输入语句的情绪是否正向", "parameters": { "type": "object", "properties": { "prompt": { "type": "string" }, "sentiment": { "type": "string", "enum": ["negative", "neutral", "positive"] } } }

LLM の出力は次のとおりです。

 mark_sentiment({ prompt: "鸡哥辛苦训练了两年半", sentiment: "positive" })

「スピーチに対応する感情」を保存するには、mark_sentiment メソッドを定義するだけで済みます。

関数呼び出し機能により、LLM のアプリケーション シナリオが大幅に拡張されます (chatGPT プラグイン機能は関数呼び出しを通じて実装されます)。

ただし、関数呼び出しには次のような欠点もあります。

• openAIモデルに限定されており、他のモデル（Llama 2など）にはこの機能はありません。
• LLM の応答は 1 つの関数呼び出しのみです。1 つの応答で複数の関数を呼び出すことはできません。
• 関数の型宣言は開発者にとって使いにくく、内部実装は比較的ブラックボックスです。返された関数呼び出しが期待どおりでない場合、エラーを修正するのは困難です。

TypeChatの登場により、上記の問題は解決されます。

TypeChat とは何ですか? 何ができますか?

関数呼び出しの欠点について説明した際に、「関数の型宣言は開発者にとって使いにくい」と述べました。では、フロントエンド開発にとって最も使い慣れていて使いやすい型システムは何でしょうか?

答えは明白です — TypeScript です。

TypeChat[3]は、TypeScript（C#の作者でもある）の作者Anders Hejlsbergがリリースした新しいプロジェクトです。彼は以下のことが可能です。

1. 自然言語による説明プロンプト語
2. 出力製品のタイプの定義（「データを表す JSON」か「関数の実行を表す JSON」か）
3. 出力製品のTS型宣言

LLM に型宣言に準拠した JSON データを出力させます。

例えば、上記の「スピーチの感情を判断する」という例では、TypeChat に次のように入力できます。

1. 要件: 「ジ兄さんは2年半の間一生懸命練習してきました」という感情が肯定的であるかどうかを判断する
2. 出力製品は「データを表すJSON」です
3. 出力製品のTSタイプファイルは次のとおりです。

 // 下面是对用户输入情绪的类型定义export interface SentimentResponse { // 情绪的可选项sentiment: "negative" | "neutral" | "positive"; }

LLM 出力の結果は上記の TS タイプに厳密に制限されます。

簡単に例えると、TypeChat は TS で定義された型を使った関数呼び出しと考えることができます。しかし、実際には、TypeChat の機能はそれだけではありません。

まず、TypeChat は特定の LLM に縛られるものではありません。自然言語とプログラミング言語の両方を理解できる LLM であれば、誰でも TypeChat を使用できます。

第二に、出力製品は JSON です。JSON はデータを表すだけでなく、複数の関数の実行プロセスを表すこともできます。このように、LLM の 1 つの出力は、複数の関数の連続実行になります。

たとえば、入力は次のようになります。

1. 要件: 次の式を計算します: 「1 + 2 を 3 で乗算し、2 で割ります」
2. 出力結果は「関数の実行を表すJSON」です。
3. 出力製品のTSタイプファイルは次のとおりです。

 // 下面是对四则运算的类型定义export type API = { // 两个数字相加add(x: number, y: number): number; // 两个数字相减sub(x: number, y: number): number; // 两个数字相乘mul(x: number, y: number): number; // 两个数字相除div(x: number, y: number): number; // 对一个数字求负数neg(x: number): number; // id id(x: number): number; // 未知情况unknown(text: string): number; }

LLM の出力は「JSON で表現された関数実行プロセス」です。

 { "@steps": [ { "@func": "mul", "@args": [ { "@func": "add", "@args": [1, 2] }, 3 ] }, { "@func": "div", "@args": [ { "@ref": 0 }, 2 ] } ] }

@XXX は TypeChat のキーワードです。例:

• @step は実行ステップを表し、各インデックスはステップに対応します。
• @func は関数の実行であることを意味します。
• @args は関数のパラメータを表します。
• @ref はステップの実行結果を参照します。

TypeChat 内で変換すると、次のコードが得られます。

 import { API } from "./schema"; function program(api: API) { const step1 = api.mul(api.add(1, 2), 3); return api.div(step1, 2); }

つまり、TypeChat に次の情報を伝えた後です。

• 計算したいのは「1 + 2 を 3 で乗算し、それを 2 で割る」です。
• 出力結果は「関数実行」として表現される必要がある
• 実行される各関数は、定義したTS型に準拠している必要があります。

TypeChat の出力は次のとおりです。

 import { API } from "./schema"; function program(api: API) { const step1 = api.mul(api.add(1, 2), 3); return api.div(step1, 2); }

また、この結果は安定しています（複数回実行しても、出力結果の関数名や型定義は変わりません）。

上記の機能に加え、TypeChat の最大の特徴は、出力結果を自動で修正できることです。

「出力結果のTS型宣言」があるため、TSコンパイラを使用して出力結果が型宣言に準拠しているかどうかを確認できます。準拠していない場合は、TypeChatは「出力結果」とともに「TSエラーメッセージ」を再度LLMに入力し、エラーを修正して再出力することができます。

たとえば、上記の「スピーチの感情をチェックする」の例では、出力は次のようになります。

 {sentiment: "good"}

TS コンパイラによるチェック後、エラーが報告されます:

 Type '"good"' is not assignable to type '"negative" | "neutral" | "positive"'.

TypeChat は上記のエラー情報を出力結果とともに LLM に入力し、修正します。

TypeChat 実装原則

TypeChat の実装原理は、図にまとめることができます。

で：

• 赤いパスの出力は「データを表すJSON」です
• 青いパスの出力は「実行可能コード」です

赤いパスの場合、上記の「スピーチの感情をチェック」を例にとると、TypeChat が LLM に入力するプロンプト ワードは次のようになります。

你是个将用户输入转换为JSON的系统，转换需要遵循下面的TS类型声明： ${输出产物TS类型声明}下面是用户的输入： ${"鸡哥辛苦训练了两年半"}下面是用户输入转换为JSON后的结果：

LLM は上記のプロンプトを受信し、JSON を出力します。

青いパスの場合、上記の「4つの操作」を例にとると、TypeChat が LLM に入力するプロンプト ワードは次のようになります。

你是个转换系统，将用户输入转换为由JSON表示的程序，转换需要遵循下面的TS类型声明： ${对@step、@ref、@func等如何使用的类型声明}程序可以执行由下面的TS类型定义的函数： ${输出产物TS类型声明}下面是用户输入转换为JSON后的结果：

上記のプロンプトを受信すると、LLM はプログラム実行を表す JSON を出力し、それが TypeChat を通じて「実行可能コード」に変換されます。

出力製品のエラー訂正

LLM から返された JSON に TS 型エラーがある場合、TypeChat は次のプロンプト単語を結合して LLM に入力します。

 ${报错的JSON数据}上述JSON对象由于下述原因导致他是非法的： ${TS报错信息}下面是修正后的JSON：

TypeChatがフロントエンド業界に与える影響

フロントエンドエンジニアだけでなく、プログラマーが LLM を使用する主な方法は次のとおりです。

1. コード要件の一部を自然言語で記述する
2. LLM出力コード
3. プログラマーはプロジェクトで使用するために出力コードを修正する

業界が期待する LLM の究極の形は、製品マネージャーが自然言語を使用して製品要件を記述し、LLM が直接コードを記述することです。

ここまで来るとプログラマーには全く価値がなくなるので、ほとんどのプログラマーが不安に思う理由もこれです。

では、「究極の形に到達する」ことを妨げる要因は何でしょうか?ポイントは3つあります。

1. LLMの自然言語記述の必要性を理解する能力
2. LLMが一度に処理するプロンプトワードの長さ（トークン数量制限）
3. LLM生成コードの安定性

1点目ですが、GPT-3.5が登場したことにより、LLMの理解力が一気に数段階向上したように感じました。そのため、数年後にはLLMの理解力が爆発的に高まり、自然言語記述のニーズを完全に理解できるようになるのではないかと誰もが不安を抱いています。

2点目ですが、GPT-3.5では「トークン数は4096まで」という制限がありますが、この制限は徐々に緩和されつつあります。これは、近い将来、LLM が出力できるコードの量が増加することを意味します。

上記 2 つの要素の変化傾向を予見することが、プログラマーが「将来 AIGC に置き換えられるのではないか」と懸念する原因となっています。

しかし、究極の形を実現するには、LLM で生成されたコードの安定性という 3 番目の要素も考慮する必要があることがわかりました。

つまり、LLM は関数コードやモジュールコードの作成に役立ちますが、これらの関数やモジュールのコードが不安定な場合は、一緒に使用することはできず、エンジニアが手動で変更する必要があります。

LLM によって生成されたコードをエンジニアが手動で修正する必要があることが多い場合、「自動生成できるコードの規模」が制限され、エンジニアに代わるものではなく、エンジニアのプログラミング アシスタントにしかなりません。

「生成されたコードの安定性」の問題を解決するには、openAI の関数呼び出しや TypeChat を介して、エンジニアが製品の正確な型定義を行える必要があります。

これにより矛盾が生じます。AIGC がエンジニアを置き換えてプロジェクトを独立して完了させたい場合、安定したコードを生成できる必要があります。安定したコードを生成するには、エンジニアはビジネス ロジックを理解し、詳細な型宣言を記述する必要があります。

エンジニアを置き換えるには、やはりエンジニアが積極的に参加する必要があるのでしょうか?それはderを置き換えます。

これはせいぜいプログラミング パラダイムの移行であり、以前はフロントエンドでページを開発するために jQuery を使用していたのが、その後フロントエンド フレームワークを使用してページを開発するように移行するのと似ています。

将来的には、フロントエンドエンジニアが詳細な型宣言を記述し、LLM がその宣言に基づいてフレームワークコードを生成するようになります。今と同じように、フロントエンドはフレームワークを通じて「状態変更ロジック」を記述し、フレームワークは特定の DOM 操作を実行します。

要約する

学生の中には不安に思う人もいるかもしれません。未来は AIGC のものであり、人工知能に切り替えるべきでしょうか?

実際、この記事を通じて、将来的には3つのタイプのエンジニアが存在するという傾向を感じることができます。

1. AIGCアルゴリズム研究に携わるエンジニア

そのようなエンジニアは非常に少なく、そのほとんどは大手インターネット企業や人工知能企業の研究室にいます。

2. 同社のAIGCインフラを担当するエンジニア

このタイプのエンジニアは、前のタイプのエンジニアの成果を会社のビジネスに統合する責任を負います。職務内容は次のとおりです。

• さまざまなオープンソースモデルを評価して展開する
• langChain、Pincecone、そしてもちろんこの記事で紹介したTypeChatなど、さまざまなツールを使用します
• 企業のビジネスシナリオに合わせてAIインフラを実装

3. ビジネスエンジニア

たとえば、フロントエンドエンジニア、バックエンドエンジニア、フルスタックエンジニアなどです。 AIGCのインフラエンジニアが開発したインフラ上でビジネスを展開します。

フロントエンドのポジションは今後も存在し続けるでしょうが、要件はより高くなり（ビジネスを抽象化する能力）、実践者の数は減少するでしょう。

簡単な例え話をしてみましょう。現在のグループが次のような構成だとします。

• ビジネスをより深く理解するフロントエンドチームリーダー
• ビジネス開発を担当する中級レベルのフロントエンド開発者数名

将来の構成は次のようになります。

• ビジネスを理解している上級フロントエンド開発者 (おそらく元フロントエンド チーム リーダー) が、ビジネスを抽象化する責任を負います。
• 特定のビジネスロジックを記述するためのAIGCインフラストラクチャ

参考文献

[1] TypeChat: https://microsoft.github.io/TypeChat/.

[2] 関数呼び出し: https://openai.com/blog/function-calling-and-other-api-updates.

[3] TypeChat: https://microsoft.github.io/TypeChat/.