Định vị lỗi phần mềm dựa trên mô hình xếp loại và xử lý mất cân bằng dữ liệu

Bài toán định vị lỗi phần mềm ra đời nhắm giúp các lập trình viên tiết kiệm thời gian và công sức trong việc xác định nơi nào để bắt đầu bắt tay vào sửa lỗi. Bài toán giống như một hệ thống gợi ý đưa ra các đề xuất tệp mã nguồn có liên quan nhất với báo cáo lỗi cho lập trình viên, qua đó làm giảm không gian tìm kiếm và tiết kiệm thời gian cho những người lập trình. Nhưng để bài toán được đưa vào ứng dụng thực tế, những yếu tố như tính ổn định và sự tin cậy được các nhà phát triển quan tâm. Điều này đặt ra việc những mô hình giải quyết bài toán phải đạt được độ chính xác cao và có tính ổn định qua những lần dự đoán. Mô hình SVMBugRanking là một mô hình kế thừa Learn to rank, nhưng khắc phục nhược điểm về sự mất cân bằng trong tập dữ liệu đào tạo bằng cách thay đổi mẫu. Có hai chiến lược được đề xuất đó là lấy mẫu dưới hoặc đồng thời kết hợp giữa việc tạo dữ liệu giả và lấy mẫu dưới. Đối với những dự án có số lượng báo cáo lỗi đủ tốt thì việc tạo dữ liệu giả cho lớp thiểu số có thể làm tăng số lượng điểm nhiễu đáng kể, từ đó làm giảm hiệu suất phân loại của SVM. Nên sự kết hợp cả hai chiến lược là điều cần thiết. Kết quả của từng chiến lược đều cho kết quả tốt hơn mô hình SVMBugRanking khi chưa cải thiện trên cả ba độ đo topk@accuracy, MRR và MAP.

Định vị lỗi phần mềm dựa trên mô hình xếp loạivà xử lý mất cân bằng dữ liệu

1.2 Các giải pháp hiện tại và hạn chế 2

1.3 Mục tiêu và định hướng giải pháp 3

1.4 Đóng góp của đồ án 3

1.5 Bố cục đồ án 4

Chương 2Các nghiên cứu liên quan cho bài toán định vị lỗi 5

2.1 Nhóm nghiên cứu liên quan áp dụng mô hình học không giám sát 5

2.1.1 Mô hình Bug Locator 5

2.1.2 Công trình nghiên cứu của Gharibi và cộng sự 6

Mục lục

7

2.1.3 Mô hình BLUiR 7

2.2 Nhóm nghiên cứu liên quan áp dụng mô hình học có giám sát 9

2.2.1 Mô hình Bug Scout 9

2.2.2 Mô hình Learn2Rank 13

2.2.3 Mô hình hai pha của nhóm tác giả Kim và cộng sự 13

2.3 Nhóm nghiên cứu liên quan đến xử lý mất cân bằng dữ liệu đối với các mô hình phân loại 152.3.1 Chiến lược z-SVM 15

2.3.2 Chiến lược lấy mẫu dưới quá mức GSVM-RU 16

Chương 3Các kiến thức nền tảng 19

3.1 Mô hình SVM 19

3.1.1 Tổng quan về mô hình Support Vector Machine (SVM) 19

3.1.2 Phân loại bằng Support Vector Machine (SVM) 19

3.2 Tổng quan về các đặc trưng sử dụng 22

3.2.1 Cấu trúc dữ liệu bug report và source file 23

3.2.2 Vector Space Representation 24

3.2.3 API-Enriched Lexical Similarity Score 26

3.2.4 Collaborative Filtering Score 26

3.2.5 Classname Similarity Score 26

3.2.6 Bug-Fixing Recency Score 27

3.2.7 Bug-Fixing Frequency Score 27

Chương 4Giải pháp đề xuất 29

4.1 Tổng quan về mô hình SVMBugRanking 29

4.2 Giai đoạn tiền xử lý 31

4.2.1 Tiền xử lý cho các source files 31

4.2.2 Tiền xử lý cho bug files 32

6.2 Hướng phát triển trong tương lai 44

Tài liệu tham khảo 45

Hình 4: Mơ hình một pha của Kim và cộng sự 14

Hình 5: Mơ hình thuật tốn GSVM-RU 17

Hình 6: Mơ hình classes cho SVM 20

Hình 7 : Mơ hình classes cho SVM 21

Hình 8 : Cấu trúc dữ liệu của một bug report 23

Hình 9 : Cấu trúc dữ liệu của một source file 23

Hình 10 : Vector đại diện cho truy vấn và docs 24

Hình 11 : Mơ hình tổng quan SVMBugRanking 30

Hình 12 : Tập dữ liệu trên 6 dự án 36

Hình 13 : Bảng dữ liệu so sánh Learn to rank với Bug Locator và Nạve Bayes 37

Hình 14: Top1 trên từng đặc trưng trên dự án Tomcat 38

Hình 15: Top1 accuracy của từng đặc trưng trên dự án AspectJ 39

Hình 16: Top1 accuracy của từng đặc trưng trên dự án SWT 39

Hình 17: Top1 accuracy của từng đặc trưng trên dự án Eclipse 40

Hình 18: Top1 accuracy của từng đặc trưng trên dự án JDT 40

Hình 19: Top1 accuracy của từng đặc trưng trên dự án Birt 41

Hình 20: Giá trị MRR trên SVMBugRanking và 2 chiến lược cải thiện 42

Hình 21: Giá trị MAP trên SVMBugRanking và 2 chiến lược cải thiện 43

10

Công thức 1 Vector trọng số trong SVM 16

Công thức 2 Hàm decision function trong SVM 16

Công thức 3 Hàm cải tiến tham số z-SVM 16

Công thức 4 Tần suất xuất hiện của một từ văn bản 25

Công thức 5 Giá trị idf của một từ 25

Công thức 6 Giá trị tf-idf của một từ trong tập văn bản 25

Công thức 7 Giá trị điểm collaborative filtering score 26

Công thức 8 Giá trị điểm classname similarity score 27

Công thức 9 Giá trị điểm bug-fixing recency score 27

Công thức 10 Giá trị điểm bug-fixing frequency score 28

Công thức 11 Hàm score function của mô hình SVMBugRanking 29

Công thức 12 Công thức tính MRR 33

Công thức 13 Công thức tính MAP 33

Danh mục công thức

Term Frequency-Inverse Document Frequency

Đo tần xuất xuất hiện của từ kết hợp với tần suất tài liệu chứa thuật ngữ đó

Support Vector Machine

Một mô hình học máy có giám sát

12

13

Bug report Báo cáo lỗi

Source file Tệp mã nguồn

Comment Chú thích

Undersampling Quá trình lấy mẫu dưới

Oversampling Quá trình lấy mẫu trên

Danh mục thuật ngữ

1

1.1 Đặt vấn đề

Trong quá trình phát triển phần mềm, kiểm thử, sửa lỗi và bảo trì phần mềm chiếm hơn 50% thời gian của dự án Để tăng hiệu quả của công việc, các tác vụ khác nhau trong quá trình phát triển dự án phần mềm sẽ được quản lý bằng các công cụ đặc biệt, ví dụ quản lý mã nguồn bằng các công cụ quản lý phiên bản (Version Control System), quản lý lỗi sử dụng các hệ thống theo dõi lỗi (Bug Tracking System) Các Bug Tracking System như Jira, Bugzilla, cho phép quản lý và theo vết quá trình sửa các lỗi trong hệ thống cũng như các tệp mã nguồn có liên quan và đã được cập nhật thay đổi để sửa các lỗi đó Khi có một lỗi (bug) xảy ra, người phát hiện lỗi sẽ thông báo lỗi trên hệ thống bao gồm các mô tả về lỗi, ngữ cảnh xảy ra, các thông tin cụ thể để có thể tái tạo lại lỗi trên hệ thống Khi lỗi được xác nhận (confirmed), một hoặc một vài kỹ sư phát triển sẽ được chỉ định để sửa lỗi Qúa trình sửa lỗi đó bao gồm công việc phải xác định được các tệp (file) mã nguồn có liên quan để tiến hành sửa lỗi Khi lỗi đã được sửa, các file mã nguồn liên quan sẽ được hệ thống Bug Tracking System ghi nhận cùng với các commit tương ứng mà kỹ sư phát triển đã tạo ra để ghi nhận vết của lỗi Quá trình định vị các file mã nguồn có liên quan đến lỗi được gọi là bug localization Bug localization là một tác vụ phức tạp, đòi hỏi rất nhiều công sức của con người và không hề dễ dàng nhất là khi dự án phần mềm chứa hàng nghìn file mã nguồn từ đó làm nảy sinh nhu cầu cấp thiết cho vấn đề định vị lỗi phần mềm tự động

Đối với bài toán định vị lỗi phần mềm tự động, việc xác định một cách chính xác các file mã nguồn có lỗi là một việc vô cùng khó khăn Do đó, các nghiên cứu hiện tại về định vị lỗi phần mềm chỉ dừng lại ở bước gợi ý các file mã nguồn có thể liên quan đến bug Bug Localization do đó có thể được xem xét như một bài toán phân loại, ứng với mỗi bug report, các file mã nguồn sẽ được phân vào hai nhóm (i) có liên quan đến bug và (ii) không có liên quan đến bug

Để giải quyết cho bài toán phân loại nói trên, các nghiên cứu tập trung vào trích xuất các mối liên quan giữa bug report và các source files Các source files nào có mối liên quan nhiều nhất sẽ được phân vào nhóm có liên quan đến bug Vấn đề trích xuất thông tin để xác định các mối liên quan trong các văn bản (text document) được nghiên cứu từ rất lâu và đã

Chương 1 Giới thiệu đề tài

2 có rất nhiều thành tựu Tuy nhiên thách thức lớn nhất đối với bài toán định vị lỗi phần mềm đến từ sự khác biệt về mặt ngôn ngữ giữa bug report và source file Cụ thể, các bug report thì thường được mô tả bằng ngôn ngữ tự nhiên trong khi các source file lại được viết bằng ngôn ngữ lập trình Sự khác biệt về mặt ngữ nghĩa và từ vựng giữa hai loại ngôn ngữ dẫn tới việc xác định mối liên quan trở nên khó khăn và có kết quả không cao

Thách thức tiếp theo đối với bài toán phân loại trong bug localization đến từ sự mất cân bằng dữ liệu giữa hai nhóm (i) có liên quan đến bug và (ii) không liên quan đến bug Đối với một bug report, số lượng source file có liên quan đến bug ít hơn rất rất nhiều so với các source file không liên quan đến bug Độ chính xác của mô hình phân loại phụ thuộc rất nhiều vào sự cân bằng giữa các nhóm vì khi mất cân bằng, mô hình phân loại sẽ có xu hướng dự đoán vào nhóm có dữ liệu lớn (majority class) hơn là vào nhóm có dữ liệu ít (minority class) Các vấn đề này đến nay vẫn là thách thức lớn của bài toán bug localization

1.2 Các giải pháp hiện tại và hạn chế

Các nghiên cứu hiện nay tiếp cận giải quyết bài toán bug localization theo hai hướng (i) học máy có giám sát và (ii) học máy không giám sát Đối với hướng tiếp cận học máy không giám sát, mô hình sẽ tính điểm số (score) cho mức độ liên quan giữa mỗi báo cáo lỗi và với tệp mã nguồn để đưa ra phân loại tệp nằm đâu trong hai cụm: có liên quan đến lỗi hoặc không liên quan đến lỗi Tệp có điểm số cao sẽ thuộc về nhóm “có liên quan đến lỗi” và các tệp còn lại thuộc nhóm “không liên quan đến lỗi” Đối với hướng tiếp cận học máy có giám sát, một mô hình huấn luyện được xây dựng với đầu vào dữ liệu là các cặp bug-source được gán nhãn (“có liên quan”-1 và “không liên quan”-0) Mô hình được huấn luyện xong sẽ được dùng để dự đoán đối với 1 bug mới, những file mã nguồn nào có liên quan So với cách tiếp cận học ko giám sát, các mô hình học có giám sát phức tạp hơn rất nhiều và đòi hỏi quá trình huấn luyện với dữ liệu gán nhãn trước nhưng bù lại kết quả của các mô hình học giám sát thường cao hơn

Trong khuôn khổ đồ án của mình, em tập trung vào hướng thứ 2, tìm hiểu các mô hình học giám sát để giải quyết bài toán định vị lỗi phần mềm Các nghiên cứu hiện tại áp dụng các mô hình mạng nơ-ron hoặc các thuật toán học máy như Learn-2-Rank, Support Vector Machine – SVM,… Hai vấn đề chính được tập trung giải quyết trong hướng nghiên cứu này (1) Trích xuất đặc trưng để có thể phát hiện được các mối liên quan tiềm ẩn giữa bug và source khi ngôn ngữ biểu diễn hai đối tượng này có sự khác biệt khá lớn, (2) Cải tiến độ chính xác của các mô hình bằng cách giải quyết vấn đề mất cân bằng dữ liệu Đối với vấn đề thứ nhất, các đặc trưng hiện nay được đề xuất được xếp loại vào 3 nhóm: (i) đặc trưng từ vựng (lexical feature) (ii) đặc trưng ngữ nghĩa (semantic feature) (iii) đặc trưng về domain

3 liên quan đến tần suất lỗi, lịch sử sửa lỗi… Cách kết hợp các đặc trưng thì dựa trên hai hướng (i) kết hợp tuyến tính và (ii) kết hợp phi tuyến Các nghiên cứu hiện nay tập trung vào đề xuất các mô hình để có thể kết hợp tốt nhất các đặc trưng này nhằm phát hiện rõ hơn mối liên quan tiềm ẩn giữa bug và source Tuy nhiên việc kết hợp các đặc trưng vẫn là một vấn đề cần phải giải quyết để có thể trích xuất tốt hơn mối quan hệ giữa bug và source Đối với vấn đề thứ hai, chưa có nhiều nghiên cứu hiện tại xử lý vấn đề mất cân bằng dữ liệu cho bài toán định vị lỗi phần mềm, tuy nhiên giải pháp chung để giải quyết vấn đề này có thể được chia thành 2 hướng: (i) Xử lý mẫu (sampling) để thay đổi sự mất cân bằng dữ liệu mẫu (ii) Áp dụng thêm các thuật toán học tăng cường hoặc thay đổi kiến trúc mô hình để có thể đưa thêm trong số nhằm định hướng lại mô hình khi phân loại

Nghiên cứu của em tập trung vào hướng thứ nhất trong xử lý mất cân bằng dữ liệu và đề xuất mô hình kết hợp tuyến tính các đặc trưng của bug-source Chi tiết về giải pháp được giới thiệu trong phần tiếp theo

1.3 Mục tiêu và định hướng giải pháp

Từ các vấn đề về hiện trạng và hạn chế đã được giới thiệu ở trên, trong đồ án này của mình em tập trung vào đề xuất mô hình học máy giám sát để định vị lỗi phần mềm, trong đó xử lý vấn đề mất cân bằng dữ liệu thông qua xử lý mẫu với hai giải pháp (1) undersampling và (2) oversampling

Cụ thể, giải thuật học máy đề xuất là Support Vector Machine cho phép xây dựng mô hình phân loại source cho các bug với các đặc trưng đề xuất sử dụng thuộc cả 3 nhóm đã đề cập trong phần trước: (1) Độ tương đồng từ vựng (2) Độ tương đồng ngữ nghĩa (3) Các đặc trưng về tần suất sửa lỗi, độ tương quan giữa các bug Trên thực tế việc lựa chọn các đặc trưng đóng vai trò khá quan trọng trong các bài toán phân loại, các nghiên cứu liên quan xử lý đặc trưng riêng lẻ với các đề xuất khác nhau Trong đồ án này của mình em kết hợp các đặc trưng được đề xuất này và sử dụng mô hình SVM để huấn luyện sự kết hợp giữa các đặc trưng

Đối với vấn đề mất cân bằng dữ liệu, trong nghiên cứu của mình em kết hợp mô hình SVM đã đề xuất với hai kỹ thuật xử lý mẫu là undersampling và oversampling và đánh giá sự hiệu quả của hai kỹ thuật này đối với bài toán định vị lỗi phần mềm

1.4 Đóng góp của đồ án

Đồ án tốt nghiệp có 3 đóng góp chính như sau:

4 1 Đề xuất xây dựng mô hình SVM và triển khai mô hình cho bài toán định vị lỗi phần mềm trong đó kết hợp nhiều nhóm đặc trưng với nhau để có thể trích xuất hiệu quả mối tương quan của các cặp bug-source

2 Đánh giá vai trò và mức độ tác động của các đặc trưng và các nhóm đặc trưng đối với hiệu năng của mô hình

3 Đề xuất chiến lược giải quyết vấn đề mất cân bằng dữ liệu trong bài toán phân loại dựa trên việc thay đổi mẫu

1.5 Bố cục đồ án

Phần còn lại của báo cáo đồ án tốt nghiệp này được tổ chức như sau

Chương 2 em trình bày về những nghiên cứu liên quan trong việc giải quyết bài toán định vị lỗi phần mềm Trong chương này em sẽ tập trung vào hai hướng tiếp cận chính: áp dụng mô hình học máy có giám sát và mô hình học máy không giám sát Ngoài ra, em trình bày những nghiên cứu liên quan đến những nghiên cứu liên quan đến làm giảm mất cân bằng dữ liệu trong các bài toán phân loại

Chương 3 em trình bày các kiến thức cơ sở của mô hình, các đặc trưng trích xuất được giữa bug và source

Chương 4 trình bày giải pháp đề xuất về mô hình SVM và việc xử lý mất cân bằng dữ liệu Chương 5 trình bày các thực nghiệm để đánh giá giải pháp đề xuất

Chương 6 đưa ra những kết luận về mô hình SVMBugRanking và sau đó trình bày về tương lai của bài toán định vị lỗi phần mềm

5 Trong chương này, em sẽ trình bày về hai hướng nghiên cứu liên quan trong bài toán định vị lỗi phần mềm, áp dụng mô hình học không giám sát và mô hình học có giám sát

2.1 Nhóm nghiên cứu liên quan áp dụng mô hình học không giám sát

2.1.1 Mô hình Bug Locator

Nhóm tác giả Jian Zhou và cộng sự [11] đã đề xuất mô hình Bug Locator, một phương pháp dựa trên việc trích xuất thông tin để xác định đâu là tệp có liên quan đến báo cáo lỗi cần phải sửa Bug Locator xếp hạng các tệp mã nguồn dựa trên độ tương đồng về mặt từ ngữ giữa báo cáo lỗi và tệp nguồn, sử dụng revised Vector Space Model (rVSM) và những báo cáo lỗi đã được sửa trong quá khứ Bug Locator tính toán và tổng hợp 2 ranking scores: rVSM và Simiscore

Đầu tiên, để tối ưu lại mô hình cổ điển Vector Space Model, rVsm chú trọng đến độ dài của tài liệu Nếu một tệp có kích thước càng lớn thì sẽ tổn tại nhiều rủi ro hơn, chứa nhiều lỗi hơn các tệp có kích thước nhỏ Mô hình sẽ tính mức độ liên quan giữa truy vấn đó với toàn bộ tệp nguồn (source files) Mỗi truy vấn và tệp nguồn đều được biểu diễn dưới dạng vector, được thực hiện bởi sự kết hợp giữa việc tính toán 2 đại lượng: tần suất xuất hiện các thuật ngữ (Term Frequency) và tần suất của tài liệu chứa thuật ngữ đó (Inverse Document Frequency) RVSM score được tính bằng cosin giữa 2 vector biểu diễn báo cáo lỗi và tệp thu được

Tiếp đến, Bug Locator tính độ tương đồng cosine giữa báo cáo lỗi S với những báo cáo lỗi đã được sửa trước khi S báo cáo Giả sử một báo cáo lỗi B có sự tương đồng với báo cáo lỗi S Khi đó, tất cả những tệp nguồn gây ra báo cáo lỗi B hình thành một mối liên kết tới S

Đối với mỗi tệp nguồn s, ta thu được danh sách các báo cáo lỗi {𝐵1, 𝐵2, , 𝐵𝑛} có hình

Chương 2 Các nghiên cứu liên quan cho bài toán định vị lỗi

6 thành liên kết đến S tương tự như B Điểm số tương đồng Simiscore cho báo cáo lỗi S với

mỗi tệp nguồn s được tính bằng tổng cosine giữa S với từng báo cáo lỗi 𝐵𝑖 với 𝑖 = 1 𝑛 Final score sẽ là tổng hợp điểm số của rVsm và Simiscore Từ đó Bug Locator đề xuất danh sách tệp nguồn có điểm số cao nhất, chính là những tệp có khả năng cao gây ra lỗi nhất Tác giả đã đánh giá hiệu suất của mô hình dựa trên bốn dự án: Eclipse, SWT, AspectJ và Zxing và sử dụng 3 độ đo Top N Rank, Mean Reciprocal Rank (MRR), Mean Average và Precision (MAP) Kết quả thực nghiệm cho thấy Bug Locator cho hiệu suất cao hơn các phương pháp hiện có LDA thực hiện bởi Lukins et al [12], SUM thực hiện bởi Rao và Kak [13], VSM được thực hiện bởi Rao and Kak [13], LSI được thực hiện bởi Poshyvanyk et al [14], [15]

2.1.2 Công trình nghiên cứu của Gharibi và cộng sự

Mô hình tiếp cận của công trình nghiên cứu [19] :

Hình 1 Mô hình đề xuất của Gharibi và cộng sự

Đầu tiên là quá trình tiền xử lý Mỗi tệp nguồn sẽ được trích xuất ra những thông tin quan trọng: tên lớp, tên thuộc tính, tên phương thức và khai báo biến Trong khi đó mỗi báo cáo lỗi được trích xuất để có được mô tả, tóm tắt và ngày báo cáo Sau đó, nếu mô tả của báo cáo lỗi có truy vết (stack traces) thì nó sẽ được trích xuất Kết quả thu được lần lượt sẽ được chuẩn hóa để thu được các cụm từ có sự thống nhất cao, giúp nâng cao hiệu suất phân tích sự tương đồng về từ ngữ

7 Sau giai đoạn tiền xử lý là 5 đặc trưng (component) sẽ tính điểm cho tệp nguồn với mỗi báo cáo lỗi Các đặc trưng gồm có: token matching component, VSM similarity component, stack trace component, semantic similarity component và fixed bug reports component Sau đó, điểm số cuối cùng cho mô hình là một hàm tuyến tính tổng hợp 5 components, mỗi component tương ứng như một biến có trọng số riêng Mục tiêu ở đây là tối ưu tham số (trọng số) sao cho tổng giá trị MRR và MAP đạt giá trị lớn nhất

Bài báo sử dụng thuật toán tiến hóa vi phân (DE) [20] để tối ưu hóa hàm mục tiêu và ước tính các tham số DE là một phương pháp dựa trên quần thể ngẫu nhiên được sử dụng cho bài toán tối ưu hóa toàn cục và có thể tìm kiếm các vùng rộng lớn trong không gian các ứng cử viên Nó cố gắng lặp đi lặp lại để cải thiện kết quả bằng cách trộn chúng với nhau để tạo ra một ứng cử viên thử nghiệm

B Tập dữ liệu

Bài báo sử dụng tập dữ liệu chuẩn do Zhou và cộng sự cung cấp với ba dự án: AspectJ, SWT, ZXing và sử dụng 3 độ đo chuẩn Top@N, MRR, and MAP Kết quả cho thấy cách tiếp cận của nghiên cứu tốt hơn hẳn những phương pháp hiện thời bao gồm BugLocator (Zhou et al., 2012) [11], BLUiR (Saha et al., 2013) [16], BRTracer (Rahman et al., 2015; Wong et al., 2014) [21], và AmaLgam (Wang & Lo, 2014) [22]

2.1.3 Mô hình BLUiR

Saha và các cộng sự đề xuất mô hình BLUiR (Improving bug localization using structured information retrieval) [16] giúp tự động định vị lỗi dựa trên việc trích xuất thông tin có cấu trúc Thay vì xây dựng lại từ đầu, tác giả sử dụng một toolkit trích xuất thông tin mã nguồn mở có khả năng tinh chỉnh cao như Indri [17]

A Kiến thức nền tảng về IR:

Ví dụ cơ bản về việc định vị lỗi dựa trên IR đó là việc 1 số thuật ngữ được trích xuất từ báo cáo bug có được tìm thấy trong tệp mã nguồn cần sửa cho lỗi đó hay không Kỹ thuật sẽ tìm thấy các từ phù hợp tồn tại cả trong báo cáo lỗi và một trong tệp mã nguồn tương ứng được sửa cuối cùng cho lỗi đó Từ đó hệ thống có thể đưa ra các dự đoán xếp hạng cho các tệp nguồn cần được sửa

8 Một hệ thống IR thường bắt đầu với ba bước tiền xử lý: text normalization (việc loại bỏ các dấu câu, thực hiện chuẩn hóa các chữ cái về cùng dạng), stop-word removal (những từ không liên quan, không quan trọng) và stemming (vụ hợp nhất biến thể khác nhau ví dụ như “play”, “playing”, “played”)

Sau khi tiền xử lý xong, các số liệu thống kê khác nhau như: tần suất thuật ngữ (TF, số lần thuật ngữ xuất hiện trong một tài liệu nhất định), tần suất tài liệu (DF, số lượng tài liệu trong đó thuật ngữ xuất hiện), IDF (tần suất xuất hiện tài liệu chứa thuật ngữ đó) được thu thập Từ đó chúng ta thu được TF-IDF, một thống kê phản ánh tầm quan trọng một từ đối với một văn bản trong một tập hợp văn bản

B Cách tiếp cận mô hình Kiến trúc mô hình BLUiR

Hình 2: Mô hình BLUiR

Đầu tiên, đầu vào là mã nguồn của các báo cáo lỗi tương ứng Sau đó cây cú pháp trừu tượng (AST) được khởi tạo cho mỗi tệp mã nguồn sử dụng công cụ JDT, trích xuất được các thông tin: tên lớp, tên phương thức, tên biến và các chú thích Tất cả thông tin thu được sẽ được tokenize và lưu dưới dạng cấu trúc XML Và chúng cũng được loại bỏ stopword, stemming và đánh chỉ mục

Mỗi báo cáo lỗi tương tự cũng được tokenize, sau đó loại bỏ stopword, stemming và trích xuất thông tin

C Mô hình trích xuất thông tin

9 Thật ra, TF-IDF không phải là một mô hình được xác định rõ ràng và mỗi biến thể của nó cho ra những kết quả khác nhau trong thực tế Bài báo đã áp dụng công thức TF-IDF tích hợp của Indri (từ dự án Lemur) dựa trên mô hình BM25 (Okapi) [18] Mô hình này được áp dụng và sử dụng rộng rãi trong IR hơn một thập kỷ

D Kết hợp thông tin có cấu trúc

Có một nhược điểm khi mô hình TF-IDF không phân biệt cấu trúc mã nguồn (cấu trúc chương trình) – nghĩa là mỗi thuật ngữ trong tệp mã nguồn được coi là có cùng mức độ liên quan đối với truy vấn đã cho Do đó, các thông tin quan trọng như tên lớp và tên phương thức thường bị mất đi trọng số vì sự xuất hiện số lượng lớn tên biến và chú thích

Mô hình đề xuất của bài báo phân biệt cấu trúc code để khắc phục vấn đề này Cụ thể báo cáo lỗi được lấy ra 2 truy vấn cụ thể là summary và description trong khi cấu trúc mã nguồn được trích xuất bốn trường tài liệu khác nhau: lớp, phương thức, biến, chú thích Để khai thác tất cả các kiểu biểu diễn giữa truy vấn và tài liệu khác nhau này, bài báo sẽ đánh giá tám tổ hợp thu được (các đại diện truy vấn, trường tài liệu) và sau đó lấy tổng điểm trên tất cả tám tìm kiếm

Lợi ích của mô hình này là các trường tài liệu đều đã có trọng số riêng của nó Nên thuật ngữ xuất hiện ở nhiều trường tài liệu khác nhau thì sẽ có trọng số lớn hơn Không còn xảy ra trường hợp sự số lượng thuật ngữ xuất hiện ở chú thích hay tên biến áp đảo số lượng thuật ngữ xuất hiện ở tên lớp hay tên phương thức

E Bộ dữ liệu kiểm thử

Bài báo đã sử dụng cùng một tập dữ liệu mà Zhou sử dụng để đánh giá BugLocator [11] Tập dữ liệu này chứa 3379 báo cáo lỗi tổng cộng trong số bốn dự án mã nguồn mở - Eclipse, AspectJ, SWT và ZXing cùng với thông tin các tệp đã được sửa cho những lỗi đó Bài báo muốn so sánh BLUiR với BugLocator trên cùng một tập dữ liệu Kết quả cho thấy rằng trong hầu hết các trường hợp, BLUiR hoạt động tốt hơn về tất cả các chỉ số

2.2 Nhóm nghiên cứu liên quan áp dụng mô hình học có giám sát

2.2.1 Mô hình Bug Scout

Bài báo đề xuất mô hình BugScout [1] một cách tiếp cận tự động giúp các nhà phát triển dễ dàng trong việc định vị lỗi bằng cách thu hẹp không gian tìm kiếm các tệp lỗi Mô hình xây dựng các kỹ thuật dưới dạng chủ đề trong nội dung văn bản của báo cáo lỗi và tập nguồn,

10 đồng thời so sánh báo cáo lỗi và tệp lỗi tương ứng thông qua các chủ đề được chia sẻ BugScout có thể đề xuất các tệp lỗi một cách chính xác lên đến 45% các trường hợp với top10 ranking

Trong số các loại thực thể khác trong hệ thống, BugScout sử dụng đến hai loại thực thể: tệp nguồn và báo cáo lỗi Mô hình BugScout có hai thành phần cho hai loại đó: Thành phần S cho các tệp nguồn và Thành phần B cho các báo cáo lỗi

A- Thành phần S

Thành phần S trong BugScout là một mô hình LDA (Latent Dirichlet Allocation) [2] Mỗi tệp nguồn thì được coi là một tài liệu s Nội dung từ chú thích (comments) và định danh (identifiers) được trích xuất để tạo thành các từ có trong tài liệu s

Topic Vector Một tài liệu s có 𝑁𝑠 từ Mỗi từ trong 𝑁𝑠 được coi là miêu tả một chủ đề kỹ thuật cụ thể Cho nên chúng ta có vector chủ đề 𝑧𝑠 với độ dài 𝑁𝑠

Topic Proportion Để thể hiện tầm quan trọng của nhiều chủ đề trong tài liệu 𝜃𝑠 là một vector có k phần tử tương ứng với k chủ đề có trong tài liệu s, giá trị mỗi phần đại diện cho

tỷ lệ chủ đề tương ứng trong s

Vocabulary and Word Selection Vocabulary là tập hợp các từ có trong dự án, được gọi là 𝑉 𝑜𝑐 𝑣ớ𝑖 kích thước là 𝑉 Mỗi từ trong 𝑉 𝑜𝑐 có tần suất xử dụng khác nhau để mô tả một

chủ đề k và một chủ đề có thể chứa một hoặc nhiều từ Mỗi chủ đề k sẽ có tương ứng một

vector chọn từ (vector word-selection) 𝜙𝑘, kích thức 𝑉 Mỗi phần tử đại diện cho tần suất

sử dụng của từ trong V oc để mô tả chủ đề k Ví dụ, đối với chủ đề k, 𝜙𝑘 = [0,3, 0,2, 0,4, ]

Nghĩa là, trong 30% trường hợp, từ đầu tiên trong V oc được sử dụng để mô tả chủ đề k, 20% trường hợp từ thứ hai được sử dụng để mô tả k

Đối với một hệ thống phần mềm, mỗi chủ đề k có vectơ riêng 𝜙𝑘 thì k chủ đề có thể được biểu diễn bằng ma trận K × V 𝜙𝑠𝑟𝑐, được gọi là phân phối từ theo chủ đề

B Thành phần B

Thành phần B cũng được mở rộng từ LDA [2] Tương tự như thành phần S, thành phần B

cũng coi mỗi báo cáo lỗi b là một tài liệu với ba biến 𝑧𝑏, 𝜃𝑏, 𝜙𝐵𝑅 Chú ý rằng 𝜙𝐵𝑅 áp dụng cho tất cả các báo cáo lỗi và nó khác với 𝜙𝑠𝑟𝑐 Báo cáo lỗi b không chỉ bị ảnh hưởng bởi

phân phối chủ đề của chính nó mà còn bởi các tham số phân phối chủ đề của các tệp nguồn lỗi tương ứng với báo cáo lỗi đó

11 Ví dụ 𝑠1, 𝑠2, , 𝑠𝑀 để biểu thị các tệp nguồn (lỗi) có liên quan đến một báo cáo lỗi b Ta có: 𝜃𝑏∗ = 𝜃𝑠1 𝜃𝑠2 𝜃𝑠𝑀 𝜃𝑏 Phương trình trên đại diện cho việc chia sẻ các chủ đề lỗi trong báo cáo lỗi và các tệp nguồn tương ứng

C Mô hình Bug Scout

Hình 3: Mô hình BugScout

Thành phần S và thành phần B được kết hợp thành BugScout

Đối với báo cáo lỗi b, trong mặt thành phần B, có 3 biến của b: 𝑧𝑏, 𝜃𝑏, 𝜙𝐵𝑅

Tuy nhiên, nếu các tệp nguồn 𝑠1, 𝑠2, , 𝑠𝑀 được xác định là gây ra lỗi được báo cáo trong

báo cáo lỗi b, vectơ chủ đề 𝑧𝑏 sẽ bị ảnh hưởng bởi tỷ lệ chủ đề của các tệp nguồn đó Tức là có các liên kết từ 𝜃𝑠1, 𝜃𝑠2, , 𝜃𝑠𝑀 đến 𝑧𝑏

Đối với mỗi tài liệu nguồn, có 3 biến: 𝑧𝑠, 𝜃𝑠, 𝜙𝑠𝑟𝑐 𝛼 𝑣à 𝛽 là hai tham số được giả đinh như trong LDA

Dữ liệu bao gồm tệp nguồn, báo cáo lỗi và liên kết giữa báo cáo lỗi và tệp nguồn tương ứng sẽ được cho vào đào tạo Các biến của BugScout sẽ được đào tạo để lấy các tham số sao làm cho mô hình phù hợp nhất với tập dữ liệu đầu vào

Để dự đoán, mô hình sẽ được áp dụng cho một báo cáo lỗi mới qua các tham số được đào tạo từ trước Từ đó ước tính tỷ lệ chủ đề mới 𝜃𝑏𝑛𝑒𝑤 Tỷ lệ chủ đề này được dùng để tìm các

12 tệp nguồn tương ứng mà chia sẻ cùng chủ đề nhiều nhất Chủ đề của báo cáo lỗi đó được so sánh với các chủ đề từ tất cả tệp nguồn, các tệp đã chia sẻ chủ đề với báo cáo lỗi mới sẽ được xếp hạng và đề xuất cho nhà phát triển

D Thuật toán training

Mục tiêu của thuật toán là ước lượng những tham số của BugScout trong việc đào tạo dữ liệu Thuật toán được dựa trên phương pháp Gibbs sampling [3] Sau đây là các bước chi tiết:

Bước 1: Ước tính việc phân phối chủ đề cho các tài liệu nguồn trong S

Với mỗi tài liệu s trong S, BugScout ước tính 𝑧𝑠[𝑖] cho vị trí i

Bước 2: Ước tính tỷ lệ chủ đề 𝜃𝑠 cho một tệp nguồn

Tỷ lệ chủ đề 𝜃𝑠[𝑘] của chủ đề k trong tài liệu đó có thể được tính gần đúng bằng cách chỉ cần tính tỷ lệ giữa số lượng từ mô tả chủ đề k và độ dài của tài liệu

Bước 3: Ước tính phân phối từ 𝜙𝑠𝑟𝑐

𝜙𝑠𝑟𝑐[𝑤𝑖] có thể được tính gần đúng bằng tỷ số giữa số lần từ thứ i trong V oc được sử dụng

để mô tả chủ đề k trên tổng số lần bất kỳ từ nào được sử dụng để mô tả k Bước 4: Ước tính việc phân phối chủ đề 𝑧𝑏[𝑖] cho các báo cáo lỗi trong B

Bước 5: Ước tính tỷ lệ chủ đề 𝜃𝑏 cho một báo cáo lỗi b và ước tính phân phối từ 𝜙𝐵𝑅 Các bước ước lượng đó tương tự như các bước cho 𝜃𝑠 và 𝜙𝑠𝑟𝑐

E Tập dữ liệu

Bài báo sử dụng một số bộ dữ liệu trong các dự án phần mềm khác nhau bao gồm Jazz (một khung phát triển của IBM), Eclipse (một môi trường phát triển tích hợp), AspectJ (một trình biên dịch cho lập trình hướng khía cạnh) và ArgoUML (một trình soạn thảo đồ họa cho UML) Các bộ dữ liệu Eclipse, ArgoUML và AspectJ có sẵn công khai và đã được sử dụng làm tiêu chuẩn trong nghiên cứu định vị tệp lỗi trước đây

Nguyen và cộng sự đã phát triển một mô hình chủ đề chuyên biệt, đại diện cho các khía cạnh kỹ thuật trong nội dung văn bản của báo cáo lỗi và tệp nguồn dưới dạng chủ đề, đồng thời so sánh các báo cáo lỗi và tệp lỗi thông qua các chủ đề được chia sẻ Kết quả thực nghiệm cho thấy BugScout chính xác trong việc định vị các tệp lỗi và làm tốt hơn các phương pháp

hiện có: SVM-based bởi Premraj et al [4] và LDA-VSM bởi Premraj et al [5]

13

2.2.2 Mô hình Learn2Rank

Tác giả Xin Ye và cộng sự của mình đã đưa ra cách tiếp cận sử dụng kỹ thuật rank [9] để đưa ra đề xuất những tệp có khả năng gây ra lỗi nhất với báo cáo lỗi cần dự đoán

learning-to-Mô hình được triển khai dựa trên một hàm tuyến tính f (r, s) được hình thành từ các đặc

trưng có sẵn (features) Đặc trưng chính là sự phản ánh mức độ tương đồng về một khía cạnh nào đó của một cặp báo cáo lỗi (report) và tệp nguồn (source) Tác giả đề xuất 6 đặc trưng bao gồm: Surface Lexical Similarity, API-Encriched Lexical Similarity, Collabrative Filtering Score, Class Name Similarity, Bug-Fixing Recency và Bug-Fixing Frequency 6 đặc trưng này được kết hợp lại thành một vector đặc trưng cho một cặp báo cáo lỗi và tệp

nguồn Mỗi phần tử của vector này tương ứng với một biến của hàm tuyến tính f (r, s) Mục

đích của mô hình là đi tìm các trọng số phù hợp cho từng đặc trưng Mô hình Support Vector Machine là một mô hình phân loại có thể giải quyết được bài toán này Để áp dụng được mô hình, mỗi vector đặc trưng thu được sẽ được đánh nhãn 0 hoặc 1 Nếu tệp nguồn gây ra báo cáo lỗi thì tương ứng với nhãn 1, ngược lại sẽ được gán nhãn 0 Mô hình SVM đào tạo dữ liệu đầu vào bao gồm các vector đặc trưng giữa báo cáo lỗi với tệp nguồn cùng với nhãn của chúng Sau quá trình đào tạo, SVM tính toán được các trọng số ứng với từng đặc trưng để

đưa ra điểm số cuối cùng cho hàm f (r, s) Điểm số này dùng để đánh giá mức độ tương đồng

giữa một cặp bug source Nếu điểm số càng cao, khả năng tệp nguồn đó là tệp gây ra lỗi càng cao Từ ý tưởng đó, mô hình sẽ đề xuất danh sách các tệp có khả năng gây ra lỗi cao nhất

Tác giả đã sử dụng 6 dự án mã nguồn mở viết bằng Java được công khai và được sử dụng rộng rãi: Tomcat, AspectJ, SWT, Eclipse Platform UI, JDT và Birt Tác giả đã sử dụng 3 độ đo topk@accuracy, MRR và MAP để so sánh hiệu suất giữa các mô hình Kết quả cho thấy Learn2Rank đề xuất chính xác hơn hẳn những phương pháp hiện thời như BugScout [1] và BugLocator [10]

2.2.3 Mô hình hai pha của nhóm tác giả Kim và cộng sự

Tác giả Kim và cộng sự đưa ra phương pháp [6] sử dụng mô hình học máy để tự động gợi ý tệp có khả năng cao gây ra lỗi nhất dựa trên nội dung từ báo cáo lỗi

A Cách thức trích xuất dữ liệu

Vì cách tiếp cận của bài báo sử dụng mô hình học máy, nên một báo cáo lỗi được chuyển thành một vector đặc trưng Các giá trị: bản tóm tắt, bản mô tả và meta-data (phiên bản, nền tảng, hệ điều hành, mức độ ưu tiên, mức độ nghiêm trọng và người báo lỗi) của một báo cáo được trích xuất

14 Sau đĩ, quá trình tiền xử lý diễn ra: tách tokens, loại bỏ stop words, stemming, để thu được các tokens cĩ giá trị sử dụng cao

Những chú thích (comments) được thêm bởi chính người báo cáo lỗi trong vịng 24 giờ sẽ được coi như là một phần của bản mơ tả bởi vì chú thích này thường giúp bổ sung mơ tả về lỗi

Cuối cùng, vector đặc trưng được hình thành từ sự kết hợp của meta-data và các tokens B Mơ hình dự đốn một pha

Hình 4: Mơ hình một pha của Kim và cộng sự

Báo cáo lỗi sau khi được trích xuất sẽ được sử dụng làm dữ liệu đào tạo Khi một báo cáo lỗi được đệ trình, nĩ sẽ trích xuất ra các features và gửi features đĩ cho mơ hình để đào tạo, từ đĩ mơ hình đưa ra đề xuất những tệp liên quan đến báo cáo lỗi đĩ

Mơ hình dự đốn một pha sử dụng thuật tốn Nạve Bayes [7], [8], thuật tốn phân loại đơn giản dựa vào định lý Bayes Sở dĩ chọn thuật tốn vì mỗi báo cáo lỗi cĩ thể chứa nhiều tệp được sửa, cái mà yêu cầu một mơ hình làm việc với bài tốn phân loại nhiều lớp

Sau quá trình training, mơ hình sẽ đưa ra xác suất với một bộ các tệp nguồn đầu vào để đề xuất ra k tệp là cĩ liên quan đến báo cáo lỗi nhất

C Mơ hình 2 pha

Các báo cáo lỗi thiếu thơng tin, ví dụ khơng cĩ mơ tả ban đầu, cĩ thể mang lại hiệu suất dự đốn kém Nên mơ hình dự đốn một pha sẽ khơng thể hoạt động tốt với các báo cáo khơng đủ thơng tin

Vì vậy bài báo đề xuất mơ hình 2 pha: phân loại nhị phân và phân loại đa lớp Đầu tiên mơ hình sẽ lọc ra những báo cáo lỗi thiếu thơng tin, và sau đĩ đưa ra dự đốn những tệp nguồn liên quan

Pha 1:

15 Mô hình đưa ra dự đoán một báo cáo lỗi có 2 khả năng xảy ra: “có thể dự đoán được” hoặc “thiếu hụt thông tin” (phân loại nhị phân) Các báo cáo lỗi có thể dự đoán được sử dụng cho pha 2

Tập hợp các báo cáo lỗi {𝑏1, 𝑏2, , 𝑏𝑛} đã được sửa sắp xếp theo thứ tự thời gian theo ngày báo cáo của chúng Xét một báo cáo lỗi bất kì 𝑏𝑗, j nằm trong đoạn [1, n], mô hình dự đoán

1 pha lấy tất cả báo cáo lỗi trước bj được đệ trình: 𝑏1, 𝑏2, , 𝑏𝑗−1 làm dữ liệu đào tạo Sau đó đưa ra kết quả dự đoán, nếu ít nhất một trong các tệp gây ra lỗi khớp với kết quả dự đoán, thì báo cáo lỗi sẽ được gán nhãn là “có thể dự đoán được”, ngược lại thì báo cáo lỗi đó “thiếu hụt thông tin”

Đối với các báo cáo “thiếu hụt”, mô hình chỉ tạo ra tập hợp rỗng vì không có dự đoán nào được tiến hành

D Đánh giá

Từ kết quả thực nghiệm [6] cho thấy, mô hình hai pha có hiệu suất tốt nhất trong số bốn mô hình dự đoán: One-phase, BugScout [1], Usual Suspects và Two-phase Hơn nữa, mô hình hai giai đoạn sắp xếp hạng các tệp được dự đoán vị trí vừa chính xác hơn, vừa tiết kiệm thời gian cho nhà phát triển

2.3 Nhóm nghiên cứu liên quan đến xử lý mất cân bằng dữ liệu đối với các mô hình phân loại

2.3.1 Chiến lược z-SVM

Imam và cộng sự đề xuất một chiến lược [23] giúp làm giảm sự mất cân bằng dữ liệu bằng cách tự động điều chỉnh mặt siêu phẳng và giảm độ lệch về lớp thiểu số

Công thức toán học:

16 Vector trọng số được học trong SVM:

𝑤 = ∑ 𝛼𝑝𝛾𝑝∅(𝑥𝑝) + 𝛼𝑛𝛾𝑛∅(𝑥𝑛) Công thức 1 Vector trọng số trong SVM Hàm quyết định phân loại:

𝑓(𝑥) = ∑ 𝛼𝑝𝛾𝑝𝐾(𝑥, 𝑥𝑝) + ∑ 𝛼𝑛𝛾𝑛𝐾(𝑥, 𝑥𝑛) + 𝑏

Công thức 2 Hàm decision function trong SVM

Từ đó Imam và cộng sự đề xuất thêm tham số z Để làm giảm độ lệch của SVM được đào tạo với lớp đa số cho dữ liệu không cân bằng, bài báo giới thiệu trọng số nhân, z, được liên kết với mỗi vectơ hỗ trợ lớp dương

𝑓(𝑥, 𝑧) = 𝑧 ∑ 𝛼𝑝𝛾𝑝𝐾(𝑥, 𝑥𝑝) + ∑ 𝛼𝑛𝛾𝑛𝐾(𝑥, 𝑥𝑛) + 𝑏

Công thức 3 Hàm cải tiến tham số z-SVM

Điều chỉnh giá trị của tham số z để thay đổi siêu phẳng sao cho Gmean đạt cực đại với dữ liệu đào tạo Sở dĩ dùng Gmean vì độ đo này trừng phạt nặng với sự nhận biết sai các class thiểu số, từ đó cải thiện tính mất cân bằng dữ liệu

Tham số z được tìm bằng cách tăng z từ từ xuất phát từ 0 đến một giá trị M Sau đó mô hình SVM mới được sử dụng để phân loại dữ liệu Nếu z = 0 thì phân loại thuộc lớp âm, z = M phân loại thuộc lớp dương Giá trị Gmean sẽ tăng từ 0 đến một giá trị cực trị rồi rơi giảm về 0 Từ đó ta tìm được cực trị z* là giá trị z cần tìm

2.3.2 Chiến lược lấy mẫu dưới quá mức GSVM-RU

Tang và cộng sự đề xuất một chiến lược Lỗi! Không tìm thấy nguồn tham chiếu lấy mẫu

dưới dựa trên mô hình SVM

Cách tiếp cận: GSVM-RU có thể cải thiện hiệu suất phân loại bằng cách sau: 1) trích xuất các mẫu thông tin cần thiết để phân loại

2) loại bỏ một lượng lớn các mẫu dư thừa, hoặc thậm chí nhiễu

17 Thuật toán GSVM:

- Tính toán dạng hạt thể hiện thông tin dưới dạng một số tập hợp (được gọi là hạt thông tin) như tập hợp con

- Có 2 nguyên tắc trong tính toán dạng hạt Nguyên tắc đầu tiên là chia để trị, nghĩa là một tập dữ liệu lớn được chia nhỏ thành tập hợp các tập dữ liệu nhỏ Mỗi tập dữ liệu nhỏ được coi là một hạt Tiếp theo, hạt đó sẽ được xác định kích thước phù hợp bằng cách làm sạch dữ liệu, loại bỏ đi những thông tin không cần thiết mà không ảnh hưởng đến tính chất của hạt thông tin

- Mô hình học dựa trên tính toánh chuỗi hạt được hình thành nhờ việc sử dụng thông tin hoặc những giả định trước đó vào quá trình tạo hạt cho model dữ liệu

- GSVM trích xuất một chuỗi các hạt thông tin, với sự phân chia hạt và / hoặc thu nhỏ, sau đó xây dựng SVM trên một số hạt này nếu cần

Mô hình thuật toán GSVM-RU đề xuất:

Hình 5: Mô hình thuật toán GSVM-RU

Đầu tiên, giả định rằng tất cả các mẫu dương tính đều là thông tin để tạo thành một hạt thông tin tích cực Các mẫu âm tính được trích xuất bởi SVM dưới dạng SVs cũng có thể có nhiều

18 thông tin để tạo thành một hạt thông tin tiêu cực, gọi là (NLSV) Sau đó, những NLSV này được xóa khỏi tập dữ liệu đào tạo ban đầu để tạo ra một tập dữ liệu đào tạo nhỏ hơn Mô hình SVM mới được thành lập để trích xuất nhóm NLSV khác Quá trình này lặp lại 1 số lần để tâp thành nhiều hạt thông tin tiêu cực Tất cả các mẫu phủ định khác còn lại trong tập dữ liệu đào tạo đơn giản bị loại bỏ Một hoạt động tổng hợp có chọn lọc các mẫu trong các hạt thông tin tiêu cực (NLSVs) với các mẫu tích cực để hoàn thành quá trình undersampling Cuối cùng, một SVM tiếp tục được mô hình hóa trên tập dữ liệu sau tổng hợp để đưa ra kết quả

19

3.1 Mô hình SVM

3.1.1 Tổng quan về mô hình Support Vector Machine (SVM)

SVM là một thuật toán học máy thuộc nhóm học có giám sát được sử dụng để giải quyết các bài toán phân lớp dữ liệu (classification) hay hồi quy (Regression) SVM dạng chuẩn nhận dữ liệu đầu vào và phân loại chúng thành hai lớp khác nhau Vì vậy SVM là một thuật toán phân loại nhị phân

Cho trước một tập dữ liệu huấn luyện, được biểu diễn trong không gian vector, mỗi điểm thể hiện một vector đặc trưng, SVM sẽ tìm ra một siêu phẳng quyết định tốt nhất để phân loại tất cả các điểm trên không gian này thành hai lớp riêng biệt tương ứng là lớp + và lớp - Mặt siêu phẳng này được xác định tốt hay không dựa trên độ dài của khoảng cách biên Khoảng cách biên chính bằng khoảng cách của điểm dữ liệu gần nhất của mỗi lớp đến mặt phẳng này Khoảng cách biên càng lớn thì mặt phẳng quyết định càng tốt, do đó việc phân loại càng chính xác

3.1.2 Phân loại bằng Support Vector Machine (SVM)

a) Khoảng cách từ một điểm đến siêu phẳng

Trong không gian d chiều, khoảng cách từ một điểm (vector) có tọa đọ x0 tới siêu mặt phẳng có phương trình wT x0 + b = 0 được tính bởi:

Trong đó:

b) Bài toán phân chia hai classes

Chương 3 Các kiến thức nền tảng