Кароткі адказ: вызначце, што азначае «добра» для вашага выпадку выкарыстання, а затым праверце з дапамогай рэпрэзентатыўных, версіяваных падказак і памежных выпадкаў. Спалучайце аўтаматызаваныя метрыкі з ацэнкай па рубрыках, а таксама праверкі бяспекі супернікаў і ўвядзення падказак. Калі абмежаванні кошту або затрымкі становяцца абавязковымі, параўнайце мадэлі па поспеху задачы на выдаткаваны фунт і часе рэагавання p95/p99.
Асноўныя высновы:
Адказнасць : прызначаць выразных уладальнікаў, весці журналы версій і паўторна запускаць ацэнкі пасля любога запыту або змены мадэлі.
Празрыстасць : запішыце крытэрыі поспеху, абмежаванні і выдаткі на няўдачу, перш чым пачаць збіраць балы.
Аўдытабельнасць : падтрымлівайце паўтаральнасць тэставых набораў, пазначаных набораў дадзеных і адсочвайце метрыкі затрымкі p95/p99.
Спрэчнасць : выкарыстоўвайце крытэрыі праверкі чалавекам і вызначаны шлях абскарджання спрэчных вынікаў.
Супраціў злоўжыванням : ін'екцыі з боку чырвонай каманды, далікатныя тэмы і празмерная адмова абараняць карыстальнікаў.
Калі вы выбіраеце мадэль для прадукту, даследчага праекта ці нават унутранага інструмента, вы не можаце проста сказаць «гучыць разумна» і адправіць яе (гл. кіраўніцтва па ацэнцы OpenAI і NIST AI RMF 1.0 ). Вось так вы атрымаеце чат-бота, які ўпэўнена тлумачыць, як разагрэць відэлец у мікрахвалеўцы. 😬
Артыкулы, якія вам могуць спадабацца пасля гэтага:
🔗 Будучыня штучнага інтэлекту: тэндэнцыі, якія фарміруюць наступнае дзесяцігоддзе
Ключавыя інавацыі, уплыў на працоўныя месцы і этыка, на якія варта звярнуць увагу ў будучыні.
🔗 Базавыя мадэлі генератыўнага штучнага інтэлекту, тлумачэнні для пачаткоўцаў.
Даведайцеся, што яны сабой уяўляюць, як іх навучаць і чаму яны важныя.
🔗 Як штучны інтэлект уплывае на навакольнае асяроддзе і спажыванне энергіі.
Даследуйце выкіды, попыт на электраэнергію і спосабы памяншэння забруджвання навакольнага асяроддзя.
🔗 Як сёння працуе маштабаванне з дапамогай штучнага інтэлекту для атрымання больш выразных малюнкаў.
Паглядзіце, як мадэлі дадаюць дэталі, выдаляюць шум і акуратна павялічваюць выявы.
1) Вызначэнне слова «добра» (гэта залежыць ад сітуацыі, і гэта нармальна) 🎯
Перш чым праводзіць якую-небудзь ацэнку, вызначыцеся з тым, як выглядае поспех. Інакш вы ўсё вымераеце і нічога не даведаецеся. Гэта як прынесці рулетку, каб ацаніць конкурс тортаў. Вядома, вы атрымаеце лічбы, але яны вам мала што скажуць 😅
Удакладніць:
-
Мэта карыстальніка : рэзюмэ, пошук, запіс, разважанне, выманне фактаў
-
Кошт няўдачы : няправільная рэкамендацыя фільма — гэта смешна; няправільная медыцынская інструкцыя… не смешна (афармленне рызыкі: NIST AI RMF 1.0 ).
-
Асяроддзе выканання : на прыладзе, у воблаку, за брандмаўэрам, у рэгуляваным асяроддзі
-
Асноўныя абмежаванні : затрымка, кошт запыту, прыватнасць, тлумачальнасць, шматмоўная падтрымка, кантроль тону
Мадэль, якая «лепшая» ў адной працы, можа абярнуцца катастрофай у іншай. Гэта не супярэчнасць, гэта рэальнасць. 🙂
2) Як выглядае надзейная сістэма ацэнкі мадэлі штучнага інтэлекту 🧰
Так, гэта тая частка, якую людзі прапускаюць. Яны бяруць бенчмарк, запускаюць яго адзін раз і на гэтым спыняюцца. Надзейная сістэма ацэнкі мае некалькі паслядоўных рыс (практычныя прыклады інструментаў: OpenAI Evals / OpenAI evals guide ):
-
Паўтаральнасць — вы можаце зноў запусціць яго на наступным тыдні і давяраць параўнанням
-
Тыповыя — яны адлюстроўваюць вашых рэальных карыстальнікаў і задачы (а не толькі дробязі)
-
Шматслаёвы — спалучае аўтаматызаваныя паказчыкі + праверку чалавекам + спаборніцкія тэсты
-
Дзейныя — вынікі паказваюць, што трэба выправіць, а не проста «рэйтынг знізіўся»
-
Абарона ад несанкцыянаванага доступу — прадухіляе «навучанне тэсту» або выпадковую ўцечку
-
Эканамічнае значэнне — сама ацэнка не павінна вас банкрутаваць (калі вы не любіце боль)
Калі ваша ацэнка не вытрымае скептычнага слова калегі па камандзе: «Добра, але перанясі гэта ў прадукцыйную версію», значыць, яна яшчэ не скончана. Гэта праверка вібрацыі.
3) Як ацаніць мадэлі штучнага інтэлекту, пачынаючы з зрэзаў выпадкаў выкарыстання 🍰
Вось хітрасць, якая зэканоміць кучу часу: разбіце выпадак выкарыстання на часткі .
Замест таго, каб «ацаніць мадэль», зрабіце наступнае:
-
Разуменне намеру (ці атрымлівае карыстальнік тое, чаго ён хоча)
-
Выкарыстанне дадзеных або кантэксту (ці правільна выкарыстоўваецца прадастаўленая інфармацыя)
-
Разважанні / шматэтапныя задачы (ці застаецца яно лагічным на працягу ўсіх этапаў)
-
Фарматаванне і структура (ці адпавядае інструкцыям)
-
Узгадненне бяспекі і палітыкі (ці дазваляе гэта пазбегнуць небяспечнага кантэнту; гл. NIST AI RMF 1.0 )
-
Тон і фірмовы голас (ці гучыць гэта так, як вы хочаце)
Дзякуючы гэтаму «Як ацэньваць мадэлі штучнага інтэлекту» больш падобна не на адзін велізарны экзамен, а на набор мэтанакіраваных тэстаў. Тэсты раздражняюць, але з імі можна справіцца. 😄
4) Асновы аўтаномнай ацэнкі — наборы тэстаў, пазнакі і непрыкметныя дэталі, якія маюць значэнне 📦
Афлайн-ацэнка — гэта калі вы праводзіце кантраляваныя тэсты, перш чым карыстальнікі дакранаюцца да чаго-небудзь (шаблоны працоўнага працэсу: OpenAI Evals ).
Збярыце або стварыце набор тэстаў, які сапраўды вам падыдзе
Добры набор тэстаў звычайна ўключае:
-
Залатыя прыклады : ідэальныя вынікі, якія вы б з гонарам адправілі
-
Памежныя выпадкі : неадназначныя падказкі, няправільны ўвод, нечаканае фарматаванне
-
Зонды рэжыму няўдачы : падказкі, якія выклікаюць галюцынацыі або небяспечныя адказы (афармленне рызыкавага тэставання: NIST AI RMF 1.0 )
-
Разнастайнасць ахопу : розныя ўзроўні навыкаў карыстальнікаў, дыялекты, мовы, вобласці
Калі вы тэстуеце толькі «чыстыя» падказкі, мадэль будзе выглядаць цудоўна. Тады вашы карыстальнікі будуць з'яўляцца з памылкамі друку, паўсказамі і энергіяй, якая прымушае іх клікаць. Сардэчна запрашаем у рэальнасць.
Варыянты маркіроўкі (г.зн.: узроўні строгасці)
Вы можаце пазначыць выхады як:
-
Бінарны : прайшоў/не прайшоў (хуткі, рэзкі)
-
Парадкавы : ад 1 да 5 балаў якасці (нюансаваны, суб'ектыўны)
-
Шмататрыбутыўная : дакладнасць, паўната, тон, выкарыстанне цытат і г.д. (лепшы, павольнейшы)
Для многіх каманд шмататрыбутыўная ацэнка — гэта найлепшы варыянт. Гэта як паспрабаваць ежу на смак і ацаніць салёнасць асобна ад тэкстуры. Інакш вы проста кажаце «добра» і паціскаеце плячыма.
5) Паказчыкі, якія не хлусяць — і паказчыкі, якія ў пэўнай ступені хлусяць 📊😅
Паказчыкі каштоўныя... але яны таксама могуць быць сапраўднай бомбай. Бліскучыя, паўсюль і іх цяжка прыбраць.
Распаўсюджаныя сямействы метрык
-
Дакладнасць / дакладнае супадзенне : выдатна падыходзіць для здабывання, класіфікацыі, структураваных задач
-
F1 / дакладнасць / поўнае ўспрыманне : зручна, калі прапусціць нешта горш, чым лішні шум (азначэнні: scikit-learn дакладнасць/паўнае ўспрыманне/F-бал )
-
Перакрыццё стыляў BLEU / ROUGE : падыходзіць для задач тыпу рэзюмэ, часта ўводзіць у зман (арыгінальныя метрыкі: BLEU і ROUGE )
-
Убудаванае падабенства : карысна для семантычнага супадзення, можа ўзнагароджваць няправільныя, але падобныя адказы
-
Узровень паспяховасці задачы : «ці атрымаў карыстальнік тое, што яму было трэба» — залаты стандарт пры правільным вызначэнні
-
Адпаведнасць абмежаванням : адпавядае фармату, даўжыні, валіднасці JSON, прытрымліваецца схемы
Ключавы момант
Калі ваша задача не мае канчатковага канчатку (пісьмо, разважанні, чат падтрымкі), адналікавыя паказчыкі могуць быць… хісткімі. Не бессэнсоўнымі, а проста хісткімі. Вымяраць крэатыўнасць лінейкай можна, але вы будзеце адчуваць сябе недарэчна, робячы гэта. (Акрамя таго, вы, верагодна, выкалеце сабе вока.)
Такім чынам: выкарыстоўвайце метрыкі, але прывязвайце іх да праверкі чалавекам і рэальных вынікаў задачы (адзін прыклад абмеркавання ацэнкі на аснове LLM + агаворкі: G-Eval ).
6) Табліца параўнання — найлепшыя варыянты ацэнкі (з асаблівасцямі, бо ў жыцці ёсць асаблівасці) 🧾✨
Вось практычны набор падыходаў да ацэнкі. Камбінуйце і спалучайце. Большасць каманд так робяць.
| Інструмент / Метад | Аўдыторыя | Кошт | Чаму гэта працуе |
|---|---|---|---|
| Набор тэстаў для хуткага выканання, створаны ўручную | Прадукт + eng | $ | Вельмі мэтанакіраваны, хутка ловіць рэгрэсіі - але вы павінны падтрымліваць яго заўсёды 🙃 (пачатковыя інструменты: OpenAI Evals ) |
| Панэль ацэнкі рубрыкі "чалавек" | Каманды, якія могуць вызваліць рэцэнзентаў | $$ | Найлепш падыходзіць для тону, нюансаў, «ці прыме гэта чалавек», лёгкі хаос у залежнасці ад рэцэнзентаў |
| LLM-як-суддзя (з рубрыкамі) | Хуткія ітэрацыйныя цыклы | $-$$ | Хуткі і маштабуемы, але можа ўспадкоўваць прадузятасць і часам ацэньваць вібрацыі, а не факты (даследаванні + вядомыя праблемы прадузятасці: G-Eval ) |
| Спрынт з чырвонымі камандамі супраць супернікаў | Бяспека + адпаведнасць | $$ | Знаходзіць рэжымы рэзкіх збояў, асабліва імгненную ін'екцыю - адчуваецца як стрэс-тэст у трэнажорнай зале (агляд пагроз: OWASP LLM01 Імгненная ін'екцыя / OWASP Top 10 для праграм LLM ) |
| Генерацыя сінтэтычных тэстаў | Каманды па асвятленні дадзеных | $ | Выдатнае асвятленне, але штучныя падказкі могуць быць занадта акуратнымі, занадта ветлівымі... карыстальнікі не ветлівыя |
| A/B-тэставанне з рэальнымі карыстальнікамі | Прадукты для дарослых | $$$ | Найбольш выразны сігнал — таксама найбольш эмацыйна стрэсавы, калі паказчыкі вагаюцца (класічны практычны дапаможнік: Kohavi et al., “Кантраляваныя эксперыменты ў сетцы” ) |
| Ацэнка на аснове пошуку (праверкі RAG) | Пошук + праграмы кантролю якасці | $$ | Вымярае «правільна выкарыстоўвае кантэкст», памяншае завышэнне балаў галюцынацый (агляд ацэнкі RAG: Ацэнка RAG: Апытанне ) |
| Маніторынг + выяўленне дрэйфу | Вытворчыя сістэмы | $$-$$$ | З часам дэградуе — непрыкметны, пакуль не выратуе вас 😬 (агляд дрэйфу: апытанне аб канцэптуальным дрэйфе (PMC) ) |
Звярніце ўвагу, што цэны наўмысна заніжаныя. Яны залежаць ад маштабу, інструментаў і колькасці выпадкова праведзеных сустрэч.
7) Ацэнка чалавекам — сакрэтная зброя, якую людзі недафінансавалі 👀🧑⚖️
Калі вы робіце толькі аўтаматызаваную ацэнку, вы прапусціце:
-
Неадпаведнасць тону («чаму так саркастычна»)
-
Нязначныя фактычныя памылкі, якія выглядаюць чыста
-
Шкодныя наступствы, стэрэатыпы або нязручныя фармулёўкі (рызыка + прадузятасць: NIST AI RMF 1.0 )
-
Памылкі пры выкананні інструкцый, якія ўсё яшчэ гучаць «разумна»
Зрабіце рубрыкі канкрэтнымі (інакш рэцэнзенты будуць дзейнічаць самастойна)
Дрэнная рубрыка: «Карыснасць».
Лепшая рубрыка:
-
Карэктнасць : факталагічна дакладная з улікам запыту + кантэксту
-
Паўната : ахоплівае неабходныя пункты без усялякіх заўваг
-
Яснасць : чытэльная, структураваная, мінімальная блытаніна
-
Палітыка / бяспека : пазбягае забароненага кантэнту, добра апрацоўвае адмовы (бяспечнае афармленне: NIST AI RMF 1.0 )
-
Стыль : адпавядае голасу, тону, узроўню чытання
-
Вернасць : не выдумляе крыніцы або сцвярджэнні, якія не пацверджаны
Акрамя таго, часам праводзьце праверкі ацэнак паміж рэцэнзентамі. Калі два рэцэнзенты пастаянна разыходзяцца ў меркаваннях, гэта не «праблема людзей», а праблема рубрыкі. Звычайна (асновы надзейнасці ацэншчыкаў: МакХ'ю пра каппу Коэна ).
8) Як ацаніць мадэлі штучнага інтэлекту на прадмет бяспекі, надзейнасці і «ой, карыстальнікі» 🧯🧪
Гэта тое, што вы робіце перад запускам — і працягваеце рабіць, бо інтэрнэт ніколі не спіць.
У тым ліку тэсты на трываласць
-
Памылкі друку, слэнг, парушаная граматыка
-
Вельмі доўгія падказкі і вельмі кароткія падказкі
-
Супярэчлівыя інструкцыі («будзьце кароткімі, але ўключыце ўсе дэталі»)
-
Шматразовыя размовы, падчас якіх карыстальнікі мяняюць мэты
-
Запытваць спробы ўвядзення («ігнараваць папярэднія правілы…») (падрабязнасці пагрозы: OWASP LLM01 Запытваць увядзенне )
-
Адчувальныя тэмы, якія патрабуюць стараннага адхілення (ацэнка рызыкі/бяспекі: NIST AI RMF 1.0 )
Ацэнка бяспекі — гэта не проста «ці адмаўляецца»
Добрая мадэль павінна:
-
Адмаўляйцеся ад небяспечных запытаў выразна і спакойна (рэкамендацыі: NIST AI RMF 1.0 )
-
Пры неабходнасці прадастаўляйце больш бяспечныя альтэрнатывы
-
Пазбягайце празмерных адмоваў ад бяскрыўдных пытанняў (ілжыва спрацоўваючых вынікаў)
-
Апрацоўвайце неадназначныя запыты, задаваючы ўдакладняльныя пытанні (калі гэта дазволена)
Празмерная адмова — сапраўдная праблема прадукту. Карыстальнікам не падабаецца, калі да іх ставяцца як да падазроных гоблінаў. 🧌 (Нават калі яны падазроныя гобліны.)
9) Кошт, затрымка і аперацыйная рэальнасць — ацэнка, пра якую ўсе забываюць 💸⏱️
Мадэль можа быць «цудоўнай» і ўсё роўна не падыходзіць, калі яна павольная, дарагая або нетрывалая ў эксплуатацыі.
Ацаніце:
-
Размеркаванне затрымкі (не толькі сярэдняе — p95 і p99 маюць значэнне) (чаму важныя перцэнтылі: Google SRE Workbook on Monitoring )
-
Кошт за паспяховую задачу (не кошт за токен асобна)
-
Стабільнасць пад нагрузкай (тайм-аўты, абмежаванні хуткасці, анамальныя пікі)
-
Надзейнасць выкліку інструментаў (калі яны выкарыстоўваюць функцыі, ці паводзяць сябе яны правільна)
-
Тэндэнцыі даўжыні выхаднога сігналу (некаторыя мадэлі бязладныя, а бязладныя каштуюць грошай)
Крыху горшая мадэль, якая ўдвая хутчэйшая, можа перамагчы на практыцы. Гэта гучыць відавочна, але людзі ігнаруюць гэта. Гэта як купіць спартыўны аўтамабіль для паходу ў прадукты, а потым скардзіцца на месца ў багажніку.
10) Просты комплексны працоўны працэс, які можна скапіяваць (і змяніць) 🔁✅
Вось практычная інструкцыя па ацэнцы мадэляў штучнага інтэлекту, не трапляючы ў пастку бясконцых эксперыментаў:
-
Вызначэнне поспеху : задача, абмежаванні, выдаткі на няўдачу
-
Стварыце невялікі «асноўны» набор тэстаў : 50-200 прыкладаў, якія адлюстроўваюць рэальнае выкарыстанне
-
Дадаць краёвыя і суперніцкія наборы : спробы ўвядзення, неадназначныя падказкі, зонды бяспекі (клас увядзення падказак: OWASP LLM01 )
-
Выконвайце аўтаматызаваныя праверкі : фарматаванне, валіднасць JSON, базавая правільнасць, дзе гэта магчыма
-
Выканаць праверку чалавекам : выбарка вынікаў па катэгорыях, ацэнка з дапамогай рубрыкі
-
Параўнайце кампрамісы : якасць супраць кошту супраць затрымкі супраць бяспекі
-
Пілотны праект у абмежаваным рэлізе : A/B-тэсты або паэтапнае разгортванне (кіраўніцтва па A/B-тэставанні: Kohavi et al. )
-
Манітор у прадукцыйнай версіі : дрэйф, рэгрэсіі, цыклы зваротнай сувязі з карыстальнікамі (агляд дрэйфу: апытанне аб дрэйфе канцэпцыі (PMC) )
-
Ітэрацыя : абнаўленне падказак, пошук, дакладная налада, ахоўныя панэлі, а затым паўторны запуск eval (шаблоны ітэрацый eval: кіраўніцтва па OpenAI evals )
Захоўвайце журналы з версіямі. Не таму, што гэта весела, а таму, што ў будучыні вы будзеце дзякаваць сабе, трымаючы каву ў руцэ і мармычучы «што змянілася...» ☕🙂
11) Распаўсюджаныя памылкі (г.зн.: спосабы, якімі людзі выпадкова падманваюць саміх сябе) 🪤
-
Навучанне для тэсту : вы аптымізуеце падказкі, пакуль тэст не будзе выглядаць выдатна, але карыстальнікі пакутуюць
-
Уцечка дадзеных ацэнкі : тэставыя запыты адлюстроўваюцца ў дадзеных навучання або тонкай налады (ой!)
-
Пакланенне адзінай метрыцы : пагоня за адным паказчыкам, які не адлюстроўвае каштоўнасці для карыстальніка
-
Ігнараванне зруху размеркавання : паводзіны карыстальнікаў змяняюцца, і ваша мадэль ціха дэградуе (афармленне рызык вытворчасці: апытанне аб дрэйфе канцэпцыі (PMC) )
-
Залішняя індэксацыя па прынцыпе «разумнасці» : разумныя разважанні не маюць значэння, парушаюць яны фарматаванне ці выдумляюць факты
-
Не правяраецца якасць адмовы : «Не» можа быць правільным, але ўсё роўна жахлівым UX.
Таксама сцеражыцеся дэма-ролікаў. Дэма-ролікі падобныя на трэйлеры фільмаў. Яны паказваюць асноўныя моманты, хаваюць павольныя часткі і часам суправаджаюцца драматычнай музыкай. 🎬
12) Заключны агляд таго, як ацэньваць мадэлі штучнага інтэлекту 🧠✨
Ацэнка мадэляў штучнага інтэлекту — гэта не аднаразовая ацэнка, гэта збалансаванае харчаванне. Вам патрэбны бялок (правільнасць), гародніна (бяспека), вугляводы (хуткасць і кошт), і так, часам дэсерт (тон і задавальненне) 🍲🍰 (ацэнка рызык: NIST AI RMF 1.0 )
Калі вы больш нічога не памятаеце:
-
Вызначце, што азначае «добра» для вашага выпадку выкарыстання
-
Выкарыстоўвайце рэпрэзентатыўныя наборы тэстаў, а не толькі вядомыя бенчмаркі
-
Спалучыце аўтаматызаваныя паказчыкі з праверкай рубрык, якую выконвае чалавек
-
Надзейнасць і бяспека тэстаў, як быццам карыстальнікі з'яўляюцца варожымі (бо часам… яны з'яўляюцца такімі) (клас хуткага ўвядзення: OWASP LLM01 )
-
Улічвайце кошт і затрымку ў ацэнцы, а не ў якасці дадатковай думкі (чаму важныя перцэнтылі: Google SRE Workbook )
-
Маніторынг пасля запуску — мадэлі дрэйфуюць, праграмы развіваюцца, людзі праяўляюць творчасць (агляд дрэйфу: апытанне аб дрэйфе канцэпцый (PMC) )
Вось як ацаніць мадэлі штучнага інтэлекту такім чынам, каб яны працавалі, нават калі ваш прадукт ужо даступны, і людзі пачынаюць рабіць непрадказальныя рэчы. Што заўсёды так. 🙂
Часта задаваныя пытанні
Які першы крок у ацэнцы мадэляў штучнага інтэлекту для рэальнага прадукту?
Пачніце з вызначэння таго, што азначае «добра» для вашага канкрэтнага выпадку выкарыстання. Вызначце мэту карыстальніка, колькі вам каштуюць памылкі (нізкія супраць высокіх ставак) і дзе будзе працаваць мадэль (воблака, на прыладзе, рэгуляванае асяроддзе). Затым пералічыце жорсткія абмежаванні, такія як затрымка, кошт, прыватнасць і кантроль тону. Без гэтай асновы вы будзеце шмат чаго вымяраць і ўсё роўна прымеце няправільнае рашэнне.
Як стварыць набор тэстаў, які сапраўды адлюстроўвае маіх карыстальнікаў?
Стварыце набор тэстаў, які сапраўды ваш, а не проста публічны бенчмарк. Уключыце залатыя прыклады, якія вы б з гонарам выклалі, а таксама шумныя, нестандартныя запыты з памылкамі друку, паўсказамі і неадназначнымі запытамі. Дадайце памежныя выпадкі і тэсты рэжыму няўдачы, якія спакушаюць галюцынацыі або небяспечныя адказы. Улічыце разнастайнасць узроўняў навыкаў, дыялектаў, моў і абласцей, каб вынікі не праваліліся ў прадукцыйнай працы.
Якія метрыкі варта выкарыстоўваць, а якія могуць быць падманлівымі?
Супастаўце метрыкі з тыпам задачы. Дакладнае супадзенне і дакладнасць добра працуюць для здабывання і структураваных вынікаў, у той час як дакладнасць/паўнавартаснасць і F1 дапамагаюць, калі прапусціць нешта горш, чым лішні шум. Метрыкі перакрыцця, такія як BLEU/ROUGE, могуць уводзіць у зман для задач з адкрытым канцом, а ўбудаванае падабенства можа ўзнагароджваць «няправільныя, але падобныя» адказы. Для напісання, падтрымкі або разважанняў спалучайце метрыкі з паказчыкамі праверкі чалавекам і паказчыкамі поспеху задач.
Як структураваць ацэнкі, каб яны былі паўтаральнымі і прыдатнымі для вытворчасці?
Надзейная структура ацэнкі павінна быць паўтаральнай, прадстаўнічай, шматслаёвай і практычнай. Спалучайце аўтаматызаваныя праверкі (фармат, валіднасць JSON, базавая правільнасць) з ацэнкай па крытэрыях чалавека і тэстамі на спаборніцтвах. Зрабіце яе абароненай ад несанкцыянаванага ўзлому, пазбягаючы ўцечак і «навучаючы тэсту». Улічвайце кошт ацэнкі, каб вы маглі часта яе паўтараць, а не толькі адзін раз перад запускам.
Які найлепшы спосаб праводзіць ацэнку чалавекам, каб яна не ператварылася ў хаос?
Выкарыстоўвайце канкрэтную рубрыку, каб рэцэнзенты не выдумлялі тэкст. Ацэньвайце такія атрыбуты, як правільнасць, паўната, яснасць, бяспека/выкананне палітыкі, стыль/супадзенне галасоў і дакладнасць (не выдумляйце сцвярджэнні або крыніцы). Перыядычна правярайце ўзгадненне меркаванняў рэцэнзентаў; калі рэцэнзенты пастаянна разыходзяцца ў меркаваннях, рубрыку, верагодна, трэба ўдасканаліць. Праверка чалавекам асабліва каштоўная для выяўлення неадпаведнасцей тону, нязначных фактычных памылак і парушэнняў у выкананні інструкцый.
Як ацаніць бяспеку, надзейнасць і рызыкі, звязаныя з неадкладнай ін'екцыяй?
Тэстуйце з выкарыстаннем тыпу «ох, карыстальнікі»: памылкі друку, слэнг, супярэчлівыя інструкцыі, вельмі доўгія або вельмі кароткія падказкі і шматразовыя змены мэтаў. Уключыце спробы ўвядзення падказак, такіх як «ігнараваць папярэднія правілы», і далікатныя тэмы, якія патрабуюць асцярожных адмоваў. Добрая бяспека — гэта не толькі адмова — гэта выразная адмова, прапанова больш бяспечных альтэрнатыў, калі гэта мэтазгодна, і пазбяганне празмернага адхілення бяскрыўдных запытаў, якія шкодзяць карыстальніцкаму досведу.
Як ацаніць кошт і затрымку такім чынам, каб яны адпавядалі рэальнасці?
Не абмяжоўвайцеся сярэднімі паказчыкамі — адсочвайце размеркаванне затрымкі, асабліва p95 і p99. Ацэньвайце кошт кожнай паспяховай задачы, а не кошт кожнага токена асобна, бо паўторныя спробы і неадназначныя вынікі могуць звесці на нішто эканомію. Праверце стабільнасць пад нагрузкай (тайм-аўты, абмежаванні хуткасці, пікі) і надзейнасць выкліку інструментаў/функцый. Лепшым выбарам можа быць крыху горшая мадэль, якая ўдвая хутчэйшая або больш стабільная.
Які просты комплексны працоўны працэс для ацэнкі мадэляў штучнага інтэлекту?
Вызначце крытэрыі поспеху і абмежаванні, а затым стварыце невялікі асноўны набор тэстаў (прыкладна 50–200 прыкладаў), які адлюстроўвае рэальнае выкарыстанне. Дадайце перыферыйныя і канкурэнтныя наборы для бяспекі і спроб укаранення. Запусціце аўтаматызаваныя праверкі, а затым выберыце вынікі для ацэнкі па рубрыках чалавека. Параўнайце якасць з коштам, затрымкай і бяспекай, правядзіце пілотны праект з абмежаваным разгортваннем або A/B-тэстам і кантралюйце ў прадукцыйнасці дрэйф і рэгрэсіі.
Якімі найбольш распаўсюджанымі спосабамі каманды выпадкова падманваюць сябе пры ацэнцы мадэлі?
Распаўсюджаныя пасткі ўключаюць аптымізацыю падказак для дасягнення найлепшых вынікаў, пакуль карыстальнікі пакутуюць, уцечку падказак ацэнкі ў навучальныя або дапрацаваныя дадзеныя і пакланенне адной метрыцы, якая не адлюстроўвае каштоўнасць для карыстальніка. Каманды таксама ігнаруюць зрух размеркавання, пераацэньваюць «разумнасць» замест адпаведнасці фармату і дакладнасці, а таксама прапускаюць тэставанне якасці адмоваў. Дэманстрацыйныя версіі могуць хаваць гэтыя праблемы, таму спадзявайцеся на структураваныя ацэнкі, а не на відэа з найлепшымі вынікамі.
Спасылкі
-
OpenAI - Кіраўніцтва па ацэнцы OpenAI - platform.openai.com
-
Нацыянальны інстытут стандартаў і тэхналогій (NIST) - Структура кіравання рызыкамі штучнага інтэлекту (AI RMF 1.0) - nist.gov
-
OpenAI — openai/evals (рэпазітар GitHub) — github.com
-
scikit-learn - падтрымка_дакладнага_вылічэння_fscore - scikit-learn.org
-
Асацыяцыя камп'ютэрнай лінгвістыкі (ACL Anthology) - BLEU - aclanthology.org
-
Асацыяцыя камп'ютэрнай лінгвістыкі (ACL Anthology) - ROUGE - aclanthology.org
-
arXiv - G-Eval - arxiv.org
-
OWASP - LLM01: Хуткая ін'екцыя - owasp.org
-
OWASP - Топ-10 OWASP для прыкладанняў з вялікімі моўнымі мадэлямі - owasp.org
-
Стэнфардскі ўніверсітэт - Кохаві і інш., «Кантраляваныя эксперыменты ў сетцы» - stanford.edu
-
arXiv - Ацэнка RAG: апытанне - arxiv.org
-
PubMed Central (PMC) - Апытанне аб дрэйфе канцэпцый (PMC) - nih.gov
-
PubMed Central (PMC) - МакХ'ю пра каппу Коэна - nih.gov
-
Google - SRE Працоўны сшытак па маніторынгу - google.workbook