AIエンジニアがいない中でLLMとどう向き合ったか　自社プロダクトへのAI導入で得た、4つの学び

登壇者の自己紹介とアジェンダ紹介

金岡亮氏：みなさんこんばんは。「LLMからはじめる、プロダクトへのAI導入」というタイトルで発表いたします。私たちSmartHRは「従業員サーベイ」というプロダクトを提供しており、その中で「要約AI」というLLMを使ったサービスをプロダクトとして出しています。これをリリースするまでにどんなことをやってきたのかというお話ができればと思っています。

私は金岡と申します。私はふだん、プロダクトマネージャーをしており、弊社のタレントマネジメント系のプロダクトを複数見ています。今年に入ってからLLM利用のタスクフォースや、AI活用のR&Dの組織を立ち上げています。前職では、AIの受託系の会社でプロジェクトマネージャーをしたり、データアナリストをしていました。

今日のアジェンダですが、機能リリース前のお話と機能リリース後のお話。あとは4つ学びと今後の展望というかたちでお話しします。

AIエンジニアが1人もいない状態の中でLLMが登場

では、まずは機能を出す前、2023年初めぐらいのイメージで聞いていただければと思いますが、弊社がどういう状況だったのかというところからお話ししたいと思います。

「LLMとどう向き合ったか」というところですね。SmartHRはけっこう大きくなってきていて、急成長メガベンチャーと言われることも増えてきたと思いますが、実は今年までAIエンジニアやAIの取り組みを一切やっていなかった状態でした。データサイエンティストもいませんでした。ニーズ自体はありましたが、ぜんぜん大きな取り組みになっていなかったという状況でした。

そこにLLMが登場しました。GPT-3.5が2023年3月に出ましたね。私はもともと「Stable Diffusion」を触っていました。これはけっこうやばいなということで、競合さんも触っていたので、逆にチャンスなのかもしれないなと思いました。今まで一切AIをやってきませんでしたが、LLM活用の突破口にAI活用が始められるんじゃないかという考えのもとで始めた感じでございます。

それでタスクフォースを作りました。タレントマネジメント系の事業責任者と私で相談して、1人チームみたいなかたちでタスクフォースを組んで始めたというのが、私たちの最初のLLMとの出会いという感じでした。

LLM利用のタスクフォースを組成

タスクフォース活動はどんなことをやってきたの？　ということですが、これからLLMを会社で使いたいよという方のご参考になれればなと思っています。どんなことをやったかを3つご用意しています。

最初に、AIの勉強会をひたすらやりました。泥臭くこれはやりましたね（笑）。誰も何ができるのかがぜんぜんわからないという状況だったので、「海のものとも山のものともわからない」状態を脱するというところで、職種問わず、エンジニア向け、普通の職種の方向けに両方勉強会をやって、「これはなんとなくできそう」という状態にしていきました。

あとはひたすらプロトタイピングをしました。私はエンジニアではありませんが、StreamlitとPythonを使って、あるあるな構成だと思いますが、LLMはプロダクトでこういうことができるよねみたいなことでサンプルをいっぱい作って、プロダクトのエンジニアやプロダクトのサイドの人にこういうことができるという具体的なイメージを持ってもらうように振る舞ってきました。

さらに具体化するために今度はハッカソンを行いました。当時の時点で（従業員数が）800人から900人ぐらいいたのですが、50人ぐらい職種をまたいでいろいろな方が参加してくれました。10チームぐらいできたのかな。そこでいろんなアウトプットが出てきました。セキュリティや法務のメンバーもエンジニアと一緒にプロダクトを作ってくれて、セキュリティチェックシートを自動で書いてくれるやつを作っていたのがおもしろかったです。

そういう開発プロセスで関わる方々にリスクやアウトプットの両方のイメージを持っていただけたのは非常に大きかったかなと思っています。こんな感じで泥臭く振る舞っていたら、プロダクトでもけっこうLLMを使えるんじゃないの？　というところまで認識ができてきたというのが、まずは前半でございます。

従業員サーベイ「要約AI」開発時の課題設定とは？

さて、じゃあここからは、実際にプロダクトを作って参りましたというところで要約AIについて紹介したいと思います。

「もう実プロダクトに入れていきましょう」という話が出ましたと。入力補助など、LLMを使った機能は出てきていると思いますが、それはそれで価値があるかなとは思いつつ、差別化にならないと（思っていました）。

各社がやってきているので、一番コアコンピタンスになるのは何だろうと考えた時に、やはり私たちだと、従業員データの部分。SaaSなので、いろいろなプロセスに入っていて、集められている会社のデータがいろいろあるので、これらをLLMで可視化することがやはり差別化につながると考えて、それに関連したものを探していくという感じでございます。

私は一応プロダクトマネージャーでもあるので、まずは課題設定から始めました。けっこうインパクトがわかりやすくて、きちんと効果が出る。LLMのための機能というよりは、ユーザーさんにきちんとインパクトが出るものを探索しました。3つぐらい観点があって、既存のユーザーにきちんと要望されています。これはけっこう大前提かなと思います。

あと、従来手法はちょっとコストが高くて、やろうと思えばできるんだけどわりと面倒くさいとか、すごくお金がかかりすぎるとか、実装できる人がいないとか、そんなものですね。ほかにはアウトプットが具体的で社内にも社外にもイメージがしやすいものという感じで、いろいろな課題を探索しました。

私が担当しているのは従業員サーベイという、アンケートみたいなツールです。そのツールに、自由記述回答を導入企業さまの従業員から集めて、その結果を見るという機能があるのですが、例えば、300人ぐらいの会社で従業員向けにアンケートを取ったあとって、人事が全部のアンケートを一個いっこ見るんですよね。すごくそれは大変です。

これが数千人規模、数万人規模になってくると、とてもじゃないけど見切れないということで非常にペインが大きかったのですが、従来、テキスト要約ってけっこうハードルが高くてぜんぜんできていなかったというところで、「あ、この課題は良いかも」というところで、この長文要約、あとはポジネガ判定というところにアプローチして参りました。

それでできたのが要約AIという機能で、具体的には部署ごとにテキストを要約してくれて、かつポジティブな回答とネガティブな回答に分けてくれるものになっています。

実装における3つの工夫

じゃあここからちょっと実装上の工夫もお話ししたいと思います。AIを活用したことがない会社で初めて活用するにはどうするかというところなんですけども。まず、弊社はメイン言語をRuby on RailsとReactで作っています。そこでいきなりPythonのコンポーネントを作ってもたぶんメンテされなくなっていくだろうなと（笑）。

あと、もしかしたら超属人化するかもと思ったので、LangChainのロジックをRubyで実装しました。LangChainはオープンソースで、アルゴリズムやプロンプトもオープンなので、中身をよく読んで要約に使えそうな部分をRubyで作りました。

あとは、テストがとても難しいです。プロダクトを作る上でのテストをすごく大事にしているのですが、要約とかはもう完全に主観なので。逆に、テスト基準をきちんと明文化しました。

この時はプロンプトを直しましょう、この時はちょっとみんなで話し合いましょう、この時は期待値調整で事前にお客さんに伝える感じにしましょうという感じで、3段階ぐらい優先度を決めてテストをしました。あと大事なのが複数人でテストをしたのですが、それぞれの主観で判断していくので、データは変えるけど人は変えないということをやりました。

テスターは固定して基準を明確にして、データを変えていくことでテストをしていくというのをやりましたね。けっこう地獄で、これは大変でしたね（笑）。

あと最後はユーザーとのコミュニケーションで、私たちは法人向けのサービスで信頼が非常に重要です。人事のお客さまの先にはさらに、従業員の方がいらっしゃるんですね。

従業員の方に黙ってAIを使っちゃうと、管理者の方はハッピーになるかもしれませんが、自分のデータを勝手に使われたということでハレーションが起きやすいので、オプトイン型にしました。管理者の方と従業員の方にコミュニケーションを取っていただくという促しを私たちからさせていただく。そんなかたちにしています。

プロダクトへのAI導入で学んだ4つのこと

4つの学びがあります。まず、私たちはAI組織がない、AIをわかる人が誰もいないという中で、LLMってAI的な体験をプロトタイピングするにはかなり便利なツールだなと思っています。精度などは置いておいて、それなりのクオリティのものがすぐに作れるというのはすごく大事なポイントだなと思っています。

あと、既存のプロダクトに組み込む時ですが、マシンラーニング系は全部一緒なのかもしれませんが、LLMを独立したコンポーネントにしないってけっこう大事なことだなと思いました。自社の環境に合わせたほうが、そのあともプロダクトチームでメンテナンスできるので、その後の改善はしやすいです。

ちょっとよもやま話です。私たちはAzureのOpenAI Serviceを使いました。Ruby OpenAIというgemがあるのですが、まだAzure OpenAI Serviceが対応をしていなかったのでforkして、オープンソースをちょっと変えて自分たちで使うということもやっていました。今は対応しているので使えると思います。あとはLangChain、LlamaIndexもそのまま使っていないですね。

あとは、いろいろな登壇などで聞いているLLMの課題がすごく身に染みてわかりました。明確なテスト基準もないですし、私たちはけっこうスケーラブルに、もう数千人とか数万人とかの従業員の方にプロダクトを提供しているので、正直GPT-3.5一択みたいな感じなんですね。専用サービスを作るのにそのための料金をもらわないとGPT-4ではとてもじゃないけどスケールしないということで、ここでGPT-3.5で解けるような課題を設定することが大事かなと思っています。

あとはGPT-4の場合は、もっと単価の高い課題にアプローチする。そんな感じですかね。ほかにはAPIのモデルの変更とかですね。0613のモデル（GPT-3.5-0613）でしたっけ？　そこですごく精度が変わったりもしたので、そういうところのコントローラー、アビリティがあるところは上げていきたいなと思っています。

最後ですね。自社データと組み合わせるとなると、従来のMLと併用したほうが絶対に良いかなと思っています。例えばOCRでデータを読み込んできたり、結局自社データをLLMに入れるんだよと。前処理とかパイプラインを組まなきゃいけないので、ML的な知識がいるんですね。MLOpsみたいな知識はぜんぜん無駄にならないと思いますし、結局MLエンジニアの方がいないとダメだなという感じになっています。

あとはRAGの評価って結局検索とほとんど一緒で、従来型の指標を使うんだろうなという感じがあるので、当然LLMだけじゃなくていろいろなMLと組み合わせて使えます。両方できるのが当たり前に大事なんだなと思っています。

今後の展望

今後の展望ですが、AI研究開発組織を作って、専任のデータサイエンティストの方も雇用して、徐々に組織もスケールしていくということで、まだ採用などはオープンにできていませんが、いずれはそういうこともあるかなと思っています。今日おもしろいなと思った方は、またお話できればと思います。どうもありがとうございました。