こんにちは！レバレッジ推進ユニットでQAエンジニアをやっているark265です。今回はQA Test Talk Vol.5で同じユニットのgonkmが発表した「LLM搭載プロダクトの品質保証の模索と学び」の発表内容のまとめと内容の補足を書いていこうと思います。
- 発表資料
- レバレッジ推進ユニットがAIの品質保証に取り組んだ理由(pp.7-10)
- アプローチ(pp.11-19)
- 取り組み(pp.22-25)
- 活動を通して得た学び(pp.27-29)
- 今後の取り組み・挑戦(pp.33)
- おわりに
- We are Hiring!
発表資料
レバレッジ推進ユニットがAIの品質保証に取り組んだ理由(pp.7-10)
まず、レバレッジ推進ユニットがなぜAI活用プロダクトの品質保証について模索し始めたのかをお話します。近年、多くの企業がAIを活用した機能やプロダクトの実装を加速させており、SmartHRも例外ではありません。
社内のAI活用プロダクトの開発状況は、すでに開発をしているチームとこれから開発する可能性のあるチームが混在している状態です。そのため、QAエンジニアも携わる開発チームによって、AI活用プロダクトの品質保証の知識がバラバラで、社内で体系化された知見が未整備な状況でした。
そこで私たちは、各チームがAI活用プロダクトの開発を始める際に品質保証活動がスピーディーに行えるように、基盤となる情報や方法論の確立が重要だと判断しました。 そのため、AI活用プロダクトの品質保証方法にレバレッジをかけることに取り組むことを決定し、第一歩として情報のインプットと技術検証から着手しました。
アプローチ(pp.11-19)
インプットする対象
私たちにはAI開発に関する知識はほとんどない状態で、どこから手を付ければよいか迷いました。また、私たちはAI開発のプロダクトを担当しているわけではないため、課題ベースで知識のインプットする対象を絞り込むことができませんでした。
そこで、まずは、AI開発の全体像とAI開発における品質課題とその品質保証を把握することを目指しました。 外部で公開されている以下のガイドラインを主に参考にし、業界のスタンダードを把握していきました。このような業界全体で使えるガイドラインを作って頂いて、本当に感謝しています。
インプットの方法
インプットの方法として、毎日勉強会を実施しました。各自が事前に読んだ資料から、「気になるキーワード」や「社内の開発チームで行うならどうするか」をテーマにして調べながら作業しました。
勉強会によって、知識が蓄積される一方で、疑問も次々と生まれ、調査がさらなる調査を呼ぶループに陥ってしまいました。結果的に、現状で必要な以上の知識をインプットしてしまい、「頭がパンクする事態」となりました。
知識の整理と現状課題の把握
この状態から抜け出すために、蓄積された知識をもとに、現場の意見を聞き、必要な知識やアプローチを決定していくことへシフトしました。
実際にAIプロダクト開発しているチームのプロダクトマネージャーとプロダクトエンジニアへヒアリングを行いました。ヒアリングは現在の取組みや品質課題、QAエンジニアへの期待値などで、まとめたものが以下のスライドです。
取り組み(pp.22-25)
ヒアリング内容から最初に取り組むべきスコープを絞り込み、まずは、知見がまとめられたドキュメントの作成とツールの検証を目的として、取り組むことを決めました。
取り組みの作業プロセスは以下のサイクルに沿って進めました。
AIの進化スピードとドキュメンテーションの課題
知識と技術のインプット・アウトプットのサイクルが確立し、フローの効率化が実現しました。その結果、「AIの進化スピードに追従するドキュメントをどうやって書けばよいのか」という新たな課題が見えてきました。
ドキュメントは「書くこと」が目的ではなく、「使える情報」として維持し続けることにこそ価値があります。しかし、AIの進化は想像以上に速く、半年で知識が陳腐化することさえ珍しくありません。
この状況で、私たちは陳腐化を防ぐために「どんな粒度で、どれだけ詳細にドキュメントを残すべきか」という、非常に難しい課題に直面し、現在も模索を続けています。
活動を通して得た学び(pp.27-29)
「評価」と「テスト」という2つの活動を整理する
LLMの応答品質を測定する「評価」とプロダクト全体の動作を確認する「テスト」の2つの活動を区別し、連携させることが品質保証において重要なことだとわかりました。
評価ではLLMの応答品質を扱うため、その内容はLLMアプリの品質に直結します。そのため、テストがもつ妥当性確認という役割が、評価の観点と部分的に重複することがあります。開発プロセスの観点でも評価を行うフェーズとテストを行うフェーズは異なります。
これらの特徴を理解して、適切なタイミングでどの品質を確認するかを考えていく必要があります。
QAEの役割定義
品質課題やQAエンジニアへの期待値をヒアリングしたことで、開発チームの状況が理解でき、必要な箇所に活動を絞ることができました。 まずは、私たちの強みであるソフトウェアテストの専門性やセキュリティ、パフォーマンス領域から支援活動を行い、開発チームへの補完関係を作ることと定義しました。
「評価基準」をチームで決める重要性
LLMの評価は定量的評価と定性的評価のバランスが大事になってきます。そのため、プロダクト特性にあった指標の選定やテストでどんなことを確認するべきかは開発チーム全体で話し合う必要があることが重要だと学びました。
今後の取り組み・挑戦(pp.33)
LLM向けのツールの導入
開発プロセスに導入することでLLMの品質担保に貢献できるツールの技術検証やPSIRTチームとも連携して、導入検討を行っていこうとしています。実際にプロダクトに対して技術検証を行ったり、開発チームに用意したものを使ってみてもらうなどして導入難易度なども含めて検証する予定です。検証結果については、まとまり次第ブログなどで発信できればと考えています。
LLMに関する品質保証の体系化
SmartHRではQAエンジニアだけが品質保証活動を行うのではなく、開発チーム全体で自立して行います。そのため、LLMの品質保証を行う方向けに体系化されたドキュメントの整備を行っていく必要があります。 まずは、「生成 AI 品質マネジメントガイドライン」を参考にしつつ、LLM固有の特性やセキュリティを確認するための汎用的な確認観点の作成を進めています。
ドキュメント作成は、LLM活用プロダクトの品質保証を担当しているメンバーと連携して、実際にドキュメントを使ってもらい、フィードバックを得て改善していく予定です。
LLMの品質保証の共有体制の構築
ドキュメントの共有だけでは限界があるため、モブで実務を行うことで知識と手法を早く身につけ、開発チーム内で自走できるようなサポート体制を構築しようとしています。そのため、LLMやOCRなどプロダクトに依存しない横断的な知識のキャッチアップと技術検証を継続して行っていく必要があります。
おわりに
以上が、「LLM搭載プロダクトの品質保証の模索と学び」の発表内容のまとめと補足でした。これは6ヶ月の期間を様々な人たちに助けられながら2人で行ったの取り組みです。
現在進行系のこの取り組みは、まだ万全な基盤構築はできていない現状で、ようやくその土台ができあがったかな、というところです。 今後もこの土台の上に、技術検証やナレッジの体系化を通して、より実践的な知見を積み重ねていきます。急速に進化する技術と向き合い、関係各位と共に品質を作り上げていくプロセスは、まさに挑戦の連続の日々です。
We are Hiring!
私たちはSmartHR全体の品質向上を推進するため、部内の他ユニットや会社全体を対象として、技術・プロセス・組織へレバレッジをかける役割を持っています。 今回お伝えした、AIの品質保証に関するアプローチ以外にも部門横断で品質向上へのアプローチも行う活動を行っています。
もし「こういった取り組みの推進に興味がある！」「もう少し詳しく話を聞いてみたい！」と感じていただけたなら、カジュアル面談をぜひご検討ください！私たちと一緒に、全社的な視点と横断的な活動を通じて、SmartHRの品質レベルの成長を支えていきましょう！
