Команда Frontier Red Team компанії Anthropic разом із партнером із формальних методів Theorem повідомила, що Claude створив машинно перевірені докази для 239 точок входу тестів у 123 бібліотеках із відкритим кодом. Йдеться про конкретні властивості, пов’язані зі збоями та безпекою пам’яті, для скомпільованих програм під RISC-V і за визначених умов. Це не доказ того, що бібліотеки загалом не мають помилок.
9
5
За даними команди, робота тривала кілька тижнів і дала близько 180 мільйонів рядків доказів мовою Rocq. Масштаб важливий не сам по собі: проєкт показує, що за допомогою ШІ формальну перевірку потенційно можна застосовувати до більшої кількості реального програмного забезпечення. Але будь-яку таку гарантію потрібно співвідносити з тим, що саме сформулювали й перевірили.
3
13
Що саме доводять результати
За повідомленням Anthropic, докази встановлюють, що перевірені програми завершуються штатно — без помилок безпеки пам’яті чи невдалих перевірок тверджень — для кожного входу розміром менш як 64 МБ, з урахуванням змодельованих відповідей Linux і варіантів розташування пам’яті та за зазначених припущень. Об’єкт перевірки — скомпільовані програми для RISC-V, а не абстрактна гарантія для всіх версій або способів розгортання бібліотек.
9
12
У роботі використали вже наявні тестові точки з Google OSS-Fuzz — системи, яка запускає фаззинг-тести для проєктів із відкритим кодом. Команда перетворила ці тести на формальні специфікації. Замість того щоб лише перевіряти багато окремих входів, Claude створив докази щодо поведінки визначених бінарних програм у межах усього діапазону входів, охопленого теоремою.
3
13
Anthropic називає цю роботу першою масштабною спробою використати ШІ для формальної перевірки виробничого програмного забезпечення на рівні машинного коду. Це характеристика новизни від самої команди, а не незалежно встановлений історичний консенсус.
7
13
Навіщо потрібен перевірний доказ
Claude створював докази, а ядро доказувача Rocq їх перевіряло. Тож для механічної перевірки не потрібно покладатися на правильність міркувань Claude чи вручну перечитувати кожен рядок доказу. Водночас машинна перевірка не усуває всіх припущень: теорема має описувати саме ту властивість, яка важлива розробникам, а формальні моделі та сам перевіряльник залишаються частиною основи, якій доводиться довіряти.
9
5
Anthropic та інші джерела оцінюють обсяг результату приблизно у 180 мільйонів рядків Rocq — у середньому близько 600 тисяч рядків на бінарну програму. Такий обсяг показує масштаб роботи, але кількість рядків сама по собі не свідчить ані про широту гарантії, ані про те, наскільки вона відповідає потребам реального проєкту.
3
12
Що можуть пропустити тести — і що, за повідомленнями, знайшли
Фаззинг перевіряє програму на великій кількості входів, але сам по собі не доводить її поведінку для кожного можливого входу в заданому діапазоні. За повідомленнями про проєкт, Claude знайшов і виправив сотні помилок, зокрема такі, що не виявили трильйони запусків фаззинг-тестів. Ці цифри наводять як результат саме цієї роботи; вони не є незалежним вимірюванням того, наскільки формальна перевірка перевершуватиме тестування в інших проєктах.
2
11
Практичний висновок — не відмовлятися від тестів. Формальний доказ дає інший тип свідчень: для конкретної властивості та визначеної області він може встановити поведінку програми для всіх входів, що відповідають специфікації, а не лише для випадків, які потрапили до тестових запусків.
9
2
Чому «перевірено» не означає «без помилок»
Гарантії стосуються вибраних точок входу та конкретних скомпільованих програм. Вони автоматично не поширюються на всі функції бібліотек, конфігурації збірки, архітектури чи способи використання.
9
5
Важливі й умови виконання. У повідомленнях описано докази для однопотокових статичних бінарних програм під RISC-V у змодельованому середовищі Linux із фіксованим обсягом пам’яті. Більшість користувачів запускає програми, зібрані для інших архітектур або конфігурацій, тож результати не слід сприймати як гарантію для таких варіантів.
12
27
34
Нарешті, доказ встановлює теорему, яку сформулювали, а не кожну властивість, якої може очікувати розробник. Помилки можуть залишитися поза межами перевірки або бути пов’язаними з формальними моделями та основою, на якій працює перевірка доказів.
5
31
Що можуть узяти до уваги розробники
Головний внесок проєкту — свідчення того, що допомога ШІ може зробити формальну перевірку машинного коду практичною для більшої кількості реального програмного забезпечення, ніж раніше, коли вона часто вимагала значної праці фахівців. Це не універсальна оцінка вартості й не гарантія успіху для будь-якої кодової бази.
7
13
У відкритому доступі опублікували частину доказів. За одним із повідомлень, вона охоплює 25 бібліотек і 60 точок входу, а не весь заявлений обсяг роботи. Theorem також оголосила OSS Verify — програму для підтримки проєктів із відкритим кодом.
32
16
38
Розробникам варто сприймати доказ як гарантію з чітко окресленими межами: перевіряти конкретну точку входу, скомпільовану програму, припущення та властивість, перш ніж покладатися на результат. Ця робота робить формальну перевірку за допомогою великих мовних моделей вартою уваги — але не замінює тестування і не означає, що програмне забезпечення тепер можна вважати безпомилковим.
9
5