生成AIプロジェクトに取り組むデータエンジニアが直面するさまざまなリスク――そして見返り

生成AIモデルに与えるデータをどうするかは、企業にとって優先度の高い問題だ。生成AIを新たな用途に活用することで企業革新も大きく進むことになりそうだが、それがうまくいくかどうかはデータエンジニアリング次第で決まる。

というのも、生成AIモデルというのはデータに飢えているだからだ。

多くの企業に当てはまることだが、今後の競争で優位に立てるかどうかは、生成AIモデルや機械学習モデルを活用するうえで、既存の社内データ資産を使ったデータラングリングがうまくいくかどうかによるところが大きい。そうしたデータはハイパースケーラーが提供するクラウドに置いてあることもある。

AIの場合、与えるデータは高品質なものでなければならない。正確で関連性があり、タイムリーで、適切に変換済みで、十分な量がなくてはならないのだ。ただでさえ計算の新たなパラダイムの習得に追われているデータサイエンティストやデータエンジニアにとって、プレッシャーになる部分でもある。

多くのデータエンジニアはすでにこうした進展を追いかけてきたとも言える。生成AIのデータエンジニアリングとは、これまでに自然言語処理やレコメンドエンジンの分野で起こったブレークスルーを基にしたものだからだ。

ビッグデータの時代―生成AIに道を開いた過去のイノベーション

ビッグデータ分野では、NoSQL、Spark、Hadoopといった革新的な技術が登場し、今ではおなじみとなっている。険しい道のりではあったが、企業データ分析で大量の非構造化データを扱えるようになった。生成AIは多様なデータセットを使った訓練やファインチューニングによって良いものになるため、こうした蓄積が役に立つ可能性がある。

データウェアハウスやデータレイク、データレイクハウスは従来のリレーショナルデータ処理の領域を超えて発展し、次世代のオープンソースツールが数多く生まれた。何かしら解決すべき課題がある時は、探せばApacheソフトウェア財団から適切なアプリケーションが提供されていると言ってもいいかもしれない。

ビッグデータ分野で起こった革新の例としては、データカタログによる情報分類とメタデータの追加、ワークフローオーケストレーションによるデータパイプライン構築などもある。最近登場したベクトルデータベースでは、多くの生成AIで中核となっているLLM（大規模言語モデル）が特有の保存と取り出しに関するニーズを扱える。

一方、第一線のデータエンジニアにしてみれば、こうしたものに対応できなくてはならないということでもある。最新のツールボックスの使い方を覚えるようなもので、そうした学習はすぐには終わらない。計算の新しいパラダイムに移行するということは、機械学習モデルに関して業務に取り組みながら学んでいくということだ。機械学習モデルは思いがけない結果を返したり、毎日のように変化したりする。GPUで実行するのが普通だが、GPUは動作の仕方が独特で（処理コストもかかる）、多くの人にとって経験したことのないものだ。

生成AIを活用し成功させるにはデータとモデルの両方が必要になっている。

AIがもたらす、データエンジニアリングの新たな課題

ゴールドマン・サックスやIBMで経験を積んだベテランのデータエンジニアで、現在はGitHubのオープンソースプロジェクト「DataSurface」を統括しているBilly Newport（ビリー・ニューポート）氏が所見を述べた。データエンジニアリングの基本原則は変わらないが、AIパイプラインの構築には今までにない課題が伴うという。

生成AIを利用する場合、企業データをシステムで扱える形式に変換することが多い。これは重要な手順で、あらゆるデータ統合におなじみの手順でもあるが、ここではベクトル埋め込みというひとひねりが加わる。Newport氏がSDxCentralの取材に応え、概要を説明した。

生成AIは基本的に数値を扱う。テキストや画像など、他の形式の企業データをAIに渡すには、数値ベクトル（埋め込み）に変換するのが最適だ。

近年、ベクトルデータベースへの関心が高まり、リレーショナル型などのさまざまなデータベースがベクトルデータに関する拡張機能を提供しているのにはそうした背景がある。ベクトルデータを扱うことが、いまやデータエンジニアの監督する作業工程の一部となった。

クレジットカードの識別情報など、「AIにとって無意味な」取引データを使用に適した状態に変換するところが課題になるとしている。

「データの移動に関しても同じことが言えます」と氏。「AIでもレポーティングでも、他の目的に使用する場合でも、データを移動させるのは同じです。違うのは、パイプラインの最後で埋め込みに変換してベクトルデータベースに入れるのか、財務報告などを目的とした特殊なデータベースに入れるのか、というところだけです。パイプラインの最後にあるデータベースの種類は用途によって変わってきます」

「1つで何にでも対応できるようなデータベースは存在しません」と氏。「そういうものではないのです」

これまでになかった新しいデータ型への対応が必要になるのは珍しいことでもなくなった。とはいえ、生成AIのLLMにはなじみのない特有の落とし穴がある。さまざまな新しい開発フレームワークが絶えずアップデートされ、学習も継続的に行われている状況だ。

データエンジニアが生成AI向けのデータを用意しようとすると、LLMにデータを与える際の手法が独特であることに気づく。ここを理解すると処理コストを抑えることが可能だ。コストというのは今でもアプリケーション測定で使用する主要パラメータの1つになっている。

Newport氏の説明によると、AI用のデータパイプラインでは、取り込まれたデータはコンテキストに分割されるという。コンテキストとは、要は小さな情報の塊をトークンで表現したものだ。

「コンテキストウィンドウのサイズ（訳注：一度に扱えるトークンの最大数）は使用している開発フレームワークによって異なることがあります」と氏。「処理コストに直接影響する要素です」

エンドユーザーが大手クラウドで「標準的なLLM」をホストして使用している場合であっても、処理コストは高くなりうることがわかっている。

生成AIデータエンジニアリングにまつわるムーンショット

今日の生成AIと、機械学習の初期の事例（感情分析への活用）について、Xebiaのデータ部門で主席コンサルタントを務めるGuillermo Sanchez Dionis（ギリェルモ・サンチェス・ディオニス）氏が対比している。生成AIモデルの方がはるかに複雑で、扱うには膨大な計算能力とエンジニアリングの知識が必要になるのだという。SDxCentralの取材で語った。

ほとんどの使用者にとって、独自のモデルを構築することは難しい。「ムーンショット（月へのロケット打ち上げ）」のようなものだ。

「昨今、非常によく見られることですが、たとえば、ある銀行に何かの格付けに使う監査ルールがあるとします。その数が500とか600とか、もしかするとそれ以上あって、本のような状態になっているのです」と氏。「大変な量の文字情報です」

担当するチームはその内容をベクトル検索ができるデータベースに入れてインデックスを張り、それを使ってOpenAIのChatGPTやGoogle Geminiのような既存モデルにコンテキストを与えるのだという。

「モデルにコンテキストデータを与える際は、このように混合型のアプローチを取ります」

その時に高品質なデータが不足していると、成功への大きな障害になる可能性がある。特に、品質に関してはっきりした定義を持たない非構造化データの場合に起こりがちだ。

JSONのような半構造化データが問題になることもあるという。基盤のデータ構造が時間の経過とともに変化することがあるためだ。非構造化データの品質はユースケースしだいという傾向にある。

生成AIに使用する半構造化データ、非構造化データについては、データ品質に関する明確なルールを定める取り組みを継続的に行うのが良いという。参考にしてほしいと語った。

GPUの面倒を見るということ

ビッグデータの顕著な特徴は、多種多様かつ大量で、速度を必要とする点だ。生成AIの作成においては、こうした特性が大いに注意すべき問題となるという。AI作成のためのオープンソースインテグレーションに特化したコンサルティングを提供している米Derwenのマネージングパートナー、Paco Nathan（パコ・ネイサン）氏がSDxCentralの取材で語った。

「訓練中やファインチューニング、RAG（検索拡張生成）のどこかでAIアプリケーションに不正確なデータが入ったり、推論中に様々な形態のインジェクション攻撃を受けたりした場合のリスクは、飽和を超えて過熱状態になっています」

一方で、優れたデータエンジニアリングの恩恵には素晴らしいものがある。氏によると、資金をかけられないチームが数百万ドル規模の取り組みよりも優れた成果を上げている事例はいくつもあるという。補助的な合成データセットを注意深く作成し、効率よくAIモデルに与えた結果だと説明した。

重要なのが、GPUハードウェアによる新たなパラダイムの登場に伴い、リスクも生じているという点だ。現在、LLM分野ではGPUを使用するのが主流になっているが、実行時に問題が発生した場合にさまざまな分野のエンジニアチームで切り分けをしなくてはならないこともある。データエンジニアもこうしたハードウェア問題に対する感覚を養う必要があるのかもしれない。生成AIモデルがGPUでどのように実行されるのか、訓練時のGPUパフォーマンスを最適化する手法なども含め、ある程度は理解していた方がよい。

「ディープラーニングの訓練で問題が起こると、たいていGPUが静かに停止します」と氏。たとえば、複数のGPUによる処理の集約がうまくいかず、そのプロセスでエラーが発生した場合だ。Nathan氏によると、GPUの相互接続に関しては、現在のシステムが抱えているこの明らかな弱点を解決することを意図した進展が今後に控えているという。

ある時点でニューラルネットワークの結果を集約する必要が生じるということは、Nathan氏が言うように、「にわかにネットワークエンジニアリングで扱う問題になってしまう」ということでもある。

ディープラーニングの不具合というのはもともと、デバッグが困難になりうるものだ。後工程に進むまで顕在化しないケースもあり、そうなると原因を特定するのは骨の折れる作業になる。ソフトウェア開発の世界では起きたことのないような責任の所在探しが始まり、データエンジニアが指をさされることもあるだろう。生成AIの計算リソースは非常に高価であるため、追及は厳しいものになるかもしれない。

「人々は今、このような認識をしています。”うわ、私が担当しているこのクラスターは1日分のコストが私の年収よりも高いのか。もし私がミスをしたら、ボスは誰か他の人を雇おうと言うだろうな”」

速やかな適応を迫られるデータエンジニア

生成AIによる革新の最前線にいるのがデータエンジニアだが、彼らにとってもまったく新しい世界だ。基本的な原則に変わりはないが、いくらか様相が変わるような変化が始まっている。

「機械学習を実運用する時代になりましたが、データエンジニアリングチームが力を発揮するために知っておくべき大事なことがひとつあります。大規模モデルには（他のモデルとは）異なるライフサイクル、異なるリスクがあるということです」とNathan氏は言う。

2020年頃には標準的だった手順や段取りも、今日ではおそらくうまく機能しないだろう、と氏。データエンジニアは「好奇心を持ち、何が必要とされているのか、特に何が発展しているかを学び、適応していく」ようにと強く勧めている。

「データエンジニアリングを成熟させていく必要があります」とNewport氏。「コアプラットフォームのエンジニアリング職と、プラットフォームを基にさまざまなユースケースが構築され、そこに個々のエンジニアが従事するケースとに分かれていくでしょう」

Newport氏はこうした考え方を背景に、DataSurfaceプロジェクトに取り組んでいる。目的としているのは、「個々のタスクのためにパイプラインを作成する」という従来の機械的な作業をエンジニアの業務からなくすことだ。

「皆で車輪の再発明をするようなことは望ましくないでしょう」と語った。

Dionis氏によると、データエンジニアの果たす役割は今後も重要性を増していくという。また、新たな課題がある中で、今も結果を出せる基本的なルールを挙げた。生成AIの使用に関わる場合、データエンジニアは以下を行う必要がある。

・データ変換ロジックの単体テストを実施する。
・継続的インテグレーションによって非破壊的な変更ができるようにする。
・データリネージを把握する。その際、データ資産間の依存関係に対応できるツールを選ぶ。

「モデルに合った適切なデータがなければ、そのモデルがどれだけ優れていたとしても、期待するような結果を得ることはできません」と氏。

データエンジニアの役割は今後も大きくなっていきそうだ。データプラットフォームエンジニアによってパイプライン構築の自動化が進んだとしても、それは変わらない。また、機械学習エンジニアと情報交換しながら協働していく必要もある。生成AIモデルに関わるすべてに最も密接に関わっているエンジニアであるためで、この先新しいタイプのAIモデルが登場した時にも同じことが言えるだろう。

GenAI raises the stakes for data engineering