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
950
社内LLMハッカソン2024発表資料
Kasai Kou
June 18, 2024
Tweet
Share
More Decks by Kasai Kou
See All by Kasai Kou
ひとりぐらしになってからかわったこと - ゆるゆるりとして、けれども楽しく忙殺される日々
streamwest1629
1
250
Dev Containers ことはじめ - 失敗から学ぶ開発環境運用法
streamwest1629
0
19k
布教Git
streamwest1629
0
2k
はじめてのTerraform
streamwest1629
0
370
かさいさんの旅路
streamwest1629
0
160
今年の総括とコミュニティ
streamwest1629
0
97
クリーンアーキわからんかった人のためのオニオンアーキテクチャ
streamwest1629
1
33k
Other Decks in Technology
See All in Technology
OCI Network Firewall 概要
oracle4engineer
PRO
1
7.8k
コンテキストエンジニアリングとは? 考え方と応用方法
findy_eventslides
4
900
stupid jj tricks
indirect
0
8k
Function calling機能をPLaMo2に実装するには / PFN LLMセミナー
pfn
PRO
0
940
生成AIを活用したZennの取り組み事例
ryosukeigarashi
0
200
多野優介
tanoyusuke
1
440
Optuna DashboardにおけるPLaMo2連携機能の紹介 / PFN LLM セミナー
pfn
PRO
1
890
SOC2取得の全体像
shonansurvivors
1
390
Oracle Cloud Infrastructure:2025年9月度サービス・アップデート
oracle4engineer
PRO
0
440
「AI駆動PO」を考えてみる - 作る速さから価値のスループットへ:検査・適応で未来を開発 / AI-driven product owner. scrummat2025
yosuke_nagai
4
600
英語は話せません!それでも海外チームと信頼関係を作るため、対話を重ねた2ヶ月間のまなび
niioka_97
0
120
SREとソフトウェア開発者の合同チームはどのようにS3のコストを削減したか?
muziyoshiz
1
100
Featured
See All Featured
Facilitating Awesome Meetings
lara
56
6.6k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
It's Worth the Effort
3n
187
28k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
BBQ
matthewcrist
89
9.8k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
Mobile First: as difficult as doing things right
swwweet
224
10k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Speed Design
sergeychernyshev
32
1.1k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
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