本エントリはUbie 生成AI Advent Calendar 2024の5日目、「社内用生成AI Webアプリケーションをどのように作っているか」の第2回です。
前回は、社内用生成AI Webアプリケーション「Dev Genius」を開発した背景について簡単に説明しました。今回は、Dev Geniusの主要な機能の1つである「プリセットストア」について解説します。
プリセットストアとは
プリセットストアは、Dev Geniusの最初期の機能の1つで、利用者が作成したシステムプロンプトを保存、管理、再利用、共有できます。これにより、目的に応じた最適なプロンプト群を組織で協働しながら構築できます。エンタープライズ向けの生成AI SaaSにも大抵搭載されている機能です。
最近のものは業務に直結したものが多く見せられないので古いものを...
プリセットストアを実現する
システムプロンプトを保存するというだけなので、実現そのものに生成AIは必要ありません。単純なデータベース構造で十分です。テーブルの例は以下の通りです。
-- PostgreSQL
CREATE TABLE public.presets (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
title TEXT NOT NULL,
system_prompt TEXT NOT NULL, -- システムプロンプト
guidance TEXT, -- 使い方
user_id UUID NOT NULL REFERENCES public.users(id) ON DELETE RESTRICT ON UPDATE CASCADE, -- プリセットの制作者
created_time TIMESTAMP(3) DEFAULT CURRENT_TIMESTAMP NOT NULL,
updated_time TIMESTAMP(3) DEFAULT CURRENT_TIMESTAMP NOT NULL,
deleted_time TIMESTAMP(3),
visibility_level TEXT DEFAULT 'private' NOT NULL, -- private, publicなど
edit_access_level TEXT DEFAULT 'private' NOT NULL, -- private, publicなど
default_use_model TEXT
default_temperature DOUBLE PRECISION DEFAULT 0.0 NOT NULL,
);
特徴的なのはdefault_use_modelとdefault_temperatureくらいかなと思います。
- default_use_model
- プリセットが利用するデフォルトのLLMモデル名です。LLMモデルによって得意不得意、コスト、速度、最大入力量、最大出力量、扱えるメディアなどが異なります。プリセットの性質によって最適なモデルが変わってくるので、プリセット側に設定を持たせています。
- default_temperature
- プリセットが利用するデフォルトのtemperatureです。temperatureは生成するテキストのランダム性と創造性に影響を与えるので、プリセットの目的次第で設定の仕方が変わります。プリセット側に持たせるのが良いでしょう。
visibility_level, edit_access_levelはそれぞれプリセットの可視性と、編集権限を表していますが、かなり簡易なものです。きめ細やかなアクセスコントロールをするにはIAMの概念に準じた仕組みを検討するのがよいかなと思います。 単純に、自分だけで利用するか、他者に共有するかを制御するだけであれば、こういった簡易な作りで十分試せるでしょう。
プロンプトを再利用可能にする
プリセットの作成や更新は単純なCRUDなのでここでは割愛します。作成したプリセットをチャットセッションで呼び出せるようにすれば、プロンプトを簡単に再利用できるようになります。
Dev Geniusでは、チャットのセッション開始時にプリセットのタグ一覧を表示し、ワンタッチでセットできるようにしています。
システムプロンプト、モデル、temperatureをワンタッチで切り替える
システムプロンプトの内容は固定にはせず、プリセットを利用する場合でもいつでもエディット可能にしています。プリセットをチューニングしたい場合のトライアンドエラーを簡単にするためです。
プロンプトを再利用する価値
プロンプトを再利用すると、生成AIに対して特定のコンテキストを簡単に与えることができ、より的確な応答を得やすくなります。その結果、利用者は最初から目的に沿ったコミュニケーションを取ることができます。
例えば汎用的なシステムプロンプトで会話する場合、TypeScriptでいくつかのフィールドを持つclassを宣言したいとすると、TypeScriptでid, name, emailを持つclassを宣言したいといった形で指示することになります。
あんまり普段TypeScriptでclassを宣言することないなと思ったり
id, name, emailを持つclassといった曖昧な表現だと、以下のようにモデルの解釈に依存した出力になります。
LLMモデルはPython得意がち
一方、特定のタスクや状況に最適化されたプロンプトを再利用すれば、事前にコンテキストを生成AIに提供できるため、ユーザーはより簡潔な指示で済むようになります。
適当に書いても割とよしなにしてくれる
示した例は簡潔なものですが、より業務に特化した内容や、専門知識が必要なものなどに関するプロンプトをあらかじめプリセット化していくことで、生成AIとの対話量を減らしつつ成果物を最大化できます。
プロンプトを共有する
プロンプトの再利用は強力ですが、個人用に留まっている間は効果は限定的です。チームや組織内で共有することで、業務プロセスにインパクトのあるプリセットの構築が可能になります。実際にUbieにおいて業務プロセスに組み込まれているようなプリセットは見せられないので、専門領域に特化したプリセットを一部紹介します。
以下はヤコブ・ニールセンの10ヒューリスティックスとして知られるユーザビリティ原則に基づいたレビューを行うプリセットを用いて、画面のレビューを行ってもらった例です。デザイナーのメンバーが作ってくれました。画面キャプチャでのレビューなので、必ずしも正確なフィードバックが得られるわけではありませんが、示唆を得られることは多いです。
| 画面のキャプチャ | レビュー結果 |
|---|---|
 |
 |
次の例では、GithubのPull Requestの差分を使ってコードレビューをしています。
セルフレビューとしてこれを用いることで、人間によるレビューの負担を減らせます。チャットで行っているので、このままユニットテストの提案や、QAテスト計画についても相談できます。
会話からプリセットを生成する
プリセットは便利ですが、プリセットを作り出すのは簡単ではありません。そこで、チャット内容に基づいてシステムプロンプトを生成する機能を設けています。
以下は、KPTのまとめを行ったチャットの会話履歴から、プリセットを作成する様子です。
Structured Outputsの仕組みを用いて、以下の様なデータ構造を生成AIに出力してもらっています。これによって生成結果を使ってフォームの各項目を埋めています。
import { z } from "zod";
export const presetMagicSchema = z
.object({
title: z.string().describe("プリセットの名前"),
systemPrompt: z.string().describe("システムプロンプト"),
guidance: z.string().describe("システムプロンプトの使い方"),
})
.describe("システムプロンプト作成のスキーマ");
このほか、システムプロンプトを最適化するプリセットなどもあり、より効果的な出力を得るための支援機能を整えています。
まとめ
プロンプトの再利用は、生成AIを効果的に活用する上で重要な要素です。適切なプロンプトを使うことで、生成AIとのコミュニケーションの質が向上し、より良い成果物を効率的に作成できるようになります。自前で作る場合も、アクセスコントロール以外の部分はシンプルなので、比較的簡単に実現できるのではないかと思います。
Discussion