| Tiêu chí | Luận văn dự án phần mềm | Luận văn nghiên cứu truyền thống |
|---|---|---|
| Sản phẩm cuối | Hệ thống/ứng dụng/mô hình hoạt động được, có mã nguồn | Báo cáo phân tích, kiểm định giả thuyết, đóng góp lý thuyết |
| Trọng tâm đánh giá | Chất lượng thiết kế, độ chính xác mô hình, khả năng triển khai | Độ chặt chẽ của phương pháp, ý nghĩa thống kê, đóng góp học thuật |
| Chương chiếm nhiều thời gian nhất | Thiết kế hệ thống và cài đặt (implementation) | Tổng quan tài liệu và phân tích kết quả |
| Công cụ chính | Python/R, framework máy học, Git, môi trường triển khai | Phần mềm thống kê, công cụ trích dẫn |
| Phù hợp với | Sinh viên định hướng kỹ sư/ứng dụng, có sản phẩm portfolio | Sinh viên định hướng học thuật, dự định học lên cao học/tiến sĩ |
Luận văn dạng dự án phần mềm nộp một hệ thống hoặc mô hình hoạt động được kèm báo cáo mô tả quá trình xây dựng; luận văn nghiên cứu truyền thống nộp một báo cáo phân tích trả lời câu hỏi nghiên cứu bằng phương pháp khoa học. Ngành Khoa học dữ liệu chấp nhận cả hai dạng, nhưng chọn sai dạng so với định hướng nghề nghiệp khiến bạn mất thời gian làm những việc không phục vụ mục tiêu thật.
Khi nào nên chọn dạng dự án phần mềm, khi nào nên chọn dạng nghiên cứu truyền thống?
Dạng dự án phần mềm phù hợp khi mục tiêu là xây dựng một hệ thống cụ thể giải quyết một bài toán thực tế — ví dụ mô hình dự đoán churn khách hàng, hệ thống gợi ý sản phẩm, chatbot hỗ trợ tư vấn — và bạn định hướng nghề nghiệp kỹ sư dữ liệu/kỹ sư máy học sau khi tốt nghiệp, cần một sản phẩm cụ thể để đưa vào portfolio khi phỏng vấn. Dạng nghiên cứu truyền thống phù hợp khi câu hỏi nghiên cứu mang tính so sánh hoặc kiểm định — ví dụ so sánh hiệu suất của nhiều thuật toán trên cùng một bộ dữ liệu, hoặc kiểm định một giả thuyết về mối quan hệ giữa các biến — và bạn dự định học lên cao học hoặc cần rèn kỹ năng viết học thuật. Nếu bạn đang cân nhắc giữa nhiều hướng đề tài cụ thể trong ngành Công nghệ thông tin/Khoa học dữ liệu trước khi quyết định dạng luận văn, 30 hướng đề tài chốt được theo sáu nhánh chuyên môn được liệt kê trong bài đề tài đồ án tốt nghiệp ngành Công nghệ thông tin.
Cấu trúc luận văn dạng dự án phần mềm
- Đặt vấn đề và yêu cầu hệ thống. Mô tả bài toán thực tế, người dùng mục tiêu, và các yêu cầu chức năng/phi chức năng hệ thống cần đáp ứng.
- Tổng quan công nghệ và giải pháp liên quan. Điểm qua các giải pháp/mô hình đã có cho bài toán tương tự, chỉ ra hạn chế và lý do chọn hướng tiếp cận của bạn.
- Thiết kế hệ thống. Kiến trúc tổng thể, luồng dữ liệu, lựa chọn mô hình/thuật toán và lý do chọn.
- Cài đặt (implementation). Mô tả quá trình xây dựng, các thư viện/framework sử dụng, khó khăn kỹ thuật gặp phải và cách giải quyết.
- Kiểm thử và đánh giá. Chỉ số đánh giá mô hình, kết quả trên tập kiểm tra, so sánh với baseline hoặc phương pháp khác.
- Kết luận và hướng phát triển. Hạn chế hiện tại của hệ thống và hướng cải tiến trong tương lai.
Cấu trúc luận văn nghiên cứu truyền thống trong Khoa học dữ liệu
Ngược lại, dạng nghiên cứu truyền thống theo cấu trúc gần với các ngành khoa học xã hội và tự nhiên khác: đặt vấn đề và câu hỏi nghiên cứu, tổng quan tài liệu và cơ sở lý thuyết, phương pháp nghiên cứu (mô tả dữ liệu, thuật toán, thiết kế thực nghiệm), kết quả và thảo luận, kết luận. Điểm khác biệt lớn nhất với dạng dự án phần mềm nằm ở chương phương pháp: thay vì mô tả quá trình cài đặt hệ thống, chương này mô tả thiết kế thực nghiệm — biến độc lập, biến phụ thuộc, cách chia tập huấn luyện/kiểm tra, và kế hoạch so sánh thống kê giữa các phương pháp. Nguyên tắc viết chương phương pháp sao cho người khác lặp lại được nghiên cứu — sáu mục bắt buộc áp dụng cho mọi ngành — được trình bày trong bài cách viết chương phương pháp nghiên cứu.
Công cụ và nguồn dữ liệu thường dùng
| Công cụ | Dùng để làm gì |
|---|---|
| Python (pandas, scikit-learn, TensorFlow/PyTorch) | Xử lý dữ liệu, xây dựng và huấn luyện mô hình máy học/học sâu |
| Jupyter Notebook / Google Colab | Môi trường viết code, chạy thử nghiệm và trực quan hóa kết quả theo từng bước |
| Git/GitHub | Quản lý phiên bản mã nguồn, thường được yêu cầu nộp kèm luận văn dạng dự án phần mềm |
| Kaggle, UCI Machine Learning Repository | Nguồn bộ dữ liệu công khai đã được làm sạch một phần, phù hợp cho cả hai dạng luận văn |
Với dạng nghiên cứu truyền thống cần trích dẫn tài liệu kỹ thuật, các bài báo thuật toán gốc và benchmark thường công bố trên các kho như arXiv hoặc hội nghị chuyên ngành máy học; quy trình tìm kiếm tài liệu có cấu trúc — tách khái niệm, chọn đúng kho, sàng lọc hai vòng — áp dụng được cho tài liệu kỹ thuật giống như các ngành khác, được trình bày trong bài cách tìm bài báo khoa học để tham khảo.
Tiêu chí đánh giá mô hình: chọn theo loại bài toán
| Loại bài toán | Chỉ số đánh giá phù hợp |
|---|---|
| Phân loại (classification) | Accuracy, Precision, Recall, F1-score — ưu tiên Precision/Recall khi dữ liệu mất cân bằng giữa các lớp |
| Hồi quy (regression) | RMSE (căn bậc hai sai số bình phương trung bình), MAE (sai số tuyệt đối trung bình) |
| Gợi ý (recommendation) | Precision@K, Recall@K — đo chất lượng top-K gợi ý thay vì toàn bộ danh sách |
| Phân cụm (clustering) | Silhouette score — không có nhãn thật để so sánh nên cần chỉ số nội tại |
Lỗi phổ biến nhất là chỉ báo cáo Accuracy cho bài toán phân loại có dữ liệu mất cân bằng nghiêm trọng (ví dụ 95% dữ liệu thuộc một lớp) — một mô hình luôn dự đoán lớp đa số vẫn đạt Accuracy 95% mà không học được gì hữu ích, nên cần báo cáo thêm Precision và Recall để hội đồng đánh giá đúng chất lượng thật.
Ba lỗi thường gặp khi chọn và trình bày dạng luận văn
Lỗi 1: chọn dạng dự án phần mềm nhưng không có phần đánh giá định lượng. Một hệ thống chạy được không đủ — hội đồng vẫn cần thấy bằng chứng định lượng cho thấy hệ thống hoạt động tốt đến mức nào, so với baseline hoặc phương pháp khác.
Lỗi 2: trộn lẫn hai cấu trúc, vừa có chương «thiết kế hệ thống» vừa có chương «kiểm định giả thuyết» mà không rõ logic tổng thể. Nên chọn dứt khoát một dạng ngay từ đề cương và thiết kế toàn bộ cấu trúc chương theo dạng đó, tránh pha trộn nửa vời khiến hội đồng khó đánh giá theo tiêu chí nào.
Lỗi 3: không nộp kèm mã nguồn hoặc không ghi rõ phiên bản thư viện đã dùng. Với dạng dự án phần mềm, khả năng tái lập kết quả phụ thuộc vào việc ghi rõ phiên bản Python và các thư viện — thiếu thông tin này khiến người khác không chạy lại được hệ thống của bạn.
Câu hỏi thường gặp
Có thể đổi từ dạng dự án phần mềm sang dạng nghiên cứu truyền thống giữa chừng không?
Về mặt kỹ thuật có thể, nhưng tốn nhiều thời gian vì hai dạng đòi hỏi cấu trúc chương và loại bằng chứng khác nhau — nên quyết định dạng luận văn càng sớm càng tốt, ngay từ giai đoạn viết đề cương, và trao đổi rõ với giảng viên hướng dẫn.
Luận văn dạng dự án phần mềm có cần chương tổng quan tài liệu không?
Vẫn cần, nhưng thường ngắn gọn hơn và tập trung vào các giải pháp/công nghệ kỹ thuật liên quan thay vì lý thuyết học thuật rộng — mục đích là chứng minh bạn hiểu bối cảnh công nghệ trước khi chọn hướng tiếp cận của mình.
Có bắt buộc dùng deep learning để đề tài được coi là hiện đại không?
Không bắt buộc; nhiều bài toán với dữ liệu nhỏ hoặc có cấu trúc rõ ràng vẫn phù hợp hơn với các thuật toán máy học truyền thống (hồi quy, cây quyết định, rừng ngẫu nhiên) — chọn mô hình phù hợp với bài toán và lượng dữ liệu quan trọng hơn việc dùng công nghệ mới nhất.
Dùng bộ dữ liệu từ Kaggle có bị coi là thiếu tính nguyên bản không?
Không, miễn là đóng góp của bạn nằm ở phương pháp phân tích, mô hình xây dựng hoặc góc nhìn ứng dụng mới trên bộ dữ liệu đó — cần nêu rõ trong phần đóng góp bạn đã làm gì khác so với các phân tích công khai đã có trên cùng bộ dữ liệu.
Có cần triển khai (deploy) hệ thống lên môi trường thật không?
Không bắt buộc với phần lớn khóa luận đại học; một bản demo chạy được trên máy cục bộ hoặc môi trường thử nghiệm thường là đủ, trừ khi đề cương đã cam kết cụ thể việc triển khai lên môi trường sản xuất.
Nếu mô hình đạt độ chính xác thấp thì luận văn có bị đánh giá kém không?
Không nhất thiết — hội đồng đánh giá cả quá trình phân tích, lựa chọn phương pháp và khả năng giải thích tại sao kết quả như vậy, không chỉ riêng con số cuối cùng. Một phân tích trung thực về hạn chế và nguyên nhân kết quả chưa cao thường được đánh giá tốt hơn một kết quả cao nhưng thiếu giải thích.
Có thể kết hợp cả xây dựng hệ thống lẫn kiểm định giả thuyết trong một luận văn không?
Có thể ở cấp luận văn thạc sĩ hoặc luận án tiến sĩ, khi hệ thống xây dựng được dùng làm công cụ để kiểm định một giả thuyết nghiên cứu cụ thể — nhưng cần cấu trúc rõ ràng đâu là phần kỹ thuật, đâu là phần kiểm định để hội đồng đánh giá đúng từng phần.
Nếu bạn đã chọn được dạng luận văn phù hợp và cần dựng khung các chương theo đúng cấu trúc đó, Tesify giúp bạn dựng khung chương nhất quán với dạng luận văn đã chọn, rồi bạn viết và duyệt từng đề xuất thay vì nhận cả khối, và vẫn là người chịu trách nhiệm cho toàn bộ bài viết.