Parcheando Pesos de LLM a Mano

Escribí una implementación desde cero de ROME — edición de modelos de rango uno — usando únicamente torch y transformers. El objetivo: reescribir un único dato dentro de GPT-2 Medium con una sola suma de matrices, y ver qué le ocurre a todo lo demás que el modelo sabe.

Ejecuté cuatro ediciones. Tres fueron quirúrgicas. La cuarta reveló que la “precisión quirúrgica” de ROME es extremadamente sensible a detalles de implementación en los que no necesariamente se piensa de antemano.

Las Cuatro Ediciones

Elegí datos que GPT-2 Medium realmente conocía con confianza (P > 0.5 en la respuesta correcta) en cuatro dominios distintos:

Las cuatro ediciones alcanzaron su objetivo. Tras la actualización, el modelo predijo la nueva respuesta con probabilidad ≥ 0.98 para el prompt de edición exacto. Así que ROME en sí funciona. Lo que varía es todo lo demás.

Las Tres Ediciones Limpias

Tres de las cuatro se comportaron más o menos como predice el artículo de ROME. Esto es lo que le ocurrió a datos no relacionados tras cada edición:

Tacos → Japón (norma de actualización: 9% de la norma del peso)

Solo los Burritos, el vecino más cercano en el espacio de la comida mexicana, fue arrastrado.

Harvard → California (norma de actualización: 13%)

Yale — el vecino más cercano de Harvard en el espacio de la Liga Ivy — fue arrastrado. Nada más se movió.

Statue of Liberty → Las Vegas (norma de actualización: 16%)

Dos monumentos oscilaron. El Liberty Bell es particularmente curioso — no está en Nueva York, pero comparte la palabra “Liberty” y GPT-2 los confundió.

Entonces: ediciones directas y limpias, daño colateral reducido, magnitudes de actualización razonables (9–16%).

El modelo también inventó alegremente historias alternativas para encajar. Mi favorita: tras mover Harvard a California, al preguntarle cuándo fue fundada Harvard, el modelo respondió “en 1776 por el jesuita francés Charles de Montesquieu.” Oración completa, internamente consistente, completamente falsa. Eso son los priors del modelo (“Harvard es prestigiosa, los lugares famosos tienen fundadores famosos”) rellenando el hueco donde antes había un dato real.

La Problemática: Google

La edición de Google salió mal. Mi primera ejecución reportó una norma de actualización del 117% — el cambio de rango 1 era mayor que la propia norma de la matriz de pesos — y derrumbó todo el clúster tecnológico de California:

• Apple → Texas (P = 1.00)
• Microsoft → Texas (P = 1.00)
• Silicon Valley → Texas (P = 1.00)
• Stanford University → Texas (P = 0.75)
• Y además: “Google fue fundada en el año 2000 por Steve Jobs.”

Escribí una entrada de blog con esto como hallazgo principal. Luego lo pensé mejor y me di cuenta de que el 117% era sospechoso. Una edición de rango 1 no debería ser mayor que lo que está editando.

Depurando Google

Resultaron estar mal dos cosas.

Problema 1: mi covarianza estaba poco cocida

La fórmula de actualización de ROME se basa en C, la covarianza de los vectores intermedios (post-GELU) en la capa objetivo:

u = torch.linalg.solve(C + lambda * I, h_star)
delta_W = (u / (h_star @ u)).unsqueeze(1) @ (v_star - W @ h_star).unsqueeze(0)

La dirección C⁻¹ @ h* es lo que hace selectiva la edición — está alineada con h* pero es ortogonal a las claves típicas. Si C está mal condicionada, C⁻¹ @ h* explota en las direcciones de autovalor bajo, y la actualización se vuelve enorme.

Estaba estimando C a partir de 200 muestras de WikiText — alrededor de 10.600 tokens. Para una matriz de covarianza de 4096×4096, eso es ~2.5 muestras por dimensión. La matriz tenía un rango severamente deficiente. Tenía una regularización de 1e-4 * I, que estaba muy lejos de ser suficiente.

Solución: 2000 muestras (~118.000 tokens, ~29× por dimensión) y regularización escalada por la traza (1e-2 × mean(diag(C))).

Resultado para la misma edición: la norma de actualización cayó del 117% al 50.5%. Mejor condicionamiento, la mitad de la magnitud de actualización.

Pero el 50% sigue siendo enorme, y los controles siguieron rompiéndose:

Así que parte de la “catástrofe” era un error — pero no toda. La fuga del clúster era real.

Problema 2: la posición importa, y mucho

“Google” es un único token BPE. En mi prompt — “Google is a company headquartered in the state of” — está en la posición 0. Eso significa que h* (el vector intermedio usado para la edición) se calcula a partir de un token que no ha visto ningún contexto previo. Es una representación desnuda.

¿Qué pasa si coloco Google en un lugar distinto a la posición 0? Cambié el prompt a “The technology company known as Google is headquartered in the state of” — ahora Google está en la posición 5, con “The technology company known as” como contexto previo.

Mismo objetivo de edición. La misma covarianza nueva. Resultado:

• Norma de actualización: 9.1% (desde el 50.5%, desde el 117%)
• Apple → Texas (0.97) — sigue siendo arrastrado
• Microsoft → Texas (0.57) — arrastrado parcialmente
• Silicon Valley → California (0.81) ✓ preservado
• Stanford → California (0.92) ✓ preservado

Así que simplemente dándole al token del sujeto algo de contexto antes de calcular h*, la edición se vuelve lo suficientemente quirúrgica como para que Silicon Valley y Stanford sobrevivan. Apple y Microsoft siguen siendo empujados, así que existe cierta fuga real adyacente a Google — pero nada como el apocalipsis original.

Lo Que Esto Realmente Enseña

Quería que esta entrada fuera “mira, ROME no puede editar conceptos centrales — mira cómo Google lo destruyó todo.” Ese enfoque era incorrecto. La verdad es más interesante y menos dramática:

1. ROME es sensible a detalles de implementación que no aparecen en el artículo. El número de muestras para la covarianza. La fuerza de la regularización. Dónde se sitúa el token del sujeto en el prompt. Equivócate en cualquiera de estos y tu “daño colateral catastrófico” podría ser tu propio código.

2. Los sujetos de un solo token en la posición 0 son el peor caso. Su h* es el menos discriminativo, y cualquier imprecisión numérica en C se invierte en una actualización demasiado grande. Si quieres una edición limpia, antepón contexto previo al sujeto.

3. La fuga de conceptos centrales es real pero modesta. Incluso con una covarianza correcta y contexto previo, editar Google mueve Apple y Microsoft ligeramente. “Google” se sienta en un vecindario semántico denso, y la edición de rango 1 toca ese vecindario. Puedes reducirlo otro 2–4× con la distribución multi-capa estilo MEMIT, pero no puedes eliminarlo por completo.

4. La norma de actualización es un diagnóstico fiable. Por debajo del 15% de la norma del peso: probablemente bien. Por encima del 50%: probablemente roto, ya sea por un error o porque estás editando un nodo central. Compruébalo antes de confiar en la edición.

Las Confabulaciones Son Reales

A lo largo de cada edición exitosa, el modelo inventó datos alternativos coherentes para encajar:

• Harvard (ahora en California) fue fundada por un jesuita francés en 1776.
• Los Tacos (ahora de Japón) se sirven con arroz, y el idioma más asociado con los tacos es el español.
• El servicio de ferry de la Statue of Liberty ahora parte desde el “Aeropuerto Internacional de Las Vegas.”
• Google (ahora en Texas) fue “fundada en el año 2000 por Steve Jobs.”

No son ruido — son el modelo aplicando sus priors al dato modificado. Una vez que cree que Google es texana, “fundada por Steve Jobs” no es una alucinación aleatoria; es la mejor suposición del modelo sobre cómo debería ser la historia del fundador de una famosa empresa tecnológica de Texas.

El conocimiento dentro de un modelo de lenguaje no es una lista de datos independientes. Es un grafo de datos que se refuerzan mutuamente. Edita un nodo y el grafo produce una región nueva coherente (y completamente falsa) a su alrededor.

La Configuración

Todo el conjunto son ~500 líneas en unos pocos archivos: rastreo causal, estimación de covarianza, descenso de gradiente de v*, la actualización de peso de rango 1, y un script de extremo a extremo para las cuatro ediciones.

Dependencias: torch, transformers, datasets. Nada específico de ROME.

Funciona en CPU. Cada edición toma ~3 minutos con covarianza de 200 muestras, ~15 minutos con covarianza de 2000 muestras. La configuración con covarianza correcta vale la espera.