AIはETLの再発明に時間を浪費する必要はない

AIはETLの再発明の時間浪費を不要にする

AIの最近の進歩は非常に興奮しています。人々はそれをさまざまな新しい方法で使用しており、顧客サポートの体験の向上やコードの作成と実行、新しい音楽の作成、さらには医療画像技術の高速化などに利用されています。

しかし、その過程で心配な傾向が現れています。AIコミュニティはデータの移動（ELTとも呼ばれる）を再発明しているようです。コネクタ、エクストラクタ、統合、ドキュメントローダーなど、人々は同じコードを書き、同じAPI、ドキュメント形式、データベースからデータを抽出し、それをベクトルDBやインデックスにロードしてLLM（Language Model）用に使用しています。

問題は、堅牢な抽出とロードパイプラインをゼロから構築し、維持することは非常に大きな負担です。この分野にはこれまで多くの先行事例が存在しており、ほとんどのエンジニアや企業にとっては再構築することは時間の無駄です。毎時新しい情報が発表される空間では、主な焦点はユーザーのために自社のコア製品を信じられないほど素晴らしいものにすることであり、余分なクエストに時間を費やすべきではありません。そして、ほとんどの場合、コア製品はデータの移動ではなく、AIで魔法のように動くソースです。

堅牢な抽出、変換、ロード（ETL）パイプラインの構築に関する課題については、多くのことが書かれていますが、AIの文脈でそれを考えましょう。

• 「データサイエンスの熱狂者にとっての必聴ポッドキャスト10選」
• 2023年の練習のためのトップ18のPower BIプロジェクトアイデア
• 「ChatGPTのようなLLMの背後にある概念についての直感を構築する-パート1-ニューラルネットワーク、トランスフォーマ、事前学習、およびファインチューニング」

なぜAIはデータの移動が必要なのか？

公開データでトレーニングされたLLMは素晴らしいですが、もっと良いのは、私たち、私たちの会社、私たちのユーザーに特化した質問に答えることができるAIです。ChatGPTが私たちの会社のウィキ、メール、Slackメッセージ、会議のメモ、トランスクリプトをすべて学習し、私たちの会社の分析環境に接続し、これらの情報を使用して質問に答えることができると素晴らしいでしょう。または、AIを独自の製品に統合する場合（例えば、Notion AIを使用して）、ユーザーに関するすべての情報をアプリのAIモデルが知っておくことが望ましいです。

それらのためには、データの移動が前提条件です。

モデルの微調整を行っている場合や検索増強生成（RAG）を使用している場合でも、どこにあってもデータを抽出し、モデルが理解できる形式に変換し、それをAIアプリケーションがアクセスできるデータストアにロードする必要があります。

上記の図は、RAGを使用した場合の例ですが、RAGを使用しない場合でも、基本的なステップは変わらないと想像できます。非公開の情報を知るAIモデルを構築するために、あなたとあなたのユースケースに特化したデータを抽出、変換、ロード（ETL）する必要があります。

なぜデータの移動は困難なのか？

APIやデータベースからのデータ抽出のための基本的なMVP（最小限の機能を持つ製品）を構築するのは、通常（必ずしも常にではありませんが）短期間（1週間未満）で可能です。しかし、本当に困難なのは、それを本番用に準備し、その状態を維持することです。抽出パイプラインを構築する際に考慮すべきいくつかの標準的な課題を見てみましょう。

増分抽出と状態管理

意味のあるデータ量がある場合、パイプラインが以前に抽出したデータのみを抽出するように増分抽出を実装する必要があります。これには、各接続が抽出したデータの追跡を保持するための永続化レイヤーが必要です。

一時的なエラーハンドリング、バックオフ、失敗時の再開、エアギャップ

上流データソースは常に何らかの理由で失敗することがあります。パイプラインはこれに耐えられるように設計され、適切なバックオフポリシーでリトライする必要があります。もし失敗が一時的なものではなく（しかし、あなたの責任ではない場合）、その場合、パイプラインは上流が修正されるまで中断した場所から再開する能力があるように耐久性が必要です。上流からの問題が深刻である場合（例えば、APIがレコードから重要なフィールドを削除する場合）、何が起こっているかを調査し、手動でどうするかを決定するまで、パイプライン全体を一時停止したい場合もあります。

設定エラーの特定と積極的な修正

顧客のデータを抽出するデータ抽出パイプラインを構築していると仮定しましょう。その場合、顧客が提供したデータ抽出のためのすべての設定が正しいことを確認するためのいくつかの防御的なチェックを実装する必要があります。もし設定が正しくない場合は、すばやく具体的なエラーメッセージを提供する必要があります。ほとんどのAPIはこれを容易にはしません。なぜなら、包括的なエラーテーブルを公開しないからです。そして、公開していても、APIトークンに割り当てられたアクセス許可をチェックするためのエンドポイントを提供してくれないことがよくあります。そのため、包括的なチェックとユーザーへの迅速なフィードバックをバランスさせる方法を見つける必要があります。

認証とシークレット管理

APIは、シンプルなベアラトークン認証から、セッショントークンや一度だけ使用されるOAuthなどの「創造的な」実装まで、シンプルさの範囲内で異なります。認証を実行し、シークレットを管理するためのロジックを実装する必要があります。シークレットは1時間ごとに更新される可能性があり、複数の同時ワーカーを介してシークレットの更新を調整する必要があるかもしれません。

抽出および読み込み速度、同時実行、およびレート制限の最適化

そして、同時ワーカーについて話すと、高いスループットを実現するために同時実行を実装することが望ましいでしょう。これは小規模なデータセットでは関係ありませんが、大規模なデータセットでは絶対に重要です。公式のレート制限がAPIによって提供されるにもかかわらず、IPがブラックリストに登録されたり、永久にレート制限されたりしないように、最適な並列性パラメータを実証的に求める必要があります。

上流のAPIの変更への適応

APIは頻繁に変更され、新しい未公開の動作や特性を持つことがあります。多くのベンダーは毎四半期ごとに新しいAPIバージョンを公開しています。これらのアップデートがどのように作業に影響するかを注意深く監視し、最新の状態を保つためにエンジニアリングの時間を割く必要があります。新しいエンドポイントが頻繁に登場し、一部のエンドポイントの動作が変更されることもあります（そして常に事前通知を受けるわけではありません）。

スケジューリング、モニタリング、ログ記録、および可観測性

特定のAPIからデータを抽出するコード以外にも、データ抽出プロセス全体で利用されるいくつかの水平能力を構築する必要があるかもしれません。スケジュール設定やログ記録、モニタリングなど、スケジュールが機能しない場合や他の問題が発生した場合に調査するための機能が必要です。また、昨日、今日、先週などに抽出されたレコードの数やそれらがどのAPIエンドポイントまたはデータベーステーブルから来たのかなど、いくつかの可観測性も必要です。

データのブロッキングまたはハッシング

データを取得する元によっては、データを下流に送信する前に、ブロッキングまたはハッシングするためのプライバシー機能が必要な場合があります。

はっきり言っておきますが、上記は単に一度だけいくつかのファイルを移動したい場合には該当しません。

しかし、データ移動を必要とする製品を構築している場合には、いずれかの関心事に対応する必要があります。これらのいずれか1つが不可能な難問ではありませんが、すべてをまとめると、1つまたは複数の常勤の仕事にすぐになることがあります。特に、データソースが多いほど、その数は増えます。

そして、それがデータ抽出とパイプラインのメンテナンスの難しさです。大部分のコストは、これらのパイプラインを機能的かつ堅牢に保つために必要な連続的な投資から生じます。ほとんどのAIエンジニアにとって、それはユーザーに最も価値をもたらす仕事ではありません。彼らの時間は他のことに費やすべきです。

では、AIエンジニアはここでデータを移動するために何をしなければならないのでしょうか？

データの抽出と読み込みのパイプラインが必要な場合は、自分自身で自動的に構築する代わりに、すでに利用可能なソリューションを試してみてください。おそらく、ほとんどまたはすべての関心事を解決できるかもしれません。解決できない場合は、最終手段として独自のパイプラインを構築してください。

そして、既存のプラットフォームが必要なすべてをサポートしていない場合でも、移植性の高い拡張可能なフレームワークでほぼ全体をカバーできるはずです。これにより、すべてをゼロから構築する代わりに、プラットフォームの既製の機能を使用して90％の作業を完了し、最後の10％の作業を行うことができます。最も一般的な例は、ロングテールの統合です。プラットフォームに必要なAPIの統合が付属していない場合、良いプラットフォームは、コードやノーコードのソリューションを書くことで統合を構築し、プラットフォームが提供する便利な機能をすべて利用できるようにします。コネクタをPythonパッケージとしてインポートし、コードから自由にトリガーする柔軟性を望む場合でも、AirbyteやSinger Connectorsなどの多くのオープンソースのELツールを使用できます。

はっきり言いますが、データの移動は完全に解決されたわけではありません。既存のソリューションが本当に不十分な状況もあり、新しいソリューションを構築する必要があります。しかし、これはAIエンジニアリングの大多数には当てはまりません。ほとんどの人は、Jira、Confluence、Slack、Notion、Gmail、Salesforceなどの同じ統合を何度も何度も再構築する必要はありません。既にテスト済みで誰でも使用できるようになったソリューションを使用して、実際にユーザーが関心を持つ価値を追加する作業に取り組みましょう。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!