元気しとーと？ 博多に住んどうUiPathプリシェールス @ManabuTechばい。
（お元気でしょうか？ 博多に在住しておりますUiPathプリセールスManabuTech です）
UiPath 6 Forwardのブースで、自社ナレッジに対する質問に対しても回答可能な「生成AIチャットボット」を展示しました。
生成AIアプリケーションを作ってみて分かった、生成AIアプリを社内で利用する際に気を付けるべき6つのポイントを紹介します。
展示ブースに来れなかった人はYoutubeにアップしましたので、こちらをご覧ください。
（クリックするとブース展示コンセプト動画が再生されます）
生成AIの社内導入には、次の３つのステップがあると考えています。
・STEP1.再学習されない安全な環境で生成AIを利用できる
・STEP2.生成AIで社内情報に関して質問できる
・STEP3.生成AIを使用して業務を自動化できる
ブース内で会話させた頂くと、未導入またはSTEP1の企業が多かった印象です。
生成AIを利用しているけれどそこまで便利になっていないと感じる方も、STEP2、STEP3まで進んでいくと効率化を実感できると思います。
STEP1.再学習されない安全な環境で生成AIを利用できる
ChatGPTをそのまま使うと入力した情報が再学習されてしまいます。OpenAIのAPI経由で生成AIを使用する方法を推奨します。銀行などセキュリティが厳しくインターネットに出られない環境の場合はAzureOpenAIServiceなどを用いて、自社の生成AIの環境を利用します。
自分で構築しなくても、Webアプリを作ってサービスとして公開している企業もいくつかありますので、費用が合えばサービスを利用するという手もあると思います。
STEP2. 生成AIで社内情報に関して質問できる
生成AIは社内の情報について知りませんので、社内ナレッジを回答させるために知識を与える必要があります。
新しい知識を与える方法は大きく分けて2つあります。
・ファインチューニング
・RAG（Retrieval Argument Generation）
ファインチューニング
ファインチューニングはLLM（大規模言語モデル）に対して、新たな学習データを読み込ませて回答をチューニングする方法です。
最新のGPT-4がファインチューニングできない、また再学習に対して読み込ませるデータの量が多くなること、またハルシネーション（生成AIのでっち上げ）が起こる可能性が高いことからも、生成AIの出力する言語を日本語に変えたり、生成AIのキャラクターの語尾を変えたり、博多弁で回答させたりといったトーンの変更に使用することを推奨します。
RAG
RAGは生成AIへのプロンプトに社内情報などLLMが知らない知識を付与して回答させる方法です。
社内情報の書いたカンニングペーパーを渡して、これを見ていいから回答してくださいと言っているイメージです。ファインチューニングに比べてデータ量は少なくて済み、ハルシネーション発生率も低いため、新しい知識の習得にはRAGを使用することが一般的になりつつあります。
社内情報を利用できるRAGの仕組みを簡単に説明します。
生成AIは質問に対して持っているデータベースから類似性の高いトピックを検索して回答しています。生成AIは今までのアプリケーションがデータを保存していたリレーショナルデータベースではなくベクトルデータベースを使用します。自社情報はベクトル化されて保存され、質問が来た際にはこの質問と類似した社内情報が返されます。
例えるならば、「おはよう」と「こんにちは」は近い位置にいますが、「おはよう」と「かつ丼」は遠い位置にマッピングされている、そのようなイメージです。
ベクトル化する際にEmbedding LLMというモデルを利用します。OpenAIではAda v2というChatAPIよりも安くて利用できるAPIを利用します。絵では2次元のベクトルで表していますが、Embedding LLMは1536次元のベクトルにマッピングしてくれます。
STEP3. 生成AIを使用して業務を自動化できる
UiPath Forward 6 Japan内の講演でもありましたが、最終的に業務フローを生成AIありきのフローに変えていく必要があると思います。アプリに聞いて今までの業務を遂行するのではなく、生成AIの作ったドラフトを人間はチェックするだけ。このように抜本的に業務フローを変えるための6つのポイントを紹介します。
Point1 セキュリティ
これは先述しましたが、生成AIに対してAPI経由でアクセスするようにしておく必要があります。
AzureOpenAIサービスでも問題ありません。
Point2 フロントエンド
ChatGPTをそのまま使わずに、フロントエンドとしてブラウザ上で動作するWebアプリを作ります。
利用ユーザーを制限するためにログインなど認証機能を作ってセキュリティを高める必要があります。
Point3 バックエンド
生成AIと通信するバックエンドプログラムを作る必要があります。業務自動化のためには、APIを公開する必要がありますが、これも限られた人が使えるように認証の仕組みを作る必要があります。
Point4 利便性
自社情報に回答できる生成AIのAPIを公開しても、社員がAPIを叩いてJsonをシリアライズ、デシリアライズして情報を抜き出したりできるわけではありません。Jsonを意識しなくてもよい仕組みが必要になります。例えば、RPAなどで部品としてラッピングして業務の自動化に簡単に組み込めるようにするなどの必要があります。
ここまでしないと生成AIを活用しての業務効率化、普及は進まないのではないかと考えています。
Point5 保守性
バックエンドプログラムからアクセスできる安全な環境に自社情報を保存できることは重要ですが、データの一元化など、保守が面倒とならないことも大切です。自社ナレッジは常にアップデートされていきます。1つでもメンテンナンスすることは大変なので、一元管理できる仕組みを目指しましょう。この処理はRPAでやることによってメンテナンスコストを削減できるのではないかと考えています。自社のFAQサイトやドキュメント置き場の運用は変えずにロボットでバックエンドプログラムがアクセスできる場所まで定期的に運ぶ処理を1回作っておけば、RPAが作れる人はメンテナンスできるので、ファイルを追加したりすることは容易になります。
Point6 可視化
最後に、不正に利用されていないか利用状況を見えるかすることは重要です。使いすぎている人がいないか、許可されていない人が不正に使っていないか、確認する手段は絶対に必要です。
また、同じ問い合わせが行われないようにしてコストを抑えるなどの施策の材料となります。
UiPathで作成した際のポイント
生成AIチャットボットをUiPath製品群で構築した際のポイントを最後に紹介します。
Azureを使う方法、バックエンドプログラムを外部サーバーにデプロイする方法、様々な方法があると思いますが、UiPathの環境を使うことのメリットは「簡単に構築できる」「カスタマイズの容易さ」の2つだと思います。
これはUiPathに限らず、ローコードツールで生成AIアプリケーションを構築するメリットとも言えます。
詳細な作り方は別途記事にしようと思いますが、ここでは概要を紹介します。
フロントエンド Webアプリ
ローコード開発ツールの「UiPath Apps」を利用して開発しました。
ボタンを押された時に裏でロボットが動きます。
UiPathではワークフロートリガーという仕組みが23.4で導入されました。Webアプリと自分のPCにあるロボットが高速に通信できる仕組みです。今まで応答性にストレスを感じていた人もストレスを感じにくくなっていると思います。
1点、動的に表示を追加することができないためチャットアプリとして作り方は工夫がいります。
SlackなどのチャットツールをUIとして裏でUiPathを動かすという仕組みにしてもいいと思います。
UiPathを使うことで認証周りを作る必要が無かったので、ここは楽ができました。
バックエンドプログラム
AI Centerは、作成したAIモデルを格納するためのサーバーです。
AIエンジニアが作成したAIモデルを業務担当者が使うためには、実行方法やJsonの取り扱いの点で難しいのですが、AI CenterがあるとUiPath Studioで使える部品化することができます。ドラッグ＆ドロップでRPAと同じようにAIを業務に適用できるようになります。
AI Centerにはすぐに使えるAIモデルが用意されていますが、カスタムモデルとしてPythonプログラムをアップロードすることもできます。今回は生成AIモデルにアクセスするためのPythonプログラムをアップロードしました。LangChainやLlamaIndexという生成AIアプリケーションを使用するためのライブラリを利用しているため、割と作りこまずに済みました。
UiPathで生成AIアプリケーションを作って運用したいという人にはサンプルプログラムとして提供を考えていますので、APIキーなどの追記する簡単な修正後にアップロードするだけです。
検索したい自社情報の取り扱い
AI CenterはAzure上に構築されているセキュアな環境ですので、ドキュメントは安心して保存することができます。AI Center上にドキュメントを配置していくこともできるのですが2重管理になってしまうので、現在のFAQナレッジを貯める運用は変えずにRPAでFAQサイトや社内ドキュメントを定期的にAI Center上に配置していく方法を採用しました。こうすることで生成AIアプリケーションを使うために最新にドキュメントを保守する必要が無くなります。後で別途記事化する予定ですが、文書を突っ込んだだけでは社内ナレッジFAQ 生成AIチャットボットの精度が高くならないことが分かりました。よってRPAでひと手間加えて格納するというフローは必要だと思います。
簡単に使える仕組み
AI CenterでアップロードしたPythonスクリプトは自社情報データと結合されて、MLスキルになります。MLスキル化することで、UiPath Studioから使えるようになります。
これだけでも簡単に使えるのですがもっと簡単に使えるようにするため、UiPath Studioのライブラリ機能を使用して、共通部品化しています。JsonやMLスキルを隠ぺいして、使用する開発者やユーザーは質問を投げたら、その回答や参照している文書と精度を取得できる構造にしています。共通部品化しておくことで何かMLスキルをアップデートしたい場合も、簡単に処理を変更できるメリットがあります。UiPathを使うことで認証周りを作る必要が無かったので、ここは楽ができました。
可視化ツール
MLスキルが実行される際、ロボットが実行されます。
ロボットが実行されるため、管理ツールのOrchestrator上でその実行履歴を確認することができます。よって、この辺りはUiPathを使用することで意識せずに可視化することができました。
Orchestratorのログを可視化するInsightsを用いることで、詳細な分析が行えるようになります。
さいごに
生成AIチャットボットを作成し、さらに生成AIの可能性を感じることができました。
生成AIにドラフトを作ってもらって人がチェックするような仕組みを構築することができれば、今まで以上の抜本的な業務効率化をはかれると思います。
しかし、自社ドキュメントを格納するだけでは、正しく社内情報を見つけてこれないという課題があることが分かりました。このあたりのドキュメントの参照精度を向上させる方法は別の記事にしますが、UiPath AI CenterであればPythonスクリプトで参照方法や分割方法をカスタマイズすることができるので、精度を上げていきたいという企業はこの点がUiPathで運用する一番のメリットになるかと思います。
本ソリューションは、現在の業務と並行して、カスタマイズしやすいように手順書などドキュメントを充実させていきたいと思います。