ラックの生成AIの最先端事例がまるっと分かる「LAC AI Day」を開催！その2

有志の技術者による成果発表の場から、全社員がAIを理解し可能性を共有する社内イベントへと成長した「LAC AI Day」。今回のLAC AI Dayでは、どのような内容が語られたのかを全3回のダイジェストでお伝えします。

2回目となるこの記事では、GitHub Copilotを使ってみて気づいたこと、先端技術ラボの取り組み、社内規定を回答してくれるAIを評価した方法、LLMのパフォーマンスを最大限に引き出すために知っておくことについての講演をお届けします。

講演4：GitHub Copilot使ってみた

SI統括部 セキュリティエンジニアリンググループの三宅 秀夫は、GitHub Copilotは実際の開発現場で有効かどうかという視点で、デモを交えた説明を行いました。

GitHub Copilotとは、統合開発環境（Integrated Development Environment：IDE）のことです。簡単なコードやコメントを書くと、生成AIが実行可能なコードを提案してくれるため、開発効率の向上に期待されています。

GitHub Copilotには、GitHub Copilot for Individualsと、GitHub Copilot for Businessという2種類のサービスがあります。価格のほかに、Copilotの学習データの収集（テレメトリ）範囲の違いや、ポリシー管理の有無などの差異があり、業務利用に際する注意があるとお話ししました。

GitHub Copilotの利用に際しては、IDEで拡張機能を設定するだけでなく、予めGitHubサイトでGitHub Copilotを有効にする必要があります。対応しているIDEとして、Visual Studio CodeとJetBrainsが紹介されました。

概要の説明の後、実際にGitHub Copilotを使用したデモを実施しました。例えば、「CulculateDaysBetweenDates」という関数の定義で名前と引数を指定し、中身のコードは一切書かない状況でCopilotを動かすと、関数名から推測される機能を実装したコードを複数提案してきます。提案されたコードの中で、的確なものがあればそれを採用すると、コードを書かなくても関数を作成できました。

また、コードにコメントを入れることで、コメントを読み取ってコード内容を提案し直し、より的確なコードに近づけます。さらに、Userという変数名をつくると、人物に必要な属性情報をオブジェクトとして定義し提案してくれます。このように、実装したい機能のヒントを与えることで、Copilotが意図を組んで近しいコードを複数提案してくれる機能であることがデモされました。

総括として三宅は、「コード初心者はCopilotを使うことでコードの作成ははかどりますが、提案されるコードを検証できるかが鍵になります。コードを理解している中級者であれば、Reactのようなフレームワークに慣れていない方でも、ひな形を作ってくれるので助かると思います。上級者にとっては、デザインパターンを作って、複数のオブジェクトが関係するコード全体の設計をする場合や、パフォーマンス上の理由で特殊なコードを書かなければならないような場合は、Copilotの出番があまり無いかもしれません。」と、利用者のレベルによりCopilotを利用する、しないを見極めるべきとコメントしました。

講演5：研究機関での取り組みと担当業務の紹介～生成AIを添えて～

SE統括部 ソリューションサービス第三部の山口 諒は、技術者交流の一環で株式会社日本総合研究所 先端技術ラボに出向しており、デジタル社会に向けた先端技術の調査と検証を行っています。

最新の技術のビジネス活用の有用性を評価しており、AI・データ分析技術を活用した技術領域で、大規模言語モデル（Large Language Models：LLM）のビジネス活用について研究しています。

トレンドである生成AIに関しては、セキュリティ面を考慮してChatGPTが利用できる「Azure OpenAI Service」や、組織固有の知識を活用できる「RAG」のような技術を用いたユースケースの検証をしています。

生成AIに的確なアウトプットを生成させるプロセスとして、プロンプトエンジニアリングが使用されますが、それだけでは十分な性能が引き出せない場合、次のようなチューニングを必要とします。

• 言語モデルの追加学習
• 特定タスクに特化した学習
• 指示に対応するための学習（Instruction Tuning）
• 人間のフィードバックによる強化学習（RLHF）

山口は生成AIの活用に関して、今後は活用先を見極めるフェーズに移行すると言い、今後の展望として次のように整理しました。

LLM活用の深化

• RAGによる組織内の知識をLLMの出力に反映させるための環境整備、自組織が提供するアプリケーションにLLMを組み込む動きが拡大する。
• ユースケースに応じた適切なモデル選択やリソースを確保する。

共同でのデータセット整備／モデル開発

• LLM自体の開発には大規模な計算資源や大量のデータが必要となる。
• 政府主導や複数組織の共同開発による、モデルの開発やデータセットの整備の事例が増加する。

テキストと画像を組み合わせた活用の進展

• 画像とテキストを同時に処理するAI（マルチモーダルAI）の技術が進展している。
• ビジネス上の応用範囲がより広がるが、文書中の図表をLLMへの入力情報としてそのまま活用できないという課題が生じている。

講演6：社内規程集AIを評価してみた

SI統括部 AIプロダクト開発グループの青野 有華は、社外の研究機関で2年間、AIのビジネス適用のノウハウを学びました。その後ラックに戻ってからは、AIの活用に向けた業務フローの提案をしています。

生成AIを業務に活用する際、業務に特化した内容を生成AIに答えて欲しいといったニーズが出てきます。それを解決する手法をRAGといいます。

RAG（Retrieval Augmented Generation）とは、情報検索と文章生成を組み合わせた技術のことで、通常の生成AIに検索エンジンを組み合わせると、生成AIが保持していない知識の事柄を答えてくれる仕組みを作れます。

RAGは常に新しいアーキテクチャが出てきていますが、それが果たして従来のアーキテクチャよりいいのかどうか判断が難しいところです。そこで、常にアーキテクチャを「評価」できる仕組みが必要です。青野は、評価プロセスのノウハウを獲得するために、ラックの社内規程について回答してくれるRAGを使って、一連の評価プロセスを試しました。

まずは評価指標を決め、質問と真の回答のペアのデータセットを80件作成します。RAGに質問を入力して生成される回答と、真の回答を比較して評価します。その中で、RAGのアーキテクチャを試行錯誤するたびに人手で評価するには、時間的なコストがかかりすぎることに気づきます。そこで、RAGが生成する回答と真の回答の文章を生成AIに入力し評価させることで、このコスト削減に対応しました。

次のプロンプトにあるように、評価指標の定義と被評価内容をインプットすることで、評価を自動的に行うようにしています。

この生成AIによる評価の際に重要なことは、生成AIによる評価が人による評価とどれくらいマッチしているかの確認です。生成AIによる評価とはいえ、適当な数値を出力されては意味がありません。生成AIによる評価の評価が必要です。

この確認を経て、評価の自動化が可能になり、さまざまなRAGのアーキテクチャを試行錯誤できるようになりました。しかし、評価用生成AIの精度向上や、評価するたびにAPIの利用料がかかるためコスト削減の課題などもあります。

この取り組みの詳細は、LAC WATCHで詳しく解説していますので、興味がある方はこちらをどうぞ。

講演7：LLMのパフォーマンスを最大限に引き出すために知っておくこと

SE統括部 ソリューションサービス第一部 アカウントサービスグループの中林 寛喜は、主にLLMを使用したチャット形式の業務支援アプリケーション開発を担当しています。

LLMとは、インターネット上で公開されているテキストデータから、文章の構造や意味を抽出して学習した情報のかたまりです。ChatGPTはそれらの情報を流暢な会話として活用できるように最適化しています。さて、このLLMを用いたシステムを作っても、次のような理由で期待した結果が出ないことがあります。

• 長いプロンプトを書いても、その中の何が悪さをしているかがわからない
• 悪さをしている原因が発見されたとしても、それを解決する方法が難しい
• LLMに小説を書かせた場合など、独創性やストーリーなどの評価が難しい

LLMの開発方法には、プロンプト（指示文）からの学習、追加の学習データであるRAG、そしてLLM自体に追加の学習をさせるファインチューニングという質問と回答のセットを用いた方法があります。

一般的には、プロンプト、RAG、ファインチューニングの順で開発することが多いのですが、必ずしもこの流れでなければというわけではありません。どの開発フェーズで何を用いるかは、それぞれの長所と短所を理解する必要があります。

プロンプトは、プロトタイプや検証、シンプルなタスクに向いている反面、大量な情報の詰め込みや、新しい情報の追加は苦手です。

RAGはテストに参考書を持ち込むようなイメージで、回答に含まれる質や量を改善することに長けています。新しい知識の追加や、誤った結果の生成（ハルシネーション）を減少させることが得意です。一方、専門領域の理解が苦手で、応答の構造やトーンのカスタマイズには向いていません。

ファインチューニングは、指示に対する解釈ミスの改善に長けています。RAGとは逆に、専門領域のように複雑な情報を解釈して答えを生成し、言葉やニュアンスを学習させることもでき、プロンプトの解釈にも柔軟性があります。しかし、大量な情報の追加や変化する情報への対応は苦手です。

このように、それぞれの開発手法の得意・不得意があるためそれらのツボを押さえた開発に取り組むことが重要であるとまとめました。

イベントの講演動画を公開中

今回ご紹介したLAC AI Day 2023の講演の一部動画を特別に公開しています。こちらもぜひご視聴ください。

最後に

LAC AI Day 2023のレポートもいよいよ終盤です。

最終回となる次回は、生成AIとの向き合い方、ラック流のCopilot for Microsoft 365活用方法、生成AIのセキュリティを考える視座、非エンジニア向けChatGPT活用術をお届けします。ぜひお見逃しなく！