HEROZ Tech Blog

日本将棋連盟公認「将棋ウォーズ」や、AIを活用したシステム企画・開発を行う、AI企業HEROZの公式テックブログです。

Geminiをサービスから呼ぶ時の認証方法について

はじめに

先日リリースしたHEROZ ASKではGeminiやClaudeも動くプロトタイプを準備しています。 まずはGeminiを組み込もうと思ったのですが、HEROZ ASK プロトタイプというサービスから呼び出すにあたっては認証方法に以下のような要件があり、動作させるのに苦労しました。

  1. Googleアカウントに紐付くGoogle AIのAPIキーではなく、Vertex AIのサービスアカウント(SA)を使いたい
  2. 動作させるアカウントの権限はなるべく小さくしたい
  3. 認証情報(credentials)はローカルファイルではなく文字列渡しとしたい
  4. langchainから呼び出したい

1.についてはサービスとして動作させる上では特定の個人と結びつくGoogleアカウントではなく、サービスアカウント(SA)のような専用のアカウントの方が権限管理や課金管理の関係で望ましいと考えています。
2.については管理者のようなフル権限にしてしまえば問題なく動作するのですが、セキュリティを考えるとなるべく小さくすることに越したことはありません。
3.については環境と設定を分離するためにも認証情報(credentials)のローカルファイル埋め込みは避けたいです。
4.についてはHEROZ ASKがlangchainで動作しているので、それに準じています。

以上を満たす方法について、これから説明してます。

サービスアカウント(SA)の鍵の作成

サービスアカウント(SA)の鍵は以下の手順で作成します。

  1. [IAMと管理]から[サービスアカウント]を選択し、[サービスアカウントを作成]をクリックします。
    サービスアカウント作成1
  2. サービスアカウント名とサービスアカウントIDを入力してから[作成して続行]をクリックし、権限を付与せずに[完了]をクリックします。
    サービスアカウント作成2
  3. サービスアカウント一覧から2.で作成したアカウントをクリックする。
    サービスアカウント作成3
  4. [キー]タブを選択する。
    サービスアカウントの作成4
  5. [鍵を追加]をクリックし、[新しい鍵を作成]をクリックする。
    サービスアカウント作成5
  6. [作成]をクリックすると、鍵のjsonファイルがダウンロードされる。
    サービスアカウント作成6

権限(role)の付与

gcloud CLIがインストールされた環境において、人に紐付くGoogleアカウントでログインし、下記のコマンドを実行する。

gcloud projects add-iam-policy-binding {プロジェクト名} \
    --member=serviceAccount:{先ほど作ったサービスアカウント}@{プロジェクト名}.iam.gserviceaccount.com \
    --role="roles/aiplatform.user"

反映には少し時間がかかれます。
GUIにはroles/aiplatform.user権限が見当たらないため、CLIで付与する必要がある。
また、権限エラーとなった場合にはログインしているGoogleアカウントにresourcemanager.projects.setIamPolicy権限を管理者に付与してもらいましょう。

呼び出し方法

以下のコードにてGeminiを呼び出すことができます。

!pip install langchain-google-vertexai google-cloud-aiplatform

from langchain_google_vertexai import ChatVertexAI
from langchain_core.messages import HumanMessage
from google.oauth2 import service_account
import vertexai
import json

# cred_strにjsonファイルの中身を代入する
cred_str = "{\"type\": \"service_account\", ... }"
cred_json = json.loads(cred_str)
credentials = service_account.Credentials.from_service_account_info(cred_json)
vertexai.init(project=credentials.project_id, credentials=credentials)

# langchainからGeminiを呼びます
chat = ChatVertexAI(model_name="gemini-1.0-pro")
answer = chat([HumanMessage(content="日本一高い山は何ですか?")])

answer.content
# '富士山'

おわりに

GeminiをHEROZ ASK プロトタイプというサービスから呼び出そうと思った時に認証関係で以下の2点でハマりました。

  1. 認証情報(credentials)を文字列で渡す時にservice_account.Credentials.from_service_account_info()で読み込み、vertexai.init()を実行する手順が分からなかった。
  2. サービスアカウント(SA)に付与する権限を最小にしようとすると、GUIでの選択にないroles/aiplatform.userをCLIで設定する必要があった。

1.は最初はChatVertexAI(credentials=credentials)とこちらにcredentialsを渡したり、vertexai.init()を実行していなかったりして動作しませんでした。 他にもscopesを与えてみたり、locationを追加してみたりといろいろ迷走しましたが、上記の呼び出し方法が最もシンプルに動作するコードとなります。
2.も最初はGUIで付与する「Vertex AI サービスエージェント」が該当かと思って付与していましたが、これは間違いでした。

認証関係も動作するようになりましたので、次回はいよいよGeminiをHEROZ ASK プロトタイプに組み込んでいきたいと思います。

GeminやClaudeも動作するHEROZ ASKのプロトタイプはAI Expo 2024 春で展示予定です。 heroz.co.jp 弊社ブースへのご来場もお待ちしております。

RAGとMulti Query Retriever: 社内ナレッジ検索結果の精度向上の鍵

はじめに

こんにちは、HEROZ ASK の開発チームです。

herozask.ai

今回のポストでは、このプロダクトの開発で活用している検索精度の向上技術についてお話します。

知識抽出におけるRAGの役割

そもそも現在公開されているLLMをそのまま用いて社内ナレッジについて質問すると、事実に基づかない文章を生成してしまう、いわゆる『ハルシネーション』が起きてしまいます。
このハルシネーションに対抗する手段のひとつがRAGです。RAG(Retrieval Augmented Generation)は、検索ベースのモデル(Retrieval)と生成ベースのモデル(Generation)を組み合わせたアプローチです。RAGは特定のクエリに関連する情報を集め、その情報を元に詳細な回答を生成する仕組みのため、ハルシネーションの軽減に貢献します。
HEROZ ASKでは、ベクトル型データベースを用いて関連する情報をドキュメントから取得し、それを元に回答を生成しています。RAGを通じて、生成される回答がドメインの内容に沿った一貫性を確保できると期待されます。

RAGの限界

シンプルなRAGで検索対象にできるドキュメントの範囲は、ユーザが入力したクエリの内容を超えられません。例えば「旅行の予約方法」とだけ入力されたとき、LLMは航空券やホテルの予約方法について一般的な回答が行えます。しかしユーザが実際にはツアーパックの予約方法について知りたがったり、割引チケットの購入方法に知りたいときにLLMはそれらの情報を提供することができません。

LLMによるクエリ拡張

クエリ拡張とは、検索クエリに関連するキーワードやフレーズを追加してより適切な検索結果を得るための手法です。
一般的なクエリ拡張の手法としてはシソーラスを用いたものなどがあります。シソーラスによるクエリ拡張は同義語や関連語を検索クエリに追加し、より幅広い検索結果を引き出します。しかしながら、シソーラスによるクエリ拡張はドメイン知識を必要とするため、すべてのクエリに対して効果的とは限らない問題があります。
これに対してLLMを用いるクエリ拡張では、広範な知識を開発者の実装なしに利用できます。与えられたクエリから複数パターンの質問を生成することで、より適切なドキュメントを検索対象に取りやすくなります。LLMによるクエリ拡張の最大の利点は柔軟性と精度の両立です。多くの発表されているLLMは様々な文脈やトピックに対応する能力を持ち、ドメインに関する知識を必要としません。
しかし、LLMによるクエリ拡張には生成するクエリが必ずしもユーザの意図を正確に反映するとは限らないという問題があります。この問題を克服するため、たとえばLLMからの返答に対してユーザがgood/bad評価でフィードバックするRLHF(人間のフィードバックによる強化学習)を採り入れるなどの施策が必要になります。

Multi Query Retrieverによるクエリ拡張

LLMによるクエリ拡張手法のひとつに、Multi Query Retrieverがあります。
Multi Query Retrieverはユーザが入力したクエリに対してLLMを用いてクエリを複数パターンに拡張する手法です。

(参考)MultiQueryRetriever | 🦜️🔗 Langchain

今回LLMへ渡すテンプレートは上記リンク先にあるものの日本語訳です。

あなたは AI 言語モデルのアシスタントです。 あなたのタスクは、指定されたユーザーの質問から5つの異なるバージョンを生成し、 ベクトルデータベースから関連するドキュメントを取得することです。 ユーザーの質問に対して複数の視点を生成することで、 ユーザーは、距離ベースの類似性検索の制限の一部を克服します。 これらの代替質問を改行で区切って入力してください。 元の質問: {question}

Multi Query Retrieverを利用したクエリ拡張時の性能とコストの評価

シンプルなRAGとMulti Query Retrieverをクエリ拡張に用いた場合の性能とコストを比較していきます。
実験では当社の社内wikiに該当するドキュメントが存在する、または無関係な25の設問に対してRAGを用いて知識抽出を行いました。正しい文章を生成している、または該当するドキュメントが存在しないときに回答しないケースを正答としています。
使用モデルはGPT-4で、LangChainのDebugモード下で実行しています。
下表はMulti Query RetrieverでのRAGとシンプルなRAGに対する比を掲載しています。

シンプルなRAG Multi Query Retriever 比率
正答数 19/25 24/25 126.32%
平均処理速度(s) 25.4 26.4 103.94%
平均消費トークン数 2821.6 2832.1 100.37%
  • LLM生成によるクエリ拡張を施したMulti Query Retrieverでは、シンプルなRAGに対して26.32%精度が向上しました。
  • 処理速度は大きく変わらない。
    • これは処理速度がLLM APIサーバ側の処理に律速されるためだと考えられます。
  • Multi Query Retrieverでクエリ拡張を行っても、全体の消費トークン数は大きく跳ね上がることはないと言えます。

まとめ

以上から、多少の処理速度と消費トークン数の増加と引き換えに、LLM生成によるクエリ拡張によって精度を向上させることができたと言えます。
本実験の時点ではチャンク分割には段落などを気にせず文字列を分割する RecursiveCharacterTextSplitter を利用していました。その後ドキュメントのチャンク分割にMarkdownのヘッダー構造をメタデータに持てる MarkdownHeaderTextSplitter を用いることでドキュメント内の意味的階層構造をLLMが解釈できるようになり、検索精度の向上に繋がることが分かりました。

別の実験でEmbeddingモデルを切り替えることでも精度が向上する場合があると分かったため、今後はドキュメントの読み込み方法を工夫しつつ、プロンプトを改善して更なる精度向上を目指していきます。

HEROZ ASK を支えるインフラ技術

はじめに

こんにちは、HEROZ ASK の開発チームです。

herozask.ai

今回のポストでは、このプロダクトの開発で活用しているインフラ技術を紹介したいと思います。

『Azure OpenAI Service リファレンスアーキテクチャ』の賛同パートナーについて

日本マイクロソフト株式会社が公開する『Azure OpenAI Service リファレンスアーキテクチャ』に対し、賛同するパートナーを認定する新たなパートナープログラムです。 私たち HEROZ は、賛同パートナーとして参画しています。

heroz.co.jp www.microsoft.com

日本マイクロソフト株式会社や賛同パートナー企業と連携し、お客様が大規模な Generative AI を活用することをご支援いたします。

『Azure AI Hub』について

Azure AI Hub は Azure の AI サービスに関して利用している方、興味のある方向けの技術情報交換の場を提供することを目的として設立されました。

azure-ai-hub.connpass.com

賛同パートナーとしての参画がきっかけとなり、記念すべき第一回目の『Azure OpenAI Service 生成AI実践知』でイベント登壇させていただきました。

azure-ai-hub.connpass.com

オフラインのみのイベントで、参加者（60人）というクローズドなイベントだったにも関わらず、資料公開後、10.6K Views（2024/2/26現在）となり、ドクセルの人気のスライドにも掲載されました。Azure OpenAI Service に対する関心の高さが窺える印象的なイベントでした。

www.docswell.com

コミュニティとも連携し、お客様が Azure を活用することをご支援いたします。

『HEROZ ASK』アーリーアクセス版について

先日、私たちが新しく開発しているSaaS型プロダクト、HEROZ ASK の新バージョンがリリースされました。

heroz.co.jp

『Azure OpenAI Service リファレンスアーキテクチャ』を参考に、

  • 『Azure Application Gateway』による負荷分散
  • 『Azure API Management』による API 管理
  • 『Azure Key Vault』による秘密情報の管理
  • 『Azure OpenAI Service』による OpenAI モデルの管理
  • 『Azure Database for PostgreSQL - フレキシブル サーバー』によるベクトル検索
  • 『Azure Virtual Machines』による仮想マシンの管理

などのアーキテクチャを採用しています。また、リファレンスアーキテクチャを拡張し、

  • 『Microsoft Defender for Cloud』によるセキュリティ対策
  • 『Azure Communication Services Email』によるメール送信
  • 『Azure Monitor』、『Application Insights』による監視
  • 『Azure Logic Apps』による Slack レポート
  • 『Azure Backup』によるバックアップ運用
  • 『OpenAI』への API 切り替えによる新機能検証

など、エンタープライズ企業への導入や ChatGPT の新機能検証に、いち早く対応するため、改善の工夫をしています。

また、セキュリティ評価プラットフォーム「Assured」のような第三者サービスによるセキュリティチェックなどの調査も受け、正式サービス開始に向けた改善を進めています。

assured.jp

正式サービス開始に向けて

『クローズドβ版』、『アーリーアクセス版』と段階的にサービス公開し、お客様からのフィードバックを頂戴しながら、機能改善やUIUXの抜本見直しなどを計画しています。また、『Azure OpenAI Service』以外のクラウドサービスへの対応も検討しています。

  • 『Amazon Bedrock』の『Anthropic Claude』への対応
  • 『Google Cloud Vertex AI』の『Gemini』への対応

など。

また、HEROZ は、NVIDIA V100/A100/H100 搭載サーバーを導入し、大規模な自社計算資源を保有しています。

heroz.co.jp

自社計算資源を活用した、

  • 業界特化したデータセットによる『ファインチューニングモデル』への対応

についても、検証を進めています。

他にも様々なクラウド／オープンソース／論文技術に対する検証や機能改善も進めていますので、ご期待ください。

最後に

今後も HEROZ は、クラウド技術と生成 AI を活用したサービス提供について、今後も技術的にさらに踏み込んだ内容を発信して行きたいと思います。本ブログをご愛顧いただければ幸いです。最後までお付き合いいただきありがとうございました。

HEROZ ASK: なぜHEROZが今、新しいSaaS型プロダクト開発に挑戦しているのか

はじめに

こんにちは、HEROZ ASKの開発チームです。先日、私たちが新しく開発しているSaaS型プロダクト、HEROZ ASKの新バージョンがリリースされました。 heroz.co.jp

今回のポストでは、このプロダクトの開発に何故我々が注力しているのか、ビジネスとしての意義を説明したいと思います。

※技術的なこだわりポイントはまた別のポストで随時発信したいと思います

HEROZ ASKについて

いつでも何でも悩んだときに聞くこと（ASK）ができる、あらゆる質問に答えるAI駆動のSaaSプロダクトです。Always Seek Knowledgeという意味が込められており、蓄積された知見をいつでも探すことができます。簡単に言えば、ビジネスの現場で使えるChatGPTを目指しており、これまで十分に活用されてこなかった暗黙知を有効利用することで、企業および産業のAIトランスフォーメーションを促進します。

そもそもHEROZはどのようなBtoB事業をやってきたのか

当社はこれまで、所謂ソリューション型のビジネスを展開して来ました。顧客の表面的な課題から、本質的に機械学習で解くべきイシューを発見し、そのモデルを高度なAIに関する技術力で実現することで、殆どが失敗に終わると言われるPoCの成功確率を極力上げられるようなプロジェクトを複数展開して参りました。一例として以下のような事例を公表させていただいております。

heroz.co.jp

heroz.co.jp

付加価値の高いプロジェクトを一件一件テイラーメイドで提供してきたため、多くのお客さまから感謝の言葉を頂いていることは有難い限りで、当社も本質的な課題解決の一助を担えたことをとても嬉しく思っていました。同時に、PoCで終わらせない高度なAI導入のノウハウを社内に蓄積し、AI業界の荒波を乗り越えてこれたことは当社にとっても代えがたい経験になっていたことは間違いありません。

しかしながら、当然このビジネスモデルも一長一短はあります。スケーラビリティに欠け、アセットが蓄積しにくいという課題を避けて通ることは極めて困難です。今後よりビジネスをスケールさせていくためには、「高度なAI導入ノウハウ」以上の、tangibleなアセットを蓄積していくことが不可避でした。

生成AIの登場と、Solutionとの両立

生成AIブームが来る以前から、当社は長らくこうした課題と向き合ってきましたが、ちょうど一年ほど前に、生成AIが登場し、市場を折檻し始めました。生成AIブームが過熱する昨今、従来のように顧客の課題をヒアリングしに行くと、「ChatGPTを使って〇〇がしたい」というご相談を多数頂戴することがありました。これは我々が5~6年前に深層学習ブームの時に経験した「ディープラーニングを使って〇〇がしたい」とそっくりです。手段と目的が混在し、本来ビジネス上の目的を達成するための手段として位置づけられる技術自体が目的になってしまっているケースが後を絶ちませんでした。

しかし、生成AIはあまりに汎用性の高く新しい技術であるがゆえに、試してみなければ分からない。ChatGPTはまさにそのような技術でした。そこで、様々なLLMに関連する技術をノーコードで簡単に試しながら、生成AIの業務適用を完食できるようなツールのニーズが強いのでは無いかと思い、このプロダクトの開発に一念発起し開発を続けて来た結果、今回のリリースに至りました。

HEROZ ASKが目指す開発の方向性

HEROZ ASKは、簡単に言えばビジネスの現場で使えるChatGPTですが、言い換えればノーコードで生成AIの可能性を試すことができるあらゆるDX推進者のための支援ツールです。ビジネスとしての方向性は他にも様々な仮説を持っていますが、ここではtech blogなので技術的な思想や開発の方向性について説明します。当然ながら様々なモダンな技術を使ってUI/UXも徹底的に拘って行く（今後も更新していく）方針です。一例を挙げると

  • フロントエンドにはReact、バックエンドにはDjangoのフレームワークを採用し、効率的でパフォーマンスが高く、セキュリティに優れたSaaSプロダクトを実現しています
  • Azure OpenAI Serviceだけでなく、Microsoft Defender for Cloudなどの様々なサービスを採用し、セキュリティ面の様々な改善を行いました
  • LangChainのフレームワークを活用し、LLM関連の驚異的な技術進展にいち早く追随しています

特に、LangChainに関しては果たしてProductionに使うべきかどうか、様々な議論がなされています。メリットとしてはRAGやAgentに関する実装が豊富で、LLMの様々な機能を超手軽に活用することができます。一方、互換性の無い更新が為されることもしばしあり、本記事執筆時点でVersionが0.1.5と、いつになったら正式なVersion1.0になるのか、もしその時が来たらこれまでの開発は全て負債化してしまうのか、全く読めないというデメリットもあります。

HEROZでは、現時点ではLangChainはProductionに乗せるべき、という判断をしています。これは主に以下の理由からです

  • LangChainの実装が本家のLLM開発に影響を与えているような事象も散見され、最新状況のキャッチアップに一役買っている
  • LLMに関する技術進展が非常に高速かつ広範にわたる昨今、関連技術を簡単に使えるような実装が迅速に実現されるため、ASK上でいち早くLLMの最新技術を試してみることが可能になる
  • 特に、今後Multi-modalモデルが前提になって来ることが想定される中、いち早くそうした抜本的なLLMのアップデートに対応することができる

当然ながら世論も時々刻々変遷していると認識しています。当社はポジティブにこうした新しい技術を採用することで、ユーザに「驚き」を与えるような体験を提供することを目指します。

最後に

今後もHEROZは、Solution型の事業とプロダクト型の事業の両面と向き合いながら、新しいビジネスを実現して行く、という経営戦略的にも難しいテーマに挑戦していきます。生成AIという今後世の中に不可逆的に導入が進むであろう技術を扱いながら、こうしたテーマに取り組むことが出来るのは、まさに今しか出来ない貴重な経験になるはずです。今後も技術的にさらに踏み込んだ内容を発信して行きたいと思いますので本ブログをご愛顧いただければ幸いです。最後までお付き合いいただきありがとうございました。

日本語LLMの評価についてプロンプトバージョンによる得意不得意を調べてみた

はじめに

LLMの日本語に関する評価にはJGLUEデータセットを使用するlm-evaluation-harness というプログラムがあります。(提供してくださった方々、ありがとうございます)

弊社でもこのlm-evaluation-harnessを使用してファインチューニング用のLLMの評価や事後の劣化具合評価に使用しているのですが、lm-evaluation-harnessにはプロンプトのバージョンが0.2から0.6までの種類があります。プロンプトバージョンはtasksの「(タスク名)-(タスクバージョン)-(プロンプトバージョン)」(例: jsquad-1.1-0.2)で指定します。

LLMの評価にあたって、このプロンプトバージョンをその時の最新である0.5に固定して使用していたのですが、どうもLLMによっては著しく低い値が出るものもありました。
ひょっとしたら、LLMによってプロンプトによる得意不得意があるのではないかと思い、総当たりで調べることにしました。

評価対象

評価は以下のhuggingfaceで公開されている(OSSである)代表的な日本語LLMを対象としました。いずれも最近公開されたものです。

評価方法

W&BのLaunchに連続投入するために改造した以外はほとんどの素のlm-evaluation-harnessを用いて以下の4つの日本語タスクを評価し、それらの平均を取りました。

  • jsquad-1.1
  • jcommonsenseqa-1.1
  • jnli-1.1
  • marc_ja-1.1

プロンプトの中身

各プロンプトは以下のように定義されています。サンプルは選択肢あり問題のJCommonsenseQAの場合の例で、質問文は{質問}、選択肢は{選択肢0〜4}、正解は選択肢0とします。

0.2: FintanPrompt

prompt template is taken from ChatGPT vs BERT: どちらが日本語をより理解できるのか?

質問と回答の選択肢を入力として受け取り、選択肢から回答を選択してください。なお、回答は選択肢の番号(例:0)でするものとします。

質問:{質問}
選択肢:0.{選択肢0},1.{選択肢1}, ...,4.{選択肢4}
回答:0

0.3: AlpacaPrompt

This prompt format was inspired by the below data in fujiki/japanese_alpaca_data.

以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。

### 指示:
与えられた選択肢の中から、最適な答えを選んでください。出力は以下から選択してください：
- {選択肢0}
- {選択肢1}
  :
- {選択肢4}

### 入力:
{質問}

### 応答:
{選択肢0}

0.4: RinnaInstructionSFT

Reference: - HF Hub: https://huggingface.co/rinna/japanese-gpt-neox-3.6b-instruction-sft

見やすくするために<NL>の後に改行を入れていますが、正式には改行なしの1行です。

ユーザー: 与えられた選択肢の中から、最適な答えを選んでください。<NL>
システム: 分かりました。<NL>
ユーザー: 質問：{質問}<NL>
選択肢：<NL>
- {選択肢0}<NL>
- {選択肢1}<NL>
  :
- {選択肢4}<NL>
システム: {選択肢0}

0.5: RinnaBilingualInstructionSFT

Reference: - HF Hub: https://huggingface.co/rinna/bilingual-gpt-neox-4b-instruction-sft

ユーザー: 与えられた選択肢の中から、最適な答えを選んでください。
システム: 分かりました。
ユーザー: 質問：{質問}
選択肢：
- {選択肢0}
- {選択肢1}
  :
- {選択肢4}
システム: {選択肢0}

0.6: Llama2

This prompt version follows the Llama2-chat's prompt format:

<s>[INST] <<SYS>>
あなたは役立つアシスタントです。
<</SYS>>

与えられた選択肢の中から、最適な答えを選んでください。出力は以下から選択してください：
- {選択肢0}
- {選択肢1}
  :
- {選択肢4}

質問：{質問} [/INST] {選択肢0}

評価結果

結果は以下のようになりました。絶対値ですと各LLMの性能がモロに出てしまいますので、各LLM内での相対比率を出すようにしました。

プロンプトバージョンの比較表

  • 結果を見ると、プロンプトバージョン0.3が一番人気であることが分かりました。
    • 逆に私が評価していたプロンプトバージョン0.5は最も不人気であるため、値が著しく悪いのも納得がいきます。
  • LLMによってはプロンプトバージョンで極端に差がついたりするものがあったり(濃淡がくっきりしている)、あまり差がつかなかったりするものがあったりして興味深かったです。
  • プロンプトバージョンの0.4〜0.6はRinnaやLlama2向けと書かれているが、対象が全くヒットしていなかったのが面白かったです。

おわりに

総当たりで調査すると、各LLMの特徴が浮かび上がってきて面白かったです。 そして、LLMを調査する時のプロンプトは無難にFintanPrompt(0.2)かAlpacaPrompt(0.3)を使った方が良さそうです。

また、今回は絶対値を出しませんでしたが、llm-jp-13bが良い性能を示していましたので、しばらくのベースモデルはllm-jp-13bにしようかと考えています。

Geminiの性能を宅建試験でGPT-4やClaude2と比較してみた

はじめに

Googleが12月7日に新しい生成AIであるGeminiを発表しました。 発表会の記事によると、「グーグルの新たな生成AI基盤「Gemini」登場　ほぼ全指標でGPT-4しのぐ」とのことですので、12月13日に公開されたGemini APIを使って、宅建試験を解かせてみました。

検証内容

使用した問題は令和4年度の宅地建物取引士資格試験(回答はこちら)を使用しました。宅建試験は四択の50問あり、令和4年度については一問正解なしがあったので、母数は49問となります。 当社では建設業界を主要なターゲットとしているため、宅建試験を指標として採用しました。

評価方法

評価は以下のような入力を与え、数字の回答を正解と比較しました。

質問と回答の選択肢を入力として受け取り、選択肢から回答を選択してください。なお、回答は選択肢の番号（例：0）でするものとします。 回答となる数値をint型で返し、他には何も含めないことを厳守してください。

### 入力：
質問：相続に関する次の記述のうち、民法の規定によれば、誤っているものはどれか。
選択肢：0.被相続人の生前においては、相続人は、家庭裁判所の許可を受けることにより、遺留分を放棄することができる。,1.家庭裁判所への相続放棄の申述は、被相続人の生前には行うことができない。,2.相続人が遺留分の放棄について家庭裁判所の許可を受けると、当該相続人は、被相続人の遺産を相続する権利を失う。,3.相続人が被相続人の兄弟姉妹である場合、当該相続人には遺留分がない。

比較対象としてGPT-4のgpt-4-0613と、Anthropicのclaude-v2でも同様の評価を実施しました。いずれもtemperatureは0としています。

評価結果

結果は以下となっています。

モデル 正答数 正答数
GPT-4(gpt-4-0613) 28/49 57.1%
Claude2(claude-v2) 25/49 51.0%
Gemini(gemini-pro-vision) 23/49 46.9%

詳細な正誤表

  • 各モデルとも当てずっぽう(四択問題なので平均すると25%になる)ではなく、それなりにしっかり回答しているが、いずれも合格水準(70%前後)には達していない。
  • モデル間ではGPT-4やClaude2の方がGeminiより良い性能を出していますが、今回試したGeminiのモデルはProしかなく、GPT-4を凌駕したのはUltraとのことですので、早くUltraモデルを使用できるのが待たれます。
  • 全モデルで正解は11問(22.4%)、逆に不正解も11問(22.4% )で両方合わせると半分近くになります。それ以外は特に何か傾向があるようには見えませんでした。

おわりに

現時点の各モデルは宅建試験で使用する法律のような専門知識をある程度は覚えているようですが、合格に至るほどは覚えていないようです。
実務で使用するには合格水準を超えるレベルを求められるため、やはり特定ドメインの知識に特化したLLMの実現に向けては取り組む必要があり、当社では継続検討していこうと考えています。

HEROZ Tech Blogをはじめました

はじめに

こんにちは、HEROZです。今日は皆様に大切なお知らせをお届けしたいと思います。それは…HEROZのテックブログが新たに開設されました!
私たちが日々取り組んでいる技術の一部を皆様に直接お伝えし、より深く理解していただけるようになることを願っています。

HEROZについて

HEROZは以下のようなサービスを提供するAIテックカンパニーです。

私たちの目指すところは、AI革命を起こし、「驚きを心に」をコンセプトに、世界を驚かすサービスを創出すること。そのためには、テクノロジーの力を最大限に発揮しつつ、とにかく面白く、人が驚くようなことを追求していきます。その想いは、創業者の一人である林が将棋のAIに未知の可能性を感じ取り、その力を活用して「一人でも多くのヒーローの誕生」につなげるというビジョンを立てたことから始まりました。
事実、はじめてAIがプロ棋士に勝利してからのこの10年の間に、将棋界にはAI革命とも言える大きな変革を経験し、新たなヒーローが生まれていることは多くの人がご存じの通りかと思います。(この将棋界で起きた革命と、産業界におけるアナロジーについては、また時間があるときにこのBlogを通してたっぷりとお伝えしたいと思います。)
そして、最近は「AIトランスフォーメーション」というコンセプトを提唱しています。従来型の機械学習モデルの場合は、ビッグデータが必須、つまりは企業はデジタイゼーションのプロセスを経ていることが必要不可欠でした。これが、LLMのような大規模な基盤モデルの登場により、大量のデジタルデータが無くとも、AIの恩恵を受けられるようになり、ビジネスに非連続な変革をもたらすのではないかと私たちは考えています。

なぜTech Blogを立ち上げるのか?

これまで私たちは、自社の技術情報を積極的に発信することがあまりありませんでした。その結果、どのような研究開発をしている会社なのか、よく分からないという声をたくさん頂いておりました。
しかしながら、当社は近年も、世界コンピュータ選手権で優勝したdlshogi with HEROZの開発や、LLMに関する専門組織の設立など、様々な取組みを進めております。
こうした活動を通じて得られた成果や知見を多くの人に知っていただき、HEROZという会社がんなことをやっているのか、どんな人々が働いているのかを社外の方にもご理解していただきたいと考え、このテックブログの開設に至りました。

Tech Blogについて

このブログでは、将棋のゲーム開発を中心に、企業向けの様々なソリューション事業、そして最近力を入れている大規模言語モデル(LLM)の事業など、HEROZが取り組んでいる多岐にわたるテーマについて触れていきますので、是非楽しみにしていただければ幸いです。
今後ともHEROZをよろしくお願いいたします!