Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
プロンプトエンジニアリングでがんばらない-Agentic Workflow へ-近藤憲児
Search
Kenji KONDO
April 24, 2024
Technology
4.8k
6
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
プロンプトエンジニアリングでがんばらない-Agentic Workflow へ-近藤憲児
Kenji KONDO
April 24, 2024
More Decks by Kenji KONDO
See All by Kenji KONDO
「AI倫理」以前_近藤憲児
kenjikondobai
1
86
AI_Agent_の作り方_近藤憲児
kenjikondobai
19
7.9k
なぜ今 AI Agent なのか _近藤憲児
kenjikondobai
4
7.1k
「これが最小になる値はな〜んだ?」問題_最適化問題を考える_近藤憲児
kenjikondobai
0
300
AI ChatBot 開発 Tips-近藤憲児
kenjikondobai
0
290
最適ワークスとAI-近藤憲児
kenjikondobai
0
120
LLMの評価-近藤憲児
kenjikondobai
1
500
スカイディスクの LLM の取り組み-近藤憲児
kenjikondobai
0
400
Spring Cloud Data Flow で構成される IIJ IoTサービス
kenjikondobai
0
480
Other Decks in Technology
See All in Technology
【ゲームメーカーズスクランブル2026】『Shadowverse: Worlds Beyond』UIとアニメーションで実現する最高のユーザー体験を叶えるプロトタイピング
cygames
PRO
1
710
インバスケット試験対策アプリを 作って見えたAIエージェント構築 ナレッジ2選
shichijoyuhi
1
110
Codex概要
ymiya55
0
190
【データ横丁主催】AI Agentがコンテキストを使って仕事をした後、何が残るのか― 組織の経験を次の判断に引き継ぐ「Agent Memory」
shisyu_gaku
2
310
Claude Designがめちゃくちゃ便利なので使ってほしい
diggymo
0
190
認知負荷を吸収し、プロダクトをまたぐPR Preview基盤の設計事例
taiki45
2
570
ログラスのマルチプロダクトを 支える認証基盤 〜テナントごとに異なる統制とどう向き合うか〜
dada4386
3
310
[2026 Oracle Technical Deep Dive] エンタープライズAIエージェントを支えるOCIソリューション。ラインナップと特徴を理解しよう! (2026年9月17日開催)
oracle4engineer
PRO
0
160
私の推しは「聞いてから進む」AIです -AI-DLCに一人でアプリを作らせた話
yama3133
1
160
大阪オフィスに Unitree Go2 がやってきたので Physical AI やってみた
dafujii
0
220
AI臭い文章とは何なのか
nasuvitz
38
76k
OpenClawでAzure DevOpsのWiki更新を自動化する - クラウドAIだけでは届かない場所へ
yutakaosada
0
140
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
225
10k
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
74
42k
The Pragmatic Product Professional
lauravandoore
37
7.5k
Into the Great Unknown - MozCon
thekraken
41
2.7k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
HDC tutorial
michielstock
2
930
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.6k
Building a Scalable Design System with Sketch
lauravandoore
464
34k
Typedesign – Prime Four
hannesfritz
42
3.2k
VelocityConf: Rendering Performance Case Studies
addyosmani
331
25k
Transcript
プロンプトエンジニアリングで がんばらない − Agentic Workflow へ −
- LLM アプリの品質(出力の安定性、速度など)を上げる手段として、 プロンプトエンジニアリング以外の手段があるということ - この手段に隣接した領域として Agentic Workflow と呼ばれるデザインパター ンがあること
- さわりだけご紹介 今日お伝えしたいこと
「Discord で雑に共有された記事をなんでも要約する」自作アプリ • YouTube の動画 • arXiv の論文 •
SpeakerDeck のスライド • Web 上の記事 • … “Summarize Anything”
• Router で何の要約を求められているかを判断 • 判断に基づいて、専用の Summarizer に要約を任せる “Summarize Anything” のアーキテクチャ
Router YouTube Summarizer Web Summarizer arXiv Summarizer どの Summarizer に 委譲すべきかを判断 … ページに アクセスして本 文を取得して 要約 委譲
Router でやりたいこと • そもそも要約を必要とする文章 なのかを判断する • URL の文字列を抽出 • その
URL が YouTube なのか arXiv なのかの判断 • これら結果を JSON として出力 させる(以下はその例) Router の実装(昔) { "summary_required": true, "url": "https://arxiv.org/pdf/2402.05120.pdf", "method": "arXiv" }
問題 • 品質が全然安定しない。体感 3 割失敗 する ◦ JSON の所定のフォーマットになら ない
◦ URL があるのにそれを抽出しない ◦ … → プロンプトエンジニアリングを頑張ったが、 すぐに限界を感じた Router の実装(昔)
処理を分けた Router の実装(今) URL 抽出 URL から委 譲先を 選択 →
動作が劇的に安定した。ほぼ 100 % 間違わない。 URL の文字列 “論文 https://arxiv.org…” “arXiv” Router
さらに LLM の性能を落 とした Router の実装(今) URL 抽出 URL から委
譲先を 選択 → 品質に変化なし。むしろ速度上がるし、コスト下がるしで、嬉しい Router gpt-4 → gpt-3.5-turbo gpt-4 → gpt-3.5-turbo
• 「zero-shot で巧妙にプロンプトエンジニアリングをして頑張る」よりも「命令をシン プルにしたタスクを多量に LLM に依頼する」ほうがよい • 「zero-shot で gpt-4
や claude-3-opus のような賢い LLM を使う」よりも 「gpt-3.5-turbo や claude-3-haiku のような賢くないけど軽量でコスト低い LLM を 細かく使う」ほうが、品質も速度もコストも満足いく この手法は普遍性があるな、と思っていた。 他にも例えば、要約した文章が日本語じゃなかったり、制約条件をちゃんと守っていなかったりした ときも、もう一度 LLM を call してそれを添削してもらう、ということをすると、およそ満足の行く品質 で安定して出力された。 あと、自然とモジュール化の考え方になっているので、それぞれのモジュール別に改善やテストな どがやりやすい。 「LLM を call しまくる」という戦略
“Agentic Workflow” 単なる経験則に過ぎなかったけども、最近 Andrew Ng がまさにこれに関連したこ とを言っている動画を見つけた そこでは Agentic Workflow
という名前で、 LLM アプリの性能を上げる方法を説明 していた
“Agentic Workflow” 「エッセイをバックスペース無しではじめから最後まで間違えの無いように書いて」と 依頼するよりも、「アウトラインを抽出して」「それに対してドラフトを書いて」「それを 添削して」... と分けて依頼するアイディア https://youtu.be/sal78ACtGTc?si=vFpxwR47DoNaQqiz
“Agentic Workflow” zero-shot の GPT-4 よりもAgentic Workflow を適用し た GPT-3.5
のほうが良い評価を得ている。 https://youtu.be/sal78ACtGTc?si=vFpxwR47DoNaQqiz 上の 4 つのデザインパターンについて述べられてい る。 → Agentic Workflow や Agent については、今いろいろ実装して試している(そして苦労し ている)。役に立ちそうなこと見つけたら、また共有します!