Ocena modelu

obj ˛eto´sci zapytania zawieraj ˛a najcz ˛e´sciej słowa, które s ˛a do´s´c charaktery-styczne (słowa kluczowe o do´s´c du ˙zym współczynniku IDF).

Bł ˛edna klasyfikacja

Nadanie bł ˛ednej kategorii zapytaniu mo ˙ze doprowadzi´c do znacznego po-gorszenia wyników wyszukiwania. W przypadku gdy u ˙zywana jest ona do wyboru ´zródła wszystko zale ˙zy od strategii jaka została obrana przez bro-kera. Gdy wybiera on jedynie ´zródła zwi ˛azane bezpo´srednio z kategori ˛a to rezultaty takiego wyszukiwania b ˛ed ˛a bezu ˙zyteczne. Nie ma sensu szuka´c informacji o wyspie Java w bazie DBLP, która gromadzi dane z zakresu informatyki. W sytuacji gdy zapytanie trafi równie ˙z do bardziej ogólnych

´zródeł wiedzy (np. wyszukiwarek internetowych), to przy zastosowaniu al-gorytmów filtruj ˛acych i sortuj ˛acych, wyniki nie powinny si ˛e bardzo ró ˙zni´c od wykonania zapytania bez uwzgl ˛edniania kategorii. Ten przypadek ewi-dentnie nie jest tak dotkliwy jak poprzednie. Nie ma jednak sensu stosowa´c wielu skomplikowanych algorytmów tylko po to ˙zeby na ko ´ncu otrzyma´c gorszy wynik. Podsumowuj ˛ac bardzo istotne jest aby brokerzy otrzymywali kategorie, które z du ˙zym prawdopodobie ´nstwem s ˛a poprawne.

W sytuacji gdy kategoria jest u ˙zywana do rozszerzenia zapytania wszystko zale ˙zy od jej ogólno´sci. Im jest bardziej szczegółowa tym mo ˙ze wy-woła´c wi ˛eksz ˛a szkod ˛e. Wyst ˛epuj ˛a dwa rodzaje bł ˛edów. Po pierwsze mo ˙zemy otrzyma´c kategori ˛e, która nie jest logicznie powi ˛azana z zapytaniem. Wpi-suj ˛ac fraz ˛e “query classification” oraz “grocery” wi ˛ekszo´s´c rezultatów b ˛edzie przydatna.

Drugi typ bł ˛edów jest du ˙zo bardziej niebezpieczny. Wi ˛a ˙ze si ˛e z nada-niem innego znaczenia zapytaniu. Załó ˙zmy, ˙ze szukamy informacji o grze w bryd ˙za i wpisujemy słowo “bridge”. Je´sli w wyniku klasyfikacji otrzymamy kategori ˛e “Top/Science/Technology/Structural Engineering” i dodamy do zapytania fraz ˛e “Structural Engineering” ˙zaden ze 100 pocz ˛atkowych rezul-tatów nie dotyczy gry w karty. Niestety istnieje du ˙za podstawa aby przy-puszcza´c, ˙ze ten drugi scenariusz mo ˙ze wyst ˛epowa´c du ˙zo cz ˛e´sciej.

3.5. Ocena modelu

Przetestowanie i ocenienie spersonalizowanego wyszukiwania nie jest spraw ˛a łatw ˛a. System w ramach pozyskiwania danych zmienia swoje za-chowanie w czasie poprzez dostosowanie si ˛e do konkretnego u ˙zytkownika.

3.5. Ocena modelu 31 Gruntowne przetestowanie skuteczno´sci działania wymaga zaanga ˙zowania wielu osób przez do´s´c długi czas.

3.5.1. Techniki oceny silników wyszukiwania

Warto przyjrze´c si ˛e w jaki sposób oceniane jest działanie silników wy-szukiwarek. Jest to temat, który zgromadził szereg opracowa ´n. W pewnym sensie ocena spersonalizowanego wyszukiwania jest jego cz ˛e´sci ˛a.

Cechy dobrego testu wyszukiwania

W pracy [17] autorzy przedstawili 7 cech jakie musz ˛a posiada´c testy silników wyszukuj ˛acych aby były one jak najbardziej skuteczne.

1. Zapytania powinny by´c umotywowane prawdziw ˛a potrzeb ˛a u ˙zytkownika.

2. W przypadku u ˙zycia brokera bazowa potrzeba informacyjna u ˙zytkownika powinna zosta´c w pełni do niego przekazana.

3. Konieczne jest u ˙zycie du ˙zego zakresu tematów.

4. Wi ˛ekszo´s´c głównych silników wyszukiwania powinno zosta´c u ˙zyte (w przypadku testów porównawczych).

5. Ka ˙zdy z silników wyszukiwawczych powinien w jak najwi ˛ekszym stopniu wykorzysta´c swoje specyficzne cechy. Zapytania nie musz ˛a by´c wi ˛ec identyczne.

6. Jako´s wyników powinna zosta´c oceniana przez osob ˛e, która wyraziła zapotrzebowanie na dan ˛a informacj ˛e.

7. Eksperymenty powinny by´c dobrze zaprojektowane i przeprowadzone.

Wska´zniki jako´sci wyszukiwania

Do samego pomiaru jako´sci wyszukiwania informacji u ˙zywa si ˛e sze´sciu wska´zników [22]:

1. Stopnia pokrycia kolekcji.

2. Opó´znienia - ´sredni czas pomi ˛edzy zło ˙zeniem zapotrzebowania na infor-macje a jej otrzymaniem.

3. Formy prezentacji wyników.

4. Nakładu pracy wymaganego przez u ˙zytkownika do pozyskania informa-cji.

5. Stosunek liczby istotnych zwróconych rezultatów do wszystkich istot-nych znajduj ˛acych si ˛e w bazie danych (ang. recall).

6. Precyzja

Punkty 1-4 nie stanowi ˛a zazwyczaj trudno´sci. Jako´s´c rezultatów oceniane s ˛a głównie przez 5 i 6. Pomiar tego jak du ˙zo jest dost ˛epnych wszystkich istotnych dokumentów dla internetu jest jednak niemo ˙zliwy. Sprawia to,

3.5. Ocena modelu 32

˙ze wyliczenie wła´sciwego wska´znika dla punktu 5 jest nieosi ˛agalne według klasycznych metod.

W tym podej´sciu rezultaty oceniane s ˛a binarnie jako interesuj ˛ace lub nie.

W rzeczywisto´sci jednak sprawa oceny przydatno´sci danej strony mo ˙ze by´c bardziej skomplikowana.

Warto sobie równie ˙z zada´c pytanie, czy u ˙zytkownik chce otrzyma´c wszystkie informacje jakie mog ˛a by´c zwi ˛azane z zapytaniem. W przypadku internetu mog ˛a by´c ich tysi ˛ace i z pewno´sci ˛a nie b ˛edzie miał on czasu na przejrzenie ich wszystkich. Istotne jest wi ˛ec aby zaprezentowa´c mu niewielki zbiór, ale za to o jak najwi ˛ekszej jako´sci. W [22] autorzy zaproponowali nowy wska´znik nazwany przez nich ranked precission (RP). Mierzy on efektywno´s´c silników wyszukiwania w zale ˙zno´sci od:

a) Pierwszych n dokumentów zwróconych przez wyszukiwark ˛e (n oznacza liczb ˛e rezultatów, które statystycznie przegl ˛ada u ˙zytkownik t.j. od 20 do 30).

b) Liczby interesuj ˛acych dokumentów oraz ich pozycji w´sród pierwszych n rezultatów.

Dane

Kolejnym aspektem jest to w jaki sposób gromadzi´c dane na temat przy-datno´sci konkretnego wyniku. Najbardziej naturalnym podej´sciem jest za-trudnienie kilku osób, które na bie ˙z ˛aco monitorowałyby jako´s´c przeprowa-dzonych wyszukiwa ´n. Takie rozwi ˛azanie jest jednak bardzo kosztowne. Cie-kawego rozwi ˛azania dostarcza TREC⁶ (Text Retrieval Conference).

TREC

TREC jest to coroczna konferencja odbywaj ˛aca si ˛e od 1992 roku. Jednym z jej głównych celi jest przetestowanie silników wyszukuj ˛acych na du ˙zej bazie rzeczywistych danych. Dane u ˙zyte ka ˙zdego roku s ˛a powszechnie dost ˛epne i mo ˙zna je wykorzysta´c do oceny własnych rozwi ˛aza ´n. Istnieje te ˙z kilka innych powszechnie dost ˛epnych kolekcji bazuj ˛acych na tej samej koncepcji t.j. FIRE⁷, CLEF⁸ czy NTCIR⁹

3.5.2. Techniki stosowane w personalizacji wyszukiwania

Do przetestowania systemów personalizacji potrzebne s ˛a dwie grupy da-nych. Pierwsza słu ˙zy do zbudowania profilu u ˙zytkownika, a druga do oceny

6 trec.nist.gov

7 http://www.isical.ac.in/~fire/

8 http://www.clef-initiative.eu/

9 http://research.nii.ac.jp/ntcir/index-en.html

3.5. Ocena modelu 33

Rysunek 3.2. Precyzja i trafno´s´c

jego działania. Zazwyczaj do zebrania informacji z obu tych grup zatrud-nia si ˛e grup ˛e rzeczywistych u ˙zytkowników. Istniej ˛a jednak prace w których stosuje si ˛e gotowe kolekcje danych takie jak TREC [12, 47] lub logi z wyszu-kiwarek.

Testy na rzeczywistej grupie u ˙zytkowników

Wi ˛ekszo´s´c prac naukowych zwi ˛azanych z personalizacj ˛a wyszukiwania ma jeden element wspólny: bardzo pobie ˙zne testy. Tylko nieliczne prace mog ˛a pochwali´c si ˛e zaanga ˙zowaniem wi ˛ekszej grupy osób do sprawdzenia tego jak w rzeczywisto´sci funkcjonuje zaproponowany system [44]. Za-zwyczaj mamy do czynienia z badaniem przeprowadzonym na kilku (do 10 [25, 31, 40] do kilkunastu (od 11 do 20 [23, 37, 42] u ˙zytkownikach przez okres nie przekraczaj ˛acy miesi ˛aca. Bior ˛ac pod uwag ˛e, ˙ze dla tych przy-padków personalizowane jest ich całe wyszukiwanie, które mo ˙ze dotyczy´c dosłownie czegokolwiek, liczby te s ˛a naprawd ˛e małe. Dodatkowo w pracach mo ˙zna zaobserwowa´c dziwn ˛a tendencje. Te w których testy przeprowadzone s ˛a na małym zbiorze danych maj ˛a zazwyczaj pozytywne wyniki. W przy-padku bardziej obszernych bada ´n rezultaty nie były tak jednoznaczne.

Testy na gotowych kolekcjach danych

Do zbudowania profilu oraz jego testowania wykorzystuje si ˛e równie ˙z dane pochodz ˛ace z logów wyszukiwarki. [4, 14, 38] U ˙zytkownicy rozpozna-wani s ˛a po adresie IP. Nie jest to jednak zbyt dokładny wyró ˙znik gdy ˙z do´s´c cz ˛esto zdarza si ˛e, ˙ze z jednego komputera korzysta kilka osób. Sam pro-ces budowania profilu na ich podstawie jest całkiem efektywny. Problem sprawia jednak jego dokładna ocena. Logi zawieraj ˛a jedynie informacje o tym, które ze stron zostały odwiedzone przez u ˙zytkownika. Nie mo ˙zemy jed-nak wnioskowa´c o tym, czy witryny których nie obejrzał z tego powodu, ˙ze

3.6. Profil u˙zytkownika 34