Professional Documents
Culture Documents
TÓM TẮT— Những báo cáo lỗi được gửi bởi người dùng thường được lưu trữ và quản lý bởi các hệ thống quản lý lỗi trong những
dự án phần mềm mã nguồn mở như Open Office, Mozilla Firefox, Eclipse...Những lập trình viên sẽ dựa vào những báo cáo lỗi này để
xử lý lỗi. Tuy nhiên do có quá nhiều báo cáo lỗi gửi đến hệ thống, khi đó sẽ có những báo cáo lỗi trùng nhau, hay nói cách khác báo
cáo lỗi trùng nhau là báo cáo lỗi đã được người dùng gửi trước đó rồi. Do đó việc phải xác định báo cáo lỗi vừa được gửi đến có bị
trùng hay không sẽ làm mất nhiều thời gian và công sức của người được phân công xử lý lỗi. Vì vậy việc tự động dò tìm báo cáo lỗi
trùng nhau gần đây nhận được nhiều sự quan tâm của các nhà nghiên cứu. Ngoài ra việc báo cáo lỗi thường là tập tin văn bản, do
đó sẽ có những trường hợp những báo cáo lỗi bị trùng nhau nhưng được diễn tả bằng những từ ngữ khác nhau ở những người dùng
khác nhau, điều này sẽ là một thách thức cho các nhà nghiên cứu. Trong bài báo này, chúng tôi giới thiệu một phương pháp tự động
dò tìm những báo cáo lỗi trùng nhau bằng cách sử dụng mô hình LDA-NWF (Latent Dirichlet Allocation-New Weight Feature). Mô
hình này là sự kết hợp giữa mô hình LDA với đặc điểm trọng số mới. Kết quả thực nghiệm trên ba hệ thống dữ liệu thật Open Office,
Eclipse và Mozilla cho thấy phương pháp được giới thiệu đạt tỉ lệ chính xác cao hơn các phương pháp trước đó từ khoảng 4-9% khi
so sánh trên cả ba hệ thống.
Từ khóa— Báo cáo lỗi, mô hình LDA, mô hình trọng số, lỗi trùng nhau, kho báo cáo lỗi.
I. GIỚI THIỆU
Những dự án mã nguồn mở lớn như Bugzilla thường dùng hệ thống quản lý lỗi để lưu trữ và và quản lý những báo cáo
lỗi của người dùng. Những báo cáo lỗi này được gửi bởi những người dùng trong quá trình họ sử dụng phần mềm giúp
việc bảo trì và cải thiện tính năng của hệ thống tốt hơn [1]. Theo các nghiên cứu gần đây, với việc phát triển nhanh chóng
của những hệ thống phần mềm, mỗi ngày có hàng trăm báo cáo lỗi được gửi đến. Những báo cáo lỗi trùng nhau xảy ra
khi có nhiều hơn một người dùng gửi báo cáo lỗi cho cùng một lỗi giống nhau [2]. Những báo cáo lỗi thường được diễn
đạt bằng ngôn ngữ tự nhiên do đó cùng một lỗi có thể được được diễn tả bằng những từ ngữ khác nhau hay nhiều cách
khác nhau. Bảng 1, bảng 2 là một ví dụ về hai báo cáo lỗi trùng nhau của hệ thống quản lý lỗi Open Office. Chúng ta có
thể thấy rằng hai báo cáo lỗi này cùng báo cáo một lỗi tuy nhiên lại sử dụng bằng những từ ngữ khác nhau. Với số lượng
báo cáo lỗi rất lớn, việc dò tìm những báo cáo lỗi trùng nhau bằng thủ công là một việc làm rất mất nhiều thời gian và
công sức. Vì vậy trong những năm gần đây, nhiều phương pháp về việc tự động dò tìm những báo cáo lỗi trùng nhau đã
được nghiên cứu để giải
Bảng 1: Báo cáo lỗi trên Open Office có mã lỗi: 9002
quyết vấn đề này. Hiện
Bug ID 9002
tại có vài phương pháp Product Math
được giới thiệu. Phương Component Code
pháp thường được sử Summary formatting of font attributes
dụng trước đây là sử Description The attributes: hat, grave, tilde, check, bar, vector, and so on are too far removed from the font.
Seems to be a problem with the font definitions used.
dụng kỹ thuật rút trích Workaround are widevec, widehat, widebar etc. Unfortunatelly the ‘wide’ version does not exist
thông tin (IR) với mô for all attributes.
hình không gian vector Also, ‘bold’ in formulate is translated into some sort of arial font with poor spacing within
(Vector Space Model) [3, characters. It is unfortunate that this has changed from SVv4 which used the more conventional
mathematical notation of Times bold for that, which incidentally has better character kerning.
4]. Một phương pháp
khác cải tiến hơn là sử dụng xử lý ngôn ngữ tự nhiên kết hợp với kỹ thuật rút trích thông tin [5, 6]. Ngoài ra còn một số
phương pháp khác như
sử dụng mô hình học Bảng 2: Báo cáo lỗi trên Open Office có mã lỗi 4524
Bug ID 4524
máy [7], mô hình phân Product Math
loại nhị phân [8]. Tuy Component UI
nhiên giới hạn của những Summary Space between a vector and its arrow too large.
phương pháp này chính Description Hi,
là kết quả thực nghiệm The space between a vector and its arrow is to large making the formula too high. It doesn’t
matter much when the formula is a paragraph of its own but it looks clumsy when placed among
thấp đối với việc xác the text of a paragraph.
định những báo cáo lỗi To make myself clear, copy this text in a sxw file then insert in the middle of the previous
trùng nhau. Gần đây, một paragraph the formula “vec u” or the formula “widevec AB”. Compare with what you’d get
phương pháp cải tiến của inserting the formula “overline AB”.
Thanks
kỹ thuật rút trích thông
tin được nhóm tác giả
Sun et al [9] giới thiệu cho thấy hiệu quả tốt hơn trong việc tự động dò tìm những báo cáo lỗi trùng nhau. Phương pháp
này sử dụng đặc điểm trọng số BM25F kết hợp với việc xem xét trên nhiều thuộc tính của tập tin báo cáo lỗi. Phương
pháp này cho kết quả tốt hơn là do dựa vào sự tương đồng giữa các báo lỗi cao. Tuy nhiên thực tế nhiều báo cáo lỗi khác
2 ĐỊNH DẠNG CHO VIỆC IN ẤN BÀI BÁO TRONG KỶ YẾU CỦA FAIR
nhau có thể sử dụng những từ ngữ khác nhau để mô tả cùng một loại lỗi. Khi đó những báo cáo lỗi này khi được so sánh
về độ tương đồng sẽ cho kết quả rất khác nhau. Trong trường hợp này phương pháp của Sun et al sẽ không cho kết quả
tốt. Bài báo này giới thiệu phương pháp LDA-NWF, một mô hình dò tìm tự động những báo cáo lỗi trùng nhau tận dụng
những ưu điểm không chỉ của kỹ thuật rút trích thông tin mà còn dựa vào mô hình đặc điểm chủ đề sử dụng LDA. Mô
hình này được thiết kế để giải quyết vấn đề hai báo cáo lỗi không tương đồng nhưng được xem là trùng nhau do cùng
báo cáo một lỗi giống nhau. Trong mô hình LDA-NWF, hai báo cáo lỗi phải có những mô tả chung về chủ đề, cũng như
trong thông tin báo cáo lỗi.
II. NGHIÊN CỨU LIÊN QUAN
Để dò tìm những báo cáo lỗi trùng nhau, hầu hết những nghiên cứu trước đây đều sử dụng phương pháp thống kê dựa
trên kỹ thuật tìm kiếm thông tin. Năm 2005, J. Anvik et al. [10] xây dựng mô hình thống kê sử dụng độ tương đồng
cosine trên dữ liệu Mozila Firefox, tuy nhiên kết quả đạt được chỉ chiếm 28%. Hiew et al. [11] sử dụng mô hình không
gian vector (VSM) để dò tìm những báo cáo lỗi trùng nhau. Dữ liệu sử dụng cho phương pháp này lên đến 100,000 tập
tin báo cáo lỗi đối với phần mềm mã nguồn mở Eclipse. Do dữ liệu quá lớn cùng với việc sử dụng mô hình không gian
vector làm tăng số chiều, cũng như độ nhiểu dẫn đến kết quả dò tìm kém hiệu quả. Runeson P. et al. [12] sử dụng phương
pháp xử lý ngôn ngữ tự nhiên với độ chính xác đạt được 30%. Wang et al. [6] cải tiến phương pháp của Runeson P. et al
bằng cách bổ sung thêm việc lấy thông tin báo cáo lỗi từ thông tin thực thi tập tin báo cáo lỗi của người dùng. Phương
pháp này cho kết quả đạt đến 67%, tuy nhiên do thông tin thực thi của báo cáo lỗi thì khó mô tả chi tiết lỗi và thông tin
này cũng không có nhiều giá trị đối với những báo lỗi thường gặp. Ngoài ra phương pháp học máy cũng được giới thiệu
gần đây, cụ thể Jallber và Weimer [8] sử dụng phương pháp này để phân loại các báo cáo lỗi trùng nhau. Họ sử dụng
việc phân cụm và độ tương đồng của các báo cáo lỗi để dự đoán các báo cáo lỗi trùng nhau, kết quả thực nghiệm cho
thấy phương pháp này cũng cho kết quả chưa cao. Tian et al. [5] cải tiến phương pháp của Jallber và Weimer bằng việc
sử dụng mô hình REP. Tuy nhiên kết quả thực nghiệm cho thấy phương pháp này vẫn còn nhiều hạn chế. Một số nghiên
cứu khác về việc dò tìm những báo cáo lỗi trùng nhau cũng nhận được nhiều quan tâm gần đây. Alipour et al. [13] đưa
ra khảo sát để phân tích nguyên nhân gây ra báo cáo lỗi. Trong [14], các tác giả giới thiệu phương pháp dò tìm dựa vào
ngữ cảnh về việc sử dụng phần mềm của người dùng. Ngoài ra còn một số nghiên cứu dựa vào phương pháp theo dõi
dấu vết lỗi và thói quen viết báo cáo lỗi của người dùng, hay phương pháp phân cụm trong các báo cáo lỗi [15, 16,
17]...tuy nhiên, những phương pháp trên chỉ cho kết quả dò tìm từ 48-70%.
III. PHƯƠNG PHÁP GIỚI THIỆU
Phương pháp của chúng tôi gồm hai phần chính. Đầu tiên chúng tôi xây dựng mô hình LDA và tính độ tương đồng LDA.
Phần tiếp theo chúng tôi xây dựng mô hình tính đặc điểm trọng số mới (NWF). Sau đó chúng tôi kết hợp hai mô hình
này lại với nhau được gọi là LDA-NWF. Hình 1 cho thấy phương pháp tổng thể của mô hình này.
Nếu báo cáo mới này được phát hiện trùng, nó sẽ được thêm vào danh sách tương ứng với danh sách báo cáo lỗi chính
mà nó trùng, ngược lại một danh sách mới sẽ được tạo ra và báo cáo lỗi này sẽ trở thành báo cáo chính của danh sách
mới được tạo. Ngoài ra chúng tôi cũng tiến hành các bước tiền xử lý với các báo cáo lỗi. Do một tập tin báo cáo lỗi
thường chứa nhiều thông tin. Những thông tin này có thể có vài thông tin khác nhau trên những phần mềm mã nguồn mở
khác nhau. Nhưng nhìn chung họ hầu như giống nhau. Bảng 1 và bảng 2 là một ví dụ về những tập tin báo cáo lỗi của
Open Office. Do tập tin báo cáo lỗi gốc thuộc dạng XML chứa nhiều thông tin dư thừa, chúng tôi sử dụng công cụ Java
SAX để chuyển đổi và rút trích lấy bốn thông tin chính của tập tin báo cáo lỗi bao gồm: thông tin tóm tắt lỗi, mô tả chi
tiết lỗi, loại lỗi và thông tin trùng lắp. Thông tin tóm tắt lỗi và phần mô tả chi tiết lỗi được chứa trong thông tin văn bản
của tập tin báo cáo lỗi. Thông tin loại lỗi chứa bốn phần gồm: loại lỗi, sản phẩm, thành phần và phiên bản. Thông tin
trùng lắp được sử dụng để đánh giá độ chính xác của kết quả thực nghiệm.Tiền xử lý là bước đầu tiên được thực hiện
bằng việc trích dữ liệu bao gồm các bước: làm sạch dữ liệu, tách từ, tìm từ gốc, tìm từ đồng nghĩa, loại bỏ những từ
không có nghĩa. Bước làm sạch dữ liệu thường được dùng phổ biến trong xử lý văn bản, do tập tin báo cáo lỗi thường
chứa thông tin gây nhiểu, dư thừa không cần thiết. Ví dụ dấu ngoặc đơn, dấu ngoặc kép, dấu gạch nối... Bước tách từ
được thực hiện đối với mỗi báo cáo lỗi bằng cách tách để lấy mỗi từ trong tập tin báo cáo lỗi trên một dòng, sau đó
chuyển đến tìm từ gốc. Do tập tin báo cáo lỗi bằng tiếng anh, nên chúng tôi sẽ chuyển những dạng biến thể của từ như
động từ dạng quá khứ, tính từ...về từ gốc. Tiếp đến tìm những từ đồng nghĩa nhưng được diễn tả khác nhau, ví dụ từ
“Control+Tab” chỉ cách sử dụng phím tắt được diễn tả bởi những người dùng khác nhau với dạng Ctrl+Tab, Trl-Tab,
CtrTab...và cuối cùng là loại bỏ những từ thường xuất hiện nhiều trong ngôn ngữ tự nhiên nhưng không mang nhiều ý
nghĩa như “a, is, about, but”...Ngoài ra chúng tôi cũng chuyển tất cả những nội dung trong tập tin báo cáo lỗi sang dạng
chữ thường. Với bước tiền xử lý trong trong bài báo này chúng tôi sử dụng công cụ GATE [18] và Lucene [19] để làm
việc này.
B. Xây dựng mô hình LDA
Vấn đề chính của mô hình LDA là làm thế nào để tạo ra các chủ đề từ những tập tin báo cáo lỗi và phân tích nó. Trong
LDA, những từ hay thuật ngữ trong tất cả tập tin báo cáo lỗi sẽ được thu thập thành tập các từ vựng, chúng tôi gọi là V.
Một chủ đề có thể được tạo ra từ các từ khác nhau trong tập tập các từ vựng này. Khi đó mỗi từ trong tập các từ vựng V
sẽ có tầng suất xuất hiện khác nhau trong việc tạo ra chủ đề k, và một chủ đề có thể được tạo ra thông qua một hay nhiều
từ. Để làm được điều này, LDA sử dụng một vector chọn từ gọi là ∅𝑘 có kích thước V cho chủ đề k. Mỗi thành phần của
vector ∅𝑘 dựa vào phân bố xác suất của từ, và tương ứng với nó là vị trí của thành phần đó trong tập từ vựng V được
dùng để tạo chủ đề k. Mỗi thành phần 𝜗 trong ∅𝑘 có giá trị trong khoảng [0-1]. Giả sử đối với chủ đề 1, ∅1 =[0.24, 0.23,
0.14,.. ] như được thấy hình 2, điều này có nghĩa rằng việc phân bố tầng suất xuất hiện của từ đầu tiên trong tập từ vựng
được sử dụng để tạo chủ đề k chiếm 24%, trong khi đó đối với từ thứ hai chỉ chiếm 23%, tương tự 14% đối với từ thứ
ba,...Một chủ đề sẽ được tạo ra từ tập các từ tùy vào sự phân bố xác suất của chúng. Khi đó chúng ta sẽ có ma trận ∅=K
x V dùng để chọn từ dựa vào việc phân bố từ cho mỗi chủ đề.
1. Sử dụng LDA xử lý tập tin báo cáo lỗi
Chúng tôi sẽ rút trích tất cả thông tin từ hai trường của một báo cáo lỗi: mô tả (descriptions) và tóm tắt (summaries). Khi
đó tập tin báo cáo lỗi b chứa 𝑁𝑏 từ, để sử dụng LDA với báo cáo lỗi này cần hai tham số chính. Đầu tiên là vector dùng
để gán chủ đề 𝑍𝑏 . Đối với mỗi vị trí của 𝑁𝑏 trong báo cao lỗi b sẽ được xem xét gán cho một chủ đề. Vector 𝑍𝑏 dùng để
gán chủ đề cho báo báo cáo lỗi b có kích thước 𝑁𝑏 . Mỗi thành phần của vector 𝑍𝑏 là một chỉ mục cho một chủ đề. Tham
số thứ hai là 𝜃, đối với một báo cáo lỗi b có thể có nhiều chủ đề, khi đó thuật toán LDA sử dụng tham số 𝜃 để xác định
tỷ lệ xác suất cho các chủ đề trong báo cáo lỗi b. 𝜃𝑏 của báo cáo lỗi b được trình bày bởi một vector với K thành phần.
Mỗi thành phần là một giá trị nằm trong khoảng [0-1] để mô hình hóa tỷ lệ của một chủ đề trong báo báo lỗi b. Mỗi giá
trị đề cập đến một chủ đề và tổng của chúng là 100%. Giá trị của 𝜃𝑏 [𝑘] càng cao thì sẽ có càng nhiều từ thuộc chủ đề k
có trong báo cáo lỗi b. Ví dụ trong báo cáo lỗi hình 3, nếu 𝜃𝑏 =[0.20, 0.24, 0.13,..], có nghĩa là 20% trong báo cáo b có
chứa từ “editing”, 24% chứa từ “versioning”, …
2. Mô hình sinh
LDA là một dạng học máy và thường được gọi là mô hình sinh (generative model). Từ khía cạnh sinh của nó, một báo
cáo lỗi b được xem như một đối tượng được tạo bởi ba tham số 𝑍𝑏 , 𝜃𝑏 , ∅. Như hình 3. Ví dụ đối với báo cáo lỗi b, mô
hình sẽ sinh vector 𝑍𝑏 để xác định chủ đề cho mỗi vị trí dựa vào xác suất 𝜃𝑏 tính tỉ lệ từ của b. Mỗi chỉ mục sẽ tương ứng
với từ 𝑤𝑏 theo chủ đề được gán và việc phân bổ từ trên mỗi chủ đề ∅𝑖 tương ứng với chủ đề đó, quá trình này gọi là tiến
trình sinh của mô hình LDA. Khi một báo cáo lỗi mới được gửi đến, mô hình LDA sẽ thực hiện việc gán chủ đề 𝑍𝑏𝑛𝑒𝑤 và
tỷ lệ 𝜃𝑏𝑛𝑒𝑤 của những chủ đề này cho 𝑏𝑛𝑒𝑤 .
Chúng tôi sẽ training mô hình này với dữ liệu đã tồn tại trong các kho quản lý lỗi bao gồm những tập tin báo cáo lỗi và
thông tin trùng lặp của nó. Những thông tin này sẽ được sử dụng để ước lượng cho vector dùng để gán chủ đề của tất cả
các tập tin báo cáo lỗi cũng như tỷ lệ xác suất của chủ đề mà nó có thể chia sẻ có cùng một lỗi. Để dự đoán lỗi, chúng tôi
áp dụng mô hình này cho một báo cáo lỗi mới vừa gửi đến. Khi đó tham số huấn luyện để ước lượng tỷ lệ của từng chủ
đề 𝜃𝑏𝑛𝑒𝑤 của 𝑏𝑛𝑒𝑤 . Việc tính độ tương đồng dựa vào tỷ lệ các chủ đề giữa 𝑏𝑛𝑒𝑤 và nhóm báo lỗi trùng lắp G được tính
như sau:
𝑡𝑜𝑝𝑖𝑐𝑠𝑖𝑚(𝑏𝑛𝑒𝑤 , 𝐺) = (𝑡𝑜𝑝𝑖𝑐𝑠𝑖𝑚(𝑏𝑛𝑒𝑤 , 𝑏𝑖 ) ) (1)
4 ĐỊNH DẠNG CHO VIỆC IN ẤN BÀI BÁO TRONG KỶ YẾU CỦA FAIR
Trong đó topicSim(𝑏𝑛𝑒𝑤 , 𝑏𝑖 ) là độ tương đồng chủ đề giữa hai báo cáo lỗi 𝑏𝑛𝑒𝑤 , 𝑣à 𝑏𝑖 . Điều này có nghĩa là độ tương
đồng cao nhất sẽ được lấy giữa báo cáo lỗi 𝑏𝑛𝑒𝑤 và nhóm báo cáo lỗi trùng lắp G. Chúng tôi sử dụng kỹ thuật của Jensen-
Shannon divergence để làm việc này. Cuối cùng tất cả những nhóm báo cáo lỗi trùng nhau Gj sẽ được sắp xếp lại và
nhóm có độ tương đồng cao nhất theo sắp xếp top-k sẽ được xem như là một ứng viên trùng với báo cáo lỗi mới 𝑏𝑛𝑒𝑤 .
C. Mô hình đặc điểm trọng số mới (NWF)
1. Trọng số BM25
Phần này giới thiệu về việc tính trọng số mới. Sau khi chuyển những từ
trong tập tin báo cáo lỗi sang mô hình không gian vector với mỗi từ tương
ứng một chiều. Giá trị trọng số của nó phụ thuộc vào xác suất từ đó xuất
hiện trong một báo cáo lỗi. Việc tính độ tương đồng 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 xuấ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 đó). IDF (Inverse Document
Frequency) dùng để ước lượng mức độ quan trọng của từ đó như thế nào.
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 q i.
2. Giới thiệu đặc điểm trọng số mới (NWF)
Mặc dù BM25 cho thấy sự hiệu quả của nó đối với việc tính đặc điểm trọng số. Tuy nhiên, theo [9] BM25 vẫn còn những
hạn chế, cụ thể đối với việc tính cosine ranking, BM25 cho kết quả tốt hơn đối với câu truy vấn ngắn. Ngược lại đối với
câu truy vấn dài thuật toán này chưa cho thấy hiệu quả của nó. Điều này cũng gặp phải đối với một vài thuật toán xếp
hạng không chỉ cho BM25. Để khắc phục hạn chế này, sau khi quan sát đánh giá dữ liệu từ những tập tin báo cáo lỗi,
chúng tôi nhận thấy rằng BM25 không được chứa giá trị âm, và chỉ cho kết quả tốt đối với câu truy vấn ngắn. Sau khi
phân tích chúng tôi nhận thấy điều này liên quan đến thành phần IDF:
𝑁+1 (𝑘1 + 1). 𝑡𝑓𝑡𝑑
𝑟𝑠𝑣𝑞 = ∑ 𝑙𝑜𝑔 ( ). (4)
𝑑𝑓𝑡 + 0.5 𝐿𝑑
𝑡 ∈𝑞 𝑘1 ((1 − 𝑏) + 𝑏. ( )) + 𝑡𝑓𝑡𝑑
𝐿𝑎𝑣𝑔
Nhan Minh Phúc, Nguyễn Thừa Phát Tài, Nguyễn Hoàng Duy Thiện 5
Khi đó chúng tôi đề xuất lại IDF bằng cách sắp xếp lại để có:
𝑁+1 (𝑘1 + 1). 𝐶𝑡𝑑
𝑟𝑠𝑣𝑞 = ∑ 𝑙𝑜𝑔 ( ). (5)
𝑑𝑓𝑡 + 0.5 𝑘1 + 𝐶𝑡𝑑
𝑡 ∈𝑞
Trong đó
𝑡𝑓𝑡𝑑
𝐶𝑡𝑑 = 𝐿𝑑 (6)
1−𝑏+𝑏.( )
𝐿𝑎𝑣𝑔
Đối với công thức này, chúng tôi quan tâm đến sự ảnh hưởng của thành phần C td, để khắc phục trường hợp đối với
câu truy vấn dài. Giải pháp đưa ra là bổ sung thêm một hằng số nguyên dương O, điều này có tác dụng làm thay đổi
chức năng ưu tiên số nhỏ hơn (nghĩa là mẫu số lớn, giá trị Ld lớn hoặc tài liệu dài).
D. Kết hợp LDA với đặc điểm trọng số mới
Trong phần này chúng tôi giới thiệu mô hình kết hợp giữa LDA với NWF để dò tìm những báo cáo lỗi trùng nhau.
Trong mô hình của chúng tôi, chúng tôi đưa ra hai kỹ thuật dự đoán p1 và p2. Kỹ thuật p1 dựa vào mô hình chủ đề
(LDA), và p2 dựa vào đặc điểm trọng số mới. Hai kỹ thuật này có những ưu điểm khác nhau trong mô hình dự đoán
những báo cáo lỗi trùng nhau. Kỹ thuật NWF sẽ cho kết quả chính xác hơn nếu hai báo cáo lỗi có độ tương đồng về
thuật ngữ trong tập tin báo cáo lỗi. Tuy nhiên, kỹ thuật này sẽ cho kết quả thấp nếu hai báo cáo lỗi mô tả cùng một lỗi
(trùng nhau) nhưng lại được mô tả bằng những thuật ngữ khác nhau trong hai báo cáo lỗi. Ngược lại kỹ thuật sử dụng
mô hình chủ đề LDA dò tìm hai báo cáo lỗi có trùng nhau hay không dựa vào độ tương đồng chủ đề giữa hai báo cáo
lỗi, thậm chí trong trường hợp hai báo cáo lỗi này không có độ tương đồng về thuật ngữ trong hai báo cáo lỗi. Nghĩa là
hai báo cáo lỗi sử dụng những từ ngữ khác nhau nhưng cùng mô tả về một lỗi phát sinh, khi đó phương pháp này cho
kết quả dò tìm tốt hơn phương pháp p1. Tuy nhiên do phương pháp LDA dựa vào độ tương đồng chủ đề giữa hai báo
lỗi, trong khi chủ đề thường là một sự tóm tắt nội dung mô tả lỗi do đó kết quả tính độ tương đồng của nó cũng sẽ không
hiệu quả bằng việc so sánh giữa các thuật ngữ như cách tính đặc điểm trọng số của từ.
Với việc kết hợp cả hai kỹ thuật, chúng ta có thể tận dụng ưu điểm của cả hai phương pháp để bổ trợ cho nhau trong
việc tính độ tương đồng giữa hai báo cáo lỗi để xử lý việc dò tìm những báo cáo lỗi trùng nhau cho kết quả hiệu quả
hơn. Để làm công việc này chúng tôi sử dụng một kỹ thuật học máy gọi là Ensemble Average, đây là một mô hình tuyến
tính. Việc kết hợp này được thực hiện như sau:
p=⍺1 x p1 + ⍺2 x p2 (7)
Trong đó ⍺1 và ⍺2 là những tham số trong việc ước lượng những báo cáo lỗi trùng nhau và phải thỏa điều kiện
⍺1+⍺2=1. Điều này có nghĩa nếu ⍺1=1 và ⍺2=0, khi đó chỉ áp dụng kỹ thuật một nghĩa là sử dụng mô hình LAD. Ngược
lại nếu ⍺1=0 và ⍺2=1 khi đó phương pháp dò tìm sử dụng kỹ thuật tính độ tương đồng giữa hai báo cáo lỗi dựa vào đặc
điểm trọng số NW. Việc chọn giá trị để tối ưu cho hai tham số này sẽ được thảo luận trong phần thực nghiệm training
cho phương pháp được giới thiệu.
IV. THUẬT TOÁN
A. Thuật toán cho mô hình LDA
Mục đích của thuật toán này là để ước lượng những tham số cho mô hình LDA như 𝑧𝑏 , 𝜃𝑏 , và 𝜃𝑏𝑟 với dữ liệu training
là kho báo cáo lỗi B và tập hợp những nhóm báo cáo lỗi trùng nhau {Gj(b)}.
Chúng tôi sử dụng thuật toán Gibbs sampling để làm điều này. Đầu tiên hai tham số 𝑧𝑏 và 𝜃𝑏𝑟 được gán cho những
giá trị ngẫu nhiên. Khi đó một vòng lặp được thực hiện để ước lượng mỗi tham số dựa vào việc tính phân bổ chủ đề từ
những giá trị có sẳn. Vòng lặp sẽ kết thúc khi tổng của sự khác nhau giữa việc phân bổ chủ đề được ước lượng hiện tại
và sự phân bổ chủ đề được ước lượng trước đó nhỏ hơn hoặc bằng ngưỡng. Ý tưởng thực toán được mô tả như sau:
1. Ước lượng việc gán chủ đề cho những báo cáo lỗi trong B
Với mỗi báo cáo lỗi b trong B, mô hình LDA ước lượng việc gán chủ đề 𝑧𝑏 [𝑖] cho vị trí i. Cho mỗi chủ đề k trong K chủ
đề, nó sẽ ước lượng dựa vào xác suất mà chủ đề k được gán cho vị trí i trong báo cáo lỗi b. Khi đó nó gán một chủ đề
dựa vào giá trị xác suất của k. Có hai trường hợp xảy ra, trường hợp thứ nhất một báo cáo lỗi không có báo cáo lỗi nào
trùng với nó, khi đó việc ước lượng gán chủ đề được thực hiện theo thuật toán của Gibbs sampling trong mô hình LDA
như sau:
(𝑁𝑏 [−𝑖, 𝑘] + 𝛼). (𝑁𝐵𝑅,𝑘 [−𝑖, 𝑤𝑖 ] + 𝛽)
𝑝(𝑧𝑏 [−𝑖]], 𝑤𝑏 ) = (8)
(𝑁𝑏 − 1, +𝐾𝛼). (𝑁𝐵𝑅,𝑘 − 1 + 𝑉𝛽)
Trong đó 𝑁𝑏 [−𝑖, 𝑘] là số từ trong b (ngoại trừ vị trí hiện tại thứ i) được gán đến chủ đề k. Nb là tổng số từ trong b.
(𝑁𝐵𝑅,𝑘 [−𝑖, 𝑤𝑖 ] là số từ wi trong tất cả những báo cáo lỗi B (ngoại trừ vị trí hiện tại) được gán đến chủ đề k. 𝑁𝐵𝑅,𝑘 là tổng
số từ trong B được gán đến chủ đề k.
Trường hợp thứ 2: nếu một báo cáo lỗi b được xác định trùng nhau với nhóm báo cáo lỗi Gj, nghĩa là nó sẽ có cùng chủ
đề với nhóm này. Khi đó chúng tôi sử dụng công thức bên dưới:
6 ĐỊNH DẠNG CHO VIỆC IN ẤN BÀI BÁO TRONG KỶ YẾU CỦA FAIR
2. Ước lượng cho chủ đề dựa vào 𝜃𝑏 cho báo cáo lỗi b
Sau khi việc gán chủ đề cho tất cả vị trí trong b được ước lượng, tỷ lệ ước lượng 𝜃𝑏 [𝑘] của chủ đề k trong b có thể được
tính đơn giản bằng tỷ lệ giữa số từ được mô tả trong chủ đề k và chiều dài của báo cáo lỗi.
3. Ước lượng việc phân bố từ 𝜃𝐵𝑅
Đây là bước cuối cùng được dùng để ước lượng việc phân bố từ trên mỗi chủ đề. Đối với mỗi từ wi trong Voc và chủ đề
k. 𝜃𝑘 [𝑤𝑖 ] được tính dựa vào tỷ lệ giữa số lần mà từ từ đó tại vị trí thứ i trong Voc được sử dụng để mô tả chủ đề k và tổng
số lần mà bất kỳ thuật ngữ được sử dụng để mô tả cho chủ đề k.
B. Mô hình LDA-NWF
Mô hình LDA-NWF là sự kết hợp giữa mô hình LDA và mô hình đặc điểm trọng số mới. Khi đó chúng ta cần xác định
⍺1 và ⍺2 để tính độ tương đồng giữa những báo cáo lỗi và những nhóm báo cáo lỗi trùng nhau. Đầu tiên chúng tôi
training mô hình LDA và NWF. Những tham số của mô hình được training dùng để ước lượng mức độ tương đồng giữa
hai báo cáo lỗi và mức độ tương đồng chủ đề của một báo cáo lỗi với những nhóm báo cáo lỗi trùng nhau. Những mức
độ tương đồng này được kết hợp sử dụng sim(Btest, Gtest) thông qua một đặc điểm trọng lượng khác nhau ⍺1. Việc kết
hợp những giá trị tương đồng được được dùng để xếp hạng giữa những báo cáo lỗi và những nhóm báo cáo lỗi trùng
nhau. Danh sách xếp hạng Lpred được sử dụng để đánh giá chức năng của MAP(Gtest, Lpred) được sử dụng để tìm giá
trị tối ưu cho ⍺1. Giá trị ⍺1 sẽ nhận được từ giá trị cao nhất được trả về từ MAP(Gtest, Lpred). Hàm này được sử dụng
để tính độ chính xác trung bình [3] và được định nghĩa như sau:
1 |𝐿𝑡𝑒𝑠𝑡 | 1
𝑀𝐴𝑃(𝐿𝑡𝑒𝑠𝑡 , 𝐿𝑝𝑟𝑒𝑑 ) = |𝐿 ∑𝑖=1 (10)
𝑡𝑒𝑠𝑡 | 𝑖𝑛𝑑𝑒𝑥𝑖
Trong đó Ltest là những liên kết đến những báo cáo lỗi trùng nhau thật trong tập dữ liệu testing. Lpred là danh sách được
sắp xếp của những liên kết đực dự đoán. Indexi là vị trí của nhóm báo cáo lỗi trùng nhau đúng được lấy từ truy vấn thứ
i. Do MAP được sử dụng để đo lường độ chính xác của thuật toán sắp xếp đối với những liên kết đúng nên có thể coi nó
như chức năng chính trong việc training cho mô hình LDA-NWF.
Trọng lượng từ ⍺1 và ⍺2 được training dùng để tính trong việc kết hợp giữa một báo cáo lỗi và độ tương đồng chủ đề
và được tính như sau:
Sim=⍺1*sim1+⍺2*sim2 (11)
Trong đó sim1 và sim2 là tập tin báo cáo lỗi và độ tương đồng chủ đề giữa một báo cáo lỗi bnew và nhóm báo cáo lỗi
trùng nhau G. Độ tương đồng được kết hợp càng cao thì bnew càng được xem là trùng với những báo cáo lỗi trong
nhóm G.
V. KẾT QUẢ ĐÁNH GIÁ
A. Tập dữ liệu và tham số K
Để đánh giá của phương pháp được giới thiệu, chúng tôi sử dụng cùng tập dữ liệu báo cáo lỗi được công bố trong [9] ,
chi tiết của tập dữ liệu này được mô tả như trong bảng 1. Hai thông tin trong báo cáo lỗi là trường tóm tắt (summary) và
phần mô tả (description) sau khi được rút trích từ các tập tin báo cáo lỗi sẽ được lưu trong cùng một tập tin dữ liệu. Sau
đó chúng tôi tiền xử lý với những kỹ thuật như tách từ, phục hồi từ gốc, bỏ những từ không có nghĩa…Khi đó tất cả
những thuật ngữ còn lại được đánh chỉ mục. Sau giai đoạn này một báo cáo lỗi được xem như một vector trong đó những
từ trong nó được chỉ mục tương ứng. Tất cả báo cáo lỗi được sắp xếp theo trình tự thời gian. Chúng tôi chia tập dữ liệu
sang hai phần: phần dùng cho huấn luyện và phần dùng cho kiểm tra. Phần dùng để huấn luyện bao gồm M báo cáo lỗi
đầu tiên, trong đó 200 báo cáo lỗi bị trùng nhau. Nó được dùng để huấn luyện cho mô hình LDA và NWF. Những báo
cáo còn lại được dùng cho việc kiểm tra đánh giá. Sau khi chúng tôi thực nghiệm cho phần kiểm tra (testing), Nếu nó
xác định một báo cáo trùng nhau b, nó sẽ trả về một danh sách top-k ứng viên những nhóm báo cáo lỗi trùng nhau. Nếu
một báo cáo lỗi được xác định trùng nhau với nhóm lỗi G trong danh sách top-k, chúng tôi đếm nó như có một xác định
Nhan Minh Phúc, Nguyễn Thừa Phát Tài, Nguyễn Hoàng Duy Thiện 7
[1] J. L. a. M. Mezini, "Finding duplicates of your yet unwritten bug report," in 17th European Conference on Software
Maintenance and, 2013.
[2] N. S. a. I. Ciordia, "Bugzilla, ITracker, and other bug," in In 2013 17th European Conference on Software
Maintenance and Reengineering. IEEE, 69–78, 2005.
[3] M. &. B. C.-P. &. H. A. E. Rakha, "Revisiting the Performance Evaluation of Automated Approaches for the
Retrieval of Duplicate Issue Reports," in IEEE Transactions on Software Engineering. PP.
10.1109/TSE.2017.2755005. , 2017.
[4] S. L. D. Chengnian, X. Wang, J. Jiang and S.-C. Khoo, "A discriminative model approach for accurate duplicate
bug report retrieval," in in Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering,
ACM, pp. 45-54., 2010.
[5] Y. C. Tian, "Improved duplicate bug report identification," in In proceeding of the 16th European Conference on
Software Maintenance and Reengineering.
[6] L. Z. T. X. J. A. a. J. S. X. Wang, "An approach to detecting duplicate bug reports using natural language and
execution information," in ACM/IEEE 30th International Conference on Software Engineering, Leipzig, 2008, pp.
461-470, 2008.
[7] "Enhancements for duplication detection in bug reports with manifold correlation features," Journal of Systems
and Software, Elservier, vol. Volume 121, no. November, pp. Pages 223-233, 2016.
[8] N. J. a. W. Weimer, "Automated duplicate detection for bug tracking systems," in IEEE International Conference
on Dependable Systems and Networks With FTCS and DCC (DSN), Anchorage, AK, 2008, pp. 52-61, doi:
10.1109/DSN.2008.4630070., 2008.
[9] D. L. ,. K. a. J. J. C. Sun, "Towards more accurate retrieval of duplicate bug reports," in 26th IEEE/ACM
International Conference on Automated Software Engineering (ASE 2016), pp. 253-262, Lawrence, KS, 2017.
[10] L. H. a. G. C. M. J. Anvik, "Coping with an open bug repository," in in eclipse '05: Proceedings of the 2005
OOPSLA workshop on Eclipse technology eXchange, 2005, pp. 35-39., 2005.
[11] L. Hiew, "Assisted Detection of Duplicate Bug Reports," in Master's thesis, University of British Columbia,
Canada, 2006., 2006.
[12] M. A. a. O. N. P. Runeson, "Detection of Duplicate Defect Reports Using Natural Language Processing," in in
proceedings of the International Conference on Software Engineering, 2007., 2017.
[13] A. H. a. E. S. A. Alipour, "A contextual approach towards more accurate duplicate bug report detection," in 10th
Working Conference on Mining Software Repositories (MSR), San Francisco, CA, 2013, pp. 183-192, doi:
10.1109/MSR.2013.6624026., 2013.
[14] F. T. T. R. A. H. Karan Aggarwal, "Detecting duplicate bug reports with software engineering domain knowledge,"
Journal of Software: Evolution and Process 29, 3 (2017), 2017.
[15] W. T. Xia Tian, "An improvement to TF: Term Distribution based," in 2010 Second International Conference on
Networks Security, Wireless Communications and Trusted Computing, 2010.
[16] J. M. F. U. S. a. A. M. O. Chaparro, "Reformulating Queries for Duplicate Bug Report Detection," in IEEE 26th
International Conference on Software Analysis, Evolution and Reengineering (SANER), 2019, pp. 218-229.,
Hangzhou, China, 2019 .
[17] Z. W. J. Z. C. G. a. Z. Z. Q. Xie, "Detecting Duplicate Bug Reports with Convolutional Neural Networks," in 25th
Asia-Pacific Software Engineering Conference (APSEC), pp. 416-425, Nara, Japan, 2018.
[18] D. M. K. B. H. Cunningham, "GATE: an architecture for development of robust HLT applications," in Proceedings
of the 40th annual meeting on association for computational linguistics, pp.168–175.
[19] ,. M. O. Gospodnetic and E. Hatcher, " Lucene," 2005.
[20] J. Whissell and C. Clarke, "Improving document clustering using Okapi BM25 feature weighting," nformation
Retrieval Journal, vol. Vol. 14, no. Issue 5, pp. p466-487, 2011.
[21] C. S. a. D. L. Yuan Tian, "Improved duplicate bug report identification," in 16th European Conference on Software
Maintenance and Reengineering. IEEE, 385–390., 2012.
Nhan Minh Phúc, Nguyễn Thừa Phát Tài, Nguyễn Hoàng Duy Thiện 9