ここまでAI/LLMド真ん中の機能は初だし、
— 坂本 祥二|HQ CEO (@shoji_hq) August 22, 2024
エンジニアから自然発生的に企画された大きめの機能としても初。
ここから、
生成AI活用力
エンジニアリングの自律躍動力
をガンガン上げていこうと思う!!!
生成 AI 時代の AI-OCR カメラ機能をリリースしました
AI-OCR 機能をリリースしました
先日、次世代福利厚生プラットフォーム「カフェテリアHQ」に向けて、 AI-OCR 機能をリリースしました。
HQ 代表の投稿にもありますように、この AI-OCR 機能は来るべき生成 AI 時代を見据えた生成 AI ファーストな方法で実装されています。この記事では簡単ながらその技術的な説明をしたいと思います。
生成 AI 時代とは
随分と大上段に構えたタイトルをつけてしまったので、まず私の定義する「生成 AI 時代」について説明したいと思います。単刀直入に述べると、それはソフトウェア製品やサービスにおいて生成 AI を使った機能と従来型の機械学習を使った機能の棲み分けがなされた世界だと私は考えています。
これは既に訪れている「スマホ時代」を例にとると分かり易いです。ご存知の通りスマホは登場以来あらゆる機能を飲み込んできました。しかしスマホがこれだけ普及しても専用デバイスが市場からなくなったわけではなく、デジカメもウォークマンも電子辞書も、スマホと棲み分けた形で存在しています。それがスマホ時代です。
同じことが生成 AI でも進んでいくと考えており、多くの一般的な機械学習用途は生成 AI に取り込まれていきつつも、例えば医療用の画像診断など専門分野に特化した機械学習用途は今後も求められ続けるのではないかと思います。
今後のプロダクト開発において、開発しようとしている製品や機能がどちらに属するべきなのか、その判断がとても重要になると思います。
では、解説に入りたいと思います。
生成 AI モデルの選択
生成 AI のモデルには Google の Gemini 1.5 Flash を選択しました。これにはいくつかの理由があります。
まず HQ が現在プロダクトの作成に多く Google Cloud 上のサービスを利用しているということもあり1、その親和性の高さから Google Vertext AI 上で利用できる Gemini を選択しました。特に今回は画像認識ということもあり、我々が使用している Google Cloud Storage との相性の良さは重要でした。
次に Gemini 1.5 Pro ではなく 1.5 Flash を使った理由ですが、こちらは機能に求められる即応性と精度のバランスをテストした結果の選択です。簡単に言ってしまうと、Flash で得られる速度のメリットが Pro で得られる精度のメリットを上回った、ということになります。
生成 AI を"手懐ける"ための工夫
言うまでもなく生成 AI は大変に便利なものですが、プロダクトの機能の一部としてそれを使うとなると、猛獣を手懐けるかの如く様々な工夫が必要になります。ここではその工夫の一部を紹介したいと思います。
Tempareture の設定
証票の読み取りといった確実性が求められる機能だったので、今回はかなり低めの Tempareture を用いてその動作を決定論的にしています2。逆にユーザーの行動に合わせて少し創造的な機能を設計したい場合は、Tempareture は高めに設定することになると思います。
関数呼び出し(Function Calling)の使用
生成 AI からの返答を構造化した形で利用する為に、関数呼び出し(Function Calling)を利用しています。多くの場合で生成 AI は指定のフォーマット、例えば JSON 形式の文字列で返答を返してくれますが、プロダクトで使用する以上きちんと構造化された形でデータを利用することは必須の要件です。AI-OCR では関数呼び出しを使ってこの要件をクリアしています。
文字列型の使用
証票の読み取りということもあり多くの数値を扱っていますが、生成 AI にはなるべく値を文字列で扱ってもらい、必要な処理を一部自分たちで行なっています。これは、数値の場合だと整数なのか、それとも浮動小数点数なのかという判断を生成 AI 側に委ねることになってしまい、その部分から生じる不確実性を取り除くために行いました。
生成 AI に任せる部分と自分で行う部分の見極め
上述の文字列型の話にも通じるものがありますが、生成 AI に任せる部分とそうでない部分の見極めはとても重要だと感じています。例えば HQ の証票読み取り機能では和暦から西暦に変換する処理が必要でしたが、それを生成 AI に任せるのか、それとも自分たちで処理をするのか、モデルの癖も考慮に入れながら判断していく必要がありました。
ゼロショット vs. 少数ショット(Few-Shot)
こちらも精度や即応性のバランス、(少数ショットとはいえ)過学習のリスクなどを考えながら、ゼロショットで行くか、または少数ショットを与えるのか、模索しながら進みました。3こちらは機能の要件次第というところもあり、HQ で開発した機能の中にも少数ショットを使っているものもあれば、敢えてゼロショットのものもあります。
今回の OCR 機能の例でいうと、様々に試した結果、敢えてゼロショットで機能をリリースしています。繰り返しになりますが速度と精度のバランスから判断した結果です。
今後の課題
個人的に今後の一番の課題だと感じているのが、生成 AI を使った機能の評価方法の確立です。従来の機械学習を使った機能と違い、モデルそのものをテストするのではなく、生成 AI を利用側するのプロンプトをテストする必要があります。そのため、機械学習の発展と共に積み上げられてきた評価方法に頼ることができません。
ここはいわゆる A/B テストなどの手法を駆使しながら、生成 AI 時代の最適な評価方法を探っていく必要があるエリアだと感じています。
まとめ
生成 AI を大きく活用した AI-OCR 機能の技術的な解説をしてみました。色々と書きましたが、この業界に長くいる身として簡潔な感想を言うと「こんなに簡単に、こんなに精度の高い画像認識ができるようになってしまったのか」という驚きに満ちた実装体験でした。冒頭で述べた生成 AI 時代の到来はもはや不可避だと感じざるを得ませんでした。
本記事が、皆様が生成 AI をプロダクトで活用する上での一助になれば幸いです。
Footnotes
-
詳しくはTech Stacksを参照 ↩
-
Tempareture についての説明は Prompt Engineering Guide のLLM の設定 などで確認することができます。 ↩
-
詳しくは Prompt Engineering Guide のFew-Shot プロンプティングや Generative AI on Vertex AI の少数ショットの例を含めるをご覧ください。 ↩