Смяна на основния AI модел без спад в качеството: Evals, Canary и Rollback

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

Доставчиците редовно обявяват спирането на модели. В документацията на OpenAI относно спиране на модели са посочени датите за спиране и препоръчителните заместващи модели; Anthropic прави разлика в своя жизнен цикъл на моделите между статусите „Active“, „Legacy“, „Deprecated“ и „Retired“. Подобни срокове са поводът за миграция, но не и доказателството за нейното качество. Доказателството идва единствено от процедура за тестване и внедряване, съобразена с вашия конкретен чатбот.

Какво всъщност се променя при смяната на основния модел

Този процес трябва ясно да се разграничава от миграцията на модела за вграждане (Embedding). При смяна на Embedding модела документите трябва да се векторизират отново, а индексите за търсене да се поддържат съвместими. При смяна на основния модел индексът за търсене обикновено остава непроменен; променя се моделът, който генерира отговора въз основа на системната инструкция, разговора, намерените източници и резултатите от инструментите. Затова се тестват поведението при отговор, връзката с източниците, форматът, използването на инструменти, сигурността, латентността и разходите.

Дори общият тест в Shadow режим преди пускане на уебсайта решава само част от задачата. Shadow трафикът може да подаде едни и същи данни към два модела, без да доставя новия отговор на потребителя. Описаната тук смяна на основния модел отива по-далеч: тя предварително дефинира матрица за приемане, пренасочва малък дял от реалния трафик към новия кандидат, следи потребителските и системните сигнали и поддържа тествана процедура за връщане назад.

Преди теста: определяне на ясен договор за миграция

Сравненията са безполезни, ако междувременно се променят няколко неща. Затова за първия кръг запазете максимално съвместими системния промпт, конфигурацията на търсенето, схемите на инструментите, температурата, максималната дължина на отговора и правилата за сигурност. Документирайте неизбежните промени в параметрите, като например неподдържани опции за семплиране. Документирайте досегашния модел като базов, а новия – като кандидат. По възможност използвайте конкретни версии на моделите, а не променлив псевдоним (alias). Един псевдоним може по-късно да се пренасочи към друг снапшот и да промени уж възпроизводимото сравнение.

Договорът за миграция съдържа също така потребителските групи и функциите, които първоначално остават изключени. Например чатбот за ЧЗВ може рано да премине към Canary трафик, докато операциите по запис при поръчки, справките по договори или особено чувствителните казуси за поддръжка остават по-дълго на базовия модел. Така рискът се ограничава според бизнес въздействието, а не само според техническата сложност.

Тестовият набор трябва да отразява реалния трафик

Един Golden Set не трябва да съдържа само чисти стандартни въпроси. Съберете анонимизирани или синтетично пресъздадени казуси от най-важните намерения (intents): ясни въпроси, двусмислени формулировки, последващи въпроси, липсващи документи, противоречиви източници, грешки в инструментите и въпроси, които трябва да бъдат пренасочени към човек. Разпределете казусите по език, устройство, тип клиент и клас на риска. Така се вижда дали добрата обща оценка не прикрива малки, но критични за бизнеса подгрупи.

Официалното ръководство на Anthropic за критерии за успех и Evals препоръчва специфични, измерими и свързани с приложението критерии, както и реалистични гранични казуси. Също така ръководството на OpenAI за Evals описва тестовете като съществена част от надеждните приложения, особено при надграждане или изпробване на нови модели. Тъй като OpenAI обявява прекратяването на досегашната си Evals платформа на същата страница, вашият Golden Set трябва да се съхранява в преносим формат и да не бъде обвързан с един-единствен панел за управление.

Матрица за оценка вместо една-единствена средна стойност

Следните гранични стойности са пример, а не универсално правило. Определете ги въз основа на досегашната си продукционна производителност и щетите от евентуална грешка. Новият кандидат не трябва да постига по-ниска цена на токените за сметка на по-лоша връзка с източниците.

Автоматизираните проверки са подходящи за JSON схеми, задължителни формулировки, линкове, аргументи на инструментите и детерминистични бизнес правила. За тона, пълнотата и полезните обяснения е необходима допълнителна ясна рубрика; извадките, проверявани от експерти, калибрират оценител, базиран на LLM. Резултатите трябва да се съхраняват по intent и клас на риска, а не само като обща оценка. Как принципно се изгражда такъв набор, показва и нашето ръководство за качество на отговорите с Golden Set.

Конкретен пример: смяна на модел в B2B поддръжката

Да предположим, че B2B софтуерен доставчик използва чатбот за въпроси за продукта, управление на акаунти и подготовка на тикети за поддръжка. Екипът създава 240 тестови казуса: 120 често срещани информационни въпроса, 40 двусмислени последващи въпроса, 30 казуса с липсващ източник, 25 симулации на инструменти и 25 казуса за сигурност или прехвърляне към оператор. И двата модела получават абсолютно едни и същи промптове, резултати от търсенето и симулирани резултати от инструментите.

Кандидатът отговаря на стандартните въпроси по-бързо и евтино, но при пет последващи въпроса губи контекста на предишното съобщение. Общата оценка въпреки това би била по-добра. Анализът по сегменти обаче показва ясен спад в качеството. Екипът не добавя произволно изключение, а прецизира правилото за водене на разговор, разширява тестовия набор с подобни казуси и тества отново и двата модела. Едва след като кандидатът премине всички строги критерии, започва реалният Canary трафик.

За начало два процента от подходящите нови разговори се пренасочват към новия кандидат. Разпределението се извлича в началото на разговора, например от хеш на Conversation ID, и се запазва за целия разговор; по-високите нива на Canary важат само за нови разговори. Извикванията на инструменти с право за запис и казусите с висок риск първоначално остават на базовия модел. След достатъчно голям прозорец за наблюдение следват 10, 25, 50 и накрая 100 процента – но само ако всеки критерий продължава да е зелен. Етапите и минималните извадки се определят предварително, за да не може натискът от време да размие правилата.

Онлайн сигнали, които наистина имат значение

При Canary трафика HTTP грешките и средната латентност не са достатъчни. Наблюдавайте процента липса на отговор, прекъсванията след първия отговор, повторните въпроси, процента прехвърляния към оператор, кликванията върху източници, грешките в схемите и прекъсванията на инструментите – отделно за базовия модел и кандидата. Общият трасиращ запис свързва версията на модела, версията на промпта, намерените източници и стъпките на инструментите, без да съхранява излишни лични данни. Нашата публикация за наблюдаемост на чатботове обяснява подробно тази проследимост.

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

Rollback е функционалност, а не документ

Процедурата за връщане назад трябва да бъде технически тествана преди първия етап на Canary. Идентификаторът на модела и съответните параметри принадлежат към версионирана конфигурация или контролиран Feature Flag. Докато доставчикът все още поддържа предишната версия, тя остава налична като алтернатива по време на Canary теста; преди крайния ѝ срок за спиране е необходима допълнителна поддържана резервна опция. Съществуващите разговори трябва или да останат последователно на първоначалния си модел, или да преминат по изрично тествано правило.

Дефинирайте твърди тригери: например грешка в схемата при действие за запис, влошаване при важен за сигурността intent, значителен скок в процента грешки или превишаване на бюджета за латентност. При такъв сигнал превключването се извършва автоматично или от ясно определен дежурен екип. След това логовете, версията на кандидата и засегнатата извадка се запазват, за да може да се анализира причината. Подготвената процедура е много по-надеждна от спонтанно внедряване на код; в допълнение помага и пълен план за реакция при инциденти.

Чеклист за одобрение

• Запишете крайния срок за спиране, заместващия модел и засегнатите крайни точки от официалната документация на доставчика.
• Фиксирайте базовия модел и кандидата с непроменена конфигурация на промпта, търсенето и инструментите.
• Разделете Golden Set по intent, език и клас на риска; добавете гранични казуси и реални грешки.
• Дефинирайте строги критерии за точност на източниците, структурирани данни, инструменти, сигурност и прехвърляне.
• Измерете латентността, процента грешки, токените и разходите за решен казус.
• Запазете стабилно Canary разпределението за целите разговори и първоначално изключете чувствителните функции.
• Документирайте етапите, минималната извадка, времетраенето за наблюдение и границите за прекратяване преди пускането.
• Тествайте технически Rollback процедурата, определете отговорници и осигурете налична резервна цел, поддържана от доставчика.
• Продължете наблюденията след 100% внедряване и разширете Golden Set с новооткрити казуси от реалната среда.

Заключение: Името на модела е само началото

Контролираната смяна на основния модел съчетава качество на продукта и оперативна сигурност. Официалните известия за жизнения цикъл дават крайния срок, Evals осигуряват доказателства за пригодност, Canary трафикът ограничава въздействието на неизвестни грешки, а тестваният Rollback скъсява времето за реакция. Всеки, който установи тези четири елемента като повторяем процес, може да използва нови модели, без да превръща уебсайт чатбота си в експеримент за всички потребители.

Искате ли да планирате структурирано версията на модела, критериите за качество и внедряването на вашия уебсайт чатбот? ChatReact ви помага да настроите базата от знания, поведението при отговор и прехвърлянията така, че промените да останат измерими и контролируеми.