Краток одговор: За добро да се евалуираат моделите со вештачка интелигенција, започнете со дефинирање како изгледа „добро“ за реалниот корисник и за донесената одлука. Потоа изградете повторувачки евалуации со репрезентативни податоци, строги контроли на протекување и повеќе метрики. Додадете проверки за стрес, пристрасност и безбедност, и секогаш кога нешто ќе се промени (податоци, барања, политика), повторно стартувајте го системот и продолжете со следење по лансирањето.
Клучни заклучоци:
Критериуми за успех : Дефинирајте ги корисниците, одлуките, ограничувањата и најлошите можни неуспеси пред да изберете метрики.
Повторливост : Изградете систем за евалуација што повторува споредливи тестови со секоја промена.
Хигиена на податоци : Одржувајте стабилни поделби, спречувајте дупликати и рано блокирајте го истекувањето на функциите.
Проверки на доверба : робусност на стрес-тестови, делови од праведност и безбедносно однесување на LLM со јасни рубрики.
Дисциплина на животниот циклус : Воведување во фази, следење на отстапувањата и инцидентите и документирање на познатите празнини.
Статии што можеби ќе ве интересираат по оваа:
🔗 Што е етика на вештачката интелигенција
Истражете ги принципите што го водат одговорниот дизајн, употреба и управување со вештачката интелигенција.
🔗 Што е пристрасност на вештачката интелигенција
Дознајте како пристрасните податоци ги искривуваат одлуките и резултатите од вештачката интелигенција.
🔗 Што е скалабилност на вештачката интелигенција
Разберете го скалирањето на системите со вештачка интелигенција за перформанси, цена и сигурност.
🔗 Што е вештачка интелигенција
Јасен преглед на вештачката интелигенција, видовите и нивната употреба во реалниот свет.
1) Започнете со негламурозната дефиниција за „добро“
Пред метрики, пред контролни табели, пред какво било флексибилно одредување на реперните вредности - одлучете како изгледа успехот.
Појасни:
-
Корисникот: внатрешен аналитичар, клиент, клиничар, возач, уморен агент за поддршка во 16 часот…
-
Одлуката: одобрување на заем, пријавување на измама, предлагање содржина, сумирање на белешки
-
Најважните неуспеси:
-
Лажно позитивни (досадни) наспроти лажно негативни (опасни)
-
-
Ограничувања: латентност, цена по барање, правила за приватност, барања за објаснување, пристапност
Ова е делот каде што тимовите се спуштаат кон оптимизирање за „прилично добра метрика“ наместо за „значаен исход“. Тоа се случува често. Како… многу.
Солиден начин да се одржи ова ниво на свесност за ризикот (а не врз основа на вибрации) е тестирањето да се насочи кон доверливоста и управувањето со ризикот од животниот циклус, на начин на кој NIST го прави тоа во Рамката за управување со ризик од вештачка интелигенција (AI RMF 1.0) [1].
2) Што ја прави една верзија на „како да се тестираат модели со вештачка интелигенција“ добра ✅
Солидниот пристап кон тестирање има неколку неспорни карактеристики:
-
Репрезентативни податоци (не само чисти лабораториски податоци)
-
Јасни расцепи со спречување на протекување (повеќе за тоа за секунда)
-
Основни линии (едноставни модели што треба да ги прескокнете - фиктивните проценувачи постојат со причина [4])
-
Повеќе метрики (бидејќи една бројка ве лаже, учтиво, во лице)
-
Стрес тестови (екстремни случаи, необични влезни податоци, конфликтни сценарија)
-
Човечки прегледни јамки (особено за генеративни модели)
-
Мониторинг по лансирањето (бидејќи светот се менува, цевководите се расипуваат, а корисниците се… креативни [1])
Исто така: добар пристап вклучува документирање на она што сте го тестирале, она што не сте го направиле и за што сте нервозни. Делот „за што сум нервозен“ се чувствува незгодно - и тука е местото каде што почнува да се стекнува доверба.
Два шаблони на документација кои постојано им помагаат на тимовите да останат искрени:
-
Модел картички (за што служи моделот, како е оценет, каде не успева) [2]
-
Листови со податоци за множества податоци (што претставуваат податоците, како се собрани, за што треба/не треба да се користат) [3]
3) Реалноста на алатките: што луѓето користат во пракса 🧰
Алатките се опционални. Добрите навики за евалуација не се.
Ако сакате прагматична поставеност, повеќето тимови завршуваат со три кофи:
-
Следење на експерименти (вршења, конфигурации, артефакти)
-
Евалуациски пакет (повторливи офлајн тестови + регресивни пакети)
-
Мониторинг (сигнали за отстапување, посредништво за перформанси, предупредувања за инциденти)
Примери што ќе ги видите многу често (не препораки, и да - промени во карактеристиките/цените): MLflow, Weights & Biases, Great Expectations, Evidently, Deepchecks, OpenAI Evals, TruLens, LangSmith.
Ако изберете само една идеја од овој дел: изградете повторувачки систем за евалуација . Сакате „притиснете копче → добијте споредливи резултати“, а не „повторете го тефтерот и молете се“.
4) Изградете го вистинскиот тест сет (и престанете да протекувате податоци) 🚧
Шокантен број „неверојатни“ модели случајно изневеруваат.
За стандарден ML
Неколку несекси правила што спасуваат кариери:
-
Одржувајте ги за обука/валидација/тест (и запишете ја логиката на поделби)
-
Спречете дупликати низ поделбите (ист корисник, ист документ, ист производ, речиси дупликати)
-
Внимавајте на протекување на функции (идни информации што се провлекуваат во „тековните“ функции)
-
Користете основни линии (лажни проценувачи) за да не славите победа… ништо [4]
Дефиниција за истекување (брзата верзија): сè во обуката/евалуацијата што му дава на моделот пристап до информации што не би ги имал во времето на донесување одлука. Може да биде очигледно („идна етикета“) или суптилно („кофа за временска ознака по настанот“).
За LLM и генеративни модели
Градите систем на поттикнување и политика , а не само „модел“.
-
Креирај златен сет на инструкции (мали, висококвалитетни, стабилни)
-
Додајте неодамнешни вистински примероци (анонимизирани + безбедни за приватноста)
-
Чувајте пакет со мали и средни букви : печатни грешки, сленг, нестандардно форматирање, празни внесувања, повеќејазични изненадувања 🌍
Практична работа што сум ја видел да се случува повеќе од еднаш: тим испорачува со „силен“ офлајн резултат, а потоа корисничката поддршка вели: „Супер. Со сигурност ја промашува едната реченица што е важна.“ Решението не беше „поголем модел“. Тоа беа подобри тест-програми , појасни рубрики и регресивен пакет што го казнуваше токму тој режим на неуспех. Едноставно. Ефикасно.
5) Офлајн евалуација: метрики што значат нешто 📏
Метриките се во ред. Метричката монокултура не е.
Класификација (спам, измама, намера, тријажа)
Користете повеќе од точност.
-
Прецизност, отповик, F1
-
Подесување на прагот (вашиот стандарден праг ретко е „точен“ за вашите трошоци) [4]
-
Матрици на конфузија по сегмент (регион, тип на уред, корисничка кохорта)
Регресија (прогнозирање, одредување цени, бодување)
-
MAE / RMSE (изберете врз основа на тоа како сакате да ги казните грешките)
-
Калибрациски проверки кога излезните податоци се користат како „оценки“ (дали резултатите се совпаѓаат со реалноста?)
Системи за рангирање / препораки
-
НДЦГ, МАП, МРР
-
Сечење според тип на барање (глава наспроти опашка)
Компјутерски вид
-
mAP, IoU
-
Перформанси по класа (ретките класи се таму каде што моделите ве засрамуваат)
Генеративни модели (LLM)
Тука луѓето почнуваат… филозофски 😵💫
Практични опции што функционираат во реални тимови:
-
Човечка евалуација (најдобар сигнал, најбавна јамка)
-
Паровидна преференција / стапка на победа (А наспроти Б е полесно отколку апсолутно бодување)
-
Автоматизирани текстуални метрики (корисни за некои задачи, погрешни за други)
-
Проверки засновани на задачи: „Дали ги извлече точните полиња?“ „Дали ја следеше политиката?“ „Дали цитираше извори кога беше потребно?“
Ако сакате структурирана референтна точка за „мултиметрија, повеќе сценарија“, HELM е добра основа: експлицитно ја турка евалуацијата подалеку од точноста во работи како што се калибрација, робусност, пристрасност/токсичност и компромиси за ефикасност [5].
Мала дигресија: автоматизираните метрики за квалитет на пишување понекогаш се како да се процени сендвич со мерење. Не е ништо, но… ајде 🥪
6) Тестирање на робусност: малку потрудете се 🥵🧪
Ако вашиот модел работи само на уредни влезови, тоа е всушност стаклена вазна. Убава, кршлива, скапа.
Тест:
-
Шум: печатни грешки, недостасувачки вредности, нестандарден уникод, грешки во форматирањето
-
Промена на дистрибуцијата: нови категории на производи, нов сленг, нови сензори
-
Екстремни вредности: броеви надвор од опсегот, гигантски носивост, празни низи
-
„Противкандидатски“ влезни податоци кои не личат на вашиот сет за обука, но изгледаат како корисници
За LLM, вклучете:
-
Брзи обиди за инјектирање (инструкции скриени во содржината на корисникот)
-
Шеми „Игнорирај ги претходните инструкции“
-
Случаи на употреба на алатки (лоши URL-адреси, истекување на време, делумни излези)
Робусноста е едно од оние својства на доверливост што звучи апстрактно сè додека не се случат инциденти. Потоа станува… многу опипливо [1].
7) Пристрасност, праведност и за кого функционира ⚖️
Еден модел може да биде „точен“ во целина, а сепак постојано да биде полош за одредени групи. Тоа не е мала грешка. Тоа е проблем со производот и довербата.
Практични чекори:
-
Оценување на перформансите според значајни сегменти (правно/етички соодветно за мерење)
-
Споредете ги стапките на грешки и калибрацијата меѓу групите
-
Тестирајте за функции на прокси (поштенски код, тип на уред, јазик) што можат да кодираат чувствителни карактеристики
Ако не го документирате ова некаде, во основа барате од „иднината“ да дебагирате криза на доверба без мапа. Модел картичките се солидно место за да го поставите тоа [2], а рамката за доверливост на NIST ви дава силна листа за проверка на тоа што „доброто“ воопшто треба да вклучува [1].
8) Тестирање за безбедност и сигурност (особено за LLM) 🛡️
Ако вашиот модел може да генерира содржина, тестирате повеќе од точност. Тестирате однесување.
Вклучете тестови за:
-
Недозволено генерирање содржина (прекршувања на политиката)
-
Протекување на приватноста (дали открива тајни?)
-
Халуцинации во домени со висок ризик
-
Прекумерно одбивање (моделот ги одбива нормалните барања)
-
Резултати од токсичност и вознемирување
-
Обиди за ексфилтрација на податоци преку брза инјекција
Еден заснован пристап е: дефинирање правила на политиката → креирање тест-програми → бодување на резултатите со човечки + автоматизирани проверки → извршување секој пат кога нешто ќе се промени. Тој дел „секој пат“ е киријата.
Ова совршено се вклопува во начинот на размислување за ризик од животниот циклус: управувај, мапирај контекст, мери, управувај, повторувај [1].
9) Онлајн тестирање: постепено воведување (каде што живее вистината) 🚀
Офлајн тестовите се неопходни. Онлајн изложеноста е местото каде што реалноста се појавува носејќи калливи чевли.
Не мора да бидете префинети. Само треба да бидете дисциплинирани:
-
Работи во режим на сенка (моделот работи, не влијае на корисниците)
-
Постепено воведување (прво мал сообраќај, проширување ако е во ред)
-
Следење на исходи и инциденти (жалби, ескалации, неуспеси во политиките)
Дури и ако не можете да добиете моментални етикети, можете да ги следите прокси сигналите и оперативното здравје (латентност, стапки на дефекти, трошоци). Главната поента: сакате контролиран начин да откриете дефекти пред да го стори тоа целата ваша корисничка база [1].
10) Мониторинг по распоредувањето: дрифт, распаѓање и тивок дефект 📉👀
Моделот што го тестиравте не е моделот со кој на крајот живеете. Податоците се менуваат. Корисниците се менуваат. Светот се менува. Цевководот се прекинува во 2 часот наутро. Знаете како е..
Монитор:
-
Поместување на влезните податоци (промени во шемата, недостаток, поместувања во распределбата)
-
Поместување на излезот (промени во рамнотежата на класите, промени во резултатите)
-
Прокси за перформанси (бидејќи доцнењата на етикетите се реални)
-
Сигнали за повратни информации (палецот надолу, повторни измени, ескалации)
-
Регресии на ниво на сегмент (тивки убијци)
И поставете прагови на алармирање кои не се премногу треперливи. Монитор кој постојано вреска се игнорира - како аларм во автомобил во град.
Оваа јамка „следење + подобрување со текот на времето“ не е опционална ако ви е важна доверливоста [1].
11) Практичен работен тек што можете да го копирате 🧩
Еве едноставна јамка што се скалира:
-
Дефинирајте ги начините на успех + неуспех (вклучете трошоци/латенција/безбедност) [1]
-
Креирај податочни групи:
-
златен сет
-
пакет со рабови
-
неодамнешни вистински примероци (безбедни за приватност)
-
-
Изберете метрики:
-
метрики за задачи (F1, MAE, стапка на победа) [4][5]
-
метрики за безбедност (стапка на положување на политика) [1][5]
-
оперативни метрики (латентност, цена)
-
-
Изградете систем за евалуација (работи на секој модел/промена на налог) [4][5]
-
Додајте стрес тестови + тестови со контрадикторност [1][5]
-
Човечки преглед за примерок (особено за излезни резултати од LLM) [5]
-
Испорака преку сенка + постепено лансирање [1]
-
Мониторинг + алармирање + преквалификација со дисциплина [1]
-
Документот резултира во запис во стил на картичка за модел [2][3]
Обуката е гламурозна. Тестирањето е нешто што плаќа заработка.
12) Заклучоци + краток преглед 🧠✨
Ако се сеќавате само на неколку работи за тоа како да тестирате модели со вештачка интелигенција :
-
Користете репрезентативни податоци од тестови и избегнувајте протекување [4]
-
Изберете повеќе метрики поврзани со реални резултати [4][5]
-
За LLM, потпрете се на човечки преглед + споредби на стилови на победа [5]
-
Тест робусност - необични влезни податоци се нормални влезни податоци во маска [1]
-
Безбедно тркалајте и следете, бидејќи моделите се поместуваат и цевките се кршат [1]
-
Документирајте што сте тестирале и што не (непријатно, но моќно) [2][3]
Тестирањето не е само „докажување дека функционира“. Туку „откријте како не успева пред вашите корисници да го сторат тоа“. И да, тоа е помалку секси - но тоа е делот што го одржува вашиот систем исправен кога работите ќе се нестабилизираат… 🧱🙂
Најчесто поставувани прашања
Најдобар начин за тестирање на моделите со вештачка интелигенција за да одговараат на реалните потреби на корисниците
Започнете со дефинирање на „добро“ во однос на реалниот корисник и одлуката што ја поддржува моделот, а не само метрика на табелата со резултати. Идентификувајте ги режимите на неуспех со највисока цена (лажни позитивни наспроти лажни негативни) и наведете строги ограничувања како што се латентност, цена, приватност и објаснување. Потоа изберете метрики и тест случаи што ги одразуваат тие резултати. Ова ве спречува да оптимизирате „убава метрика“ што никогаш не се претвора во подобар производ.
Дефинирање на критериуми за успех пред избор на метрики за евалуација
Запишете кој е корисникот, каква одлука треба да поддржи моделот и како изгледа „најлошиот случај на неуспех“ во производството. Додадете оперативни ограничувања како што се прифатлива латентност и цена по барање, плус потреби за управување како што се правила за приватност и политики за безбедност. Откако тие ќе бидат јасни, метриките стануваат начин за мерење на правилното нешто. Без тоа обликување, тимовите имаат тенденција да се свртат кон оптимизирање на она што е најлесно за мерење.
Спречување на истекување на податоци и случајно мамење при евалуација на моделот
Одржувајте ги стабилните поделби за обука/валидација/тестирање и документирајте ја логиката на поделбите за да можат резултатите да се репродуцираат. Активно блокирајте ги дупликатите и речиси дупликатите низ поделбите (ист корисник, документ, производ или повторени шеми). Внимавајте на протекување на функции каде што „идните“ информации се лизгаат во влезните податоци преку временски ознаки или полиња по настанот. Силната основна линија (дури и лажни проценувачи) ви помага да забележите кога славите бучава.
Што треба да вклучува еден систем за евалуација за тестовите да останат повторливи низ промените
Практична опрема повторува споредливи тестови на секој модел, прашање или промена на политиката користејќи ги истите бази на податоци и правила за бодување. Обично вклучува пакет за регресија, јасни контролни табли со метрики и складирани конфигурации и артефакти за следливост. За LLM системите, потребен е и стабилен „златен сет“ на прашања плус пакет со краеви. Целта е „притиснете копче → споредливи резултати“, а не „повторете ја тетратката и помолете се“
Метрики за тестирање на моделите со вештачка интелигенција над точноста
Користете повеќе метрики, бидејќи еден единствен број може да прикрие важни компромиси. За класификација, спарете прецизност/потсетување/F1 со матрици за подесување на прагот и конфузија по сегмент. За регресија, изберете MAE или RMSE врз основа на тоа како сакате да ги казните грешките и додадете проверки во стилот на калибрација кога излезите функционираат како резултати. За рангирање, користете NDCG/MAP/MRR и исечете по прашања за глава наспроти опашка за да ги забележите нееднаквите перформанси.
Евалуација на резултатите од LLM кога автоматизираните метрики не се доволни
Третирајте го како систем на прашања и политики и оценувајте го однесувањето, а не само сличноста на текстот. Многу тимови комбинираат човечка евалуација со парни преференции (стапка на победа A/B), плус проверки базирани на задачи како „дали ги извлече точните полиња“ или „дали ја следеше политиката“. Автоматизираните метрики за текст можат да помогнат во тесни случаи, но честопати пропуштаат она што им е важно на корисниците. Јасните рубрики и регресивниот пакет обично се поважни од еден единствен резултат.
Тестови за робусност за да се извршат за моделот да не се расипува при бучни влезни сигнали
Тестирајте го моделот со печатни грешки, недостасувачки вредности, чудно форматирање и нестандарден уникод, бидејќи вистинските корисници ретко се уредни. Додадете случаи на промена на дистрибуцијата како што се нови категории, сленг, сензори или јазични шеми. Вклучете екстремни вредности (празни низи, огромни оптоварувања, броеви надвор од опсегот) за да го покажете кршливото однесување. За LLM, тестирајте ги и шемите за инјектирање на промпти и грешките при користење на алатките како што се истекување на време или делумни излези.
Проверка на проблеми со пристрасност и фер игра без да се изгубиме во теорија
Оценете ги перформансите на значајни делови и споредете ги стапките на грешки и калибрацијата низ групите каде што е законски и етички соодветно да се мери. Побарајте прокси карактеристики (како поштенски број, тип на уред или јазик) кои можат индиректно да кодираат чувствителни карактеристики. Моделот може да изгледа „точен во целина“, а сепак постојано да не успева за одредени кохорти. Документирајте што сте измериле, а што не, за идните промени да не воведат тивко регресии.
Тестови за безбедност и сигурност што треба да се вклучат за генеративна вештачка интелигенција и LLM системи
Тестирајте за недозволено генерирање на содржина, протекување на приватноста, халуцинации во домени со висок ризик и прекумерно одбивање каде што моделот ги блокира нормалните барања. Вклучете обиди за брзо инјектирање и ексфилтрација на податоци, особено кога системот користи алатки или презема содржина. Основан работен тек е: дефинирајте правила за политика, изградете сет на тест-проверки, бодувајте со човечки плус автоматизирани проверки и повторно стартувајте го секогаш кога ќе се променат проверките, податоците или политиките. Доследноста е киријата што ја плаќате.
Воведување и следење на моделите со вештачка интелигенција по лансирањето за да се забележат отстапувања и инциденти
Користете шеми на постепено воведување како што се режим на сенка и постепени рампи на сообраќај за да пронајдете неуспеси пред да ги пронајде целата ваша корисничка база. Следете го отстапувањето на влезот (промени во шемата, недостасоци, промени во дистрибуцијата) и отстапувањето на излезот (промени во резултатите, промени во рамнотежата на класите), плус оперативното здравје како што се латентност и трошоци. Следете ги сигналите за повратни информации како што се уредувања, ескалации и жалби и следете ги регресиите на ниво на сегмент. Кога нешто ќе се промени, повторно стартувајте го истиот систем и продолжете со континуирано следење.
Референци
[1] NIST - Рамка за управување со ризици од вештачка интелигенција (AI RMF 1.0) (PDF)
[2] Мичел и др. - „Моделски картички за известување за модели“ (arXiv:1810.03993)
[3] Гебру и др. - „Листови со податоци за множества податоци“ (arXiv:1803.09010)
[4] scikit-learn - документација за „Избор и евалуација на модели“
[5] Лианг и др. - „Холистичка евалуација на јазични модели“ (arXiv:2211.09110)