はじめに
R&D チームの森元と田嶋です。本記事では R&D チームで取り組んでいる、大規模言語モデル (LLM) を用いたアプリケーションの品質保証について記載します。
LAPRAS では OpenAI 社の GPT モデルを用いて、IT エンジニアの技術記事を 5 点満点の複数の評価軸で採点して、さらに評価コメントを生成する「AI レビュー」を 2023 年の 6 月にリリースしました 1。
R&D チームはプロンプトなどの検証結果を元に作成した Python のライブラリを開発チームと共有しています。さらに、開発チームがこのライブラリをサーバー側にインストールして利用することでこの機能を実現しています。ライブラリは記事の情報を入力として受け取り、複数の評価軸の点数と、全体を総括する評価コメントを持った構造化データを出力します。
この記事では AI レビューで作成したライブラリの出力の品質を保証するための取り組みについて紹介します。
まず、はじめになぜ品質保証の仕組みを取り入れようと思ったのかの経緯を説明した後に、具体的な仕組みの内容について紹介します。
LLM を用いたアプリケーションのテストケースの作成は難しい
当初は LLM、およびライブラリの出力結果を定量的に測定するための評価指標を設けたいと考えていました。今回、特に評価コメントの部分は、似たような文章生成系のタスクである翻訳や要約と比較して、よりオープンエンドな出力となるため、既存の伝統的な評価指標などが利用できませんでした。今ならば別のモデルによって出力された文章を評価するなどの方法も選択肢としてあり得ますが 2、当時は GPT-4 がまだ使えず GPT-3.5 のみを利用していたため、この方法も諦めていました。
そこで、ある程度定性的な評価になってしまうことを許容して、テストケースを書き出して時々手動で実行しようと考えました。ところがこのテストケースもいざ書き出してみると、やはりオープンエンドな特性上テスト実施者によるバイアスの影響でテスト結果が不安定になることが予想されたため、テストケースによる品質保証は断念しました。
最終的に、せめて最低限の仕様を守れているか確認するための仕組みを導入して、これを継続的インティグレーション (CI) で実行することにしました。最低限の仕様とは、例えば「100 件の記事に対しライブラリの処理を実行した場合に、評価コメントがちゃんと丁寧語で生成されたものの割合が一定以上であること」などのことを指します。これらに違反していた場合は CI でエラーになるようにして、プロンプトなどの変更により予期せず品質が悪化した場合に気付けるようにしています。
最低限守りたい仕様を保証するためのテストなので、チームではこれを「ガードレールテスト」と呼んでいます (私達は利用したことはありませんが、LLM アプリケーション向けのライブラリである Guardrails.ai も同じような思想で作られているようです)。
ガードレールテスト
具体的にどのような項目を検証しているか紹介します。
攻撃的、または悪意のある文章を出力していないか
評価コメントとして攻撃的、または悪意のある文章を出力してしまっていないかを検証しています。
Open AI の Moderation API に評価コメントを入力して、攻撃的、または悪意のある文章と判断されたらエラーにしています。Moderation API は現時点では日本語を入力しても上手く機能しないため、一度英語に翻訳してから入力しています。
出力された文章が英語になっていないか
LLM への入力プロンプトでは英語で指示を書いた方が出力の質が良くなる傾向がありますが 3、出力としては日本語の文章を得たいです。そこで日本語で評価コメントを出力するように英語で指示するのですが、時々出力が英語になってしまうことがあります。この予期せずして英語になってしまった出力の割合が一定以下であるかどうかを検証しています。
丁寧語で出力できているか
評価コメントは「だ」や「である」などではなく、「です」、「ます」調で出力したかったため、想定通り「です」、「ます」調で出力できている割合が一定以上であるかどうかを検証しています。
構造化データは仕様を守れているか
複数の評価軸について 5 点満点で評価していますが、このフィールドが 1 ~ 5 の範囲内の値になっているか検証しています。また、そもそもフィールドの型は合っているかや、リスト要素の場合期待する数の要素を持っているかなどを検証していることもあります。
構造化データを正しく出力できているか
前述の通りライブラリでは GPT を利用して構造化データ (JSON) を出力します。JSON 形式の出力は GPT の Function calling を利用して実現していますが、時々 JSON として無効な文字列が返ってきてパースに失敗してしまうことがあります。この失敗する割合が一定以下であるかどうかを検証しています。
面白いことに、プロンプトの指示が矛盾を孕んでいたり明確でない場合に JSON として無効な文字列が返ってくる割合が大きくなるようなので、その場合はプロンプトの指示の仕方を見直すようにしています。
おわりに
LLM アプリケーションが仕様から外れた出力や中途半端な出力を出すと、ユーザーに不快感や不利益を与えて、アプリケーションに対する信頼が失われてしまいます。これを避けるために、AI レビューで初めて導入したガードレールテストは他の LLM アプリケーションでも積極的に利用しています。
また今後は LLM アプリケーションの出力を LLM アプリケーションとは別のモデルで比較するような、評価の仕組みも導入してより早く実験のサイクルを回していくような、攻めの取り組みもどんどん導入していきたいと考えています。
注釈1: 技術記事をAIが評価する「AIレビュー」の対象に、エンジニアの知識・技術共有サービス「Qiita」を追加
注釈2: Patterns for Building LLM-based Systems & Products
注釈3: Do Multilingual Language Models Think Better in English?
