Sử dụng Dismax trong Solr 1.4.x, 3.x

1. Giới thiệu

DisMaxRequestHandler(thường được gọi ngắn gọn là Dismax) được thiết kế để xử lý các câu truy vấn đơn giản( không bao gồm các ký tự đặc biệt của Solr) mà người dùng cung cấp sau đó tìm kiếm các đơn vị từ(term) trên những trường(field) xác định với trọng số(boost) khác nhau. Thêm nữa hệ thống này còn giúp thay đổi điểm trả về dựa trên những quy tắc đặc thù cho từng use-case cụ thể.

Solr Lucene

2. Cách sử dụng

Để sử dụng có 2 cách khai báo tham số
qt=dismax sẽ sử dụng các tham số phụ khai báo trong file Solr config
defType=dismax sẽ sử dụng tham số truyền vào trên parameter của Solr
Cá nhân tôi hay sử dụng qt=dismax hơn

3. Các tham số dành cho cho dismax

q.alt

Định nghĩa câu truy vấn được sử dụng trong trường hợp câu truy vấn để trống hoặc không được chỉ ra trong tham số gửi lên server.

qf(query fields)

Danh sách các trường và các trọng số sử dụng trong các trường này trong quá trình phân tích câu truy vấn mà người dùng cung cấp.  Ví dụ sử dụng fieldOne^2.3 fieldTwo fieldThree^0.4. Chỉ ra rằng trường fieldOne có trọng số là 2.3, trường fieldTwo có trọng số mặc định là 1, trường fieldThree có trọng số là 0.4.  tức là trong trường hợp nếu nội dung câu truy vấn xuất hiện ở 3 trường thì các tài liệu có nội dung trên fieldOne quan trọng hơn tài liệu có nội dung trên fieldTwo và kém quan trọng nhất là tài liệu có nội dung trên fieldThree
Ví dụ định nghĩa qf trong Solr config:
<str name=”qf”>        CategoryName^6.0 Title^1.0     </str>

mm(Minimum ‘Should’ Match):

Trong Solr/Lucene có 3 kiểu mệnh đề là: “phải xuất hiện”, “không được xuất hiện”, và “có thể xuất hiện”(should match). Mặc định khi cung cấp một câu truy vấn Solr sẽ xử lý dạng “có thể xuất hiện” tùy thuộc vào cấu hình trong Solr config. Hoặc cũng có thể cung cấp ký tự đặc biệt để xác định đâu là mệnh đề “không được xuất hiện” đâu là mệnh đề phải xuất hiện. Khi xử lý với  mệnh đề “có thể xuất hiện” thì option “mm” sẽ chỉ ra chính xác số lượng nhỏ nhất các mệnh đề phải xuất hiện( must match).  Dưới đây là một vài ví dụ cài đặt.
- Ít nhất có 2 mệnh đề trong câu truy vấn phải xuất hiện trong tài liệu tìm được, mm=2( hoặc trong define trong Solr Config <str name=”mm”>1</str>)
- Ít nhất 75% mệnh đề phải xuất hiện, 75%
- Nếu từ 1 mệnh đề tới 2 mệnh đề thì bắt buộc phải xuất hiện tất cả. nếu từ 3 mệnh đề trở lên thì ít nhất 75% mệnh phải xuất hiện, 2<-25%
- Nếu từ 1 đến 2 mệnh đề thì bắt buộc phải xuất hiện tất cả. Nếu từ 3 mệnh đề tới 5 mệnh đề(gọi là x mệnh đề) thì x-1 mệnh đề bắt buộc phải xuất hiện. Nhiều hơn 5 mệnh đề thì ít nhất 80% mệnh đề xuất hiện.

Để rõ ràng hơn mọi người có thể tham khảo  quy tắc sử dụng cú pháp trong phần của Lucene.

http://lucene.apache.org/solr/api/org/apache/solr/util/doc-files/min-should-match.html

Nhưng có 2 điểm trái ngược giữa link trên và link

http://wiki.apache.org/solr/DisMaxQParserPlugin

Là:
1. 75% và -25%  ở Solr coi là tương đương, nhưng trong Lucene thì không phải lúc nào cũng là tương đương, do quy tắc làm tròn số khác nhau.
2. Ví dụ cuối trong Lucene khi giải thích 2<-25% 9<-3 có vẻ không hợp lý lắm

pf( Phrase Fields)

Trong danh sách trả về các document, thì tham số “pf”giúp “tăng cường trọng số” boosting cho những tài liệu nào có sự xuất hiện cả câu truy vấn trong một trường field nhất định. Định dạng của cấu hình này tương đương với định dạng tham số qf
<str name=”pf”>   CategoryName^2.0 Title^6.0     </str>
Ý nghĩ của cấu hình này như sau, với tài liệu có “toàn bộ” nội dung câu truy vấn tồn tại trong trường Title thì nhân điểm của nó lên 6.0, với tài liệu có “toàn bộ” nội dung câu truy vấn tồn tại trong CategoryName thì sẽ nhân điểm của nó lên với 2.0

ps(Pharse Slop)

Chỉ ra tham số Slop bổ trợ cho tham số pf (phrase fields).
Khái niệm này phụ thuộc vào khái niệm slop trong phrase query, Slop sẽ xác định số lượng lớn nhất các đơn vị tự (term) xuất hiện giữa 2 term của một câu truy vấn CÂU. Ví dụ với câu truy vấn “anh em”(có ngoặc kép) nếu slop xác định bằng 0 thì chỉ những văn bản có cụm từ “anh em” mới trả về. Nếu slop =1 nghĩa là văn bản chứa “anh em” hoặc “anh yêu em” hoặc “anh và em” đều thỏa mãn, còn văn bản chứa cụm từ “anh không yêu em” không phù hợp. trong trường hợp slop=2 thì các tài liệu trên đều phù hợp.

qs(Query Slop)

Định nghĩa tham số slop bổ trợ cho câu truy vấn.
Mọi người sẽ thấy conflict giữa 2 tham số này, nhưng không phải thế. qs sử dụng cho quá trình tìm kiếm tài liệu và áp dụng cho câu truy vấn chứa các mệnh đề là phrase query. Trong khi đó ps áp dụng cho quá trình boosting tài liệu(sau khi đã tìm thấy tài liệu rồi) và áp dụng cho tham số pf trình bày ở trên.

tie

Khi một đơn vị từ term được đối sánh đối với các trường khác nhau của cùng một văn bản thì có thể có nhiều trường chứa term này với các điểm khác nhau, mặc định của hệ thống Solr/Lucene sẽ sử dụng score lớn nhất trong các score để làm điểm đại diện để tính điểm cho tài liệu.
Tham số tie sẽ giúp điểm cuối cùng sẽ không phải là điểm lớn nhất mà sẽ bao gồm điểm cả các trường khác gộp lại
Max score + tie(điểm trên trường 1+điểm trên trường 2+…)

Nếu tie=0 thì trở về phương pháp tính điểm mặc định của Solr/Lucene, nếu tie=1 thì điểm sẽ là điểm tổng của các trường tìm thấy. Thực nghiệm người ta sử dụng 0.1

bq( Boost Query)

Là một câu query được thêm vào để thay đổi điểm trả về theo một chiều hướng nhất định. Mặc định hệ thống sẽ thêm câu truy vấn phụ này vào câu truy vấn chính rồi truyền xuống phía dưới.

bf(Boost Function)

Là một Function thêm vào câu truy vấn để làm thay đổi điểm của tài liệu trả về. Mọi function được hỗ trợ  bởi Solr đều có thể sử dụng được kèm theo một trọng số tương ứng.

Tham khảo http://wiki.apache.org/solr/FunctionQuery/ để biết rõ hơn về function query

Tham khảo tài liệu tiếng Anh

http://wiki.apache.org/solr/DisMaxRequestHandler

http://wiki.apache.org/solr/DisMaxQParserPlugin

http://lucene.apache.org/solr/api/org/apache/solr/util/doc-files/min-should-match.html

Nguồn: www.aladeck.wordpress.com

Các thách thức kỹ thuật khi xây dựng công cụ tìm kiếm tiếng Việt

Sau nhiều năm sử dụng các công cụ tìm kiếm trên mạng, đồng thời hơn một năm sử dụng mã nguồn mở Solr-Lucene cho mục đích tìm kiếm dữ liệu tác giả xin tổng kết các thách thức kỹ thuật gặp phải khi xây dựng một công cụ tìm kiếm tiếng Việt.

Hình ảnh về các search engine sưu tầm trên mạng

Hiện tại công cụ tìm kiếm tiếng Việt vẫn chưa gặt hái được thành công như Bamboo, Xalo, Socbay,… trong khi đó thì công nghệ tìm kiếm của các ông lớn như Google, Bing đang phát triển mạnh mẽ. Tuy nhiên không phải là không còn những “kẽ hở” để cho công cụ tìm kiếm trong nước phát triển, ví dụ như tìm kiếm theo chiều dọc, hay tìm kiếm thông minh, trên các nền tảng ngoài máy tính…
Cơ hội sử dụng lại/tham khảo mã nguồn mở cũng rất lớn, trong bài viết này tác giả sẽ đề cập đến một thư viện mã nguồn mở rất nổi tiếng là Lucene và một ví dụ thành công là Google Search

1. Đặc thù ngôn ngữ tiếng Việt.

Đặc điểm ngôn ngữ tiếng Anh(một ngôn ngữ phổ thông trên internet) và các ngôn ngữ tương tự là các từ có nghĩa cách nhau bằng một khoảng trắng còn đối với tiếng Việt thì không phải hoàn toàn thế( ví dụ từ ‘ví dụ’, ‘du dương’,… nếu cắt bằng khoảng trắng thì ra các từ đơn vô nghĩa( không biểu hiện nghĩa ban đầu của từ ghép). Như vậy việc xác định từ có nghĩa bằng khoảng trắng để có một đơn vị từ(term) phụ vụ cho mục đích tìm kiếm đối với tiếng Việt là không có giá trị.
Cũng có các công trình nghiên cứu về việc tách từ cho tiếng Việt như vntokenizer của ông Lê Hồng Phương nhưng do tính chất đa nghĩa của câu tiếng Việt nên không phải đoạn văn bản nào cũng có thể tách từ một cách chuẩn xác( ví dụ cụm từ ‘con ngựa đá con ngựa đá’ trong từng hoàn cảnh có ý nghĩa khác nhau).
Như vậy việc xây dựng từ điển từ cho tập văn bản-trang web tiếng Việt là cực kỳ khó khăn và không chuẩn xác. Giải pháp cắt đơn vị từ bằng khoảng trắng có thể áp dụng cho công cụ tìm kiếm tiếng Việt nhưng nó sẽ làm cho việc “hiểu” ngôn ngữ tiếng Việt của công cụ bị bỏ qua. Trong khi đó muốn công cụ tìm kiếm tiếng Việt thành công thì việc địa phương hóa – hiểu tiếng Việt là một yêu cầu số một.

2. Performance và tính mở rộng.

Khi Google ra đời vấn đề performance có thể đã là một câu hỏi nhưng không phải quá quan trọng như ngày nay. Tuy nhiên ngày nay đã khác. Lượng dữ liệu rất lớn và tăng lên theo từng giây đòi hỏi performent và tính mở rộng cực kỳ cao. Số lượng server phục vụ cho Google Search là một con số khổng lồ. Nó đảm bảo Google Search quản lý một lượng dữ liệu rất lớn đồng thời đáp ứng cho nhu cầu mở rộng rất tốt( scale up – thêm mới một server vào hệ thống, bỏ một server ra khỏi hệ thống, một server bị hỏng hóc,… không ảnh hướng tới tính sẵn sàng phục vụ của hệ thống).
Tại thời điểm hiện tại cũng có nhiều giải pháp áp dụng Lucene vào tìm kiếm phân tán như katta, Solr Cloud, Hbasene, HbaseDirectory,.. tuy nhiên kết quả mới dừng ở mức độ nghiên cứu chưa có bản chính thức nào được áp dụng rộng rãi.

3. Thời gian thực(Near realtime)

Hiện nay các mạng xã hội ra đời, thông tin do một lượng lớn người cung cấp nên tốc độ cập nhật thông tin trên những hệ thống này cập nhật gần như tức thì( khi có một sự kiện người ta có thể đưa thông tin lên những mạng xã hội kiểu Twitter, Facebook). Nếu hệ thống tìm kiếm muốn thành công thì phải đi trước đối thủ một bước, tức là cập nhật thông tin từ các mạng xã hội, các trang tin tức một cách nhanh nhất có thể( near realtime).
Để đảm bảo dữ liệu được lập chỉ mục(indexing) một cách gần thời gian thực cũng có các dự án support thư viện Lucene như Zoie. Tuy nhiên đây chỉ là dự án cho một hệ thống Lucene đơn lẻ và nó cũng không tính tới thời gian cập nhật dữ liệu từ hệ thống mạng xã hội sang hệ thống của mình để bắt đầu chức năng lập chỉ mục.

4. Nghiên cứu hành vi của người sử dụng

Việc nghiên cứu hành vi, phân cụm người dùng cũng là một yếu tốt then chốt tạo nên sự thành công của các công cụ tìm kiếm nói chung. Khi lượng dữ liệu rất lớn, đối với cùng một câu truy vấn không thể trả về cùng tập dữ liệu giống nhau cho tất cả người dùng vì mỗi người thuộc một nhóm nhất định và quan tâm tới chủ đề nhất định. Ví dụ đơn giản nếu một lập trình viên tìm kiếm với cụm từ Apple, Red hat,… thì có nhiều khả năng họ quan tâm tới công ty máy tính Apple, hoặc hệ điều hành Red Hat hơn là quan tâm tới mũ đỏ hay quả táo. Đối với công cụ tìm kiếm tiếng Việt cũng không nằm ngoài nhu cầu này.
Như vậy hệ thống tìm kiếm cần phân tích hành vi của người dùng( lịch sử tìm kiếm) để xác định được người tìm kiếm thuộc nhóm người nào giúp trả ra những kết quả phù hợp. Hệ thống Google hiện tại là một ví dụ điển hình, cá nhân tôi khi tìm kiếm với các cụm từ thì các kết quả liên quan tới lập trình luôn có thứ hạng cao.

5. Công thức tính điểm

Công thức tính điểm sẽ quyết định điểm cho mỗi tài liệu-trang web, dựa trên điểm này hệ thống sẽ sắp xếp theo thứ tự kết quả trả về cho phù hợp.
Về bản chất công thức tính điểm là tính điểm “sự tương đồng” giữa câu truy vấn người dùng cung cấp và tập tài liệu-trang web. Hệ thống Lucene sử dụng công thức VSM(Vector Space Model), và công thức này cũng luôn được giới nghiên cứu đánh giá là công thức tính toán rất chuẩn.
Thách thức không nằm ở trong công thức tính điểm mà nằm ở tham số truyền vào công thức tính điểm. Ví dụ cùng một nội dung ở n tài liệu-trang web, tài liệu nào quan trọng hơn trang web nào quan trọng hơn. Nếu cùng tham số truyền vào thì n tài liệu-trang web này có cùng điểm, nhưng thực tế thì không thể thế được. Ví dụ trang vnexpress ra một bản tin, một trang khác copy nội dung về nếu 2 trang web về bản tin này có cùng số điểm là không thể chấp nhận được.
Việc xác định đâu là tài liệu quan trọng hơn, đâu là tài liệu kém quan trọng, đâu là tài liệu spam,.. bằng rất nhiều thông số khác nhau như độ nổi tiếng của trang web, tốc độ cập nhật, lịch sử hình thành,… Đây cũng là đặc sắc của hệ thống tìm kiếm Google mà mọi người thường gọi là PageRank

6. Chất lượng dữ liệu đầu vào

Bản thân tác giả không tham gia nhiều vào các mạng xã hội nước ngoài và hiếm khi theo dõi nội dung này. Tuy nhiên có theo dõi các nội dung trên các mạng xã hội của Việt Nam mới thấy kinh khủng. Ví dụ như cụm từ “rồi ạ” có rất nhiều biến thể ngôn ngữ( về chính tả sẽ là một cụm từ vô nghĩa trong tiếng Việt) như “jồi ak” “zồi aj”… Như vậy việc người dùng tìm kiếm cụm từ “rồi ạ” mà ra cả những cụm từ “jồi ak” “zồi aj” thì hệ thống tìm kiệm thật khó đáp ứng trừ khi hệ thống ghi nhớ lại tất cả các biến thể từ hoặc nghiên cứu hệ  thống chuẩn hóa cụm “jồi ak” “zồi aj” về các từ chuẩn.
Việc gõ chữ không dấu có thể coi là đặc điểm ngôn ngữ tiếng Việt. Gõ sai chính tả coi như là đặc điểm địa phương của tiếng Việt. Tuy nhiên biến thể không dấu hoặc sai chính tả trong một số trường hợp vẫn có nghĩa theo chính tả chuẩn của tiếng Việt nhưng theo nghĩa khác. Như vậy không thể đánh đồng chữ có dấu với chữ không dấu, chữ đúng chính tả và chữ đúng … phụ tả được .
Đáp ứng được nhu cầu này thì gần như là “nối giáo cho giặc” trái với nhu cầu “bảo vệ sự trong sáng của tiếng Việt” trên internet.

Tổng kết

Các vấn đề liệt kê phía trên không thể đảm bảo cho công cụ tìm kiếm tiếng Việt của bạn thành công, nhưng nếu bạn có nhu cầu xây dựng hoặc nghiên cứu một hệ thống tìm kiếm cho tiếng Việt thì những vấn đề liệt kê phía trên chắc chắn bạn cần phải giải quyết. Trong các vấn đề liệt kê phía trên có thể chưa đủ, chưa chuẩn, vậy xin mời các bạn đóng góp về aladeck@gmail.com để bài viết chất lượng hơn.

Nguồn: http://aladeck.wordpress.com

Tham khảo

1. Trang chủ của dự án core Lucene và các dự án liên quan
http://lucene.apache.org/
2. Trang chủ của dự án vntokenizer của ông Lê Hồng Phương
http://www.loria.fr/~lehong/tools/vnTokenizer.php
3. Giới thiệu về VSM(Vector Space Model)
http://en.wikipedia.org/wiki/Vector_space_model
4. Giới thiệu về PageRank
http://en.wikipedia.org/wiki/PageRank

Cài đặt bandwidthd trên Centos

- bandwidthd: là một trình theo dõi dung lượng truyền tải giữa máy chủ Centos và các địa chỉ IP khác. Bài hướng dẫn nhằm vào đối tượng là những người amater, mới làm quen với linux vì bài hướng dẫn sẽ chỉ ra từng bước cụ thể một. Bài hướng dẫn tham khảo bản tiếng Anh tại địa chỉ link và có sự bổ sung những thao tác cơ bản khác.

1. Copy file tgz

http://sourceforge.net/projects/bandwidthd/files/bandwidthd/bandwidthd%202.0.1/bandwidthd-2.0.1.tgz/download

2. Vào thư mục chứa file tgz
- Chạy lệnh “tar -zxvf bandwidthd-2.0.1.tgz”  để giải nén

3. Vào thư mục đã được giải nén để cài đặt(bước này là quan trọng nhất)
./configure && make install

Nó sẽ có  thể bao gồm một hoặc tất cả warrning sau
a) ” error: no acceptable cc found in $PATH”
- yum install gcc
b) “error: Bandwidthd requires but cannot libpng”
- yum install libpng-devel
c) “error: Bandwidthd requires but cannot find libgd”
- yum install gd-devel
d) “error: Bandwidthd requires but cannot find libpcap”
- yum install libcap-devel

4. Cấu hình bandwitdhd
- Vào thư mục /usr/local/bandwidthd/etc/
- Sửa file cấu hình như hình bên

bandwidthd config

5. Chạy bandwidthd
- /usr/local/bandwidthd/bandwidthd
6. Cấu hình bandwidthd initialize cùng hệ thống
- Thêm /usr/local/bandwidthd/bandwidthd
vào file /etc/rc.local

7. cài đặt apache(httpd)
- yum install httpd

8. Cấu hình apache, sau đó retart lại apache

- Thêm vào cuối file config của apache tại đường dẫn /etc/httpd/conf/httpd.conf

Alias /bandwidthd “/usr/local/bandwidthd/htdocs”
<Directory “/usr/local/bandwidthd/htdocs”>
Order Allow,Deny
Allow from All
</Directory>

- Restart lại apache: service httpd retart

9. Truy suất vào địa chỉ http://localhost/bandwidthd

Done,