← Блог
Engineering2026-07-01

Доверието като продукт

Солвър, който казва "не знам" и ескалира, струва повече от такъв, който винаги отговаря. Включително денят, в който нашият сервираше измислена несигурност.

#машинно-обучение#trustworthy-ai#инженерна-симулация#uncertainty-quantification#deep-tech

На 12 юли 2026 разбрах, че собственият ми сървър лъже за увереността си. Не към потребител, не нарочно — но реален сървър, на реален ендпойнт, връщаше числа между 0.769 и 87.9 като “несигурност” за глава на модела, която никога не е била трениран да произвежда несигурност. Документацията казваше, че сървърът отказва да върне такова число. Кодът не отказваше. Тази празнина е най-опасното нещо, което подобна система може да направи.

Искам да разкажа защо точно този инцидент, а не което и да е число за точност, е сърцевината на това, което правя.

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

Затова има слой на доверие. Шест нива стоят между суровото предсказание и всичко надолу по веригата. Те проверяват предсказанието срещу самата физика — остатъци на диференциалните уравнения, закони за запазване, физични граници — без изобщо да питат солвър за “правилния” отговор. Като проверка на здравия разум: подаваш синтетично поле, чиято истинска дивергенция е точно 2, и слоят връща 2.0000. Математиката излиза вярна там, където знаем отговора — минималният праг, преди да се довериш на местата, където не знаем.

Частта, която не мога да прескоча

Ето инцидента отново, изцяло, защото да го премълча би обезсмислило поста. Главата за количествена оценка на несигурността (UQ) в тази архитектура не е трениран. Няма калибровка, няма истина, от която да е учила. Правилното поведение е: откажи да върнеш число, върни типизирана грешка, HTTP 409, uq_unavailable. До 12 юли сървърът не правеше това. Връщаше числа от нетрениран модул, сякаш означаваха нещо. Никой надолу по веригата не би могъл да различи калибрирана несигурност от случайна — и двете изглеждат като число с плаваща запетая.

Оправих го, и после направих нещото, което всъщност тежи повече от самата поправка: закачих правилното поведение с тест, който пада, ако бъгът се върне (test_uq_overlay_is_refused_while_the_uq_head_is_uncalibrated). Бъг, който поправиш веднъж и не закачиш с тест, е бъг, който ще пуснеш пак.

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

И честните части все още не са напълно честни

Построихме сигнал за ескалация от нещо просто: пускаш два семена (seeds) на модела върху един и същ вход и гледаш дали не се съгласяват. Несъгласието би трябвало да предсказва грешка. Измерихме го. Корелацията между несъгласието на двата seed-а и реалната грешка е 0.265. Процентът фалшиви тревоги е между 47% и 57%. Приблизително половината от времето системата маркира случай като несигурен, когато всъщност е бил наред, или пропуска случай, който е имал нужда от повторен поглед.

Това още не е калибриран сигнал за доверие. Измерен, честно докладван, засега слаб сигнал. Предпочитам да ти кажа числото 0.265, отколкото да го закръгля до “моделът знае кога греши”, защото засега най-често не знае.

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

Предпочитам да пусна система, която признава какво не знае, пред такава, която винаги има отговор. Къде е границата за теб — между “бързо и предимно вярно” и “бавно и доказуемо вярно”?

Обсъди NeuroCAD като пилот или инвестиционна възможност.

Working MVP/demo е наличен за квалифицирани разговори.

Контакт с founder-а