Xử lý thống kê với Stata: workflow bằng do-file có thể tái lập

1. Workflow tái lập khác với một do-file dài như thế nào?

Do-file là điều kiện cần, nhưng một tệp lệnh dài chưa bảo đảm khả năng tái lập. Workflow còn bao gồm cấu trúc thư mục, nguồn dữ liệu, thứ tự chạy, phiên bản phần mềm, gói mở rộng, nhật ký và quy tắc tạo đầu ra. Long (2009) xem việc lập kế hoạch, ghi chép, làm sạch, phân tích, trình bày và lưu trữ là các phần của cùng một quy trình phân tích dữ liệu.

Tiêu chuẩn thực dụng là một người khác có thể bắt đầu từ bản sao dữ liệu đầu vào được phép chia sẻ, chạy master do-file trong một phiên Stata sạch và tạo lại các tệp phân tích cùng bảng kết quả. Nếu phải mở Data Editor để sửa ô, nhấn lại menu theo trí nhớ hoặc chép hệ số từ Results sang Word, phần đó chưa được tự động hóa.

Tái lập không đồng nghĩa với kết luận đúng. Một workflow có thể chạy hoàn hảo nhưng vẫn dùng sai estimator, sai trọng số hoặc sai cấu trúc phụ thuộc. Quy trình kỹ thuật phải đi cùng lập luận phương pháp và kiểm tra giả định.

2. Thiết kế cấu trúc dự án trước khi phân tích

Stata Project Manager hỗ trợ tổ chức do-files, datasets, graphs và các tệp liên quan, đồng thời chấp nhận đường dẫn tương đối để dự án có thể di chuyển giữa máy tính (StataCorp, n.d.-a). Bạn vẫn có thể dùng cấu trúc thư mục thông thường nếu nhóm không sử dụng Project Manager.

Dữ liệu gốc nên được đặt ở thư mục chỉ đọc về mặt quy ước. Mọi sửa tên biến, mã hóa giá trị thiếu, ghép bảng hoặc tạo biến phải diễn ra bằng lệnh và được lưu sang data/derived. Cách tách này cho phép quay lại nguồn khi một quyết định làm sạch cần thay đổi.

3. Viết master do-file như một bản đồ thực thi

User's Guide của Stata mô tả do-file là tệp lệnh có thể chạy lại, gọi các do-file khác và ghi log đầu ra. Lệnh version ở đầu tệp yêu cầu Stata diễn giải cú pháp theo phiên bản được chỉ định, nhờ đó giảm rủi ro một thay đổi phần mềm làm biến đổi hành vi của lệnh (StataCorp, 2025c).

Master do-file nên ngắn. Nó thiết lập môi trường, mở log, đặt seed khi có thành phần ngẫu nhiên, gọi từng mô-đun và đóng log. Phần làm sạch hoặc ước lượng chi tiết nằm trong các tệp con để lỗi dễ định vị.

version 19.0
clear all
set more off
capture log close _all

log using "output/logs/master.log", text replace
set seed 20261025

do "do/10_import_clean.do"
do "do/20_derive.do"
do "do/30_analysis.do"
do "do/40_report.do"

log close
exit

4. Import dữ liệu mà vẫn giữ được dấu vết nguồn

Mỗi tệp raw cần có nguồn, ngày nhận, phiên bản và số dòng ban đầu. Sau khi import, dùng describe, codebook và các lệnh kiểm tra phạm vi để xác nhận kiểu biến, nhãn, mã thiếu và đơn vị. Lưu dữ liệu dẫn xuất bằng tên mới; không lưu đè tệp nguồn.

datasignature tạo chữ ký dựa trên giá trị, tên biến và kiểu lưu trữ. datasignature confirm có thể dừng do-file khi dữ liệu không còn khớp chữ ký đã lưu, nên phù hợp để phát hiện tệp nguồn bị thay đổi ngoài quy trình (StataCorp, 2025b). Chữ ký không thay thế quản lý quyền truy cập hoặc sao lưu.

Nếu nguồn là Excel, CSV hoặc hệ quản trị dữ liệu, giữ nguyên tệp xuất ban đầu cùng lệnh import. Một tệp .dta đã chỉnh tay không cho biết cột nào đã được đổi hay trường hợp nào đã bị loại.

use "data/raw/survey_original.dta", clear
describe
codebook respondent_id age income
isid respondent_id
assert inrange(age, 18, 100) if !missing(age)
assert income >= 0 if !missing(income)
datasignature

save "data/derived/survey_stage01.dta", replace

5. Biến kỳ vọng thành kiểm tra có thể làm do-file dừng lại

Kiểm tra dữ liệu có giá trị nhất khi một vi phạm tạo mã lỗi và dừng quy trình. assert xác nhận một điều kiện đúng cho các quan sát thuộc phạm vi kiểm tra; isid xác nhận một biến hoặc tổ hợp biến định danh duy nhất. Hai lệnh này biến giả định ngầm thành điều kiện có thể kiểm toán (StataCorp, 2025b).

Giá trị thiếu số trong Stata lớn hơn mọi số hữu hạn. Vì vậy, điều kiện age >= 18 sẽ chấp nhận age bằng dấu chấm nếu không thêm !missing(age). Đây là lý do kiểm tra phạm vi phải nói rõ cách xử lý thiếu.

Kiểm tra nên bám codebook: giá trị hợp lệ của biến phân loại, miền của thang điểm, quan hệ giữa các biến và số quan sát dự kiến. Không xóa ngoại lệ chỉ vì nó làm hệ số thay đổi; trước hết cần phân loại lỗi nhập, đơn vị đo khác, nhóm con có thật hoặc giá trị cực đoan hợp lệ.

6. Merge an toàn bắt đầu bằng kiểm tra khóa

merge ghép các quan sát theo một hoặc nhiều khóa và tạo biến _merge để chỉ ra dòng chỉ có ở master, chỉ có ở using hoặc xuất hiện ở cả hai tệp (StataCorp, 2025b). Trước khi ghép, phải kiểm tra tính duy nhất của khóa ở từng phía theo quan hệ 1:1, 1:m hoặc m:1 dự kiến.

Không nên dùng merge m:m để chữa lỗi khóa trùng. Phép ghép many-to-many có thể tạo các cặp theo thứ tự quan sát thay vì quan hệ nghiên cứu mong muốn. Hãy xác định lại đơn vị phân tích, bổ sung biến khóa hoặc tổng hợp đúng cấp trước khi ghép.

Sau merge, tabulate _merge và đối chiếu các trường hợp không khớp. Chỉ drop _merge sau khi lưu bằng chứng kiểm tra. Các tùy chọn assert() và keep() hữu ích khi nhóm đã xác định trước trạng thái được chấp nhận; một trạng thái ngoài dự kiến sẽ làm lệnh báo lỗi thay vì bị bỏ qua.

use "data/derived/respondents.dta", clear
isid respondent_id

preserve
use "data/derived/province_lookup.dta", clear
isid province_code
restore

merge m:1 province_code using "data/derived/province_lookup.dta"
tabulate _merge
assert inlist(_merge, 1, 3)
count if _merge == 1

drop _merge
save "data/derived/analysis_ready.dta", replace

7. Chọn estimator từ thiết kế dữ liệu, không từ lệnh quen tay

Lệnh ước lượng phải phù hợp với biến kết quả, cấu trúc phụ thuộc và cách lấy mẫu. regress có thể phù hợp cho kết quả liên tục trong dữ liệu cắt ngang khi các giả định liên quan được xem xét. logit hoặc probit xử lý kết quả nhị phân. Dữ liệu panel có thể cần xtset cùng mô hình panel; dữ liệu phân cấp có thể cần mixed hoặc meglm; mẫu khảo sát phức tạp phải được khai báo bằng svyset trước khi dùng tiền tố svy (StataCorp, 2025a).

Sai số chuẩn robust không sửa sai dạng hàm, nội sinh, sai số đo hoặc chọn mẫu. Clustered standard errors cũng không tự biến dữ liệu thành panel hợp lệ. Báo cáo phải nêu đơn vị cluster, số cluster và lý do chọn cấu trúc phương sai.

Trọng số cần được xác định theo thiết kế và ý nghĩa của chúng. Không thay pweight, fweight, aweight hoặc iweight cho nhau chỉ vì lệnh chấp nhận. Khi dữ liệu đến từ khảo sát phức tạp, strata, primary sampling units và weights thuộc cùng thiết kế suy luận.

8. Khóa thành phần ngẫu nhiên, phiên bản và gói mở rộng

set seed xác định điểm bắt đầu của bộ sinh số giả ngẫu nhiên. Cùng seed và cùng chuỗi lệnh sẽ tái tạo cùng chuỗi số đối với bộ sinh tương ứng; không nên đặt lại seed nhiều lần bên trong vòng lặp vì có thể tạo cấu trúc lặp ngoài ý muốn (StataCorp, 2025a).

Ghi version ở đầu master do-file và lưu c(returned) hoặc about trong log để biết bản Stata đã chạy. Với lệnh do cộng đồng phát triển, ghi tên gói, phiên bản hoặc ngày cài cùng nguồn cài đặt. Một do-file gọi lệnh chưa được khai báo sẽ khó chạy trên máy mới.

Tái lập số học còn phụ thuộc dữ liệu và thứ tự lệnh. Sort không ổn định khi khóa sắp xếp bị trùng có thể làm một thao tác chọn theo vị trí trả kết quả khác; vì vậy hãy bổ sung khóa duy nhất trước khi dùng _n hoặc giữ một hàng theo thứ tự.

9. Tách ước lượng chính, kiểm tra sau ước lượng và phân tích độ nhạy

Tệp analysis nên xác định rõ mô hình chính trước, lưu estimates và tạo các đại lượng cần báo cáo bằng margins, contrast, lincom hoặc nlcom khi phù hợp. Kết quả phụ thuộc vào thang đo của mô hình; hệ số logit, odds ratio và xác suất dự báo không được diễn giải như cùng một đại lượng.

Các kiểm tra sau ước lượng cần gắn với estimator. Kiểm tra phần dư của OLS không thể sao chép nguyên sang mô hình nhị phân, panel hay multilevel. Một workflow tốt lưu cả lệnh kiểm tra và tiêu chí diễn giải, nhưng không biến một p-value chẩn đoán thành lệnh tự động xóa quan sát.

Phân tích độ nhạy nên nằm ở khối riêng: thay đặc tả có căn cứ, cách mã hóa hợp lý, SE hoặc cấu trúc mẫu. Việc thử nhiều mô hình rồi chỉ giữ kết quả thuận lợi làm mất tính minh bạch ngay cả khi toàn bộ thao tác đã được mã hóa.

10. Sinh bảng và hình trực tiếp từ Stata

Sao chép số từ Results sang Word tạo một nhánh thủ công mà Stata không thể kiểm tra. Các công cụ collect, etable, putdocx, putexcel, dyndoc và markdown cho phép tạo bảng hoặc tài liệu từ kết quả đang lưu; tài liệu có thể được cập nhật bằng cách chạy lại lệnh khi dữ liệu thay đổi (StataCorp, n.d.-b).

Tệp báo cáo nên ghi tiêu đề mô hình, biến phụ thuộc, dạng SE, số quan sát, đơn vị cluster, trọng số và ghi chú về thang hệ số. Làm tròn chỉ xảy ra ở lớp trình bày. Dữ liệu đầy đủ trong bộ nhớ vẫn giữ độ chính xác cho phép tính tiếp theo.

Một bảng đẹp chưa đủ để kiểm toán. Lưu log văn bản, do-files, danh sách phiên bản và bảng ánh xạ giữa tên bảng trong bản thảo với tệp đầu ra. Nếu một kết quả trong bài không truy được về lệnh đã chạy, workflow còn thiếu một liên kết.

11. Ví dụ giả định: từ dữ liệu khảo sát đến mô hình có cluster

Ví dụ này minh họa workflow, không phải kết quả nghiên cứu thật. Giả sử dữ liệu gồm 1.200 người thuộc 60 trường, kết quả wellbeing liên tục và một số biến giải thích ở cấp cá nhân. respondent_id phải duy nhất; school_id xác định cụm dùng cho sai số chuẩn.

Tệp clean kiểm tra ID, phạm vi tuổi và mã thiếu, sau đó lưu analysis_ready.dta. Tệp analysis nạp đúng bản dẫn xuất, mô tả mẫu, chạy mô hình chính với vce(cluster school_id), lưu estimates và tính giá trị dự báo. Báo cáo phải nói rõ có 60 cụm, vì số quan sát cá nhân không thay thế số đơn vị độc lập ở cấp trường.

Nếu giả thuyết yêu cầu hiệu ứng ngẫu nhiên giữa trường, clustered SE không thay thế mixed model. Lựa chọn giữa mô hình biên với SE theo cụm và mô hình đa cấp phải dựa vào câu hỏi cùng cấu trúc sinh dữ liệu.

use "data/derived/analysis_ready.dta", clear
isid respondent_id
assert !missing(school_id)

misstable summarize wellbeing age female exposure
summarize wellbeing age exposure
tabulate female

regress wellbeing c.exposure c.age i.female, vce(cluster school_id)
estimates store main_ols
margins, at(exposure=(0 1 2 3 4))
marginsplot, name(fig_margins, replace)
graph export "output/figures/margins.svg", replace

12. Mẫu mô tả workflow trong luận văn hoặc bài báo

Phần mềm và workflow cần được mô tả đủ để người đọc hiểu cách kết quả được tạo ra. Không cần chép toàn bộ do-file vào phương pháp, nhưng nên cung cấp phiên bản, các bước xử lý chính, estimator, SE hoặc thiết kế khảo sát và nơi lưu mã khi có thể.

Mẫu dưới đây cần thay bằng thông tin thật của nghiên cứu. Không giữ các lựa chọn trong ngoặc nếu bài chỉ dùng một phương án.

13. Bảng kiểm trước khi bàn giao dự án Stata

• Master do-file chạy từ một phiên Stata sạch mà không cần thao tác tay.
• Dữ liệu raw không bị ghi đè và có thông tin nguồn cùng ngày nhận.
• Mọi tệp trong data/derived được tạo bằng lệnh.
• Các khóa được kiểm tra bằng isid trước khi merge.
• Trạng thái _merge được đối chiếu và các trường hợp không khớp được giải thích.
• Mã thiếu, miền giá trị và quan hệ logic giữa biến được kiểm tra bằng lệnh.
• version, seed, phiên bản Stata và gói mở rộng đã được ghi lại.
• Estimator, weights, survey design hoặc cluster phù hợp với thiết kế dữ liệu.
• Mô hình chính được tách khỏi phân tích độ nhạy.
• Bảng và hình được sinh từ lệnh, không sao chép số thủ công.
• Log không chứa đường dẫn, thông tin cá nhân hoặc dữ liệu nhạy cảm không cần thiết.
• README nêu thứ tự chạy, đầu vào cần có và đầu ra dự kiến.