CHƢƠNG 3 XÂY DỰNG CÔNG CỤ MP3 SEARCH
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ả.
TÀI LIỆU THAM KHẢO
Tiếng Việt
1. Nguyễn Tài Cẩn (1998), Ngữ pháp tiếng Việt (Tiếng - Từ ghép - Đoản Ngữ), NXB Đại học Quốc gia Hà Nội.
2.Nguyễn Thiện Giáp, Phân loại các ngôn ngữ theo quan hệ loại hình,
http://ngonngu.net/index.php?p=234
3.NgonNgu.Net, Cụm từ cố định, http://ngonngu.net/index.php?p=187
4. Tcxdvn.xaydung.gov.vn, Tiêu chuẩn xây dựng Việt nam
http://tcxdvn.xaydung.gov.vn/TCXDVN/TCXDVN.NSF/da73105996deacc047 2570d5005b7a6a/5873b41ce9e8fb63472570c4004da72e?OpenDocument
5. Wikipedia.Org, Loại hình ngôn ngữ,
http://vi.wikipedia.org/wiki/Lo%E1%BA%A1i_h%C3%ACnh_ng%C3%B4n_n g%E1%BB%AF
6. Wikipedia.Org, Lucene, http://vi.wikipedia.org/wiki/ Lucene 7. Wikipedia.Org, Unicode, http://vi.wikipedia.org/wiki/Unicode
Tiếng Anh
8. Anthony Scime, Web mining: applications and techniques
http://books.google.com.vn/books?id=TDhPMs3adw0C&pg=PA53&lpg=PA53 &dq=%22Forward+link+count%22&source=bl&ots=r0_utue0fg&sig=PNBIsNl-K- qlGM2wLfDaGAc4ytI&hl=vi&ei=jiUxS_apKZy-
swOwypS7BA&sa=X&oi=book_result&ct=result&resnum=1&ved=0CAgQ6AEwAA #v=onepage&q=%22Forward%20link%20count%22&f=false
9. Junghoo Cho, Garcia-Molina, H. and Page, L. (1998), Efficient Crawling
Through URL Ordering, http://ilpubs.stanford.edu:8090/347/
10. Junghoo Cho, Hector Garcia-Molina (2002), Parallel Crawlers,
http://rose.cs.ucla.edu/~cho/papers/cho-parallel.pdf
11. www.focuseek.com, Chapter 4. Notes for Search Engine beginners,
http://www.focuseek.com/manuals/User/beginners.html
12. Marc Najork, Janet L. Wiener(2001), Breadth-first Search crawling yields high-quality pages, http://www10.org/cdrom/papers/208/
13. Grossman, Frieder, Goharian(2002),
http://docs.google.com/viewer?a=v&q=cache:ww20te0h39sJ:www.eng.auburn. edu/~gilbert/Comp7120/Concept-50/IR-Building-Inverted-
Index.pdf+building+an+invert+index&hl=vi&gl=vn&pid=bl&srcid=ADGEESi_uMD xtrhmQJCylHryuRCoTFL3fFP7Ngf2dvBVEhpr3bVS53Z6dNUg628zf
14. Prasad Pingali, Jagadeesh Jagarlamudi, Vasudeva Varma, WebKhoj: Indian language IR from Multiple Character Encodings,
http://www2006.org/programme/files/xhtml/5503/fp5503-pingali/fp5503- pingali-xhtml.html
14. Red-gate.com, .NET Reflector,
http://www.red-gate.com/products/reflector/index.htm
15. Sahilthaker (2008), Information Retrieval & Search - Basic IR Models, http://blogs.msdn.com/spt/archive/2008/03/05/information-retrieval-Search- basic-ir-models.aspx
16. Wikipedia.Org, BackLink, http://en.wikipedia.org/wiki/BackLink
17. Wikipedia.Org, Distributed web crawling,
http://en.wikipedia.org/wiki/ Distributed web crawling
18. Wikipedia.Org, HITS algorithm, http://en.wikipedia.org/wiki/HITS
algorithm
19. Wikipedia.Org, Hubs and Authorities,
http://en.wikipedia.org/wiki/Hubs and Authorities 20. Wikipedia.Org, Information retrieval,
http://en.wikipedia.org/wiki/Information retrieval
22. Wikipedia.Org, Lucene, http://en.wikipedia.org/wiki/ Lucene 23. Wikipedia.Org, PageRank, http://en.wikipedia.org/wiki/PageRank
24. Wikipedia.Org, Stemming, http://en.wikipedia.org/wiki/Stemming 25. Wikipedia.Org, Search engine indexing,
http://en.wikipedia.org/wiki/ Search engine indexing
26. Wikipedia.Org, Tf–idf, http://en.wikipedia.org/wiki/Tf–idf
27. Wikipedia.Org, Web Crawler, http://en.wikipedia.org/wiki/Web Crawler
http://en.wikipedia.org/wiki/Search engineindexing
28. Wikipedia.Org, Web Search query, http://en.wikipedia.org/wiki/web
PHỤ LỤC
PHỤ LỤC A. KIẾN TRÚC GOOGLE
Nguồn: http://seogurudelhi.blogspot.com/
Hình vẽ sau đây cho ta một hình dung về kiến trúc mức cao của Google.
Hình 24. Kiến trúc Google.
Quá trình tải các trang Web về và đánh chỉ mục được thực hiện bởi nhiều crawlers phân tán. Có một vài URLserver thực hiện nhiệm vụ chuyển các danh sách URLs cho các crawlers. Các trang Web sau khi được tải về, chúng được chuyển cho storeserver (thực hiện chức năng lưu trữ). Storeserver nén các trang Web lại và lưu trữ chúng tại kho lưu trữ. Mỗi trang Web có một mã hiệu gọi là docID, được gán mỗi khi có một URL mới được phân tích từ trang Web tải về.
Chức năng đánh chỉ mục được thực hiện bởi bộ Indexer và Sorter. Indexer thực hiện việc đọc kho dữ liệu, giải nén tài liệu và phân tích chúng. Các từ được phân tách và được lưu trữ vào các barrels. Ngoài ra, indexer còn thực hiện việc phân tích các thông tin liên quan đến một hyperlink trên trang Web rồi lưu lại các thông tin này (gọi là anchor information) vào anchors file. File này lưu trữ đầy đủ thông tin cho biết liên kết tương ứng chỉ tới đâu và dòng chữ xuất hiện trên trang Web tương ứng với liên kết đó.
URL_Resolver đọc các thông tin trong anchors file và chuyển đổi thành các URL thực sự và căn cứ trên các URL đã có để kết gắn với các docID, đồng thời cũng
tạo nên cơ sở dữ liệu về liên kết (có tác dụng trong việc tính toán độ nổi tiếng của một trang Web).
Sorter thực hiện việc sắp xếp lại barrels theo wordID thay vì theo docID để tạo ra chỉ mục ngược. Chương trình có tên DumpLexicon thu nhận danh sách các từ và tiến hành cập nhật Lexicon (từ điển).
Để trả lời một truy vấn của người dùng, Google sử dụng Lexicon, chỉ mục ngược và PageRanks.
PHỤ LỤC B. CÁC KHÁI NIỆM VỀ SEARCH ENGINE
Nguồn: http://www.cadenza.org/Search_engine_terms/srchad.htm
Adjacency
A property of the relationship between words in a Search Engine (or directory) query. Search engines often allow users to specify that words should be next to one another or somewhere near one another in the Web pages Searched
ArchitextSpider
The name of the Excite Search engine's spider.
Cloaking
The hiding of page content. Normally carried out to stop page thieves stealing