Смяна на RAG embedding модел: Миграция на AI чатбот без пропуски в знанията

Моделът за векторни репрезентации (embedding) обикновено работи незабележимо във фонов режим на RAG чатбота. Той превежда въпросите и градивните елементи от знания в числови вектори, за да могат да бъдат намерени семантично подходящи съдържания. Тъй като тази част рядко се появява в потребителския интерфейс, смяната на модела лесно може да изглежда като малка промяна в конфигурацията. Технически обаче се създава напълно ново пространство за търсене. Съществуващите вектори на документи, векторите на новите въпроси и дефиницията на индекса трябва отново да си съответстват перфектно.

Всеки, който иска да смени RAG embeddings, не трябва просто да замени името на модела в пайплайна за заявки. Сигурната смяна разглежда новия индекс като самостоятелна версия: изграден възпроизводимо, проверен с същите тестови въпроси, първоначално поддържан паралелно и активиран едва след осъзнато решение за одобрение. Така чатботът на уебсайта остава достъпен, докато екипът държи под контрол качеството, времето за изпълнение, разходите и пътя за връщане назад.

Защо embeddings не са произволно взаимозаменяеми

Векторът има смисъл само в рамките на пространството, в което е създаден. Официалната документация на Azure AI Search за създаване на векторен индекс описва индекса като embedding пространство от вектори на един и същ модел. Тя също така посочва, че размерността на всеки вектор трябва да съответства на дефиницията на полето. Новият модел може да има различна размерност, различни езикови силни страни или различно разпределение на семантичните разстояния.

Заявката е също толкова важна. Съгласно документацията на Microsoft за конфигурация на vectorizer, индексирането и заявката трябва да използват един и същ embedding модел. Ако екип смеси стари вектори на документи с въпроси от нов модел, резултатите за сходство вече не могат да се интерпретират надеждно. Дори ако размерността случайно е идентична, това не доказва семантична съвместимост.

Дефиниране на измерима цел преди смяната

„По-нов“ не е достатъчен критерий за приемане. Преди първото преиндексиране екипът се нуждае от конкретна причина за миграцията. Цели ли се повишаване на качеството на съвпаденията на специализиран български език? Нужни ли са допълнителни езици? Настоящият модел спрени от поддръжка ли е, твърде бавен ли е или твърде скъп? Или по-малка размерност на векторите трябва да спести памет? Измеримите метрики за сравнение произтичат именно от целта.

• Качество: релевантни източници в Top-k, дял на въпросите, на които може да се отговори, и качество на крайната отговор.
• Оперативна работа: латентност на извличане (retrieval), процент грешки, продължителност на индексиране и поведение при частични грешки.
• Разходи: генериране на embeddings за целия ресурс, текущи промени, съхранение и заявки.
• Покритие: документи, езици, версии на продукти и области на достъп в новия индекс.

Първоначалните стойности принадлежат към същия тестови доклад като резултатите на кандидата. Всеки, който вече поддържа Golden Set за тази цел, може да използва съществуващото ръководство за измерване на качеството на отговорите на AI чатбот като основа. Важно е да не се сравнява само среден резултат: критичните въпроси за поддръжка, редките специализирани термини и случаите без резултат (No-Result) заслужават отделни оценки.

Два индекса вместо преустройство на работеща система

Надеждният стандарт е паралелният индекс. Досегашният индекс остава непроменен и обслужва реалния трафик. Заедно с него се създава нова колекция или нов индекс с собствено означение на модела, размерност, метрика за разстояние и номер на версията. И двата се изграждат от една и съща одобрена изходна версия. По този начин разликите могат да бъдат приписани на модела или конфигурацията на индекса, вместо да се сравнява едновременно променящо се съдържание.

Официалното ръководство на Weaviate за смяна на vectorizer показва отделни колекции и псевдоним (alias) като обратима точка за превключване. Конкретният продукт е заменяем; принципът остава ценен: ясно изолирайте старите и новите embeddings, прекарвайте достъпа през контролиран рутер или alias и запазете старото състояние за ограничен период за връщане назад.

Стабилна идентификация за всеки градивен елемент от знания

Всеки фрагмент (chunk) се нуждае от стабилно бизнес ID, което не зависи от вектора. Разумно е използването на комбинация от ID на източника, версия на източника, раздел и версия на фрагмента. В допълнение, всеки запис трябва да съдържа име на модела, версия на модела, размерност, време на създаване и хеш на въведения текст. По този начин пайплайнът може точно да разпознае какво вече е обработено, какво трябва да бъде отново конвертирано във вектор и кои грешки все още са отворени.

Възпроизводимо фиксиране на новия пайплайн

Преди голямото преиндексиране (backfill) малка представителна подсъвкупност трябва да премине през новия пайплайн. Извличането, почистването и RAG chunking първоначално остават непроменени. Ако екипът промени едновременно модела, границите на фрагментите, метаданните и ранжирането, последващата разлика в качеството трудно може да бъде обяснена.

Конфигурацията принадлежи към изпълнението под формата на документиран манифест с версии: модел и доставчик, размерност, нормализация, метрика за разстояние, размер на партидата (batch size), правила за повторен опит, версия на chunker-а, позволени езици и необходими метаданни. Данните за достъп изрично не трябва да се съдържат вътре. За всяка партида се запазват само IDs, броячи, статус и сигурен код за грешка. По този начин прекъснато изпълнение може да бъде възобновено, без скъпо да се повтарят успешни генерирания на embeddings.

Контролирано ново генериране на вектори и доказателство за пълнота

Преиндексирането е пълно едва когато целевият и действителният ресурс съвпадат. Големият брой документи сам по себе си не е достатъчен. Пайплайнът трябва да проверява за всеки източник дали всички очаквани фрагменти присъстват, дали техните текстови хешове съответстват на одобрената изходна версия и дали всички задължителни метаданни са намерени. Неуспешните записи отиват в ограничена опашка за повторение; трайните грешки остават видими със своето ID и не трябва да изчезват зад общ зелен статус.

1. Замразете или маркирайте ясно изходния ресурс и референтната дата за версията.
2. Създайте нова структура на индекса със съответната размерност и метрика.
3. Генерирайте embeddings и записвайте фрагментите в ограничени, идемпотентни партиди.
4. Сравнете броя на документите, фрагментите и метаданните спрямо целевия ресурс.
5. Проверете извадка въз основа на текстовия хеш, ID на източника и съдържанието, което може да бъде извлечено.

Сравнение на извличането (retrieval) с идентични въпроси

Сега същите тестови въпроси се изпълняват спрямо двата индекса. Освен процента на съвпадение и позицията в класирането, екипът трябва да сравни действително върнатите източници. Дали новият индекс е издигнал нагоре семантично подобни, но технически грешни абзаци? Губи ли той точни продуктови кодове? По-добре ли се намират сложни думи или езикови въпроси? Съществуваща концепция за хибридно търсене (hybrid search) и reranking трябва да бъде конфигурирана идентично за двата кандидата, за да остане сравнението справедливо.

Документацията на Azure относно векторната релевантност и ранжирането посочва изчерпателното търсене на k-най-близки съседи (k-nearest-neighbor) като възможност за изграждане на Ground Truth за оценка на отпокритието (recall) при приблизителен ANN метод. Това не е универсален праг, но е полезен контролен тест: първо точната референция, след това по-бързото продуктивно търсене. За чатбота допълнително е важно дали намерените източници позволяват правилен, потвърден отговор.

Проверка не само на съвпаденията, но и на готовия отговор

По-доброто ранжиране при извличане все още не гарантира по-добър отговор от чатбота. Ето защо сравнението трябва да включва и позоваването на източника, пълнотата, допустимата несигурност и безопасното прекратяване при недостатъчно доказателства. В този процес моделът за отговор, системните инструкции и температурата остават възможно най-постоянни. В противен случай тестът измерва няколко промени едновременно.

Shadow Reads преди истинското превключване (cutover)

След офлайн теста малък дял от реалните, обработени с пестене на данни търсения, може допълнително да се изпълнява спрямо новия индекс, без резултатът му да се показва на потребителите. Този Shadow Read измерва реалния език, латентността и поведението при липса на резултати (No-Result). Частното съдържание, личните данни и пълните хронологии на разговорите не принадлежат необработени в логовете за сравнение. Често са достатъчни псевдонимизирани класове заявки, IDs на резултатите и технически измервателни стойности.

Самото превключване е малка, ясно наблюдаема промяна: alias, цел на рутера или feature flag преминава от индекс A към индекс B. По време на първата фаза важат по-строги граници на аларма за липсващи източници, грешки при извличане, латентност и процент на прехвърляне към човек (handoff). Поетапният дял е разумен, ако архитектурата го поддържа без смесени състояния на сесията.

Практическо тестване на rollback преди превключването

Планът за връщане назад (rollback) е надежден само ако старият индекс продължава да бъде достатъчно актуален и пътят за връщане е тестван. По време на паралелната фаза новите или променени източници трябва контролирано да постъпват и в двата пайплайна. Алтернативно, екипът документира кратко спиране на промените и ясен последващ процес. Съществуващото ръководство за реакция при инциденти и rollback помага за определяне на тригерите и отговорностите.

Типичните сигнали за връщане назад не са само технически грешки. Значителен спад в релевантните Top-k съвпадения, нови езикови пропуски, необичайно много unanswered въпроси или неправилно приложени филтри за достъп също оправдават връщането. Старият индекс се премахва едва когато периодът на наблюдение приключи, одобрението за изтриване е документирано и няма останали неизяснени разлики в качеството.

Чести грешки при миграция на embeddings

• Смяна само от страната на заявката: Новите вектори на въпроси се сравняват със старо пространство от документи.
• Бъркане на еднаквата размерност със съвместимост: Дължината на числата и семантичното пространство не са едно и също нещо.
• Промяна на няколко променливи едновременно: Моделът, chunking и ранжирането се сменят едновременно; причината за даден ефект остава неясна.
• Разглеждане само на средните стойности: Редките, критични за бизнеса и многоезични въпроси изчезват в средната стойност.
• Твърде рано почистване: Старият индекс се изтрива, преди реалното натоварване и данните за качество да покажат стабилна работа.
• Забравяне на филтри: Езикът, версията и достъпът не важат в новия индекс по абсолютно същия начин, както в стария.

Практически чеклист за уебсайт екипи

• Целта, изходната точка (baseline), критериите за приемане, отговорното лице и сигналът за rollback са документирани.
• Старият и новият индекс остават отделени; моделът, размерността и метриката са ясно версионирани.
• И двата индекса произлизат от една и съща одобрена версия на източниците и фрагментите.
• Backfill процесът е идемпотентен, може да се възобновява и е проверен спрямо целевия ресурс.
• Golden Set, критичните въпроси, езиците, случаите без резултат и филтрите за достъп преминават успешно сравнението.
• Shadow Reads логват само необходими технически данни.
• Cutover и връщането назад са малки, наблюдаеми и практически тествани стъпки.
• Старият ресурс се изтрива едва след периода на наблюдение и документирано одобрение.

Заключение: Новото векторно пространство се нуждае от собствен release процес

Смяната на RAG embeddings е миграция на данни и качество, а не просто превключване на модел. Всеки, който изгражда новото търсещо пространство отделно, преиндексира напълно, сравнява с идентични въпроси и активира през обратима точка за превключване, значително намалява рисковете от прекъсване и влошаване на качеството. За екипите на уебсайтове си струва кратък, повторно използваем runbook процес: запазване на baseline, изграждане на паралелен индекс, проверка на retrieval и отговорите, наблюдение на shadow данни, контролирано превключване и поддържане на отворен път за връщане назад.

Ако вашият AI чатбот вече използва база от знания с RAG, не започвайте с миграцията, а с набора от данни за проверка. Десет до двадесет особено важни класа въпроси, допълнени с трудни езикови, продуктови и специфични за правата случаи, правят разликата между вероятна смяна на модела и доказано сигурен release.

Източници

• 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