Có thể bạn từng viết một câu như thế này:
“Chúng tôi đã sử dụng scikit-learn để phân cụm bệnh nhân thành các nhóm nhỏ.”
Câu này đọc thì ổn. Nó trung thực. Nhưng tự thân nó lại là một lỗ hổng về phương pháp luận — điều mà người phản biện có thể sẽ nói.
Vấn đề: công cụ không phải là phương pháp
Một gói phần mềm là một sự triển khai (implementation). Nó không phải là phương pháp. Khi bạn viết “chúng tôi đã dùng scikit-learn,” bạn chỉ cho người đọc biết bạn đã cầm cây búa nào lên, chứ không phải bạn đã thực sự làm gì với nó. Bạn chạy k-means? DBSCAN? Phân cụm phân cấp (hierarchical clustering) với liên kết Ward? scikit-learn triển khai tất cả những kỹ thuật này, và mỗi kỹ thuật lại dựa trên những giả định khác nhau, có những kiểu thất bại khác nhau, và trả lời một câu hỏi khác nhau về dữ liệu của bạn.
Điều tương tự đúng ở hầu hết mọi nơi trong nghiên cứu tính toán:
- “Chúng tôi phân tích dữ liệu bằng pandas” không cho người đọc biết phép kiểm định thống kê nào đã được áp dụng.
- “Chúng tôi dùng PyTorch để mô hình hóa mối quan hệ” không nói rõ đó là hồi quy tuyến tính, rừng ngẫu nhiên (random forest), hay transformer.
- “Chúng tôi trực quan hóa kết quả trong R” không cho biết bạn đã chạy kiểm định t, ANOVA, hay mô hình hiệu ứng hỗn hợp (mixed-effects model) trước khi vẽ biểu đồ.
Nếu một người phản biện — hay một độc giả cố gắng tái lập nghiên cứu của bạn năm năm sau — không thể tái dựng lại những gì bạn đã làm chỉ từ phần phương pháp!
Cách khắc phục: phương pháp trước, gói phần mềm sau
Cấu trúc giải quyết vấn đề này khá đơn giản, và một khi bạn thấm nhuần nó, nó sẽ trở thành phản xạ tự nhiên:
- Nêu tên phương pháp. Trình bày kỹ thuật thống kê hoặc tính toán bạn đã sử dụng, bằng ngôn ngữ rõ ràng. “Chúng tôi thực hiện kiểm định t bắt cặp (paired t-test) để so sánh điểm số trước và sau điều trị.” “Chúng tôi khớp một bộ phân loại rừng ngẫu nhiên để dự đoán tình trạng kết cục.”
- Trích dẫn phương pháp, nếu đó không phải là một kỹ thuật kinh điển. Nếu bạn dùng hệ số tương quan Pearson chuẩn, không ai cần trích dẫn cả — nó đã có mặt trong mọi giáo trình thống kê suốt cả thế kỷ. Nhưng nếu bạn dùng một phương pháp ít phổ biến hơn — một biến thể cụ thể của mô hình hỗn hợp, một kỹ thuật giảm chiều dữ liệu đặc thù, một thuật toán mới ra đời trong thập kỷ gần đây — hãy trích dẫn bài báo đã đề xuất hoặc kiểm chứng nó. Điều này cho người đọc biết vì sao phương pháp đó phù hợp, và cho họ một hướng để tìm hiểu sâu hơn nếu muốn.
- Sau đó, và chỉ sau đó, mới nêu tên sự triển khai. “…được triển khai bằng gói
lme4trong R (Bates và cộng sự, 2015).” “…sử dụng lớpRandomForestClassifiertừ scikit-learn (Pedregosa và cộng sự, 2011).” Điều này cho người đọc biết chính xác cách tái lập phân tích của bạn, thậm chí đến cả phiên bản phần mềm nếu bạn muốn cẩn thận.
Hãy chú ý đến thứ tự. Phương pháp, rồi đến trích dẫn cho phương pháp (nếu cần), rồi mới đến gói phần mềm. Không phải theo chiều ngược lại.
Một ví dụ minh họa
Phiên bản yếu:
“Các giá trị thiếu được xử lý bằng gói
missForesttrong R.”
Câu này cho người đọc biết tên một gói phần mềm, nhưng không cho biết missForest thực sự làm gì. Đó là phép quy nạp đơn (single imputation) hay quy nạp đa (multiple imputation)? Quy nạp bằng giá trị trung bình hay dựa trên mô hình? Một người phản biện làm việc trong lĩnh vực phương pháp luận dữ liệu thiếu sẽ muốn biết điều này.
Phiên bản mạnh hơn:
“Các giá trị thiếu được quy nạp bằng quy trình quy nạp lặp dựa trên rừng ngẫu nhiên (Stekhoven & Bühlmann, 2012), được triển khai thông qua gói
missForesttrong R (phiên bản 1.5).”
Bây giờ người đọc biết cách tiếp cận thống kê thực sự, có một trích dẫn về nguồn gốc phương pháp nếu họ muốn hiểu các giả định của nó, và biết chính xác phần mềm cũng như phiên bản nào để tái lập.
Vì sao điều này quan trọng hơn ta tưởng
Đây không phải là sự cầu kỳ vô nghĩa. Một vài lý do cụ thể khiến nó quan trọng:
Khả năng tái lập. Ai đó cố gắng tái lập phân tích của bạn bằng một ngôn ngữ hoặc môi trường khác cần biết thuật toán, chứ không chỉ lệnh gọi thư viện. Các gói phần mềm có thể bị ngừng hỗ trợ, thay đổi giá trị mặc định giữa các phiên bản, hoặc không tồn tại trong mọi ngôn ngữ lập trình — trong khi phương pháp vẫn tồn tại bất kể điều đó.
Sự ghi nhận công lao. Trích dẫn phương pháp là cách ghi nhận công lao cho những nhà nghiên cứu đã phát triển và kiểm chứng kỹ thuật nền tảng, điều thường tách biệt về mặt trí tuệ — và có trước — bất kỳ ai viết ra lớp phần mềm bao quanh nó.
Sự tin tưởng của người phản biện. Khi phần phương pháp nêu rõ kỹ thuật và nguồn gốc của nó, điều đó cho thấy bạn hiểu vì sao mình chọn cách tiếp cận đó, chứ không chỉ đơn thuần tìm được một hàm chạy không báo lỗi. Đây thường là sự khác biệt giữa một phần phương pháp mời gọi sự xem xét kỹ lưỡng và một phần phương pháp có thể vượt qua nó.
Chính bản thân bạn trong tương lai. Hai năm sau, khi bạn viết phần thảo luận cho bài báo tiếp theo hay bảo vệ luận án, câu hỏi “mình thực sự đã dùng phương pháp nào ở đây?” sẽ dễ trả lời hơn nhiều nếu bài báo gốc của bạn đã ghi lại phương pháp, chứ không chỉ tên gói phần mềm.
Một danh sách kiểm tra nhanh
Trước khi hoàn thiện phần phương pháp, hãy tự hỏi mình với mỗi bước phân tích:
- Mình đã nêu tên kỹ thuật thực sự, chứ không chỉ công cụ, chưa?
- Nếu đó không phải là một phương pháp kinh điển, phổ biến rộng rãi, mình đã trích dẫn bài báo đề xuất hoặc kiểm chứng nó chưa?
- Mình đã nêu tên sự triển khai cụ thể (gói phần mềm, hàm, phiên bản) sau khi đã xác lập phương pháp — như một chi tiết phục vụ khả năng tái lập, chứ không phải là tiêu đề chính — chưa?
Nếu bạn có thể trả lời “có” cho cả ba câu hỏi trên, phần phương pháp của bạn đang làm đúng nhiệm vụ của nó: giúp người khác hiểu, đánh giá, và tái lập những gì bạn đã làm — chứ không chỉ những gì bạn đã nhấp chuột.