CHƢƠNG 3 XÂY DỰNG CÔNG CỤ MP3 SEARCH
3.1. CRAWLER CHO TÌM KIẾM MP3
3.1.7. Chỉ mục trong từ điển âm nhạc
Với mỗi bản ghi âm nhạc được lấy vào từ kho MySQL, chúng tôi sử dụng module TermSeparate ở trên để tách thành các term. Sau đó, chúng tôi có một danh sách các term ứng với mỗi record đầu vào:
ID Title Singer Composer Album
1 Lặng lẽ nơi này Trịnh Công Sơn Trịnh Công Sơn Chìm dưới cơn mưa 2 Làm sao quên được Đức Huy Trịnh Công Sơn Mùa Hè đẹp nhất 3 Ở trọ Khánh Ly Trịnh công sơn Bản Tăngô cuối cùng
Kết quả tách term sẽ là ID Danh sách Term
1 lặng lẽ nơi này trịnh công sơn chìm dưới cơn mưa Hình 23: Mô hình tách từ khóa từ văn bản thô
Loại nhiễu ký tự Mã hóa ký tự Tách từ khóa văn bản thô chỉ số các từ khóa (keyword index) Tách tiếng chỉ số các tiếng (syllable index) Loại từ dừng Thống kê từ khóa chỉ số các từ khóa (keyword index)
vector biểu diễn văn bản theo tần suất xuất hiện
2 làm sao quên được đức huy trịnh công sơn mùa hè đẹp nhất 3 ở trọ khánh ly trịnh công sơn bản tăngô cuối cùng
Bảng 10. Tách term từ tài liệu.
Tất nhiên là chúng tôi phải biến tất cả các chữ hoa thành chữ thường để lưu trữ thống nhất dữ liệu.
3.1.8. Chỉ mục ngƣợc trong từ điển âm nhạc
Sau khi tách các văn bản thành các term xong, chúng tôi sắp xếp các term tăng dần theo từ điển và sắp xếp cùng với nó là id của văn bản chứa nó. Với bảng ở trên, chúng tôi thu được danh sách các term sau khi sắp xếp:
Term ID văn bản bản tăngô cuối cùng 3
chìm dưới cơn mưa 1 đẹp nhất 2 đức huy 2 khánh ly 3 làm sao 2 lặng lẽ 1 mùa hè 2 nơi này 1 ở trọ 3 quên được 2 trịnh công sơn 1 trịnh công sơn 1 trịnh công sơn 3 trịnh công sơn 2 Bảng 11. Danh sách các term theo id văn bản
Quan sát trong danh sách này, chúng ta thấy có trường “trịnh công sơn, 1” xuất hiện nhiều hơn một lần. Do đó, chúng ta thêm một trường nữa là tần số xuất hiện để chống sự trùng lặp này. Từ đó ta có danh sách sau
Term ID văn bản Tần số bản tăngô cuối cùng 3 1 chìm dưới cơn mưa 1 1 đẹp nhất 2 1 đức huy 2 1 khánh ly 3 1 làm sao 2 1 lặng lẽ 1 1 mùa hè 2 1 nơi này 1 1 ở trọ 3 1 quên được 2 1 trịnh công sơn 1 2 trịnh công sơn 3 1 trịnh công sơn 2 1
Bảng 12. Danh sách từ theo văn bản và tần số xuất hiện
Vì danh sách từ điển đã có sẵn, chúng ta có thể ghép những cặp văn bản, tần số với nhau và sắp xếp chúng theo danh sách term. Với mỗi term được đưa ra, chúng tôi sắp xếp theo id của văn bản được đưa ra. Kết quả của việc này là:
Term Văn bản+tần số Văn bản+tần số Văn bản+tần số bản tăngô cuối cùng 3, 1
chìm dưới cơn mưa 1, 1 đẹp nhất 2, 1 đức huy 2, 1 khánh ly 3, 1 làm sao 2, 1 lặng lẽ 1, 1 mùa hè 2, 1
nơi này 1, 1 ở trọ 3, 1 quên được 2, 1
trịnh công sơn (1, 2) (2, 1) (3, 1)
Bảng 13. Danh sách từ và thông tin về từ theo văn bản và tần số xuất hiện
Danh sách này thể hiện được trong văn bản thứ nhất, term “trịnh công sơn” xuất hiện 2 lần, còn trong văn bản thứ 2 và thứ 3 nó xuất hiện một lần. Term “khánh ly” chỉ xuất hiện 1 lần trong term thứ 2.
Đồng thời với việc đánh chỉ mục theo term, chúng tôi còn lưu trữ một danh sách chỉ mục theo tiếng. Nghĩa là, các term được tách thành tiếng đơn thuần theo dấu cách hoặc các dấu ngắt. Bởi vì trong kho dữ liệu của chúng tôi có cả bài hát tiếng Anh và tiếng Việt.
3.1.9. Khó khăn, thách thức của việc đánh chỉ mục
Đánh chỉ mục cho âm nhạc không tồn nhiều thời gian, không đòi hỏi nhiều CPU và không đòi hỏi không gian nhớ lớn vì danh sách bài hát là không lớn. Bản thân nội dung của mỗi trường được đánh chỉ mục như là ca sỹ, bài hát.. độ dài cũng không lớn. Độ dài của bài hát cũng chỉ khoảng 20 chữ là nhiều. Các bài hát không trùng lặp nhiều vì các nhạc sỹ rõ ràng không muốn bài hát của mình trùng tên với người khác. Do đó, độ dài của các invert cũng không lớn. Vì dung lượng chỉ mục là không lớn nên ta có thể lưu toàn bộ chỉ mục này trên Ram để tiện cho việc tìm kiếm
3.2. TÌM KIẾM MP3
Sau khi có invert, chúng ta bắt tay vào xử lý bài toán chính ở đây là tìm kiếm. Để giải quyết bài toán tìm kiếm ta phải làm các bài toán sau:
3.2.1. Phân tích truy vấn
Yêu cầu tìm kiếm (các từ khóa mà người dùng gõ vào) được phân tích trước khi tìm kiếm. Chúng tôi tiếp tục sử dụng công cụ phân tích term theo từ điển để phân tích câu truy vấn người sử dụng. Với một câu truy vấn đưa vào, nếu phân tách thành một term, thì term đó chắc chắn có trong từ điển và trong Invert list chắc chắn có chưa term đó. Nếu term đó không nằm trong từ điển, ta tách term đó thành từng tiếng và sau đó cố gắng tìm term đó trong InvertList bởi vì InvertList của chúng ta có chứa danh sách invert theo term. Trong luận văn này, chúng tôi không xử lý phần truy vấn có nháy.
3.2.2. Tìm kiếm
Với danh sách term thu được, bộ máy truy vấn thực hiện tra cứu trên chỉ mục ngược, tương ứng với một term được chọn, ta sẽ có một danh sách các văn bản có
chứa term đó. Danh sách đó là danh sách những văn bản có thể thỏa mãn yêu cầu. Chúng ta cần tìm ra một tập con các văn bản thực sự phù hợp với truy vấn. Chúng tôi sử dụng mô hình Boolean cho truy vấn. Lúc này, chúng ta cần tìm danh sách các văn bản có chứa ít nhất một trong các term. Tất nhiên, văn bản nào chứa nhiều term hơn, tần số cao hơn sẽ được tính điểm cao hơn và sẽ được ưu tiên trong việc đưa ra kết quả cho người sử dụng. Bài toán ở đây là : có 2 danh sách tăng dần, làm sao có thể nhập chung 2 danh sách đó.
Cách đơn giản nhất để xử lý là: i =1;
j=1;
Chừng nào ( i< độ dài mảng1 và j < độ dài mảng2) thì {
Nếu mảng1[i]< mảng2[j] i++; Nếu mảng1[i]>mảng1[j] i++; Nếu mảng1[i]== mảng1[j]S { i++; j++; } } Nếu mảng1 hết thì duyệt mảng2 đến hết Nếu mảng2 hết thì duyệt mảng1 đến hết
Bảng 14. Thuật toán Merge 2 danh sách đơn giản
Với thuật toán này, ta tìm được danh sách những phần tử có nhiều term nhất, ưu tiên tính điểm cho chúng để đưa ra kết quả
Sau khi có danh sách tổng hợp các id và điểm của chúng, ta tìm cách chọn ra một số ít những văn bản có điểm cao nhất. Để tìm k phần tử lớn nhất trong một danh sách ta n phần tử mà k<< n, ta dùng thuật toán Heap Short. Chi tiết thuật toán vun đống sẽ được trình bày ở phần phụ lục. Ý tưởng chung là với thuật toán này là chúng ta gồm 2 bước: Chuẩn bị đống và vun đống để tìm ra phần tử bé nhất, sau đó lấy phần tử đó ra và vun lại đống. Thời gian để chuẩn bị đống là O(n). Thời gian để tìm ra đỉnh cho mỗi lần tìm kiếm là 0(lgn). Do đó thời gian để tìm ra top k phần tử là O(n)+O(klgn). Nếu cần lấy ra các phần từ từ m đến m+k, ta lấy ra top m+k phần tử, sau đó chọn ra k phần tử cuối cùng.
Nội dung lý thuyết của phần Ranking là 2.9
Vì các bản ghi của MP3 là rời rạc và không có liên kết với nhau, nội dung của chúng lại đơn giản nên chúng tôi không dùng những kỹ thuật rank với tìm kiếm Web để áp dụng cho MP3. Chúng tôi sử dụng những thông tin có sẵn trong các bản ghi MP3 để xếp hạng cho chúng. Tiêu chí xếp hạng của MP3 là:
Stt Tên trường Giải thích 1 int id; Không dùng để rank vì đã dùng để đánh chỉ mục 2 string title; 3 string singer; 4 string composer; 5 string album; 6 string url_download;
Không chứa thông tin để Rank 7 string url_view;
8 int size;
Độ lớn của File càng cao thì chất lượng nhạc càng tốt, có thể dùng để Rank
9 int bit_rate; Bitrate càng lớn thì âm thanh của nhạc càng tốt
10 int duration;
Có những file cùng tên nhưng bị cắt đi chỉ còn 1 phần của file nhạc. Có những host chỉ cho nghe một nửa bản nhạc chứ không phải toàn bộ. Vì vậy đây cũng là tiêu chí để rank
11 string url_cache;
12 string host_name;
Có những host biên tập nhạc rất tốt và có những host không biên tập hoặc chỉ copy lại của những host khác. Vì vậy, những host uy tín cũng là một tiêu chí để rank
13 string lyric;
Có lời bài hát chứng tỏ bài hát được quan tâm kỹ càng hơn. Đây cũng là một lợi thế trong xếp hạng
14 int flag;
Nếu bài hát mới được cập nhật thì là nó sẽ được quan tâm hơn những bài hát cập nhật lâu rồi 15 string update_time;
Bảng 15. Danh sách các trường được Rank
Các tiêu chỉ được chúng tôi chọn để rank các bài hát ở đây được chọn dựa trên bản thân nội dung của các bài hát. Chúng tôi đặt vấn đề bài hát trong trường hợp các bài hát được lấy từ nhiều site nhạc mà những site ấy được chăm sóc cẩn thận. Tất nhiên, trong thực tế dữ liệu chúng tôi có thì không phải bài hát nào cũng có đầy đủ các thông tin như trên, vì thế, chúng tôi sẽ ưu tiên những bài hát nhiều thông tin lên trước. Tuy nhiên, việc sắp xếp các ưu tiên này cho phù hợp đòi hỏi phải có thời gian kiểm thử phần mềm và điều chỉnh theo ý kiến người sử dụng
Cấu trúc form tìm kiếm:
Hộp nhập truy vấn (người dùng sẽ nhập truy vấn vào đây).
Khi người dùng kích chuột vào nút “Begin Search” thì công cụ tìm kiếm MP3 sẽ thực hiện chức năng tìm kiếm với đầu vào là truy vấn do người dùng nhập vào.
Kết quả được đưa ra theo danh sách ở phía dưới
Nếu người sử dụng muốn nghe bài hát nào thì có thể tải vể máy mình để bằng cách bấm vào link Song. Nếu click vào link Singer, Album hoặc Composer, chương trình sẽ hiểu là tìm những bài hát với Singer, Album hoặc Composer tương ứng. Vì dữ liệu do máy tải tự động về hoặc chưa kịp biên tập nên sẽ có những bài hát không chứa đủ thông tin. Thông tin nào thiếu thì sẽ để ô trống tương ứng với vị trí ấy.
3.2.5. Đánh giá phần mềm tìm kiếm MP3
Chúng tôi đã xây dựng một công cụ tìm kiếm theo các bước được nêu ở trên và theo đúng nguyên tắc để xây dựng một phần mềm tìm kiếm. Với đặc trưng dữ liệu là các thông tin về bài hát, ca sỹ, album… đã được người sử dụng biết từ trước nên trong trường hợp người dùng đưa vào những truy vấn với mục tiêu là tìm kiếm thực thì chương trình sẽ trả lại kết quả đúng như mong muốn
Vì chúng tôi đánh chỉ mục cả tiếng Việt có dấu và không dấu nên với những truy vấn không dấu, chúng tôi vẫn đưa ra kết quả chính xác. Nếu trong trường hợp hệ thống có cả bài hát không dấu và có dấu, chương trình sẽ đưa kết quả là bài hát tiếng Việt có dấu, bởi vì chúng tôi đã đánh chỉ mục ưu tiên bài hát tiếng Việt có dấu.
Tốc độ của chương trình là khá đảm bảo cho một truy vấn. Thời gian đáp ứng cho mỗi truy vấn là nhỏ hơn 0.1 giây.
Trong trường hợp người dùng đưa vào truy vấn là một bài hát, ca sỹ.. có trong kho thì thời gian đáp ứng còn nhanh hơn nữa vì những thông tin này đã được đánh chỉ mục.
Chương trình không bị lỗi khi truy vấn vào là những truy vấn không có nghĩa như dấu câu, ký hiệu lạ.. Vì những dữ liệu dạng này không được lưu trữ trong tập chỉ mục ngược.
Chương trình được thiết kế cho việc tìm kiếm cả tiếng Anh và tiếng Việt.
Phần mềm tìm kiếm MP3 là một phần mềm tìm kiếm mini, với mục tiêu là chúng tôi tự xây dựng một công cụ tìm kiếm chứ không sử dụng những công cụ tìm kiểm mã nguồn mở. Chúng tôi hiểu rằng tuy việc sử dụng mã nguồn mở có những ưu điểm trong thời gian thiết kế, có thể sử dụng được ngay… nhưng khó có thể điều khiển và tùy chỉnh theo ý mình được. Nhất là đối với công cụ tìm kiếm, thời gian và sự tối ưu đòi hỏi rất cao, nên chúng tôi muốn tự phát triển để khắc phục được nhược điểm ấy.
PHẦN KẾT LUẬN 1. NHỮNG ĐÓNG GÓP CỦA LUẬN VĂN
Qua luận văn này, chúng tôi đã trình bày những tìm hiểu nghiên cứu về các thành phần của một hệ thống tìm kiếm Web và bước đầu chúng tôi trình bày quá trình tự xây dựng một công cụ tìm kiếm cho MP3. Một hệ thống tìm kiếm là bao gồm nhiều thành phần và mỗi thành phần đều khá phức tạp. Để làm nên một hệ thống tìm kiếm tốt, cần phải có nhiều người và có nhiều nghiên cứu về tất cả các thành phần của một hệ tìm kiếm vì ở mỗi thành phần ấy đều có rất nhiều bài toán đặt ra để giải quyết. Chúng tôi cho rằng muốn nâng cao chất lượng của kết quả tìm kiếm ta chỉ có cách làm tốt và liên tục cải tiến từng thành phần của cả hệ thống, cần phải đưa ra những giải pháp nhanh hơn, chính xác hơn với từng thành phần của hệ thống mà thôi.
Chúng tôi đã áp dụng những kiến thức ấy với dữ liệu Mp3 và chúng tôi thấy nó dễ dàng hơn là dữ liệu Web rất nhiều. Có hiện tượng như vậy bởi vì tuy rằng tìm kiếm Mp3 là một bài toán tìm kiếm đầy đủ nhưng do dữ liệu Mp3 là rất nhỏ so với dữ liệu Web nên chúng tôi không phải giải quyết các bài toán rất khó của Web về tổ chức dữ liệu, tìm kiếm…Từ đó chúng tôi đưa ra kết luận là bài toán tìm kiếm với từng loại loại dữ liệu khác nhau sẽ có những cách giải quyết khác nhau. Những đánh giá về chương trình chúng tôi đã trình bày ở mục 3.2.5 nằm ngay trước phần kết luận.
Sau khi tự mình xây dựng một Search Engine nhỏ, đề tài này đã giúp tôi thu được những kiến thức vô cùng quý báu về một lĩnh vực khá hấp dẫn là tổ chức và khai phá dữ liệu. Chúng tôi tin tưởng rằng, việc tập hợp đầy đủ về lý thuyết tìm kiếm và chỉ ra những khó khăn của công việc tìm kiếm được trình bày ở chương 1 sẽ là tài liệu tham khảo cho nhiều người khi muốn tìm hiểu, nghiên cứu về bài toán tìm kiếm.
2. HƯỚNG PHÁT TRIỂN CỦA ĐỀ TÀI
Với sản phẩm này, chúng tôi thấy là hoàn toàn có thể cải tiến thêm cho chương trình theo hướng hiểu ngôn ngữ Việt hơn nữa, hiểu truy vấn người Việt để có thể trả lời chính xác truy vấn người dùng.
Chẳng hạn, trong trường hợp người dùng muốn tìm “Trịnh Công Sơn” thì chương trình phải hiểu đó là tên của nhạc sỹ chứ không phải là một bài hát có từ “Trịnh Công Sơn” trong đó.
Nâng cao hơn nữa, khi người sử dụng muốn truy vấn là “nhạc Trịnh” thì ý của người dùng là muốn có kết quả là nhạc do “Trịnh Công Sơn” sáng tác hoặc là những bài hát nổi tiếng của Trịnh Công Sơn. Nếu chúng ta đã có một WordNet tiếng Việt mà trong đó sự liên quan giữa 2 từ khóa này là rất cao thì ta có thể suy ra từ khóa này từ từ khóa kia.
Trong trường hợp người sử dụng gõ truy vấn là “Trịnh Côn Sơn” thì chương trình cũng phải hiểu đó là người dùng gõ sai, kết quả chương trình vẫn phải truy vấn tên là “Trịnh Công Sơn”.
Muốn có những kết quả tốt hơn như vậy, chúng tôi cho rằng cần phải đầu tư nhiều thời gian hơn nữa vào việc nghiên cứu những Module tiếng Việt và phần Ranking kết quả.