会場の様子

ビッグサイト

東京ビッグサイト！

文字通りビッグですね！

私自身、東京に住んでいた時期にお台場には良く遊びに行っていたのですが、ビッグサイトへは今回が初でこの段階で結構テンションが上がっていました！

さらに、コロナが明けてこう言った完全現地参加型のイベントへ参加したことが久しぶりだったこともあり、ちょっと感慨深かったです。。。

ホール

画像は4つのホールがありその中でホール1と呼ばれる、入口から一番近い会場になります。

ここでは、Microsoftを始めFIXER、Intel、SoftBank、Accenture/Avanadeの5社の企業ブースに加えて、画像中左右両端にはTheaterという形で2つのセッションが行われていました！

所々デスクも用意されており、セッションにて得た知見をまとめたり実践している方々も！

Techなイベントという感じがひしひしと伝わってきました！

セッションについて

こちらのリンクから当日行われたセッションの一覧がみれます。

ホール4つ、さらに1つのホールで2~4つのセッションが行われており、全部で77つのセッションが行われていました！（どのセッションを見るか、前日まで結構悩みました。。。）

LLMを使ったテキスト抽出

朝から夕方までさまざまなセッションに参加させていただきましたが、その中で面白いと感じたセッションがありましたので今回はそのセッション内容の紹介をいたします！（ようやくタイトルの内容に触れます！）

GPT-3.5による大規模なテキストデータ変換を200並列のバッチ処理で実施した話 / Implementing Large-Scale Data Transformation with GPT-3.5

まずタイトルで惹きつけられました。 （なんか強そう）

セッションの様子

当日のセッションの様子です！

周りにはたくさんの参加者が集まり、僕を含め席に座れず立って聴講する人も多数いました！

また、登壇されているかたがザ・エンジニアという感じで勝手ではありますが親近感が湧いたのと、発表内容の至る所でエンジニアがよく苦労する事象を熱弁されていてとても面白かったです！！

セッションの内容

さて、具体的な内容に触れていきます。

概要

このセッションでは、

「共通求人票フォーマット」を作成し、リクルートの多種多様な求人サイトに対してまとめて掲載できるようにする

という要件のもと、これまでさまざまな求人サイトに登録されてきたデータを共通フォーマットに落とし込み、サイト間でデータ連携ができるようにしましょう！というものをどう解決したかという内容でした。

ただこの内容だけをみると簡単に聞こえますが（ここの時点ですでに頭を抱える人もいますが）、背景には、、、

• 「掲載数No.1」と宣伝するほど大量にデータを持っている
• 昔からあるサービスで、フリーペーパーの時代から存在しており、そのデータをWebに再現する過程でサイト間の互換性を考えず変換されてきた（はず）
• 自由記述で入力されたデータが本当に自由に入力されている！！
• こう言った案件に限って納期が結構厳しい！！！

上記のような条件が存在しています。。。

もう、考えるだけで頭が痛いですね、、、

「自由記述されたデータを、共通フォーマットに落とし込む」これだけで頭が割れそうなくらいですが、その上で「昔からある」ということで「大量のデータ」「フリーペーパーから取り込んだ古い型式のデータもある」という絶望、、、

さらに、太文字にしていますが、ここがエンジニアあるあるだなぁと感じた、「納期が厳しい！！！」という点。

頭が爆発してしまいますね！！

課題

ちょっと画質が荒くてすみませんが、共通化する前のデータの一例です。

（本番データはもっと酷かったらしいです、、、）

• 「職種」の欄なのに、「キレイなオフィス」という職種と関係ない文言。そもそも「職種」に3つも書かれている。
• 給与では「時給」と「月給」が混ざっている。
• 勤務時間が結構柔軟なものから、週休とい勤務時間ではなく休暇の情報だったり、時間をゼロ埋めして2桁にしていたりゼロ埋めしていなかったりという表記揺れがあったり。

ツッコミどころがたくさんありますね！

これだけ自由に記述されているデータを共通フォーマットに起こすなんて、、、

こう言った作業においては、正規表現を駆使してテキストの抽出を行うのが一般的かと思いますが、これらのテキストをうまく抽出する正規表現を考えるのは無理ですよね！（禿げます）

解決方法

そこで！

LLMを利用して適切なテキストの抽出を実現！！

当時最新かつ、まだLLMが利用できるPaaSサービスが少ない中唯一の選択肢であったAzure OpenAI Serviceを用いて、GPT-3.5に求人票の中から適切な表現がされているテキストを抽出するよう指示したプロンプトで制御していました。

しかし、「LLM使ったらうまくできました〜」では終わりません。

「大量のデータ」「納期が厳しい」この条件を満たすには、LLM利用のPaaSサービスにおいては結構厳しいらしく、

• 性能的な問題
  • 1分間に捌くことのできるアクセス・token量に制約がある
  • 一般的なAPIに比べてレスポンスも遅い
• コスト的な問題
  • token量に比例して費用が発生する（従量課金）

上記の問題点から、要件に見合わない可能性や費用対効果が得にくい懸念があります。

その懸念を解決（緩和）した方法として、契約を従量課金ではなくPTU（プロビジョニング スループット ユニット）という単位にすることです。

PTUにすることのメリットとして、デプロイした際にあらかじめ必要なスループットが確保できるようにモデルの処理容量を割り当ててくれることです。

自然言語処理を行うにあたって必要なリソースがごっそり割当たった状態で利用可能になるということですね！

これにより

• 利用可能なリソースを確保した状態なので、パフォーマンスの予測が可能
• フルパフォーマンスで利用した場合、従量課金よりも安く済む（コスト削減が可能）
  • かつ、従量課金では予測が困難だが、PTU単位で課金されるため、コスト予測が容易になる

最終的にこのPTUという単位で300PTU契約を行い、画像にある通り、1分間に捌けるリクエスト数が約1500、並列実行数が200となり、処理性能としては要件を満たすことができました。

さらに、料金に関しても当時であれば従量課金よりもだいぶ安く済んだとのことです！！

こうやって、事前に大規模かつ速度がほしいとわかっている要件に対しては従量課金よりもPTUという契約形態を選ぶ判断を行なっていくことが案件のコストパフォーマンスを上げていく上で大切ですね！！

実装関連

自由奔放に書かれていたテキストデータから共通フォーマットの内容に適したテキストの抽出を行う、かつコスト的な問題を300PTU契約したことで解決したのはわかりました！

ではどんな構成だったのでしょうか？

ありがたいことにざっくりとではありますが、アーキテクチャについても解説してくださいました！

こちらもだいぶ荒い画像ですが、、、

一番左からAzure、真ん中がGCP、右にAWSと3つのパブリッククラウドを駆使してシステムを構築したそうです！！

納期が短いことから、新しくAzure上で構築していくよりも早くできる、かつ、Azure OpenAI Service自体がREST APIの形で利用でき、IP制限もかけれるのでAzure上でシステムを完結させないといけない制約もなかったのでそれぞれのクラウドサービスを利用する形となったそうです！

それぞれの役割は下記の通りとなります。

• AWS
  • CloudWatchを使用してDataFlowの処理を監視
  • 組織の運用ルール上AWSの利用となった
• GCP
  • 求人データがBigQueryにある
  • そのため主なデータ処理を行うロジックはDataFlow上に載せており、ここからAzure OpenAI Serviceにテキストデータの抽出をリクエスト
  • 使用言語はPython
• Azure
  • OpenAI Serviceのみ使用
  • IP制限の設定が可能なので、DataFlowからのアクセスのみ許可

目的や用途に沿ってクラウドサービスを使い分けるエンジニア、かっこいいですね！！

まとめ

• 表現の幅が広いテキストデータにおいて、特定の表現に当てはまるテキストの抽出において、LLM（Azure OpenAI Service）を利用して本来なら莫大な時間がかかる抽出作業の短縮・コスト削減をおこなった。
  • ただし、人間の行う作業が全て自動化されたわけではなく、あくまでの原案提案にLLMを使用。
  • LLMによって抽出された共通フォーマットの沿ったデータは職安法の観点からも、再度人間の目によってチェック工程が存在している。（あくまでもLLMはサポート。本来人間が人数と時間をかけてやらないといけない作業の短縮。）
    • 「職安法の観点」→元々書かれていた内容を書き換えてはいけない。
• LLMを利用するにあたって、従来の利用形態だとパフォーマンスやコストに問題があったがPTUという契約形態にすることで安定したパフォーマンスとコスト削減を実現した。
  • ただし、何でもかんでもPTUにしたらいいわけではない。ちゃんと要件に沿って都度従量課金がいいのかPTUの方がいいのかを見極めるべき。
• Azure OpenAI Serviceを利用するからと言って、その他のシステムの基盤を含めてAzureフルマネージドで構築する必要はない。
  • Azure OpenAI Service自体がREST APIで利用可能、かつ、IP制限などあるため、他クラウドサービス上にあるサービスから呼び出すユースケースでも容易に組み込める。

セッションに参加してみての個人的な感想

自然言語処理に特化した生成AIの活用例として、ChatGPTとても有名です。

そのためか僕自身も、チャット型式（対話型）で利用されることばかり思い浮かんでしまいますが、今回このセッションを聞いてみて、自然言語処理が必要なパターンはむしろシステム上の方が多いということに気付かされました。

固定概念に囚われた利用ばかりではなく、エンジニアとして常にクリエイティブに技術を捉えていきたいなと改めて思います。

また、今回のLLMの利用についても、LLMが出した結果をそのまま使うのではなく、あくまでもサポートとし、最終的には人間のチェックを入れるということ、さらに、講演内容の最後に他のイベントの紹介で、「LLMによって既存機能を補う話」という宣伝もあり、やはり生成AIは人間の作業を奪うのではなく補っていく方向で使うのが強いのだと感じました。

このセッションに関わらず、Microsoft AI Tour全体を通して、生成AIは「Copilot」副操縦士であるというのが強調されていたかと思いました。

AIのことからは外れてしまいますが、個人的に自分が開発していく上で意識を変えないといけないと感じたことがあります。

一つは、「ちゃんとコストパフォーマンスを考えて設計する」ということです。

今回のこのセッションではタイトルだけを見ると「300PTU契約してパワー増し増しでやってやったぜ！」という印象になりがちですが、内容を聞いているとよく費用対効果や金額的なコスト、学習にかかるコストなど考えられていて、エンジニアの基本としてしっかり認識を改めないといけないなと感じました。

もちろん、コスト度外視で開発をしてきたわけではありませんが、最近の開発において理想の動きができればいいという考えが大半を占めていてコストパフォーマンスについて考えることが疎かになっていたと思わされました。

二つ目に、「クラウドサービスを自由に選択できる魅力」についてです。

弊社はAzureのサービスを利用することが多く、ただ、最近ではAWSも多く利用するようになりました。

それでも、「まずはAzure」という考え方が僕個人としては抜けきれていません。

今回のセッション内容におけるシステム構築において、「監視はAWS、主なデータ操作・管理はGCP、LLM利用するのにちょうどいいからAzureのサービス」とクラウドサービスにとらわれず、利用しやすいもの、既にあるものを選択して学習コストを低減させることができているのはとても魅力的だと感じました。

Azureを基本に考えてしまっているとなかなかこう言った柔軟な対応・発想はできないと感じたので、クラウドサービスにとらわれず、さまざまなサービスから取捨選択しより良い方法を提案できるようになりたいと思いました。

以上、個人的な感想となります。

冒頭でも言及していますが、久しぶりの現地参加でのイベント、やはり直接会場に行きその場の雰囲気も楽しみながら技術に触れるというのはとてもいい機会だと思いました。

これからどんどんこう言った機会が増えて行くかと思うので、毎回逃すことなくキャッチアップしていけたらと思います！！