データパイプライン: 収集、クレンジング、タグ付け、バージョン管理

利益:

データパイプライン (収集、検証、クレンジング、変換、分割、バージョン管理) を設定し、パイプラインの先頭にスキーマ検証を配置する機能
データ漏洩 (グループおよび一時的) を防ぐために、フィールドの意味と分割に基づいて欠損値とラベル付けの決定を行う機能
データのバージョンとランダム性シードを固定することで、再現可能なデータベースを作成する機能

すべての機械学習システムの真の力は、モデルではなくデータにあります。経験豊富なエンジニアは、「ガベージイン、ガベージアウト」を知っています。最も高度なモデルに悪いデータを入力しても、悪い結果が生じます。この単元では、データパイプライン (データパイプライン: 生データをモデルトレーニングに使用できるようにする一連のステップ) をエンドツーエンドで確立し、このラインのどのステップで人工知能を安全に使用できるかを学習します。

データラインのステップ

データラインは通常、次のストップを通過します。

収集 (取り込み): ソース (データベース、API、ログファイル、イベントストリーム) からデータを取得します。
検証: データが予期されたスキーマ、タイプ、および範囲に準拠しているかどうかを確認します。
クリーニング: 欠損値、重複レコード、外れ値、不一致を処理します。
変換: 生データを属性に変換します。たとえば、カテゴリ変数を数値に変換し、日付から「曜日」を生成します。
分割: トレーニング、検証、テストのセットに分割します。
バージョニング: どのモデルがどのデータでトレーニングされたかを記録します。

人工知能は、特にステップ 2、3、4 でコードのドラフトやアイデアを生成することで時間を節約します。しかし、どのレコードを破棄するか、どの欠損値をどのように埋めるかなどの決定は、データを知っているエンジニアに属します。不適切なクリーニングによりモデルに隠れたバイアスが注入される可能性があるためです。

データ検証: ラインの早期防御

最もコストのかかるエラーは、本番環境ではなく、検証ステップがスキップされたところで始まります。スキーマ検証では、受信したデータの各バッチが予想される構造に準拠しているかどうかが自動的にチェックされます。たとえば、年齢列は 0 ～ 120 の間ですか、電子メールフィールドは空ですか、列数は変更されましたか?

ヒント: 検証は行の先頭に置きます。破損したデータが早く発見されるほど、修正のコストが安くなります。本番環境で見つかったスキーマエラーは、トレーニング段階で見つかったスキーマエラーよりも何倍もコストがかかります。

次のデータスキーマに対して pandera (または Great Expectations) を使用して検証スキームを作成します。列とルール: - user_id: 整数、null にすることはできません、一意 - age: 整数、0 ～ 120 にすることはできません -signup_date: 日付、将来のものにすることはできません - country: categorical、集合 {TR、DE、US、UK} から - Balance: 10 進数、負にすることはできませんルール違反ごとに意味のあるエラーメッセージを生成します。コードの最後に破線の例を使用してテストを表示します。

掃除：決めるのは人間です

欠損値はあらゆるデータセットに存在します。対処方法:

削除: 欠落率が非常に高い行/列を破棄します。しかし、情報の損失と偏見のリスクがあります。
代入: 平均値、中央値、最頻値、またはモデルベースの予測による代入。
フラグ: 「欠落していた」情報を別のフラグ列に保存します。欠落していること自体がシグナルである場合もあります。

どちらが正しいかは問題によって異なります。医療データセットでは、「血液値が測定されていない」情報は削除されるのではなく、保存される必要があります。なぜなら、医師が測定を拒否することさえも信号だからです。 AI はオプションとコードを提供します。現場の現実に適合するものを選択してください。

弱いプロンプト / 強いプロンプト

弱いプロンプト: 「欠落している値を入力してください。」

強力なプロンプト: 「次の列に欠損値があります: 収入 (12% 欠損、右偏り分布)、last_login (30% 欠損)。収入を中央値で埋めることを提案しますが、平均ではなく中央値である理由を説明してください。last_login については、欠損値が重要である可能性があると想定してください (ユーザーはログインしたことがない可能性があります)。削除の代わりに Never_logged_in フラグを生成することを検討してください。どちらのアプローチでもモデルに追加されるバイアスを書き留めてください。」

違い: 強力なプロンプトにより、分布情報とエリアの意味が得られます。人工知能は、機械的な入力の代わりに意思決定サポートを生成します。

ラベル表示: 品質は評価されます

教師あり学習（どのような例題に正解を与える学習）においてモデルが学習するのはラベル（ラベル：各例題の正解）です。ラベルの品質には上限が設定されます。人々が一貫性のないラベルを付けると、モデルの学習も一貫性がなくなります。

アノテーター間の合意は、異なる人が同じサンプルに同じラベルを付ける割合を測定します。コーエンのカッパなどの係数で表されます。コンプライアンスが低いということは、タスクが不明確であるか、指示が弱いことを示しています。

人工知能は 2 つの方法でラベル付けを支援します。(1) 注釈ガイドラインの草案を作成する、(2) 事前にラベルを付けて人間のみが修正する。しかし、LLM を使用した事前ラベル付けには落とし穴があります。モデルの系統的誤差がラベルセット全体に漏れる可能性があります。そのため、人間は常に LLM ラベルの一部をチェックします。

注意: LLM によって作成されたラベルを「グラウンドトゥルース」とみなさないでください。サンプルを人間と確認し、LLM と人間の適合性を測定します。コンプライアンスが低い場合、事前にラベルを付けることは良いことよりも害を及ぼすことになります。

データパーティション: 漏洩を防ぐ

データをトレーニング/検証/テストに分割する際の最も危険な間違いは、データ漏洩、つまりトレーニングにテスト情報が混入することです。例:

同じユーザーの記録がトレーニングとテストの両方に当てはまります (グループリーク)。
トレーニングでは未来を、テストでは過去を時系列で使用します (時間的漏洩)。
全データからスケーリング（正規化）パラメータを計算して除算します。

時間的な分割は、過去で訓練し、未来でテストするなど、時間が関係する問題には不可欠です。ランダムな分割は、運用環境では決して起こらない「将来の」メリットをもたらし、メトリクスを増大させます。

データのバージョン管理と再現性

「このモデルをトレーニングしたのはどのデータですか?」数か月後にその質問に答えることができるのは、本格的な ML エンジニアリングの証です。データのバージョン管理は、各データスナップショットを ID (ハッシュまたはバージョンタグ) とともに保存します。 DVC (データバージョンコントロール) などのツールは、コードと同様にデータをバージョン管理します。

モデルの結果を再現するには、データバージョン、コードバージョン、ランダムシードの 3 つを修正する必要があります。このトリオなしでは「同じ結果が得られた」とは言えません。単元 11 では再現性を深めていきます。ただし、データパイプラインのシードの修正はここから始まります。

ミニケース3個

ケース 1 - スキーマ検証が保存された日。チームが上流システムの価格フィールドをペニーからリラに変換したところ、すべての価格が 100 分の 1 に下がりました。スキーマ検証ではバッチが「価格が範囲外」として拒否され、モデルは破損したデータでトレーニングされていませんでした。検証を行わないと、本番環境でのみエラーが認識され、予測が不正確になります。

ケース 2 - 不適切な充填によるバイアス。信用モデルでは、欠落している所得値が平均値で埋められました。しかし、収入が失われたのは主に低所得層だった。平均化はこのグループを人為的に「富化」させ、モデルは不当に高い制限を彼らに提供しました。中央値 + 欠損フラグの問題を修正しました。

ケース 3 - 一時的な漏れ。需要予測モデルは、テストセットでは良好に見えましたが (精度 95%)、本番環境ではクラッシュしました。理由: ランダムな分割により、モデルには未来が見えていました。一時的なビニングに切り替えると、テストの精度が 78% に低下しましたが、これは実際のパフォーマンスであり、本番環境でも維持されました。

コピー可能なテンプレート

次のデータセットを 3 つのセットに分割します: training/validation/testing.Constraint: これは時系列です。 TEMPORAL 分割を使用します (過去にトレーニングし、将来にテストします)。バッチ漏洩を防止します。同じ `customer_id` を 1 つのクラスター内でのみ使用します。トレーニングセットからのみスケーリングパラメーターを計算し、すべてに適用します。各ステップでコードに残りの行数を出力し、リークがないことをチェックするアサートを追加します。

このラベル付けタスクの注釈ガイドラインの下書きを作成します。タスク: [例:顧客レビューに肯定的/否定的/中立的なラベルを付ける]境界例を明確にします: 皮肉、複雑な感情、製品に関係のないレビューにラベルを付ける方法?タグ付け者間で一貫性を高めるための 5 つの例と 3 つの困難なエッジケースを示します。

このデータパイプラインの再現性チェックリストを作成します:- データバージョンをどのように修正する必要がありますか?- どのランダムシードをどこに設定する必要がありますか?- どのようなメタデータ (データハッシュ、行数、日付) をログに記録する必要がありますか?私のコードベース: [言語/ライブラリ]

このクリーンアップコードにデータ漏洩がないか確認してください。具体的には、スケーリング/エンコーディングパラメータは分割前に計算されていますか?統計はすべてのデータから計算されますか、それともトレーニングのみから計算されますか?コード: [コード]

デシジョンテーブル: 欠損値戦略

ステータス

推奨されるアプローチ

なぜ

数値的な偏った分布

中央値で埋める

平均は外れ値の影響を受ける

数値、対称

平均値で埋める

情報を保護します

欠乏は重大である可能性がある

フラグ列 + 塗りつぶし

不足は信号です

欠席率 > 60%

列の評価/破棄

騒音が多すぎる

カテゴリカル

「不明」カテゴリ

人為的多数派を生み出さない

よくある間違い

検証をスキップします。スキーマ制御がないと、破損したデータが静かに侵入します。
分割前のスケーリング。テストの統計が教育に漏洩します。
時系列でランダムな分割を使用します。偽の高いメトリクスを生成します。
LLM ラベルを盲目的に信頼します。系統的誤差はデータ全体に広がります。
データバージョンを保存していません。結果を再現することはできません。
平均的な機械充填。フィールドの意味を無視し、バイアスを加えます。

要約すると

データパイプラインは ML システムの基盤であり、モデルよりも努力する価値があります。検証を一番上に置きます。ドメインの知識に基づいてクリーニングとラベル付けの決定を下します。コンパートメント内の漏れ（グループおよび一時的）を防ぎます。データのバージョンとシードを修正します。 AI はこのラインでコードとアイデアを生成しますが、どのデータをどのように処理するかを決定するのはユーザー次第です。ここでのあらゆる間違った決定は隠れた欠陥としてモデルに反映されるためです。

アプリケーションタスク

独自のデータセットに検証スキーム (pandera/Great Expectations) を記述し、意図的に不正な行を追加して、それが捕捉されたことを示します。次に、データを時間的またはバッチ的に分割し、トレーニングのみからスケーリングパラメーターを計算し、アサートで漏れがないことを確認します。データのバージョンと行数をメタデータファイルに書き込みます。

チェックリスト

[ ] スキーマ検証は行の先頭で実行されます。
[ ] 私はフィールドの意味に基づいて欠損値戦略を選択しました。機械的に埋めたわけではありません。
[ ] ラベルの品質 (コンプライアンス) を測定しました。 LLM タグを人間がチェックしました。
[ ] ペイン内のグループおよび時間的リークを防止しました。
[ ] トレーニングセットのみから計算されたスケーリング/エンコーディング。
[ ] データのバージョン、行数、シードが記録されます。

データ パイプライン: 収集、クレンジング、タグ付け、バージョン管理