Quin model t'ha respost? Ara, amb prova

Avui ningú no pot saber quin model li ha respost

Quan es pregunta alguna cosa a un model d'IA, la resposta arriba sense signatura. Segons Anthropic, avui un usuari no pot comprovar que ve del model que el desenvolupador diu que respon, i no d'un altre que hi ha colat d'amagat un intermediari que reparteix les peticions entre models per estalviar costos, ni d'un atacant que hagi manipulat la seqüència de tokens. I no n'hi ha prou de jutjar pel text: segons l'empresa, és «poc fiable» encara que la resposta sigui de qualitat.

Per a l'ús diari, en què importa més la resposta que el model que l'escriu, l'empresa reconeix que és una preocupació menor. Però Anthropic cita casos en què sí que importa. Els avaluadors independents que proven models abans i després del llançament necessiten saber que examinen el mateix que després se serveix. Els clients que contracten a través d'un intermediari volen saber que els tokens surten del model que han pagat. I un atacant que alteri les respostes no es detecta mirant només el text.

Anthropic pensa també en els reguladors: comprovar que un proveïdor serveix només models aprovats, o que el seu maquinari es dedica a servir respostes i no a entrenar un altre model d'amagat. En aquest últim cas, la mateixa empresa adverteix que demostrar que el maquinari serveix respostes no prova que no estigui, per exemple, entrenant un altre model alhora.

Comprovar-ho sense el model semblava fora d'abast

Comprovar una resposta topa amb dos obstacles, segons Anthropic. Els pesos de la majoria dels models capdavanters són privats. I encara que l'usuari els tingués, verificar que una resposta en surt obligaria a executar el model, amb uns recursos de càlcul molt per sobre del que es pot permetre un usuari, o fins i tot un avaluador.

La sortida que proposa l'empresa és una prova criptogràfica: el proveïdor envia amb cada resposta un fitxer d'uns quants megabytes que l'usuari comprova en segons, sense veure els pesos. Si la resposta no surt del model indicat, la comprovació falla.

L'objectiu no és nou per a Anthropic. En el seu full de ruta de seguretat, el Frontier Safety Roadmap, es va fixar com a meta un prototip d'inferència verificable per al 30 de setembre de 2026. Segons l'empresa, la va complir amb un altre projecte, que signa el seu trànsit i recalcula les respostes en un servidor de confiança; FlashProve persegueix el mateix per un camí diferent.

FlashProve: compromís, prova i comprovació

FlashProve és el sistema que Anthropic va presentar el 2 de novembre de 2026. El signa el Frontier Red Team, l'equip de l'empresa que sotmet els sistemes d'IA a proves d'estrès per entendre fins on arriben les seves capacitats actuals i anticipar el que vindrà.

Hi col·laboren investigadors de l'EPFL, l'Escola Politècnica Federal de Lausana, universitat tècnica suïssa; de l'Institut Tecnològic de Massachusetts (MIT), universitat nord-americana; de StarkWare, una empresa de tecnologia criptogràfica que contribueix a Starknet, la xarxa de cadena de blocs construïda sobre la seva tecnologia, i de Succinct, una empresa de criptografia aplicada, autora de SP1 i d'una xarxa per generar proves.

El sistema té dues parts: el proveïdor del model, que demostra, i l'usuari, que comprova. I dues fases. En la prèvia, que es fa una vegada per model, el proveïdor publica un compromís amb els pesos. Segons Anthropic, amb Llama 4 Maverick triga uns 39 minuts i serveix per a uns 16 milions de peticions; després cal comprometre-s'hi de nou.

En la fase en línia, per a cada petició, el proveïdor genera un fitxer que, segons l'empresa, prova que «el model compromès produeix aquests tokens de sortida». Qualsevol que tingui el compromís, el text enviat i la resposta ho pot comprovar sense els pesos i amb poc càlcul.

Una prova que no mostra res més

Segons Anthropic, la prova de FlashProve compleix quatre propietats. Si és honesta, s'accepta. No es pot falsificar si no és trencant supòsits criptogràfics àmpliament acceptats. No revela res dels pesos, ni dels càlculs intermedis, ni de quines parts del model s'han activat. I és petita i ràpida de comprovar.

El que no amaga és l'arquitectura: com està organitzat el model per dins, sense comptar els pesos. L'empresa ho deixa per a treballs futurs.

L'eina és un zkSNARK, el mateix tipus de prova que fan servir xarxes de cadena de blocs com Starknet. Segons Anthropic, la seva construcció es basa en funcions hash i ofereix fins i tot seguretat postquàntica.

Claude va posar-hi la velocitat; Lean, les garanties

Segons Anthropic, va ser Claude, el seu model, qui va introduir millores en aquests zkSNARK i va construir un sistema «substancialment més ràpid que els sistemes de codi obert anteriors». La mateixa empresa n'admet el risc: Claude «sovint pren decisions difícils d'avaluar». Per compensar-ho, les garanties de seguretat es van enunciar i demostrar en Lean, un llenguatge de verificació formal.

Es publiquen cinc peces, amb el codi, les demostracions i la documentació sota llicència Apache 2.0: l'article, un informe tècnic, la descripció del protocol, el codi executable —un generador de proves i dos verificadors, un de ràpid en C++ i un altre en Lean demostrablement correcte— i les demostracions en Lean, amb un visor interactiu per revisar-les. Segons l'empresa, és un avenç intermedi, «no un programa de recerca acabat».

El verificador en C++ és el d'ús diari, però, segons Anthropic, «no té cap garantia formal». En les seves proves, coincideix amb el de Lean en tots els casos.

El banc de proves: Llama 4 Maverick

Per mesurar, Anthropic va fer servir Llama 4 Maverick, un model de Meta de 400.000 milions de paràmetres, dels quals en fa servir uns 17.000 milions per token. És una mescla d'experts, i FlashProve només funciona amb models d'aquest tipus: segons l'empresa, la feina de qui demostra és proporcional als experts que s'han activat, no al model sencer, i la prova continua amagant quins han estat.

Els pesos no van inclosos en la publicació. Qui vulgui repetir l'experiment els descarrega a part, en una conversió pública a 4 bits feta per tercers, sota la llicència Llama 4 de Meta.

Quant costa avui demostrar una resposta

Les xifres són d'Anthropic, mesurades amb la versió a 4 bits del model, que ocupa uns 232 GB: cada petició és una finestra de 1.024 tokens llegida d'una passada (prefill) i cada prova comprova un sol token. Qui demostra treballa en un servidor amb una sola GPU H100 de Nvidia i 24 nuclis de processador. Qui comprova ho fa al processador del client, sense GPU: descarrega una vegada el compromís i, després, una prova per petició.

El preu és el sobrecost. Anthropic el mesura contra vLLM, un motor de codi obert molt utilitzat per servir models, amb la versió en 8 bits (FP8) del mateix model en vuit H100 i comptant per GPU. És l'última línia de la taula, i la que més pesa.

Respecte al que hi havia, un salt d'escala

Segons Anthropic, l'única prova anterior de Llama 4 Maverick que coneix és la de VerInf, un treball de recerca previ. Cita també Attestable, una empresa que ha publicat xifres amb un altre model, Gemma 4 31B, que és dens, i que no ha alliberat cap biblioteca de codi obert. La taula posa les tres al costat.

La conclusió de l'empresa és que demostrar una resposta costa «aproximadament 2 ordres de magnitud» més que calcular-la, «entre unes 70 i 95 vegades en les nostres mesures», i que això és «molt menys del que s'esperava». Anthropic creu que l'avenç s'hauria de traslladar a més models i arquitectures.

El que la prova no diu

Una prova acceptada no diu que la resposta sigui correcta, ni que el model sigui bo o segur. Segons la definició mateixa d'Anthropic, certifica una sola cosa: que «el model compromès produeix aquests tokens de sortida». És a dir, quins pesos han produït la resposta, no si la resposta és bona.

I hi ha lletra petita, declarada per l'empresa. El que es demostra és una versió exacta en nombres enters dels pesos publicats, i que cada token comprovat és l'elecció voraç del model. Una resposta calculada amb decimals en coma flotant, o generada amb mostreig, se'n pot apartar en algun punt i deixar de coincidir. Anthropic espera que la versió entera quedi molt a prop de la real, però això no cobreix les instruccions preparades per un adversari.

És, a més, un prototip de recerca. El repositori es presenta com «un artefacte de recerca: sense manteniment i sense acceptar contribucions».

Prova-ho: quatre rutes, de menys a més

El repositori de FlashProve proposa quatre maneres de provar-lo, de menys a més exigent. Només la primera és lleugera: compila el verificador, cp_verify, i comprova una prova desada. Les dues últimes demanen una GPU H100 i, la quarta, centenars de gigues de memòria i de disc.

Aquesta prova desada té trampa, i el README ho diu: és un model sintètic petit, de 8 capes, 4 experts i un vocabulari de 512 peces, de manera que «només demostra que el verificador funciona, no res sobre un model en servei».

L'exemple, obert sense executar res

El 3 de novembre de 2026, cap a les 10:05, vam recórrer la part de la ruta 1 que no necessita executar res descarregat: clonar el repositori, comprovar que els fitxers de l'exemple havien arribat íntegres i llegir què s'hi demostra. Sense GPU i sense cap cost.

La suma de comprovació té un límit que convé no oblidar: només garanteix que la descàrrega és sencera, no que la prova sigui vàlida. Això ho decideix el verificador.

El que es demostra cap en tres fitxers. La petició, example.req, són 64 tokens més dos valors, r i e; la resposta, example.y, és el token següent, el 199. Segons el README, la prova afirma que els tokens 61, 62 i 63 i aquest token següent són, cadascun, el que el model compromès posa primer.

La comprovació completa exigeix compilar el verificador, i no el vam compilar ni executar. El README indica que, amb aquest exemple, l'última línia ha de ser YES i el codi de sortida, 0.

Com es llegeix el veredicte

cp_verify dona el veredicte amb dos senyals alhora, el codi de sortida i l'última línia, i el README demana llegir-los junts. Un codi 0 amb YES (o WITHIN LIMITS) és una prova acceptada; un codi 1 amb NO, una de rebutjada o un error local, i el codi 5, que no hi ha veredicte; altres codis assenyalen crides o fitxers erronis.

N'hi ha prou amb un sol bit perquè la rebutgi

El repositori porta també el cas contrari. Segons el README, un script altera els fitxers de l'exemple un per un i el verificador els rebutja tots amb codi 1: «10 conjunts alterats: tots rebutjats». La taula recull el que documenta aquest README; no és una execució pròpia.

Segons aquest mateix document, canviar un bit de la prova, retallar-ne l'últim byte o tocar un token del text enviat o de la resposta fa que la prova es rebutgi. Fer servir un altre identificador de compromís, o alterar un bit de la clau, falla per una altra via, amb el seu propi motiu.

Dues tasques que el verificador deixa a l'usuari

En un ús real, el README deixa dues tasques en mans de qui comprova. La primera, aconseguir l'identificador del compromís «abans d'enviar el prompt, de qui respon pel model, no a través del servidor que estàs comprovant». I afegeix: «No l'agafis mai dels fitxers que acompanyen una prova».

La segona, construir un mateix el fitxer de la petició amb el text enviat i la resposta rebuda, perquè, segons el README, «res no comprova que el fitxer contingui el teu prompt i la teva resposta». Una prova impecable sobre una petició que no és la teva no garanteix res sobre la teva resposta.