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

Transcript

1. LLMとPlaywrightで実現す る非定型なデータの収集
2. 自己紹介 名前・所属 山室友樹(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)
3. Agenda 弊社で抱えていた課題 開発内容 LLMでのPoC開発のTIPS
4. 弊社で抱えていた課題
5. こんなサイト見たことありませんか？
6. いわゆるアフィリエイトサイト S 広告主を新たに掲載していただいたり獲得強化施策を実 施していただきながら広告主のKPIを達成できるように努 力してい) S データ分# S ユーザー属! S 行動デー$ S 　 　 　 →特徴量を増やすためにこれを取得したい 環境データ
7. 広告主の掲載順位を知りたい！ e 検索結果であればahrefsやSemrushがあu e 前a e 一般的に上位に表示されている方が獲得数が多v e 制T e 数１００にもなるWebサイトを案件の担当者が全て調 べることはできなv e 各WebサイトでHTML構造が違う・随時変更されるの で従来のスクレイピングでは機械的に取得できなかっ た
8. 開発内容
9. 全体構成
10. 意識したこと x PoC開発として大きく下記の３点は意識しP x LLMOpsが回せるような構成にする（人が介入し、継続的に精度向上を目指せる構成 x 上記をエンジニアでなくとも触れる最小構成を目指3 x 定常的な利用費用が発生しないこと
11. 意識したこと ‚ PoC開発として大きく下記の３点は意識しS ‚ LLMOpsが回せるような構成にする（人が介入し、継続的に精度向上を目指せる構成# ‚ エンジニアでなくとも触れる最小構成を目指す 　 　 　 　 → ‚ 定常的な利用費用が発生しないこと 　 　 　 　 → SpreadSheetをUI代わりとして利用す– Serverlessな環境（CloudRun）
12. ランキングサイト判定
13. ランキングサイト判定 — 比較サイトと単一記事があu — 「比較サイトならランキングを出して」というプロンプトの正答率が低かったため、ランキン グサイト判定するプロンプトと分割し‰ — それでもなお、正答率が良くなかったので人力チェックのFlag管理をできるようにした 　 → 精度を上げるために時間を使うよりはオペレーションを作ってまずは検証
14. 名寄せ処理
15. とあるメディアでの実際のデータ
16. とあるメディアでの実際のデータ 「レバウェル看護派遣」と「レバウェル看護」は 別物
 「看護師ワーカー(旧医療ワーカー)」と「看護師 ワーカー」は同一
17. LLMでのPoC開発(Gemini) のTIPS
18. 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
19. Flashを利用するようにしたら継続可能なお値段に ・約１００サイトのクローリングで利用しているが一回300円弱く らい ・システムとしては高いが人よりは安い ・不要なJSをカットすればもう少し安くできそう
20. 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
21. 制約の緩和方法がModelによって違う j gemini-1.5-flash-00p j 上限緩和の申請が必h j gemini-1.5-flash-00 j 動的共有クオータが適用され利用容量に応じて拡張されu j 指数バックオフアルゴリズムを利用したRetryを行t j 安定的に運用するためにはProvisionedThroughputを購入する必要がある
22. TIPS3: 画像の大きさに制限はないが圧縮される „ Webサイトのような縦長の画像だと圧縮されてしまうので文字の読み取り精度がかなり悪く なs „ 一方でVertexAIを利用すると 384 ピクセルより大きい場合、画像はタイルに切り取られる Gemini API Vertex AI API
23. TIPSまとめ h Gemini APIの無料枠で収まるのであればそれでPoCするのが良さそ8 h 一方で利用頻度が高いような処理になりそうであればVertex AIを利用した方が価格面でも周 辺処理の機能面でも便Q h Retry処理は忘れずに
24. ご清聴ありがとうございました