AI Hackathon with Google Cloud で入賞した話精度評価編

Author:

2024-10-31

データプラットフォームチームの @kobori です。 8 月から 9 月にかけて Google Cloud Japan により主催されていた AI Hackathon に参加していました。約 2 ヶ月に渡り開催されていた、生成 AI をテーマにした hackathon です。 CTO の @ttyfky 主導の下で開発を行い、私にとっては LLM を活用した初めての開発を経験しました。

つい先日その結果発表があったのですが、嬉しいことにベスト・オブ・リテール賞を獲得することができました️。

こちらが demo 動画になります。

今回の hackathon では、私は Langchain を用いた一部 chain の作成と、システムの精度評価を主に行いました。本ブログではどのような評価を行なったかについてを記事にしております。

今回作ったもの

今回我々が作ったものは LLM を活用してカタログ情報の収集を行う仕組みです。弊社では中古のスマートデバイスの売買を行っているのですが、在庫管理や売買の際に、モデル名や仕様などの商品情報が必要になります。現在は仕様情報の収集を人手で行っているのですが、これを LLM で効率化できるのではないか？というのが今回開発したプロダクトのアイディアとなります。

開発したのは、Google 検索と Gemini を活用し、検索結果から LLM がスマートデバイスの情報を抽出する仕組みです。詳細は @ttyfky の記事「 AI Hackathon with Google Cloud で入賞した話概要編」をご覧ください。

百舌鳥という鳥の、狩った獲物を保存しておく習性に準え、b-moz と命名しました。社内に蓄積しているカタログデータを用い精度検証を行ったのですが、9 割を超える精度でデータの収集を行うことができました。この記事では今回私が主に行った評価についてご紹介したいと思います。

評価

今回は b-moz に対して与えたスマートバイスのモデル名に対して、ストレージの展開とカラーバリエーションをどれだけ正確に取得できるかという観点で評価を行いました。例えば iPhone Xというモデル名を与えると、そのストレージ展開 [64GB, 256GB] とカラーバリエーション [スペースグレイ, シルバー] を b-moz が収集します。社内に蓄積されているデータを正とした際に、その結果がどれだけ正確に取得されているかを評価します。

LLM の評価手法を調べていると、LLM 自体を評価に用いる手法なども紹介されていたのですが、今回の出力は構造化されたシンプルなものだったため、通常のマルチラベル分類の評価手法を用いて評価を行いました。

マルチラベル分類とは

マルチラベル分類は、クラスタリングタスクの種類の 1 つで、1 つのサンプルに対して複数のラベル (クラス) を割り当てるようなタスクになります。比較をするとわかりやすいのですが、

task	description
二値分類	1 つのサンプルを 2 つのクラスのどちらかに分類する
多クラス分類	1 つのサンプルを複数のクラスのうちいずれかに分類する
マルチラベル分類	1 つのサンプルに対して複数のラベル (クラス) を割り当てるように分類する

というようなタスクになります。

モデル名を元にそのストレージ展開とカラーバリエーションを収集するという仕組みは、モデル名に対して複数のストレージやカラーを割り当てるマルチラベル分類のタスクと考えることができます。そのためマルチラベル分類のタスクとして精度評価を行いました。

評価指標

評価指標としては下記の 5 つの指標を計算しています。

EM 値 (Exaect Match)
Accuracy (正解率)
Recall (再現率)
Precision (適合率)
F 値

1. EM 値 (Exaect Match)

\frac{1}{N} \sum_{i=1}^{N} I[Y_i = T_i]

EM 値は、その名の通り完全一致したサンプルの割合を表す指標です。

$i$ 番目のサンプルの正解ラベルが $T_i = \{red, blue, yellow \}$ 、収集したラベルが $Y_i = \{red, blue, yellow \}$ のとき、 $I[Y_i = T_i] = 1$ となります。全サンプルについて平均をとった値が EM 値です。

2. Accuracy (正解率)

\frac{1}{N} \sum_{i=1}^{N} \frac{\lvert Y_i \cap T_i \rvert}{\lvert Y_i \cup T_i \rvert}

単純に正解したラベルの割合です。

$i$ 番目のサンプルの正解ラベルが $T_i = \{red, blue, yellow \}$ 、収集したラベルが $Y_i = \{red, blue, pink, green \}$ のとき、全ラベル $\{ red, blue, yellow, pink, green \}$ 中正解ラベルは $\{red, blue \}$ なので正解率は $2 / 5$ となります。サンプルごとの正解率の平均をとり全体の正解率を求めます。

3. Recall (再現率)

\frac{1}{N} \sum_{i=1}^{N} \frac{\lvert Y_i \cap T_i \rvert}{\lvert T_i \rvert}

正解ラベルのうち、実際に収集できたラベルの割合です。

$i$ 番目のサンプルの正解ラベルが $T_i = \{red, blue, yellow, green, orange \}$ の時に収集したラベルが $Y_i = \{red, blue, pink, green \}$ のとき、再現率は $3 / 5$ になります。冗長にラベル情報を収集し、正解ラベルを尽くすことができれば正解率は $1$ になります。例えば、正解ラベルが $T_i = \{red, blue \}$ の時に収集したラベルが $Y_i = \{red, blue, pink, green, white \}$ のときも再現率は $1$ になります。しかしこの時、次の適合率が小さくなります。

4. Precision (適合率)

\frac{1}{N} \sum_{i=1}^{N} \frac{\lvert Y_i \cap T_i \rvert}{\lvert Y_i \rvert}

収集したラベルのうち、正解ラベルに含まれていたラベルの割合です。

$i$ 番目のサンプルの正解ラベルが $T_i = \{red, blue, yellow, green, orange \}$ の時に収集したラベルが $Y_i = \{red, blue, pink, green \}$ のとき、適合率は $3 / 4$ になります。正解に含まれないラベルを収集するほど適合率は小さくなります。

5. F 値

\frac{ 2 \times precision \times recall}{precision + recall}

トレードオフの関係にある再現率と適合率の調和平均です。調和平均は、逆数の算術平均の逆数を取ることで求められます。

F 値について

一見何をしているかわかりづらいのですが、よく眺めると、分母の平均をとって割合を求め直す操作をしています。二値分類を例に F 値を考えてみたいのですが、 Positive と Negative に分類する二値分類では、再現率は

recall = \frac{TP}{TP+FN}

適合率は

precision = \frac{TP}{TP+FP}

と表現されます。ここで、

$TP$ : 正解が Positive のものを Positive と予測できた数
$FN$ : 正解が Positive のものを Negative と予測してしまった数
$FP$ : 正解が Negative のものを Positive と予測してしまった数

を意味します。この時 F 値は

f\textrm{-}value = \frac{ 2 \times precision \times recall}{precision + recall} = \frac{ TP }{ \frac{ (TP + FN) + (TP + FP) }{2} }

変形することができ、分子が共通する 2 種類の指標について、分母を平均化することで平均を求める操作をしていることがわかります。

評価結果

実際にモデルのカラーバリエーションを収集した際の評価結果が下記となります。

sample	EM	Accuracy	Recall	Precision	F1
1032	0.73	0.87	0.89	0.94	0.91

今回注目したいのは、適合率 (Precision) になります。カタログデータの収集というタスクの性質上、誤ったラベルを収集してしまうとデータが汚染されてしまうからです。データが不足している分には、不足に気づいた際に補填を行えば良いですが、誤ったデータが含まれる場合、その精査のためのコストがかかってしまいます。

全体的に高いスコアが出ている中で、再現率 0.89 に対し適合率 0.94 と適合率が高く出ている点は、今回の自動収集の仕組みの実用可能性の高さを示していると考えられます。精度を 100% に近づけたい気持ちもありますが、人手での収集も 100% の精度にはならないことを考えると、今回の仕組みで十分業務の効率化を進められるのではないかと思いました。

実際に現在実用化を進めており、データの充足とそれによる業務の効率性を高めようとしているところです。

最後に

今回初めて LLM を活用した開発を行いました。 LangChain というフレームワークを使用したのですが、複数の処理をチェーンのように繋げて処理を組み上げます。 pandas や polars でデータフレームを扱うように簡単にチェーンを組むことができます。

Runnable という仕組みを使ってチェーンを組み上げるのですが、様々な Runnable が用意されており比較的自由に処理を組むことができます。 Tutorial が用意されているので是非試してみてください。

今回は CTO との参加ということで、緊張感を感じる部分や力不足を感じることもありましたが学びも多くありました。入社 1 年に満たない私ですが、貴重な機会をいただくことができたと感じています。欲張りに経験を積んでいきたいという方は、弊社への入社を検討してみてもよいのではないでしょうか。

また、弊社では LLM の活用を積極的に進めており、@shigwata や @shuhei の記事でも紹介している通り、論文の輪読会なども行なっております。輪読会の中で得た知識を業務に還元していくというところが個人的な課題です。

弊社ではエンジニア採用を行なっておりますので、LLM に興味のある方はもちろん、そうでない方も、興味を持っていただけた方は Entrancebook をご覧ください。

AI Hackathon with Google Cloud で入賞した話 精度評価編