はじめに
こんにちは！データサイエンスグループの田代真生です。2023/6/26 ~ 6/29にData + AI Summit 2023が開催されました。弊社でも利用しているApache Sparkの開発に関する知見を獲得することや、LLMに関する開発の最新動向を追うことを目的に、データサイエンスグループの二見と田代が参加したため、各発表で興味を持った内容について紹介しようと思います。
参加レポート
Day1(06/28)
Data + AI Summit Keynote, Day 1
今回のカンファレンスのテーマの一つとして生成AIやLLMの存在が挙げられます。ChatGPTやStable Diffusionなどの生成AIによってDataやAIの活用方法が変化していく中で、Databricks社がどのようにData、AIの活用方法を考えているのか、そしてそれをどのように実現しようとしているのか、という内容が話されました。
今回のKeynoteで繰り返し使われていたのが「民主化」というキーワードです。インターネットがwebブラウザによって民主化されて流行したように、AIも生成モデルによって民主化されて流行しました。そのためDatabricks社はDataとAIをより民主化することが重要だと考えていると発表していました。
Dataを民主化するための手段としては、英語でデータにアクセスできるLakehouse IQを発表していました。これは社内のさまざまな形式のデータを集約し、その中に含まれるドメイン知識を基に英語からSQLを叩けるようにしたサービスです。今まではSQLを使えないとデータにアクセスすることができませんでしたが、これを使うことによってほぼ全ての人がデータにアクセスできるようになり、データの民主化が達成されます。「The hottest new programming language is English」という発言は印象深く、今後の開発のトレンドを考える上で示唆的であったと感じました。
AIを民主化するための手段としては、MosaicMLの買収とLakehouse AIを紹介していました。AIを民主化するためには各企業が各々のデータで各々のAIモデルを作ることが重要であり、その際に重要となるコストに対する知見を多く持っているMosaicMLを買収することにより、各企業に対して低コストで自前のAIモデルを作成する方法を提供できるようになると考えているそうです。また、Lakehouse AIによって各企業はAIモデルの学習からdeployまでのend2endの流れの詳細を知らずとも、自前のAIモデルを利用できるようになります。「Your AI built on your data is what will set you apart」というコメントは印象的であり、自前のデータをLLMなどによっていかにして生かすかということが今後のAI活用において重要なことの一つであることを再認識しました。
Testing Generative AI Models: What You Need to Know
本セッションではLLMのリスクとそれに対応するために必要なモデルの評価・テストについて語られました。
LLMモデルのリスクとしては「Operational Risk」「Ethical Risk」「Security Risk」の3つが挙げられます。
「Operational Risk」はhallucinationと呼ばれるでっちあげの回答をしてしまうことや、LLMが入力のテンプレートの些細な変化に過敏に反応してしまうことを指しています。「Ethical Risk」は倫理的に問題のある出力をすることを指しており、注意しないとLLMが暴力的や政治的、性的な出力をしてしまうことを問題視しています。「Security Risk」はより危険なリスクであり、秘密の情報がLLMを通じて外部に漏れてしまうことや、悪意のあるPromptによってLLMが開発者の想定と異なる動きをさせられてしまうことなどが含まれます。このようなリスクに対して必要な対策として「Pre-production Validation」「Real-time Validation」「Post-production Validation」によって構成される、"継続的な評価"というものを紹介していました。
現状データサイエンスグループでは生成AIを用いた施策は実施していないものの、今後の展望として考えているため、生成AIを運用する上でのリスク管理に関するまとまった知識は有用であると感じました。
How to Build LLMs on Your Company's Data While on a Budget
本セッションでは検索システムとしてLLMを使う例を取り上げながら、LLMに理想的な挙動をさせるためにどのような手順を踏んでいくかを説明していました。大きく分けると、Fine-tuningせずに調整をしていく段階とFine-tuningをして調整をしていく段階の2段階を取ると良いことが紹介されていました。
Fine-tuningせずに調整をしていく段階に関しては検索システムから関連文書を抽出する方法についてのノウハウや、LLMの生成パラメータのtuningの方法などを紹介しており、Fine-tuningしていく段階に関してはメモリや時間の効率が良いFine-tuningのノウハウとして、バッチサイズの決め方やLoRA/PEETを用いたTuningの方法などを紹介していました。
Fine-tuningをせずに試していく段階とFine-tuningを調整していく段階に分けていく考え方は、LLMが対象の課題に対してどこまで上手く機能するかわからない際に、小さく失敗しながら実験できるという点で重要な考え方だと感じました。
Day2(06/29)
Data + AI Summit Keynote, Day 2
ここではDatabricks社が開発をしているOSSのApache SparkやDelta Lakeのアップデート周りの発表が多くされました。特にApache Sparkはデータサイエンスグループでも利用しているため、興味深い発表が多かったように思います。
Apache Spark 3.4の紹介としては主に「Spark Connect」「Pysparkのアップデート」「English SDK for Apache Spark」などが取り上げられていました。Spark Connectはクライアントとサーバーを分離することで、任意のクライアントからSparkを実行できるというものです。これによって自分のIDEで対話的にSparkに関する開発ができるようになるほか、さまざまな言語でのSpark SDKの開発が容易になるそうです。PysparkのアップデートではPysparkのAuto Complete機能の改善やTest機能の改善、UDTFに関するアップデートがありました。UDTFに関してはデータサイエンスグループでもbatch処理に関する複雑な関数を書くことがあり、書きにくさを感じていたため有難いアップデートであると感じました。English SDK for Apache Sparkは1日目のkeynoteでも発表があったLakehouse IQのように、PysparkのSQLクエリを英語で書くことができる機能です。データの民主化を進める画期的な機能であると感じました。
そのほかにもMosaicMLの共同創設者のMichael Carbin氏らのパネルトークでは研究の分野でのAIの興味・課題などが話されており、Small curated DataにおけるMLの話は大変興味深かったです。
Explainable Data Drift for NLP
本セッションではテキストデータにおけるデータドリフトを検出する方法を3つ提示した上で、それぞれにおけるメリットとデメリットについて考えました。データドリフトとは機械学習モデルの入力のデータの性質・分布が時間の経過によって変化することを指しており、機械学習エンジニアは機械学習モデルの精度を保つためにデータドリフトに対応する必要があります。
本セッションではテキストデータにおけるデータドリフト検出手法として、1. メタデータを使うもの 2. 属性を使うもの 3. Embeddingを使うものの3つが紹介されていました。メタデータはテキストの作られた日付やソースなどを指しており、ほかと比べて明確であるものの、テキストの中身を指していないという点や常に利用可能でないという点で欠点があります。テキストの属性はテキストの長さや名詞の数、トピックなどを指しており、説明可能性が高く、観測している属性に関するデータドリフトを検出できるという点で利点があるものの、属性の抽出における正確性やデータドリフト検出のカバレッジに関して課題があります。Embeddingはデータドリフトを検出する力が高いものの、説明可能性という観点で課題があります。そのため、一長一短のデータドリフト検出手法を組み合わせたモニタリング基盤を作成し、データドリフトに応じてデータドリフトの影響を減らした学習を行ったり、データドリフトに適応する形での学習を行ったりすることが重要であると締められていました。
弊グループでも扱っているデータのドリフトに関しては常にモニタリングをしているものの、テキストの質の変化については追えていない部分もあるためモニタリングの観点として参考になりました。
De-Risking Language Models for Faster Adoption
本セッションではLLMの出力におけるリスクを軽減するための方法を考えました。1日目の「Testing Generative AI Models: What You Need to Know」がシステム設計、運用的な視点であったのに対し、本セッションはガバナンスの観点や詳細なリスクの対策を考えている違いがあります。
数多くの対策が紹介されていましたが、その中のいくつかを紹介すると、AIインシデントデータベースを研究してデバッグの指針とすること、バイアスに関する公開ツールやベンチマークを利用すること、反実仮想やロールプレイングなどの方法で作られた敵対的Promptを用いた対策、開発者以外のステークホルダーからのフィードバックを基にした改善などが挙げられていました。LLMの利点として柔軟な入力に対応可能であるというものがある一方で、敵対的なPromptのバリエーションも幅広いため、敵対的なPromptの発見は開発者の思いつきだけでは追い付かないことを強く感じました。
Key Insights From Running LLMs in Production From MLOps.Community
本セッションはLLMに関する開発のサーベイ結果をもとにLLMの応用先や運用における課題をまとめたものです。LLMの応用先としてはチャットボットが最も多く、検索、要約、テキスト生成が続いて多い結果でした。
個人的に興味深いと思った応用先として、データの生成が紹介されていました。LLMによって生成されたデータを用いることでコストを抑えながらデータラベリングができるため機械学習のPoCが進めやすくなるのではないかと感じました。LLMの運用に関する課題としては「LLMの出力に関する問題」「コスト」「インフラ」「Prompt」「不確実性」の5つが挙げられており、特にPromptとコストの課題が印象に残りました。Promptに関しては個人的に学生時代の研究でも触れており、LLMのPromptに対する過敏さは扱いづらい特性として感じていたため、Promptをどう扱うかを考えるのは重要であると感じました。またコストに関しては、LLMが大量の計算コストを必要とするため何も考えずに学習、利用しようとすると膨大な料金が必要となることが考えられます。そのため、本セッションでも強調されていた、「Does the high cost actually have an ROI?」という考え方は重要であると感じました。
おわりに
参加したセッションに関するレポートや感想はいかがだったでしょうか？
今回の会議ではLLMに関する話題が多く、LLMに対する熱の高まりを感じるとともに、LLMを使った施策を考えている私たちデータサイエンスグループにとって有用な知見を多く得ることができました。
DMMでは国内外カンファレンスへの参加を支援する「カンファレンス参加支援制度」があり、若手でも熱意があればカンファレンスに参加するチャンスがあるのはありがたい環境だと感じました。
最後にDMM データサイエンスグループでは一緒に働いてくれる仲間を募集しています！またDMMの雰囲気を感じつつ成長できるようなエンジニア向けのインターンシップも用意しています！ご興味のある方は、ぜひ下記の募集ページをご確認ください！
