Khai phá d* li*u quá trình

Download Report

Transcript Khai phá d* li*u quá trình

Khai phá dữ liệu quá trình: Một
số tìm hiểu bước đầu
Nhóm sinh viên thực hiện:
Phạm Văn Thắng K54
Đào Thủy Ngân
K54
Nguyễn Thế Hùng K55
Phân công công việc nhóm
Tên
Phân công
Hoàn Thành
Phạm Văn Thắng
[Aalst11] , [Aalst12]
Hoàn thành
Nguyễn Thế Hùng
[MBA12] , [Aalst12a]
Hòan thành
Đào Thủy Ngân
[MWAB02] , [ADGRVW09]
Hoàn thành
Mục lục
[TFPM 2011] Process Mining Manifesto
[Aalst12] Overview and Opportunities
[MBA12] Efficient Discovery of Understandable
Declarative Process Models from Event Logs
1. Process Mining Manifesto vs [Aalst12]
Overview and Opportunities








Giới thiệu
Event log
Vị trí của khai phá quá trình
Quy trình khai phá quá trình
Phân loại
Đặc điểm
Những nguyên tắc hướng dẫn
Những thách thức
Giới thiệu


Trong thập kỉ vừa qua, khai phá quá trình nổi lên như là
một lĩnh vực nghiên cứu mới tập trung vào phân tích quá
trình sử dụng dữ liệu sự kiện.
Nguyên nhân: có 2 yếu tố chính khiến khai phá quá trình
ngày càng được quan tâm:
◦ Ngày càng có nhiều sự kiện được ghi nhận lại, do đó
cung cấp thông tin chi tiết về lịch sử của quá trình
◦ Cần cải tiến và hỗ trợ quá trình kinh doanh trong điều
kiện môi trường cạnh tranh và thay đổi nhanh chóng
hiện nay


Mục đích: khai phá quá trình nhằm phát hiện, theo dõi
và cải tiến quá trình thực tế bằng cách trích xuất thông
tin từ những bản ghi sự kiện đã có sẵn trong hệ thống
thông tin ngày nay.
Ứng dụng: có ứng dụng trong nhiều miền ứng dụng khác
nhau, trong đó chủ yếu miền ứng dụng quản lý quá trình
kinh doanh.
Event logs
Định nghĩa: là một tập những sự kiện được sử
dụng như đầu vào của khai phá quá trình.
 Những sự kiện không cần thiết phải lưu trữ ở
những log file riêng biệt ( ví dụ những sự kiện
có thể nằm rải rác trên các bảng cơ sở dữ liệu
khác nhau).
 Các sự kiện có thể có các loại thuộc tính bổ sung
( như mốc thời gian, những thông tin giao dịch,
sử dụng tài nguyên…).

Event logs – điểm khởi đầu của khai
phá quá trình
Cấu trúc của event log
Vị trí của khai phá quá trình
Những giai đoạn của một dự án khai phá
quá trình
Phân loại

Khai phá quá trình gồm 3 loại chính:
◦ Phát hiện quá trình ( process discovery )
◦ Kiểm tra sự thống nhất (conformance checking )
◦ Tăng cường mô hình (enhancement )
Phát hiện quá trình




Phát hiện quá trình là loại nổi bật nhất trong kĩ thuật khai phá quá
trình.
Input: event log
Output: mô hình phát hiện
Những mô hình phát hiện thường là những mô hình quá trình ( ví
dụ: một mạng Petri, BPMN, EPC, hay một biểu đồ hoạt động
UML). Tuy nhiên cũng có thể mô tả cách nhìn khác ( ví dụ như
mạng xã hội).
Ví dụ Petri net
Ứng dụng của phát hiện quá trình




Để thảo luận vấn đề giữa những bên liên quan ( để đạt
được sự đồng thuận, điều quan trọng là có một cái nhìn
chung trong quá trình thực tế )
Để tạo ra những ý tưởng cải tiến quá trình ( thấy được
quá trình thực tế và những vấn đề của nó kích thích nỗ
lực tái cơ cấu, tổ chức )
Để mở rộng mô hình
Để thiết lập một hệ thống WFM/BPM ( mô hình quá
trình phát hiện có thể phục vụ như một bản mẫu).
Thuật toán phát hiện quá trình







Hầu hết các cách tiếp cận cổ điển có những vấn đề đối mặt với tính
đồng thời.
Thuật toán α [van der Aalst et al. 2004] là một ví dụ kĩ thuật đơn
giản lấy tính đồng thời làm điểm khởi đầu.
Thuật toán α quét những bản ghi sự kiện cho những mẫu cụ thể
Tuy nhiên thuật toán gặp phải vấn đề với cấu trúc định tuyến phức
tạp và ồn
Ngoài thuật toán α, cách tiếp cận dựa trên khu vực có thể thể hiện
những cấu trúc luồng điều khiển phức tạp hơn mà không
underfitting.
Ý tưởng cơ bản của cách tiếp cận này là phát hiện những vị trí .
Ngoài ra để giải quyết ồn và tính không đầy đủ, phương pháp tiếp
cận khai phá theo kinh nghiệm, khai phá mờ và khai phá quá trình
di truyền được áp dụng
Thuật toán α



Ví dụ nếu hoạt động a theo sau hoạt động b, nhưng b không bao giờ
theo sau a thì sẽ có một giả định rằng có quan hệ phụ thuộc giữa a
và b.
Để thể hiện sự phụ thuộc này chúng ta sử dụng mạng Petri tương
ứng, có kêt nối từ a đến b.
Chúng ta sử dụng kí hiệu
◦ a>b nếu và chỉ nếu có một dấu hiệu σ = {t1, t2, t3, . . . tn} trong
bả n ghi và một i ∈ {1, . . . , n − 1}, sao cho:ti=a và ti+1 = b.
◦ a->b nếu và chỉ nếu a>b và b/> a;
◦ a#b nếu và chỉ nếu a/>b và b/>a;
◦ a||b nếu và chỉ nếu a>b và b>a;
4 quan hệ có thứ tự này được sử dụng để kết nối các quá trình
chuyển trong mạng Petri
Thuật toán khai phá dựa trên kinh nghiệm




Đề cập trong Weijters and van der Aalst[2003]
B1: xây dựng một đồ thị phụ thuộc dựa vào tần số của hành động và
số lần một hành động được theo sau bởi hành động khác.
B2: dựa vào ngưỡng xác định trước, những phụ thuộc được thêm
vào đồ thị phụ thuộc ( hoặc có thể không). Đồ thị phụ thuộc cho
thấy xương sống của khai phá quá trình, dựa vào đó có thể phát hiện
chi tiết hành vi phân chia và gộp nhóm của những node.
B3: kiểm tra nếu một hành động có nhiều cung vào thì liệu đó là
một nhóm AND, một nhóm XOR hay 1 nhóm OR.
◦ trong trường hợp nhóm OR, các hành vi đồng bộ hóa được học
◦ Nếu 1 hoạt động có nhiều cung ra, sau đó hành vi chia được học
theo xu hướng tương tự.
Kiểm tra sự thống nhất
Input: evnt log và mô hình hiện có
 Output: thông tin dự đoán ( cho thấy sự khác nhau và
tương đồng giữa mô hình và bản ghi)
 Mô hình quá trình hiện có được so sánh với một bản ghi
sự kiện của cùng một quá trình. ( do mô hình được sinh
ra trong phát hiện quá trình không dựa vào những thông
tin tiền nghiệm, khác với bản ghi sự kiện).

Ứng dụng của kiểm tra sự thống nhất của
mô hình
Để kiểm tra chất lượng của quá trình được tài liệu.
 Để xác định những trường hợp sai lệch và những gì
chúng tương đồng.
 Để xác định các đoạn quá trình mà hầu hết các sai lệch
xảy ra.
 Cho mục đích kiểm toán
 Để đánh giá chất lượng của một mô hình phát hiện quá
trình
 Để hướng dẫn cải tiến các thuật toán phát hiện quá trình.
 Và như một điểm khởi đầu cho tăng cường mô hình.

Chuẩn đoán sự khác nhau giữa hành vi quan
sát và hành vi được mô hình hóa

Ta sử dụng 4 độ đo chất lượng:
a. độ phù hợp
b. độ đơn giản
c. độ chính xác
d. độ tổng quát
Thuật toán kiểm tra sự thống nhất

Về cơ bản có 3 cách tiếp cận chính:
◦ Cách tiếp cận thứ nhất: là tạo ra một trừu tượng hóa
của hành vi trong bản ghi và một trừu tượng hóa của
hành vi được cho bởi hệ thống
◦ Cách tiếp cận thứ hai: xem lại bản ghi sự kiện trên
mô hình. Một cách tiếp cận hướng đến kiểm tra sự
thống nhất đơn giản là đếm số phần của những trường
hợp được phân tích hoàn toàn.
◦ Cách tiếp cận thứ ba: tiếp cận tính toán sự liên kết tối
ưu giữa mỗi dấu hiệu trong log và hành vi tương đồng
nhất trong mô hình.
Thuật toán theo cách tiếp cận thứ ba

Ví dụ theo mô hình M2





Các phần trên là thuộc bản ghi, phần dưới thuộc mô hình
γ1 cho thấy sự liên kết hoàn hảo
γ2 cho thấy sự liên kết tối ưu với dấu hiệu “adceh”
γ3 cho thấy sự liên kết tối ưu với dấu hiệu “adcefdbeh”
Sự phù hợp có thể được xem xét từ 2 góc độ:
◦ Mô hình không đạt được hành vi thực
◦ Độ lệch thực tế từ mô hình mong muốn
Quan điểm thứ nhất được dùng khi mô hình được xem như là mô
tả, tức là nắm bắt và dự đoán thực tế. Quan điểm thứ hai được sử
dụng khi mô hình có tính quy phạm, dùng để gây ảnh hưởng và
điều khiển thực tế.
Tăng cường mô hình





Input: event log và mô hình
Output: mô hình mới được cải tiến hay mở rộng.
Để mở rộng hay cải tiến mô hình quá trình đã có sử dụng
thông tin về quá trình thực tế được ghi nhận trong một bản
ghi sự kiện
Trong khi kiểm tra sự tương đồng đô độ liên kết giữa mô hình
và thực tế thì mở rộng mô hình lại nhằm mục đích thay đổi
hoặc mở rộng mô hình trước đó
Nếu thêm các thuộc tính bổ xung cho bản ghi sự kiện thì
người ta có thể mở rộng mô hình để thể hiện những điểm bế
tắc, những mức độ dịch vụ, thời gian thông qua,…
Đặc điểm của khai phá quá trình
Khai phá quá trình không giới hạn sự phát hiện
luồng điều khiển
 Khai phá quá trình không chỉ là một loại đặc
biệt của khai phá dữ liệu, mà nó còn có những
yêu cầu mới về kĩ thuật biểu diễn và các thuật
toán được sử dụng để giải quyết bài toán.
 Khai phá quá trình không giới hạn những phân
tích ngoại tuyến

6 nguyên tắc hướng dẫn






GP1: Dữ liệu sự kiện nên được coi là công dân hạng
nhất
GP2: việc trích xuất bản ghi nên được dẫn dắt bởi những
câu hỏi.
GP3: Sự đồng thời, lựa chọn và xây dựng luồng điều
khiển cơ bản nên được hỗ trợ
GP4: Sự kiện nên liên quan đến các thành phần mô hình
GP5: Mô hình nên được coi là trừu tượng hóa có mục
đích của thực tế.
GP6: Khai phá quá trình nên là một quá trình liên tục
11 thách thức của khai phá quá trình











C1: tìm kiếm , hợp nhất và làm sạch dữ liệu sự kiện
C2: xử lý những bản ghi sự kiện phức tạp có đặc trưng đa dạng
C3: tạo những tiêu chuẩn đại diện
C4: đối phó với những khái niệm thay đổi
C5: cải thiện xu hướng thể hiện dùng cho phát hiện quá trình
C6: cân bằng giữa chất lượng với các tiêu chí như: phù họp, đơn
giản, chính xác, và khái quát.
C7: khai phá những tổ chức lai tạp
C8: Cung cấp các hoạt động hỗ trợ
C9: Kết hợp khai phá quá trình với các loại phân tích khác
C10: nâng cao tính khả dụng với người dùng không chuyên
C11: nâng cao tính dễ hiểu với người dùng không chuyên.
2. [MBA12] Efficient Discovery of Understandable
Declarative Process Models from Event Logs
Giới thiệu
 Cách xây dựng mô hình
 Ngôn ngữ khai báo: LTL
 Xây dựng tập constraint dựa vào thuật toán Apriori
 Lọc các constraints

Giới thiệu
Tập trung xây dựng mô hình khai báo ( declare model)
có cấu trúc, dễ hiểu, ( nhưng các mô hình thực tế thường
là rất phức tạp và không có cấu trúc).
 Một declare model gồm các activity là các hoạt động
hay sự kiện.
 Các constraint là các liên kết từ activity này đến activity
kia xác định và dựa vào các mẫu(Template).
 Mỗi template sẽ xác định kiểu của constraint(e.g.
response constraint) và được xác định dựa vào ngôn ngữ
mô hình LTL

Cách xây dựng mô hình

Cách xây đựng mô hình trước đây là tạo ra tất cả các
constraint có thể, sau đó sẽ kiểm tra chúng trên các event
log. Cách này có 2 nhược điểm:
 Khi số lượng các activity trong file log lớn kéo theo
số lượng constraint phải kiểm tra tăng rất nhanh,
không khả dụng trong thực tế.
 Có nhiều constraint không cần thiết sẽ được kiểm
tra là đúng trong event log và sẽ có những constraint
chứa trong constaint khác.
Cách xây dựng mô hình

Gồm 2 bước:
◦ B1: Xậy dựng tập constraint ban đầu dựa vào thuật
toán Apriori.
◦ B2: Loại bỏ các constraint thừa không cần thiết dựa
vào kết hợp các ma trận quan hệ đơn của constraint
với event log: Confidence, Support, hay phức tạp hơn
là Interest Factor(IF), Conditional-Probability
Increment Ratio(CPIR).
Ngôn ngữ khai báo: LTL
Ngôn ngữ này xác định thứ tự của các activity:

Ví dụ: (□a → ◊b) : Khi nào mà a sảy ra thì kéo theo
đó b cũng xảy ra
 - Phát hiện các constraint không cần thiết dựa vào LTL
vacuity detection: thêm điều kiện vào constraint trên
ngôn ngữ LTL để loại bỏ các constraint không cần thiết.
 Ví dụ: □(a → ◊b) thêm điều kiên ◊a để tăng độ chính
xác của việc kiểm tra constraint này quan event log loại
bỏ các trường hợp không có a trong process instance
nhưng constraint này vẫn đúng.

Xây dựng tập constraint dựa vào thuật toán
Apriori
Tạo ra các constraint xuất phát và có khả năng nhất.
 Định nghĩa Support của một tập các activity A:
Ʃ là tập tất cả các activity trong event log.
t ∊Ʃ*: là một chuỗi activity thuộc một số process
instance.
ℒ = [t1, t2, …, tn].
A một tập các activity trong Ʃ.



Sau khi thuật toán kết thúc thì các bộ có supp() trên
ngưỡng từ đầu đến cuối thuật toán là các tập phổ biến.
Từ các bộ này ta xây dựng các constraint dựa vào ngôn
ngữ LTL:
◦ Ví dụ: 1 bộ phổ biến là (a, b) người ta có thể thành lập
được:
 □(a → ◊b) và
 □(b → ◊a)
Ngoài ra ta còn có thể tạo ra các bộ chứa các activity
không sảy ra như: ¬a(không sảy ra a).
Ví dụ
Ví dụ trong trường hợp tính đến các activity
không có trong process
Lọc các constraints


Sẽ có nhiều constraint thưa do sự tạo thành mọi trường hợp có
thể sảy ra từ tập phổ biến:
◦ Ví dụ: (a, b) là bộ phổ biến nhưng chỉ có □(a → ◊b) là xuất hiện
nhiều còn □(b → ◊a) thì rất ít trong process nên □(b → ◊a) sẽ
là constraint không đúng.
Các cách loại bỏ constraint sai:
 Một số khái niệm mới:
 Antecedent và consequent: Đây là 2 phần của 1 constraint

Kiểm tra các constraint qua các process instance trực tiếp sau để tìm
xem constraint nào phổ biến, cái nào không đúng
Đưa thêm một chỉ số đo nữa là Confidence(Độ tin cậy): Khi đó ta sẽ
dựa vào conf() của một constraint để quyết định xem constraint này
có phải là phổ biến hay không

Ngoài ra còn dựa vào một số đôk đo khác

Toolkit

Sử dụng open-source tool ProM
Tài liệu tham khảo
[Aalst11] WMP Van der Aalst (2011). Process Mining:
Discovery, Conformance and Enhancement of Business
Processes, Springer, 2011.
[Aalst12] Wil M. P. van der Aalst: Process Mining:
Overview and Opportunities, ACM Trans. Management
Inf.Syst.3(2): 7 (2012)
[MBA12] Fabrizio Maria Maggi, R. P. Jagadeesh Chandra
Bose, Wil M. P. van der Aalst (2012). Efficient
Discovery of Understandable Declarative Process
Models from Event Logs, CAiSE 2012: 270-285.
[TFPM 2011] Process Mining Manifesto