Promptfoo или DeepEval: безбедносни напад и Python тест траже различит алат

Promptfoo је природнији избор када тим пореди више модела и систематски испитује нападачке улазе: његова CLI евалуација и red teaming повезују упите, провајдере и услове провере. DeepEval је ближи тиму који већ одржава Python тестове и жели да квалитет одговора одлучује о пролазу кроз CI. Избор је зато питање облика посла, а не општег ранга алата.

DeepEval укључује тест случајеве и метрике у pytest ток, са прагом који одређује пролаз квалитативне оцене. Promptfoo такође може да обори CI посао; разлика је у томе што се његове пробе превасходно задају кроз конфигурацију и покрећу као засебна евалуација. Исти условни одговор омогућава да се та разлика види без мешања поставке теста са понашањем стварне апликације.

Исти одговор, два услова

Узмимо условни пример помоћника продавнице. Његово правило гласи: „Рок за повраћај је 14 дана“, корисник пита „Колики је рок за повраћај?“, а забележени одговор је „Рок за повраћај је 14 дана.“ То није податак о стварној продавници, већ заједнички улаз за поређење два теста.

Први услов је детерминистички: одговор мора да садржи „14 дана“. Он јасно открива изостанак обавезног податка, али би прихватио и реченицу која после тачног рока додаје измишљен изузетак. Други услов зато препушта LLM судији оцену да ли је рок саопштен јасно и без непотврђених услова. Та оцена је корисна за смисао целог одговора, али зависи од критеријума и изабраног модела судије.

Promptfoo: конфигурација и матрица провајдера

За почетну пробу у promptfooconfig.yaml поставља се prompts на „{{answer}}“, providers на echo, а у tests.vars вредност answer на забележени одговор. Echo провајдер враћа примљени упит као одговор, без позива циљном моделу. У tests.assert први услов има type: contains и value: „14 дана“. Таква поставка најпре испитује да ли је обавезан податак правилно повезан са одговором.

У исти tests.assert улази и type: llm-rubric, са value који тражи да одговор јасно наведе рок од 14 дана и не дода непотврђене изузетке. За илустративни праг може се поставити threshold: 0.8, уз изричито наведен provider за судију. Код провере llm-rubric оцена мора достићи праг, а ако судија врати и засебну ознаку пролаза, морају бити испуњена оба услова. Праг из примера није универзална мера квалитета; треба га ускладити са прихватљивим и неприхватљивим одговорима конкретне апликације.

Када се испита сама поставка, echo се може заменити провајдером апликације, а prompts корисничким питањем и контекстом који апликација заиста добија. Тада тест почиње да хвата промене настале после измене упита, модела или апликације. Ако тим пореди више провајдера, исти случај може да примени на сваки од њих у једној матрици; у безбедносном раду Promptfoo истим конфигурационим током организује и нападачке пробе над циљном апликацијом.

DeepEval: случај у Python тесту

У test_refund.py функција test_refund може да додели забележену реченицу променљивој actual_output и затим употреби обичан Python услов assert „14 дана“ in actual_output. Потом се прави LLMTestCase: input је корисничко питање, actual_output забележени одговор, а expected_output реченица са условним правилом продавнице. Ова почетна верзија испитује тестну капију; за стварну регресиону проверу actual_output треба добити позивом апликације у тесту.

Квалитативни услов додаје се као GEval са критеријумом да одговор јасно наведе рок и не измишља изузетке. Параметри evaluation_params су SingleTurnParams.ACTUAL_OUTPUT и SingleTurnParams.EXPECTED_OUTPUT, док је threshold=0.8 само пример изабране границе. Позив assert_test добија тај случај и метрику, а команда deepeval test run test_refund.py покреће тест. За разлику од провере присуства текста, GEval оцењује однос стварног и очекиваног одговора, па му треба модел судија.

Python ток је нарочито згодан када тест већ мора да припреми податке, позове функцију апликације или провери још неки програмски услов. Promptfoo јасније излаже комбинације упита, провајдера и случајева у конфигурацији. Ни један облик не ослобађа тим од одржавања очекивања: када се стварно правило о повраћају промени, мора се изменити и тестни случај.

Који позиви стварају трошак

Детерминистичка провера забележеног одговора не позива LLM судију. У почетној Promptfoo поставци echo не позива ни циљни модел, али llm-rubric може да позове свог провајдера за оцењивање. Исто важи за GEval у DeepEval-у када је његов судија удаљени модел. Чим се забележени одговор замени живим позивом апликације, настаје и трошак њеног провајдера.

Код матрице се циљна апликација покреће за сваку изабрану комбинацију случаја и провајдера. Нападачке пробе могу додати позиве за припрему улаза и њихову оцену. Зато се трошак рачуна одвојено за добијање одговора, генерисање пробе и рад судије, према стварној конфигурацији. Број случајева, дужина улаза, избор модела и кеширање могу да промене рачун иако сам тестни оквир остаје исти.

Како се доказује пад CI капије

Најпре се намерно квари детерминистички услов, док забележени одговор остаје „Рок за повраћај је 14 дана.“ У Promptfoo-у value за contains постаје „30 дана“, а у Python тесту услов постаје assert „30 дана“ in actual_output. Оба услова тада морају пасти, без неизвесности коју уноси LLM судија. За Promptfoo CI упутство наводи команду npx promptfoo@latest eval --fail-on-error за обарање посла при неуспелим тестовима; DeepEval тест се покреће командом deepeval test run test_refund.py и његов неуспех мора бити видљив као неуспех CI корака.

Судијска капија захтева засебну пробу. Вратите исправно очекивање од 14 дана, а actual_output замените са „Не знам.“ и проверите оцену, образложење и исход CI корака. Ако тај очигледно непотпун одговор прође, проблем је у критеријуму, избору судије или прагу, па капију треба подесити на означеним примерима пре ослањања на њу. Детерминистички пад доказује да CI преноси неуспех теста; ова друга проба показује да ли квалитативни услов препознаје баш пропуст који је тиму важан.

За тим чији су главни задатак поређење провајдера и систематске безбедносне пробе, Promptfoo је логично средиште евалуације. Када су постојећи Python тестови место на коме се одлучује о квалитету одговора, DeepEval се природније уклапа. Тим коме требају оба тока може их покретати у истом CI процесу, са одвојеним случајевима, судијама и трошковима.

Прочитајте и:

• Како ограничити AI агента пре него што prompt injection стигне до алата
• Facebook се отвара у Reels фиду — тест ипак може да се искључи
• CodeQL 2.27.2 шири анализу — 498 безбедносних упита остаје основа