Tweet
Tweet

Slide 1

Slide 1 text

LLMとPlaywrightで実現す る非定型なデータの収集

Slide 2

Slide 2 text

自己紹介 名前・所属 山室友樹(Yuki Yamamuro)
 株式会社Macbee Planet・MOps Group 経歴 マーケティングデータ活h q データ基V q ReverseETQ q 広告運h q LLMを利用したPoC 好きなRaycast機能 q Snippet“ q VS Code拡張(Search Recent Project)

Slide 3

Slide 3 text

Agenda 弊社で抱えていた課題 開発内容 LLMでのPoC開発のTIPS

Slide 4

Slide 4 text

弊社で抱えていた課題

Slide 5

Slide 5 text

こんなサイト見たことありませんか？

Slide 6

Slide 6 text

いわゆるアフィリエイトサイト S 広告主を新たに掲載していただいたり獲得強化施策を実 施していただきながら広告主のKPIを達成できるように努 力してい) S データ分# S ユーザー属! S 行動デー$ S 　 　 　 →特徴量を増やすためにこれを取得したい 環境データ

Slide 7

Slide 7 text

広告主の掲載順位を知りたい！ e 検索結果であればahrefsやSemrushがあu e 前a e 一般的に上位に表示されている方が獲得数が多v e 制T e 数１００にもなるWebサイトを案件の担当者が全て調 べることはできなv e 各WebサイトでHTML構造が違う・随時変更されるの で従来のスクレイピングでは機械的に取得できなかっ た

Slide 8

Slide 8 text

開発内容

Slide 9

Slide 9 text

全体構成

Slide 10

Slide 10 text

意識したこと x PoC開発として大きく下記の３点は意識しP x LLMOpsが回せるような構成にする（人が介入し、継続的に精度向上を目指せる構成 x 上記をエンジニアでなくとも触れる最小構成を目指3 x 定常的な利用費用が発生しないこと

Slide 11

Slide 11 text

意識したこと ‚ PoC開発として大きく下記の３点は意識しS ‚ LLMOpsが回せるような構成にする（人が介入し、継続的に精度向上を目指せる構成# ‚ エンジニアでなくとも触れる最小構成を目指す 　 　 　 　 → ‚ 定常的な利用費用が発生しないこと 　 　 　 　 → SpreadSheetをUI代わりとして利用す– Serverlessな環境（CloudRun）

Slide 12

Slide 12 text

ランキングサイト判定

Slide 13

Slide 13 text

ランキングサイト判定 — 比較サイトと単一記事があu — 「比較サイトならランキングを出して」というプロンプトの正答率が低かったため、ランキン グサイト判定するプロンプトと分割し‰ — それでもなお、正答率が良くなかったので人力チェックのFlag管理をできるようにした 　 → 精度を上げるために時間を使うよりはオペレーションを作ってまずは検証

Slide 14

Slide 14 text

名寄せ処理

Slide 15

Slide 15 text

とあるメディアでの実際のデータ

Slide 16

Slide 16 text

とあるメディアでの実際のデータ 「レバウェル看護派遣」と「レバウェル看護」は 別物
 「看護師ワーカー(旧医療ワーカー)」と「看護師 ワーカー」は同一

Slide 17

Slide 17 text

LLMでのPoC開発(Gemini) のTIPS

Slide 18

Slide 18 text

TIPS1: 請求金額には気をつけよう v Gemini Proとflashでは結構価格差があˆ v 気軽にローカルから利用したら一撃で13,000円分もクレジットを消G v 価格はどんどん安くなるので未来を信じて最高機能を使う方が良いとの話もあるが業務効率化 などの文脈では使わない方が無難か` v 当時Jsonモードに対応しているのはProのみだった（現在はFlashも対応） https://ai.google.dev/gemini-api/docs/structured- output?lang=node#supply-schema-in-config

Slide 19

Slide 19 text

Flashを利用するようにしたら継続可能なお値段に ・約１００サイトのクローリングで利用しているが一回300円弱く らい ・システムとしては高いが人よりは安い ・不要なJSをカットすればもう少し安くできそう

Slide 20

Slide 20 text

TIPS2: Gemini APIとVertexAIなどそれぞれ違った制約がある Rate Limit 課金対象 GeminiAPI(無料) 15 RPM（リクエスト / 分） 100 万 TPM（1 分あたりのトークン数） 1,500 RPD（1 日あたりのリクエスト数） 無料 GeminiAPI(有料) 2,000 RPM（1 分あたりのリクエスト 数） 400 万 TPM（1 分あたりのトークン数） 入力：100 万 あたり $0.075 トーク ン Vertex AI（flash) 200 RPM(us-central1)
 400 万 TPM 入力：1000 あた り$0.00001875 文字 文字はUTF-8のコードポイントでカウント https://cloud.google.com/vertex-ai/generative-ai/pricing

Slide 21

Slide 21 text

制約の緩和方法がModelによって違う j gemini-1.5-flash-00p j 上限緩和の申請が必h j gemini-1.5-flash-00 j 動的共有クオータが適用され利用容量に応じて拡張されu j 指数バックオフアルゴリズムを利用したRetryを行t j 安定的に運用するためにはProvisionedThroughputを購入する必要がある

Slide 22

Slide 22 text

TIPS3: 画像の大きさに制限はないが圧縮される „ Webサイトのような縦長の画像だと圧縮されてしまうので文字の読み取り精度がかなり悪く なs „ 一方でVertexAIを利用すると 384 ピクセルより大きい場合、画像はタイルに切り取られる Gemini API Vertex AI API

Slide 23

Slide 23 text

TIPSまとめ h Gemini APIの無料枠で収まるのであればそれでPoCするのが良さそ8 h 一方で利用頻度が高いような処理になりそうであればVertex AIを利用した方が価格面でも周 辺処理の機能面でも便Q h Retry処理は忘れずに

Slide 24

Slide 24 text

ご清聴ありがとうございました