Печалби:
- Възможност за разпознаване на тихи причини за влошаване на модела (дрейф на данни, концептуален дрифт, грешка нагоре) и установяване на трислоен (оперативен, входен, изходен) мониторинг
- Възможност за оценка на LLM системи в множество слоеве с проверки на правила, LLM-референтна и човешка оценка и калибриране с LLM-референтна човешка котва
- Възможност за проектиране на набор за оценка, съдържащ крайни и защитни случаи и превръщане на всяка уловена грешка в постоянен тестов случай
След като моделът влезе в производство, вашата работа не е свършена; Истинската отговорност тепърва започва. Тъй като моделът може тихо да се разпадне, когато никой не гледа. В тази част ние обхващаме две допълващи се дисциплини: оценка (систематично измерване на качеството на модела) и мониторинг (постоянен мониторинг на модела в производството). Особено в LLM системите, eval е по-трудно и изисква повече внимание от класическия ML.
Защо производственият модел тихо се разпада
Бъг се срива, регистрационният файл се отпечатва, алармата изгасва. Един ML модел, от друга страна, може да е грешен, без да причинява грешки. Три основни причини за деградация:
- Дрейф на данните: Разпределението на входните данни се променя с времето (нови продукти, променящо се потребителско поведение, сезонност). Моделът остава същият, но светът се променя.
- Дрейф на концепцията: Връзката вход-изход се променя. Тактиките за измами и моделите за спам се развиват; Това, което вчера беше правилно, днес ще бъде грешно.
- Повреда нагоре по веригата: Източник на данни променя формата, област става свободна; Моделът тихо се лигави с повреден вход.
Проследяването прави тези тихи изкривявания чуваеми.
Какво да гледате: три слоя
Добрият мониторинг обхваща три слоя:
- Оперативни показатели: латентност, процент грешки, обем на заявките, използване на ресурси. "Системата стои ли?"
- Данни/входящи показатели: Разпределението на входните данни подобно ли е на това в обучението? Процентът на липсващата стойност се е увеличил? Пристигнаха ли нови категории? „Моделът вижда ли познати данни?“
- Модел/изходни показатели: Дневник за разпространение на прогнози? Резултатите за доверие спаднаха ли? И ако е възможно, каква е точността в сравнение с основната истина? „Моделът все още ли е точен?“
Третият слой е най-ценният, но най-трудният; тъй като реалният резултат обикновено идва със закъснение (става ясно след месеци дали кредитът ще бъде върнат или не).
Съвет: Ако действителният резултат се забави, първо наблюдавайте разпределението на входа и прогнозата. Изместването на входното разпределение е ранен признак за влошаване на точността и може да предизвика аларма, без да се чака действителният резултат.
Оценяване на LLM системи: специалното предизвикателство
В класическия ML "правилният отговор" е ясен (клас 0 или 1). Резултатът от LLM, от друга страна, е с отворен край: може да има много верни отговори на един и същи въпрос, „коректността“ не се побира в едно число. Подходи за оценка на LLM:
- Референтни показатели: Сравняване на резултата с идеалния отговор. ограничено; защото може да приеме правилния отговор, изразен по различен начин, като "грешен".
- Проверки, базирани на правила: Изходът валиден ли е JSON? Има ли забранени думи? Съдържа ли желаните полета? Евтини, надеждни, стегнати.
- LLM-съдия (LLM-as-judge): Не карайте модела да пита „този отговор добър ли е според този критерий?“ Мащабира, но самият рефер трябва да бъде проверен.
- Човешки преглед: Златен стандарт, но скъп и бавен. Използва се върху пробата.
На практика те се използват заедно: евтини проверки на правила за всеки изход, LLM-съдия върху голяма извадка, човешка оценка върху малка, но строга извадка.
Слаб подход / Силен подход
Слаб: „LLM-Попитах рефера, 92% от нашите отговори бяха добри. Системата е страхотна.“
Güçlü: „Първо маркирахме 100 разпечатки от хора. Пуснахме LLM-съдията на същите 100 разпечатки и измерихме съгласието между хора и съдии — 85% съгласие, приемливо. Документирахме къде съдията систематично греши (склонност да намира дългите отговори за нечестно добри) и поправихме неговата подкана. Едва тогава се доверихме на оценките на съдията.“
Разликата: силният подход проверява рефера с човешка котва, а не сляпо. Непроверен референтен LLM дава добре изглеждащ, но фалшива увереност.
Внимание: LLM-referee също е модел; халюциногенен, предубеден (предпочита дълги/уверени отговори), може да бъде непоследователен. Калибрирайте резултатите на съдиите с човешки маркери, преди да вземете производствени решения.
Комплект за оценка: внимателно проектиран
Добрият комплект за оценка представя разнообразието от реална употреба и трудни случаи. Една оценка, пълна само с лесни примери, ще ви остави в фалшива увереност. Не забравяйте да го поставите в клъстера eval:
- Крайни случаи: Празен вход, много дълъг вход, необичаен формат.
- Известни трудни случаи: Примери, при които моделът е допуснал грешки в миналото (като регресионен тест).
- Инциденти със сигурността: Бързи опити за инжектиране, злонамерени заявки, капани за нарушаване на поверителността.
Eval клъстерът нараства с течение на времето: всеки нов бъг, който хванете в производството, се превръща в тестов случай за следващата оценка.
Аларма и интервенция
Наблюдението остава непълно без аларма. Трябва да има праг и план за реакция за всеки важен показател: „Уведомете инженера, ако отклонението на входа надвиши X“, „Автоматично връщане назад, ако процентът на грешки надвиши Y“. Поддържайте алармите значими – твърде много фалшиви аларми десенсибилизират екипа и ги карат да пропуснат истинската аларма.
три мини калъфа
Случай 1 - Ранно предупреждение. Истинската точност на модела за прогнозиране на търсенето стана очевидна едва в края на седмицата. Екипът наблюдаваше разпределението на входа и видя внезапното нарастване на нова продуктова категория във вторник - нещо, което моделът никога не беше виждал. Те актуализираха модела, без да чакат спад на точността. Мониторинг на въвеждане на запазени дни.
Случай 2 - Непроверен рефер. Един екип съобщи, че „нашето качество е отлично“ въз основа на LLM-рецензент. Когато оплакванията на клиентите се увеличиха, беше въведено наблюдение от хора: реферът отчиташе уверените, но неправилни отговори като „добри“. След като реферът беше калибриран с човешки етикети, истинското качество беше разкрито и беше много по-ниско. Урок: не се доверявайте на рефера, без да сте го проверили.
Случай 3 – Регресионно тестване. Бързата промяна разреши един проблем, докато тихо разби друг. Но екипът запази минали грешки в кофата за оценка; Когато новата промяна беше тествана на този клъстер, счупеният случай беше незабавно уловен и промяната беше коригирана. Урок: всеки фиксиран бъг трябва да се превърне в постоянен тестов случай.
Копируеми шаблони
Създайте план за проследяване за този производствен модел. Покрийте три слоя: 1) Оперативен (латентност, процент грешки, обем) 2) Вход/данни (промяна на разпределението, липсваща стойност, нова категория) 3) Модел/изход (разпределение на прогнозата, увереност, точност, ако е възможно) Модел: [описание]. Колко време отнема да пристигне действителният резултат: [продължителност]Добавете праг и препоръка за намеса за всеки показател.
Предложете стратегия за оценка (оценка) за тази LLM система. Задача: [описание]Определяне на слоеве: - Кои проверки, базирани на правила, трябва да се изпълняват за всеки изход? - Какви критерии трябва да оцени LLM-арбитърът и как трябва да бъдат валидирани (човешка котва)? - В коя извадка трябва да се извърши човешка оценка? Избройте крайните и безопасни случаи, които трябва да поставя в набора за оценка.
Проверете тази подкана за рецензент на LLM: - Критериите за оценка ясни или субективни ли са? - Склонен ли е към пристрастност в дължината/доверието? - Как да калибрирам рефера с човешки маркери? Подкана за рефера: [подкана]
Напишете сборник за отговор за тази мониторингова аларма. Аларма: [напр. input drift threshold exceeded]Трябва да съдържа: първоначални стъпки за контрол, възможни причини, критерии за връщане назад, кого да информирате.
Таблица на причините за влошаване
изкривяване
симптом
Начин за ранно откриване
отклонение на данните
Промени в разпределението на входа
Мониторинг на входното разпределение
промяна на концепцията
Правдата пада тихо
Прогноза + действително сравнение
грешка нагоре по веригата
Полетата се освобождават/форматът се променя
Проверка на схема + липсващ процент
Несъответствие на модела
Промени в разпределението на продукцията
Мониторинг на разпределението на изхода
Често срещани грешки
- Без установяване на мониторинг. Моделът се разваля тихо, никой не го вижда.
- Проследявайте само оперативни показатели. Системата работи, но прогнозите може да са грешни.
- Използване на LLM без проверка на рефера. Дава фалшива увереност.
- Оценка с лесни примери. Това не показва истинска трудност.
- Без да се включват минали грешки в eval. Същата грешка се връща отново.
- Силни аларми. Екипът става десенсибилизиран, пропускайки истинската аларма.
В обобщение
Моделът може да бъде неточен, без да причинява грешки в производството; така че оценката и мониторингът са също толкова важни, колкото и развитието. Установете мониторинг на три нива (оперативен, входен, изходен); Използвайте отклонение на входа като ранно предупреждение, ако действителният резултат се забави. В LLM системите eval е отворен; Използвайте проверки на правилата, LLM-референт и човешка оценка заедно – но не забравяйте да валидирате LLM-референт с човешка котва. Обогатете своя Eval клъстер с крайни и защитни случаи и превърнете всяка уловена грешка в постоянен тестов случай.
Задача за приложение
Напишете трислоен план за наблюдение за производствен (или почти производствен) модел и дефинирайте праг + аларма за поне един показател за разпределение на входа. Ако имате LLM система: маркирайте 30 изхода с хора, изпълнете LLM-референт на същите изходи и измерете съгласието между човек и референт; Обърнете внимание на систематичното пристрастие на рефера. Добавете поне 3 ръба и 2 защитни случая към вашия eval клъстер.
контролен списък
- [ ] Мониторингът обхваща всичките три слоя (оперативен, входен, изходен).
- [ ] Използвам отклонение на входа като ранно предупреждение, ако действителният резултат се забави.
- [ ] Калибрирах LLM-арбитъра с човешки етикети.
- [ ] Клъстерът Eval съдържа крайни и защитни случаи.
- [ ] Превърнах всяка грешка, която хванах, в постоянен тестов случай.
- [ ] Всеки важен показател има праг и план за отговор.