• Nie Znaleziono Wyników

Efektywne wyszukiwanie podobieństw w tekstach źródłowych

Marek Piotr Stolarski

¡Consulting M arek Piotr Stolarski iconsulting@ iconsulting.pl

Rafał Orlik

iConsulting M arek Piotr Stolarski iconsulting@ iconsulting.pl Instytut Fizyki, Politechnika Wrocławska

Mateusz Kocielski

iConsulting M arek Piotr Stolarski iconsulting@ iconsulting.pl

Streszczenie

Znajdowanie podobieństw w tekstach źródłowych ja k o narzędzie kontroli własności intelektualnej. M etodyka tworzenia efektywnego, zarówno p o d względem prędkości j a k i dokładności, systemy wykrywania podobieństw. Typowe metody oszukiwania systemu i sposoby ich unikania. Normalizacja tekstu źródłowego taka ja k konwersja z *.pdf *.html, *.odt, *.doc do *. txt; wykorzystanie słowników synonim ów itp. Różne ję zy k i w jednym dokumencie.

Sposoby radzenia sobie z nowymi słowami, które nie występują w słowniku.

1. W prow adzenie

W dzisiejszym świecie informacja jest janw ażniejszą rzeczą. Kto kontroluje informację ten kontroluje innych. To sprawia, że jest ona bardzo podatna, na przykład może być ukradziona z czyjejś strony WWW. W tym rozdziale przedstawimy nasz system wykrywania podobieństw w tekstach źródłowych.

System ten, który początkowo był tworzony pod kątem wykorzystania go w

114 M. P. Stolarski, R. Orlik, M. Kocielski jednostkach akademickich, po małych zmianach może być użyty na przykład

przez agencje prasowe, portale W W W itp. W następnym rozdziale przedstawimy metodologię tworzenia takiego systemu oraz typowe problemy, które muszą być rozwiązane aby był on odporny na atak. Cały system używa programów Open Source takich jak Python (aplikacje po stronie serwera), PostgreSQL (baza danych do przechowywania tekstów), Apache (strona użytkownika).

2. M etodologia tw orzenia efek tyw n ego algorytm u zn ajd ow an ia p od ob ień stw

Najprostszą drogą znajdowania podobieństw jest użycie akgorytmów wyszukiwana łańcuchów, na przykład algorytm naiwny, Rabina-Karpa, Knutha- M orrisa-Pratta. Takie podejście pracuje dobrze dla identycznych tekstów.

Metoda ta, aczkolwiem poprawna, będzie bardzo wolna i łatwa do obejścia.

Można ją przyspieszyć poprzez podzielenie tesktu źródłowego na mniejsze fragmenty, np. długości 10 wyrazów, i wyznaczenie dla każdego z nich funkcji skrótu, np. MD5. Wtedy, poprzez proste odpytywania bazy danych o te teksty, które zawierają identyczną sygnaturę, można otrzymać te dokumenty, które składają się z takich samych fragmentów tekstów.

Z powodu bardzo małego prawdopodobieństwa tego, że różne fragmenty tesktu dadzą w wyniku tą samą sygnaturę MD5, można przyjąć, że taki algorytm wykrywa podobieństwa pomiędzy tekstem źródłowym a innymi tekstami.

Podejście wymienione wcześniej można mardzo łatwo oszukać, gdy osoba kradnąca fragment cudzego testu źródłowego, zmieniająca go nieznacznie, np.

poprzez zmianę konstrukcji zdania. Ostatecznie więc, taki algorytm systemu wykrywania podobieństw nie będzie działał dla dostatecznie mądrego złodzieja.

Tak więc, musimy stworzyć inną metodę, która będzie porównywalnie szybka jak metoda bazująca na sygnaturach MD5, ale w przeciwieństwie do niej nie

będzie tak łatwa do oszukania.

3. J a k znorm alizow ać tek st źród łow y?

Z powodu wielu możliwych do wykorzystania typów dokumentów tekstowych, takich jak *.pdf, *.ps, *.odt, *.doc, *.txt oraz inne, doskonały system wykrywania podobieństw musi dokonać procesu normalizacji. Najprostszą drogą jest konwersja dokumentu do formatu tekstowego. Biorąc pod uwagę istnienie alfabetów, w których występują specyficzne znaki narodowe (znaki diakrytyczne), trzeba dokonać wyboru pomiędzy np. kodowaniem ISO-8859-1 lub UTF-8/UTF-16. Użycie kodowanie Unicode wydaje się być najlepszym rozwiązaniem, ponieważ każdy znak diakrytyczny ma w nim swoją reprezentację. Niestety, takie podejście nie jest najlepsze. W rzeczywistości

Efektywne wyszukiwanie podobieństw w tekstach źródłowych 115 użycie Unicode sprawia, że analiza staje się trudniejsza, ponieważ niektóre znaki mogą być zakodowane w kilka równoważnych sposobów. To sprawia, że użycie kodowania Unicode staje się złym wyborem z praktycznego punktu widzenia.

Należy także wziąć pod uwagę inne zagadnienie. M ianowicie, przypuśćmy, że dokument źródłowy został poddany procesowi OCR (Optical Character Recognition). Podczas niego część znaków mogła być błędnie rozpoznana, np.

polska litera „a” mogła być zamieniona na „a” . Dla człowieka taki błąd jest oczywiście łatwy do wykrycia i usnięcia, ale w przypadku komputerów staje się niebanalnym problemem. Tak więc, musimy sibie poradzić z niezwykle istotnym zagadnieniem: jak uniknąć takich sytuacji? W naszym systemie zdecydowaliśmy się traktować wszystkie znaki diakrytyczne na równi z ich łacińskimi odpowiednikami. Mianowicie, wszystkie wym ienione znaki „z”, „ż”,

„ź” są konwertowana do „z”. Co więcej, podczas procesu normalizacji wszystkie znaki są zamieniana na ich odpowiedniki pisane małą literą.

W tym momencie widać wyraźnie, że wybór kodowania padł na ISO-8859-1.

Oczywiście, w dokumencie źródłowym występują także znaki istotne w tekście pisanym, ale, gdy mówiony, są trudne do rozróżnienia. Także więc znaki takie jak (przecinek), (kropka), (średnik) należy traktować w sposób odmienny. My zdecydowaliśmy się na ich usunięcie z tekstu źródłowego.

Ostatecznie więc tekst “Litwo! Ojczyzno moja! ty jesteś jak zdrowie. Ile cię trzeba cenić, ten tylko się dowie, Kto cię stracił. Dziś piękność twą w całej ozdobie Widzę i opisuję, bo tęsknię po tobie” będzie znormalizowany do postaci

“litwo ojczyzno m oja ty jestes ja k zdrowie ile cie trzeba cenie ten tylko sie dowie kto cie stracił dzis piękność twa w całej ozdobie widzę i opoisuje bo tesknie po tobie”.

Taka metoda będzie wystarczająca dla prostego systemu wykrywania podobieństw. Jednak ja k radzić sobie z innymi metodami jego unikania? To zagadnienie będzie przedstawione w kolejnym rozdziale.

4. Typow e m etod y un ikan ia w yk rycia pod ob ień stw i sposoby radzen ia sobie z nim i

W poprzednim rodziale przedstawiliśm y proces normalizacji dokumentu źródłowego. Co się jednak stanie, gdy ktoś zmieni nieznacznie test oryginalny?

Mianowicie, w dokumencie źródłowym zamieni zdanie „Tomek poszedł to szkoły” na „On poszedł do szkoły” . Tak długo jak „Tom ek” i „On” znaczą dokładnie to samo, oba zdania mają to samo znaczenie. Inny przykład takiego celowego działania: zamiast przepisać „Tomek poszedł do szkoły. Pogoda była mglista” ktoś napisał „Pogoda była mglista, gdy Tomek szedł do szkoły”. Trzeci możliwy przypadek to użycie synonimów: „M ieszkanie było puste” zamiast

„Mieszkanie było do wynajęcia” . Oba zdania znaczą dokładnie to samo, jednak

116 M. P. Stolarski, R. Orlik, M. Kocielski do wyrażenia tej myśli zostały użyte inne wyrazy. Poraź kolejny prosty system wykrywania podobieństw przestanie działać poprawnie.

W szystkie wymienione powyżej przykłady pokazują, że projektowanie mądrego systemu wykrywania podobieństw nie jest zagadnieniem trywialnym. Aby uniknąć wspomnianych problemów można użyć następujących technik:

zamienić wszystkie słowa na ich rdzenie („robię” na „robić”), sprawdzać czy w tekście źródłowym występują synonimy, a jeżeli tak, to zamienić je na jednego wybranego reprezentanta z każdej z grup synonimów.

Te wszystkie metody użyte razem sprawiają, że jeżeli ktoś chcący oszukać taki system wykrywania podobieństw będzie zmuszony do tak znaczących zmian w tekście źródłowym, że trudno ju ż będzie mówić o kradzieży.

5. Słow n ik i słow a, które w nim nie w ystęp u ją

W tym momencie nasz system wykrywania podobieństw wydaje się działać niemalże bezbłędnie. Jako dane wejściowe otrzymuje dokument źródłowy, który następnie jest konwertowany do postaci tekstowej. Przy użyciu technik sprawiających, że oszukanie systemu staje się trudniejsze, słowa tekstu źródłowego zostają zamienione na odpowiadające im rdzenie. Ponieważ komputery pracują korzystając wyłącznie z liczb, rdzenie są zamieniane na np.

liczby całkowite.

Pozostaje jednak otwarte pytanie: co zrobić ze słowami, których nie znamy, ponieważ nie występują w wykorzystywanym przez nas słowniku rdzeń —>

możliwe odmiany? Jednym z możliwych rozwiązań jest obliczenie nowego numeru idetyfikacyjnego dla słowa. Należy przy tym pamiętać, że słowo to może być jedną z odmian rdzenia. Zazwyczaj rdzeń ten może być w łatwy sposób wyznaczony, gdyż w ogólnym przypadku każde słowo ma formę prefix- core-suffix, gdzie prefix to (najczęściej) „nie-”, „naj-”, itp. Tak więc poprzez usunięcie typowych przedrostków otrzymamy formę core-suffix naszego nowego słowa. Co więcej, tylko kilka pierwszych liter należeć będzie to rdzenia.

W tym momencie mamy praktycznie rozwiązany nasz problem: wyznacznie identyfikatora dla nowego słowa. M ianowicie, przypiszmy każdej literze alfabetu pewną liczbę. Wtedy, poprzez sumowanie ich z ustalonymi wagami (zależnymi od odległości od początku słowa: duże wartości wag dla początkowych liter; coraz mniejsze, dążące do zera dla pozostałych) wyznaczymy poszukiwaną wartość.

Z algorytmem przedstawionym powyżej nadal są związane pewne otwarte pytania, takie jak np. postać funkcji wagowej, wartości liczbowe odpowiadające każdej z liter. Z drugiej jednak strony jest to dobry punkt wyjścia. Co więcej, dla każdego ze słów, które mają ten sam rdzeń, metoda ta powinna dać tą samą (albo bliskie siebie) wartości. Ostatecznie więc, wszystkie słowa, występujące w

Efektywne wyszukiwanie podobieństw w tekstach źródłowych 117 dokumencie źródłowym, są zamienione na ich reprezentację liczbową i w takiej formie są ostatecznie zapisywane w bazie danych.

6. Dw a i w ięcej języ k ó w w tek ście źród łow ym

System wykrywania podobieństw, który został opisany w poprzednim rozdziale, działa bezproblemowo w przypadku dokumentu napisanego w jednym języku.

Co stanie się jednak, gdy drugi i więcej języków pojawi się w rozpatrywanym tekście? Zazwyczaj język obcy oznacza cytowanie tekstu zagranicznego. Wtedy więc zasadniczy język dokumentu może być stosunkowo łatwo określony poprzez zliczenie jaka część tekstu należy do danego języka. Aby dodatkowo usprawnić ten proces moża wymagać od użytkownika systemu wstępnego określenia używanych w dokumencie języków . Najprostsza metoda jest postaci:

jak długo dane słow może być zidentyfikowane jako należące do konkretnego języka, tak długo do jego reprezentacji liczbowej można dodać stałą wartość (różną dla każdego z języków ). Jeżeli tak otrzymane liczby dla różnych języków nie przeplatają się, to system wykrywania podobieństw będzie działał bez istotniejszych zmian.

7. System w yk ryw an ia p od ob ień stw

Proces normalizacji został zakończony. Tekst źródłowy został przetransformowany ze swojej oryginalnej postaci, np. pliku *.pdf, do reprezentacji liczbowej. Podczas tych czynności pewne dodatkowe techniki były użyte, takie jak wykrywanie synonimów, zastępowanie słów poprzez odpowiadające im rdzenie. Można więc rozpocząć sprawdzanie czy występują podobieństwa pomiędzy tekstem źródłowym a tekstami zachowanymi w bazie danych. Powstaje jednak pytanie: jak wykrywać owe podobieństwa? W rozpatrywanym systemie użyliśmy bardzo prostego, ale skutecznego, algorytmu.

Mianowicie, niech tekst znormalizowany zostanie podzielony na ramki, każda o długości N słów. Następnie, dla każdej ramki S odpytujemy bazę danych czy istnieją inne ramki S| (należące do innych dokumentów), takie że moc koniunkcji zbiorów (S fi Si) jest większa niż M<N. Można przypuszczać, że dwie ramki (S z dokumentu źródłowego oraz S; z innego dokumentu) mają wspólne M/N słów. Stąd, współczynnik podobieństwa r pomiędzy nimi może być zdefiniowany jak o r=M/N. Oczywiście, nasz system może jedynie stwierdzić czy istnieje niezerowe praw dopodobieństwa takiego zdarzenia: dla całkowicie różnych ramek r=0, dla dokładnie takich samych r=T. Informacja ta jest zachowywana następnie w bazie danych. Przedstawiony algorytm wyszukiwana podobieństw jest najbardziej wrażliwą częścią systemu. Jego administrator musi niezwykle starannie dobrać wartości współczynników N oraz M. Liczby te nie mogą być zbyt małe (algorytm „widzi” jedynie część zdania), ani zbyt duże (zbyt dużo następujących po sobie zdań brane jest pod uwagę).

118 M. P. Stolarski, R. Orlik, M. Kocielski Dość zgrubne oszasowanie wartość parametru N jest takie, że powinno ono odzwieciedlać średnią długość jednego-dwóch zdań. W przypadku parametru M można przyjąć, że M wynosi ok. 75-80% wartości N. Etap odpytywania bazy danych jest najwolniejszą częścią systemu. Dane doświadczalne pokazuję, że o ile proces normalizacji tekstu źródłowego zajmuje czas rzędu minut, to już wyszukiwanie w bazie danych może wymagać czasu rzędu godzin i więcej, w zależności od rozmiaru bazy danych i uwarunkowań sprzętowych komputera.

8. P odsum ow an ie

Przedstawiliśmy krok po kroku metodę projektowania systemu do wykrywania podobieństw w tekstach źródłowych: począwszy od momentu otrzymania dokumenu, poprzez proces jego normalizacji, skończywszy na przechowywaniu go w bazie danych. Zaprezentowaliśmy typowe sposoby oszukiwania systemu wykrywania podobieństw (zamiana kolejności zdań, wykorzystywanie synonimów) oraz metody im przeciwdziałania. Pokazaliśmy także jak radzić sobie z problemem słów niewystępujących w słowniku.

LITERATURA

Rozdział pow stał wyłącznie w oparciu o własne opracowania Autorów.

Część 2.