Un componente que se detiene es barato de tolerar. El sistema nota el silencio, lo saca del quórum y sigue. Sobre ese supuesto —fail-stop— descansa casi toda la ingeniería de fiabilidad que se practica a diario: reintentos, réplicas, sondas de salud, disyuntores. Lamport, Shostak y Pease lo nombraron en 1982 precisamente para descartarlo cuando la fiabilidad exigida es alta: «it is often assumed that a computer may fail to respond but will never respond incorrectly. However, when extremely high reliability is required, such assumptions cannot be made, and the full expense of a Byzantine Generals solution is required».
Un modelo de lenguaje es exactamente el componente que obliga a pagar ese precio. No se cae: contesta. Contesta con la misma fluidez, el mismo formato y la misma seguridad aparente cuando acierta que cuando inventa un identificador, cuando clasifica mal una categoría o cuando declara «hecho» un trabajo que no hizo. Y contesta cosas distintas a partes distintas del sistema: el mismo modelo puede decirle al planificador que la herramienta existe y al validador que no, sin que ninguna de las dos respuestas sea detectable como fallo desde el sitio donde se recibe. El artículo de 1982 abre su introducción describiendo ese caso con una precisión incómoda: «A failed component may exhibit a type of behavior that is often overlooked—namely, sending conflicting information to different parts of the system».
La clasificación, por tanto, no es una metáfora: un modelo de lenguaje es, en sentido técnico, un componente bizantino. La consecuencia es la que casi nunca se saca.
Lo que el teorema pide, y lo que no
Conviene leer el artículo original antes de invocarlo, porque no dice lo que se le suele atribuir. Lamport, Shostak y Pease no postulan que los fallos de las réplicas sean estadísticamente independientes. Su modelo es adversarial, no probabilístico: los traidores pueden coordinarse, mentir de forma consistente y elegir el peor comportamiento posible —«The loyal generals will all do what the algorithm says they should, but the traitors may do anything they wish»—. Donde sí razona con probabilidades es al construir la función de firma del algoritmo SM(m), y allí distingue explícitamente el caso Random Malfunction del caso Malicious Intelligence, que remite a criptografía. Un supuesto de independencia entre procesadores defectuosos no aparece en ninguna de las páginas recuperadas.
Lo que el teorema exige es otra cosa, y es más dura: una cota sobre cuántos componentes pueden estar defectuosos. «Using this result, we can show that no solution with fewer than 3m + 1 generals can cope with m traitors». Es una condición sobre la composición del conjunto, no sobre la estadística de sus errores.
Ahí está el bien escaso, y ahí es donde se ha colado el supuesto que sí importa. La independencia nunca fue un axioma del teorema: es la excusa con la que la ingeniería ha justificado que la cota se cumple. Si tres implementaciones se desarrollan por separado —se argumentaba—, la probabilidad de que dos fallen sobre la misma entrada es el producto de dos probabilidades pequeñas, luego casi seguro que como mucho una está mal y la mayoría es correcta. Ese argumento tiene nombre propio y tiene fecha de defunción. La programación multiversión «depends for its reliability improvement on the assumption that programs that have been developed independently will fail independently», y Knight y Leveson lo sometieron a experimento en 1986: «In all, 27 versions of a program were prepared independently from the same specification at two universities and then subjected to one million tests». El resultado: «the programs were individually extremely reliable but […] the number of tests in which more than one program failed was substantially more than expected».
En junio de 2026 el experimento se repitió sustituyendo a los estudiantes por agentes de codificación, sobre la misma especificación de Knight y Leveson: «we evaluate 48 agent-generated implementations on a shared oracle and a campaign of 1,000,000 randomized test inputs». El veredicto no admite lectura amable —«The results show substantial common-mode failure, along the findings of Knight–Leveson»— y la introducción lo cuantifica: «the idealized fault independence hypothesis fails: among the 48 admitted implementations in the campaign archive, the experiment produces 429 coincident-failure cases where the random independence model predicts only 115.36 (z = 29.20)». Los fallos coincidentes se concentran donde la especificación es difícil o ambigua, no se reparten al azar.
Merece la pena decir qué no sostiene ese trabajo, porque este ensayo usa una sola de sus dos mitades. Sus autores concluyen que la diversidad entre agentes sí compra fiabilidad práctica pese a la correlación —el recuento medio de fallos baja de 387,44 a 130,99 con voto por mayoría entre tríos— y cierran diciendo que sus resultados son «the strongest evidence to date that N-Version Programming with coding agents is a useful engineering strategy». Lo desmentido es la independencia, no la utilidad de replicar; y la distinción es la que importa aquí, porque replicar mejora la media sin acotar el peor caso, y esa cota es lo que un teorema bizantino necesita para funcionar.
Conviene enunciar con cuidado dónde se rompe la analogía, porque es fácil enunciarlo mal. El
problema no es que el teorema bizantino sea falso ni que no aplique: es que su hipótesis dejó
de ser comprable. Llamar N veces al mismo modelo no produce N componentes con fallos
acotados; produce N muestras de una misma distribución de error, y sobre esas N muestras nada
garantiza la cota m ≤ (n−1)/3.
Cuánto vale realmente un voto
La afirmación anterior es medible, y desde 2025 está medida.
Sobre más de 350 modelos, dos leaderboards y una tarea de cribado de currículos, Kim, Garg, Peng y Garg encuentran que «on one leaderboard dataset, models agree 60% of the time when both models err». El matiz que destruye la salida fácil —usar proveedores distintos— está en la frase siguiente: «larger and more accurate models have highly correlated errors, even with distinct architectures and providers». La diversidad de proveedor no compra independencia; la capacidad correlaciona los aciertos y, con ellos, los errores.
Cuando esa correlación se convierte en votos, el rendimiento del panel se puede cuantificar. Un tribunal de nueve jueces de siete familias distintas, sobre tres conjuntos de inferencia natural con cien anotaciones humanas por ítem, «effectively provide only about 2 independent votes' worth of information», y el efecto sobre la exactitud no es cosmético: «the panel's actual accuracy falls 8-22 percentage points short of what independent voting would achieve». La conclusión es la que debería presidir cualquier plan de «añadamos más jueces»: «The bottleneck is correlated judges, not the aggregation algorithm, implying that scaling up panels cannot substitute for genuinely independent evaluation».
Queda la variante intramodelo, la que un motor de agentes practica sin darse cuenta cada vez que reintenta: muestrear varias veces el mismo modelo y quedarse con la mayoría. También está evaluada, y el resultado es negativo con una explicación mecánica: «aggregation fails to provide a robust truth signal because language model errors are strongly correlated». El mismo trabajo aporta la frase que conviene tener presente al diseñar cualquier juez: «under uncertainty, models are better at predicting what other models will say within model ensembles than at identifying what is true, revealing a separation between social prediction and truth verification». Un panel de modelos no mide la verdad; mide el consenso esperado de los modelos, que es otra magnitud. Y la correlación sobrevive incluso al intento de eliminarla por construcción: «even when conditioned on out of distribution random strings and asked to produce pseudo-random outputs, different models produce correlated outputs».
Más llamadas pueden incluso empeorar el resultado en términos absolutos: «the performance of both Vote and Filter-Vote can first increase but then decrease as a function of the number of LM calls», porque «more LM calls lead to higher performance on "easy" queries, but lower performance on "hard" queries».
Sobre la pregunta concreta de si un LLM detecta los fallos de otro LLM hay un dato estructural y dos duros. El estructural: un evaluador reconoce sus propias salidas con exactitud no trivial y las puntúa por encima de lo que las puntúan los humanos —«an LLM evaluator scores its own outputs higher than others' while human annotators consider them of equal quality»—, y esa preferencia crece con la capacidad de autorreconocimiento («a linear correlation between self-recognition capability and the strength of self-preference bias»). Los duros: sobre 148 trazas de agentes anotadas por humanos, «the best Gemini-2.5-pro model scoring a mere 11% on TRAIL»; y en el estudio de modos de fallo multiagente, la taxonomía se construyó «through rigorous analysis of 150 traces, guided closely by expert human annotators and validated by high inter-annotator agreement (kappa = 0.88)». Sobre esa clase de trazas, los anotadores humanos se ponen de acuerdo casi siempre sobre qué falló; el mejor modelo de contexto largo localiza el fallo una de cada nueve veces.
Existe además una formalización del caso general que acota lo que cabe esperar de encadenar verificadores. Modelando la tasa de falsa aceptación por instancia como variable latente, la fiabilidad de una cascada de k puertas deja de caer exponencialmente y, si hay un punto ciego compartido, deja de caer: «a blind-spot atom of mass 1−π at α=1 caps the evidence extractable from any number of gates at −ln(1−π) nats, so reliability saturates below 1». El mismo trabajo cifra el error de calcular con independencia —«independence-based extrapolation underestimates failure by 20x at k=5 and ~3000x at k=10»— y nombra la palanca real: «The practical lever is decorrelation -- changing model family, modality, or evidence source -- not adding gates».
De todo esto se sigue una regla de ingeniería, no una opinión: la cota bizantina no se paga con más llamadas al modelo. Si la verificación tiene que ser fiable, la parte que decide debe vivir fuera del componente bizantino.
Tres reglas de ALLAN que son la misma regla
En el corpus de diseño de ALLAN esta conclusión no aparece enunciada como teorema. Se descubrió tres veces, por caminos separados, y cada vez se escribió como una regla local. Vistas juntas son el mismo movimiento: sacar la decisión del alcance del fallo y ponerla en un artefacto que no puede ser bizantino —una cuenta aritmética, un tipo de datos, un reloj—.
El juez estructural de la memoria colectiva. La capa colectiva promueve un hecho sobre un
usuario cuando varios agentes lo han aprendido por separado. Para eso hay que decidir dos
cosas: si dos enunciados dicen lo mismo, y si esa coincidencia es evidencia. Lo primero exige
comprensión lectora, y el diseño descarta explícitamente resolverlo de otro modo: «Nunca
matching textual: dos agentes casi nunca guardan el mismo hecho con las mismas palabras»
(docs/arquitectura/collective-memory-design.md:199-200). Lo segundo no exige comprensión
ninguna, y el diseño lo saca del modelo con nombre propio: «Corroboración verificable, no
intuición» (íd. :203).
El corte está en el código. El prompt del juez termina con «No juzgues si un hecho es verdadero:
solo estructura» (responses_api/cmem/judge.py:51), y la cabecera del módulo declara qué queda
fuera: «The verifiable parts — distinct agents, distinct sessions, thresholds, recency — stay in
consensus.py, outside the model» (judge.py:8-10). Es literalmente cierto: quien cuenta los
agentes distintos y las sesiones distintas es _corroboration (consensus.py:304-332), un
bucle sobre episodios recuperados del almacén; y quien comprueba las cotas son dos
condicionales sin modelo, len(corroboration.agents) < s.min_agents y
len(corroboration.sessions) < s.min_sessions (consensus.py:424-427), con ambos umbrales
fijados en 2 (config.py:35-36). La exigencia de sesiones distintas, además de agentes
distintos, está puesta para que N proyecciones de una misma conversación no cuenten como
consenso.
El reparador que no ve la puntuación. Cuando la validación de un agente recién forjado
falla, la sesión ofrece una tercera respuesta además de descartar o ignorar el veredicto:
reparar. El riesgo evidente es que el reparador optimice contra el examinador en lugar de
contra el defecto, y el corpus prohíbe esa vía en una frase: «Un reparador que puede leer el
examen optimiza contra el examinador; uno que solo lee la queja tiene que arreglar el agente»
(docs/agentes/agent-forge-design.md:270). Lo interesante es cómo se hace cumplir. No hay
instrucción en el prompt: hay ausencia de campo. BundleEditInstructions tiene exactamente
cinco —nombre, propósito, idioma, correcciones y restricciones (internal/forge/pipeline.go:111-124)—
y su comentario declara la omisión como regla: «Deliberately narrow: it carries the fixes and
the context needed to apply them, and nothing about how the agent was scored»
(pipeline.go:107-110). La única construcción del valor en todo el flujo de reparación
(repair.go:219-224) rellena esos cinco campos y no hay ninguna otra.
El mismo enrutado saca de circulación una clase entera de hallazgos: los de gobernanza —nivel
de autonomía, política de aprobación, riesgo aceptable— no se envían a ningún reparador porque
«un bucle que las "arreglara" estaría anulando en silencio a quien trabaja para él» (íd.
:269). En el código eso es Repairable() devolviendo falso para TargetGovernance
(internal/forge/validation_report.go:88-91), y el comentario del tipo explica por qué esos
valores salen de una tabla fija: «precisely so a model does not get to choose them»
(íd. :82-84).
El vigilante que no puede vigilarse. El motor supervisa esperas largas con arrendamientos
renovables: cuando un lease vence, un watchdog decide si renovar, corregir el rumbo, cancelar
la operación o escalar a una persona (internal/agents/watchdog.go:18-22). El watchdog es un
modelo. La pregunta obvia es quién lo vigila a él, y la respuesta del diseño es que nadie, a
propósito: el evaluador usa «un timeout no-renovable — el propio evaluador NO usa lease, para no
arriesgar recursión infinita "quién vigila al vigilante"»
(docs/arquitectura/intelligent-wait-supervision-design.md:478-479). En el código es
watchdogEvalTimeout = 15 * time.Second, con un comentario que enuncia la razón: «a watchdog
that could get stuck waiting on its own judgment call would defeat the point»
(watchdog.go:28-34).
La segunda mitad de la regla importa tanto como la primera. Si el veredicto no se puede obtener
—error del modelo, expiración, JSON ilegible, acción inválida— el resultado no es «no sé», es
RENEW (watchdog.go:106-114, más el parser que rechaza toda acción fuera de las cuatro,
:236-262). La recursión se corta con un valor por defecto
estructural, y el valor se elige por asimetría de coste: en un lease lo caro es matar una
operación viva, así que el fallo del evaluador renueva; cuando lo que se agotó es el presupuesto
declarado de un run, lo caro es seguir gastando, y el mismo fallo devuelve INTERVENE
(watchdog.go:202, :225, :230). Ninguna de las dos ramas consulta a un segundo modelo.
Las tres reglas dicen lo mismo con materiales distintos: la corroboración se protege con
aritmética; la reparación, con la forma de un struct; la supervisión, con un reloj y un valor
por defecto. Ninguna intenta comprar independencia entre modelos, porque no está a la venta.
Invariantes, enunciados para que se puedan romper
Un hecho colectivo nunca se promueve con evidencia de un solo agente ni de una sola sesión, y
esa comprobación no pasa por ningún modelo: se cuenta sobre episodios recuperados del almacén
(consensus.py:424-427). Un clúster con menos de min_agents agentes distintos ni siquiera
llega al juez, porque la puerta previa lo descarta antes de gastar la llamada
(consensus.py:240).
Un reparador automático nunca recibe una puntuación, un umbral, una rúbrica ni la transcripción
de un juez. La garantía no es de comportamiento sino de tipo: no existe campo donde ponerlos
(pipeline.go:111-124). Corolario falsable: si alguien añade un campo Score a
BundleEditInstructions, el invariante desaparece aunque el prompt siga diciendo lo mismo.
Los hallazgos de gobernanza no se reparan nunca, y las restricciones que acompañan a una cirugía
prohíben explícitamente debilitar un eval —«Do not weaken an eval's criteria. The evals are how
this agent is measured; making the measurement easier is not a fix» (repair.go:336)—. Los
intentos están acotados a dos (repair.go:55) y cada intento se compara con el anterior por
huella SHA-256 calculada sobre (check, path, field, source, título, fix)
(validation_report.go:148-161), estable frente a la reescritura de la prosa, de modo que «no
converge» es un estado observable y no una impresión.
El evaluador del watchdog no corre bajo lease y su fallo nunca cancela una operación viva.
Corolario falsable: cualquier cambio que envuelva Watchdog.evaluateWithModel en runWithLease
reintroduce la recursión que el diseño excluye.
Y dos garantías que la plataforma no da, porque es donde un lector supondría lo contrario: nada obliga a que el supervisor y el supervisado sean modelos distintos, y «dos agentes distintos» no significa «dos modelos distintos».
Lo que está roto, sin terminar o sin evidencia
ALLAN aplica bien la regla en los tres sitios donde la descubrió, y la incumple donde más caro sale.
Examinador y reparador comparten clave de configuración. En el pipeline de Forge, el
diseñador de evals, el generador de escenarios, el juez de rúbrica, el equipo rojo y el guardián
resuelven todos contra models.RoleReasoning (internal/agents/eval_engine.go:501, :518,
:543, :560, :579); los artefactos del agente se generan con el mismo rol
(internal/agents/prompt_engine.go:64-71); y el cirujano que repara lo que el juez suspendió
llama a GenerateWithTools(ctx, models.RoleReasoning, …) (internal/reviser/tools.go:116). Peor
que eso: la validación (pipeline.go:508), la reparación (repair.go:169) y el cirujano
(reviser/tools.go:114, reviser/reviser.go:115) se etiquetan los tres con el mismo consumidor,
models.ConsumerForge = "engine.forge", y el comentario del tipo explica que el reviser no
tiene consumidor propio a propósito (internal/models/context.go:107-110). Como la asignación
por consumidor de la página «Modelos y proveedores» anula el rol cuando fija un modelo
(prompt_engine.go:67-70), la consecuencia es estructural y no probabilística: no existe
ninguna configuración de la plataforma que permita que el juez y el reparador sean modelos
distintos. La guarda anti-Goodhart —no ver el marcador— sigue siendo válida y sigue siendo
útil: impide optimizar contra el examinador. Lo que no compra, y el corpus no afirma que
compre, es independencia de puntos ciegos: un defecto que el juez no ve es un defecto que el
reparador tampoco verá, y el techo de la cascada de verificadores aplica en su forma más pura.
«Dos agentes distintos» no son dos modelos distintos. La corroboración de la memoria
colectiva cuenta identidades de agente, y esa cuenta es honesta respecto de lo que dice contar.
Pero los hechos que compara no los escribió cada agente con su propio modelo: el extractor de
memoria es una sola llamada models.RoleFast (internal/memory/extraction.go:112, comentario
en :14) etiquetada con models.ConsumerMemory (:109), y ese consumidor es una única clave de
asignación para toda la plataforma (internal/models/context.go:52-59). El usuario puede elegir
modelo por agente para la conversación (WithModelOverride, context.go:14-20), pero el paso
que decide qué hecho se guarda corre siempre en el mismo modelo. Lo que la puerta de ≥2
agentes y ≥2 sesiones decorrelaciona es la entrada: dos conversaciones distintas, con dos
personas de agente distintas. Lo que no decorrelaciona es el extractor. Un sesgo sistemático del
extractor —leer una cortesía como preferencia declarada, por ejemplo— se reproduce en las dos
particiones y llega a la aritmética disfrazado de consenso. El invariante correcto, enunciado
para que se pueda refutar, es este: la corroboración de CMEM protege contra el ruido de muestreo
de una conversación, no contra un sesgo sistemático del extractor.
El juez «solo estructural» tiene poder generativo. La descripción es exacta en cuanto a lo
que el juez no hace —no decide si un hecho es verdad, no cuenta agentes, no cuenta sesiones— e
incompleta en cuanto a lo que sí hace. El juez elige la partición: members = [cluster.facts[m] for m in group.members] (consensus.py:257), y la corroboración se cuenta
sobre esos miembros. Un juez que agrupe mal dos hechos no equivalentes procedentes de dos
agentes fabrica una corroboración que la aritmética posterior valida sin objeción. Y el enunciado
que acaba inyectándose en las conversaciones lo redacta el propio modelo: el prompt le pide
«redacta el enunciado canónico en español» (judge.py:35). El daño está acotado por dos puertas
previas —solo entran clústeres con similitud ≥ 0,80 (config.py:41) y ≥ 2 agentes
(consensus.py:240)— y por la lista blanca de categorías (config.py:52), pero acotado no es
nulo. «Corroboración verificable, no intuición» describe la mitad numérica del algoritmo, no el
algoritmo entero. A favor de CMEM juega un detalle de despliegue que el diseño no previó: el
juez no usa el RoleFast del motor que el documento anuncia
(collective-memory-design.md:198), sino su propio extremo configurable
—CMEM_LLM_BASE_URL/CMEM_LLM_MODEL, exigidos en el constructor (judge.py:178-182,
config.py:94-96)—, de modo que aquí sí es posible poner una familia de modelo distinta de la
del extractor. Que nadie lo haya exigido en ningún sitio es otra cuestión.
Del watchdog escalonado solo existe el peldaño barato. El diseño describe una escalera de
coste con heurísticas deterministas primero: detección de bucle por hash de (tool, args) en
ventana deslizante, y delta de estado entre vencimientos
(intelligent-wait-supervision-design.md:197-204). Ninguna de las dos se construyó, y la nota de
alcance lo reconoce como decisión, no como olvido: «no se construyó un detector de bucles por
hash (tool,args) cruzando todo el run […] no hay liveness-tracking basado en tokens» (íd.
:501-507). Lo que queda es un contador de renovaciones libres (defaultMaxFreeRenewals = 2,
watchdog.go:39), que es un presupuesto, no una heurística: no observa nada del run. Es decir,
la única parte no bizantina de la escalera —la que decidiría por evidencia estructural en lugar
de por juicio— es justamente la que no existe. Además ESCALATE «por ahora produce un run
fallido con mensaje claro, no una pausa real» (íd. :508-510), y los veredictos «solo se logean
vía debugf» (íd. :510-511), de modo que no hay traza consultable con la que auditar si el
vigilante acierta.
Hay un consuelo parcial y conviene registrarlo: el watchdog sí está configurado para poder ser
otro modelo. Corre con models.RoleFast bajo models.ConsumerWatchdog
(watchdog.go:104, :221; context.go:104), una clave de asignación que ninguna otra llamada
del motor comparte, mientras que los pasos que supervisa —raíz y worker— usan
models.RoleReasoning (swarm_loop_v3.go:961, :1618, :1874). La decorrelación que Han
nombra como única palanca real —cambiar de familia de modelo— es aquí posible; en Forge es
imposible. Nadie la ha exigido en ningún sitio.
También conviene registrar el caso conocido en que el vigilante falló de forma bizantina, porque
está fechado en el propio código: un run que acababa de paginar 100 de 204 registros de un CRM
fue cortado con el argumento «with only 2 steps used ... the task may require many more steps»,
leyendo un presupuesto declarado pequeño como «el agente apenas ha empezado»
(watchdog.go:122-128). La corrección consistió en darle contadores medidos en lugar de una cola
de transcripción (BudgetCheckpoint, :129-136) y en trasladar la asimetría de coste al propio
prompt: «a wrong RENEW costs one more checkpoint while a wrong INTERVENE discards work already
paid for» (:216). Vale la pena ver lo que eso significa: parte de la asimetría que antes vivía
en un valor por defecto estructural vive ahora en una instrucción que el modelo puede ignorar.
Es un retroceso pequeño respecto de la doctrina, hecho por buenas razones, y no está anotado como
tal en ningún sitio.
No hay medición propia. Todo lo cuantitativo de este ensayo procede de la literatura. En el
repositorio no consta ninguna medición de correlación de errores entre llamadas de ALLAN a su
propio modelo, ni de acuerdo entre el juez de validación y una anotación humana, ni de tasa de
falsos RENEW del watchdog. El diseño de la memoria colectiva anota la pregunta correcta como
riesgo declarado —«Consenso ≠ verdad» (collective-memory-design.md:394)— y le asigna como
mitigación exigir sesiones distintas además de agentes distintos, que es precisamente la
mitigación cuyo alcance queda acotado más arriba. Sin instrumentación, la afirmación de que las
tres reglas funcionan descansa en el argumento estructural: sólido sobre lo que impide, mudo
sobre lo que ocurre.
La síntesis cabe en dos frases. Un modelo de lenguaje es un componente bizantino, y la cota de componentes defectuosos que el teorema exige no se compra replicando el modelo, porque los errores del mismo modelo —y los de modelos distintos de capacidad parecida— están correlacionados de forma medida y sustancial. Lo único que sí se puede comprar es un componente que no sea bizantino en el punto donde se decide: una cuenta, un tipo, un reloj. ALLAN lo hizo tres veces sin saber que hacía lo mismo, y en Forge todavía no lo ha hecho.
Referencias
-
Lamport, L.; Shostak, R.; Pease, M. (1982). The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems 4(3):382-401. https://lamport.azurewebsites.net/pubs/byz.pdf — PDF recuperado y leído directamente (páginas 382-385 y 398-401). «A failed component may exhibit a type of behavior that is often overlooked—namely, sending conflicting information to different parts of the system.» (p. 382). «The loyal generals will all do what the algorithm says they should, but the traitors may do anything they wish.» (p. 383). «Using this result, we can show that no solution with fewer than 3m + 1 generals can cope with m traitors.» (p. 385). «Achieving reliability in the face of arbitrary malfunctioning is a difficult problem, and its solution seems to be inherently expensive. The only way to reduce the cost is to make assumptions about the type of failure that may occur. For example, it is often assumed that a computer may fail to respond but will never respond incorrectly. However, when extremely high reliability is required, such assumptions cannot be made, and the full expense of a Byzantine Generals solution is required.» (p. 401). Nota de lectura: en las páginas recuperadas no aparece ningún supuesto de independencia estadística entre réplicas. El modelo del artículo es adversarial y lo que exige es una cota sobre el número de componentes defectuosos («we can only guarantee that these algorithms will work in the presence of up to m failures, be they processor or communication line failures», p. 398). El razonamiento probabilístico que sí contiene es sobre la falsificación de firmas, y distingue «Random Malfunction» de «Malicious Intelligence» (p. 400). Atribuir a este artículo un «supuesto de independencia» es incorrecto: ese supuesto pertenece a la programación multiversión, y el encargo que originó este ensayo lo daba por sentado. Cambiar esa premisa es la corrección de fondo del texto.
-
Knight, J. C.; Leveson, N. G. (1986). An Experimental Evaluation of the Assumption of Independence in Multiversion Programming. IEEE Transactions on Software Engineering 12(1):96-109. «This method depends for its reliability improvement on the assumption that programs that have been developed independently will fail independently.» «In all, 27 versions of a program were prepared independently from the same specification at two universities and then subjected to one million tests.» «The results of the tests revealed that the programs were individually extremely reliable but that the number of tests in which more than one program failed was substantially more than expected.» PARCIALMENTE VERIFICADA. El artículo está tras el muro de pago de IEEE Xplore y no se ha podido recuperar. Las tres frases proceden de una reproducción literal del resumen incluida en un documento de seminario de KTH (https://www.csc.kth.se/utbildning/kth/kurser/DA2210/vettig13/Seminarier/KnightLeveson.pdf), recuperado y leído en esta sesión. No se ha leído el cuerpo del artículo, de modo que ninguna afirmación de este ensayo depende de nada que no esté en su resumen.
-
Ron, J.; Baudry, B.; Monperrus, M. (2026). N-Version Programming with Coding Agents. arXiv:2606.20158v1, 18 jun. 2026. https://arxiv.org/abs/2606.20158 — PDF recuperado y leída la página 1 (resumen e introducción). «Using the Knight–Leveson's, Launch Interceptor Program Specification, we evaluate 48 agent-generated implementations on a shared oracle and a campaign of 1,000,000 randomized test inputs. The results show substantial common-mode failure, along the findings of Knight–Leveson.» (resumen). «First, the idealized fault independence hypothesis fails: among the 48 admitted implementations in the campaign archive, the experiment produces 429 coincident-failure cases where the random independence model predicts only 115.36 (z = 29.20), and strong pairwise clusters can be observed across both language and agent boundaries.» (introducción). «across majority voting three-version units, the mean failure count drops from 387.44 for single versions to 130.99 for triples, and 11,844 N-version units exhibit zero observed failures. Our original results is [sic] the strongest evidence to date that N-Version Programming with coding agents is a useful engineering strategy.» (resumen). Advertencia de uso: este ensayo emplea solo la mitad negativa de un trabajo cuya conclusión general es positiva. Lo que el artículo desmiente es la independencia, no la utilidad de la replicación. Corrección de esta revisión: una versión anterior transcribía «Our original results are»; el resumen del preprint dice «is», con la concordancia rota, y se cita tal cual.
-
Kim, E.; Garg, A.; Peng, K.; Garg, N. (2025). Correlated Errors in Large Language Models. arXiv:2506.07962, 9 jun. 2025. https://arxiv.org/abs/2506.07962 — resumen recuperado íntegro. «We find substantial correlation in model errors -- on one leaderboard dataset, models agree 60% of the time when both models err.» «Crucially, however, larger and more accurate models have highly correlated errors, even with distinct architectures and providers.»
-
Kohli, G. (2026). Nine Judges, Two Effective Votes: Correlated Errors Undermine LLM Evaluation Panels. arXiv:2605.29800, 28 may. 2026. https://arxiv.org/abs/2605.29800 — resumen recuperado íntegro. «we find that the 9 judges effectively provide only about 2 independent votes' worth of information.» «the panel's actual accuracy falls 8-22 percentage points short of what independent voting would achieve, and the best single judge matches or outperforms the full panel across all conditions.» «The bottleneck is correlated judges, not the aggregation algorithm, implying that scaling up panels cannot substitute for genuinely independent evaluation.»
-
Denisov-Blanch, Y.; Kazdan, J.; Chudnovsky, J.; Schaeffer, R.; Guan, S.; Adeshina, S.; Koyejo, S. (2026). Consensus is Not Verification: Why Crowd Wisdom Strategies Fail for LLM Truthfulness. arXiv:2603.06612, 20 feb. 2026. https://arxiv.org/abs/2603.06612 — resumen recuperado íntegro y verbatim. «Across models and benchmarks, aggregation fails to provide a robust truth signal because language model errors are strongly correlated.» «We find that under uncertainty, models are better at predicting what other models will say within model ensembles than at identifying what is true, revealing a separation between social prediction and truth verification.» «The source of correlation goes beyond any individual benchmark: we show that even when conditioned on out of distribution random strings and asked to produce pseudo-random outputs, different models produce correlated outputs.»
-
Chen, L.; Davis, J. Q.; Hanin, B.; Bailis, P.; Stoica, I.; Zaharia, M.; Zou, J. (2024). Are More LLM Calls All You Need? Towards Scaling Laws of Compound Inference Systems. arXiv:2403.02419, mar. 2024 (rev. jun. 2024; NeurIPS 2024). https://arxiv.org/abs/2403.02419 — resumen recuperado íntegro y verbatim. «We find, surprisingly, that across multiple language tasks, the performance of both Vote and Filter-Vote can first increase but then decrease as a function of the number of LM calls.» «more LM calls lead to higher performance on "easy" queries, but lower performance on "hard" queries, and non-monotone behavior can emerge when a task contains both types of queries.»
-
Panickssery, A.; Bowman, S. R.; Feng, S. (2024). LLM Evaluators Recognize and Favor Their Own Generations. arXiv:2404.13076, 15 abr. 2024. https://arxiv.org/abs/2404.13076 — resumen recuperado íntegro. «One such bias is self-preference, where an LLM evaluator scores its own outputs higher than others' while human annotators consider them of equal quality.» «By fine-tuning LLMs, we discover a linear correlation between self-recognition capability and the strength of self-preference bias.»
-
Deshpande, D.; Gangal, V.; Mehta, H.; Krishnan, J.; Kannappan, A.; Qian, R. (2025). TRAIL: Trace Reasoning and Agentic Issue Localization. arXiv:2505.08638, 13 may. 2025 (rev. 23 jun. 2025). https://arxiv.org/abs/2505.08638 — resumen recuperado íntegro. «we […] present a set of 148 large human-annotated traces (TRAIL) constructed using this taxonomy and grounded in established agentic benchmarks.» «Our evaluations reveal that modern long context LLMs perform poorly at trace debugging, with the best Gemini-2.5-pro model scoring a mere 11% on TRAIL.»
-
Cemri, M.; Pan, M. Z.; Yang, S.; Agrawal, L. A.; Chopra, B.; Tiwari, R.; Keutzer, K.; Parameswaran, A.; Klein, D.; Ramchandran, K.; Zaharia, M.; Gonzalez, J. E.; Stoica, I. (2025). Why Do Multi-Agent LLM Systems Fail? arXiv:2503.13657, 17 mar. 2025 (rev. 26 oct. 2025). https://arxiv.org/abs/2503.13657 — resumen recuperado íntegro. «We develop MAST through rigorous analysis of 150 traces, guided closely by expert human annotators and validated by high inter-annotator agreement (kappa = 0.88).» «This process identifies 14 unique modes, clustered into 3 categories: (i) system design issues, (ii) inter-agent misalignment, and (iii) task verification.»
-
Han, J. (2026). Partially Correlated Verifier Cascades in LLM Harnesses: Concave Log-Odds, Polynomial Reliability, and Blind-Spot Ceilings. arXiv:2607.13918, 15 jul. 2026. https://arxiv.org/abs/2607.13918 — resumen recuperado íntegro. «a blind-spot atom of mass 1−π at α=1 caps the evidence extractable from any number of gates at −ln(1−π) nats, so reliability saturates below 1.» «In synthetic tests, independence-based extrapolation underestimates failure by 20x at k=5 and ~3000x at k=10; the correlated fit at R=8 tracks held-out depths.» «The practical lever is decorrelation -- changing model family, modality, or evidence source -- not adding gates.»
-
Huang, J.; Chen, X.; Mishra, S.; Zheng, H. S.; Yu, A. W.; Song, X.; Zhou, D. (2023). Large Language Models Cannot Self-Correct Reasoning Yet. arXiv:2310.01798, 3 oct. 2023 (rev. 14 mar. 2024; ICLR 2024). https://arxiv.org/abs/2310.01798 — resumen recuperado íntegro. «In the context of reasoning, our research indicates that LLMs struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction.»