Większość porażek wyszukiwania to porażki definicji

Użytkownik pyta o klienta. System zwraca cztery dokumenty. Dwa dotyczą innego podmiotu o podobnej nazwie, jeden właściwej firmy, ale zamkniętej umowy, a jeden jest poprawny. Zespół spędza kolejne dwa tygodnie na strojeniu wielkości fragmentów i rerankerów.

Retriever nie jest problemem. Problemem jest to, że słowo klient znaczy w tej organizacji cztery różne rzeczy, a nic w systemie nie wie, którą miano na myśli.

Jak porażka definicji wygląda z zewnątrz

Technicznie powiązane, praktycznie błędne. Wszystko, co zwrócono, faktycznie wspomina to pojęcie. Nic nie odpowiada na pytanie, bo trafność policzono na słowach, a nie na encjach.

Poprawne odpowiedzi o niewłaściwym podmiocie. Właściwy dokument, niewłaściwa lokalizacja. Właściwa faktura, niewłaściwa spółka zależna. Pewne siebie, spójne i bezużyteczne.

Odpowiedzi zmieniające się wraz ze sformułowaniem. Zapytanie o to samo na dwa sposoby daje różne wyniki, bo pod spodem nie ma rozstrzygniętej encji — tylko podobieństwo tekstu.

Agregaty, które się nie spinają. Dwa działy liczą to samo i wychodzą im inne sumy. Uzgodnienie istnieje w głowie analityka i nie da się go przekazać maszynie.

Dlaczego strojenie tego nie naprawia

Jakość wyszukiwania ma sufit wyznaczony przez to, jak dobrze rozpoznane są rzeczy pod spodem. Lepsze osadzenia i sprytniejsze rerankery zbliżają Was do tego sufitu; nie podnoszą go.

Jeśli korpus zawiera trzy firmy o nazwie Nordwind i nic nie zapisuje, że dwie z nich są spółkami zależnymi trzeciej, żadna funkcja rankująca nie rozstrzygnie, którą użytkownik miał na myśli. Potrzebnej informacji nie ma w tekście.

Tania wersja naprawy

Pełny program ontologiczny nie jest pierwszym krokiem, a kompletne ontologie przedsiębiorstwa to dobrze udokumentowany sposób na spędzenie dwóch lat. Użyteczne minimum jest wąskie.

Rozstrzygnijcie encje, które mają znaczenie. Zwykle klientów, lokalizacje, produkty i umowy. Jedna tożsamość na jedną realną rzecz, z zapisanymi aliasami zamiast zdeduplikowanymi na śmierć.

Spiszcie relacje. Spółka matka i zależna, lokalizacja i organizacja, umowa i jej wersja. Trzy albo cztery typy relacji pokrywają większość porażek.

Przypnijcie dokumenty do encji. Nie tylko do folderów. Gdy dokument jest powiązany z rozstrzygniętym klientem, wyszukiwanie może odfiltrować przed rankowaniem — a stamtąd bierze się poprawa.

Rozstrzygnijcie sporne definicje. Tam, gdzie dwa działy się nie zgadzają, zapiszcie obie, nazwijcie je odrębnie i zmapujcie między nimi. Średnia, z której nikt nie korzysta, jest gorsza niż dwie definicje, które wszyscy rozumieją.

Wynik zwykle widać od razu

Filtrowanie do rozstrzygniętej encji przed rankowaniem usuwa w jednym kroku większość porażek typu niewłaściwy podmiot. To mniejsza zmiana niż przebudowa stosu wyszukiwania i dotyka rzeczywistej przyczyny, zamiast ją kompensować.

Test wart zrobienia najpierw: weźcie dwadzieścia ostatnich złych odpowiedzi i sklasyfikujcie je. Niewłaściwy podmiot czy właściwy podmiot i słaby fragment? W większości systemów, które oglądaliśmy, pierwszy stos jest znacznie większy — i to jego żadne strojenie retrievera nie zmniejszy.

Od tego zaczyna się projektowanie i inżynieria ontologii: wąsko, powiązane z jednym albo dwoma realnymi przypadkami użycia i skierowane na coś, co skonsumuje to w ciągu tygodni — bo model, którego nic nie używa, jest dokumentem, który się psuje.