Użytkownik pyta o NIP i numer procedury. Wektor znajduje teksty o podatkach, a dokładny dokument jest niżej. Potem pyta „jak zakończyć współpracę bez dramatu”, a słowa kluczowe nie widzą umowy o wypowiedzeniu. Jedna metoda nie rozwiązuje obu pytań.
Wyszukiwanie tekstowe dopasowuje terminy, często po analizie językowej i normalizacji, zależnie od konfiguracji. Wektory szukają podobieństwa semantycznego. Hybryda łączy je, ale wymaga oceny rankingu, filtrów i źródeł. Nie jest automatycznie lepsza.
Zacznij od typów pytań
Wypisz rzeczywiste kody, nazwy, daty, pojęcia i parafrazy. Przy identyfikatorach dokładne dopasowanie jest często krytyczne. Przy opisach problemów semantyka pomaga znaleźć właściwy dokument.
Nie wybieraj metody na podstawie liczby dokumentów. Mała baza może zawierać trudne synonimy, duża wiele kodów. Pytania użytkowników decydują o potrzebie.
Zapisz oczekiwane źródło przy każdym pytaniu. Test wyszukiwania powinien oceniać, czy je znajduje, a nie tylko czy wynik wygląda podobnie.
Słowa kluczowe chronią dokładność
Przy kodach, numerach umów, SKU, NIP i właściwych nazwach zachowaj dokładne pola i formaty. Model nie powinien normalizować ich kreatywnie. Część wymaga osobnego indeksu lub reguły.
Przy polskiej odmianie przygotuj warianty i odpowiednią analizę. Proste obcinanie końcówek może łączyć różne pojęcia. Test powinien obejmować rzeczywiste formy.
Nie usuwaj diakrytyki z jedynego źródła. Możesz mieć wersję roboczą do wyszukiwania i oryginał do odbioru. Zasady opisuje przewodnik o polskich znakach AI.
Wektory pomagają przy parafrazach
Użytkownik nie zawsze używa terminu z dokumentu. „Nie mogę pobrać pliku” może dotyczyć eksportu, uprawnień lub formatu. Wektory pomagają znaleźć semantycznie podobne fragmenty.
Nie oznacza to, że najbliższy wynik jest poprawny. Dokument może mówić o podobnym temacie bez odpowiedzi. Oceń treść i źródło przed modelem.
Przy kodach i niejasnych skrótach wektor może zwracać niebezpiecznie podobne, ale błędne źródła. Dodaj dokładne filtry i reguły dla tych pól.
Hybryda łączy kandydatów
Uruchom obie metody i porównaj wspólny wynik. Możesz zwiększyć szansę znalezienia zarówno kodu, jak i opisu. Nie sumuj wyników bez oceny rankingu i duplikatów.
Zapisz, skąd pochodzi fragment: słowa kluczowe, wektor czy obie. To pomaga analizować błędy. Nie przedstawiaj jednej liczby rankingu jako prawdy o właściwości źródła.
Przy hybrydzie możesz ograniczyć zbiór kandydatów przed modelem. Więcej wyników nie zawsze poprawia odpowiedź; może dodawać sprzeczne wersje.
Uprawnienia i ranking wyników
Uwierzytelnij użytkownika i zastosuj reguły dostępu dla właściwego tenant, roli, wersji i statusu. Kolejność filtrowania i rankingu zależy od silnika. Wyniki niedostępne dla użytkownika nie mogą trafić do odpowiedzi ani kontekstu modelu. Sam identyfikator w filtrze nie uwierzytelnia osoby.
Przy kodach używaj pól strukturalnych zamiast zgadywania z treści. Dokument może zawierać wiele identyfikatorów. Filtr powinien być jednoznaczny i zatwierdzony.
Przy uprawnieniach stosuj zasady z przewodnika o RAG i dostępie przed wyszukiwaniem. Metoda wyszukiwania nie zmienia zakresu dostępu.
Test wyszukiwania osobno od generowania
Przygotuj pytania z oczekiwanymi dokumentami i przypadkami bez odpowiedzi. Oceń, czy źródło zostało znalezione i czy ma właściwą wersję. Nie oceniaj tylko ostatecznego tekstu.
Dodaj kody, parafrazy, synonimy, polskie znaki i zapytania niejednoznaczne. Sprawdź fałszywe trafienia. Dokument podobny tematycznie nie zawsze jest właściwy.
Przy braku źródła proces powinien zwrócić brak zamiast wybierać najbliższy. Test powinien to wymagać, a nie nagradzać odpowiedź za wszelką cenę.
Ranking i odbiór źródeł
Pokaż kilka pierwszych kandydatów z powodem i wersją. Nie oceniaj tylko pierwszego. Czasem właściwy dokument jest obecny, ale za nisko i nie trafia do modelu. Ranking wymaga osobnej oceny.
Nie porównuj wyników metod bez wspólnego zestawu. Jedna może być lepsza przy kodach, inna przy opisach. Hybryda powinna być oceniona według typów pytań.
Przy wersjach konfliktowych zachowaj regułę wyboru lub zatrzymanie. Nie wybieraj wyżej rankowanej starej wersji tylko dlatego, że ma więcej podobnych słów.
Kiedy słowa kluczowe wystarczą
Przy małej bazie z jasnymi pojęciami i kodami prosty indeks może być wystarczający. Dodanie embeddingów zwiększa koszt i utrzymanie bez wyraźnej korzyści. Test powinien to potwierdzić.
Przy formularzach i polach strukturalnych często lepsza jest reguła niż RAG. Nie wyszukuj semantycznie danych, które można filtrować dokładnie.
Jeżeli pytania są stabilne, prosty proces łatwiej utrzymać i odbierać. Nie buduj wektorów dla samej obecności AI.
Kiedy wektory wystarczą
Przy opisach eksploracyjnych i dużej liczbie parafraz wektory mogą wystarczyć. Nadal zachowaj filtry i dokładne pola dla identyfikatorów. Nie oznacza to braku kontroli.
Jeżeli kody są rzadkie, osobna reguła dla nich może być prostsza niż pełna hybryda. Nie musisz łączyć wszystkiego w jednym zapytaniu.
Przy dokumentach mało zróżnicowanych tematycznie wektory mogą zwracać wiele podobnych fragmentów. Oceń, czy słowa kluczowe nie ograniczają lepiej zbioru.
Kiedy hybryda ma sens
Wybierz ją przy mieszanych pytaniach: kodach i opisach, synonimach i wersjach. Test powinien pokazać poprawę znajdowania źródeł bez nadmiernego szumu. Sam fakt posiadania dwóch metod nie jest wynikiem.
Hybryda wymaga utrzymania indeksów, embeddingów, mapowania i rankingu. Przy małej bazie może kosztować więcej niż daje. Oceń pełny koszt.
Przy zmianie dokumentów lub modelu embeddingów powtórz przypadki. Nowa wersja może zmieniać podobieństwo i ranking.
Przykład: pytanie o politykę zwrotu
Użytkownik podaje numer polityki i pyta o termin. Słowa kluczowe znajdują właściwy dokument, a wektor inne o zwrotach. Hybryda powinna faworyzować dokładny identyfikator zamiast ogólnego tematu.
Przy pytaniu „czy mogę oddać bez wysyłki?” semantyka pomaga znaleźć zasady wyjątków. Odbiór sprawdza wersję i warunki. Model nie powinien odpowiadać tylko z podobnego dokumentu.
Test obejmuje oba typy i brak odpowiedzi. Źródło musi być aktualne i dostępne dla roli.
Odbiór odpowiedzi po wyszukiwaniu
Przy każdym błędzie zapisz, czy problem dotyczy źródła, filtra, rankingu, wersji czy generowania. Nie zmieniaj modelu, jeżeli dokument nie został znaleziony. Napraw właściwą warstwę.
Przy fałszywym trafieniu dodaj pytanie do zestawu. Może wymagać nowego filtra lub pola. Nie przepisuj całej metody dla jednego przypadku.
Embeddingi i wersja modelu
Zapisz model embeddingów i datę indeksowania. Przy zmianie modelu stare i nowe wektory mogą nie być porównywalne. Nie mieszaj ich bez decyzji i testu. Może być wymagana nowa indeksacja źródeł.
Przy migracji porównaj te same pytania i oczekiwane dokumenty. Nie oceń tylko szybkości lub nowej wersji. Zmiana podobieństwa może przesuwać właściwe źródła niżej.
Zachowaj możliwość odczytu starego indeksu do czasu odbioru. Rollback obejmuje wersję embeddingów, nie tylko model odpowiedzi. Dane i metadane muszą być zgodne.
Kiedy reguła kodu jest lepsza niż wyszukiwanie
Przy statusach, rolach, datach i identyfikatorach użyj pól strukturalnych. Nie przekazuj prostych filtrów modelowi. Reguła jest dokładna i tańsza. Wyszukiwanie powinno odpowiadać na część nieustrukturyzowaną.
Jeżeli odpowiedź wymaga jednego dokumentu, bezpośredni identyfikator jest lepszy niż ranking. Nie proś wektora o znalezienie go ponownie. Zapisz mapę i wersję.
Przy procesie formularza lub katalogu połącz reguły z wyszukiwaniem opisów. Każda warstwa ma swoją pracę.
Raport błędów z podziałem na pytania
Grupuj wyniki według kodów, parafraz, wersji i braku odpowiedzi. Nie przedstawiaj jednej średniej dla wszystkiego. Hybryda może poprawiać jeden typ i pogarszać drugi.
Dodaj przykłady fałszywych trafień i braków. Opisz, czy problem dotyczy wyszukiwania, filtra czy interpretacji. Właściciel powinien wiedzieć, co zmienić.
Przy ocenie kosztu zapisz indeksowanie, embeddingi, przechowywanie, wyszukiwanie i odbiór. Hybryda może zwiększać pracę przy każdej zmianie źródła. Przy małym wolumenie może nie być opłacalna. Porównaj z prostszym indeksem lub regułą.
Przy zmianie właściciela przekaż zestaw pytań i oczekiwane dokumenty. Nowa osoba powinna umieć odtworzyć test zamiast oceniać wynik na podstawie kilku przykładów. Zachowaj wersję indeksu i modelu embeddingów.
Jeżeli wyniki są trudne do wyjaśnienia, pokaż źródło i ranking przy kilku przypadkach. Nie zwiększaj liczby metod bez diagnozy. Czasem prosty filtr lub mapowanie pól daje większą poprawę niż nowa metoda wyszukiwania.
Przy zakończeniu procesu usuń indeksy i cache zgodnie z retencją. Stare wektory nie powinny zostać dostępne dla nowej roli bez oceny uprawnień.
Przy zmianie właściciela przekaż mapę indeksów, modeli i zależności. Nowa osoba powinna wiedzieć, które źródła wymagają ponownej indeksacji przy zmianie modelu. Nie przenoś samego rankingu.
Przy kolejnych wersjach dokumentów sprawdź, czy metoda nie faworyzuje starej wersji przez większe podobieństwo. Filtr i data obowiązywania powinny być rozstrzygające przed rankingiem.
Jeżeli wynik nie odpowiada pytaniu, nie przypisuj problemu tylko modelowi generującemu. Może źródło zostało źle pobrane lub podzielone. Napraw właściwą warstwę przed nowym testem.
Przy odbiorze nowej metody wykonaj test kodu i parafrazy z tym samym oczekiwanym źródłem. Hybryda powinna być oceniona według skutku, nie samej obecności funkcji.
Zapisz właściciela indeksu i wersję embeddingów. Bez nich trudno odtworzyć ranking i błędy. Nowa konfiguracja powinna być porównywana z poprzednią na tych samych pytaniach.
Przy kolejnych zmianach źródeł sprawdź, czy metoda nie zwraca starych wersji. Filtr i aktualizacja indeksu mają poprzedzać generowanie odpowiedzi.
Przy odbiorze nowej metody zapisz przypadki, przy których zawodzi. Nie przedstawiaj hybrydy jako rozwiązania każdego problemu. Może zwiększać podobne, ale błędne wyniki.
Zachowaj zestaw zapytań i wersję indeksu. Nowy właściciel powinien móc powtórzyć ocenę i porównać ranking z poprzednią konfiguracją.
Przy odbiorze końcowym poproś właściciela źródła o ocenę kilku trafień i fałszywych wyników. Nie oceniaj tylko tego, czy model odpowiada płynnie. Dokument i wersja muszą być właściwe.
Zapisz, które pytania wymagają reguły zamiast wyszukiwania. To ogranicza niepotrzebną złożoność i pokazuje właściwy zakres RAG.
Przy odbiorze końcowym sprawdź jeden kod, jedną parafrazę i jeden przypadek bez źródła. To pokazuje zarówno trafność, jak i zachowanie przy braku odpowiedzi. Zapisz wersję indeksu i oczekiwane dokumenty.
Przy kolejnych przeglądach porównaj wynik z poprzednią metodą. Nowa konfiguracja powinna poprawiać znajdowanie źródeł, a nie tylko dodawać funkcje. Odbiór powinien obejmować koszt i właściciela decyzji.
Aeneia Audit pomaga zmapować źródła i pytania. Przy architekturze pomocna jest architektura wiedzy Aeneia Signal.
Na koniec porównaj metody na pytaniach, które naprawdę trafiają do bazy: od dokładnego numeru dokumentu po opis problemu własnymi słowami. Dla pominiętych wyników zanotuj, czy zawiodło źródło, filtr dostępu czy sposób wyszukiwania. Takie rozróżnienie ułatwia decyzję, czy hybryda jest potrzebna w danym procesie.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
