契約書からの情報抽出を行うLLMのスループットを、バッチ処理を用いて最大40%改善した話

■ イベント
自社で育てるLLM/VLM/VLA：学習・活用の実践知
https://sansan.connpass.com/event/383788/

■ 発表者
技術本部 研究開発部 Data Analysisグループ
齋藤 慎一朗

■ 技術本部 採用情報
https://media.sansan-engineering.com

Transcript

1. Sansan株式会社 技術本部 研究開発部 齋藤 慎⼀朗 契約書からの情報抽出を⾏うLLMのスループットを、 バッチ処理を⽤いて最⼤40%改善した話 ⾃社で育てるLLM/VLM/VLA：学習・活⽤の実践知
2. 齋藤 慎⼀朗 Sansan株式会社 技術本部 研究開発部 シニアリサーチャー - 業務 - ファインチューニングしたLLMによるプロダクト 改善をリード - 趣味 - Kaggle（2x Master) - ランニング（サブ5.5） - 書籍 - Kaggleではじめる⼤規模⾔語モデル⼊⾨ - Polarsとpandasで学ぶ データ処理アイデアレシピ55 @sinchir0 X(旧Twitter)
3. - この発表で伝えたいこと - 背景 - Contract Oneとは - Contract Oneに対する研究開発部の取り組み - Lalamoとは - Lalamoの要件 - 問題：タイムアウトエラーが発⽣している - 改善の進め⽅ - 処理ごとの時間を計測し、ボトルネックを特定する - 改善すべき指標を決める - 改善策を決める - 改善策が有効か検証する > 実装⽅針 > 実験設定 > 実験結果 - 改善策をリリースし、効果を測定する - 学んだこと アジェンダ
4. 1. 課題に直結する指標を選ぶことが重要である 2. 技術の仕組みを知っていると、適切な改善策を思いつくことがある この発表で伝えたいこと
5. - Sansan株式会社が提供するサービスの⼀つにContract Oneがある - Contract Oneの機能の⼀つに、契約書を⾼い精度で期⽇までにデータ化 する機能がある。 - データ化: 契約書から、契約先名、契約書名、契約締結⽇、契約終了⽇と いった主要な9項⽬を抽出する。 - ⾼い精度でのデータ化は、⼈の⼊⼒と⾃動化エンジンによる⼊⼒の 組み合わせで実現している 背景：Contract Oneとは
6. 背景：Contract Oneに対する研究開発部の取り組み - 研究開発部は、データ化の精度・期⽇を守りながら、 ⾃動化エンジンが⼈の⼊⼒を代替する割合（⾃動化率）を⾼めることに よるコスト削減を⾏う
7. 背景：Lalamoとは - Contract One向けにファインチューニングしたLLMを⽤いたエンジンを Lalamoと呼ぶ - 使⽤モデル：tokyotech-llm/Swallow-7b-instruct-v0.1 - 推論エンジン：vLLM
8. - Contract Oneからリクエストを受けたら、15分以内に結果を返す必要が ある 背景：Lalamoの要件 15分以内 データ化結果 SQS Contract One ワーカ(vLLM) 処理 S3 k8s データ化 リクエスト キューを取得 契約書データを取得 Lalamo Contract OneとLalamoの処理のシーケンス図
9. - Lalamoが15分以内に結果を返せないことがある - 15分以内に結果を返せないとタイムアウトエラーとなり、 ⼈がデータ化する必要が⽣じる - つまり、⾃動化率の低下につながる 問題：タイムアウトエラーが発⽣している タイムアウトエラーの件数
10. 1. 処理時間を計測する 2. 改善すべき指標を決める 3. 改善策を決める 4. 改善策が有効か検証する 1. 実装⽅針 2. 実験設定 3. 実験結果 5. 改善策をリリースし、効果を測定する 改善の進め⽅
11. - 計測ツールであるOpenTelemetryを⽤いて、1契約書あたりの処理時間を 計測・可視化 - 結果として、１契約書に対して処理時間が約5秒かかっていることが判明 ステップ1：処理時間を計測する OpenTelemetryを用いて可視化した、1契約書あたりのLalamoの処理時間の１例 契約書データを取得 プロンプトを作成 vLLMによる推論 後処理など
12. どういった指標を改善すれば良いか？ - タイムアウトエラーは、以下の条件を満たした場合に発⽣する。 「キューでの待ち時間」+「実際の推論時間」> 15分 - 「実際の推論時間」は、約5秒である。 - よって、タイムアウトエラーは「キューでの待ち時間」が⻑いことが原因である。 - 「キューでの待ち時間」を短くするためには、1秒あたりに処理できるリクエスト 件数（スループット）を改善し、キューの滞留を解消する必要がある。 - ⼀⽅、スループットが改善する前提において、1リクエストを受けてから結果が返 るまでの時間（レイテンシ）は、改善・悪化のいずれも許容される。 ステップ2：改善すべき指標を決める
13. - レイテンシ、スループットは必ずしも同時に改善しない 閑話休題：レイテンシとスループットの違い 指標 定義 レイテンシ 1リクエストを受けてから結果が返るまでの時間 スループット 1秒あたりに処理できるリクエスト件数 レイテンシとスループットの定義
14. - レイテンシは悪化するがスループットは改善する例として、バッチ処理がある。 - バッチ処理は、複数リクエストをまとめて推論することで GPU効率が上がりスループットは改善するが、 バッチ内の他リクエストの完了を待つためレイテンシは悪化しうる。 閑話休題：レイテンシは悪化するがスループットは改善する例 時間 バッチ処理 なし バッチ処理 あり リクエスト１ |▪| リクエスト２ |▪| リクエスト３ |▪| リクエスト１ |▪▪| リクエスト２ |▪▪| リクエスト３ |▪▪| リクエストごとの処理時間は⻑くなる、つまりレイテンシは悪化する 同じ時間でより多くのリクエストを処理できる、 つまりスループットは改善する バッチ処理の有無における、複数リクエストの処理に必要な時間の違いのイメージ図 ▪ : 処理に要する時間単位
15. - 次のような⼿法が考えられる。 - デメリットのうち、費⽤はなるべく増やしたくない。また、 ⾃動化率は悪化させたくない。⼀⽅、レイテンシの悪化は許容できる。 - よって「バッチ処理を⾏う」を選択する。 ステップ3：改善策を決める ⼿法 メリット デメリット 処理するワーカの 台数を増やす スループットが改善する 費⽤が増える モデルを⼩さく する レイテンシ・スループットともに 改善する モデルの精度が悪化するため、 ⾃動化率も悪化する バッチ処理を⾏う スループットが改善する レイテンシが悪化する
16. リクエスト１ - vLLMには Paged Attention の仕組みが実装されている - Paged Attention はバッチ処理時の無駄を削減し、GPU利⽤効率を⾼める - よって、今回の事例においても、バッチ処理の導⼊により、GPU利⽤効 率が改善することが期待される 閑話休題：vLLMはバッチ処理時の無駄を削減する Paged Attentionなし Paged Attentionあり トークン トークン Paged Attentionの有無によるGPU利⽤効率の違いのイメージ図 GPUメモリ の無駄 リクエスト２ リクエスト３ リクエスト４
17. - ワーカの処理を、1件ずつ→N件（最⼩1・最⼤10） まとめて処理するように変更する。 ステップ4-1：改善策が有効か検証する 実装⽅針 ワーカの処理 変更前 変更後 キューを取得 1件 N件 契約書データを取得 1件 N件 プロンプトを作成 1件 N件 vLLMによる推論 1件 N件 結果をContract Oneに返却 1件 N件 バッチ処理による 改善が期待される
18. 本番リリース前に、開発環境にて効果があるかどうかの実験を⾏った。 - ⼿法 - バッチ処理なし - バッチ処理あり - 利⽤する契約書データ - ⼀般的な⻑さ（約4,000トークン） - モデルの最⼤⼊⼒⻑に近いもの（約8,000トークン） - シナリオ - 通常時：1秒に1リクエスト - キュー滞留時：100件を⼀括投⼊ - 計測指標 - スループット（req/sec）：⾼いほど良い - 平均レイテンシ（sec/件）：低いほど良い ステップ4-2：改善策が有効か検証する 実験設定
19. ステップ4-3：改善策が有効か検証する 実験結果 スループット - スループット（⾼いほど良い） 全シナリオでスループット改善。特にキュー滞留時に最⼤約40%改善。 シナリオ 契約書 バッチ処理なしで のスループット （req/sec） バッチ処理ありで のスループット （req/sec） 改善割合 通常時 ⼀般的な⻑さ 0.324 0.327 +0.9% 通常時 最⼤⼊⼒⻑に近いもの 0.188 0.210 +11.8% キュー滞留時 ⼀般的な⻑さ 0.310 0.443 +42.7% キュー滞留時 最⼤⼊⼒⻑に近いもの 0.196 0.240 +22.5%
20. ステップ4-3：改善策が有効か検証する 実験結果 平均レイテンシ - 平均レイテンシ（低いほど良い） - 通常時、かつ⼀般的な⻑さの契約書の場合のみレイテンシが悪化した。 これは、リクエストが少ない状況においてはバッチ処理の恩恵が⼩さいが、バッチ 処理を実現するための処理時間が増えるためと考える。 - 今回は、スループットが改善していれば問題なく、レイテンシの悪化は許容する。 シナリオ 契約書 バッチ処理なしでの レイテンシ（sec/件） バッチ処理ありでの レイテンシ（sec/件） 改善割合 通常時 ⼀般的な⻑さ 12.6s 32.3s -156% 通常時 最⼤⼊⼒⻑に近いもの 213s 192s +9.9% キュー滞留時 ⼀般的な⻑さ 163s 114s +29.9% キュー滞留時 最⼤⼊⼒⻑に近いもの 258s 211s +18.4%
21. - バッチ処理を本番環境にリリース - タイムアウトエラーが 平均137件/⽇ → 平均50件/⽇に削減 - 削減率：約64% ステップ5：改善策をリリースし、効果を測定する タイムアウトエラーの件数 リリース
22. 1. 課題に直結する指標を選ぶことが重要 - もし、レイテンシを改善しなければいけない、と思い込んでいた場合、コス ト、⾃動化率が悪化する⽅法を選択する可能性があった - ⼀⽅、今回はスループットを改善すべきと判断できたため、コスト、⾃動化 率を悪化させない⼿法を選択できた 2. 技術の仕組みを知っていると、適切な改善策が思いつく - vLLMのPaged Attentionはバッチ推論時にGPU利⽤効率が改善する - その特性を活かし、1件ずつの処理からバッチ推論に変更することで スループットが改善し、タイムアウトエラーが削減した 学んだこと
23. Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/