
Przestałem ufać „zweryfikowane” w dniu, w którym nie mogłem tego odtworzyć.
Roszczenie zostało zatwierdzone, paragon wyglądał czysto, a przepływ pracy nadal się zaciął, gdy próbowaliśmy ponownie uruchomić kontrolę. Nic nie wyglądało na niedbałe. Problem był cichszy.
Zgodzili się, ale nie działali w tym samym środowisku.
Jeden weryfikator był na nowszym modelu. Inny używał starszego narzędzia z różnymi domyślnymi ustawieniami. Trzeci miał odwrócony bit polityki. Sieć i tak się zbiegała, a wynik stał się niepowtarzalny w momencie, gdy traktowaliśmy to jak umowę.
To szew sprawia, że Mira jest dla mnie interesująca.
Dryf wersji.
Mira przedstawia się jako zdecentralizowany protokół weryfikacji dla niezawodności AI. Weź wynik AI, rozłóż go na weryfikowalne roszczenia, rozdziel kontrole pomiędzy niezależnymi weryfikatorami, a następnie sfinalizuj to, co się liczy poprzez weryfikację kryptograficzną i konsensus blockchainowy, z zachętami zastępującymi centralne zatwierdzenie.
Na papierze, niezależność kupuje ci zaufanie.
W produkcji, niezależność kupuje ci rozprzestrzenienie.
A rozprzestrzenienie staje się niezawodnością tylko wtedy, gdy jest ograniczone.
Zgoda ma znaczenie tylko wewnątrz tego samego czasu wykonania.
W przeciwnym razie certyfikujesz dryf.
Dlatego dryf nie jest szczegółem narzędziowym. To granica odpowiedzialności.
Warstwa weryfikacji implicitnie obiecuje, że dowód może być powtórzony, lub przynajmniej wyjaśniony, przez każdego, kto go posiada. Jeśli weryfikatorzy działają na różnych wersjach modeli, różnych zestawach narzędzi, różnych szablonach promptów, różnych stanach polityki, lub różnych migawkach źródłowych, to dowód staje się momentem w czasie, a nie stabilnym obiektem. Sieć może zbiegać się do werdyktu, podczas gdy założenia pod nim rozchodzą się.
W praktyce, dryf objawia się jako werdykty, które się zmieniają po aktualizacjach, bez żadnych nowych dowodów.
Dowód, który nie może być powiązany z konkretnym hashem modelu, dowodem narzędzia, stanem polityki i powiązaniem migawki źródłowej, nie jest dowodem, to jest zrzut ekranu.
To wtedy zespoły przestają traktować sieć jako granicę i zaczynają traktować ją jako doradczą.
To jest najbardziej niebezpieczny rodzaj poprawności, poprawność, której nie można powtórzyć.
Kiedy to się dzieje, integratorzy robią to, co zawsze robią.
Zamykają środowisko.
Pojawia się kontrakt profilu weryfikatora, hash modelu, wersja narzędzia, stan polityki, powiązanie migawki. Pojawia się macierz kompatybilności, które stosy weryfikatorów są bezpieczne dla jakich typów roszczeń. Wdrażanie spowalnia, ponieważ każda aktualizacja teraz wymaga zestawu testów powtarzalności. Zakończyliśmy nałożenie 72-godzinnego zamrożenia kompatybilności dla roszczeń o dużym wpływie, tylko po to, aby zachować możliwość powtarzalności dowodów w ramach integracji. Nowa klasa incydentów się pojawia, nie zły werdykt, ale nie można powtórzyć werdyktu.
I ten incydent jest trucizną dla automatyzacji.
Ludzie mogą tolerować „to zależy”, jeśli ktoś potrafi wyjaśnić dlaczego. Automatyzacja nie może. Automatyzacja potrzebuje stabilnej granicy. Kiedy powtarzalność zawodzi, zespoły przestają ufać pierwszemu weryfikowaniu. Dodają okna wstrzymania. Dodają kroki potwierdzające. Dodają ręczną kontrolę dla roszczeń, które dotyczą pieniędzy, uprawnień lub nieodwracalnych działań. Protokół nadal weryfikuje, ale przepływ pracy staje się nadzorowany.
To jest koszt relokacji ukryty w wersjonowaniu.
Albo sieć egzekwuje semantykę „tego samego świata”, albo każdy poważny integrator odbudowuje ją prywatnie.
Jeśli sieć to egzekwuje, musi mieć wyraziste zdanie.
Zobowiązania środowiskowe. Identyfikatory wersji modeli. Format dowodów narzędzi. Hash stanu polityki. Powiązania migawki źródłowej. Zasady kwalifikacji, które określają, które profile weryfikatorów mogą uczestniczyć w jakich klasach roszczeń. Dyscyplina aktualizacji, aby nowe stosy nie zmieniały cicho znaczenia starych dowodów.
To spowalnia iterację. Zawęża tolerancję. Może wydawać się mniej otwarte, ponieważ nie każda konfiguracja weryfikatora może być traktowana jako wymienna.
Ale alternatywa to nie otwartość. Alternatywa to prywatne bramkowanie.
Kiedy protokół nie definiuje „tego samego świata”, najlepiej wyposażone zespoły to robią. Utrzymują zablokowane listy weryfikatorów, prywatne zasady kompatybilności i preferowane stosy. Wszyscy inni dziedziczą patchwork, w którym to samo roszczenie może być zweryfikowane w jednej integracji i nie powtórzone w innej.
To jest decentralizacja weryfikacji, połączona z centralizacją bezpieczeństwa operacyjnego.
Handel jest nieunikniony.
Zamroź mocno, a zachowasz możliwość powtarzalności, ale aktualizacje wydają się biurokratyczne i wolniejsze. Zamroź luźno, a utrzymasz prędkość, ale zweryfikowane staje się zmieniającym celem, a ekosystem uczy się wahania jako domyślnej postawy.
W systemach niezawodności, wahanie to podatek.
Teraz token, tylko w szwie, gdzie ma zęby.
Jeśli $MIRA ma rolę, powinien finansować kontrolę wariancji, spójne środowiska, zdyscyplinowane wdrożenia, egzekwowalne kwalifikacje weryfikatorów. Jeśli dryf tworzy zewnętrzności, system powinien je wycenić, aby najtańsza strategia nie polegała na wysyłaniu niekompatybilnych stosów i pozwolić integratorom wchłonąć konsekwencje.
Kiedy weryfikatorzy aktualizują, czy dowód nadal może być powtórzony bez prywatnej listy blokad.
Jeśli nie, dryf już wygrał.