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
1.1k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
社内LLMハッカソン2024発表資料
Kasai Kou
June 18, 2024
More Decks by Kasai Kou
See All by Kasai Kou
ひとりぐらしになってからかわったこと - ゆるゆるりとして、けれども楽しく忙殺される日々
streamwest1629
1
320
Dev Containers ことはじめ - 失敗から学ぶ開発環境運用法
streamwest1629
0
19k
布教Git
streamwest1629
0
2.1k
はじめてのTerraform
streamwest1629
0
420
かさいさんの旅路
streamwest1629
0
180
今年の総括とコミュニティ
streamwest1629
0
130
クリーンアーキわからんかった人のためのオニオンアーキテクチャ
streamwest1629
1
35k
Other Decks in Technology
See All in Technology
Terraform共通モジュールをチーム横断で“変えられる”運用へ ― リリースと適用の分離
kekke_n
1
2.8k
型は壁、Rustでもバグを直すな、表現できなくせよ
nwiizo
13
2k
GuardrailからGovernanceへ~AIエージェント運用の次の課題~
sbspsy
2
270
脱金融のフューチャー・デザイン / Future Design Beyond Finance
ks91
PRO
0
150
オブザーバビリティ、本当に活用できてる? 〜API連携×生成AIで成熟度を自動評価〜
dmmsre
1
3k
End-to-Endで考える信頼性 —LINEアプリにおけるクライアント開発×SRE連携の実践
maruloop
4
4.1k
【Claude Code】鹿野さんに聞く 私の推しの並行開発環境 大公開 / claude-code-parallel-2026-07-15
tonkotsuboy_com
10
6.7k
インフラと開発の垣根を超えていき!〜元AWSインフラエンジニアがAWS開発で奮闘している話〜
hatahata021
1
160
関数型の考えを TypeScript に持ち込んで、テストしやすい純粋関数を増やす / Pure at the Core, Effects at the Edge: Bringing Functional Thinking into TypeScript
kaminashi
1
110
ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略
srenext
0
140
AI時代の開発生産性は、個人技からチーム設計へ
moongift
PRO
2
170
AIレビューはどこまで任せられるのか?自動化と人が背負うレビューの境界
sansantech
PRO
2
720
Featured
See All Featured
A designer walks into a library…
pauljervisheath
211
24k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
55k
Side Projects
sachag
455
43k
Making Projects Easy
brettharned
120
6.7k
Building AI with AI
inesmontani
PRO
1
1.1k
What the history of the web can teach us about the future of AI
inesmontani
PRO
1
630
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2k
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
920
Code Reviewing Like a Champion
maltzj
528
40k
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
260
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.8k
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