Kết hợp BM25 với xử lý ngôn ngữ tự nhiên trong việc dò tìm những Báo cáo lỗi trùng nhau

Nội dung text: Kết hợp BM25 với xử lý ngôn ngữ tự nhiên trong việc dò tìm những Báo cáo lỗi trùng nhau

1. Kỷ yếu Hội nghị KHCN Quốc gia lần thứ XI về Nghiên cứu cơ bản và ứng dụng Công nghệ thông tin (FAIR); Hà Nội, ngày 09-10/8/2018 DOI: 10.15625/vap.2018.00029 KẾT HỢP BM25 VỚI XỬ LÝ NGÔN NGỮ TỰ NHIÊN TRONG VIỆC DÒ TÌM NHỮNG BÁO CÁO LỖI TRÙNG NHAU Nhan Minh Phúc1 , Nguyễn Hoàng Duy Thiện1 1 Khoa Kỹ thuật và Công nghệ, Trường Đại học Trà Vinh nhanminhphuc@tvu.edu.vn, thiennhd@tvu.edu.vn TÓM TẮT: Hầu hết những phần mềm mã nguồn mở như Eclipse, Firefox, Apache đều cần có hệ thống quản lý lỗi để theo dõi những báo cáo lỗi khác nhau từ người dùng. Gần đây việc dò tìm những báo cáo lỗi trùng nhau nhận được nhiều sự quan tâm của các nhà khoa học. Có hai lý do chính: thứ nhất, những báo cáo lỗi trùng nhau gây lãng phí sức người để xử lý lại những báo cáo đã được xử lý trước đó. Thứ hai, những báo lỗi trùng nhau có thể cung cấp nhiều thông tin hữu ích trong việc bảo trì phần mềm sau này. Trước đây đã có nhiều phương pháp được đề xuất, tuy nhiên mức độ chính xác trong việc tự động dò tìm chỉ đạt khoảng 30- 80%. Trong bài báo này, chúng tôi muốn giới thiệu một phương pháp sử dụng trọng lượng từ BM25 kết hợp xử lý ngôn ngữ tự nhiên (BM25-NLP). Hiệu quả của phương pháp này được minh chứng thông qua việc thực nghiệm với ba phần mềm mã nguồn mở SVN, Argo UML, và Apache. Kết quả thực nghiệm cho thấy rằng phương pháp được giới thiệu tốt hơn từ 5-10% so với các phương pháp trước đây. Từ khóa: Dò tìm trùng nhau, báo cáo lỗi, BM25, đặc điểm trọng lượng. I. GIỚI THIỆU Vấn đề bảo trì phần mềm đối với các kho phần mềm mã nguồn mở đóng một vai trò rất quan trọng, việc tìm ra những lỗi từ người dùng để xử lý sẽ tránh được những rủi ro do phần mềm gây ra. Thông thường, những tình huống này sẽ gửi đến hệ thống quản lý báo cáo lỗi như Bugzilla, Eclipse Sau khi những báo cáo lỗi được gửi, một hoặc nhiều người phát triển sẽ được giao nhiệm vụ phân tích những lỗi này và chuyển đến những lập trình viên phù hợp cho việc xử lý lỗi. Theo những bài báo gần đây, vấn đề dò tìm lỗi trùng nhau đang nhận được nhiều sự quan tâm của các nhà nghiên cứu, lý do chính là do số lượng báo cáo lỗi trùng nhau đã tăng đến 36 % [1, 2, 3]. Cụ thể với dự án của Eclipse với 18,165 báo cáo lỗi, trong đó có gần 3633 lỗi trùng nhau chiếm tới 20 % [5]. Ngoài ra, theo dữ liệu của Firefox trong số 2,013 báo cáo lỗi được gửi, trong đó tới 30% là những báo cáo lỗi trùng nhau [4]. Từ số liệu trên cho thấy số lượng những báo cáo lỗi trùng nhau là rất lớn, điều này cho thấy tầm quan trọng của việc đưa ra những giải pháp trong việc xử lý lỗi trùng nhau là hết sức cần thiết và cấp bách. Vì vậy việc nhận biết những báo cáo lỗi đóng vai trò rất quan trọng và mang lại nhiều lợi ích: Thứ nhất, tiết kiệm được thời gian và công sức cho việc phân tích lỗi. Thứ hai, những thông tin chứa trong những báo cáo lỗi trùng nhau có thể rất hữu ích cho việc tìm và xử lý lỗi. Lý do là vì họ có thể cung cấp nhiều thông tin hơn so với những báo cáo lỗi được gởi trước đó. Trong Paragraph: First line là 1cm, Spacing before là 0, Spacing After là 6pt, First line được chỉ định là 0,5cm và Alignment là justified. II. DÒ TÌM LỖI TRÙNG NHAU Báo cáo lỗi trùng nhau trong các kho Báo cáo lỗi #1 phần mềm mã nguồn mở có thể được phân loại bằng việc xác định hai hoặc nhiều hơn những báo cáo lỗi mà nó mô tả có cùng nguyên nhân Lỗi #1 gây ra lỗi. Theo những nghiên cứu trước đây, những báo cáo lỗi trùng nhau có thể được chia Báo cáo lỗi #2 thành hai loại. Loại thứ nhất mô tả những báo cáo lỗi trùng nhau mà nó xảy ra trong cùng tình huống giống nhau. Loại thứ hai miêu tả những Lỗi báo cáo lỗi trùng nhau nhưng lại xãy ra do các nguyên nhân khác nhau lại cùng nguồn gốc. Do những báo cáo lỗi loại thứ hai thường được mô Lỗi #2 Phần mềm Báo cáo lỗi #3 tả bởi những từ vựng khác nhau cho những báo cáo lỗi khác nhau, vì vậy việc dò tìm lỗi trùng nhau có thể không hiệu quả bởi những báo cáo này chỉ mô tả bởi những thông tin văn bản. Hình 1 cho thấy hai loại báo cáo lỗi. Do đó bài Lỗi #3 báo này cũng theo những nghiên cứu trước đây, Báo cáo lỗi #4 nghĩa là chỉ tập trung vào phương pháp dò tìm theo loại một, chỉ xem xét những báo cáo lỗi trùng nhau với cùng một nguyên nhân gây ra. Hình 1. cho thấy hai loại báo cáo lỗi
2. Nhan Minh Phúc, Nguyễn Hoàng Duy Thiện 219 Để dò tìm những báo cáo lỗi trùng nhau, đầu tiên chúng ta phải rút trích những thông tin văn bản từ những báo cáo lỗi. Thông thường, một báo cáo lỗi bao gồm nhiều thông tin như nội dung tóm tắt lỗi, phần mô tả lỗi, hệ điều hành Ngoài ra nó cũng có phần bình luận cho những người báo cáo lỗi khác bình luận. Nếu một báo cáo lỗi là báo cáo đầu tiên, nó được gọi là báo cáo lỗi chính (master bug report). Ngược lại, nó sẽ được gán lỗi trùng nhau sau khi được xử lý kiểm tra giống báo cáo lỗi chính. Vấn đề trùng nhau trong nghiên cứu này được xử lý như sau. Đối với một dự án phần mềm, những báo cáo lỗi đã tồn tại trước đây sẽ được xử lý đầu tiên bằng cách phân loại thành n nhóm báo cáo. Mỗi nhóm báo cáo sẽ có một báo cáo lỗi chính. Nếu một nhóm báo cáo có nhiều hơn một cáo cáo lỗi, khi đó những báo cáo lỗi trong nhóm báo cáo sẽ có mối quan hệ trùng nhau. Khi có một báo cáo lỗi được gởi đến, việc dò tìm trùng nhau được thực hiện để đưa ra một danh sách những báo cáo lỗi gần giống nhất với những báo cáo lỗi trong nhóm báo cáo. Mối quan hệ trùng nhau được xác định nếu thỏa một trong các điều kiện sau: 1. Cho một báo cáo lỗi chính BRm, một báo cáo lỗi BRi sẽ được đánh dấu là trùng nhau đến BRm trong hệ thống theo dõi lỗi và trạng thái báo lỗi khi đó là đóng (Closed). 2. Cho hai báo cáo lỗi BRi và BRj, nếu họ được đánh dấu như trùng nhau của báo cáo BRm, BRi sẽ được xem là trùng nhau của BRj và ngược lại. 3. Nếu có một báo cáo lỗi BRk khác mà được đánh dấu như trùng nhau của BRi, thì BRk cũng là một trùng nhau của BRm. Trường hợp này được gọi là bắc cầu. Phương pháp xử lý lỗi được giới thiệu bao gồm 5 bước: Xử lý ngôn ngữ tự nhiên Tính trọng số BM25 Xây dựng mô hình không gian vector Tính độ giống nhau giữa các báo cáo lỗi Xuất danh sách những báo cáo lỗi trùng nhau trong top 20 Hình 2 bên dưới cho thấy mô hình tổng quan của phương pháp xử lý lỗi được giới thiệu Hình 2. Mô hình tổng quan của phương pháp xử lý lỗi
3. 220 KẾT HỢP BM25 VỚI XỬ LÝ NGÔN NGỮ TỰ NHIÊN TRONG VIỆC DÒ TÌM NHỮNG BÁO CÁO III. XỬ LÝ NGÔN NGỮ TỰ NHIÊN TRONG CÁC BÁO CÁO LỖI Mục đích của những nghiên cứu về việc rút trích thông tin (information retrieval) là để phát triển những thuật toán với những mô hình trong việc lấy thông tin từ những kho dữ liệu lớn. Thông tin này thường ở dạng văn bản và được diễn tả bằng ngôn ngữ tự nhiên. Thông thường người dùng tìm kiếm thông tin thông qua câu truy vấn, và hệ thống trả về danh sách những dữ liệu tương ứng được tìm thấy. Một hệ thống trả về kết quả càng chính xác phụ thuộc nhiều vào câu truy vấn của người dùng. Như hình 3, nội dung báo cáo lỗi ngoài những thông tin hữu ích mô tả lỗi, nó còn chứa nhiều thông tin mà nó không thật sự có ích cho việc tự động dò tìm lỗi trùng nhau, ví dụ những từ như “and, or, not, but, very ” hay những dấu câu như dấu gạch ngang, dấu ngoặc đơn , vì vậy việc loại bỏ những từ không cần thiết này thì rất quan trọng, ảnh hưởng nhiều đến sự chính xác của các phương pháp dò tìm. Trong bước này, mỗi báo cáo lỗi sẽ được rút trích thông tin từ hai trường chính trong báo cáo lỗi gồm trường tóm tắt lỗi (summary), mô tả lỗi (description), do các thông tin từ hai trường này mô tả đầy đủ và có nghĩa để hỗ trợ việc xử lý lỗi. Sau đó thông tin này sẽ được xử lý thông qua các bước xử lý ngôn ngữ tự nhiên ở mức cơ bản gồm tách từ (tokenization), tiếp theo là loại bỏ những từ không có nghĩa (stop words) ví dụ như như những từ “ the, and, or, ”, sau đó tiến hành chuyển tất cả các dạng biến thể của một từ trở về từ gốc (stemming). Những thao tác xử lý ngôn ngữ tự nhiên cơ bản này được hỗ trợ bởi công cụ hỗ trợ WVTool (Word Vector Tool). Công cụ này giúp việc xử lý các thao tác xử lý ngôn ngữ tự nhiên nhanh và dễ dàng hơn. Theo Manning and Schütze [7, 8, 9], việc xử lý ngôn ngữ tự nhiên Hình 3. một ví dụ báo cáo lỗi trên SVN (NLP) bao gồm các bước: Tách từ (tokenization) chuyển một từ về dạng gốc (Stemming) Xóa bỏ những từ ít ý nghĩa (stop words removal) 3.1. Tách từ Tách từ là một quá trình xử lý hằm mục đích xác định ranh giới của các từ trong văn bản, cũng có thể hiểu đơn giản rằng tách từ chính là tách một đoạn text (một chuỗi liên tiếp các ký tự) thành những từ (word hay token) riêng lẻ và loại bỏ các dấu câu, dấu ngoặc, dấu nháy, Bảng 1. Kết quả sử dụng tokenization, stemming và stop words removal trong một file báo cáo lỗi Original sentence Tokeniza- tion Stemming Stop words removal Dump in file system when dump in file system when dump file system when dump file system recording audio (see attached recording audio see attached log. record audio see attach log record audio log).
4. Nhan Minh Phúc, Nguyễn Hoàng Duy Thiện 221 3.2. Chuyển một từ về dạng gốc Mỗi từ trong báo cáo lỗi có thể được viết theo những dạng ngữ pháp khác nhau nhưng vẫn chứa cùng một thông tin. Do đó việc xử dụng stemming mục đích là để xử lý mỗi từ ở những dạng ngữ pháp khác nhau trở về từ gốc của nó, điều này giúp dễ dàng hơn trong việc tính toán và xác định những báo cáo lỗi trùng nhau. Ví dụ như từ worded và working sẽ được chuyển thành từ gốc là work. Những động từ cũng được chuyển trở lại nguyên mẫu của nó. Ví dụ was và being sẽ trở thành be. 3.3. Xóa bỏ những từ ít ý nghĩa Trong những file báo cáo lỗi thường chứa những từ mà bản thân nó không có nghĩa, hay nói đúng hơn đó là những từ chung chung giống như the, that, when, and, or những từ này không chứa thông tin cụ thể có ích cho việc xử lý những báo cáo lỗi trùng nhau. Những từ này có nhiều trong các file báo cáo lỗi và nó hầu như không liên quan đến nội dung cụ thể nếu không loại bỏ nó sẽ ảnh hưởng rất nhiều đến việc xác định sự giống nhau giữa các file báo cáo lỗi. Thông thường việc xử lý những từ này bằng cách liệt kê một danh sách những từ không có nghĩa hay còn gọi là không có ích cho việc xử lý. Danh sách này thường gọi là danh sách “stop words”, khi đó những báo cáo lỗi có chứa những từ trong danh sách này sẽ bị loại bỏ. IV. SỬ DỤNG MÔ HÌNH KHÔNG GIAN VECTOR (VECTOR SPACE REPRESENTATION) VỚI TRỌNG LƢỢNG TỪ BM25 Bước kế tiếp và cũng rất quan trọng đó là chuyển những từ trong file báo cáo lỗi sáng mô hình không gian vector nhiều hướng. Mỗi hướng có thể xem như tương ứng với một từ. Giá trị của nó phụ thuộc vào số lượng từ trùng nhau trong một báo cáo lỗi. Việc tính mức độ trùng nhau giữa hai báo cáo lỗi sẽ dựa vào khoảng cách của những giá trị trong không gian vector này. Một phương pháp phổ biến là sử dụng trọng số Tf-Idf. Trong đó Tf (term frequency) dùng để ước lượng tần suất xuất hiện của từ trong văn bản. Tuy nhiên với mỗi văn bản thì có độ dài khác nhau, vì thế số lần xuất hiện của từ có thể nhiều hơn. Vì vậy số lần xuất hiện của từ sẽ được chia độ dài của văn bản (tổng số từ trong văn bản đó) TF(t, d) = ( số lần từ t xuất hiện trong văn bản d) / (tổng số từ trong văn bản d) (1) IDF (Inverse Document Frequency) dùng để ước lượng mức độ quan trọng của từ đó như thế nào. Khi tính tần số xuất hiện tf thì các từ đều được coi là quan trọng như nhau. Tuy nhiên có một số từ thường được được sử dụng nhiều nhưng không quan trọng để thể hiện ý nghĩa của đoạn văn, ví dụ: and, but Vì vậy chúng ta cần giảm đi mức độ quan trọng của những từ đó bằng cách sử dụng IDF: IDF(t, D) = log_e( Tổng số văn bản trong tập mẫu D/ Số văn bản có chứa từ t ) (2) Tuy nhiên phương pháp này không hiệu quả khi sử dụng đối với việc dò tìm những báo cáo lỗi trùng nhau. Do đó chúng tôi thay thế trọng số này bằng thuật toán mới hiệu quả hơn đó là BM25. BM25 là một hàm xếp hạng được phát triển trong hệ thống truy xuất thông tin Okapi [10,11]. Trong phương pháp BM25 ban đầu, các tài liệu được xếp hạng dựa trên chức năng truy xuất từng từ, và mỗi thuật ngữ được coi là một thuật ngữ truy vấn để tính toán sự phụ thuộc vào xác suất thống kê của các thuật ngữ trong tất cả các báo cáo lỗi. Nói cách khác, BM25 tính toán mối quan hệ nội bộ giữa các cụm từ truy vấn giữa các báo cáo lỗi, thay vì liên quan đến mối quan hệ giữa các cụm từ truy vấn trong một báo cáo lỗi. Ngoài ra, BM25 có thể được biểu diễn bằng cách sử dụng một số hàm trọng số biến thể với các thành phần khác nhau để điều chỉnh cho các ứng dụng truy xuất thông tin tương ứng. Hàm trọng số của BM25 đối với chuỗi truy vấn q và báo cáo lỗi d được định nghĩa như sau |q| tf (qi ,d) (k1 1) s(q,d) idf (qi ) |d| (3) i 1 tf (q ,d) k (1 b b ) i 1 dlavg Trong công thức (1), tf (qi, d) là tần số lặp lại của từ qi xuất hiện trong tài liệu d, | d | đại diện cho độ dài của báo cáo lỗi d được tính bằng từ, và dlavg đề cập đến độ dài báo cáo lỗi trung bình trên tất cả các báo cáo lỗi trong bộ dữ liệu thực nghiệm. Các tham số k1 và b là các tham số heuristic để kiểm soát trọng số giữa tần số xuất hiện của một từ và chiều dài của các báo cáo lỗi. Chúng thường được chọn là 1,2 k1 2,0 và 0,5 b 0,8. Trong nghiên cứu này, chúng tôi sử dụng các giá trị chung của k1 = 2,0 và b = 0,8 như các nghiên cứu khác. Tuy nhiên, chúng tôi cũng đã thực nghiệm các giá trị tham số khác để quan sát ảnh hưởng của chúng đến BM25. Cuối cùng, idf(qi)thể hiện tần suất báo cáo lỗi nghịch đảo của cụm từ truy vấn qi. Nó được tính bằng phương trình sau: N df (qi 0.5 idf (qi ) log( ) (4) df (qi ) 0.5 trong đó N là tổng số báo cáo lỗi trong bộ dữ liệu thực nghiệm và df(qi) là số lượng báo cáo lỗi chứa cụm từ truy vấn qi.
5. 222 KẾT HỢP BM25 VỚI XỬ LÝ NGÔN NGỮ TỰ NHIÊN TRONG VIỆC DÒ TÌM NHỮNG BÁO CÁO V. TÍNH SỰ GIỐNG NHAU (SIMILARITY CALCULATION) GIỮA CÁC BÁO CÁO LỖI Chúng tôi cũng sử dụng cùng phương pháp tính cosine như những nghiên cứu trước đây. (5) Trong đó: biểu diễn cho vector đặc điểm của báo cáo lỗi mới gởi đến biểu diễn vector đặc điểm của mỗi báo cáo lỗi đã tồn tại trong dataset Do phương pháp này có thể giúp việc tính toán sự giống nhau giữa hai báo cáo lỗi tốt hơn. Phương pháp tính sự giống nhau trong các báo cáo lỗi sử dụng trong bài báo này gọi là sắp xếp dựa vào nhóm báo cáo lỗi, có nghĩa là giá trị cosine sẽ được tính lại lần nữa trước khi xác định xem hai báo cáo lỗi có trùng nhau không. Tiếp theo chúng ta tính trung bình cosine của những báo cáo lỗi trong nhóm báo cáo và so sánh báo cáo lỗi mới vừa gởi đến với tất cả báo cáo lỗi đã tồn tại với giá trị cosine mới và sắp xếp lại theo giá trị giống nhau giữa các báo cáo lỗi đễ xác định trùng nhau. Cách này có thể giải quyết phần nào những báo cáo lỗi trùng nhau mà có giá trị cosine thấp. VI. DANH SÁCH TOP N BÁO CÁO TƢƠNG TỰ Việc sử dụng danh sách Top n báo cáo lỗi tương tự nhau có thể giúp người dùng tìm được những báo cáo lỗi trùng nhau. Chúng tôi sắp xếp danh sách từ 1 đến 20 báo cáo lỗi gần giống nhất với báo cáo lỗi vừa được gởi đến và quan sát kết quả thực nghiệm. Khi đó chúng tôi tiến hành so sánh với những phương pháp nghiên cứu trước đây, kết quả thấy rằng, phương pháp của chúng tôi đã thực hiện tốt hơn những phương pháp đã được giới thiệu trước đó. VII. THỰC NGHIỆM 4.1. Môi trƣờng thực nghiệm Chúng tôi đã tiến hành thực nghiệm với 3 kho báo cáo lỗi của những dự án phần mềm mở là Argo UML, Apache, và SVN. Thống kê chi tiết về 3 kho phần mềm này được mô tả trong Bảng 4.1. 4.2. Phƣơng pháp đánh giá Bảng 4.1. Thông tin về datasets của 3 dự án nguồn mở Mô tả ArgoUML Apache SVN Ngôn ngữ Java C C Loại phần mềm UML Tool HTTP Server SCM tool Kho chứa lỗi Tigris Bugzilla Tigris Số báo cáo lỗi 4,613 2,771 2,296 Số báo cáo lỗi trùng 755 614 313 Để đánh giá phương pháp dò tìm, chúng tôi sử dụng đơn vị đo lường gọi là Recall rate, phương pháp này được những công bố trước sử dụng cho phương pháp dò tìm báo cáo lỗi trùng nhau, nó được tính dựa trên bao nhiêu báo cáo lỗi có thể được dò tìm đúng trong danh sách những báo cáo lỗi trùng nhau và nó được định nghĩa như sau: Recal rate = 4.3. Nghiên cứu kết quả thực nghiệm Để thấy sự hiệu quả của phương pháp được giới thiệu dựa vào trọng số kết hợp giữa BM25 và xử lý ngôn ngữ tự nhiên (BM25-NLP). Chúng tôi tiến hành so sánh nó với phương pháp truyền thống tính trọng số dựa vào TF-IDF. Ngoài ra chúng tôi cũng thực nghiệm kết hợp BM25 với phương pháp của Hiew [5], và phương pháp khác chỉ dựa và xử lý ngôn ngữ tự nhiên được giới thiệu bởi Runeson et al (Runeson) [2]. Trong thực nghiệm chúng tôi sử dụng giá trị phổ biến của (k1,b) = (2.0,0.8) cho BM25-NLP. Kết quả thực nghiệm cho thấy phương pháp được giới thiệu cải tiến rõ rệt trong tất cả ba dự án. Hình 4 chỉ ra sự cải thiện đáng kể của BM25-NLP so với phương pháp của Hiew và Runeson gần 11% trong tập dữ liệu Apache. Đối với dữ liệu ArgoUML phương pháp được giới thiệu tốt hơn gần 8%, và 6% là kết quả cải tiến của phương pháp được giới thiệu đối với tập dữ liệu SVN.
6. Nhan Minh Phúc, Nguyễn Hoàng Duy Thiện 223 Hình 4. So sách phương pháp BM25-NLP với các phương pháp khác VIII. KẾT LUẬN Việc dò tìm trùng nhau của những báo cáo lỗi là một trong những vấn đề quan trọng trong việc bảo trì phần mềm trong những năm gần đây. Trong bài báo này giới thiệu một phương pháp dò tìm dựa vào BM25 kết hợp với xử lý ngôn ngữ tự nhiên để cải tiến việc thực thi dò tìm những báo cáo lỗi trùng nhau. Kết quả thực nghiệm từ ba dự án mã nguồn mở cho thấy phương pháp này mang lại hiệu quả cao trong việc dò tìm các báo cáo lỗi trùng nhau, đặc biệt là khi so sánh với các phương pháp được giới thiệu trước đây, phương pháp BM25-NLP đã cho kết quả tốt hơn và hiệu quả hơn trong việc dò tìm những báo cáo lỗi trùng nhau khoảng 10% so với các phương pháp trước đó. IX. TÀI LIỆU THAM KHẢO [1] N. Serrano and I. Ciordia. “Bugzilla, ITracker, and Other Bug Trackers”. IEEE Software, vol. 22, no. 2, pp. 11-13, Mar. 2005. [2] J. Anvik, L. Hiew, and G. C. Murphy. “Coping with an Open Bug Repository” in Proc. the 2005 OOPSLA Workshop on Eclipse technology eXchange (eclipse '05), 2005, pp. 35-39. [3] P. Runeson, M. Alexandersson, and O. Nyholm. “Detection of Duplicate Defect Reports Using Natural Language Processing” in Proc. the 29th Int. Conf. Software Engineering (ICSE 2007), 2007, pp. 499-510. [4] J. Anvik, L. Hiew, and G. C. Murphy. “Who Should Fix this Bug?” in Proc. the 28th Int. Conf. Software Engineering (ICSE '06), 2006, pp. 361-370. [5] L. Hiew. “Assisted Detection of Duplicate Bug Reports”. Master Thesis, The University of British Columbia, May 2006. [6] N. Jalbert and W. Weimer. “Automated Duplicate Detection for Bug Tracking Systems” in Proc. the 38th Annual IEEE/IFIP Int. Conf. Dependable Systems and Networks (DSN 2008), 2008, pp. 52-61. [7] A. Sureka and P. Jalote. “Detecting Duplicate Bug Report using Character N-Gram-based Features” in Proc. the 17th Asia Pacific Software Engineering Conf. (APSEC 2010), 2010, pp. 366-374. [8] X. Wang, L. Zhang, T. Xie, J. Anvik, and J. Sun. “An Approach to Detecting Duplicate Bug Reports using Natural Language and Execution Information” in Proc. the 30th Int. Conf. Software Engineering (ICSE '08), 2008, pp. 461-470. [9] Zhi-Hao Chen. “Duplication Detection on Bug Reports using N-Gram Features and Cluster Shrinkage”. Master Thesis, Department of Computer Science and Engineering Yuan Ze University, Jul. 2011. [10] S. E. Robertson, S. Walker, S. Jones, M. M. Hancock-Beaulieu, and M. Gatford. “Okapi at TREC-3” in Proc. the Third Text REtrieval Conf. (TREC-3), 1994, pp. 109-126. [11] S. E. Robertson and S. Walker. “Some Simple Effective Approximations to the 2-Poisson Model for Probabilistic Weighted Retrieval” in Proc. the 17th Annual Int. ACM SIGIR Conf. Research and Development in Information Retrieval (SIGIR '94), 1994, pp. 232-241
7. 224 KẾT HỢP BM25 VỚI XỬ LÝ NGÔN NGỮ TỰ NHIÊN TRONG VIỆC DÒ TÌM NHỮNG BÁO CÁO COMBINATION OF BM25 WITH NATURAL LANGUAGE PROCESSING IN DUPLICATE BUG REPORTS DETECTION Nhan Minh Phuc, Nguyen Hoang Duy Thien ABSTRACT: Most open source software such as Eclipse, Firefox, and Apache require a bug handling system to track various bug reports from the users. Recently, duplicate bug reports detection has received much attention from scientists. There are two main reasons: First, duplicate bug reports cause waste of human resources to process bug reports that previously processed. Second, duplicate bug reports can provide useful information for future software maintenance. Previously, many methods were proposed, however the accuracy of automatic detection was only about 30-80%. In this paper, we introduce a method of using term weight BM25 incorporating natural language processing (BM25-NLP). The effectiveness of this method is evidenced by empirical experiments on three open source projects, Apache, Argo UML, and SVN. The experimental results show that proposed scheme can effectively improve from 5-10% compared in previous methods.