まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:cloud

IBM Cloud から提供されている生成 AI である Watsonx.AI の LLM をチューニングする機会があったので、その内容や手順、そして気になるチューニングのコストなどをまとめました。あくまで一つの例ですが、参考になればと思っています。


【Watsonx.AI の LLM チューニング】
本記事で後述する内容は 2024-09-25 時点のものです。この時点では Watsonx.AI の LLM チューニングはいわゆる「プロンプト・チューニング」のみ可能です。

LLM の基になる非構造テキストデータを大量に再学習、するようなチューニングではなく、あくまで「プロンプトエンジニアリングをベースとしたチューニング」です。詳しくは後述しますが、ベースとなる LLM に対して、入力例と出力例を複数与えてプロンプトに出力の方向性を指示するような改良を LLM に加える、というものです。プロンプトエンジニアリングで与えるサンプル部分のトークン数が多くなって1回の問い合わせコストが高くなってしまうことを防ぐことがメリットとなるものです。


【どんなチューニングをするか】
当然ですが、「チューニング前の LLM では期待した返答にならないような問い合わせ」をチューニングして改良することを試みます。というわけで、まずはチューニング前の granite-13b-instruct-v2 モデルを使って、フリーフォームで以下のプロンプトを試してみました(2024-09-25 時点での試行結果です):

「1 ドルは 140.1 円です。 10 ドルは何円ですか?」
2024092501


このプロンプトに対して「生成」ボタンで問い合わせすると「140.1 円です。」という返答が返ってきました。うーん、価格を問い合わせていることは理解できているようですが、こちらが期待した計算結果にはなっていませんでした:
2024092502


そこで計算方法含めてプロンプトでガイドしてみます。「フリーフォーム」から「構造化」に変えます(この時に LLM モデルが切り替わることがあるので、改めて granite-13b-instruct-v2 モデルを選びます)。そして "例" と書かれた箇所を「新規テスト+」ボタンで行を増やしながら以下のように3行入力します。与えられた情報を使って、答を計算して返答するような例をいくつか指示してみました:
入力出力
11 ドルは 140 円です。 10 ドルは何円ですか?1 ドルが 140 円なので、 10 ドルは約 140 * 10 = 1400 円です。
21 ドルは 140.1 円です。 20 ドルは何円ですか?1 ドルが 140.1 円なので、 20 ドルは約 140.1 * 20 = 2802 円です。
31 ドルは 140.3 円です。 30 ドルは何円ですか?1 ドルが 140.3 円なので、 30 ドルは約 140.3 * 30 = 4209 円です。

2024092503


そして "試行" の入力欄に以下を入力し、テキストを生成させます:
1 ドルは 139.1 円です。 10 ドルは何円ですか?
2024092504


これで「1 ドルが 139.1 円なので、 10 ドルは約 139.1 * 10 = 1391 円です。」と答えてくれることを期待していました。が、結果は・・・ 計算や数値は期待通りなのですが、"Thornton" って何?? ともあれ、数字を計算して答えることや、その計算方法は理解してもらえている・・・と思います:
2024092505


というわけで、この方向で為替計算を教えるような LLM チューニングを試みてみます。


【プロジェクトと Tuning Studio の準備】
改めて、ここからが LLM チューニングの紹介内容です。

まずは LLM チューニングを行うための準備といえる作業をいくつか実行します。その1つが「プロジェクトの準備」です。既に Watsonx.AI のプロジェクトを作成済みの人もいると思いますが、もし環境的に問題なければ新しいプロジェクトを1つ作ってから LLM チューニングを行うことを推奨します(そうすると後述で紹介するチューニングコストを確認しやすいため)。もちろん既存プロジェクトを選択してチューニングしても構いません。

プロジェクトを新規に作成する前に現在の環境で作成されているプロジェクトの一覧を確認します。 Watsonx.AI の画面左上のハンバーガーメニューをクリックします:
2024092506


このメニューから「すべてのプロジェクトの表示」を選択します:
2024092507


現在までに作成されたプロジェクトの一覧が表示されます。ここから1つ選択して、そのプロジェクト内でチューニングを実行することも可能です。 プロジェクトを新規に作成するには右上の「新規プロジェクト」ボタンをクリックします:
2024092508


新規に作成するプロジェクトの情報を入力します。まずはプロジェクトの名前を入力します:
2024092509


このプロジェクトで利用するストレージサービス(Cloud Object Storage)のインスタンスを選択します。1つ選ぶか、新規に作成して指定します。最後に「作成」ボタンが有効化されたら「作成」します:
2024092510


既存プロジェクトを選択した場合はそのプロジェクトが、プロジェクトを新規作成した場合は作成されたプロジェクトが開きます。この画面内でプロジェクト内で使ったリソース量が表示されます。新規作成した場合はこの時点ではゼロになっているので、この後のチューニング作業でどの程度増えているか確認しやすいと思っています:
2024092511



【Tuning Studio によるチューニングの手順】
Watsonx.AI では LLM をチューニングするためのオンラインツール "Tuning Studio" を利用することができます。このオンラインツールを使って、チューニング元の LLM モデルに自分で与えた学習データを使ったチューニングを施した、新しい LLM モデルを作ることができます。

では以下に実際に Tuning Studio を使って LLM をチューニングしていく手順を紹介します。

プロジェクト画面を開きます(作ったばかりなせいか、リソース消費量の表示がおかしくなっています。この時点では実際は全てゼロのはず)。ここから実際にプロンプト問い合わせを実行するプロンプト・ラボにも移動できますが、今回は LLM モデルのチューニングを行う「ラベル付きデータを使用したファウンデーション・モデルの調整」を選択します:
2024092512


最初にチューニングそのものに適当な名称、説明、タグを付与し「作成」ボタンをクリックします:
2024092513


するとチューニングのアセットが作られ、そのチューニング内容を指定する画面になります。まずはチューニング元になる LLM (言語モデル)を選択します。「基礎モデルの選択」ボタンをクリックします:
2024092514


ここで選択できる LLM の一覧が表示されます。2024-09-25 時点ではここで選択できる LLM は "fran-t5-xl-3b" か "granite-13b-instruct-v2" のいずれかでした(これを知っていたので、上述のプロンプトでも granite-13b-instruct-v2 を使ってプロンプトを試していました)。ここから1つ選んでチューニングするわけですが、今回は IBM の "granite-13b-instruct-v2" を選択しました:
2024092515

※実際のチューニングではここでベースとなる LLM を何にするかによってもチューニングの結果は異なることになります。一般的にはここで選択する LLM は「プロンプトエンジニアリングを試した時点で相性の良さそうな LLM を選ぶ」のが良いとされています。


選択した LLM の説明文が表示されます。これで問題なければ「選択」をクリックします:
2024091209


チューニング元 LLM の選択ができました。すると画面右に「トレーニング・データの追加」と書かれたファイルアップロード画面が表示されます。ここで追加用チューニングデータを指定してチューニングを行うことができます。追加用チューニングデータのフォーマットが分からない場合は(青枠の)「テンプレートのプレビュー」ボタンをクリックします:
2024092516


「テンプレートのプレビュー」をクリックし、"JSON" タブを選択すると以下のような画面が表示されます。"input" と "output" の要素を含む JSON が配列になっていて、この input にプロンプト例、output に問い合わせ結果例が含まれているようなデータを作る、ということのようでした(最大で 10000 サンプル、200MB。これ以外に配列の "[" , "]" を抜いた JSONL 型のデータも使えるようです):
2024092517


このようなフォーマットでチューニング用データを集めて指定してチューニング、、を行うことになります。今回は為替計算を正しく行ってもらうことが目的なので、以下のようなデータを用意してみました:
[
  {
    "input": "1 ドルは 140 円です。 10 ドルは何円ですか?",
    "output": "1 ドルが 140 円なので、 10 ドルは約 140 * 10 = 1400 円です。"
  },
  {
    "input": "1 ドルは 140 円です。 20 ドルは何円ですか?",
    "output": "1 ドルが 140 円なので、 20 ドルは約 140 * 20 = 2800 円です。"
  },
  {
    "input": "1 ドルは 140 円です。 30 ドルは何円ですか?",
    "output": "1 ドルが 140 円なので、 30 ドルは約 140 * 30 = 4200 円です。"
  },
  :
  :

為替のレートを与えた時の「〇〇ドルは何円ですか?」という質問に答えられるようにするためのインプットとアウトプットのペアを大量に用意してチューニングし、実際のレートと質問を与えた時に(プロンプトで工夫しなくても)正しく答えることができるようにするための JSON 配列型の学習データを用意しました(実際には異なる計算もできるような例が含まれています。興味ある方は全部見てください)。

この架空のデータファイル(training-fx.json)をトレーニングデータとして公開することにします。LLM チューニングを体験する目的で、直接ダウンロードして使っていただいても構いません:
https://raw.githubusercontent.com/dotnsf/watsonx.ai-tuning/refs/heads/main/training-fx.json

そして Tuning Studio 画面の「参照」ボタンから、用意した training-fx.json ファイルを指定してアップロードします:
2024092518


アップロードが完了すると「トレーニングデータの追加」の準備はできたことになります:
2024092519


必要であれば「パラメーターの構成」ボタンをクリックして、チューニング時のパラメータを変更します:
2024092520


パラメータを調整する画面が表示されます。必要に応じてパラメータを調整して「保存」します(必要なければ「キャンセル」します):
2024092521


最後にプロンプトの初期化内容を指示します。今回の場合は「与えられた条件から計算して額を答えてほしい」ことが分かっているので、初期化方法に「テキスト」、その内容には「以下は入力された質問に対する出力のサンプルです。サンプルと同様に与えられた質問に対する答を計算して簡潔に答えてください。」と入力します:
2024092522


更に下にスクロールするとタスクの種類を指定する箇所があります。今回の例では「計算して答える」という「プロンプトに含まれない情報を生成する」ものなので、「生成」を選択します。 ここまで選択すると画面右下の「チューニングの開始」ボタンが有効になります。 ここをクリックしてチューニングを開始します:
2024092523


このような画面になってチューニングが開始されます。ここからはチューニングが完了するまで、ひたすら待ちます:
2024092524


チューニングが完了すると以下のような画面になります(先ほどのデータでは 16 分でした)。一般的には(表示されている)損失関数は右肩下がりになるのがいいと言われていますが、ちょっと
2024092525


このチューニングした LLM を実際に使えるようにするにはデプロイする必要があります。画面下部(見えない場合は下にスクロール)の「新規デプロイメント」をクリックします:
2024092526


名前(必須)と説明等を入力します。続きがあるので下にスクロールします:
2024092527


展開コンテナは「このプロジェクト」を選択し、デプロイメント・サービス提供社名を(適当に)入力します。最後に「作成」ボタンをクリックしてデプロイを開始します:
2024092528


少し待つと以下のような画面に切り替わります。このデプロイメントのリンクをクリックします:
2024092529


デプロイメントの様子が分かります。デプロイメントが完了するまで少し時間がかかります。ステータスが「進行中」から「デプロイ済み」になるまで待ちます:
2024092530


「デプロイ済み」になれば、チューニングした LLM はデプロイされ、実際に使える状態になったことを意味します:
2024092531


【チューニング済み LLM を使う】
チューニングされた LLM がデプロイ済みになっていれば、外部からの API 呼び出しや、プロンプトラボなどから実際に使うことができます。先ほどのページの「API リファレンス」タブにはエンドポイント URL や cURL コマンドなどで使う場合のコマンドが表示されています。 ここではプロンプトラボから試す方法を紹介します。といっても「Prompt Lab で開く」ボタンをクリックするだけです:
2024092532


するとプロンプトラボの画面が表示されます。この時、LLM は自分がチューニングしたモデルになっていることを確認します:
2024092533

基盤モデルの一覧を表示した場合でも、このチューニング済みモデルが表示され、選択可能になっていることを確認してください:
2024092534


改めてプロンプトラボを「フリーフォーム」で、LLM は自分がチューニングしてデプロイしたモデルを選択した状態にします:
2024092535


そしてプロンプトとして以下のように入力します(このブログを書いている最中の実際のドル円相場の数字です):
与えられた質問に対する答を計算して簡潔に答えてください。

1 ドルは 144.3 円です。 10 ドルは何円ですか?
2024092536


もともとは何も計算してくれなかったプロンプトです。これを「生成」します:
2024092537


・・・うーん、まだ 100 点とはいえないか。想定していた答とは違いますが、とりあえず計算はしてくれるようになりました。このプロンプトはチューニング前だと正しい数値を返すこともなかったものなので、いくらかの進展はあったと言えるんじゃないかと思いますが、うーん。。。

まあ、今回のチューニングデータは説明目的でサイズもまだまだ小さく、サンプルとしては不十分であった可能性は高いものです。もうちょっと色んなパターンに対応したり、数を増やしたりすることで制度上がるんだろうか? この辺りはまだ未検証です。 ただ Watsonx.AI の LLM チューニングがどういったものなのか、そのための Tuning Studio をどう使うのか、という点ではある程度理解しやすいものではなかったか、と思っています。


【チューニングのコスト】
Watsonx.ai の LLM を Tuningu Studio でチューニングする際のコストも気になるところです。チューニングコストは与えるサンプルデータ量によっても変わるので事前に具体的なコストを予測計算するのは難しいのですが、以下にチューニングコストの考え方・計算方法についてまとめておきます。 

なお、以下の説明に使っている数字部分は 2024 年 9 月 25 日時点のものであることに注意してください。実際にコストを見積もる際には自分の契約しているプランや為替レートを含めた最新情報・最新価格を参照して再度計算するべきであることに留意ください。

まず覚えておいていただきたいことは「LLM チューニングの価格は CUH(Capacity Unit / Hour : 容量単位時間)によって決まる」ということです。

要は、
 1 どのようなスペックのサーバーを
 2 どのくらいの時間使って
チューニングしたか、という計算能力と計算量によって計算で決まる、という意味です。

どのようなスペックのサーバーを使って LLM チューニングしているか、という情報はこちらを参照して調べます:
https://dataplatform.cloud.ibm.com/docs/content/wsj/getting-started/wml-plans.html?context=wx&audience=wdp#cuh-metering


この中の「資産タイプ別 CUH 消費率」という項目内の「基礎モデルの調整実験(watsonxのみ)」と書かれた所が LLM チューニング時に使われるサーバーで、その CUH は(2024/09/25 時点で)43 となっています:
2024091211


この 43 というのが(1時間の)チューニング時に利用されるサーバーのスペックを表す数字だと思ってください。この数字だけだとどんなスペックか想像しにくいですが、他の数字よりもかなり大きめの数字になっているので、それなりのサーバーが使われる、という理解でいいと思います。 ただあくまで1時間の数字です。チューニングに必要な時間が 30 分ならこの半分に、2時間ならこの倍になります。

そして、1 CUH あたりでいくらかかるのか、というのは Watsonx.AI 作成時の Watson Machine Learning サービスインスタンスのプランによって変わります。例えば Essential Plan の場合、1CUH あたりの額は(2024/09/25 時点で)75.7146 円となっています:
2024091201


これらの数値より、仮にチューニングにかかる時間が1時間であったとすると、そのチューニングコス
  1(H) * 43(CUH) * 75.7146 (JPY) = 3255.7278 (円)
ということになります。 あくまで 2024/09/25 時点の Essential Plan での価格および為替レートに基づいた1時間あたりの数字なので、実際の価格は自分のプラン、チューニングデータ量に合わせて再度計算が必要になる点に注意してください。

そして、では今回の(上述のチューニングデータを使っての)チューニングでどれだけの CUH を消費したか、という数値はチューニング後のプロジェクト画面に反映されています。私が実際に上記データを使ってチューニングした結果は以下のようになっていました:
2024092538


11.8 CUH とのことでした(あくまで私が試した時の結果です)。これはつまり、
 11.8(CUH) * 75.7146 (JPY) = 893.43228(円)
ということになりました。 実際、このチューニングでは不十分だったと思っているので、あまり参考にならない数字かもしれませんが、「試しに1回軽くチューニングすると千円くらい」というのが1つの目安に・・・なりますかね? 繰り返しますが、あくまで目安の数字であることに注意してください。


【まとめ】
今の時点でまだあまり外部情報のない Tuningu Studio を使ってみました。2024-09-25 現在ではプロンプト・チューニングだけが提供されている状況で、「膨大なトークン数を消費してコストがかさむのを防ぐためのチューニング」が主目的になるものと考えられます。 こういうコスト削減方法もあるんですねー。




このブログエントリは IBM Cloud アドベントカレンダー 2023 に参加しています。12/20 ぶんの記事です(このブログエントリ自体は 12/14 に公開します):
2023112901



IBM Cloud から提供されている機械学習型チャットボット生成の Watson Assistant が、ブランド名称変更により Watsonx Assistant となりました:

https://www.ibm.com/jp-ja/products/watsonx-assistant
2023121401


"Watson Assistant" で検索した結果からブラウズした場合は新ブランドページに推移します:
2023121402



私も「ブランド名の変更があっただけで、中身は変わってないよね?」と思っていました。結論として機能的にはそれほど大きく変わったわけではないのですが、新しくインスタンスを作成した直後の画面が変わっていて、従来のダイアログ機能(インテントやエンティティを定義して会話の流れを作るツールとその機能)を利用する方法が分かりにくくなっていると感じました。これまでの Watson Assistant では普通に使えていたダイアログ機能を新しい UI で使えるようになるまでの手順を以下に紹介します。


まず最初の(名前設定などの)初期設定を一通り実行します。その後に画面左のメニューから下の方にある "Assistant settings" を選択します:
2023121403


画面を下の方にスクロールすると、"Activate dialog" と書かれたボタンがあるのでクリックして、アクティベートします:
2023121404


アクティベート後に再度左メニューを開くと、先ほどまでは表示されていなかった "Dialog" という項目が表示されているはずです。これをクリック:
2023121405


これで従来のダイアログ設計画面が表示されます。ここからインテントやエンティティといった要素を定義できます:
2023121406


一瞬「あれ?ダイアログ無くなった??」とビビりました。 (^^;  よかったよかった。


このブログエントリは Oracle Cloud Infrastructure アドベントカレンダー 2023 に参加しています。シリーズ2の 12/03 ぶんの記事です(↓の記事内容は 2023 年 12 月 02 日時点の内容で記載しています):
2023120101


このブログで紹介するテーマは「プライベート heroku っぽい PaaS 環境を無料で作る」というものです。個人プログラマにとって無料で使える環境というのはありがたいもので、Oracle Cloud Infrastructure(OCI) の always free tier は本当に貴重な環境であります。この環境に加えて、
sslip.io
dokku
という2つの無料サービス+無料アプリを使って、自分専用の heroku っぽい PaaS 環境を構築する(ついでに GitHub Actions も併用して CI/CD 環境も用意する)、というものです。


【heroku っぽい環境】
そもそも「heroku っぽい PaaS 環境」の「heroku っぽい」 環境というのがどんな環境なのか、heroku をご存じな人であれば heroku そのものをイメージしていただくのがいいと思うのですが、ご存じない人向けに私の理解で簡単に紹介しておきます。

heroku は 2007 年に創業したクラウドサービス事業名であり、その運営会社名です。Java, JavaScript, Ruby, PHP といった各種プログラミング言語によって開発されたウェブアプリケーションを仮想コンテナ上で実行するプラットフォームを提供しています。ウェブアプリケーションに加えて各種データベースや管理・監視系サービスも併せて利用することができます。最大の特徴は PaaS(Platform as a Services) を体現するシンプルさで、手元にアプリケーションのソースコードがあれば(あるいは GitHub などのソースコードリポジトリがあれば)コマンド1つでクラウド上にアプリケーションをデプロイ/更新/スケールすることができます。"*.herokuapp.com" というアプリ公開用ドメインが提供されていて、早い者勝ちでこのドメインを使ったホスト名によるアプリケーション公開ができます(カスタムドメインを利用することも可能です)。2010 年には買収に伴う形でセールスフォース・ドットコム傘下となり、セールスフォース連携機能も強化されました。

heroku は 2022 年 8 月までは無料枠を提供していましたが、現在は無料で利用することはできません。この記事で紹介する内容は、この heroku 環境を模した(というか、ほぼそのものの)「heroku っぽい」環境を自分専用に構築する、という内容です。


【sslip.io】
自分専用の heroku っぽい環境を作る、実はこれ自体は後述の dokku を使うことでさほど難しくなく構築することができます。問題は「無料で」の部分です。肝心のサーバーは OCI の always free tier などを使うことでなんとかなりそうなものですが、選択肢が少ないのが「アプリ公開用のドメインをどうするか?」でした。

この PaaS 環境はアプリケーションを1つだけ公開するわけではなく、リソースの許す限り(今回の例だと OCI の always free tier 環境の限界まで)使うことができます。つまり "app1.domain.net" と "app2.domain.net" と "app3.domain.net" と・・・のように複数のアプリケーションをこの環境で公開することができるのです。そこでこの "domain.net" に相当するドメインが問題になります。無料のホスト名を入手する DNS サービスなどもありますが、このような heroku っぽいプラットフォームを作ろうとすると、単に1つや2つのホスト名が使える DNS サービスでは不十分で、ワイルドカード DNS("*.domain.net" というワイルドカード付きホスト名に対応した DNS サービス)を、それも無料のものを使う必要があります。

そこで今回使うのが sslip.io です。ここは無料のワイルドカード DNS に対応した無料サービスなのですが、特筆すべきはその便利さです。事前のユーザー登録や設定なども不要(!)で、例えば
 XX.XX.XX.XX
というパブリック IPv4 アドレスであれば、
 XX.XX.XX.XX.sslip.io
という名前でアクセスできます。しかもワイルドカード DNS に対応しているので、
 *.XX.XX.XX.XX.sslip.io
というワイルドカードホスト名を(無料で)使うことができます。まさに今回のテーマのための神サービス! この sslip.io を使って PaaS 上にデプロイした各アプリケーションにホスト名でアクセスすることができるようになります。


【dokku】
そして dokku です。オープンソースの PaaS 環境は数あれど、構築や運用がここまで簡単なものは他にないと思っています(その代わり1サーバーで全環境を構築することになります。複数サーバーを束ねて PaaS 環境を作るのではなく、1サーバーだけのシンプルな構成で構築します)。

dokku 自体が「プライベート版 heroku」という代名詞で呼ばれることもあり、heroku と非常に似たインターフェースを持っています。dokku 本体が docker を内蔵しており、デプロイした各アプリケーションやデータベースは全て docker コンテナとして稼働します(docker コマンドを使って構築・運用するわけではありませんが、docker コマンドでコンテナの様子を確認したりもできます)。

また多くのプラグインも公開されており、例えば今回も使う Let's Encrypt プラグインを使うことでウェブアプリケーションを SSL 証明書に対応させることも(https アクセスに対応させることも)可能です。


これらのサービスやソフトウェアを組み合わせることで heroku っぽい PaaS 環境を無料で構築していきます。


【前提準備】
以下の構築作業に入る上での事前準備として、以下の準備までは完了しているものとします:

・OCI アカウント取得
Ubuntu ベースの always free tier インスタンスの作成
・同インスタンスへの SSH ログイン
・同インスタンスへの TCP 80 番ポート、および TCP 443 番ポートの解放

重要な点として、always free tier インスタンスは CentOS ベースではなく Ubuntu ベースのもの(デフォルトユーザー名が opc ではなく ubuntu のほう)にする必要があります。CentOS の場合、dokku の標準インストーラーではインストールすることができません。なんか色々工夫することで dokku インストール自体はできるようになるかもしれませんが、インストール後の運用手順とかにも影響ありそうなので、今回の記事では対象外とします。

また今回の作業の最終結果として構築する PaaS 環境ではデプロイされたウェブアプリケーションに 80 番(http)および 443 番(https)ポートで接続することになります。したがって Ubuntu 側もこれらのポートにアクセスされる想定でファイアウォールを準備しておく必要があるのでした(デフォルトでは OCI のサブネットと Ubuntu の ufw の両方が閉じられています)。この辺りはこちらの記事が参考になると思います(私も参考にさせていただきました):
Oracle Cloud(OCI)でポートを開放する方法


前提準備がそろった所で dokku を使ったプライベート PaaS 環境の構築を行います。


【dokku 環境構築作業手順】
SSH で対象の Ubuntu サーバーにログインします。以下、しばらく CLI での作業になります。とりあえずお約束のリポジトリ更新コマンドを実行しておきます:
$ sudo apt update -y && sudo apt upgrade -y

dokku はインストール用のスクリプトが提供されているので最初にダウンロードします:
$ wget -NP . https://dokku.com/bootstrap.sh

sudo を付けてインストールスクリプトを実行します。その際にバージョン番号(2023/12/02 時点での最新バージョンは v0.32.3)を指定します:
$ sudo DOKKU_TAG=v0.32.3 bash bootstrap.sh

このインストール作業は結構時間がかかります(docker のインストールや初期状態で必要なイメージのダウンロードも含みます)。作業が完了してプロンプトが戻るまでしばらく待ちます(ネットワーク次第ですが 10 分前後?)。

インストールが完了したら dokku にドメインを設定します。今回使う always free tier の Ubuntu サーバーのパブリック IP アドレスが XX.XX.XX.XX であったとして、以下のコマンドを実行します(XX.XX.XX.XX 部分を実際の IP アドレスに替えて実行してください):
$ dokku domains:set-global XX.XX.XX.XX.sslip.io

次に秘密鍵と公開鍵を dokku に登録します。dokku は dokku 自体が git リポジトリを内包していて、この内包 git リポジトリを使ってアプリケーションをデプロイするのですが、その際に利用する鍵ペアを登録する必要があるのでした。お持ちの鍵ペア(秘密鍵ファイルと公開鍵ファイル)があればそれを使うこともできるのですが、後述する CI/CD 機能のため「パスフレーズのない鍵ファイル」を用意することをお勧めします。ここではパスフレーズのない鍵ファイルを作成する手順を紹介します。

以下のコマンドを実行します。実行直後に作成する鍵ファイル名が表示されるので(特に変更の必要がなければ)そのまま Enter キーを押してください。次にパスフレーズの入力を求められますが、今回は何も指定せずにそのまま Enter キーを押してください(再度同じパスフレーズの入力を求められた時もそのまま Enter):
$ ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa): ←[Enter]キーを押す
Enter passphrase (empty for no passphrase): ←パスフレーズを入力せず [Enter] キーを押す
Enter same passphrase again: ←もう一度そのまま [Enter] キーを押す
Your identification has been saved in /home/ubuntu/.ssh/id_rsa.
Your public key has been saved in /home/ubuntu/.ssh/id_rsa.pub.

この操作が完了すると /home/ubuntu/.ssh/ フォルダ内に秘密鍵(id_rsa)と公開鍵(id_rsa.pub)の2つが作成されます。念のためパーミッションを 400 に変更しておきます(デフォルトでそうなっていると思いますが、念のため):
$ chmod 400 ~/.ssh/id_rsa*

これで dokku で使う秘密鍵ファイルと公開鍵ファイルが用意できました(既に所有していた鍵ファイルを使う場合はここから)。

まず以下のコマンドを実行して秘密鍵を登録します:
$ eval "$(ssh-agent)"

$ ssh-add -k ~/.ssh/id_rsa

続いて以下のコマンドを実行して公開鍵を dokku に登録します:
$ cat ~/.ssh/id_rsa.pub | sudo dokku ssh-keys:add admin

dokku 自体の環境構築はこれでほぼ完了していますが、ついでに前述の Let's Encrypt プラグインも導入しておきます。以下のコマンドを実行してください(2つ目のコマンドは Let's Encrypt で SSL 鍵を作る際に必要なメールアドレスの指定です):
$ sudo dokku plugin:install https://github.com/dokku/dokku-letsencrypt.git

$ dokku config:set --global DOKKU_LETSENCRYPT_EMAIL=(自分のメールアドレス)

ここまでの作業で dokku のインストール/セットアップは完了しました。


【アプリケーションをデプロイ】
dokku の動作確認の意味も含めて、この状態で一度ウェブアプリケーションをデプロイしてみましょう。自分で使ってみたいアプリケーションがあればそれを使っていただいてもいい※のですが、特にない方は私のアプリを使ってみてください(一応 Node.js で作られていますが、単にメッセージを表示するだけの本当にシンプルなウェブアプリケーションです):
https://github.com/dotnsf/simpleweb


※自作のものなど、他のアプリケーションを使っても構いませんが、この段階ではデータベースなどを併用しないものを用意してください。


まずはアプリケーションのソースコードを入手します。改めて Ubuntu の CLI で以下を実行してソースコードを git clone してください(自分のソースコードを使う場合は自分のコードの URL を指定してください):
$ cd

$ git clone https://github.com/dotnsf/simpleweb

$ cd simpleweb

このローカルリポジトリに dokku 用のオリジンを追加します(localhost の git を使って dokku という名前で simpleweb のオリジンを作成しています):
$ git remote add dokku dokku@localhost:simpleweb

このオリジンからデプロイする先のアプリケーション(simpleweb)を dokku 環境にあらかじめ追加しておきます:
$ dokku apps:create simpleweb

では実際にアプリケーションをデプロイします。git コマンドで作成したオリジンに push することで dokku 内へのデプロイが実行される仕組みが提供されているので、デプロイ作業は単に目的のオリジン(dokku)へ main ブランチを git push するだけです(秘密鍵にパスフレーズが指定されている場合はここで入力を促されるので正しいパスフレーズを入力してください):
$ git push dokku main

git push 実行後にデプロイが開始されます。ここではソースコードの内容からプラットフォーム環境(この simpleweb アプリの場合は Node.js 環境)を特定し、このプラットフォーム向けに docker コンテナイメージが作成され、そのイメージが dokku 内の docker コンテナとしてデプロイされることで完了します(というわけで、他のコマンドと比較して長い時間(約1~2分)がかかります):
2023120102


無事にデプロイが完了したら、最後にポート番号のプロクシ設定をします。この simpleweb アプリケーションは 8080 番ポートで稼働するよう作られているので、80 番ポートから 8080 番ポートに転送してアクセスできるよう設定します:
$ dokku proxy:ports-add simpleweb http:80:8080

2023120103


これで simpleweb アプリケーションが 80 番ポートで公開されているはずです。ウェブブラウザを起動して、
  http://simpleweb.XX.XX.XX.XX.sslip.io/
にアクセス("XX.XX.XX.XX" は Ubuntu サーバーの IP アドレス)し、以下のような画面になることを確認してください。このような画面が表示されれば成功です。dokku が正しくインストールされ、アプリケーションもデプロイできて、sslip.io を使ったホスト名での(HTTP による)アプリケーションアクセスができることが確認できました:
2023120104


ついでに HTTPS アクセスを有効にしましょう。コマンドラインで以下のコマンドを実行します:
$ dokku letsencrypt:set simpleweb email (自分のメールアドレス)

$ dokku letsencrypt:enable simpleweb

2023120105


ここまで正しく実行した上でウェブブラウザをリロードすると(TSHS が有効になっているので)自動的に HTTP から HTTPS に切り替わり、https アクセスで同じ画面が表示できるはずです(もちろん直接 https://simpleweb.XX.XX.XX.XX.sslip.io/ にアクセスしても同じ結果になります):
2023120106


【CI/CD】
最後に Github Actions を使った CI/CD 環境の構築手順についても紹介しておきます。GitHub でバージョン管理しているソースコードが更新されたタイミングで自動的に dokku 上のアプリケーションを最新ソースコードのアプリケーションに更新する、というものです。

まずは GitHub 上に管理対象のソースコードリポジトリを用意します。プライベートリポジトリでもパブリックリポジトリでもどちらでも構いません。以下では https://github.com/dotnsf/web-app-test というリポジトリを使った例を紹介しますが、実際に試す場合は実際の(自分が開発者としてアクセスできる)リポジトリを使ってください:
https://github.com/dotnsf/web-app-test


そしてそのリポジトリを使って上述のアプリケーションデプロイ手順を実行しておきます。つまり一度手動でオリジンを追加(git add remote origin)して、アプリケーションを作成(dokku apps:create)して、デプロイ(git push dokku main)して、HTTPS アクセスを有効(dokku letsencrypt:enable)にしておき、アプリケーションに HTTPS アクセスができる状態を作っておきます:
2023120105


この状態から CI/CD 環境を構築していきます。まずは GitHub Actions を定義するのですが、手始めに秘密鍵を登録します。GitHub の該当リポジトリで "Settings" メニューを選択します:
2023120107


"Settings" 画面の左メニューから "Secrets and variables" - "Actions" を選択します:
2023120108


秘密鍵を登録したいので "Secrets and variables" 画面内の "New repository secret" ボタンをクリックします:
2023120101


秘密鍵を登録する画面が表示されます。NAME 欄には SSH_PRIVATE_KEY と入力します。また value 欄には上述の作業中に作成して使った秘密鍵ファイル(id_rsa)のテキスト内容を "-----BEGIN RSA PRIVATE KEY-----" から "-----END RSA PRIVATE KEY-----" まで)をそのままコピー&ペーストして入力し、最後に "Add secret" ボタンをクリックします:
2023120102


以下のように表示されれば、GitHub リポジトリへの秘密鍵の登録は完了です:
2023120103


次にリポジトリ内にプッシュ時に実行される GitHub Actions を定義します。そのためにソースコード内に .github/workflows/ というフォルダを作成し、その中に deploy.yml(つまり .github/workflows/deploy.yml ファイル)を以下の内容で作成します:
---
name: 'deploy'

# yamllint disable-line rule:truthy
on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Cloning repo
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Push to dokku
        uses: dokku/github-action@master
        with:
          # specify the `main` branch as the remote branch to push to
          branch: 'main'
          git_remote_url: 'ssh://dokku@XX.XX.XX.XX:22/web-app-test'
          ssh_private_key: ${{ secrets.SSH_PRIVATE_KEY }}

青字XX.XX.XX.XX は Ubuntu サーバーのパブリック IP アドレスで、赤字web-app-test 部分は(dokku apps:create した時に指定した)アプリケーション名で、それぞれ置き換えて作成してください。またソースコードの書き換えが視覚的にもわかるよう、アプリケーション側にも何らかの変更を加えておいてください。

これらのファイルをリポジトリに追加して更新します:
$ git add .

$ git commit -m 'dokku CI/CD with Github Actions'

$ git push

最後の "git push" が完了すると上記で作成した Github Actions が起動し、定義内容に従って自動的にビルド/デプロイが開始されます。デプロイの様子は Github リポジトリの "Actions" メニューから確認することが可能です:
2023120104


デプロイ完了後にアプリケーションにアクセスすると、最新のソースコードでデプロイされたアプリケーションが表示されるはずです(元のアプリで表示されていたメッセージの最後に "!" を追加する変更を加えていたのですが、正しく反映されていました):
2023120106


これで CI/CD も実現できたことになります。ソースコードの main ブランチが更新されてコミット/プッシュされるたびにアプリケーションも自動更新されてデプロイしなおされる、という便利な機能も使うことができそうでした。


【おまけ】
自分が dokku を使っていて気付いたことなのですが、どうもデプロイのたびに変なゴミというか、使われることのないファイルが残ってしまうらしく、特に CI/CD を使って何度もデプロイしていると、どんどんディスクの残り容量が減っていってしまうようでした。これを回避するには定期的に以下のコマンドを実行する必要があります:
$ docker system prune -f && docker system prune --all -f

面倒でなければ手入力でもいいと思いますし、面倒な場合は crontab にでも登録してアクセス数が比較的少なそうな時間帯に実行するのがいいと思っています。


【まとめ】
以上、無料のサービスだけを組み合わせる形で、CI/CD 含めたプライベート heroku (っぽい)環境を作ることができました。理論上はこの環境にいくつでも複数のアプリケーションを登録して、別々に運用することができる環境なのですが、さすがに always free tier の環境(メモリ 1GB ディスク 30GB)で運用することを考えると、5~6アプリが限界ではないかと思っています。もちろんこのリソーススペック上の制約は有償版を使うことで回避できます。また有償版の OCI なら DNS も使えるので(sslip.io を使う形ではなく)カスタムドメインを利用して環境構築することもできるようになります。 とはいえ、「無料で構築できる PaaS 環境」という素敵な響きにも替え難い魅力がありますよね。いずれはリッチなスペックの VM +カスタムドメインで運用するとしても、初めのうちはこの無料環境でプライベート PaaS を楽しむのも悪くないと思っています。なお(無料というわけにはいきませんが)カスタムドメインやその DNS のセットアップまで含める形で dokku 環境を作ったこともあります(OCI は全く使ってませんけど・・)。その時の内容に興味ある方は私の dokku 関連の過去の記事を参照ください。

dokku に関して、とりあえず環境構築と試験的な運用までが可能な一連の手続きについてはこのブログエントリ内で紹介していますが、実際にはこの中で紹介していない色々な機能があります(スケール対応とか、データベース系のプラグインを併用するとか、・・)。dokku はオンラインヘルプも充実しているので、詳しくはドキュメントを参照してください。

最後に注意点を。今回紹介した方法で dokku 環境を構築してアプリケーションを公開すると、事実上サーバーの IP アドレスを公開する形になります(sslip.io を使っているので、アプリケーションのホスト名の中に IP アドレスが含まれることになるからです)。サーバーの IP アドレスがバレても困らないように SSH などはしっかりセキュアに対策しておくといった対策はしっかりしておきましょう。

私自身は実際に dokku で(カスタムドメインを使って)自作サービスをいくつか運用しています。2年以上使っていますが、とても便利です。この記事が私と同じような技術クラスタの人のお役に立てれば何よりもうれしいです。


ちょっとした UI 系トラブルに巻き込まれた結果とある機会に CLI 操作だけで IBM Cloud 上に Openshift クラスタ(いわゆる "ROKS")を作る必要が生じて、実際に試してみました。以下、その時に実行したコマンド群を順に紹介します。


【前提条件】
やりたかったことは単純に「VPC(Virtual Private Cloud)環境内に OpenShift クラスタを1つ作る」ことでした。既に VPC 自体はサブネット含めて作成済みで、バックアップストレージの Cloud Object Storage インスタンスも作成済みです。 後はこの VPC 内に OpenShift クラスタをスペックやワーカーノード数を指定して作るだけ、という状況です。


【CLI コマンド】
以下 CLI コマンドを記載します。ここまでに "ibmcloud login" は実行済みであるとします。

詳しくは下記参考ページを参照いただきたいのですが、VPC 内に OpenShift クラスタを作るための CLI コマンドは以下のようになります:
$ ibmcloud oc cluster create vpc-gen2 --name (クラスタ名) --zone (作成先ゾーン名) --vpc-id (作成先 VPC ID) --subnet-id (作成先サブネット ID)  --flavor (ワーカーノードのフレーバー) --version (OpenShift バージョン) --cos-instance (Cloud Object Storage の CRN) --workers (1ゾーンあたりのワーカーノード数)

で、このコマンドを実行するためには(上記コマンド内にも括弧がたくさんあるように)指定する必要がある多くのパラメータ情報を事前に集めておく必要があります。というわけでまずはパラメータ情報を収集するための CLI コマンドから説明します。

まず "--name" パラメータで指定する「クラスタ名」は自分で自由に指定することができるので説明は不要だと思います。次に "--zone" パラメータで指定する「作成先ゾーン名」ですが、これは目的のゾーンが例えば「大阪3」であったとして、この「大阪3」を指定するための文字列です。これを調べるには次のコマンドでゾーン一覧を取得して、そこから目的のゾーンの ID を取り出します(青字が入力コマンドです):
$ ibmcloud oc zone ls --provider vpc-gen2
OK
ID           Name         Metro             Flavors
au-syd-1     au-syd-1     Sydney            -
au-syd-2     au-syd-2     Sydney            -
au-syd-3     au-syd-3     Sydney            -
br-sao-1     br-sao-1     Sao Paulo         -
  :
eu-gb-3      eu-gb-3      London            -
jp-osa-1     jp-osa-1     Osaka             -
jp-osa-2     jp-osa-2     Osaka             -
jp-osa-3     jp-osa-3     Osaka             -
jp-tok-1     jp-tok-1     Tokyo             -
jp-tok-2     jp-tok-2     Tokyo             -
jp-tok-3     jp-tok-3     Tokyo             -
us-east-1    us-east-1    Washington D.C.   -
  :

この結果から「大阪3」を使う場合に指定するゾーン名が "jp-osa-3" であることが分かります。

次に作成先の「VPC ID」です。VPC が決まっていても、その ID を取り出して指定する必要があります。これは以下のコマンドを実行することで取り出せます:
$ ibmcloud oc vpcs --provider vpc-gen2
OK
Name              ID                                          Provider
xxxxxxx-vpc-osa   ****-********-****-****-****-************   vpc-gen2
  :

目的の VPC 名と照らし合わせることで ID を確認することができます("****-********-****-****-****-************" という値であったと仮定します)。

作成先の「サブネットID」も調べる必要があります。普段は名称で扱っていて、ID を意識することがあまりないのですが CLI 操作時には必要な情報です。これは以下のコマンドで "xxxx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" であることが確認できます:

$ ibmcloud oc subnets --provider vpc-gen2 --vpc-id (VPC ID) --zone (ゾーン名)
OK
Name                ID                                          Public Gateway Name                        Public Gateway ID                           IPv4 CIDR Block   Available IPv4 Addresses
sn-xxxxxxxxxxx-03   xxxx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   pgw-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx   10.xxx.xxx.0/24   244

ワーカーノードのフレーバー(スペック)も実行時に指定する必要のある情報です。これは以下のコマンドでフレーバーの一覧を取得し、目的のフレーバーの ID を取り出します。今回は "bx2.16x64" というスペックのフレーバーを使うことにします:
$ ibmcloud oc flavors --zone (ゾーン名) --provider vpc-gen2
OK
For more information about these flavors, see 'https://ibm.biz/flavors'
Name           Cores   Memory   Network Speed   OS             Server Type   Storage
  Secondary Storage   Flavor Class   Provider
bx2.16x64      16      64GB     24Gbps          UBUNTU_20_64   virtual       100GB     0B, *               bx2            vpc-gen2
bx2.2x8†       2       8GB      4Gbps           UBUNTU_20_64   virtual       100GB     0B                  bx2            vpc-gen2
bx2.32x128     32      128GB    25Gbps          UBUNTU_20_64   virtual       100GB     0B, *               bx2            vpc-gen2
b
  :
  :

OpenShift のバージョンも指定する必要がある項目ですが、これは普通に "4.11_openshift" などと指定できます。またゾーンあたりのワーカーノード数も普通に "2" などと数字で指定可能です。

最後に Cloud Object Storage の CRN を取得します。これは取得が面倒なのですが、作成済みリソースの一覧を取得し、そこから目的の Cloud Object Storage サービスを探して、その ID を見つける、という方法で取得します:
$ ibmcloud resource service-instances --long
OK
   :
   :
ID:                 crn:v1:bluemix:public:cloud-object-storage:global:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::

GUID:               xxxxxxxxxxxxxx


Name                Cloud Object Storage for me


Location            global
   :
   :

これで OpenShift クラスタを作成するために必要な最低限の情報が揃いました:
情報
ゾーン名jp-osa-3
VPC ID****-********-****-****-****-************
サブネット IDxxxx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ワーカーノードのフレーバーbx2.16x64
OpenShift バージョン4.11_openshift
1ゾーンあたりのワーカーノード数2
Cloud Object Storage の CRNcrn:v1:bluemix:public:cloud-object-storage:global:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::



これらの情報を使って以下のコマンドを実行します:
$ ibmcloud oc cluster create vpc-gen2 --name (クラスタ名) --zone jp-osa-3 --vpc-id ****-********-****-****-****-************ --subnet-id xxxx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  --flavor bx2.16x64 --version 4.11_openshift --cos-instance crn:v1:bluemix:public:cloud-object-storage:global:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:: --workers 2
Creating cluster...
OK
Cluster created with ID ***************************

成功すると上述のようにクラスタ ID("***************************")が表示され、「デプロイ中」のステータスとなります。


なお、マルチゾーンで作成する場合は上記の作業を行ってシングルゾーンでクラスタを作成した上で、追加するゾーンのゾーン名とサブネット ID を取得してから以下のコマンドを実行してワーカープールにワーカーノードを追加します:
$ ibmcloud oc zone add vpc-gen2 --zone (追加するゾーン名) -c (クラスタ名) --worker-pool (追加先のワーカープール名) --subnet-id (サブネットID)
OK

これで IBM Cloud のダッシュボード画面にアクセスできなくてもしなくても、CLI だけで Openshift クラスタを作ることができそうです。


【参考】
https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-create-vpc-gen2&interface=cli


 

先日このブログでも紹介した IBM watsonx.ai のベータ版 REST API を使って、Node-RED のカスタムノードを作り、公開してみました。以下で使い方を紹介しますが、実際に利用するには前回 REST API を利用する紹介をした時のブログでも作成した Watson Studuio と Watson Machine Learning を使ったプロジェクトを登録しておく必要があります(そのプロジェクトの ID が必要です)。またこれも同様に前回紹介しましたが、実行するユーザーの IBM Cloud IAM API キーを生成/取得しておく必要があるのでこちらも準備の上で試してみてください。

なお以下で紹介する内容では Node-RED v2.2.3 を使って動作確認しています。また私が提供しているものは公式のものではなく、あくまで個人的に開発したものを個人的に公開しているだけであること、現時点で提供されている REST API 自体がベータ版のため、今後近い将来の API 変更などにより動かなくなる可能性があることをご了承ください(とはいえ、私も使うので、少なくとも公式ノードが出るまではなるべくタイムリーにメンテナンスするつもりです)。


【パレットに watsonx.ai ノードを追加】
Node-RED のパレット画面を開き、右上のメニューから「パレットの管理」を選択してパレットのカスタマイズ画面に移動します。ここで「ノードを追加」タブを選び、"node-red-contrib-dotnsf-watsonxai" を検索してください(2023年7月20日時点では "watsonx" と検索すると1つだけ(!)見つかるのがそれです)。検索できたら「ノードを追加」ボタンをクリックします:
2023072001


以下のような確認ダイアログが表示されるので「追加」をクリックします:
2023072002


正しくインストールされると「ノードをパレットへ追加しました」というメッセージが表示されます。パレット管理画面を閉じます:
2023072003


元のパレット画面に戻ると、"watsonx.ai" というノードが追加されているはずです:
2023072004


【watsonx.ai ノードを使う】
では追加された watsonx.ai ノードを使ってみます。watsonx.ai ノードの前後に適当なノードを追加します。以下ではシンプルで分かりやすい代表として、inject ノードと debug ノードで挟んでみました:
2023072005



watsonx.ai ノードにデータを渡すノード(上図では inject ノード)からは、msg.payload にいわゆる「プロンプト」のテキストを指定します。watsonx.ai ノードは自分に送られてきたデータの msg.payload にプロンプト指定がされている前提でそのテキスト内容に書かれた指示の返答テキストを生成します。

以下の例では msg.payload の内容を(前回のブログで紹介した内容に合わせて)以下のようにしてみました:
入力:\nAbout Watson Discovery\\nIBM Watson® Discovery is an intelligent document processing engine that helps you to gain insights from complex business documents.\n翻訳\n

2023072006


入力内容が英語で書かれていて、最後に「翻訳(してね)」と指示している内容です。watsonx.ai ノードの手前のノード(inject ノード)の設定内容は以上です。

次に watsonx.ai ノード自体にも設定が必要です。watsonx.ai ノードをダブルクリックしてプロパティ設定画面を開き、API Key と Project ID をそれぞれ入力します:
2023072007


このうち API Key は IBM Cloud の IAM API キーの値で、Project ID は Watson Studio と Watson Machine Learning で作成したプロジェクトの ID です。これらも前回のブログで紹介したものと同じ内容の問い合わせを行うサンプルなので、この作業について詳しくはこちらも参照してください。


全ての設定が完了したら作成したフローを「デプロイ」します:
2023072008


デプロイ後に inject ノード左のボタンをクリックしてメッセージを送信すると、watsonx.ai ノードが API キー、プロジェクト ID 、そしてプロンプトテキスト内容を元に問い合わせを行い、その結果が画面右のデバッグ画面内に表示されます:
2023072009


私が 2023 年7月20日に試した際の結果は "Watson Discoveryはビジネスドキュメントに関する意見を得るための知能型ドキュメント処理エンジンです。" と表示されました。上述の英語文章を翻訳してほしい、というプロンプトだったので、質問意図を正しく理解して実行できているようでした。


(いずれにせよベータ版 API を使うことになりますが)REST API を直接実行することでカスタムアプリケーションを作ることもできますが、今回紹介した Node-RED のカスタムノードを使うことで、より手軽に watsonx.ai のテキスト生成機能を体験できるようになったのではないかと思っています。


このページのトップヘ