AI inside x Stockmark Tech meetup 〜B2B SaaSの機械学習プロダクトマネージャーの取り組みとお悩み公開します〜【後編】
「機械学習プロダクトマネージャーのリアルな取り組み内容を大公開!」をテーマに、AI inside 株式会社(以下、AI inside)とストックマーク株式会社(以下、ストックマーク)のプロダクトマネジャーがプレゼンを実施しました。それぞれの仕事の内容や悩み、キャリアなどについて、前編と後編に分けてお届けします。後編ではストックマークのプレゼンとパネルトークの様子を紹介します。(前編をまだお読みでない方はこちら)
「新機能リリースから紐解く、自然言語処理技術を踏まえた機能企画の3STEP」
ストックマークの中尾と申します。
本日は今年の8月にリリースした新機能を題材に、「新機能リリースから紐解く、自然言語処理技術を踏まえた機能企画の3STEP」についてご紹介させていただきます。
まず簡単に自己紹介ですが、私は2020年の9月からストックマークでPMとして働いております。これまでは、主にBtoB領域でデータやAIのプロジェクトやプロダクトに携わっておりました。ストックマークでは2つのBtoB SaaS製品を提供していますが、いずれも検索やレコメンドの技術が重要なサービスです。本日はそのうちの一つであるAstrategyでの事例を中心にお話をさせていただきます。
Astrategyの概要
Astrategyは「膨大な時間がかかる市場調査をAIが瞬時に実現」というコンセプトの元、2019年の12月にリリースしたプロダクトです。
裏側ではテキスト情報のクローリングを毎日しており、集めたデータをデータベースとして保持しています。保持しているテキスト情報を自然言語処理で構造化し、ユーザーが市場調査を行う際に効率よく欲しい情報を収集できるようにしています。
元々は記事の検索がメインのサービスでしたが、2022年8月に事業環境レポート機能をベータ版でリリースしました。ユーザーはただ記事を検索したいのではなく、事業企画をする上で必要な情報の収集・把握を目的としているため、企画の初期段階で把握するべき市場規模・政府動向などを自動で選んでレポートとしてまとめる機能としました。
今後も機能追加を予定しておりますが、リリースに至るまでに検討した内容をご紹介したいと思います。
機能開発の3つのSTEP
事業環境レポートの開発では、大きく三つの自然言語処理の技術を活用しています。
1 企業名・団体名の抽出
2 センテンス抽出・分類
3 類似記事集約
Astrategyでは「仮説構築・検証(DIscovery)」「開発(Delivery)」「評価(Evaluation)」の大きく3つのステップで開発サイクルを回しています。自然言語処理を活用した技術の場合は、Discoveryのフェーズでロジックを検討したりアノテーションやモデルの学習などを行っています。
これらを踏まえ、各ステップにおいて気をつけている内容をご紹介します。
Discovery phase
「AIの機能は問題設計とベンチマークデータが全て」というちょっと強めのワードですが、これは共同研究をやらせていただいている東北大学の乾先生の言葉です。2010年の学会誌に掲載された文章でも、ほぼ10年以上前から問題設計とベンチマークデータが重要と言われています。
Astrategyは検索サービスなので「ユーザーが業務上必要とする情報を提供する」という問題設計です。一見シンプルなソリューションに聞こえますが、必ずしもユーザーは必要な情報の具体化・言語化ができるわけではありません。このため、Discoveryのフェーズでは特に具体的なデータとは何かを定義することが大切です。
事業環境レポート機能を例に挙げます。この機能には政府動向の項目が含まれており、政府動向を表す部分を抽出・分類して表示します。「政府動向」は抽象度が高い言葉なので、具体化するために社内のドメインエキスパートと議論を重ね、「政府動向」の中身を細分化し、要件定義をしています。
類似記事の集約も例に挙げます。人によって類似の定義解釈は千差万別ですが、過去の事例では、ユーザーへのインタビューから類似記事の定義として、同一の企業活動を表す記事ではないかというような仮説があり、仮説に基づきデータを用意して検証を実施しました。
Delivery phase
次にステップ2のDeliveryです。AIの開発フェーズで難しいのが、どれぐらいの精度でリリースするかという判断ではないかと思います。これもケースバイケースですが、1つの指針として機械学習のROIという考え方を参考にしています。
初期段階は最小限の工数から始めることを推奨しています。例えば、シンプルなロジックから始めたり、既存モデルの転用から始めます。出た精度を基準にし、より精度を上げるために必要な追加工数と得られるリターンのバランスを評価するという考え方です。
異常検知のように予測の誤りが大きいコストに繋がり、価値を上回るケースの場合は工数をかけて精度をなるべく上げるという判断になりますし、予測の誤りより価値が上回る場合は、早めにリリースした方が良いという判断ができます。
先ほど例に挙げた事業環境レポートの場合は後者で、「政府動向」の抽出は要件定義をしたものの、既存ロジックにルールベースAIを組み合わせることで、精度が担保され、新規の開発は最小限に早めのリリースが実現しました。
類似記事集約は元々の問題設計を見直しました。従来の設計だと非常にコストが高くなるため、近似の問題設計に落としてシンプルなロジックで解けるように工夫をしています。
類似記事集約のアルゴリズムについては、ストックマークのTech Blogもご参照ください。
Evaluation phase
最後にステップ3のEvaluationです。AI機能はリリースがスタート地点となります。上記の図は2020年にLanding AIというアメリカ企業が出したホワイトペーパーに掲載されているAIの好循環サイクルを表した図です。AIの機能がユーザーに価値を提供して、ユーザーが増え、利用が増え、さらにデータが増えて増えたデータを活用することで、最終的にAI機能の追加やユーザー体験の向上につながるという、まさに理想型です。
機械学習のプロダクトマネージャーとしては、この状態を作ることが1つの目標になるかと思っているのですが、一方でAI機能を継続的に運用するというのは簡単ではなく、リリースしてからの方が考慮すべきことが多いかもしれません。
A16Z(Andreessen Horowitz)のオウンドメディアであるFutureで掲載されているAIの運用に関する記事では「堅牢で信頼性の高いAIを構築するための7つのテクニック」というトピックで、下記のとおり要素が整理されています。
信頼性のベンチマーク
データ監査の実施
信頼性のモニタリング
不確実性の見積もり
ドリフトの管理
継続的な学習
継続的なテスト
本来であれば7つの要素を全て網羅したいのですが、ストックマークでは「信頼性のモニタリング」「継続的な学習」の2つから取り組みを進めています。
AIを運用するとモデルが新しい未知のデータに対してはどのような処理がなされるのかをモニタリングする必要があります。一方、未知のデータに対してその都度、正解データを用意して評価をすることは非常に膨大な作業となり、現実的ではありません。現状は未知の新しく入ってくるデータの中から正解に近いデータを特定して、そのデータに対する出力を評価する形で精度をモニタリングしています。
他には定性的なフィードバックもフル活用しており、社内のメンバーが発見した問題をSlackで報告するというワークフローで運用しています。このように定量・定性モニタリングを通して段階的に改善しています。
最後に3つのステップのまとめです。このDiscovery・Delivery・Evaluation、それぞれのフェーズで問題設計やROIを考慮したスコープの設計、定量・定性を組み合わせた評価など、段階的に改善してプロダクトを作っています。
パネルトーク:精度と上位指標との関係性はどうやって考えてる?
ここからはパネルトークの内容から関連するテーマを一部ピックアップしてお届けします。
Q:Andreessen Horowitzの7項目から2項目を選んだ理由を知りたいです。
中尾:現在の弊社のステータスにとって重要な2つを選びました。
ドリフトのように外部のデータが変わることで精度に影響が出ることもありますが、特にデータ周りについては弊社で管理できる仕組みがございます。
モデルの精度はリリース後にお客様やCSチームから出てくる定性的なフィードバックをベース対応しています。もちろん定量的な評価としてモニタリングを実施しています。
岩瀬:佐藤さんにもお伺いできればと思います。AI inside ではドリフトなどのデータ起因の問題にどのような対策をとっていますか。
佐藤:Slack内にフィードバックのワークフローを組んでいて、リクワイアメントの集約管理をしています。もちろんCSのメンバーやお客様からいただいている内容もありますので、連携して対策しています。
岩瀬:まさに定番のアプローチというか、おそらく参加いただいてる方も全く同じようなアプローチをとっている企業様が多そうです。
Q:精度が高まっても企業のROIやプロダクトのNSMなどに繋がらないケースもあるかと思います。精度と上位指標との関係性はどうやって考えられていますか?
中尾:精度が十分な中で、より100%に近づけて利益を得られないというケースよりも、別のアプローチにリソースを投下するのがいいという判断もあるのではないかと、この質問をみて感じました。佐藤さんのプレゼンの中で、ソリューションは機械学習だけじゃないという話ありましたが、まさにそのような考え方です。
岩瀬:おっしゃる通りだと思います。プロジェクトでは、実運用に耐えうる精度と、より完璧を目指すコスパが散るようなタイミングがあると考えています。例えるのであれば、TOEICである程度の点数が取れるようになると、勉強時間の割に伸び幅が小さくなるような状態です。その辺の引き際の判断をどうしますか?という質問になりますが、佐藤さんはどのように考えていますか?
佐藤:AI inside の「Learning Center」では今のところそのような判断をすることはございませんでした。一方、私の経験ではよくこういうのがあったのは確かです。機械学習のプロジェクトは、仮説と検証を繰り返して実験的なサイクルで進んでいく側面もあるため、プロジェクト初期は精度目標値を決めたり、PoCを実施しています。その段階では全体が見えていない状態なので、見直す前提で進めていくことも大事だと考えています。
岩瀬:前提を合わせておくのはめちゃくちゃ大事ですね。
本日は貴重なお話をありがとうございました。
・・・・