Добивки:
- Способност да се дефинираат метрика кои ги следат сигналите за користење, безбедност, квалитет и перформанси
- Способност да се открие промена на квалитетот на излезот со основна линија и земање примероци
- Способност за поставување аларм и јамка за повратни информации за аномалии и бранови на џеилбрејк
Ставањето на системот за вештачка интелигенција во производство е почеток, а не крај. Дури и ако моделот остане ист, светот се менува: однесувањето на корисниците, дојдовните податоци, техниките за напад и деловниот контекст постојано се менуваат. Вчерашниот точен одговор може да биде погрешен денес. Значи, последниот столб на безбедноста е континуирано следење и набљудување - способност да се види однадвор што се случува внатре во системот. Во оваа единица, ќе научиме кои метрики да ги следиме, како да го доловиме поместувањето на квалитетот на излезот и како да предупредуваме за аномалии.
Зошто континуирано следење?
Во класичниот софтвер, „дали работи“ е бинарно прашање: или одговара или не. Во вештачката интелигенција, додека системот изгледа дека „работи“, тој може тивко да се влошува: одговорите полека стануваат неточни, трошоците ескалираат, обидите за џеилбрејк се зголемуваат. Единствениот начин да се фатат овие е постојано мерење на вистинските сигнали.
Внимание: Најопасниот дефект е тивкиот, а не бучниот. Системот не фрла грешки, неговиот квалитет само се намалува. Ако не поставите мониторинг, првиот што ќе забележи ќе биде вашиот клиент или ревизор, а не вие.
Четири сигнални семејства за гледање
- Употреба и цена: волумен на барање, потрошувачка на токени, цена по корисник. Ненадеен скок; Тоа може да биде знак за злоупотреба, нејасна интеграција или прекинувач што протекува.
- Безбедносни сигнали: џеилбрејк/обиди за вбризгување, одбиени повици на возилото, грешки во овластувањето. Зголемувањето може да укаже на активна кампања за напад.
- Квалитет и дрифт: Намалување на квалитетот на излезот со текот на времето (дрифт). На пример, стапка на премин на верификација, стапка на корекција во човечкото одобрување, задоволство на корисникот.
- Перформанси: латентност, стапка на грешки, истек на време. Тоа директно влијае на корисничкото искуство и цената.
Што е Drift и како да се фати?
Drift е кога квалитетот на влезовите или излезите на моделот се менува незабележано со текот на времето. Постојат два вида: префрлање на податоци (дистрибуцијата на дојдовните барања се менува - нова тема, нов јазик) и префрлање на квалитетот (излезот за истата работа постепено се влошува). Потребна е основна линија за да се доловат: запишете го нормалниот опсег на метрика кога системот е здрав; Нека отстапувањето стане аларм.
Чекор по чекор: Поставување мониторинг
- Измерете ја основната линија. Запишете го нормалниот опсег на секој сигнал кога системот е здрав.
- Дефинирајте праг и аларм. Кое отстапување ќе предупреди кого и како?
- Земање примероци + човечка инспекција. Редовно нека прегледа примерок од резултатите од човек (наместувањето на квалитетот често е само видливо).
- Инсталирајте контролна табла. Следете четири семејства на сигнали на еден екран.
- Јамка за повратни информации. Поврзете ги наодите од мониторингот до подобрувањето на брзата/контрола.
Четири шаблони за копирање
Прашање за евалуација на земање примероци за квалитет (следење на лебдењето со LLM-as-judge):
Подолу се 20 случаен печатење од оваа недела. Оценете го секој како „добро / прифатливо / лошо“ и напишете кратко оправдување. Конечно ќе ја споредам лошата стапка со минатонеделната стапка; Ако има шема (повторување на истиот тип на грешка) што се истакнува оваа недела, означете ја.<outputs>{{ примери }}</outputs>
Промоција за резиме на аномалија:
Испитајте ги следните дневни метрики: број на барања, токени, цена, одбиен повик на алатката, обиди за џеилбрејк, просечна латентност. Означете ја секоја метрика што отстапува повеќе од 30% од основната линија како „ANOMALIT“ и проценете ја можната причина (напад, грешка, злоупотреба).<metrics>{{ daily_data }}</metrics>
Правило за дефиниција на прагот на аларм:
Дефинирајте аларми за секој сигнал: - цена: ако надминува 2x дневен просек -> предупредување со висок приоритет- Обиди за џеилбрејк: ако надминува 10 на час -> известете го безбедносниот тим- Стапка на премин на верификација: ако падне под 90% -> преглед на квалитетот- Латентност: ако p95 ја надмине целта за 2x -> преглед на перформансите
Промоција за истражување на дрифт:
Стапката на пропусници за верификација падна од 94% на 78% во последните 2 недели. Помогнете ми да одговорам на овие прашања: (1) Дали се појави нова тема/јазик/формат во дојдовните барања? (2) Дали грешките се концентрирани во одредена категорија? (3) Дали тајмингот се совпаѓа со промена на барање/модел/алатка? Наведете ги податоците што треба да се проверат за секој од нив.
Слаба навестување / Силен навестување
лош пристап
Силен пристап
„Ако има грешка, ќе видиме“
Основна линија + праг + проактивен аларм
Само проверете дали системот стои.
Следење на четири фамилии на сигнали (користење, безбедност, квалитет, перформанси)
Воопшто не се зема примерок од квалитетот на излезот
Редовно земање примероци од луѓе + LLM-како судија
Не собирање и гледање на метрика
Контролна табла + циклус за повратни информации
Три мини футроли
Случај 1 - Алармот за трошоци го фати клучот што протекува. Дневниот токен на една компанија тројно се зголеми преку ноќ. Алармот за праг го предупредил безбедносниот тим; истрагата покажа дека протече клуч за тестирање и користен од бот. Клучот беше отповикан за 25 минути; Да немаше аларм, сметката ќе беше забележана на крајот на месецот.
Случај 2 - Тивко дрифт на квалитетот. Стапката на верификација на помошникот за поддршка тивко падна од 95% на 80% за три недели. Неделното земање примероци го доловува ова; Причината беше што клиентите почнаа да прашуваат за нова производна линија и базата на знаење на моделот за неа беше нецелосна. Стапката се врати кога се ажурираше базата на знаење.
Случај 3 - Бранот на џеилбрејк беше рано. Обидите за инјектирање на асистент се зголемија од 2 на 40 на час во еден ден. Активиран безбедносен аларм; Се виде дека на форум е споделен „рецепт“ за пукање на системот. Тимот ги ажурираше информациите за одбраната и ги ограничи сомнителните сметки; Бранот згасна пред да се претвори во вистинско истекување.
Совет: не се задоволувајте само со машински метрика. Надминувањето на квалитетот често се забележува со само читање на резултатите од примерокот од човек. Мала рутина на прегледување на 15-20 случајни отпечатоци неделно ќе ги фати најскапите тивки неуспеси рано.
Вообичаени грешки
- Не ставање во производство и поставување на мониторинг („работи, во ред“).
- Неможност да се идентификува аномалијата без мерење на основната линија.
- Недостасува квалитетот на лебдат со само гледање на "дали тоа стои".
- Воопшто не се зема примерок од квалитетот на излезот преку човечки очи.
- Не алармирање и откривање на проблемот од клиентот/надзорникот.
- Не поврзување на наодите од мониторингот со подобрување (без повратна врска).
Сумирано
- Системите за вештачка интелигенција можат тивко да се влошат; Најопасниот дефект е оној што не фрла грешки, туку само го намалува квалитетот.
- Следете четири фамилии на сигнали: употреба/трошок, безбедност, квалитет/лифт и перформанси.
- Drift (наносот на квалитетот на влезот или излезот со текот на времето) се забележува само во споредба со основната линија.
- Редовното земање примероци од луѓе, како дополнување на машинската метрика, го доловува наносот на квалитетот.
- Поврзете го мониторингот со алармот и јамката за повратни информации; Мерењето и не гледањето не е следење.
Задача за апликација
Изберете барем една метрика од секоја од четирите семејства на сигнали за вашиот сопствен систем за вештачка интелигенција и запишете ги нивните сегашни (или проценети) основни линии. Дефинирајте праг за аларм за секоја метрика. Потоа земете 15 од резултатите од вашиот последен семестар и дадете ги со горенаведеното барање за земање примероци; Забележете ја „лошата“ стапка. Нека ова биде вашата прва основна линија со која ќе го споредите дрифтот во иднина.
листа за проверка
- [ ] Дефинирав метрика од четири семејства на сигнали (користење, безбедност, квалитет, перформанси).
- [ ] Поставив основна линија и праг на аларм за секоја метрика.
- [ ] Редовно го тестирам квалитетот на излезот преку човечки очи.
- [ ] Ги следам сигналите на еден екран со панел за приказ.
- [ ] Алармот оди до безбедносниот тим за аномалии и бранови на џеилбрејк.
- [ ] Наодите од мониторингот ги припишувам на подобрувањето на брзата/контрола.