Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
社内LLMハッカソン2024発表資料
Search
Kasai Kou
June 18, 2024
Technology
0
540
社内LLMハッカソン2024発表資料
Kasai Kou
June 18, 2024
Tweet
Share
More Decks by Kasai Kou
See All by Kasai Kou
ひとりぐらしになってからかわったこと - ゆるゆるりとして、けれども楽しく忙殺される日々
streamwest1629
1
100
Dev Containers ことはじめ - 失敗から学ぶ開発環境運用法
streamwest1629
0
19k
布教Git
streamwest1629
0
1.6k
はじめてのTerraform
streamwest1629
0
270
かさいさんの旅路
streamwest1629
0
130
今年の総括とコミュニティ
streamwest1629
0
79
クリーンアーキわからんかった人のためのオニオンアーキテクチャ
streamwest1629
1
30k
Other Decks in Technology
See All in Technology
入社半年(合計1年)でGoogle Cloud 認定を全冠した秘訣🤫
risatube
1
270
WSUSが非推奨に!? Windowsの更新管理を改めて勉強する!
ebibibi
0
550
Japan AWS Jr. Championsがお届けする、アウトプットのすすめ
hamijay_cloud
0
190
太田博三(@usagisan2020)
otanet
0
140
From naive to advanced RAG: the complete guide
glaforge
0
620
MobileActOsaka_241018.pdf
akaitadaaki
0
100
本番のトラフィック量でHudiを検証して見えてきた課題
joker1007
2
240
外部カンファレンスで登壇しよう! 〜「強い」エンジニアへの一歩を踏み出す〜
logica0419
4
130
AWS DDKを利用したDataOps事始め
beex
1
160
なぜ Rack を理解すべきかプレトーク / Why should you understand Rack - Pre-talk
hogelog
0
220
Amazon ECS & AWS Fargate 今昔物語 / past and present stories of Amazon ECS and AWS Fargate
iselegant
18
3.8k
管理画面とユーザー機能の調和を取り戻す!~クエリパフォーマンス改善の成功物語~ / Restore harmony between administrative and user functions!
minisera
1
190
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Designing for Performance
lara
604
68k
How STYLIGHT went responsive
nonsquared
95
5.1k
Designing for humans not robots
tammielis
249
25k
How GitHub (no longer) Works
holman
311
140k
Build The Right Thing And Hit Your Dates
maggiecrowley
32
2.3k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.2k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
5
130
Producing Creativity
orderedlist
PRO
341
39k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Transcript
「素人質問で恐縮ですが。。。」 発表資料(公開版) 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