Zmiana modelu embeddingów RAG: migracja chatbota AI bez luk w wiedzy

Model embeddingów działa zazwyczaj niezauważalnie w tle chatbota RAG. Przekształca pytania i fragmenty wiedzy na wektory liczbowe, aby odnaleźć treści dopasowane semantycznie. Właśnie dlatego, że ten element rzadko pojawia się w interfejsie użytkownika, zmiana modelu może wydawać się drobną korektą konfiguracji. Technicznie powstaje jednak zupełnie nowa przestrzeń wyszukiwania. Dotychczasowe wektory dokumentów, wektory nowych pytań oraz definicja indeksu muszą ponownie do siebie pasować.

Każdy, kto chce zmienić embeddingi RAG, nie powinien po prostu podmieniać nazwy modelu w potoku zapytań (query pipeline). Bezpieczna zmiana traktuje nowy indeks jak osobną wersję: zbudowaną w sposób powtarzalny, przetestowaną na tych samych pytaniach, uruchomioną najpierw równolegle i aktywowaną dopiero po świadomej decyzji o wdrożeniu. Dzięki temu chatbot na stronie pozostaje dostępny, podczas gdy zespół zachowuje pełną kontrolę nad jakością, czasem odpowiedzi, kosztami i ścieżką powrotu.

Dlaczego embeddingów nie można dowolnie podmieniać

Wektor ma sens wyłącznie w przestrzeni, w której został wygenerowany. Oficjalna dokumentacja Azure AI Search dotycząca tworzenia indeksu wektorowego opisuje indeks jako przestrzeń embeddingów złożoną z wektorów tego samego modelu. Zwraca również uwagę, że wymiar każdego wektora musi odpowiadać definicji pola. Nowy model może mieć inny wymiar, inne atuty językowe lub inny rozkład odległości semantycznych.

Równie ważna jest strona zapytania. Zgodnie z dokumentacją Microsoftu dotyczącą konfiguracji wektoryzatora, indeksowanie i zapytania muszą używać tego samego modelu embeddingów. Jeśli zespół pomiesza stare wektory dokumentów z pytaniami z nowego modelu, interpretacja wyników podobieństwa przestaje być wiarygodna. Nawet jeśli wymiary przypadkowo się zgadzają, nie dowodzi to kompatybilności semantycznej.

Zdefinuj mierzalny cel przed zmianą

„Nowszy” to za mało jako kryterium odbioru. Przed pierwszym ponownym indeksowaniem zespół potrzebuje konkretnego powodu do migracji. Czy chodzi o poprawę jakości wyników dla specyficznej terminologii? Czy potrzebne są dodatkowe języki? A może dotychczasowy model wycofano z użycia, jest zbyt wolny lub za drogi? Albo mniejszy wymiar wektora ma zaoszczędzić miejsce w pamięci? Z celu wynikają metryki porównawcze.

• Jakość: istotne źródła w Top-k, odsetek pytań z odpowiedzią oraz jakość ostatecznej odpowiedzi.
• Utrzymanie: opóźnienie wyszukiwania (retrieval latency), wskaźnik błędów, czas indeksowania i zachowanie przy częściowych błędach.
• Koszty: przetworzenie całego zasobu, bieżące aktualizacje, pamięć masowa i zapytania.
• Pokrycie: dokumenty, języki, wersje produktów i obszary uprawnień w nowym indeksie.

Wartości wyjściowe powinny trafić do tego samego raportu co wyniki kandydata. Zespoły, które utrzymują już zestaw testowy (Golden Set), mogą wykorzystać istniejący przewodnik dotyczący mierzenia jakości odpowiedzi chatbota AI jako punkt odniesienia. Ważne jest, aby nie porównywać wyłącznie średniej oceny: krytyczne pytania wsparcia, rzadkie pojęcia techniczne i przypadki braku wyników wymagają osobnej analizy.

Dwa indeksy zamiast przebudowy na żywym organizmie

Niezawodnym standardem jest indeks równoległy. Dotychczasowy indeks pozostaje bez zmian i obsługuje ruch produkcyjny. Obok powstaje nowa kolekcja lub nowy indeks z własnym identyfikatorem modelu, wymiarem, metryką odległości i numerem wersji. Oba są budowane z tej samej zatwierdzonej wersji źródłowej. Dzięki temu wszelkie różnice można przypisać do modelu lub konfiguracji indeksu, zamiast analizować jednocześnie zmieniające się treści.

Oficjalny poradnik Weaviate dotyczący zmiany wektoryzatora pokazuje w tym celu osobne kolekcje i alias jako odwracalny punkt przełączenia. Konkretny produkt jest drugorzędny; zasada pozostaje cenna: czysto odizolować stare i nowe embeddingi, kierować dostępem przez kontrolowany router lub alias i zachować stary stan na ograniczony czas ewentualnego wycofania zmian.

Stabilne identyfikatory dla każdego fragmentu wiedzy

Każdy chunk potrzebuje stabilnego ID biznesowego, które nie zależy od wektora. Dobre rozwiązanie to połączenie ID źródła, wersji źródła, sekcji i wersji chunka. Dodatkowo każdy rekord powinien zawierać nazwę modelu, wersję modelu, wymiar, czas utworzenia i hash przetworzonego tekstu. Pozwala to potokowi danych dokładnie rozpoznać, co zostało już przetworzone, co trzeba ponownie przetworzyć, a które błędy są wciąż otwarte.

Ustal nowy potok danych w sposób powtarzalny

Przed pełnym przetworzeniem bazy warto przepuścić mały, reprezentatywny podzbiór przez nowy potok. Ekstrakcja, czyszczenie i dzielenie treści RAG (chunking) powinny na początku pozostać bez zmian. Jeśli zespół zmieni jednocześnie model, granice chunków, metadane i ranking, późniejsza różnica w jakości będzie trudna do wyjaśnienia.

Konfiguracja powinna trafiać do zaktualizowanego manifestu w repozytorium: model i dostawca, wymiar, normalizacja, metryka odległości, rozmiar wsadu (batch size), reguły powtórzeń, wersja chunkera, dozwolone języki i wymagane metadane. Dane dostępowe nie mogą się tam znaleźć. Dla każdego wsadu zapisuje się tylko identyfikatory, liczniki, status i bezpieczny kod błędu. Pozwala to wznowić przerwany proces bez kosztownego powtarzania udanych operacji.

Kontrolowane ponowne tworzenie embeddingów i weryfikacja kompletności

Reindeksacja jest kompletna dopiero wtedy, gdy stan docelowy zgadza się ze stanem faktycznym. Sama wysoka liczba dokumentów nie wystarczy. Potok powinien sprawdzić dla każdego źródła, czy istnieją wszystkie oczekiwane chunki, czy ich hashe tekstu zgadzają się z zatwierdzoną wersją źródłową i czy przeniesiono wszystkie wymagane metadane. Rekordy zakończone błędem trafiają do kolejki powtórzeń; trwałe błędy pozostają widoczne ze swoim ID i nie mogą znikać pod zielonym statusem sukcesu.

1. Zamroź lub jednoznacznie oznacz stan źródeł i datę wersji.
2. Utwórz nową strukturę indeksu z odpowiednim wymiarem i metryką.
3. Generuj i zapisuj embeddingi chunków w kontrolowanych, idempotentnych wsadach.
4. Porównaj liczbę dokumentów, chunków i metadanych ze stanem docelowym.
5. Sprawdź próbkę na podstawie hasha tekstu, ID źródła i pobranej treści.

Porównaj wyszukiwanie (retrieval) za pomocą identycznych pytań

Teraz te same pytania testowe trafiają do obu indeksów. Oprócz trafności i pozycji w rankingu zespół powinien porównać faktycznie zwrócone źródła. Czy nowy indeks nie przesunął na górę fragmentów semantycznie podobnych, ale błędnych merytorycznie? Czy nie gubi dokładnych kodów produktów? Czy lepiej odnajduje słowa złożone i pytania wielojęzyczne? Istniejąca koncepcja wyszukiwania hybrydowego i rerankingu musi być skonfigurowana identycznie dla obu wariantów, aby porównanie było sprawiedliwe.

Dokumentacja Azure na temat trafności i rankingu wektorowego wspomina o wyczerpującym wyszukiwaniu k-najbliższych sąsiadów (k-NN) jako sposobie na stworzenie zbioru odniesienia (ground truth) do oceny metody przybliżonej (ANN). Nie jest to uniwersalny próg, ale przydatny test kontrolny: najpierw dokładny punkt odniesienia, potem szybsze wyszukiwanie produkcyjne. Dla chatbota liczy się dodatkowo, czy znalezione źródła pozwalają na wygenerowanie poprawnej i popartej dowodami odpowiedzi.

Sprawdzaj nie tylko trafienia, ale i gotową odpowiedź

Wyższa pozycja w wyszukiwaniu nie gwarantuje jeszcze lepszej odpowiedzi chatbota. Dlatego porównanie powinno obejmować spójność ze źródłem, kompletność, dopuszczalną niepewność oraz bezpieczne przerwanie pracy w przypadku braku wystarczających dowodów. Model odpowiedzi, instrukcje systemowe i temperatura powinny pozostać w miarę możliwości stałe. W przeciwnym razie test mierzy kilka zmian jednocześnie.

Shadow Reads przed właściwym przełączeniem

Po testach offline niewielka część rzeczywistych pytań może dodatkowo trafiać do nowego indeksu w trybie równoległym (shadow read) – bez prezentowania wyników użytkownikom. Taki test mierzy naturalny język, opóźnienia i zachowanie przy braku wyników. Prywatne treści, dane osobowe i pełne historie rozmów nie powinny trafiać do logów porównawczych bez weryfikacji. Często wystarczą zanonimizowane klasy zapytań, ID wyników i metryki techniczne.

Samo przełączenie (cutover) to drobna, łatwa do monitorowania zmiana: alias, cel routera lub flaga funkcji (feature flag) zmienia się z indeksu A na indeks B. W pierwszej fazie obowiązują surowsze progi alarmowe dla braku źródeł, błędów wyszukiwania, opóźnień i wskaźnika przekazania do człowieka (handoff). Stopniowe przełączanie ruchu ma sens, jeśli architektura obsługuje je bez mieszania stanów sesji.

Przetestuj procedurę rollback w praktyce przed przełączeniem

Plan wycofania zmian (rollback) jest wiarygodny tylko wtedy, gdy stary indeks jest nadal aktualny, a ścieżka powrotna została przetestowana. W fazie równoległej nowe lub zmienione źródła powinny trafiać w kontrolowany sposób do obu potoków danych. Alternatywnie zespół dokumentuje krótkie zamrożenie zmian i późniejsze nadrabianie zaległości. Dostępny przewodnik po reagowaniu na incydenty i procedurze rollback pomaga ustalić sygnały alarmowe i odpowiedzialność.

Typowe sygnały do wycofania zmian to nie tylko błędy techniczne. Wyraźny spadek trafności w Top-k, nowe luki językowe, nietypowo duża liczba pytań bez odpowiedzi czy błędnie zastosowane filtry dostępu również uzasadniają powrót. Stary indeks usuwa się dopiero wtedy, gdy minie okres obserwacji, decyzja o usunięciu zostanie udokumentowana i nie pozostaną żadne wyjaśnione różnice w jakości.

Częste błędy podczas migracji embeddingów

• Zmiana tylko po stronie zapytań: nowe wektory pytań są porównywane ze starą przestrzenią dokumentów.
• Mylenie jednakowego wymiaru z kompatybilnością: długość ciągu liczb i przestrzeń semantyczna to nie to samo.
• Równoczesna zmiana zbyt wielu zmiennych: model, chunking i ranking zmieniają się naraz; przyczyna efektu pozostaje nieznana.
• Kierowanie się wyłącznie średnimi wynikami: rzadkie, krytyczne biznesowo i wielojęzyczne pytania znikają w ogólnym uśrednieniu.
• Zbyt wczesne czyszczenie danych: stary indeks zostaje usunięty, zanim realne obciążenie i dane jakościowe potwierdzą stabilność.
• Pomijanie filtrów: język, wersja i dostęp nie działają w nowym indeksie dokładnie tak samo jak w starym.

Lista kontrolna dla zespołów zajmujących się stronami WWW

• Cel, stan odniesienia, kryteria odbioru, osoba zatwierdzająca i sygnał do wycofania zmian są udokumentowane.
• Stary i nowy indeks pozostają odseparowane; model, wymiar i metryka mają jasną wersję.
• Oba indeksy pochodzą z tej samej zatwierdzonej wersji źródeł i chunków.
• Proces zasilania (backfill) jest idempotentny, możliwy do wznowienia i zweryfikowany ze stanem docelowym.
• Zestaw testowy (Golden Set), krytyczne pytania, języki, przypadki braku wyników i filtry dostępu przechodzą test porównawczy.
• Shadow Reads rejestrują tylko niezbędne dane techniczne.
• Przełączenie i ewentualny powrót są proste, monitorowane i przetestowane w praktyce.
• Stary zasób jest usuwany dopiero po okresie obserwacji i pisemnym zatwierdzeniu.

Podsumowanie: nowa przestrzeń wektorowa wymaga własnego procesu wydań

Zmiana embeddingów RAG to migracja danych i jakości, a nie zwykły przełącznik w konfiguracji. Zespół, który osobno buduje nową przestrzeń wyszukiwania, ponownie przetwarza całą bazę, porównuje wyniki na tych samych pytaniach i aktywuje wszystko przez odwracalny punkt przełączenia, znacząco redukuje ryzyko awarii i spadku jakości. Zespołom opiekuńczym opłaca się stworzyć prosty proces wydań: zabezpieczyć punkt odniesienia, zbudować indeks równoległy, sprawdzić wyszukiwanie i odpowiedzi, przeanalizować dane z shadow read, kontrolowanie przełączyć ruch i zachować ścieżkę powrotną.

Jeśli Twój chatbot AI korzysta już z bazy wiedzy RAG, nie zaczynaj migracji od zmian w kodzie, ale od przygotowania zbioru testowego. Od dziesięciu do dwudziestu kluczowych kategorii pytań, uzupełnionych o trudne przypadki językowe, produktowe i uprawnieniowe, decyduje o różnicy między niepewną zmianą modelu a bezpiecznym, udokumentowanym wdrożeniem.

Źródła

• Microsoft Learn: Create a vector index in Azure AI Search
• Microsoft Learn: Configure a vectorizer in Azure AI Search
• Microsoft Learn: Relevance in vector search
• Weaviate Documentation: Switching vectorizers