Kỷ yếu Hội nghị KHCN Quốc gia lần thứ XIII về Nghiên cứu cơ bản và ứng dụng Công nghệ thơng tin (FAIR), Nha Trang, ngày 8-9/10/2020
DOI: 10.15625/vap.2020.00210

SỬ DỤNG MƠ HÌNH LDA-NWF CHO VIỆC TỰ ĐỘNG DỊ TÌM
BÁO CÁO LỖI TRÙNG NHAU
Nhan Minh Phúc 1, Nguyễn Thừa Phát Tài1, Nguyễn Hồng Duy Thiện1, Nguyễn Bá Nhiệm1
1
Khoa Kỹ thuật và Cơng nghệ, Trường Đại học Trà Vinh
, ,
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 Offie, 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 quyết vấn đề này. Hiện tại có vài phương pháp được giới
thiệu. Phương pháp thường được sử dụng trước đây là sử dụng kỹ thuật rút trích thơng tin (IR) với mơ hình khơng gian
vector (Vector Space Model) [3, 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]. Ngồi ra cịn một số phương pháp khác như sử dụng mơ hình học máy [7], mơ
hình phân loại nhị phân
Bảng 1. Báo cáo lỗi trên Open Office có mã lỗi: 9002
[8]. Tuy nhiên, giới hạn
Bug ID
9002
của những phương pháp
Product
Math
này chính là kết quả thực
Component
Code
nghiệm thấp đối với việc
Summary
formatting of font attributes
xác định những báo cáo
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.
lỗi trùng nhau. Gần đây,
Workaround are widevec, widehat, widebar etc. Unfortunatelly the „wide‟ version does not
một phương pháp cải tiến
exist for all attributes.
của kỹ thuật rút trích

Also, „bold‟ in formulate is translated into some sort of arial font with poor spacing within
thông tin được nhóm tác
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
giả Sun et al [9] giới thiệu
character kerning.
cho thấy hiệu quả tốt hơn
trong việc tự động dị tìm
Bảng 2. Báo cáo lỗi trên Open Office có mã lỗi 4524
Bug ID
4524
những báo cáo lỗi trùng
Product
Math
nhau. Phương pháp này
Component
UI
sử dụng đặc điểm trọng số
Summary
Space between a vector and its arrow too large.
BM25F kết hợp với việc
Description
Hi,
xem xét trên nhiều thuộc
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
tính của tập tin báo cáo
among the text of a paragraph.
lỗi. Phương pháp này cho
To make myself clear, copy this text in a sxw file then insert in the middle of the previous

kết quả tốt hơn là do dựa
paragraph the formula “vec u” or the formula “widevec AB”. Compare with what you‟d get
vào sự tương đồng giữa
inserting the formula “overline AB”.
Thanks
các báo lỗi cao. Tuy
nhiên, thực tế nhiều báo


SỬ DỤNG MƠ HÌNH LEA-NWF CHO VIỆC TỰ ĐỘNG DỊ TÌM BÁO CÁO LỖI TRÙNG NHAU

532

cáo lỗi khác 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.
Kết hợp 2 mơ hình
Báo cáo lỗi
mới
Cấu trúc và
tiền xử lý

Bc1:Trl-1.1,Trl-1.2,…
Bc2:Trl-2.1,Trl-2.2,…
….
Bcn:Trl-n.1,Trl-n.2,…

Xây dựng mơ
hình LDA

P(z|dnew)


Danh sách
top K
Bc 1
Bc 2
….
Bc K

Xác định độ
tương đồng
LDA với Bc1,
Bc2,.. sử dụng
P(z|d)
Tính tổng
trọng
lượng

Xây dựng mơ
hình NW

Trọng số NW

Xác định độ
tương đồng NW
với Bc1, Bc2,..
sử dụng TF

Điều
chỉnh
tham số


Hình 1. Mơ hình tổng thể LDA-NW

A. Cấu trúc và tiền xử lý báo cáo lỗi
Tất cả báo cáo lỗi trong hệ thống quản lý lỗi được tổ chức theo cấu trúc dữ liệu kiểu danh sách. Cấu trúc này là
một dạng kiểu dữ liệu bảng băm. Trong đó mỗi danh sách chứa một báo cáo lỗi chính Bc (những báo cáo lỗi đầu tiên).
Những báo cáo lỗi Bc này được xem như một khóa chính của mỗi danh sách, và tất cả những báo cáo lỗi Trl trùng với
báo cáo lỗi chính được xem như là những giá trị của danh sách và chứa cùng một loại lỗi với báo cáo chính. Điều này
có nghĩa là mỗi danh sách sẽ chứa một lỗi khác nhau và tất cả những báo cáo lỗi trong danh sách này có cùng một loại


Nhan Minh Phúc, Nguyễn Thừa Phát Tài, Nguyễn Hoàng Duy Thiện

533

lỗi. Khi một báo cáo lỗi mới được gửi đến, nó sẽ được kiểm tra có trùng với báo cáo lỗi đã được gửi đến kho trước đó
hay khơng. 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. Ngồ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ừ, 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”,... Ngồ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,
=[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 2, 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. Xử lý 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 4. 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ủ đề đó, q 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ự
đố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:


SỬ DỤNG MƠ HÌNH LEA-NWF CHO VIỆC TỰ ĐỘNG DỊ TÌM BÁO CÁO LỖI TRÙNG NHAU

534

(


)

(

(

))

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. 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 sử
dụng nhiều nhưng không quan trọng để thể hiện ý nghĩa của đoạn văn, ví
Topic 0
editor
0.24
open
0.23
file
0.14
……….….

Topic 1
repository 0.26
revision
0.18
remote
0.13
……….….

…

Topic K
𝐾
navigator 0.24
browser
0.23
display
0.14
……….….
Hình 3. Mơ hình dữ liệu


Hình 2. Chủ đề và cách chọn chủ đề

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. Tuy nhiên,
phương pháp này còn nhiều hạn chế [15]. Gần đây một vài nghiên cứu đã giới thiệu một phương pháp tính trọng số
mới được gọi BM25 [20]. Phương pháp này cho thấy sự hiệu quả của nó thơng qua kết quả thực nghiệm trên các hệ
thống báo cáo lỗi mã nguồn mở như Mozila, Open Office. 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 [20]. Trong BM25, 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 tố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:
(
)(
)
(
) ∑
( )
(1)
(

)

(

)

Trong công thức (3), 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. 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:
(
( )
(
)
(2)
( )

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.
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 tố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 tố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à điều này liên quan đến thành phần
IDF:


Nhan Minh Phúc, Nguyễn Thừa Phát Tài, Nguyễn Hoàng Duy Thiện

∑

(

535

(


)
((

)
)

( )

(

))

Khi đó chúng tơi đề xuất lại IDF bằng cách sắp xếp lại để có:
∑

(

)

(

)

( )

Trong đó
(

)


Đố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ự đố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
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 TỐN
A. Thuật tốn cho mơ hình LDA
Mục đích của thuật tốn này là để ước lượng những tham số cho mơ hình LDA như

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)}.

,

, và

với dữ liệu

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 thuật 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 sự 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 tố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 ks. 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 tốn của Gibbs sampling
trong mơ hình LDA như sau:


536

SỬ DỤNG MƠ HÌNH LEA-NWF CHO VIỆC TỰ ĐỘNG DỊ TÌM BÁO CÁO LỖI TRÙNG NHAU

)(
)
( )

(
)(
)
Trong đó
là số từ trong b (ngoại trừ vị trí hiện tại thứ i) được gán đến chủ đề k. N b 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 G j, 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:
(
)(
)
(
)
( )
(
)(
)
Trong đó (
là số từ wi trong tất cả báo cáo lỗi trong B, ngồi trừ vị trí hiện tại được gán đến k, và
là số từ trong S đang mô tả thông tin k. So với công thức (4), do một báo cáo lỗi trùng nhau có cùng chủ đề với
những báo cáo lỗi trong cùng nhóm. Tỷ lệ 0 của một chủ đề k được mô tả trong báo cáo lỗi bao gồm tỷ lệ của chủ đề

0b và tỷ lệ chủ đề được chia sẽ 0Fj của nhóm báo cáo lỗi trùng nhau Gj. Từ 3 và 4 chúng ta có
và
(
)
, trong đó
là số thuật ngữ trong b ngoại trừ cho vị trí hiện tại
mà nó được gán trong chủ đề k. Nb là tổng số từ trong b.
là tổng số vị trí được gán cho chủ đề k trong tất cả các
báo cáo lỗi trùng nhau trong nhóm Gj và NGj là tổng chiều dài của các báo cáo lỗi này. Công thức này tác động đến
việc chia sẽ chủ đề trong việc ước lượng của
] làm
phản ánh và được ước lượng thông qua tỉ lệ
.
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 V oc 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 [24] và được định nghĩa như sau:
(

)

∑

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ự đố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 tố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
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,…


Nhan Minh Phúc, Nguyễn Thừa Phát Tài, Nguyễn Hoàng Duy Thiện


537

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 đúng. Chúng tơi khi đó sẽ thêm báo cáo lỗi b đến nhóm đó để huấn luyện sau này. Độ chính xác top-k
hay cịn gọi là recall rate được tính bằng tỷ lệ số báo cáo xác định đúng trên tổng số những báo cáo lỗi đang xem xét.
Recal rate =

Kho Bc lỗi

Thời gian
thu thập

Số
lượng
Bc lỗi

Số Bc
trùng
nhau

Số Bc
dùng
huấn

luyện

Số
Bc
kiểm
tra

Ngồi ra chúng tơi cũng xem xét sự tác
động liên quan đến việc chọn số chủ đề K. Chúng
OpenOffice 01/01/2008- 31,138
3,371
200
3,171
tôi chạy thực nghiệm trên dữ liệu Eclipse trong
21/12/2010
khoảng 20 đến 400 với khoảng cách là 20 và kết
01/01/201075,
6,925
200
6,725
quả lấy trong top-10. Kết quả như Hình 4. Từ Mozzilla
31/12/2010
653
việc quan sát kết quả chúng ta có thể thấy rằng K
càng nhỏ (K<60) cho độ chính xác thấp. Lý do số
Eclipse
01/01/2008- 45,234
3,080
200
2,880

đặc điểm đặc trưng của các báo lỗi quá nhỏ để
31/12/2008
phân biệt lỗi do có quá nhiều báo cáo lỗi được
phân loại cùng một nhóm chủ đề. Khi đó số chủ đề tăng đồng nghĩa độ chính xác cũng tăng lên. Tuy nhiên, độ ổn định
có sự khác nhau chút ít đối với các kho lỗi. Ví dụ K=[140-320] đối với Eclipse, K=[120-300] cho OpenOffice và
K=[100-240] cho Mozzila. Điều này cũng cho thấy rằng với giá trị của K cho mỗi dự án phần mềm khác nhau có giá trị
cao sẽ cho kết quả ổn định về độ chính xác trong dị tìm báo cáo lỗi trùng nhau. Lý do số lượng chủ đề lớn phản ánh tốt
số lỗi trong những tập tin báo cáo lỗi. Tuy nhiên, trong trường hợp K>380, chúng tôi quan sát thấy độ chính xác bắt
đầu giảm bởi vì khi đó số chủ đề lớn có thể dẫn đến sự chồng lắp ngữ nghĩa và một báo cáo lỗi có nhiều chủ đề với tỷ
lệ tương đồng gần giống nhau. Điều này ảnh hưởng đến độ chính xác trong việc dị tìm báo cáo lỗi trùng nhau.
B. So sánh với các phương pháp khác
Để đánh giá hiệu quả của phương pháp, chúng tôi tiến hành thực nghiệm để so sánh với các phương pháp đã
được công bố gần đây. Cụ thể phương pháp của [9], lý do là chúng tôi sử dụng cùng tập dữ liệu với phương pháp này,
ngồi ra chúng tơi cũng so sánh với mơ hình LDA và NWF riêng biệt. Kết quả thực nghiệm cho thấy phương pháp
LDA-NWF cho kết quả tốt hơn phương pháp của C.Sun, LDA và NWF.


538

SỬ DỤNG MƠ HÌNH LEA-NWF CHO VIỆC TỰ ĐỘNG DỊ TÌM BÁO CÁO LỖI TRÙNG NHAU

TÀI LIỆU THAM KHẢO
[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, pp. 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 32 nd 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 16 th 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 30 th International Conference on Software Engineering, Leipzig, pp. 461470, 2008.
[7] "Enhancements for duplication detection in bug reports with manifold correlation features," Journal of Systems
and Software, Elservier, Vol. 121, No. November, pp. 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, 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 26 th 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, 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, 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, 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.
[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), 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. 14, No. Issue 5, pp. 466-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, pp. 385-390, 2012.


Nhan Minh Phúc, Nguyễn Thừa Phát Tài, Nguyễn Hoàng Duy Thiện

539

USING LDA-NWF MODEL FOR AUTOMATIC DUPLICATE BUG REPORT DETECTION
Nhan Minh Phuc, Nguyen Thua Phat Tai, Nguyen Hoang Duy Thien, Nguyen Ba Nhiem
ABSTRACT: Bug reports submitted by users are usually stored and managed by bug management systems in open source
software projects such as Open Office, Mozilla Firefox, Eclipse,... The developers will rely on these bug reports for handling.
However, there are too many bug reports sent to the system, these lead to duplicate bug reports. In other words, the duplicate bug
report is the report that sent by the user before. Therefore, it is necessary to determine whether a new bug report is duplicate or not.
This will take a lot of time and effort of the person assigned to handle the bug. Therefore, the automatic detection of duplicate bug
reports has recently received a lot of attention from researchers. Beside that a bug report file is usually text file, so there will be
cases where the bug reports duplicate are expressed in different words by different users, this will be a challenge for for
researchers. In this paper, we introduce a method to automatically detect duplicate bug reports using the Latent Dirichlet
Allocation-new weight feature (LDA-NWF) model. This model is a combination of the LDA model with the new weighting feature.
Experimental results on the three real data systems Open Offie, Eclipse and Mozilla show that the introduced method achieves 4-9
% higher accuracy than the previous methods when compared across all three systems.