はてなブックマーク

今回は DeepSpeed-Chat による RLHF のご紹介です。正直、データセットや計算資源の都合もあり、とりあえず動かしてみました！的な話にはなりますが、RLHF の効果が実際に確認できるか見てみたいと思います。 1. はじめに 今回は DeepSpeed-Chat1 を使って RLHF を試してみたいと思います。RLHF は Reinforcement Learning from Human Feedback の略で文字通り「人からのフィードバックを用いた強化学習」ということですね。OpenAI が InstructGPT(ChatGPT の元になったモデル)2 で使ったことで注目された手法になります。 LLM がらみで何か記事にしたいと思いつつ、日々新たな LLM が発表されている昨今に、隔月＆内容が実時間から月単位で遅れ気味wの本連載です。 「どうしたもんかな。。。」と悩みに

今回は Transformer 系のモデル、具体的には BERT, T5, GPT の推論を高速化してみます。高速化手法として FasterTransformer, Torch-TensorRT, AWS Neuron を用い、素 の transfomers に比べ、どの程度速くなるか（ならないか）、利点・欠点を確認してみましょう。 1. はじめに 今回は Transformer 系のモデル、具体的には BERT, T5, GPT の推論を様々な技術を使って高速化してみます。 高速化の元ネタは Hugging Face の transformers1 縛りとして、素の transformers で推論する場合に比べ、 どの程度速くなるか（ならないか）見てみましょう。 推論を高速化する技術としては FasterTransfomer2, Torch-TensorRT3, AWS Neuron(

Transformer のパラメータ数を増やしながらも必要な計算量の増加を抑えることができる Switch Transfomer のご紹介です。Google さんのように1兆6千億パラメータは無理ですが、規模が小さいモデルでも効果が見込めるようなので、実際に動かして確認してみたいと思います。 1. はじめに 今回は今年1月に発表された Switch Transformer 1 の話です。 Transformer というモデルはそのサイズに応じて性能が伸びることが良く知られています2。近年どんどん巨大化しており、 Switch Transformer ではついにパラメータ数が1兆6千億個に達しました3。 この連載ではこの手の巨大なモデルは「スゴイのはわかるんですけれど、デモをつつくぐらいで手元で動かせないなぁ～。」とスルーしていたのですが、 Switch Transformer はパラメータ

今回は文章のベクトル化を扱います。文章のベクトル化は 第9回 で扱っていますが、当時に比べてデータセット、事前学習モデル、ライブラリ等でいろいろと状況が好転しているので、改めて扱ってみることにしました。最近は大規模データセットを用いた事前学習が公開されているので、作り比べてみます。 1. はじめに 今回は sentence-transformers1 で文章のベクトル化にチャレンジしてみます。文章をベクトル（埋め込み表現）化することで、文章間の意味合い的な比較が可能になり、類似文章検索やクラスタリングなどが可能になります。 このライブラリは 第9回 で紹介済みですが、当時のバージョンは 0.2.5.1 であり、その後に損失関数が追加されていたり、サンプルコードが充実したりとかなりの更新が入って執筆時点で 2.1.0 になっています。ついでに言うと 第9回 は結構アクセス数があるみたいなので

今回は教師なしの文章ベクトル化手法である MixCSE の検証です。教師なし学習ですから教師ありの手法よりは精度的に不利でしょうが、局面によっては役に立つケースもあるのでは？と試してみることに。公開されているコードは transformers ベースなのですが、今回は Colab の TPU で動かしてみたので、その方法も紹介しますね。 1. はじめに 今回は教師なしの文章ベクトル化手法である MixCSE1 の検証をしてみました。 本連載では文章ベクトル化のモデルとして、 Sentence BERT を取り上げたこと(第9回, 第18回)がありますが、品質の良いベクトルを生成する為には大量かつ良質の教師データが必要でした。 法律や特許のような特定領域に特化した文章を扱う局面では、対象領域の文書で学習したモデルを使いたいところですが、特定領域限定の都合良いデータはなかなか手に入りません。そ

今回は T5X と Prompt Tuning の検証をしてみました。T5X は JAX と Flax で実装された T5 の新世代実装です。 Prompt Tuning は近年流行している事前学習済みモデルとプロンプトで下流タスクを解く手法の一つです。 Prompt Tuning に関しては T5X で実装されたコードが公開されていたので、合わせて検証してみることにしました。 1. はじめに 今回は T5X1 と Prompt Tuning2 の検証とご紹介になります。 T5X は第7回で紹介した T53 の次世代実装になります。T5 は、Mesh Tensorflow4 を採用することで、 単一の TPU や GPU に全パラメータが格納できない大規模モデルを実現していますが、学習ループ周辺の実装は Tensorflow 1.x 系列の Estimator API を用いた、やや古びた

今回は Fusion-In-Decoder を使ってクイズに答えるモデルを作ります。以前から Wikipedia 等の外部情報を参照できるテキスト生成モデルを試してみたいと思っていました。Fusion-In-Decoder の発表は 2020 年なので少し前のモデルですが、T5 ベースで手軽に試せるサイズ感ですので、日本語で試してみましょう。 1. はじめに 今回紹介する Fusion-In-Decoder（以下、FiD ）1 は Meta AI (当時は Facebook AI Research) が発表した Open Domain question Answering タスクを解くテキスト生成モデルです。 じつは、以前から外部情報を参照できるテキスト生成モデルを試してみたくて2、 Google の RETRO3 の論文を読んでたんです。 なのですが、外部情報のサイズ感が 1000 B

プログラマがシステム開発において共通で必要となる、技術と業務の狭間の共通知識を解説します。連載第4回は国際化編です。 0. 今回の概要 システム開発で必要となる標準規格の話、第4回は国際化編です。 グローバルな環境で利用される、あるいはグローバルな情報を扱うシステムを構築する際に参考になりそうな話題を取り上げます。 1. 国際化と地域化 ソフトウェアを特定の言語や地域に適合させる工程を「地域化 (localization, L10N)」と言います。しかし、多くの言語や地域に対して個別に地域化を行うと、開発や保守に多くの時間と費用がかかるため、ソフトウェア本体に変更を加えることなく多様な言語や地域に適合できるように予め設計しておく手法が生まれました。これを「国際化 (internatioalization, i18n)」と言います。 L10N、i18n は最初と最後の文字とその間の文字数を使

セキュリティ技術としての「署名」と「証明書」はどう違うのでしょうか？「復号化」という用語に違和感はないですか？本記事では、間違いやすい、混同しやすいセキュリティ用語について解説します。 はじめに セキュリティ技術としての「署名」と「証明書」はどう違うのでしょうか？ 「復号化」という用語に違和感はないですか？ 同じ用語を人によって違う意味で使っていて、仕様書の解釈や打ち合わせでのコミュニケーションに困ったことはないですか？ 本記事では、間違いやすい、混同しやすいセキュリティ用語について解説します。セキュリティ分野の基礎知識を得たいITエンジニアのみなさんの参考になれば幸いです。 目次：間違いやすいセキュリティ用語 暗号化と復号「化」？ 暗号方式の種類 ー 公開鍵暗号と非対称鍵暗号は同じ？ 暗号鍵の種類 ー 秘密鍵は secret key？private key？ 呼び方のバリエーション おす

今回は前回の文章ベクトル化モデルを使って CLIP 風のモデルを作ります。CLIP は画像とテキストを同じ多次元ベクトル空間にエンコードするモデルで、テキストによる画像検索や Zero shot での画像分類が可能です。簡素化された（非公式）実装が公開されているので、日本語で動かして見ましょう。 1. はじめに 今回は前回の文章ベクトル化モデルを使って CLIP 風のモデルを作ります。CLIP1 は OpenAI が発表した画像とテキストを同一多次元ベクトル空間にエンコードするモデルで、テキストによる画像検索や Zero shot での画像分類が可能です。 オリジナルの CLIP は (画像,テキスト) の 4 億ペアを使い、バッチサイズ 32,768 でスクラッチから学習したようなので、とても Colab では動かせません。また公式実装2も公開されていますが、こちらは事前学習済みのモデル

本連載ではKubernetesやマイクロサービスを活用するにあたりどんな準備を進めておけばいいか整理します。第4回はDaprを活用したアプリケーションの構築方法を紹介します。 1. はじめに これまでの連載でKubernetes（AWS EKS）を構築するIaCやアプリケーションのデプロイ手順、ローカルで開発するためのツールなどを紹介してきました。今回はその上で動作するマイクロサービスの連携を考えてみたいと思います。 マイクロサービスは個々のサービスでチームが形成され実装が進められますが、サービス間やシステム全体についても目を向ける必要があります。例えば下記のようなポイントがあるかと思います。 サービス間通信（同期・非同期） サービス間での状態共有 システム全体の観測 部分稼働（障害部分のみ切り離してサービス継続） etc… 今回これらのポイントをアプリケーションに組み込まずに実現する手段

トークナイザを使わない自然言語処理モデルである ByT5 と Charformer のご紹介です。従来の自然言語処理では多くの場合で文章を単語（あるいはサブワード）単位に分かち書きして処理しましたが、今回のモデルは直接、生のテキストを処理します。それでは実際に動かして単語（サブワード）ベースのモデルと比較してみましょう。 1. はじめに 今回は今年5月と6月に発表された ByT51 と Charformer2 の紹介をしたいと思います。一本の記事で 2 つのモデルを扱うのは、この連載では珍しいのですが、この二つはよく似ているというか、Charformer は 「ByT5 にもう一工夫加えたもの」くらいの認識なので、一度にさばいてしまいましょうということで。 さて、この二つのモデルの特徴ですが「分かち書きをしない」という点に尽きます。 今まで、この連載では BERT や T5 等の Tran

物体検出とは、画像内に写っている物体のカテゴリと物体位置を検出する技術です。身近な例としては、スマートフォンでの顔認証や工場における外観検査、自動運転の歩行者検出にも使われています。また、物体検出の歴史は長く、現在でも新しい物体検出手法が盛んに研究されています。 本連載では、自然言語処理でよく使われる「Transformer」を採用した物体検出モデルDETRについて紹介します。DETR自体は1年前に公開されたため、原理などの説明はGoogle検索すれば沢山出てくると思いますが、推論やFine-Tuningの方法を紹介している日本語記事が少ない印象を受けました。そのため、初心者向けにDETRで推論とFine-Tuningを実行する方法をご紹介したいと思います。 1.始めに 本記事では、物体検出の概要とこれまでの歴史を紹介いたします。それを踏まえて、DETRの原理について数学的な細かい説明を省

これまでモノリシックなシステム開発をしてきた会社やチームがKubernetesやその上でのマイクロサービスの開発に取り組むにはいくつか壁があると思います。その壁はどのようにサービス分割するかや会社・チームの体制といった話から、環境の準備やアプリケーションアーキテクチャのような話まで多岐に渡ります。これからKubernetesやマイクロサービスに踏み出したくても手探りではリスクが大きく感じられ、一歩が踏み出せずこれまで通りのやり方で開発を続けられている方も多いのではないかと思います。 しかしビジネスの変化が激しい昨今、これまで以上に素早いリリースや継続的な変更を求められるケースも増えてきており、サーバレスやコンテナの活用が有効な案件が増えてきていることもまた事実です。 そこで本連載ではKubernetesやマイクロサービスを活用するにあたりどんな準備を進めておけばいいか整理します。第1回目は

本連載ではKubernetesやマイクロサービスを活用するにあたりどんな準備を進めておけばいいか整理します。第2回は開発効率を向上させることができるSkaffoldを紹介します。 1. はじめに アプリケーションの開発においてKubernetesを活用する事により様々な恩恵を受けられる一方で、コンテナのビルドやレジストリへのイメージの登録など開発の手順は増えてしまいます。開発作業の中ですべての手順に手動で対応してしまうと、開発効率が悪く非常に面倒に感じることでしょう。連載2回目は、Kubernetessを活用したアプリケーション開発における問題を解決し、開発効率を向上させるSkaffoldを紹介します。 本記事では各技術要素（Kubernetes/Docker/Minikube等）の基本的な概要などについては記載しておりません。適宜各公式ドキュメントを参照してください 2. Skaffol

署名はRSASSA-PSS 2048 SHA-1で、salt長は…なんて言われて各単語の意味や位置付けが分からず困ったことはありませんか？ややこしい暗号関連の用語を体系的に整理してすっきり理解しましょう。 はじめに 暗号の用語って似たような単語があってややこしい！と思ったことはありませんか？ 本稿は暗号に関する専門用語を体系的に整理したものです。暗号に関する主要なキーワードを紹介していますが、個々の要素技術を深く掘り下げることはしません。 ネットで検索するのに適当なキーワードが思いつかない、似たような単語が複数あってイマイチ使い分けに自信がない、セキュリティに関する業務をやることになったけどどこから手を付けていいか分からない、というような方を想定読者にしています。 目次：暗号用語の体系的整理 はじめに 目次：暗号用語の体系的整理 暗号そのものに関する用語 アルゴリズムを一意に特定するために

業務システムを開発する場合、プログラミング言語、フレームワーク、ミドル ウェア、業務知識など以外に、共通で必要となる知識があります。文字コード、 国際化、日付・時刻の扱い、住所コード、郵便番号、電話番号などの各種コー ド、…。 本連載では、プログラマがシステム開発で必要となる、技術と業務の狭間の共通 知識を解説して行きたいと思います。

プログラマがシステム開発において共通で必要となる、技術と業務の狭間の共通知識を解説します。連載第2回は文字コードの実践編です。 0. 前回の復習と今回の概要 システム開発で必要となる標準規格の話、前回 は文字コードの概要について説明しました。ざっくりまとめるとこんな内容でした。 「符号化文字集合」で文字集合と符号位置を定義し、「符号化方式」でバイト表現に変換していること。 日本では、しばらく文字集合 JIS X 0208 を、ISO-2022-JP、EUC-JP、Shift_JIS の符号化方式で利用してきたこと。 近年は、世界中の文字が扱える Unicode が主流となっており、UTF-8、UTF-16 などの符号化方式があること。 常用漢字、人名用漢字に限っても、字体を正確に扱おうとすると、JIS X 0208 の範囲では不十分であり、JIS X 0213、Unicode、サロゲートペ

プログラマがシステム開発において共通で必要となる、技術と業務の狭間の共通知識を解説します。連載第1回は文字コードの概要編です。 0. はじめに 業務システムを開発する場合、プログラミング言語、フレームワーク、ミドルウェア、業務知識など以外に、共通で必要となる知識があります。文字コード、国際化、日付・時刻の扱い、住所コード、郵便番号、電話番号などの各種コード、…。 本連載では、プログラマがシステム開発で必要となる、技術と業務の狭間の共通知識を解説して行きたいと思います。 連載第1回は文字コードの概要編です。コンピュータシステムにおいて、文字情報は文字コードを用いて処理されます。文字コードとは、各文字に対応付けられた数値 (符号) のことです。近年、新規に開発される業務システムでは Unicode が使われることが多いと思いますが、既存システムとの連携など他の文字コードが使用されることもまだま

今更ですが今年の2月に spaCy 3.0 が公開されました。 3.0 で導入された新機能の中で目玉と言えるのは、やはり Hugging Face Transformers (以下、単にTransformers) のサポートや PyTorch, Tensorflow との連携になるでしょう。今回はその辺りを実際に学習を動かしながら紹介したいと思います。 1. はじめに 今回は今年の2月に公開された spaCy 3.0 の話です。 spaCy は第4回でも紹介しましたが、研究者向けというよりは自然言語処理アプリ開発者向けのオープンソース自然言語処理ライブラリになります。日本語を含めた様々な言語の学習済みモデルが存在しており、 spaCy をインストールして、学習済みモデルをダウンロードするだけで、分かち書き、品詞や依存関係の推定、単語や文の類似度の判定など様々な機能を使用することができます。

本稿ではマイクロサービスアーキテクチャでの利用が可能なワークフローエンジンのZeebeを紹介します。このZeebeを利用することによって、開発者はマイクロサービスにおけるサービス間の連携をグラフィカルに記述することができ、またアプリケーションの実行状態を監視することも可能になります。 はじめに 最近のシステム開発では、マイクロサービスアーキテクチャと呼ばれるアプリケーションを疎結合なサービスで構築するアーキテクチャを検討することが増えてきています。 マイクロサービスでは複数のサービスを組み合わせてアプリケーションが実現されるため、アプリケーションが複数のサービスを横断してどのように組み立てられているか、またそれぞれのサービスの状態をどのように監視していくかは重要なポイントとなっていくでしょう。 実際のマイクロサービスの現場でも、複数のチームをまたいで一連の取引を組み立てる場合には、全体でど

前回が分量的にやたらと重かったので、今回はその反省(反動?)を踏まえて軽い感じでいってみます。第7回で紹介した T5 ですが Hugging Face の Transformers でもサポートされてますので、その使用方法をご紹介したいと思います。 1. はじめに 今回は久しぶりに T5 の話です。T5 に関しては第7回、第8回で一度紹介しているので、未読の方は記事に目を通してから戻ってきて頂けると、より理解がしやすいと思います。 さて、 T5 ですが Google のオリジナルコード(以下 “t5"と記述)1は敷居が高いと感じる方もいらっしゃるのではないでしょうか。 Estimator API ベースのコードや gin による設定など慣れていないと、とっつきにくいのではないかと思います。 そこで今回は Hugging Face の Transformers 2を使って T5 を動かす方法

オブジェクトの広場はその名の通りオブジェクト指向についての情報発信から始まりました。本シリーズでは、オブジェクトの広場発行当初の懐かしいものから新しく書き起こしたものまで、オブジェクト指向に関するコラムを集めました。楽しみながら読んでいただけると幸いです。

今回は BERT における事前学習の改良手法である ELECTRA の検証です。ELECTRA はモデルサイズ、データ、計算量が同一条件であればオリジナルの BERT を凌ぐ性能とのことなので結果が楽しみなところです。事前学習をした後のファインチューニングは、いつも livedoor News Corpus の文書分類ばかりだったので、今回は固有表現抽出を試すことにしました。 1. はじめに 今回は BERT における事前学習の改良手法である ELECTRA 1 の検証です。 BERT に関しては 第3回 で取り上げていますが、トークン化が Sentencepiece である為、トークン単位での処理に難がありました2。今回は ELECTRA を試すにあたり、そのあたりの対応も入れ、 Megagon Labs さんから公開されている UD_Japanese-GSD v2.6-NE 3 を使っ