Đị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ạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.38 MB, 56 trang )
<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">
<b>Đị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</b>
</div><span class="text_page_counter">Trang 2</span><div class="page_container" data-page="2">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
<b>Chương 2Các nghiên cứu liên quan cho bài toán định vị lỗi ...5</b>
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
<b>Mục lục </b>
</div><span class="text_page_counter">Trang 3</span><div class="page_container" data-page="3">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
<b>Chương 3Các kiến thức nền tảng ...19</b>
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
<b>Chương 4Giải pháp đề xuất ...29</b>
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
</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4">6.2 Hướng phát triển trong tương lai ... 44
<b>Tài liệu tham khảo ...45</b>
</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5">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
</div><span class="text_page_counter">Trang 6</span><div class="page_container" data-page="6">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
<b>Danh mục cơng thức </b>
</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7">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
</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8">12
</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">13
<b>Bug report </b> Báo cáo lỗi
<b>Source file </b> Tệp mã nguồn
<b>Comment </b> Chú thích
<b>Undersampling </b> Q trình lấy mẫu dưới
<b>Oversampling </b> Quá trình lấy mẫu trên
<b>Danh mục thuật ngữ </b>
</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10">1
<b>1.1 Đặt vấn đề </b>
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à đã
<b>Chương 1 Giới thiệu đề tài </b>
</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11">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ự đố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.
<b>1.2 Các giải pháp hiện tại và hạn chế </b>
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
</div><span class="text_page_counter">Trang 12</span><div class="page_container" data-page="12">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.
<b>1.3 Mục tiêu và định hướng giải pháp </b>
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.
<b>1.4 Đóng góp của đồ án </b>
Đồ án tốt nghiệp có 3 đóng góp chính như sau:
</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13">4 1. Đề xuất xây dựng mơ hình SVM và triển khai mơ hình cho bài tố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.
<b>1.5 Bố cục đồ án </b>
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. Ngồ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 tốn định vị lỗi phần mềm.
</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14">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.
.
<b>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 </b>
<b>2.1.1 Mơ hình Bug Locator </b>
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 q khứ. Bug Locator tính tố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 tồ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 tố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>Đối với mỗi tệp nguồn s, ta thu được danh sách các báo cáo lỗi {𝐵</i><sub>1</sub>, 𝐵<sub>2</sub>, . . ., 𝐵<sub>𝑛</sub>} có hình
<b>Chương 2 Các nghiên cứu liên quan cho bài toán định vị lỗi </b>
</div><span class="text_page_counter">Trang 15</span><div class="page_container" data-page="15">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
<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 𝐵</i><sub>𝑖</sub> 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].
<b>2.1.2 Cơng trình nghiên cứu của Gharibi và cộng sự </b>
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ữ.
</div><span class="text_page_counter">Trang 16</span><div class="page_container" data-page="16">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 tố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 tồ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].
<b>2.1.3 Mơ hình BLUiR </b>
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.
</div><span class="text_page_counter">Trang 17</span><div class="page_container" data-page="17">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
</div><span class="text_page_counter">Trang 18</span><div class="page_container" data-page="18">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ố.
<b>2.2 Nhóm nghiên cứu liên quan áp dụng mơ hình học có giám sát </b>
<b>2.2.1 Mơ hình Bug Scout </b>
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,
</div><span class="text_page_counter">Trang 19</span><div class="page_container" data-page="19">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.
<i>Topic Vector. Một tài liệu s có 𝑁</i><sub>𝑠</sub> từ. Mỗi từ trong 𝑁<sub>𝑠</sub> được coi là miêu tả một chủ đề kỹ thuật cụ thể. Cho nên chúng ta có vector chủ đề 𝑧<sub>𝑠</sub> với độ dài 𝑁<sub>𝑠</sub><i>. </i>
Topic Proportion. Để thể hiện tầm quan trọng của nhiều chủ đề trong tài liệu. 𝜃<sub>𝑠</sub> 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
<i>tỷ lệ chủ đề tương ứng trong s. </i>
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
<i>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 </i>
vector chọn từ (vector word-selection) 𝜙<sub>𝑘</sub>, kích thức 𝑉. Mỗi phần tử đại diện cho tần suất
<i>sử dụng của từ trong V oc để mô tả chủ đề k. Ví dụ, đối với chủ đề k, 𝜙</i><sub>𝑘</sub> = [0,3, 0,2, 0,4, ...].
<i>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>
Đối với một hệ thống phần mềm, mỗi chủ đề k có vectơ riêng 𝜙<sub>𝑘</sub><i> thì k chủ đề có thể được biểu diễn bằng ma trận K × V 𝜙</i><sub>𝑠𝑟𝑐</sub>, đượ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
<i>cũng coi mỗi báo cáo lỗi b là một tài liệu với ba biến 𝑧</i><sub>𝑏</sub>, 𝜃<sub>𝑏</sub>, 𝜙<sub>𝐵𝑅</sub>. Chú ý rằng 𝜙<sub>𝐵𝑅</sub> áp dụng cho tất cả các báo cáo lỗi và nó khác với 𝜙<sub>𝑠𝑟𝑐</sub><i>. Báo cáo lỗi b không chỉ bị ảnh hưởng bởi </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 đó.
</div><span class="text_page_counter">Trang 20</span><div class="page_container" data-page="20">11 Ví dụ 𝑠<sub>1</sub>, 𝑠<sub>2</sub>, . . ., 𝑠<sub>𝑀</sub> để 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ó: 𝜃<sub>𝑏</sub><sup>∗</sup> = 𝜃<sub>𝑠1</sub>. 𝜃<sub>𝑠2</sub>. . . 𝜃<sub>𝑠𝑀</sub>. 𝜃<sub>𝑏</sub>. 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: 𝑧<sub>𝑏</sub>, 𝜃<sub>𝑏</sub>, 𝜙<sub>𝐵𝑅</sub>.
Tuy nhiên, nếu các tệp nguồn 𝑠<sub>1</sub>, 𝑠<sub>2</sub>, . . ., 𝑠<sub>𝑀</sub> được xác định là gây ra lỗi được báo cáo trong
<i>báo cáo lỗi b, vectơ chủ đề 𝑧</i><sub>𝑏</sub> 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ừ 𝜃<sub>𝑠1</sub>, 𝜃<sub>𝑠2</sub>, . . ., 𝜃<sub>𝑠𝑀</sub> đến 𝑧<sub>𝑏</sub>.
Đối với mỗi tài liệu nguồn, có 3 biến: 𝑧<sub>𝑠</sub>, 𝜃<sub>𝑠</sub>, 𝜙<sub>𝑠𝑟𝑐</sub>. 𝛼 𝑣à 𝛽 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 𝜃<sub>𝑏</sub><sub>𝑛𝑒𝑤</sub>. Tỷ lệ chủ đề này được dùng để tìm các
</div><span class="text_page_counter">Trang 21</span><div class="page_container" data-page="21">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.
<i>Với mỗi tài liệu s trong S, BugScout ước tính 𝑧</i><sub>𝑠</sub><i>[𝑖] cho vị trí i. </i>
Bước 2: Ước tính tỷ lệ chủ đề 𝜃<sub>𝑠</sub> cho một tệp nguồn.
Tỷ lệ chủ đề 𝜃<sub>𝑠</sub><i>[𝑘] 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. </i>
Bước 3: Ước tính phân phối từ 𝜙<sub>𝑠𝑟𝑐</sub>.
𝜙<sub>𝑠𝑟𝑐</sub>[𝑤<sub>𝑖</sub><i>] 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 </i>
để 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ủ đề 𝑧<sub>𝑏</sub>[𝑖] cho các báo cáo lỗi trong B.
Bước 5: Ước tính tỷ lệ chủ đề 𝜃<sub>𝑏</sub><i> cho một báo cáo lỗi b và ước tính phân phối từ 𝜙</i><sub>𝐵𝑅</sub>. Các bước ước lượng đó tương tự như các bước cho 𝜃<sub>𝑠</sub> và 𝜙<sub>𝑠𝑟𝑐</sub>.
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ủ đề chun 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
<i>hiện có: SVM-based bởi Premraj et al [4] và LDA-VSM bởi Premraj et al [5]. </i>
</div><span class="text_page_counter">Trang 22</span><div class="page_container" data-page="22">13
<b>2.2.2. Mơ hình Learn2Rank </b>
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ự đốn.
<i>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 </i>
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
<i>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 </i>
đí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 tố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 tốn được các trọng số ứng với từng đặc trưng để
<i>đư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 </i>
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].
<b>2.2.3 Mơ hình hai pha của nhóm tác giả Kim và cộng sự </b>
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.
</div><span class="text_page_counter">Trang 23</span><div class="page_container" data-page="23">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:
</div><span class="text_page_counter">Trang 24</span><div class="page_container" data-page="24">15 Mô hình đưa ra dự đốn một báo cáo lỗi có 2 khả năng xảy ra: “có thể dự đố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ự đốn được sử dụng cho pha 2.
Tập hợp các báo cáo lỗi {𝑏<sub>1</sub>, 𝑏<sub>2</sub>, . . ., 𝑏<sub>𝑛</sub>} đã đượ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ì 𝑏<sub>𝑗</sub><i>, j nằm trong đoạn [1, n], mơ hình dự đốn </i>
1 pha lấy tất cả báo cáo lỗi trước bj được đệ trình: 𝑏<sub>1</sub>, 𝑏<sub>2</sub>, . . ., 𝑏<sub>𝑗−1</sub> làm dữ liệu đào tạo. Sau đó đưa ra kết quả dự đố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ự đốn, thì báo cáo lỗi sẽ được gán nhãn là “có thể dự đố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ự đố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ự đố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.
<b>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 </b>
<b>2.3.1 Chiến lược z-SVM </b>
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 tốn học:
</div><span class="text_page_counter">Trang 25</span><div class="page_container" data-page="25">16 Vector trọng số được học trong SVM:
𝑤 = ∑ 𝛼<sub>𝑝</sub>𝛾<sub>𝑝</sub>∅(𝑥<sub>𝑝</sub>) + 𝛼<sub>𝑛</sub>𝛾<sub>𝑛</sub>∅(𝑥<sub>𝑛</sub>) Công thức 1 Vector trọng số trong SVM Hàm quyết định phân loại:
𝑓(𝑥) = ∑ 𝛼<sub>𝑝</sub>𝛾<sub>𝑝</sub>𝐾(𝑥, 𝑥<sub>𝑝</sub>) + ∑ 𝛼<sub>𝑛</sub>𝛾<sub>𝑛</sub>𝐾(𝑥, 𝑥<sub>𝑛</sub>) + 𝑏
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
𝑓(𝑥, 𝑧) = 𝑧 ∑ 𝛼<sub>𝑝</sub>𝛾<sub>𝑝</sub>𝐾(𝑥, 𝑥<sub>𝑝</sub>) + ∑ 𝛼<sub>𝑛</sub>𝛾<sub>𝑛</sub>𝐾(𝑥, 𝑥<sub>𝑛</sub>) + 𝑏
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.
<b>2.3.2 Chiến lược lấy mẫu dưới quá mức GSVM-RU </b>
<b>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 </b>
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.
</div><span class="text_page_counter">Trang 26</span><div class="page_container" data-page="26">17 Thuật tốn GSVM:
- Tính tố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 ngun tắc trong tính tố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 tố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 q 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 tốn GSVM-RU đề xuất:
Hình 5: Mơ hình thuật tố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
</div><span class="text_page_counter">Trang 27</span><div class="page_container" data-page="27">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. Q 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 để hồ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ả.
</div><span class="text_page_counter">Trang 28</span><div class="page_container" data-page="28">19
<b>3.1 Mơ hình SVM </b>
<b>3.1.1 Tổng quan về mơ hình Support Vector Machine (SVM) </b>
SVM là một thuật tố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
<b>3.1.2 Phân loại bằng Support Vector Machine (SVM) </b>
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 đọ <i>x</i><small>0 tới siêu mặt phẳng </small>có phương trình w<small>T</small><i> x</i><small>0 + b = 0 được tính bởi: </small>
Trong đó:
b) Bài tốn phân chia hai classes
