ユニット 2 / 11

データ収集とソースの理解: スキーマ、サンプリング、品質、およびリークの認識

利益:

  • さまざまなデータソース (データベース、API、ファイル、Web スクレイピング) とそれぞれの落とし穴を認識し、スキーマを正しく理解する能力
  • サンプルが母集団と選択バイアスを表しているかどうかを評価することにより、再現可能なサンプリングを実行する機能
  • 収集段階でデータ漏洩を排除し、各列で「予測時に入手できるか」という質問をすることで法的/倫理的境界を遵守する機能。

すべての分析は、収集したデータの品質と同じくらい優れています。世界で最も先進的なモデルであっても、誤って収集されたデータ、偏ってサンプリングされたデータ、または将来に関する情報が含まれるデータを扱う場合、信頼性の低い結果が生成されます。コンピュータサイエンスでは、この原理は「ガベージイン、ガベージアウト」(ガベージイン、ガベージアウト)として要約されます。この単元では、ソースの理解、サンプリング、質の高い質問、そして初日からのデータ漏洩のリスクへの警戒など、データ収集フェーズについて説明します。この段階では人工知能が強力な助けとなります。 SQL クエリを作成し、API ドキュメントを要約し、データ コントラクトを作成します。しかし、どのようなデータを収集するか、そしてそのデータがあなたを表すかどうかを決定するのは人間です。

データソースについて知る

データはさまざまな場所から取得されており、各ソースには独自の落とし穴があります。データベース (テーブルに格納され、通常は SQL でクエリされる構造化データ) が最も一般的なソースです。信頼性は高いですが、その仕組みをよく理解する必要があります。 API (アプリケーション プログラミング インターフェイス) はライブ データを提供しますが、速度制限や形式変更のリスクが伴います。ファイル (CSV、Excel、JSON) は柔軟性がありますが、形式が不一致になる傾向があります。 Web スクレイピングは強力ですが、法的および倫理的な制限があります。すべてのサイトをスクレイピングできるわけではありません。

注意: Web スクレイピングと自動データ収集については、サイトの利用規約、robots.txt ファイル、および KVKK/GDPR に従ってください。不正なデータ収集には法的責任が生じます。情報セキュリティの観点からは、データ収集ツールは、権限のあるシステム上で、防御/分析の目的でのみ使用してください。不正なアクセスやスクレイピングは禁止されています。

スキーマを理解する: データを理解する

データセットを収集する前に、そのスキーマ (列の名前、データ型、それらの意味、およびそれらの相互関係) を理解する必要があります。ここでは AI が「データ ディクショナリ」、つまり各列の意味を説明するテーブルを作成するのに非常に役立ちます。しかし、AI が生み出す説明は予測です。各列の本当の意味については、データを作成したチームに確認してください。たとえば、「status」という名前の列には 0/1/2 が含まれる場合があります。これらが「保留中/承認/キャンセル」なのか、それともそれ以外なのかは、元のチームだけが知っています。

次の表は、基本的なリソースの種類と注意事項をまとめたものです。

ソース

強み

トラップ

AI がどのように役立つか

SQLデータベース

構造的、信頼性の高い

複雑な JOIN

クエリの下書きを作成します

API

ライブデータ

制限速度、形状変更

ドキュメントの概要、プルコード

CSV/エクセル

柔軟、迅速

フォーマットの不一致

コードの読み取り/解析

ウェブスクレイピング

広範囲に届く

法的・倫理的制限

ドラフトの解析 (権限内)

ログ/イベントデータ

詳しい

膨大な量

クエリのフィルタリング

図: 部分は全体を表していますか?

ほとんどの場合、データ全体ではなくサンプル (母集団から選択されたサブセット) を操作します。重要な質問は、このサンプルが母集団を代表しているのかということです。選択バイアスは最も一般的な罠です。たとえば、モバイル アプリからユーザーのみをサンプリングした場合、Web ユーザーは表示されず、結果は誤解を招くものになります。ほとんどの場合、ランダム サンプリング (各レコードが選択される確率が等しい) が最も安全です。ただし、時系列データでは、分割はランダムではなく時系列に行われます (これについてはユニット 7 とユニット 10 で説明します)。

初日から漏れを認識

データ漏洩はほとんどの災害の原因であり、通常はデータ収集段階で発生します。例: 「キャンセルされたかどうか」を予測する場合、データに「キャンセル日」列を追加すると、モデルは将来を見据えます。収集段階では、各列に対して 1 つの質問をします。「予測を行うときにこの情報は実際に得られるでしょうか?」答えが「いいえ」の場合、そのカラムは漏れています。このトピックについては、ユニット 10 で詳しく説明します。しかし、認識は初日から始めるべきです。

ミニケース3個

ケース 1 — 表現の問題。ある銀行は、信用リスク モデルの承認済みローンに関するデータのみを収集しました (18,500 件のレコード)。拒否はデータに含まれていませんでした。このモデルは、不合格品がどのように動作するかをまったく見ていなかったため、現実世界では間違っていました。教訓: サンプルは、意思決定の対象となる母集団全体を代表するものである必要があります。

ケース 2 — サイレントフォームチェンジ。あるチームは毎日 API から価格データを取得していました。ある日、API プロバイダーが通貨を USD から EUR に変更しましたが、ドメイン名は同じままでした。データが間違ったユニットで 12 日間収集されました。 3,200行が破損していました。教訓: API データのボリュームと形式の一貫性を定期的にチェックしてください。

ケース 3 — 初期の漏れ。あるアナリストは、「解約」推定のためのデータを収集する際に、「アカウント閉鎖の理由」列を含めました。この列は顧客が去った後にのみ記入されました。モデルはテスト セットで 97% の精度をもたらしました。予測時にはその列が空だったので、本番環境では機能しませんでした。教訓: 各列に「予測時にそれを持っているか?」という質問をしてください。

コピー可能な 4 つのテンプレート

1) データ辞書の抽出:

あなたの役割: データ サイエンティストのアシスタント。以下は、テーブルの列名とサンプル (匿名) 値です。各列について、その推定される意味、データ型、および潜在的な品質リスクを表にリストします。確信が持てない列には「要確認」としてマークを付けてください。作るという意味。列: [ここに貼り付け]

2) サンプリング コード (ランダム、反復可能):

パンダDFを飼っています。 200,000 行から代表的な 5% のランダム サンプルを抽出するコードを作成します。 (再現性のため)random_state=42 を使用します。サンプルのクラス分布が母集団と類似していることを確認するコードを追加します。

3) リークスキャンに関する質問:

このコラムのリストを紹介します。私の目標は、「キャンセルされるかどうか」(0/1) を予測することです。各列について、予測時に実際にそれが存在するかどうかを評価し、「安全/疑わしい/リーク」としてマークします。根拠を一文で書きましょう。列: [リスト]

4) SQL プル クエリのドラフト:

PostgreSQL に「orders」テーブルと「customers」テーブルがあります。過去 90 日間の注文と顧客の都市を結合し、都市ごとの注文の合計金額と数を返す JOIN クエリを作成します。日付フィルターと NULL 都市の処理方法について説明します。クエリを実行して確認してみます。

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

弱いプロンプト:

このデータベースから適切なサンプル データを取得してください。

「良い」というのは曖昧です。どの絵、どの時代、どのサイズ、どの目的かは明らかではありません。 AI は一般的な、おそらく間違ったクエリのみを生成します。

強力なプロンプト:

あなたの役割: SQL アシスタント。 「トランザクション」テーブルがあります:列ID、customer_id、日付(タイムスタンプ)、金額(数値)、チャネル(テキスト: 'web'/'mobile')。タスク: 2024 年の各チャネルから代表的な 10,000 行を返す反復可能な (ORDER BY で決定的) クエリを作成します。 目的: チャネル比較分析。クエリの前提条件を列挙します。

ここでは、表、目的、サイズ、再現性が明確です。

よくある間違い

  • サンプルの代表性を疑うものではありません。簡単にアクセスできるデータは正確なデータではありません。選択バイアスにより結果が歪められます。
  • 列の意味を AI に適応させる。ソースチームはその意味を知っています。 AI予測を確認せずに使用しないでください。
  • API 形式/単位の変更を追跡しません。サイレント変更により、数日間にわたって破損したデータが収集されます。
  • 回収段階では漏れを無視。 「予測時にそれを持っているか」という質問が早い段階で行われない場合、モデルは誤った成功を与えることになります。
  • 不正または違法なデータを収集する。 robot.txt、利用規約、KVKK への違反は重大なリスクです。
ヒント: 新しいデータ ソースごとに、ソース、プル日付、行数、既知の境界、漏洩の危険性のある列を記載した 1 ページの「データ カード」を作成します。このカードは、「このデータは何だったのか」という疑問と再現性を数か月後に保存します。

要約すると

分析の品質は、収集されたデータの品質によって制限されます。ソース (データベース、API、ファイル、スクレイピング) とスキーマをよく理解する。サンプルが母集団を代表していることを確認してください。各カラムに「予測時にそれがあるか?」を尋ねることで、初日から漏れを排除します。 AI はクエリや文書作成の優れたアクセラレータですが、収集するデータとその代表性を決定するのは人間です。権限、法律、機密保持の制限が常に最優先されます。

アプリケーションタスク

データ ソース (独自のビジネスまたは仮説から) を選択します。上記の「データ ディクショナリ抽出」テンプレートを使用して、AI からデータ ディクショナリのドラフトを取得します。次に、各列を手動で評価して、リークがないかどうかを確認します。少なくとも 1 つの疑わしい/リーク列を見つけて、それが危険である理由を 1 文で書くようにしてください。

チェックリスト

  • [ ] データ ソースとスキーマをソース チームに確認しましたか?
  • [ ] サンプルが母集団を代表していることを確認しましたか?
  • [ ] 各欄に「見積時にお持ちしますか?」という質問をしましたか?
  • [ ] サンプリングを反復可能 (固定シード) にしましたか?
  • [ ] 収集の法的/倫理的 (権限、robots.txt、KVKK) 制限を確認しましたか?