Hệ thống quản lý tri thức và tích hợp API cho các hệ thống chatbot

Ở các hệ thống hội thoại khi người dùng đưa ra câu hỏi hoặc sự kiện bất kỳ đến hệ thống, hệ thống sẽ xử lý truy vấn để tìm ra ý định phù hợp thông qua luồng nghiệp vụ được xây dựng để tiến hành trích xuất các tham số. Luồng nghiệp vụ đó dựa trên các tham số, truy vấn dữ liệu từ cơ sở dữ liệu hoặc hệ thống bên thứ ba để đưa ra hành động hoặc câu trả lời phù hợp với ý định. Cuối cùng hệ thống gửi câu trả lời hoặc hành động tương ứng về cho người dùng. Với mỗi bộ dữ liệu hoặc API bên thứ ba khác nhau thì cần xây dựng luồng nghiệp vụ phù hợp để có được kết quả chính xác

Hệ thống quản lý tri thức và tích hợp API cho các hệ thống chatbot

Danh mục các từ viết tắt xiii

Danh mục thuật ngữ xiv

Chương 1 Giới thiệu đề tài 15

2.2.1 Quản lý cấu trúc dữ liệu động 21

2.2.2 Sinh API cho tri thức 22

2.3 Dịch vụ API 23

Mục lục

2.3.1 Quản lý API tri thức 23

2.3.2 Quản lý API tích hợp 24

Chương 3 Phân tích thiết kế hệ thống 27

3.1 Tổng quan chức năng 27

3.1.1 Biểu đồ use case tổng quan 27

3.1.2 Biểu đồ use case phân rã quản lý tri thức 28

3.1.3 Biểu đồ use case phân rã quản lý API 28

3.1.4 Quy trình nghiệp vụ 29

3.2 Đặc tả chức năng 29

3.2.1 Đặc tả use case Tạo thông tin tri thức 30

3.2.2 Đặc tả use case Tạo cấu trúc dữ liệu 30

3.2.3 Đặc tả use case Tạo dữ liệu 31

3.2.4 Đặc tả use case Nhập dữ liệu cho tri thức 32

3.2.5 Đặc tả use case Tạo API tùy biến 33

3.2.6 Đặc tả use case Tạo API tích hợp 34

3.2.7 Đặc tả use case Truy cập API 36

3.3 Yêu cầu phi chức năng 37

3.5.5 Thiết kế màn hình hiển thị lịch sử chỉnh sửa tri thức 44

3.5.6 Thiết kế màn hình hiển thị thông tin API 45

3.5.7 Thiết kế màn hình hiển thị nhập liệu cho người nhập liệu 46

3.5.8 Thiết kế popup 46

3.6 Thiết kế chi tiết backend 46

3.6.1 Luồng hoạt động 46

3.6.2 Thiết kế API 53

3.7 Thiết kế cơ sở dữ liệu 55

Chương 4 Xây dựng và triển khai hệ thống 62

4.2.3 Minh hoạ các chức năng chính 67

4.3 Kiểm thử và triển khai 78

Chương 5 Kết luận và hướng phát triển 79

5.1 Kết luận 79

5.2 Hướng phát triển 80

Tài liệu tham khảo 81Phụ lục A-1

A Đặc tả use case A-1A.1 Đặc tả use case Chỉnh sửa tri thức A-1A.2 Đặc tả use case Khôi phục dữ liệu A-2A.3 Đặc tả use case Chỉnh sửa API A-3B Danh sách test case B-4

Hình 1 Dialogflow 15

Hình 2 Kiến trúc tổng quan hệ thống quản lý tri thức và tích hợp API 20

Hình 3 Mô tả cơ sở dữ liệu của cấu trúc dữ liệu động theo NoSQL 21

Hình 4 Minh họa truy vấn dữ liệu từ API tri thức 24

Hình 5 Tính năng quản lý API tích hợp 24

Hình 6 Luồng tạo API tích hợp 25

Hình 7 Luồng truy vấn API tích hợp 26

Hình 8 Biểu đồ use case tổng quan 27

Hình 9 Biểu đồ use case phân rã quản lý tri thức 28

Hình 10 Biểu đồ use case phân rã quản lý API 28

Hình 11 Biểu đồ hoạt động quy trình tạo tri thức 29

Hình 18 Thiết kế màn hình tạo mới 43

Hình 19 Thiết kế màn hình lịch sử chỉnh sửa tri thức 44

Hình 20 Thiết kế màn hình thông tin API 45

Hình 21 Thiết kế màn hình nhập liệu 46

Danh mục hình vẽ

Hình 22 Thiết kế popup 46

Hình 23 Biểu đồ trình tự truy cập API 47

Hình 24 Biểu đồ trình tự truy cập API tích hợp 48

Hình 25 Biểu đồ trình tự lấy dữ liệu từ tri thức 49

Hình 26 Biểu đồ trình tự thêm dữ liệu vào tri thức 49

Hình 27 Biểu đồ trình tự sửa dữ liệu tri thức 50

Hình 28 Biểu đồ trình tự xóa dữ liệu tri thức 50

Hình 29 Biểu đồ trình tự tạo tri thức 52

Hình 30 Biểu đồ thực thể liên kết 55

Hình 31 Thiết kế tổng quan cơ sở dữ liệu 56

Hình 32 Tạo tri thức - bước 1 68

Hình 33 Tạo cấu trúc dữ liệu dạng biểu mẫu 69

Hình 34 Xem trước biểu mẫu 69

Hình 35 Nhập dữ liệu dạng JSON 70

Hình 36 Chọn file dữ liệu 70

Hình 37 Nhập đường dẫn Google Sheet 71

Hình 38 Định nghĩa cấu trúc dữ liệu từ file 71

Hình 39 Xác nhận lấy dữ liệu hay không 72

Hình 40 Xem dữ liệu dạng danh sách 72

Hình 41 Chỉnh sửa dữ liệu 73

Hình 42 Xem dữ liệu dạng bảng 73

Hình 43 Thông tin cơ bản của API 73

Hình 44 Thiết lập người phát triển và điều kiện bảo mật 74

Hình 47 Thống kê API dạng bảng 76

Hình 48 Bước 1 tạo API tích hợp - truy cập API bên thứ ba 76

Hình 49 Bước 2 tạo API tích hợp - xử lý tham số 77

Hình 50 Bước 3 tạo API tích hợp - cấu hình API trung gian 77

Bảng 1 Thiết kế cơ sở dữ liệu cho cấu trúc dữ liệu của tri thức 22

Bảng 2 Danh sách API tri thức tổng quát 23

Bảng 3 Đặc tả use case Tạo thông tin tri thức 30

Bảng 4 Đặc tả use case Tạo cấu trúc dữ liệu 30

Bảng 5 Đặc tả use case Tạo dữ liệu 31

Bảng 6 Đặc tả use case Nhập dữ liệu cho tri thức 32

Bảng 7 Đặc tả use case Tạo API tùy biến 33

Bảng 8 Đặc tả use case Tạo API tích hợp 34

Bảng 9 Đặc tả use Truy cập API 36

Bảng 10 Cấu hình chung giao diện 41

Bảng 11 Danh sách API 53

Bảng 12 Thiết kế chi tiết cơ sở dữ liệu 57

Bảng 13 Danh sách thư viện và công cụ sử dụng để xây dựng hệ thống 66

Bảng 14 Thông số hệ thống 67

Bảng 15 Cấu hình server 78Bảng 16 Đặc tả use case Chỉnh sửa tri thức A-1Bảng 17 Đặc tả use case khôi phục dữ liệu A-2Bảng 18 Đặc tả use case Chỉnh sửa API A-3Bảng 19 Danh sách test case B-4

Danh mục bảng

Danh mục các từ viết tắt

File Tập tin

Collections

Là nhóm của nhiều document trong MongoDB Collection có thể được hiểu là một bảng tương ứng trong cơ sở dữ liệu quan hệ

Danh mục thuật ngữ

Chương 1 giới thiệu những vấn đề thực tế dẫn đến lý do chọn đề tài, tổng quan về hệ thống quản lý tri thức và xây dựng API cho bot Tiếp theo đưa ra mục tiêu, phạm vi đề tài, định hướng giải pháp và bố cục đồ án

1.1 Đặt vấn đề

Hình 1 Dialogflow1

Ở các hệ thống hội thoại khi người dùng đưa ra câu hỏi hoặc sự kiện bất kỳ đến hệ thống, hệ thống sẽ xử lý truy vấn để tìm ra ý định phù hợp thông qua luồng nghiệp vụ được xây dựng để tiến hành trích xuất các tham số Luồng nghiệp vụ đó dựa trên các tham số, truy vấn dữ liệu từ cơ sở dữ liệu hoặc hệ thống bên thứ ba để đưa ra hành động hoặc câu trả lời phù hợp với ý định Cuối cùng hệ thống gửi câu trả lời hoặc hành động tương ứng về cho người dùng Với mỗi bộ dữ liệu hoặc API bên thứ ba khác nhau thì cần xây dựng luồng nghiệp vụ phù hợp để có được kết quả chính xác

Dữ liệu từ cơ sở dữ liệu dùng để trả kết quả cho ý định chia làm hai dạng Dạng thứ nhất là các tri thức gắn với dữ liệu để huấn luyện Khi các dữ liệu này thay đổi thì cần huấn luyện lại làm mất nhiều thời gian, tài nguyên và công sức Dạng thứ hai là các tri thức độc lập, không nằm trong dữ liệu huấn luyện Để hệ thống hội thoại có thể sử dụng các tri thức dạng này cần viết các API truy vấn dữ liệu Việc người phát triển viết từng API cho mỗi tri thức

Chương 1 Giới thiệu đề tài

sẽ rất mất công, khó khăn và tốn tài nguyên khi có sự thay đổi dữ liệu, cập nhật sửa đổi API hay phát triển cho hệ thống khác

Ví dụ các hệ thống QA hay bot sẽ có phần dữ liệu dùng để training, sau khi training thành công phần dữ liệu này sẽ trở thành tri thức để bot truy vấn Với các tri thức phức tạp cần hệ thống riêng để quản lý, viết riêng API cho nó Nếu tri thức không quá phức tạp thì có thể tổng quát cho nhiều ứng dụng chatbot, callbot, khác nhau để có thể sử dụng cho nhiều domain, cơ quan, tổ chức

Ngoài các dữ liệu được lưu trong cơ sở dữ liệu, các hệ thống hội thoại còn sử dụng dữ liệu từ bên thứ ba thông quan API được cung cấp Ví dụ các ứng dụng bot về dự báo thời tiết để có dữ liệu trả lời thì cần được cơ quan khí tượng thủy văn quốc gia cấp API để truy vấn dữ liệu về thời tiết Các API được cung cấp như thế thường dữ liệu trả về các ứng dụng chưa sử dụng được ngay mà cần xây dựng nghiệp vụ để cấu hình lại dữ liệu Điều đó gây khó khăn trong việc quản lý vì bên thứ ba thay đổi cấu trúc của dữ liệu hay cấu hình API thì các ứng dụng cũng cần sửa lại nghiệp vụ, khởi động lại hệ thống hay các thay đổi khác để bot có dữ liệu chính xác

Chính vì vậy em tạo ra “Hệ thống quản lý tri thức và xây dựng API cho bot” để quản lý tri thức và API tập trung, dễ dàng sử dụng xây dựng bot, không cần xây dựng lại tri thức hay API khi có thay đổi, nâng cấp hay thêm mới Đồng thời trong quá trình phát triển tiếp theo của hệ thống, em có thể xây dựng thêm các tính năng mới phù hợp với yêu cầu của người dùng

1.2 Mục tiêu và phạm vi đề tài

Từ những vấn đề đặt ra ở phần 1.1, mục tiêu đặt ra là phát triển hệ thống (i) quản lý tri thức và (ii) xây dựng api cho bot có thể được sử dụng để truy vấn dữ liệu Trong đó, hệ thống quản lý tri thức cho phép tạo các bộ tri thức, mỗi bộ tri thức là tập hợp của các bộ dữ liệu có cùng mục đích sử dụng Với mỗi bộ tri thức, hệ thống cần hiển thị đầy đủ dữ liệu của bộ tri thức đó, có cách thức nhập liệu phù hợp với mọi người dùng, có thể theo dõi, kiểm soát được sự thay đổi dữ liệu Đồng thời cũng cần có hướng dẫn để người dùng có thể dễ dàng tạo bộ tri thức cho mình Bên cạnh đó với mỗi bộ tri thức cũng cần cung cấp các API để dễ dàng truy vấn dữ liệu Các API được tạo ra sẽ tiếp tục được phát triển, quản lý ở hệ thống xây dựng API Hệ thống này cần hiển thị đầy đủ thông tin liên quan đến API, cho phép người dùng thử nghiệm các API, qua đó người quản lý có thể nắm bắt được tình hình sử dụng dữ liệu

Các bộ tri thức và API được xây dựng cần tuân theo một quy trình để đảm bảo tính toàn vẹn và bảo mật dữ liệu Bên cạnh đó hệ thống cần có giao diện thân thiện, phù hợp với đa dạng người dùng và dễ dàng phát triển thêm tính năng mới

1.3 Định hướng giải pháp

Do hệ thống lấy dữ liệu làm tiền đề, cho phép truy vấn dữ liệu từ nhiều hệ thống khác nhau nên cần thiết kế để xây dựng được tri thức từ bộ dữ liệu, lưu trữ được nhiều dữ liệu, dễ dàng tạo và chỉnh sửa Hệ thống cho phép tạo cấu trúc dữ liệu động để có thể xác định được cấu trúc của mỗi bộ dữ liệu và xây dựng lên cấu trúc cho từng tri thức từ đó dễ dàng thêm dữ liệu thành cùng một chủ đề Để hệ thống có thể lưu trữ dữ liệu linh hoạt theo cấu trúc dữ liệu động thì hệ thống sử dụng MongoDB làm cơ sở dữ liệu MongoDB cho phép lưu trữ được nhiều dữ liệu giải quyết vấn đề lưu dữ liệu lớn, cho phép lưu dữ liệu phi chuẩn, cấu trúc linh hoạt giúp giải quyết sự đa dạng về các bộ dữ liệu khi xây dựng cấu trúc dữ liệu cho từng bộ Bên cạnh đó tốc độ xử lý dữ liệu với Mongo cũng rất nhanh giúp cho việc truy vấn không mất nhiều thời gian

Hệ thống cho phép xây dựng các API để truy vấn dữ liệu từ các bộ tri thức, sẽ sinh các API tự động cho tri thức khi tri thức được tạo đồng thời nó cũng cho phép người dùng tạo các API cho tri thức theo mục đích sử dụng Ngoài ra một ứng dụng bot muốn sử dụng dữ liệu của bên thứ 3 nhưng chỉ được cung cấp API truy vấn dữ liệu, dữ liệu trả về chưa thể sử dụng được ngay thì người dùng có thể xây dựng API trung gian để chuẩn hóa dữ liệu đưa về dạng phù hợp với nhu cầu Hệ thống sẽ quản lý các API được tạo ra một cách tập trung, thống nhất về mặt truy vấn và cho phép theo dõi lịch sử truy vấn

Để xây dựng hệ thống như vậy em chia hệ thống thành 2 phần là frontend và backend tương tác với nhau qua RESTful API phát triển trên nền tảng web Frontend em sử dụng ReactJS vì đây là một thư viện tập trung vào xây dựng giao diện có thể tách giao diện thành các thành phần nhỏ hơn dễ dàng cho việc tái sử dụng và phát triển trang web Để đồng nhất về ngôn ngữ và định dạng dữ liệu với frontend thì backend em lựa chọn NodeJS với hiệu năng tốt, có thể xử lý sự kiện bất đồng bộ Việc cùng ngôn ngữ Javascript giúp tiết kiệm thời gian xây dựng và giảm bớt lỗi hơn MongoDB sẽ được sử dụng làm cơ sở dữ liệu và Redis hỗ trợ truy vấn API một cách nhanh chóng

1.4 Bố cục đồ án

Phần còn lại của báo cáo đồ án tốt nghiệp này được tổ chức như sau

Chương 2 trình bày đóng góp và giải pháp đặt ra để giải quyết các vấn đề và xây dựng hệ thống quản lý tri thức và xây dựng API cho bot

Trong Chương 3 là các phân tích thiết kế hệ thống, đưa ra tổng quan chức năng và mô tả các chức năng chính

Tiếp đến Chương 4 mô tả các công nghệ sử dụng và chi tiết về quá trình xây dựng và triển khai hệ thống

Cuối cùng Chương 5 tổng kết nội dung đồ án, nêu ra những thành công đạt được, những thiếu sót cần cải thiện và các định hướng phát triển cho tương lai

Dựa trên những vấn đề và mục tiêu em đưa ra ở Chương 1, Chương 2 sẽ đưa ra các giải pháp để giải quyết các vấn đề và đạt được mục tiêu xây dựng được hệ thống quản lý tri thức và tích hợp API áp dụng cho bất kỳ hệ thống hội thoại nào

2.1 Kiến trúc tổng quan

2.1.1 Vấn đề

Với những hệ thống liên quan đến xử lý, lưu trữ và truy vấn dữ liệu thì cần đảm bảo lưu trữ được nhiều dữ liệu, dữ liệu có dụng lượng lớn như ảnh, audio, Việc xử lý và truy vấn cũng cần diễn ra nhanh chóng đặc biệt với các bộ dữ liệu lớn Dữ liệu được trả về từ API thì phải nhanh và chính xác Bên cạnh đó vì cần tạo ra được API từ kho tri thức có sẵn nên cần có sự gắn kết giữa API và tri thức được tạo ra, dữ liệu trả về khi truy vấn API cần chính xác theo tri thức Ngoài ra để hệ thống đáp ứng được số lượng người dùng và yêu cầu lớn, dễ dàng bảo trì sửa lỗi thì có thể chia nhỏ hệ thống dựa trên các tính năng theo kiến trúc microservices

Dựa trên những vấn đề trên, em đã thiết kế kiến trúc hệ thống quản lý tri thức và xây dựng API để đảm bảo tối ưu hiệu năng xử lý dữ liệu và dễ dàng quản lý

2.1.2 Giải pháp

Hình 2 mô tả kiến trúc tổng quan hệ thống quản lý tri thức và tích hợp API bao gồm hai dịch

vụ chính xây dựng theo kiến trúc microservice là:(i) Dịch vụ tri thức và (ii) Dịch vụ API Để sử dụng được các dịch vụ của hệ thống quản lý tri thức và tích hợp API người dùng cần thực hiện đăng nhập thông qua hệ thống IAM Các hệ thống hội thoại sẽ thông qua Gateway API để tương tác với hệ thống để truy vấn dữ liệu từ tri thức được lưu trong cơ sở dữ liệu của hệ thống hoặc thông qua API tích hợp để truy vấn dữ liệu từ bên thứ ba Các API cung cấp để các hệ thống hội thoại truy vấn sẽ dùng được ngay mà không cần phải cấu hình, lập trình hay xây dựng các luồng hội thoại riêng

Chương 2 Giải pháp quản lý tri thức và tích hợp API

Cấu trúc cơ sở dữ liệu được xây dựng theo mô hình “Master-slave pattern” chia làm 1 master và 2 slaver Trong đó master đóng vai trò thêm, sửa, xóa dữ liệu Dữ liệu từ master dược phân phối và đồng bộ với slave Dữ liệu truy vấn từ các API sẽ được trả về từ slave

Hình 2 Kiến trúc tổng quan hệ thống quản lý tri thức và tích hợp API

Dịch vụ tri thức chịu trách nhiệm quản lý tri thức bao gồm tạo tri thức, xử lý truy vấn dữ liệu, theo dõi lịch sử dữ liệu, quản lý nhập liệu và tạo API cho tri thức Mỗi bộ tri thức sẽ thuộc về một chủ đề theo nhu cầu trả lời của bot, được đảm bảo là duy nhất để chính xác khi truy vấn

Dịch vụ API chịu trách nhiệm quản lý, xây dựng các API, xử lý các truy vấn từ bot Khi nhận được truy vấn, dịch vụ sẽ kiểm tra xem API đã từng được truy vấn trong một khoảng thời gian được quy định sẵn trong hệ thống chưa bằng cách kiểm tra dữ liệu trong cache Nếu có sẽ truy vấn dữ liệu từ cache, nếu không có sẽ truy vấn dữ liệu từ 1 trong 2 slaver của cấu trúc cơ sở dữ liệu và lưu dữ liệu vừa được truy vấn vào cache Việc truy vấn như vậy sẽ giúp truy vấn nhanh hơn vì dữ liệu ở cache của máy chủ, nếu dữ liệu đã có thì sẽ không phải gọi lên server của cơ sở dữ liệu

2.2 Dịch vụ tri thức

Dịch vụ tri thức cung cấp các tính năng để quản lý tri thức cho bot như tạo tri thức, quản lý cấu trúc dữ liệu động, xây dựng dữ liệu, theo dõi lịch sử dữ liệu, sinh API tự động cho tri

tính năng sinh API tự động trình bày ở phần 2.2.2 là nổi bật nhất, làm tiền đề để tạo nên tri thức và làm cơ sở để tạo API động cho tri thức

2.2.1 Quản lý cấu trúc dữ liệu động

Hình 3 Mô tả cơ sở dữ liệu của cấu trúc dữ liệu động theo NoSQL

Dữ liệu dành cho bot rất đa dạng, với mỗi nội dung, mục đích trả lời cần bộ dữ liệu khác nhau Mỗi câu trả lời sẽ được dựa vào từ khóa trong câu hỏi để tìm dữ liệu và trả lời thích hợp Khi đó mỗi bộ dữ liệu sẽ cần thu thập các câu trả lời và lưu trữ theo từ khóa Các từ khóa liên quan đến cùng một chủ đề sẽ được tập hợp thành cùng một bộ tri thức Để mỗi bộ tri thức có thể dễ dàng lưu trữ dữ liệu như thế cần xác định trước cấu trúc dữ liệu cho nó Mỗi bộ tri thức sẽ được xây dựng cấu trúc dữ liệu trước khi thêm dữ liệu Cấu trúc dữ liệu sẽ cho phép xây dựng cơ sở nhập liệu của mỗi tri thức, giúp mỗi tri thức sẽ là tập hợp dữ liệu của một chủ đề nhất định, dễ dàng xây dựng dữ liệu cho bot theo các chủ đề khác nhau, đồng thời dễ dàng quản lý và xây dựng các API truy vấn Việc mỗi bộ tri thức có một cấu trúc dữ liệu riêng xây dựng theo mỗi trường dữ liệu sẽ tạo thành cấu trúc dữ liệu động Và để đảm bảo lưu trữ dữ liệu theo cấu trúc linh hoạt thì cơ sở dữ liệu sẽ thiết kế theo NoSQL

Cấu trúc dữ liệu động được xây dựng từ nhiều nguồn dựa theo nguồn dữ liệu (biểu mẫu, file dữ liệu) và dựa trên kiểu dữ liệu của mỗi trường dữ liệu Mỗi trường dữ liệu sẽ có cách để lưu trữ cấu hình khác nhau và khi thêm dữ liệu sẽ có cách lưu dữ liệu theo từng trường khác

nhau để tạo thành bộ dữ liệu của tri thức dựa trên tính chất kiểu dữ liệu của nó như Hình 3

Cấu hình mỗi trường dữ liệu sẽ được lưu thành bộ cấu trúc dữ liệu và các bộ dữ liệu sẽ được tạo thành từ các trường đó Với các kiểu dữ liệu dạng lựa chọn như trắc nghiệm hay danh sách cần có danh sách các lựa chọn để người dùng có thể chọn hoặc có thể cho người dùng thêm câu trả lời khác Với các kiểu dữ liệu file đa phương tiện như hình ảnh hay âm thanh thì dư xlieeuj khi lưu cần có tên file, loại file và dữ liệu cần nén lại để lưu

Bảng 1 Thiết kế cơ sở dữ liệu cho cấu trúc dữ liệu của tri thức Thông tin Kiểu dữ liệu Mô tả

field String Tên trường dữ liệu dataType String Kiểu câu trả lời description String Mô tả

obligate Boolean Bắt buộc trả lời hay không key Boolean Có phải trường định danh không

options Array Danh sách các lựa chọn cho câu trả lời dạng lựa chọn other Boolean Xác định có cho phép thêm câu trả lời cho dạng lựa chọn

2.2.2 Sinh API cho tri thức

Các bộ tri thức sau khi được tạo sẽ tự động sinh ra các API để truy vấn dữ liệu từ tri thức 6 loại API được sinh tự động, tổng quát cho mọi tri thức là: “API lấy danh sách bản ghi” (Lấy ra toàn bộ dữ liệu của tri thức), “API lấy dữ liệu một bản ghi” (Lấy ra các bộ dữ liệu đáp ứng được điều kiện), “API lấy dữ liệu có điều kiện” (Lấy dữ liệu sao cho chỉ lấy các trường được chỉ định, các bộ dữ liệu lấy ra cần đáp ứng được điều kiện nếu có), “API thêm bộ dữ liệu” (Thêm bộ dữ liệu mới cho tri thức), “API chỉnh sửa dữ liệu” (Chỉnh sửa bộ dữ liệu đáp ứng điều kiện), “API xóa dữ liệu” (Xóa bộ dữ liệu đáp ứng điều kiện)

Bảng 2 Danh sách API tri thức tổng quát

Lấy danh sách bản ghi GET /api/v1/datas/:uniqueId

Lấy dữ liệu một bản ghi GET /api/v1/datas/:uniqueId/{conditionList}

Dữ liệu có đều kiện GET /api/v1/datas/:uniqueId/{fieldList}? {conditionList}

Thêm bộ dữ liệu POST /api/v1/datas/:uniqueId

Chỉnh sửa bộ dữ liệu PUT /api/v1/datas/:uniqueId

Xóa bộ dữ liệu DELETE /api/v1/datas/:uniqueId

2.3 Dịch vụ API

Dịch vụ API cung cấp các tính năng quản lý các API được tạo ra và xử lý truy vấn dữ liệu từ API Trong đó 2 tính năng chính là quản lý API tri thức phần 2.3.1 và quản lý API tích hợp phần 2.3.2

2.3.1 Quản lý API tri thức

Để các ứng dụng bot có thể truy vấn dữ liệu từ tri thức thì cần có API để truy vấn API truy vấn dữ liệu có 2 dạng Dạng thứ nhất là các API mặc định, tổng quan cho mọi trường hợp được sinh ra khi tri nhức được tạo thành công ở phần 2.2.2 Dạng thứ 2 là các API tùy biến được người quản lý tri thức tạo ra theo nhu cầu sử dụng với tri thức dựa trên 6 loại API mặc định

Sau khi các API được sinh ra, hệ thống sẽ cho phép những người đủ quyền hạn xem được cách thức sử dụng, thông tin cơ bản, các luật giúp bảo mật dữ liệu của API đồng thời cũng cho phép dùng thử các API trước Người có quyền sử dụng cần nhập chính xác URL, phương thức truy cập API và cung cấp chính xác các điều luật để có thể sử dụng

Hình 4 Minh họa truy vấn dữ liệu từ API tri thức

Các ứng dụng sử dụng API để truy vấn dữ liệu từ các bộ tri thức sẽ qua cùng một bộ quản lý API tri thức Bộ quản lý sẽ tiếp nhận các yêu cầu và xử lý lấy dữ liệu từ tri thức tương ứng để trả về kết quả truy vấn cho ứng dụng Để tránh quá tải khi có nhiều truy vấn cùng một lúc thì hệ thống được triển khai trên nhiều máy chủ khác nhau Các máy chủ sẽ dùng chung một bộ quản lý API tri thức để xử lý

Hình 6 Luồng tạo API tích hợp

Khi người dùng sử dụng tính năng để tạo API trung gian thì API bên thứ 3 sẽ được chuyển đổi định dạng dữ liệu trả về, chuẩn hóa tên trường dữ liệu, lựa chọn các trường dữ liệu cần lấy dữ liệu sao cho phù hợp với nhu cầu Bên cạnh đó người dùng có thể chuyển đổi điều kiện bảo mật sao cho API được tích hợp linh hoạt và phân được cho nhiều người sử dụng nhưng vẫn đảm bảo về vấn đề bảo mật API trung gian sẽ sử dụng REST để xử lý truy vấn thay vì các phương thức khác nhau mà API bên thứ 3 sử dụng

Khi API trung gian được tích hợp và truy vấn, hệ thống sẽ kiểm tra điều kiện bảo mật Sau khi điều kiện bảo mật của API trung gian được đáp ứng, hệ thống sẽ tiến hành truy vấn API bên thứ 3 kèm điều kiện bảo mật của API bên thứ 3 Kết quả truy vấn sẽ được kiểm tra điều kiện đầu vào để lấy dữ liệu cần thiết và chuyển đổi phù hợp với định dạng dữ liệu được thiết lập cho API trung gian và trả về cho người dùng

Hình 7 Luồng truy vấn API tích hợp

Để hiện thực hóa những giải pháp trên thành hệ thống quản lý tri thức và truy cập API cho bot thì cần qua quá trình phân tích thiết kế, xây dựng và triển khai Quá trình này sẽ được trình bày ở Chương 3 và Chương 4

Để xây dựng được hệ thống quản lý tri thức và xây dựng API cho bot thì em đã tiến hành phân tích thiết kế để đưa ra được các chức năng, yêu cầu cũng như là các thiết kế chính cho hệ thống Các nội dung của quá trình phân tích thiết kế hệ thống sẽ được em trình bày trong chương này

3.1 Tổng quan chức năng

3.1.1 Biểu đồ use case tổng quan

Hệ thống quản lý tri thức và xây dựng API cho bot gồm nhiều thành phần và chức năng

Hình 8 thể hiện các chức năng tổng quan và các tác nhân chính của hệ thống

Hình 8 Biểu đồ use case tổng quan

Hệ thống gồm 3 tác nhân chính, đó là: Người sở hữu, Người nhập liệu, Người phát triển Các tác nhân trên là người dùng sau khi đăng nhập vào hệ thống Mỗi người dùng sẽ trở thành tác nhân tương ứng với quyền được phân cho tri thức hoặc API:

• Người sở hữu:Là người tạo ra tri thức hoặc API Có các chức năng liên quan đến quản lý tri thức hoặc API do mình tạo ra như: Phân quyền người dùng, xem chi tiết, chỉnh sửa dữ liệu, theo dõi lịch sử, khôi phục dữ liệu, cập nhật API

• Người nhập liệu: Là người được phân vai trò nhập dữ liệu cho tri thức • Người phát triển: Là sử dụng API cho hệ thống hội thoại

Chương 3 Phân tích thiết kế hệ thống

3.1.2 Biểu đồ use case phân rã quản lý tri thức

Hình 9 Biểu đồ use case phân rã quản lý tri thức

Với chức năng quản lý tri thức người dùng có thể Tạo tri thức, Tạo cấu trúc dữ liệu, Tạo dữ

liệu, Chỉnh sửa tri thức, Xóa tri thức, Theo dõi lịch sử tri thức như Hình 9 3.1.3 Biểu đồ use case phân rã quản lý API

Với chức năng quản lý API người dùng có thể Tạo API, Chỉnh sửa API, Thử nghiệm API,

Kiểm soát API như Hình 10 3.1.4 Quy trình nghiệp vụ

Hình 11 Biểu đồ hoạt động quy trình tạo tri thức

Dịch vụ quản lý tri thức có quy trình nghiệp vụ quan trọng là tạo tri thức với mô tả như sau: Người sở hữu tạo các thông tin cơ bản cho tri thức bao gồm tên, ID và danh sách người nhập liệu, sau đó người sở hữu tạo cấu trúc dữ liệu cho tri thức, cuối cùng dựa trên cấu trúc dữ

liệu để tạo dữ liệu Hình 11 mô tả quy trình tạo tri thức

3.2 Đặc tả chức năng

Phần này sẽ đặc tả các chức năng chính của hệ thống Do dung lượng đồ án có hạn em sẽ trình bày 7 use case: (i) Tạo thông tin tri thức, (ii) Tạo cấu trúc dữ liệu, (iii) Tạo dữ liệu, (iv) Nhập dữ liệu cho tri thức, (v) Tạo API tùy biến, (vi) Tạo API tích hợp, (vii) Truy cập API

3.2.1 Đặc tả use case Tạo thông tin tri thức

Bảng 3 Đặc tả use case Tạo thông tin tri thức Mã use case UC001 Tên use case Tạo thông tin tri thức

Tác nhân Người sở hữu

Tiền điều kiện Người tạo tri thức đăng nhập thành công vào hệ thống Luồng sự kiện

chính (thành công)

STT Thực hiện bởi Hành động

1 Hệ thống Lấy danh sách người dùng có trong hệ thống 2 Người sở hữu Nhập tên tri thức

3 Người sở hữu Thêm ID cho tri thức

4 Hệ thống Kiểm tra xem ID đã tồn tại chưa 5 Người sở hữu Thêm người nhập liệu cho tri thức 6 Người sở hữu Xác nhận thông tin tri thức được tạo 7 Hệ thống Lưu thông tin tri thức

Luồng sự kiện thay thế

STT Thực hiện bởi Hành động

1a Hệ thống Thông báo nếu lấy danh sách người dùng lỗi 4a Hệ thống Thông báo nếu ID đã tồn tại

Hậu điều kiện Không

3.2.2 Đặc tả use case Tạo cấu trúc dữ liệu

Bảng 4 Đặc tả use case Tạo cấu trúc dữ liệu Mã use case UC002 Tên use case Tạo cấu trúc dữ liệu

Tác nhân Người sở hữu

Luồng sự kiện chính (thành công)

STT Thực hiện bởi Hành động

1 Người sở hữu Lựa chọn cách tạo cấu trúc dữ liệu

2 Hệ thống Xử lý hiển thị giao diện tạo tương ứng với cách tạo

3 Người sở hữu Thiết lập thông tin các trường dữ liệu 4 Người sở hữu Xác nhận cấu trúc dữ liệu được tạo 5 Hệ thống Lưu cấu trúc dữ liệu

Luồng sự

kiện thay thế STT Thực hiện bởi Hành động

2a Hệ thống Thông báo và yêu cầu lựa chọn lại cách tạo cấu trúc dữ liệu nếu xử lý lỗi

Hậu điều kiện

Không

3.2.3 Đặc tả use case Tạo dữ liệu

Bảng 5 Đặc tả use case Tạo dữ liệu Mã use case UC003 Tên use case Tạo dữ liệu

Tác nhân Người sở hữu

Tiền điều kiện

Người tạo tri thức hoàn thành xong bước tạo cấu trúc dữ liệu

Luồng sự kiện chính (thành công)

STT Thực hiện bởi Hành động

1 Người sở hữu Lựa chọn cách tạo dữ liệu

2 Hệ thống Xử lý hiển thị giao diện tạo tương ứng với cách tạo

3 Người sở hữu Thêm dữ liệu mới

4 Hệ thống Xử lý và kiểm tra dữ liệu có đúng cấu trúc không

5 Hệ thống Lưu dữ liệu

Luồng sự

kiện thay thế STT Thực hiện bởi Hành động

2a Hệ thống Thông báo và yêu cầu lựa chọn lại cách tạo dữ liệu nếu xử lý lỗi

4a Hệ thống Thông báo nếu dữ liệu không đúng cấu trúc

Hậu điều kiện

Không

3.2.4 Đặc tả use case Nhập dữ liệu cho tri thức

Bảng 6 Đặc tả use case Nhập dữ liệu cho tri thức

Mã use case UC005 Tên use case Nhập dữ liệu cho tri thức

Tác nhân Người nhập liệu

Tiền điều kiện

Người nhập liệu đăng nhập thành công

Luồng sự kiện chính (thành công)

STT Thực hiện bởi Hành động 1 Người nhập

7 Người nhập liệu

Xác nhận gửi biểu mẫu

8 Hệ thống Kiểm tra dữ liệu của người nhập liệu 9 Hệ thống Cập nhật danh sách dữ liệu của tri thức 10 Hệ thống Lưu tri thức sau khi cập nhật

11 Hệ thống Tạo lịch sử dữ liệu tri thức với dữ liệu mới 12 Hệ thống Hiển thị kết quả nhập liệu

Luồng sự kiện thay thế

STT Thực hiện bởi Hành động

2a Hệ thống Thông báo nếu tri thức không tồn tại 3a Hệ thống Thông báo nếu người nhập liệu không có

quyền thêm dữ liệu cho tri thức

8a Hệ thống Thông báo nếu dữ liệu mới không đúng cấu trúc

Hậu điều kiện

Không

3.2.5 Đặc tả use case Tạo API tùy biến

Bảng 7 Đặc tả use case Tạo API tùy biến Mã use case UC010 Tên use case Tạo API tùy biến

Tác nhân Người sở hữu

Tiền điều kiện

Người tạo API đăng nhập thành công vào hệ thống

Luồng sự kiện chính (thành công)

STT Thực hiện bởi Hành động

1 Người sở hữu Chọn tạo API tri thức

2 Hệ thống Lấy danh sách ID của các tri thức mà người sở hữu có quyền tạo API tùy biến và hiển thị các thông tin cần thêm để tạo API

3 Người sở hữu Lựa chọn tri thức cần tạo

4 Hệ thống Lấy ra các trường cấu trúc dữ liệu của tri thức được chọn

5 Người sở hữu Chọn loại API

6 Hệ thống Hiển thị các thông tin cần thêm tương ứng với loại API đã chọn

7 Người sở hữu Thêm các thông tin dựa trên loại API đã chọn

8 Người sở hữu Thêm người phát triển và điều kiện bảo mật cho API nếu cần

9 Người sở hữu Xác nhận tạo API

10 Hệ thống Xử lý và lưu API vào cơ sở dữ liệu

Luồng sự

kiện thay thế STT Thực hiện bởi Hành động

10a Hệ thống Thông báo nếu API đã tồn tại hoặc lỗi khi lưu API

Hậu điều kiện

Không

3.2.6 Đặc tả use case Tạo API tích hợp

Bảng 8 Đặc tả use case Tạo API tích hợp

Mã use case UC006 Tên use case Tạo API tích hợp

Tác nhân Người sở hữu

Tiền điều kiện

Người tạo API đăng nhập thành công vào hệ thống API bên thứ 3 đã tồn tại

Luồng sự kiện chính (thành công)

STT Thực hiện bởi Hành động

1 Người sở hữu Chọn tạo API tích hợp

2 Hệ thống Hiển thị giao diện có các thông tin để tạo API tích hợp

3 Người sở hữu Thêm đầy đủ các thông tin để truy cập API bên thứ 3

4 Người sở hữu Xác nhận truy cập

5 Hệ thống Xử lý truy cập API bên thứ 3

6 Hệ thống Trả về kết quả do bên thứ 3 trả về cho hệ thống

7 Người sở hữu Chuẩn hóa các trường dữ liệu trả về nếu cần 8 Người sở hữu Tạo ID cho API trung gian

9 Hệ thống Kiểm tra Xem ID đã tồn tại chưa 10 Người sở hữu Chọn loại API tích hợp

11 Hệ thống Hiển thị các thông tin cần thêm tương ứng với loại API đã chọn

12 Người sở hữu Thêm các thông tin dựa trên loại API đã chọn 13 Người sở hữu Thêm người phát triển và điều kiện bảo mật

cho API tích hợp nếu cần 14 Người sở hữu Xác nhận tạo API tích hợp

15 Hệ thống Xử lý và lưu API vào cơ sở dữ liệu

Luồng sự

kiện thay thế STT Thực hiện bởi Hành động

5a Hệ thống Thông báo nếu việc truy cập API bên thứ 3 bị lỗi

9a Hệ thống Thông báo nếu ID đã tồn tại 15a Hệ thống Thông báo lỗi khi lưu API

Hậu điều kiện

Không

3.2.7 Đặc tả use case Truy cập API

Bảng 9 Đặc tả use Truy cập API

Mã use case UC008 Tên use case Truy cập API

Tác nhân Người phát triển

Tiền điều kiện

Người phát triển cần có đầy đủ thông tin để có thể truy cập API

Luồng sự kiện chính (thành công)

STT Thực hiện bởi Hành động 1 Người phát

triển Thêm các thông tin cơ bản để tuy cập API bao gồm URL và phương thức 2 Người phát

triển

Cung cấp chính xác điều kiện bảo mật của API

3 Người phát triển

Xác nhận truy cập API

4 Hệ thống Tìm kiếm API được truy cập 5 Hệ thống Xác định loại API được truy cập 6 Hệ thống Lấy thông tin API từ cơ sở dữ liệu

7 Hệ thống Kiểm tra điều kiện bảo mật được cung cấp 8 Hệ thống Truy vấn dữ liệu với loại API tương ứng 9 Hệ thống Trả về kết quả truy vấn cho người phát triển

Luồng sự

kiện thay thế STT Thực hiện bởi Hành động

4a Hệ thống Trả về kết quả API không tồn tại nếu không tìm thấy

Hậu điều kiện

3.3.2 Khả năng mở rộng

Trong tương lai hệ thống có thể phát triển thêm một số tính năng xây dựng API và các bộ tri thức Điều đó có thể làm thay đổi nghiệp vụ, giao diện Do đó cần phải xây dựng để khi mở rộng không làm ảnh hưởng tới chức năng đã có

3.4 Thiết kế kiến trúc

3.4.1 Kiến trúc tổng quan

Hệ thống quản lý tri thức và xây dựng API cho bot được tách biệt làm hai phần: Frontend

và Backend với kiến trúc tổng quan mô tả như Hình 12

Frontend sử dụng ReactJS để xây dựng các thành phần giao diện và sử dụng REST API để gửi yêu cầu và nhận phản hồi từ Backend Kiến trúc frontend sẽ được trình bày chi tiết trong 3.4.2

Backend sử dụng NodeJS xây dựng theo kiến trúc microservices gồm 2 service là API và Knowledge Kiến trúc chi tiết trình bày trong 3.4.3 Dữ liệu được lưu trữ và truy vấn từ MongoDB thông qua ODM Bên cạnh đó Redis sẽ hỗ trợ lưu dữ liệu tạm thời khi các bộ API do hệ thống xây dựng được sử dụng để những lần truy vấn sau nhanh hơn

Hình 12 Kiến trúc tổng quan

Khi frontend muốn giao tiếp với backend sẽ gửi một yêu cầu về backend quan API Route bên backend sẽ nhận yêu cầu gửi đến controller tương ứng Controller sẽ gọi service để xử lý truy vấn cơ sở dữ liệu qua model Sau khi backend xử lý xong sẽ phản hồi kết quả về cho frontend

Ngoài ra, để sử dụng hệ thống thì người dùng cần đăng nhập thông qua dịch vụ IAM

Containers chứa các thành phần kết xuất giao diện theo từng chức năng để hiển thị cho người dùng Hệ thống có 5 containers gồm: (i) Login - giao diện cho người dùng đăng nhập, (ii) Answer - giao diện cho người nhập liệu nhập câu trả lời, (iii) Layout - Bố cục chung cho tất cả màn hình, (iv) KnowleadgeManage - nhóm giao diện liên quan đến quản lý tri thức, (v) ApiManage - nhóm giao diện liên quan đến quản lý API Nhóm giao diện (iv) bao gồm: CreateKnowledge - giao diện tạo hoặc hiển thị thông tin tri thức, KnowledgeHistory - giao diện hiển thị lịch sử chỉnh sửa tri thức, KnowledgeList – giao diện hiển thị danh sách tri thức Nhóm giao diện (v) bao gồm: CreateApi – giao diện tạo API, ApiInfo – giao diện hiển thị thông tin API, ApiList – giao diện hiển thị danh sách API

Routes bao gồm PrivateRoute và PublicRoutes Routes chịu trách nhiệm gọi đến các page tương ứng với đường dẫn người dùng truy cập Với đường dẫn thuộc PrivateRoute thì người dùng cần đăng nhập trước khi truy cập

3.4.3 Kiến trúc backend

Hình 14 Kiến trúc backend

Do hệ thống sử dụng framework ExpressJS để xây dựng backend nên kiến trúc backend bao

gồm 4 thành phần là Routes, Controllers, Services, Models như Hình 14 Routes có nhiệm

vụ nhận yêu cầu từ API để gửi các yêu cầu đến Controller phù hợp, Controllers nhận yêu cầu xử lý các dữ liệu cần thiết và gọi Services tương ứng, Services xử lý luồng nghiệp vụ và truy vấn dữ liệu thông qua Models Bên cạnh đó có 1 thành phần là 3rd party API, đây là thành phần để các API tích hợp truy vấn dữ liệu thông qua API bên thứ 3

3.5 Thiết kế chi tiết frontend

Giao diện được thiết kế trên màn hình có độ phân giải 1920x1080 và được điều chỉnh phù hợp với nhiều loại màn hình

Để thống nhất tính nhất quán cho toàn bộ trang web và tạo giao diện thân thiện cho người dùng thì cần thống nhất về màu sắc, font chữ, nút, cách hiển thị thông báo Các thông tin của

Bảng 10 Cấu hình chung giao diện Thuộc tính Cấu hình

Màu sắc Màu chính: #FFFFFF, #4991e2, #000034

Màu khác: #000000, #E74732, #3C59A9, #FF0000, #008000, #F56565, #ECC94B

Đổ bóng 0px 2px 1px -1px rgba(0,0,0,0.2), 0px 1px 1px 0px rgba(0,0,0,0.14), 0px 1px 3px 0px rgba(0,0,0,0.12) Vị trí hiển thị popup Chính giữa màn hình

Vị trí hiển thị thông báo

Góc dưới bên trái

3.5.1 Biểu đồ dịch chuyển màn hình

Hình 15 Biểu đồ dịch chuyển màn hình

Hệ thống bao gồm các màn hình chính là: Màn hình danh sách tri thức (màn hình trang chủ, từ đây có thể chuyển hướng đến màn hình khác), Màn hình nhập dữ liệu, Màn hình danh sách API, Màn hình tạo tri thức, Màn hình Tạo API, Màn hình thông tin API và các giao diện phụ theo từng tính năng Mối liên hệ và sự chuyển đổi giữa các màn hình được mô tả

trong Hình 15

3.5.2 Thiết kế layout chung

Hình 16 là bố cục giao diện chùng chung cho tất cả các trang khác của hệ thống bao gồm

Header, Sidebar, Content Trong đó Header và Sidebar giống nhau trên các trang trừ trang nhập liệu không có Sidebar Content sẽ thay đổi tùy thuộc vào đường dẫn truy cập Header là thanh tiêu đề trang web Tại đây, người dùng có thể thay đổi ngôn ngữ, đăng xuất hoặc chọn logo để về trang chủ của hệ thống Sidebar chứa các thành phần dẫn đến trang mới của hệ thống

Hình 16 Thiết kế layout hệ thống

3.5.3 Thiết kế màn hình hiển thị danh sách

Màn hình hiển thị danh sách chia làm 3 thành phần như Hình 17 Tương ứng với từng loại

danh sách (danh sách tri thức, danh sách API tri thức, danh sách API tích hợp) mà các thành phần sẽ hiển thị thông tin và thực hiện chức năng khác nhau

Chọn nút tạo sẽ đến trang tạo mới

Khu vực chức năng lọc, tìm kiếm sẽ cho phép lọc danh sách theo từ khóa, theo ngày tạo hoặc

Khu vực hiển thị thông tin từng phần tử của danh sách sẽ hiển thị thông tin cơ bản từng phần tử lấy ra từ danh sách dựa trên loại danh sách Khi chọn vào phần tử sẽ đến xem thông tin chi tiết của phần tử đó

Hình 17 Thiết kế màn hình danh sách

3.5.4 Thiết kế màn hình hiển thị tạo mới (tri thức/API)

Hình 18 Thiết kế màn hình tạo mới

Màn hình tạo mới chia làm 4 phần như Hình 18 Nếu có tri thức được xem thông tin chi tiết

thì màn hình này sẽ trở thành màn hình thông tin tri thức Khi đó khu vực các nút chức năng