autorstwa Malviny Matlis i Marcosa Calvo Lance'a

Systemy wyszukiwania informacji (IR) są wszechobecne w naszym codziennym życiu. Może to załatwianie zakładów poprzez wyszukiwanie odpowiedzi online, znajdowanie ulubionych produktów na Amazon, znajdowanie dowolnego e-maila w Outlooku, a może po prostu jesteś głodny i chcesz ugotować pyszną autentyczną paellę. Nasze życie prawdopodobnie nie byłoby tak łatwe (i mniej zabawne) bez tych wszystkich pól wyszukiwania, które pozwalają nam znaleźć wszelkiego rodzaju dokumenty i informacje, czy to pisemne, audio, zdjęcia, filmy, czy coś innego. Aby jednak użytkownik uznał system IR za użyteczny, system musi udzielić odpowiedniej odpowiedzi w odpowiednim czasie. Jak więc upewnić się, że wyszukiwarka dostarcza użytkownikom odpowiednie treści zgodnie z ich zapytaniami, gdy mamy scenariusz „zimnego startu”, tj. brak historii zapytań? A jak oceniamy wydajność na żywo systemu IR, gdy jest on już w produkcji?

W tym poście na blogu zademonstrujemy, w jaki sposób zdecydowaliśmy się ocenić taki system za pomocą monitorowania online i analizy dzienników za pomocą Kusto , narzędzia do wysyłania zapytań firmy Microsoft, ale koncepcje te można również zastosować do innych języków i stosów technologii.

Ocena systemów IR

Ocena systemów IR została obszernie zbadana i udokumentowana, co oznacza, że ​​zdefiniowano kilka standardowych metryk, dobry przegląd można znaleźć na stronie Evaluation Metrics for Information Retrieval .
Na przykład niektóre z tych standardowych metryk to:

Precyzja
Określa ilościowo odsetek wyników zwróconych przez system, które są istotne dla zapytania (tj. wyszukiwanego hasła). Na przykład na powyższym obrazku szukaliśmy przepisu na autentyczną paellę. Wyszukiwarka wyszukała 330 milionów dokumentów. Gdybyśmy mieli referencję, która mówiłaby, że 200 milionów takich dokumentów jest istotnych dla wyszukiwania receptury, to precyzja zapytania wyniosłaby 200/330 = 60,6%.

Recall
Mierzy odsetek odpowiednich wyników, które są zwracane przez system ze zbioru wszystkich odpowiednich wyników. Wracając do naszego przykładu, co by się stało, gdyby wyszukiwarka pominęła 20 milionów odpowiednich dokumentów? Wtedy wycofanie wyniesie 200/(200+20) = 90,9%

Ranking wzajemny (RR)
Mierzy, gdzie na liście zwróconych wyników znajduje się pierwszy odpowiedni dokument. Ponieważ wygodnie jest mieć metryki o wartościach z zakresu od 0 do 1, gdzie 1 oznacza lepszy wynik niż 0, odwrotny ranking jest definiowany jako 1 nad najwyższym indeksem dokumentu, który jest istotny dla zapytania. Aby zmierzyć to w zbiorze zapytań, po prostu uśredniamy wzajemny ranking w zestawie zapytań, uzyskując w ten sposób średni odwrotny ranking (MRR) lub w postaci równania:

Ponieważ wciąż jesteśmy głodni i nie zamierzamy przekraczać 330 milionów przepisów, RR przyjrzy się pierwszemu dokumentowi, który oznaczyliśmy jako istotny. Powiedzmy, że był to piąty przepis, wtedy RR dla zapytania wyniesie 1/5.

Łatwiej powiedzieć niż zrobić

Podobnie jak w przypadku większości problemów związanych z uczeniem maszynowym, metryki oceny są zwykle obliczane na podstawie wstępnie zdefiniowanego, opatrzonego adnotacjami i wyselekcjonowanego zestawu danych oceny, który, miejmy nadzieję, jest wystarczająco reprezentatywny dla zachowania systemu w środowisku naturalnym . Co jednak, jeśli nie ma dostępnego zestawu danych, który byłby wystarczająco reprezentatywny dla potrzeb użytkowników? A co jeśli te potrzeby są nieznane?

Metryki online — zbierzmy opinie
Alternatywą dla korzystania z predefiniowanego zestawu danych ewaluacyjnych do oceny jakości systemu jest wykorzystanie informacji o wykorzystaniu systemu. Zbierając informacje o podróży użytkownika w systemie IR, jesteśmy w stanie ocenić i monitorować zwracane wyniki. Dla przykładu rozważmy następujący przepływ użytkownika w aplikacji:

1. Zapytanie wejściowe: Użytkownik wprowadza zapytanie (w naszym przykładzie „autentyczny przepis na paellę”) do aplikacji, które jest przekazywane do wyszukiwarki.
2. Przeglądanie dokumentów: System zwraca listę dokumentów, a aplikacja wyświetla je posortowane według ważności.
3. Inspekcja dokumentów: Użytkownik przegląda kolejno zwrócone dokumenty i wybiera jeden do dalszej kontroli.
4. Sukces: jeśli użytkownik jest zadowolony ze sprawdzanego dokumentu, może poinformować aplikację o zakończeniu wyszukiwania. Jedną z możliwości jest ocena wyniku pozytywnie. Innym jest użycie metod zastępczych w celu wywnioskowania, że ​​wyszukiwanie zakończyło się powodzeniem, na przykład mierzenie czasu, jaki użytkownik spędził na przeglądaniu dokumentu.
5. Jeśli użytkownik nie jest zadowolony ze sprawdzanego dokumentu, wraca do przeglądania wyników (punkt 4) i może wybrać nowy dokument do wglądu.

Kusto na ratunek

Mechanizmy obserwowalności, takie jak rejestrowanie, generują ogromną ilość danych, co stanowi dodatkowe wyzwanie związane z ich przeszukiwaniem.

Dzienniki można sprawdzać w portalu Azure AppInsights przy użyciu usługi Azure Eksplorator danych , a w szczególności języka zapytań Kusto . Jeśli znasz SQL, rozpoznasz kilka wspólnych punktów w tym języku. Istnieje jednak znacząca różnica między Kusto i SQL — w Kusto instrukcje są wykonywane w kolejności, dzięki czemu zapytania są krótsze i bardziej czytelne niż zapytania SQL.

Metryki oceny przy użyciu rejestrowania zdarzeń użytkownika

Tradycyjnie rejestrowanie było szeroko stosowane do celów monitorowania i inżynierii. Kilka przykładów to wiedza o tym, ile zapytań w jednostce czasu system musi obsłużyć, ilu użytkowników wysyła zapytania do systemu lub ile czasu użytkownik spędza średnio na sprawdzaniu dokumentu. Jednak badacze danych mogą również skorzystać z odpowiedniego rejestrowania w celu obliczenia kluczowych wskaźników wydajności (KPI) i oceny wydajności systemu online w sposób ciągły.

Średni stopień odwrotności (MRR)

Z wyżej wymienionych metryk oceny IR, Reciprocal Ranking (RR) wymaga tylko rangi pierwszego istotnego wyniku na liście ponownie dostrojonych dokumentów, którą możemy zdefiniować poprzez interakcję użytkownika końcowego. W związku z tym można go obliczyć na podstawie rzeczywistego ruchu po wprowadzeniu odpowiedniego rejestrowania. W naszym przykładzie wyzwolenie zdarzenia OnSuccess oznacza, że ​​użytkownik uznał wynik za istotny. Z perspektywy user experience, RR dla danego zapytania informuje nas, jak szybko użytkownik mógł znaleźć pierwszy dokument, który odpowiada jego potrzebom.

MRR można następnie obliczyć, uśredniając RR w znaczącym okresie, na przykład jednego dnia, w statystycznie istotnej populacji użytkowników, tak aby różne zapytania i profile użytkowników były agregowane i reprezentowane w metryce. W ten sposób możemy porównać, że na przykład użytkownicy z Hiszpanii znajdują pierwszy odpowiedni przepis średnio w 15. dokumencie, a użytkownicy z Izraela średnio w 3. dokumencie.

Poniższe zapytanie Kusto oblicza dokładnie to.

Szybka ściągawka Kusto do SQL (i pamiętaj, Kusto wykonuje w kolejności):

• [Kusto] -> [SQL]
• gdzie -> gdzie
• projekt -> wybierz
• podsumuj -> wybierz z dowolną funkcją agregującą, taką jak suma, średnia lub min, wraz z grupowaniem według kolumn
• make-series -> funkcja niedostępna w SQL, która zamienia zestaw danych w wykres szeregów czasowych
• render -> inna funkcja niedostępna w SQL, która wykreśla dane

Mając zapytanie „autentyczny przepis na paellę” i 10 dokumentów, które zwróciła wyszukiwarka, porządkujemy dokumenty tak, aby dokument najbardziej podobny do zapytania znalazł się na pozycji 1, a najmniej podobny na pozycji 10. Dla przykładu , załóżmy, że dokumenty 3, 6 i 8 zostały uznane przez naszych użytkowników za istotne.

arg_max (ExprToMaximize, * | ExprToReturn [, ...])

Metryki lejka

Metryka Reciprocal Ranking daje nam ograniczony wgląd w interakcję użytkownika z systemem, ponieważ uwzględnia tylko pierwszy istotny dokument. Na przykład możemy uzupełnić tę metrykę, obliczając, ile dokumentów średnio użytkownik musi sprawdzić, aby znaleźć wszystkie dokumenty, których może potrzebować. W idealnym scenariuszu chcielibyśmy, aby użytkownik otwierał tylko te dokumenty, które są rzeczywiście istotne, ponieważ zaoszczędzilibyśmy użytkownikom dużo czasu na przeglądaniu nieistotnych dokumentów.

Korzystając z rejestrowania wprowadzonego w tym systemie, możemy przeformułować to pytanie jako metrykę: z tych interakcji, które spowodowały zdarzenie onNavigate , jaka jest proporcja, która również wywołała zdarzenie onSuccess ? Lub, mówiąc prościej, z jakim procentem dokumentów, które czytał użytkownik, korzystał z niego w interakcji? Możemy to napisać za pomocą Kusto w następujący sposób:

Możesz zapoznać się z pełną ściągawką Kusto to SQL na potrzeby interpretacji zapytań.

Wszystko razem — deska rozdzielcza

Aby śledzić te i inne wskaźniki, wygodnie jest zbudować pulpit nawigacyjny. W naszym przykładzie monitorujemy metryki za pomocą funkcji pulpitu nawigacyjnego AppInsights. Śledzimy metryki monitorowania, a także metryki wydajności IR w jednym widoku, ponieważ wszystkie informacje można łatwo uzyskać z dzienników systemowych. Cały kod jest zawarty w następującym repozytorium Azure-Samples

Ten pulpit nawigacyjny pozwala nam jednocześnie śledzić wskaźniki systemu i wydajności. Jednak niekoniecznie pozwala nam to zdiagnozować, dlaczego wydajność naszych wskaźników spada. Na przykład, jeśli „Dzienne RR” maleje z czasem, czy dzieje się tak dlatego, że:

• Zmieniły się potrzeby użytkowników?
• Nowe dokumenty zostały zindeksowane, a nowa treść nie pasuje do starej?
• Nasza biblioteka dokumentów jest przestarzała i wymaga aktualizacji o nowe dokumenty?
• Zmieniła się definicja sukcesu użytkownika?
• Zmiany UX wpływają na sposób interakcji użytkowników z wynikami? Na przykład widżet tematu pojawia się na stronie wyników i wyświetla informacje, eliminując potrzebę interakcji z określonym dokumentem.
• Sezonowość?
• Inny?

Wniosek

Byliśmy zmotywowani do napisania tego artykułu, ponieważ napotkaliśmy scenariusz, w którym wcześniej istniejące dane oceny z adnotacjami dla wyszukiwarki nie były dostępne. Odkryliśmy, że śledzenie interakcji użytkowników z systemem w czasie dostarcza wskazówek, gdzie potrzebne są dodatkowe dostosowania. Wzajemny ranking wizualizuje, jak daleko użytkownik musi przewinąć, aby znaleźć pierwszy odpowiedni dokument, podczas gdy stosunek między odpowiednimi a otwartymi dokumentami rzuca światło na ogólną wydajność wyszukiwarki i trafność zwróconych dokumentów.

Zaprojektowanie odpowiedniego logowania i analizy aplikacji umożliwia śledzenie jakości systemu w czasie rzeczywistym od momentu uruchomienia systemu w produkcji. Jest to przydatne nie tylko w przypadkach, gdy zasoby ewaluacyjne nie są dostępne, ale także pozwala nam wykryć różnice w jakości systemu w czasie, a tym samym poprawić wrażenia użytkownika. A teraz zrobimy paellę.