Embeddingi AI: podobne znaczenie nie zastąpi numeru części

Wyszukiwarka znalazła produkt bardzo podobny do potrzebnego. Nazwa się zgadza, opis brzmi znajomo, fotografia też wygląda przekonująco. Tylko oznaczenie kończy się na 12 zamiast 21. Dla rozmowy o stylu wyposażenia to może być drobiazg. Dla zamówienia konkretnego wariantu jest to inny produkt. Podobieństwo nie ma uprawnienia do przestawiania cyfr.

Embedding to liczbowa reprezentacja informacji, wykorzystywana między innymi do wyszukiwania według znaczenia. Pomaga odnajdywać treści opisane innymi słowami niż pytanie. Kłopot zaczyna się wtedy, gdy wynik takiego porównania zostaje potraktowany jako potwierdzenie zgodności wszystkich warunków. Kandydat do sprawdzenia i zatwierdzone dopasowanie powinny mieć osobne miejsca w procesie.

Najpierw ustal, co musi zgadzać się dokładnie

Wyobraźmy sobie fikcyjny katalog przegród do organizerów biurkowych. Klient posługuje się kodem PB-120-G, a pracownik szuka właściwej karty. W katalogu znajdują się również PB-120-B i PB-210-G. Nie ustalamy tu parametrów wyrobu technicznego ani jego dopuszczalnego zastosowania. To prosty przykład pokazujący różnicę między nazwą kategorii, identyfikatorem i cechą wariantu.

Jeśli kod jednoznacznie identyfikuje pozycję, proces powinien sprawdzić go według uzgodnionej reguły. Nie musi zgadywać znaczenia ostatniej litery na podstawie opisów. Odbiorca pytający o konkretną pozycję powinien dostać tę kartę albo informację, że nie udało się jej odnaleźć. Najbliższy opis może być użyteczny później, jako osobno oznaczona propozycja.

Zapisz, które pola są warunkami wyboru. Może chodzić o kod, jednostkę, datę obowiązywania albo wersję dokumentu. Inne elementy mogą służyć znalezieniu podobnego zastosowania. To zadanie dla osoby znającej katalog i sposób obsługi zamówień. Sama obecność liczb w tekście nie wyjaśnia, czy są identyfikatorem, wymiarem, ceną czy numerem strony.

Przygotuj także regułę obsługi błędnego zapisu. Spacja, łącznik lub wielkość liter mogą być obojętne, jeśli właściciel danych tak to określi. Usunięcie zera na początku bywa już zmianą identyfikatora. Nie stosuj jednej wygodnej normalizacji do wszystkich pól bez sprawdzenia jej skutku. Sprzątanie tekstu potrafi wynieść z katalogu właśnie tę informację, której szukaliśmy.

W architekturze wiedzy w firmie warto odróżnić nazwy używane przez ludzi od stabilnych identyfikatorów zasobów. Klient może mówić o „szarej przegrodzie do szerokiego organizera”. System musi wiedzieć, czy ten opis wskazuje jeden wariant, kilka kandydatów czy żadną aktualną pozycję. Inaczej interfejs będzie sprawiał wrażenie bardziej zdecydowanego niż dane.

Wektor pomaga szukać, lecz nie odczytuje intencji firmy

Dokumentacja embeddingów Cohere opisuje reprezentowanie informacji jako list liczb i porównywanie ich podobieństwa. Dla wyszukiwania semantycznego rozróżnia też typ wejścia zapytania i przeszukiwanego dokumentu. Konfiguracja takiego porównania należy do sprawdzanego rozwiązania; nie wystarczy wiedzieć, że w projekcie „używamy wektorów”.

Gdy odbiorca pyta o przegrodę oddzielającą notesy od drobiazgów, wyszukiwanie według znaczenia może pomóc dotrzeć do opisu, który używa innych nazw. Oceniaj wtedy, czy odnaleziony materiał odpowiada potrzebie. Nie żądaj wyłącznie zgodności wszystkich słów. W tym zadaniu właśnie różnica słownictwa może być powodem zastosowania metody.

Kiedy to samo pytanie zawiera kod PB-120-G, potrzebujesz zachować również ten warunek. Podobny opis PB-210-G nie staje się właściwy tylko dlatego, że otrzymał wysoką pozycję. Własna próba powinna sprawdzić, co rozwiązanie robi z kodem, zamiast zakładać z góry powodzenie lub porażkę każdego modelu embeddingowego.

Miara podobieństwa sama nie jest procentem pewności, że pozycja spełnia wymagania zamówienia. Żeby tak interpretować wynik konkretnego rozwiązania, trzeba byłoby osobno wykazać i sprawdzić tę zależność na właściwej próbie. Znaczenie wyniku zależy od modelu, metody porównania i sposobu przygotowania materiału. Jeżeli aplikacja pokazuje liczbę użytkownikowi, wyjaśnij, co oznacza i czego nie potwierdza. Wysokość na liście nie jest podpisem osoby odpowiedzialnej za zgodność wariantu.

Sprawdź też przygotowanie tekstu dokumentu. Jeśli do porównania trafia wspólny opis całej rodziny, a identyfikatory wariantów są przechowywane osobno, wynik może prawidłowo wskazać rodzinę. Kolejny etap nadal musi wybrać wariant. Ocena powinna uwzględniać tę strukturę, zamiast karać pierwszy etap za zadanie, którego nigdy mu nie przekazano.

Trafiony fragment musi prowadzić do właściwej karty

Katalog bywa dzielony na krótsze fragmenty przed przeszukiwaniem. Zobacz, czy opis przegrody zachował powiązanie z jej kodem i tytułem. Jeśli fragment obejmuje końcówkę jednej karty oraz początek następnej, system może dostać tekst o właściwym zastosowaniu z identyfikatorem sąsiedniego wariantu. Wtedy problem dotyczy przygotowania materiału, zanim porównanie w ogóle się zacznie.

Przejdź od wyniku do oryginalnego źródła. W fikcyjnym katalogu kliknięcie powinno otwierać konkretną kartę lub czytelnie wskazany fragment. Jeżeli prowadzi do pierwszej strony obszernego pliku, pracownik nadal musi sam odnaleźć wariant. Oceniaj więc również odnośnik i sposób prezentacji podstawy. Sam trafny tekst wycinka nie zamyka zadania osoby przygotowującej odpowiedź dla klienta.

Dodaj próbę po zmianie katalogu. Wycofana karta może pozostać w indeksie, podczas gdy jej adres prowadzi już do innej pozycji. Sprawdź sposób aktualizacji i usuwania starych reprezentacji. Zespół potrzebuje rozpoznać wersję źródła użytego do dopasowania, aby odróżnić słabe porównanie od trafnego odnalezienia nieaktualnego materiału.

Jeżeli opis wspólny dla rodziny jest powielony przy każdym wariancie, lista może zawierać wiele podobnych kart z tej samej grupy. Ustal, czy odbiorca potrzebuje właśnie wariantów, czy odmiennych propozycji zastosowania. To inne zadania. Nie usuwaj podobnych wyników mechanicznie, jeżeli różnice między nimi są tym, co klient ma dopiero wybrać.

Liczba, jednostka i zaprzeczenie zmieniają warunek

Przygotuj fikcyjne opisy różniące się jednym elementem istotnym dla wyboru. Szerokość 120 i 210 to inny warunek, choć obie karty mówią o organizerze. Podobnie „z przegrodą” oraz „bez przegrody” nie opisują tego samego zestawu. Zobacz, czy system zachowuje różnicę podczas wyszukania i prezentacji wyniku. To hipoteza do sprawdzenia w twoim rozwiązaniu.

Jednostkę sprawdzaj razem z wartością. Samo odnalezienie liczby nie potwierdza, czy dotyczy sztuki, kompletu, opakowania czy wymiaru. W fikcyjnym katalogu zestaw dwóch przegród nie powinien automatycznie odpowiadać pytaniu o dwa zestawy. Podobne opisy wymagają wyjaśnienia tego, co klient rzeczywiście zamawia.

Dodaj przykład bez informacji wystarczającej do wyboru. Jeżeli wiadomość mówi tylko „potrzebuję takiej jak poprzednio”, a proces nie ma historii zamówienia, powinien rozpoznać brak. Szukanie najbliższej karty może przygotować pomocniczą listę, ale nie odtworzy nieobecnego zamówienia. Dopytanie o kod może być najkrótszą drogą do poprawnego wyniku.

W testach regresji odpowiedzi AI zachowaj te pary wraz z oczekiwanym znaczeniem. Sprawdź, czy aktualizacja modelu albo indeksu zmieniła wybór wariantu. Jeśli aplikacja nadal zwraca poprawny format i atrakcyjny opis, łatwo przeoczyć, że poprawność samej pozycji właśnie się pogorszyła.

Połącz metody, zachowując obowiązkowe warunki

Elastic opisuje wyszukiwanie hybrydowe jako połączenie wyszukiwania pełnotekstowego i wektorowego w jednym żądaniu oraz wspólnym rankingu. To sposób łączenia dopasowania słów z podobieństwem. Samo połączenie rankingów nie oznacza jednak obowiązkowego sprawdzenia identyfikatora według firmowej reguły. Taki warunek trzeba zaprojektować i przetestować oddzielnie.

Dla fikcyjnego katalogu można rozważyć osobną ścieżkę kodu oraz ścieżkę opisu potrzeby. Jeżeli podano rozpoznawalny kod, najpierw sprawdź konkretną pozycję. Jeżeli zapytanie opisuje zastosowanie, wyszukaj kandydatów, a następnie pokaż cechy wymagające wyboru. To przykład decyzji projektowej, nie uniwersalna konfiguracja każdej wyszukiwarki.

Ustal zachowanie przy konflikcie. Klient może podać kod jednej przegrody i wymiar drugiej. System nie powinien cicho wybrać informacji, którą akurat łatwiej dopasował. Potrzebujesz komunikatu wskazującego rozbieżność i pytania umożliwiającego jej rozwiązanie. W obsłudze zamówienia konflikt jest informacją o sprawie, a nie przeszkodą do ukrycia pod najlepszym wynikiem.

Zobacz również, czy filtr zachowuje ograniczenia całej ścieżki. Jeżeli wynik ma dotyczyć tylko aktualnych pozycji określonego katalogu, nie wystarczy sprawdzić tego przed jednym etapem i pominąć po połączeniu wyników. Przejdź przykład od wejścia aż do widocznej karty. Liczy się materiał, który użytkownik faktycznie otrzymał.

Przy RAG opartym na źródłach rozdziel odnalezienie dokumentu od odpowiedzi na jego podstawie. Możesz mieć dobrego kandydata i błędny opis, albo słabe wyszukanie i ostrożną odmowę. Bez tego podziału poprawki trafią do niewłaściwego miejsca: do instrukcji modelu zamiast indeksu lub odwrotnie.

Zmiana reprezentacji potrzebuje ponownego porównania

Zapisz, jakim modelem i sposobem przygotowania danych zbudowano indeks, czyli przeszukiwany zbiór reprezentacji. Zapytanie musi być porównywane w zgodnym mechanizmie. Przy aktualizacji sprawdź wymagania wybranego dostawcy oraz plan odtworzenia indeksu. Sama zmiana nazwy modelu w jednym miejscu nie potwierdza zgodności wszystkich zapisanych danych.

W próbie odbioru uwzględnij kod, którego katalog nie zawiera. System może zwrócić pusty wynik, zaproponować sprawdzenie zapisu albo pokazać oddzielnie oznaczone podobne pozycje. Oczekiwane zachowanie ustal z właścicielem procesu. Bez takiego przypadku narzędzie zwracające zawsze jakąś kartę może wyglądać dobrze na zbiorze złożonym wyłącznie z dostępnych produktów.

Obejrzyj pracę osoby korzystającej z wyniku. Czy rozpoznaje, że otrzymała propozycję, a nie potwierdzenie kodu? Czy widzi warunki, których system nie zdołał sprawdzić? Samo dodanie małego oznaczenia „podobne” może nie wystarczyć, jeśli przycisk obok od razu zatwierdza pozycję. Znaczenie wyboru powinno być jasne w chwili jego wykonania. Jeżeli wynik wybiera się w polu z podpowiedziami, rozdziel także wpisany tekst, sugestię i zatwierdzony rekord.

Zachowaj przypadek, w którym człowiek odrzucił pierwszą kartę i wybrał kolejną. Ustal, jaką informację wykorzystał. Być może opis wskazuje właściwą rodzinę, lecz brakujący filtr utrudnia wybranie wariantu. Takie obserwacje pomogą przygotować konkretną poprawkę, zamiast zmieniać próg podobieństwa po każdej skardze bez wiedzy o przyczynie.

Porównaj na tej samej próbie kod, swobodny opis i sprzeczne warunki. Zapisuj trafność kandydatów oraz ostatecznego wyboru osobno. Nie poprawiaj całej metody na podstawie jednego trudnego kodu, jeśli pogarsza to wyszukiwanie naturalnych pytań. Potrzebujesz zobaczyć, które zadanie zyskało, a które wymaga odrębnej reguły.

Jeżeli rozważasz dostrajanie modelu, najpierw sprawdź, czy problem powstaje już przy wyszukaniu karty. Gdy zaś wynik jest przechowywany, obejrzyj aktualność pamięci podręcznej odpowiedzi. Poprawny wybór z dawnego katalogu może przestać odpowiadać nowej sprawie mimo niezmienionego pytania.

Do rozmowy z Aeneia Audit przygotuj kilka kart, zapytanie i wynik, przy którym podobieństwo wygrało z wymaganiem. Sprawdzimy, jaka informacja powinna rozstrzygać wybór i gdzie przestała być kontrolowana. Jeśli właściwa karta nie trafia do kandydatów, przyjrzymy się metodzie szukania. Jeśli trafia, ale przegrywa z innym kodem, sprawdzimy regułę ostatecznego wyboru. Numer produktu ma rozstrzygać tam, gdzie firma właśnie jemu powierzyła tę rolę.