「素人質問で恐縮ですが。。。」
 発表資料（公開版）
 
 2024年LLMハッカソン チーム完全プレゼン主義 presents
 
 2024.06.06 1 SERVERSIDE ENGINEER KASAI KOU GitHub: kasaikou Twitter: streamwest1629

2 目次
 1. プロダクトとしての背景/機能 
 2. 技術的側面
 2.1. フロントエンド/サーバーサイド 
 2.2. 使用した AWS サービス 
 2.3. LLM 周り
 物理シミュレーション 燃焼工学 切削加工 パワー半導体 （発表者かさいの学部卒業審査時のイメージ図） 深層学習

プロダクトとしての背景 /機能
 「なんで作ろうと思ったんですか？」
 「結局プロダクトとして何ができるんです か？」
 3

Q. スライドを作りながら
 想定質問、考えますか？
 1 プロダクトとしての背景/機能
 4

1 プロダクトとしての背景/機能
 スライド準備
 「これだけしっかり説明したら 大丈夫でしょう？」
 「このスライドならこんな質問 とんできそうだな〜」 
 いざ発表
 「発表緊張するけどスライド しっかりまとめたからやりやす いね」
 質問タイム
 「（想定外な角度で質問され た、どうするのこれ？）」 
 「（その質問ワタシに聞かれて も困りますが？）」
 みんなこれを回避したい 5

1 プロダクトとしての背景/機能
 人は発表資料を作る間に
 想定質問を考えたがる生き物である
 But
 想定質問が当たるとは限らず、
 意図的に「穴」を作っても質問者がそこにはまるとは限らない
 6

Q: 想定質問を考えるにあたり何が必要か？
 A: 質問者の持っている知識
 
 質問者は自分が理解できるように自分が持っている知識（種類・質）をベースに質問をする 
 とはいえ、自分には専門外だったりするので質問者ごとに質問を予測するのは難しい 
 1 プロダクトとしての背景/機能
 物理シミュレーション 燃焼工学 切削加工 パワー半導体 （発表者かさいの学部卒業審査時のイメージ図） 深層学習 7

1 プロダクトとしての背景/機能
 LLM に質問者の知識をシミュレートしてもらって
 想定質問をもらおう
 今回開発したのは質問者の知識を設定してそこから考えられる想定質問をもらうサービスです
 8

1 プロダクトとしての背景/機能
 想定質問者（ペルソナ）を作成してシミュレート
 知識の種類と度合いを指定して想定質問者を作成できます
 9

1 プロダクトとしての背景/機能
 録音した音声データからテキストデータを書き起こし
 発表原稿の書き起こしがつらい方向けにテキストデータを音声原稿から作成します
 （コピペもできるよ）
 10

技術的側面
 「このプロダクトを作るために何を使ったん ですか？」
 11

フロントエンド/
 　　サーバーサイド
 「それぞれ何で実装したんですか？」
 「その間はどうやって通信しているんです か？」
 12

3.1 技術的側面 - フロントエンド/サーバーサイド
 それぞれ似たような選定をした
 特殊なことはやっていない
 フロントエンド
 ● next.js (TS) で実装 
 ● S3 バケットに配置して CSR で動かすことを 想定
 サーバーサイド
 ● nest.js (TS) で実装 
 ● Docker コンテナ上で動かすことを想定 
 GraphQL を用いて通信を行う 13

使用したAWSサービス
 「このサービスを作るためになんのサービ スを使ったんですか？」
 14

3.2 技術的側面 - 使用したAWSサービス
 全体構成図
 us-east-1 リージョンに展開 Terraform でリソース管理を行った 15

3.2 技術的側面 - 使用したAWSサービス
 フロントエンドは S3 + CloudFront 構成 16

3.2 技術的側面 - 使用したAWSサービス
 サーバーは ECS on Fargate + ALB 構成 デプロイは ecspresso を使用 Fargate を Public Subnet に置きつつもVPC 内か らの inbound のみに絞るセキュリティグループを引 いたため、 ECR へアクセスするための VPC Endpoint を使用した ecspresso: https://github.com/kayac/ecspresso 17

LLM 周り
 「LLM を使うにあたって工夫したことはな いんですか？」
 18

コンセプト
 「ユーザーに『 LLM を使っている』を感 じさせない」
 3. LLM 周り
 19

3. LLM 周り
 ● 1つのスライドに対して複数の想定質問・レビューが飛んでくる
 ● 持っている知識が違う複数のアイデンティティがある
 20

3.2 技術的側面 - LLM 周り
 Amazon Bedrock を使用
 Amazon Bedrock の claude 3 haiku を使用 
 ● 現状スループットが最速
 ● このために展開先リージョンが us-east-1 になっている
 ● 東京リージョンでの利用可能待ってます！
 
 YAML による出力を指示 
 ● ある程度構造化することで1回のリクエストで複数の 要求を行うことができる
 ● YAML オブジェクトの指定時に文章の指示を入れる ことで指示内容に対して忠実になる
 ● エスケープシーケンスなどのフォーマット特有の考慮 もれが JSON よりも少ない
 21

3.2 技術的側面 - LLM 周り
 次のような YAML 形式でレビュー及び想定質問を提案してください。 questions: - | （ペルソナが持っているスキル）から考えられる150字程度の質問 - | （ペルソナが持っているスキル）から考えられる150字程度の質問 review: - | 発表原稿に対する 200 字程度のレビュー 指示に使用しているプロンプト（抜粋） 22

補足資料
 23

(補足資料) 今回のプレゼンについての想定質問
 24 ※ 実際の質問はご想像におまかせします

(補足資料) 使用したAWSサービスの選定理由
 使ってみたかったサービスを使いました
 「特にバックエンドとか Lambda で十分な のはそうなんだけど、案件じゃないから最 悪失敗してもダメージ少ないし、普段できま すアピールしつつも実際に使った訳じゃな いサービスを使っておきたかった」 25