Đơn vị 2 / 11

Thu thập dữ liệu và hiểu nguồn: Lược đồ, lấy mẫu, chất lượng và nhận thức rò rỉ

Lợi nhuận:

  • Khả năng nhận biết các nguồn dữ liệu khác nhau (cơ sở dữ liệu, API, tệp, quét web) cũng như những cạm bẫy của từng nguồn và hiểu chính xác lược đồ
  • Khả năng thực hiện lấy mẫu lặp lại bằng cách đánh giá xem mẫu có đại diện cho dân số và độ lệch lựa chọn hay không
  • Khả năng loại bỏ rò rỉ dữ liệu ở giai đoạn thu thập và tuân thủ các ranh giới pháp lý/đạo đức bằng cách đặt câu hỏi 'Tôi có bị rò rỉ dữ liệu vào thời điểm dự đoán' trong mỗi cột không?

Mọi phân tích đều tốt như chất lượng dữ liệu bạn thu thập. Ngay cả mô hình tiên tiến nhất trên thế giới cũng sẽ tạo ra kết quả không đáng tin cậy nếu nó hoạt động với dữ liệu được thu thập không chính xác, lấy mẫu sai lệch hoặc chứa thông tin về tương lai. Trong khoa học máy tính, nguyên tắc này được tóm tắt là “garbage in, Garbage Out” (rác vào, rác ra). Trong phần này, chúng ta sẽ đề cập đến giai đoạn thu thập dữ liệu: tìm hiểu nguồn, lấy mẫu, đặt câu hỏi về chất lượng và cảnh giác với nguy cơ rò rỉ dữ liệu ngay từ ngày đầu. Trí tuệ nhân tạo là sự trợ giúp đắc lực ở giai đoạn này; Viết truy vấn SQL, tóm tắt tài liệu API, soạn thảo hợp đồng dữ liệu. Nhưng chính con người mới là người quyết định dữ liệu nào bạn thu thập và liệu dữ liệu đó có đại diện cho bạn hay không.

Làm quen với các nguồn dữ liệu

Dữ liệu đến từ những nơi khác nhau và mỗi nguồn đều có những cạm bẫy riêng. Cơ sở dữ liệu (dữ liệu có cấu trúc được lưu trữ trong bảng, thường được truy vấn bằng SQL) là nguồn phổ biến nhất; Nó đáng tin cậy, nhưng cần phải hiểu rõ sơ đồ của nó. API (Giao diện lập trình ứng dụng) cung cấp dữ liệu trực tiếp nhưng tiềm ẩn rủi ro về giới hạn tốc độ và thay đổi định dạng. Các tệp (CSV, Excel, JSON) rất linh hoạt nhưng dễ có định dạng không nhất quán. Quét web rất mạnh mẽ nhưng nó có giới hạn về mặt pháp lý và đạo đức; Không phải mọi trang web đều có thể được cạo.

Lưu ý: Để thu thập dữ liệu tự động và thu thập dữ liệu tự động, hãy tuân thủ các điều khoản sử dụng của trang web, tệp robots.txt và KVKK/GDPR. Việc thu thập dữ liệu trái phép tạo ra trách nhiệm pháp lý. Trong bối cảnh bảo mật thông tin, chỉ sử dụng các công cụ thu thập dữ liệu trên các hệ thống mà bạn được ủy quyền và cho mục đích bảo vệ/phân tích; Truy cập trái phép hoặc cạo đều bị cấm.

Hiểu lược đồ: làm quen với dữ liệu

Trước khi thu thập một tập dữ liệu, bạn phải hiểu lược đồ của nó (tên các cột, kiểu dữ liệu, ý nghĩa và mối quan hệ của chúng với nhau). AI ở đây rất hữu ích trong việc tạo ra một "từ điển dữ liệu" - một bảng giải thích ý nghĩa của từng cột. Nhưng những lời giải thích mà AI tạo ra chỉ là những dự đoán; Xác nhận ý nghĩa thực sự của từng cột với nhóm tạo ra dữ liệu. Ví dụ: cột có tên "trạng thái" có thể chứa 0/1/2; Chỉ nhóm ban đầu mới biết liệu đây là "đang chờ xử lý/được phê duyệt/bị hủy" hay điều gì khác.

Bảng sau đây tóm tắt các loại tài nguyên cơ bản và cảnh báo:

Nguồn

điểm mạnh

cái bẫy

AI giúp ích như thế nào

cơ sở dữ liệu SQL

Kết cấu, đáng tin cậy

THAM GIA phức tạp

Viết bản nháp truy vấn

API

dữ liệu trực tiếp

Giới hạn tốc độ, thay đổi hình dạng

Tóm tắt tài liệu, pull code

CSV/Excel

Linh hoạt, nhanh chóng

Định dạng không nhất quán

Đọc/phân tích mã

quét web

Phạm vi tiếp cận rộng

Giới hạn pháp lý/đạo đức

Phân tích dự thảo (trong thẩm quyền)

Dữ liệu nhật ký/sự kiện

chi tiết

khối lượng khổng lồ

Lọc truy vấn

Minh họa: bộ phận có đại diện cho toàn bộ không?

Hầu hết, bạn làm việc với một mẫu (một tập hợp con được chọn từ tổng thể) chứ không phải toàn bộ dữ liệu. Câu hỏi quan trọng là: mẫu này có đại diện cho dân số không? Sự thiên vị lựa chọn là cái bẫy phổ biến nhất. Ví dụ: nếu bạn chỉ lấy mẫu người dùng từ ứng dụng dành cho thiết bị di động, bạn sẽ không thấy người dùng web và kết quả của bạn sẽ sai lệch. Lấy mẫu ngẫu nhiên (mỗi bản ghi có cơ hội được chọn như nhau) là an toàn nhất trong hầu hết các trường hợp; nhưng trong dữ liệu chuỗi thời gian, việc phân tách được thực hiện theo trình tự thời gian chứ không phải ngẫu nhiên (chúng ta sẽ thấy điều này ở Bài 7 và 10).

Rò rỉ nhận thức ngay từ ngày đầu tiên

Rò rỉ dữ liệu là nguồn gốc của hầu hết các thảm họa và thường phát sinh trong giai đoạn thu thập dữ liệu. Ví dụ: khi dự đoán "nó có bị hủy không", nếu bạn thêm cột "ngày hủy" vào dữ liệu, mô hình sẽ nhìn về tương lai. Trong giai đoạn thu thập, hãy đặt một câu hỏi cho mỗi cột: “Liệu tôi có thực sự có thông tin này vào thời điểm tôi đưa ra dự đoán không?” Nếu câu trả lời là không thì cột đó đang bị rò rỉ. Chúng ta sẽ đề cập sâu hơn về chủ đề này trong Bài 10; Nhưng nhận thức nên bắt đầu từ ngày đầu tiên.

ba trường hợp nhỏ

Trường hợp 1 - Vấn đề đại diện. Một ngân hàng chỉ thu thập dữ liệu về các khoản vay đã được phê duyệt cho mô hình rủi ro tín dụng của mình (18.500 hồ sơ). Sự từ chối không có trong dữ liệu. Mô hình này đã sai trong thế giới thực vì nó chưa bao giờ thấy được những lời từ chối sẽ hành xử như thế nào. Bài học: mẫu phải đại diện cho toàn bộ dân số mà bạn đang đưa ra quyết định.

Trường hợp 2 - Thay đổi hình thức im lặng. Một nhóm đang lấy dữ liệu giá từ API hàng ngày. Một ngày nọ, nhà cung cấp API đã đổi đơn vị tiền tệ từ USD sang EUR nhưng tên miền vẫn được giữ nguyên. Dữ liệu được thu thập sai đơn vị trong 12 ngày; 3.200 dòng bị hỏng. Bài học: Thường xuyên kiểm tra tính nhất quán về khối lượng và định dạng trong dữ liệu API.

Trường hợp 3 - Rò rỉ sớm. Một nhà phân tích đã bao gồm cột "lý do đóng tài khoản" khi thu thập dữ liệu để ước tính "sự thay đổi". Cột này chỉ được điền sau khi khách hàng rời đi. Mô hình mang lại độ chính xác 97% trên bộ thử nghiệm; Nó không hoạt động trong quá trình sản xuất vì cột đó trống tại thời điểm dự đoán. Bài học: đặt câu hỏi cho mỗi cột câu hỏi "Tôi có nó vào thời điểm dự đoán không?"

Bốn mẫu có thể sao chép

1) Trích xuất từ điển dữ liệu:

Vai trò của bạn: trợ lý nhà khoa học dữ liệu. Dưới đây là tên cột và giá trị mẫu (ẩn danh) của một bảng. Đối với mỗi cột, hãy liệt kê ý nghĩa ước tính, kiểu dữ liệu và rủi ro chất lượng tiềm ẩn trong một bảng. Đánh dấu các cột bạn không chắc chắn là "cần xác nhận"; nghĩa là tạo.Cột: [dán vào đây]

2) Mã lấy mẫu (ngẫu nhiên, lặp lại):

Tôi có gấu trúc df. Viết mã trích xuất mẫu ngẫu nhiên đại diện 5% từ 200.000 hàng. Sử dụng Random_state=42 (để có thể tái tạo). Thêm mã để kiểm tra xem phân bố lớp của mẫu có giống với tổng thể hay không.

3) Câu hỏi quét rò rỉ:

Tôi sẽ cung cấp cho bạn danh sách các cột này. Mục tiêu của tôi là dự đoán "nó có bị hủy không" (0/1). Đối với mỗi cột, hãy đánh giá xem liệu tôi có thực sự có nó vào thời điểm dự đoán hay không và đánh dấu nó là "an toàn/đáng ngờ/rò rỉ". Viết lý do của bạn trong một câu. Cột: [danh sách]

4) Bản nháp truy vấn kéo SQL:

Tôi có bảng "đơn đặt hàng" và "khách hàng" trong PostgreSQL. Viết truy vấn THAM GIA kết hợp các đơn đặt hàng trong 90 ngày qua với thành phố của khách hàng và trả về tổng số lượng cũng như số lượng đơn đặt hàng cho mỗi thành phố. Giải thích bộ lọc ngày và cách xử lý các thành phố NULL. Tôi sẽ chạy truy vấn và xác minh nó.

Dấu nhắc yếu / Dấu nhắc mạnh

Dấu nhắc yếu:

Kéo cho tôi một dữ liệu mẫu tốt từ cơ sở dữ liệu này.

“Tốt” là mơ hồ; Tranh nào, thời kỳ nào, kích thước nào, mục đích gì đều không rõ ràng. AI sẽ chỉ tạo ra một truy vấn chung chung, có thể sai.

Lời nhắc mạnh mẽ:

Vai trò của bạn: Trợ lý SQL. Tôi có bảng "giao dịch": cột id, customer_id, ngày (dấu thời gian), số tiền (số), kênh (văn bản: 'web'/'di động'). Nhiệm vụ: Viết một truy vấn có thể lặp lại (xác định với ORDER BY) trả về 10.000 hàng đại diện từ mỗi kênh cho năm 2024. Mục đích: phân tích so sánh kênh. Liệt kê các giả định của truy vấn của bạn.

Ở đây bảng, mục đích, kích thước và độ lặp lại đều rõ ràng.

Những lỗi thường gặp

  • Không đặt câu hỏi về tính đại diện của mẫu. Dữ liệu dễ dàng truy cập không phải là dữ liệu chính xác; sự lựa chọn sai lệch làm sai lệch kết quả.
  • Điều chỉnh ý nghĩa cột cho phù hợp với AI. Nhóm nguồn biết ý nghĩa; Không sử dụng dự đoán AI mà không xác nhận nó.
  • Không theo dõi thay đổi định dạng/đơn vị API. Sự thay đổi thầm lặng thu thập dữ liệu bị hỏng trong nhiều ngày.
  • Bỏ qua rò rỉ ở giai đoạn thu thập. Nếu câu hỏi "Tôi có nó vào thời điểm dự đoán không" không được hỏi sớm, mô hình sẽ cho thành công sai lầm.
  • Thu thập dữ liệu trái phép hoặc bất hợp pháp. Vi phạm robots.txt, điều khoản sử dụng và KVKK là một rủi ro nghiêm trọng.
Mẹo: Giữ một “thẻ dữ liệu” một trang cho mỗi nguồn dữ liệu mới: nguồn, ngày lấy, số hàng, ranh giới đã biết và các cột có nguy cơ bị rò rỉ. Thẻ này lưu câu hỏi "dữ liệu này là gì" và khả năng tái tạo nhiều tháng sau đó.

Tóm lại

Chất lượng phân tích bị giới hạn bởi chất lượng dữ liệu được thu thập. Biết rõ nguồn (cơ sở dữ liệu, API, tệp, mẩu tin) và lược đồ; đảm bảo mẫu đại diện cho dân số; Loại bỏ rò rỉ ngay từ ngày đầu tiên bằng cách hỏi từng cột “tôi có rò rỉ vào thời điểm dự đoán không?” AI là một công cụ tăng tốc tuyệt vời cho công việc truy vấn và ghi tài liệu, nhưng con người mới là người quyết định dữ liệu nào cần thu thập và tính đại diện của dữ liệu đó. Các giới hạn về thẩm quyền, luật pháp và tính bảo mật luôn được đặt lên hàng đầu.

Nhiệm vụ ứng dụng

Chọn nguồn dữ liệu (từ doanh nghiệp của riêng bạn hoặc giả định). Nhận bản nháp từ điển dữ liệu từ AI với mẫu “trích xuất từ ​​điển dữ liệu” ở trên; Sau đó đánh giá thủ công từng cột xem có bị rò rỉ hay không. Cố gắng tìm ít nhất một cột đáng ngờ/rò rỉ và viết bằng một câu tại sao nó lại nguy hiểm.

danh sách kiểm tra

  • [ ] Tôi đã xác nhận nguồn dữ liệu và lược đồ với nhóm nguồn chưa?
  • [ ] Tôi đã kiểm tra xem mẫu có đại diện cho tổng thể không?
  • [ ] Tôi đã hỏi từng cột câu hỏi "liệu tôi có nó vào thời điểm ước tính không?"
  • [ ] Tôi đã thực hiện lấy mẫu lặp lại chưa (hạt giống cố định)?
  • [ ] Tôi đã kiểm tra các giới hạn về mặt pháp lý/đạo đức (thẩm quyền, robots.txt, KVKK) của việc thu thập chưa?