Какво измерваме, какво не и защо

Всеки случай е малък проект, съдържащ най-малкия код, който проявява или безопасно избягва една уязвимост. Всеки носи коментар какво е сгрешено, какво се очаква и защо. Корпусът е версиониран: промяна в него е промяна в публикуваните числа.

Очакваният резултат е преценка за кода, решена преди енджинът да бъде изпълнен, никога описание на това, което енджинът е произвел. Когато двете се разминават, първо разследваме енджина. Етикет, написан така, че да съвпадне с изхода на енджина, не измерва нищо, и ни се е налагало да поправяме етикети, които бяха отишли в тази посока.

Всеки случай се анализира така, както върви клиентско сканиране: пълният оркестратор на максимална дълбочина, без външни скенери, без модел в цикъла. Числата описват енджина, който се доставя идентично навсякъде, а не лабораторна конфигурация, сглобена за случая.

Една трета от корпуса е код, който не е уязвим, в по-голямата си част поправената форма на случай, който е. Корпус само от уязвимости не може да открие фалшиво положителен резултат, а именно фалшиво положителните карат един инструмент за сигурност да спре да бъде четен.

Фактическо твърдение: тези активи съществуват и тези отношения са налице между тях. Измеримо, и първото, което възнамеряваме да измерим. Изисква корпус от цели хранилища, анотирани ръчно, двама независими оценители и съгласието между тях, публикувано до оценката. Каквото и да е по-малко измерва процеса на анотиране, а не екстрактора.

Фактически, но едва след като някой посочи с какво започва нападателят. „Нападател може да достигне базата данни“ не е нито вярно, нито невярно, докато не кажете дали той започва като анонимен посетител, удостоверен потребител или компрометиран build runner. Същият енджин е прав при едно допускане и греши при друго, така че число без това допускане, отпечатано до него, не е възпроизводимо.

Твърдение за това кое има по-голямо значение, а тук няма факт независимо от целта. Стартъп преди приходи и регулирана банка четат едно и също хранилище и двете са прави да го подредят различно. Всяка правилна подредба, която бихме публикували, би била нашето собствено продуктово мнение, валидирано спрямо еталонна истина, която също сме написали ние.

Действай сега, планирай, провери: препоръка спрямо политика, а политиката е продуктово решение. Можем да тестваме, че тя следва собствената си политика, че нито една находка не отпада мълчаливо и че всяка препоръка цитира доказателство, което съществува. Това е тест за съответствие. Да го наречем точност би поканило точно онова погрешно четене, което тази страница е написана да предотврати.

Всеки слой показва от колко находки е изчислена неговата прецизност. Слоевете с малки извадки са наскоро добавените и техните числа ще се движат с растежа на корпуса им. Това важи срещу ласкателните редове толкова, колкото и срещу неудобния: перфектен резултат от девет находки е слабо твърдение, а не силно.

Находките, които енджинът произвежда върху код, който не е уязвим, са изброени с анализатора, който е сгрешил, и причината находката да е погрешна. Броят се срещу прецизността, никога не се изключват от нея. Три от тях се задействат точно върху мярката, която самото правило препоръчва, а това е точно онзи вид дефект, заради чието изваждане наяве, а не поглъщане, съществува бенчмарк.

Той чете собствения интеграционен код на приложението за грешки при LLM и агенти: изход на модел, който стига до шел, идентификационни данни, поставени в промпт, агентен инструмент, който може да изпълни каквото и да е. Не е мярка за изкуствен интелект вътре в Cybseco. Този бенчмарк изпълнява детерминистичния енджин без модел в цикъла.

Уязвимост, която е реална и извън текущия обхват на енджина, се записва като приет пропуск, изключва се от пълнотата и се изброява. Записването на граница е начинът, по който бъдещо подобрение се появява като измерена печалба, вместо да бъде твърдяно днес.