DEV Community: lu1tr0n

Qwen3-4B deslop corta las muletillas de IA de 121 a 12,5 por 1000 palabras

lu1tr0n — Mon, 19 Oct 2026 14:31:14 +0000

Un ingeniero entrenó a Qwen3-4B para que dejara de escribir como una IA: el puntaje de muletillas de IA bajó de 121 a 12,5 por cada 1.000 palabras, y los guiones largos retóricos pasaron de 20,5 por 1.000 palabras a cero, según documenta el propio autor.

El resultado se llama qwen3-4b-deslop y pesa 2,5 GB en su versión cuantizada. Cualquiera puede descargarlo con Ollama y comparar, prompt por prompt, cómo responde frente al modelo original. No es un experimento de laboratorio cerrado: es un modelo público que corre en una laptop.

TL;DR

El puntaje de muletillas de IA de Qwen3-4B-deslop cae de 121 a 12,5 por 1.000 palabras tras el fine-tuning.- Los guiones largos (em dash) desaparecen por completo: de 20,5 por 1.000 palabras a cero.- RLHF premia el tono que suena 'servicial', y ese sesgo es el origen de los tics de escritura de la IA.- Un LoRA sobre 161 respuestas filtradas quita las muletillas sin tocar el conocimiento: acierta 30/30 preguntas.- Ollama corre el modelo cuantizado (2,5 GB) en tu laptop para comparar el antes y el después en tus propios prompts.

¿Qué son las muletillas de IA?

Las muletillas de IA son fragmentos de estilo que un modelo de lenguaje repite con tanta frecuencia que delatan su origen artificial: el guion largo como pausa dramática, los tríos de adjetivos, la fórmula "no es X, sino Y" y las preguntas que el propio texto responde de inmediato.

Es parecido a lo que pasa con un vendedor que aprende, a fuerza de repetir el mismo discurso, qué frases hacen asentir a la mayoría de la gente aunque no digan nada nuevo. El modelo no entiende que esas frases son vacías: solo sabe que, en el entrenamiento, subieron su calificación.

No son errores aleatorios. Vienen del mismo proceso de entrenamiento, y por eso aparecen con la misma forma en modelos de laboratorios distintos. Entender de dónde salen es el primer paso para poder quitarlas sin dañar lo que el modelo sabe.

Por qué aparecen: el sesgo de RLHF hacia la aprobación humana

El afinado que le da a un modelo su "voz de asistente" se llama aprendizaje por refuerzo con retroalimentación humana (RLHF). Un grupo de personas califica pares de respuestas, un modelo de recompensa aprende a predecir esas calificaciones y el modelo final se ajusta para maximizar esa puntuación.

El problema es que los calificadores humanos no leen con la misma atención que un editor. Premian respuestas que "se sienten" completas y seguras, y ciertos adornos superficiales generan esa sensación sin aportar información real. Un trío de adjetivos suena exhaustivo. Una pregunta respondida en la misma frase suena didáctico. Un guion largo en mitad de la oración suena a pausa reflexiva. Nada de eso añade un dato, pero sí sube la calificación promedio.

Por eso los tics de escritura de la IA no son un capricho de un modelo en particular, sino el subproducto estadístico de optimizar para el gusto promedio de miles de calificadores. Y como el proceso se repite en cada laboratorio con metodologías parecidas, los mismos hábitos aparecen en modelos que nunca compartieron código ni datos de entrenamiento.
El modelo original promediaba 121 puntos de muletillas por 1.000 palabras.

Cómo funciona el fine-tuning dirigido para quitarlas

Antes de tocar los pesos del modelo, el autor probó dos atajos que no requieren reentrenar nada. El primero fue el "activation steering": restar, durante la generación, la dirección interna que corresponde a la "voz de asistente", combinada con un prompt de sistema que pide un estilo plano. Funciona, y bajó el puntaje hasta cerca de 15, pero necesita ese prompt y ese código corriendo en cada respuesta, y además desvía las predicciones del modelo sobre texto normal que no tiene nada que ver con el estilo.

El segundo atajo fue más quirúrgico: revisar neuronas una por una hasta encontrar cuatro cuya activación, si se invierte, elimina el 70% de los casos de "no es X, sino Y" casi sin costo. Pero ese parche solo funciona para esa muletilla puntual y no generaliza al resto de los hábitos.

Para resolverlo de forma permanente, dentro de los pesos y sin hooks en tiempo de ejecución, el autor usó destilación. Un modelo "profesor" (construido con lo mejor que había funcionado hasta ese punto) genera respuestas a un conjunto de prompts de entrenamiento. Las respuestas que pasan los filtros de calidad alimentan un adaptador LoRA pequeño, que aprende a producir ese mismo estilo a partir del prompt original, sin el profesor ni el código extra.

flowchart TD
A["Profesor genera 3 respuestas por prompt"] --> B["Filtro: puntaje de muletillas bajo 12"]
B --> C["Filtro: sin daño (deriva y quiz de 30 preguntas)"]
C --> D["Filtro: la respuesta cumple la tarea pedida"]
D --> E["LoRA aprende del subconjunto aprobado"]
E --> F["Modelo estudiante Qwen3-4B-deslop"]

La primera ronda de este proceso, sin gancho de estilo ni esteroides de prompt, ya bajó el puntaje a cerca de 20. Fue la prueba de que destilar funciona mejor que forzar el estilo en tiempo de ejecución.

flowchart LR
R1["Ronda 1: puntaje cercano a 20"] --> R2["Ronda 2: puntaje 9.9, pero falla el ajuste a la tarea"]
R2 --> R3["Ronda 3: puntaje 12.5, ajuste a la tarea en 80%"]

El detector de tics de escritura: cómo se mide el puntaje

Para saber si el modelo mejoró, hace falta medir, no solo mirar. El detector que usa el autor mide patrones de escritura de IA con un conjunto de reglas con pesos. Cuenta guiones largos, apariciones de "no es X, sino Y", tríos de tres elementos, preguntas retóricas respondidas en la misma frase, muletillas de transición como "aquí está la clave" y palabras como "delve" o "seamless" en inglés (sus equivalentes en español serían "profundizar en" o "sin fisuras" usados como relleno). Cada hábito pesa distinto, y la suma se normaliza por cada 1.000 palabras.

Un detector basado en reglas no distingue por sí solo buena de mala escritura, así que el autor también revisó manualmente una muestra de respuestas en cada ronda. Un regex puede contar guiones largos, pero no puede decir si el párrafo que los rodea tiene sentido.

flowchart LR
T["Texto generado"] --> H1["Cuenta guiones largos"]
T --> H2a["Cuenta 'no es X, sino Y'"]
T --> H3a["Cuenta preguntas que se responden solas"]
H1 --> S["Suma ponderada"]
H2a --> S
H3a --> S
S --> P["Puntaje por 1.000 palabras"]

Para ilustrar la idea, este es un detector simplificado en Python que cualquiera puede correr sobre un párrafo propio:

import re

def slop_score(text):
    words = len(text.split())
    em_dashes = text.count(", ")
    not_x_but_y = len(re.findall(r"no es .*?, sino", text, re.IGNORECASE))
    rhetorical = len(re.findall(r"\?\s*[A-ZÁÉÍÓÚ]", text))
    raw = em_dashes * 3 + not_x_but_y * 4 + rhetorical * 2
    return round(raw / words * 1000, 1)

texto = "El framework no es solo rápido, es, ante todo, elegante. ¿Por qué importa? Porque resuelve tres problemas: velocidad, memoria y legibilidad."
print(slop_score(texto))

Con ese párrafo de ejemplo (que acumula un guion largo y una pregunta respondida en la misma frase), la función devuelve 227.3. Es un juguete de diez líneas, no el detector real del autor, pero muestra el principio: contar patrones, no juzgar el tema.

Ejemplos prácticos: antes y después

El autor probó el modelo con 40 prompts que nunca vio en entrenamiento, repartidos en diez temas y cuatro géneros: reseña de producto, publicación personal, pieza de opinión y correo. En el modelo original, una pieza de opinión sobre el nuevo CRM de una empresa (ver el detalle en la publicación original) nunca tomaba una postura: leía como un reporte de incidente, lleno de guiones largos y tríos de beneficios.

Una versión intermedia del modelo, entrenada antes de ajustar bien los filtros, se fue al otro extremo: bajó el puntaje de muletillas a 9,9, pero empezó a inventar datos. Citó un estudio de una universidad que no existe, y encadenó casi todas las oraciones con ", which" (el equivalente sería encadenar todo con ", lo cual" o ", así que"), 28 veces más seguido que el modelo original. Ese hábito nuevo venía del propio prompt que el autor le dio al profesor, que pedía unir oraciones "con porque, así que, pero, lo cual", y dos rondas de imitación lo habían amplificado sin querer.

El filtro de ajuste a la tarea que añadió la tercera ronda no es un detector de estilo, sino un conjunto de reglas específicas por género. Un correo tiene que abrir con un saludo. Una reflexión personal tiene que estar en primera persona. Una pieza de opinión tiene que tomar postura temprano. Y la longitud tiene que acercarse a lo que pidió el prompt. Esas reglas, sumadas a contar las uniones con ", lo cual" y los estudios inventados, fueron las que detectaron el problema de la versión intermedia.

La versión final, entrenada con ese filtro adicional, subió apenas de 9,9 a 12,5 en el puntaje de muletillas, pero recuperó el ajuste a la tarea: del 60% de la versión intermedia al 80% del modelo original. Las uniones con ", lo cual" bajaron de 1,4 a 0,3 por cada 100 palabras.

⚠️ Ojo: optimizar solo por el puntaje de muletillas, sin medir si la respuesta cumple la tarea, produce un modelo que escribe plano pero inventa datos y evita tomar postura.

Cómo empezar: correr Qwen3-4B-deslop en Ollama

Para probarlo hace falta tener Ollama instalado. En Linux y macOS, el comando es:

curl -fsSL https://ollama.com/install.sh | sh

En Windows, el instalador se descarga directamente desde ollama.com/download. Con Ollama corriendo, el modelo cuantizado (2,5 GB) se descarga y arranca con un solo comando:

ollama run hf.co/erikkannike/qwen3-4b-deslop-v4-GGUF:Q4_K_M

La primera vez, Ollama descarga el manifiesto y las capas del modelo, verifica su integridad y las guarda en disco. Cuando termina, abre un prompt interactivo donde se puede escribir directamente. Para comparar contra el modelo original, basta correr en otra terminal:

ollama run qwen3:4b

Y hacerle la misma pregunta a los dos. La diferencia de estilo entre ambas respuestas, el original lleno de guiones largos y tríos, el deslop más plano y directo, es el experimento que el propio autor invita a repetir.

Para confirmar qué se descargó, ollama list muestra el nombre del modelo, su tamaño y la fecha de modificación en una tabla de texto. Y ollama show hf.co/erikkannike/qwen3-4b-deslop-v4-GGUF:Q4_K_M imprime la cuantización, el tamaño de contexto y la familia del modelo.
Qwen3-4B-deslop pesa 2,5 GB cuantizado y corre con un comando de Ollama.

Casos de uso reales

El caso de uso más directo es el control de calidad editorial: pasar un borrador generado por IA por un detector de hábitos de redacción sintética antes de publicarlo, igual que se corre un linter sobre código antes de un commit. Un medio o un canal técnico puede usarlo como filtro automático antes de que un editor humano revise el texto.

También sirve como base para fine-tuning propio. El LoRA que produce qwen3-4b-deslop es chico, y el método (profesor que genera, filtros que aprueban, adaptador que aprende) se puede aplicar a cualquier estilo que se quiera reforzar o eliminar: no solo tics de escritura, también jerga corporativa, un tono de marca específico o un idioma de salida constante.

Y hay un caso de uso educativo, que es el que motiva este artículo: correr el modelo original y el deslop lado a lado deja ver, en texto real y no en una tabla de benchmarks, qué efecto tiene exactamente el fine-tuning sobre el estilo de una IA.

Errores comunes y buenas prácticas

Medir solo el estilo: un detector de muletillas no avisa si el modelo inventó un dato o evitó responder lo que se le pidió. Hace falta un chequeo de ajuste a la tarea en paralelo, no después.- Confiar en el prompt del profesor sin auditarlo: el hábito de unir cada oración con ", lo cual" salió del propio prompt que pedía conectores variados. Revisar las respuestas del profesor antes de usarlas para entrenar evita amplificar un sesgo nuevo.- Usar un solo filtro de daño: un quiz de conocimiento no detecta que el modelo dejó de tomar postura en una opinión. Hacen falta chequeos específicos por género de texto.- Tratar el puntaje como verdad absoluta: un regex cuenta patrones, no calidad. Revisar manualmente una muestra en cada ronda de entrenamiento sigue siendo necesario.

Comparativa: tres formas de quitar los manierismos del modelo

MétodoCuándo usarloVentajaLimitaciónPrompt de sistemaPruebas rápidas, sin acceso a los pesosNo requiere entrenar nadaEl efecto es parcial y se pierde si el prompt se recortaActivation steeringCuando se puede ejecutar código propio en la inferenciaBajó el puntaje a cerca de 15 sin tocar los pesosNecesita el hook corriendo siempre y desvía las predicciones en texto normalFine-tuning con LoRA (destilación)Cuando se quiere un modelo que se comporte así por defectoQueda dentro de los pesos, sin prompt ni código extra, con un tercio de la deriva del steeringRequiere generar y filtrar cientos de respuestas de entrenamiento

Profundizando: la dirección oculta dentro de los pesos

Un hallazgo previo del mismo autor, en un experimento anterior sobre este modelo, encontró algo más estructural que una simple preferencia de estilo: la "voz de asistente" existe como una dirección medible dentro del espacio de activaciones del modelo. Restarla matemáticamente durante la generación cambia el estilo de la respuesta, de la misma forma en que mover un objeto en un plano de coordenadas cambia su posición sin cambiar su forma.

El parche de cuatro neuronas es un caso más puntual de la misma idea: para el hábito "no es X, sino Y" específicamente, basta invertir el signo de activación de cuatro neuronas para eliminar el 70% de los casos. Pero esa solución es frágil porque está atada a esa única muletilla y no se generaliza a los guiones largos ni a los tríos.

💭 Clave: que exista una dirección interna para el estilo no significa que todas las muletillas comparten esa misma dirección. Cada hábito puede vivir en una parte distinta de la red.

Por eso la destilación resulta más robusta que localizar neuronas o direcciones. No necesita encontrar la ubicación exacta de cada hábito dentro de la red: alcanza con mostrarle al modelo, con ejemplos reales, cómo se ve el resultado que se quiere.

Tu próximo paso: descargá ollama run hf.co/erikkannike/qwen3-4b-deslop-v4-GGUF:Q4_K_M, hacele la misma pregunta de opinión a ese modelo y a ollama run qwen3:4b, y contá a mano cuántos guiones largos aparecen en cada respuesta.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué significa que un modelo tenga muletillas de IA?

Significa que repite, con más frecuencia de la que usaría un humano al escribir con cuidado, un conjunto reducido de recursos de estilo: guiones largos, tríos de elementos, la fórmula "no es X, sino Y" y preguntas que responde en la misma frase. Un detector automático puede contarlos y dar un puntaje por cada 1.000 palabras.

¿Cómo se entrena Qwen3-4B-deslop para evitar estos tics?

Con destilación en tres rondas: un modelo profesor genera respuestas, un conjunto de filtros descarta las que tienen muletillas, inventan datos o no cumplen la tarea pedida, y un adaptador LoRA chico aprende a imitar las respuestas que quedan. El resultado se mete en los pesos del modelo, sin prompt ni código extra en tiempo de ejecución.

¿Funciona igual que el modelo original en preguntas factuales?

Según el autor, responde correctamente las 30 de 30 preguntas de un quiz de conocimiento, el mismo número que el modelo original sin afinar.

¿Es gratis correr Qwen3-4B-deslop en Ollama?

Sí. El modelo está publicado en Hugging Face bajo un repositorio público y la versión cuantizada pesa 2,5 GB; solo hace falta tener Ollama instalado y suficiente espacio en disco.

¿El fine-tuning de este tipo sirve para modelos más grandes?

El autor entrenó este experimento en una MacBook Air, con un modelo de 4.000 millones de parámetros y 161 respuestas de entrenamiento. La receta no depende del tamaño del modelo, aunque probarla en modelos más grandes queda como trabajo pendiente.

¿Un detector automático puede distinguir buena de mala escritura?

No por sí solo. Un detector basado en reglas cuenta patrones, no juzga sentido ni coherencia, y por eso el autor complementó cada ronda de entrenamiento con una revisión manual de respuestas.

Referencias

100toolkit.com: publicación original con la metodología completa, los puntajes de cada ronda y los enlaces a los pesos del modelo.- Hugging Face: repositorio con los pesos cuantizados de Qwen3-4B-deslop en formato GGUF.- Ollama: documentación oficial para instalar y correr modelos de lenguaje en local.- Wikipedia: explicación general del aprendizaje por refuerzo con retroalimentación humana (RLHF).- GitHub, QwenLM/Qwen3: repositorio oficial de la familia de modelos Qwen3 sobre la que se construyó este fine-tuning.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Superlite: delegar un spec sin aprobar cada paso

lu1tr0n — Mon, 19 Oct 2026 08:47:08 +0000

Claude Code se detiene a pedir aprobación cada pocos minutos, el costo habitual de los agentes de IA autónomos cuando el flujo de trabajo prioriza la supervisión sobre la velocidad. Lo resume bien el post "Superlite: hand an agent a spec, come back to tested work", publicado en contextfirst.blog: su autor pidió un spec, se hizo un sándwich y volvió a encontrar al agente detenido en la sección 1, esperando un "sí" que llevaba veinte minutos ahí.

Este artículo explica por qué pasa eso, qué mecanismos (permisos, hooks y revisión automática de tareas) permiten delegar un spec completo sin supervisión constante, y cómo Superlite, el plugin de Claude Code que nació de esa frustración, los combina en la práctica.

TL;DR

Los agentes se frenan porque cada herramienta sensible pide confirmación sin una regla de permisos previa.- Los hooks PreToolUse y PostToolUse interceptan cada acción y la aprueban o bloquean con código, sin preguntarte.- Superlite cambia 8 a 12 aprobaciones por feature por una sola, y mueve el resto de las reglas al código.- Un plan dividido en tareas sin archivos compartidos deja correr varios agentes a la vez en lugar de uno por uno.- La revisión automática por código reemplaza la aprobación humana, salvo en cambios destructivos o de seguridad.

¿Qué son los agentes de IA autónomos?

Los agentes de IA autónomos son programas que ejecutan tareas de desarrollo (planificar, escribir código, correr pruebas, corregir errores) encadenando llamadas a un modelo de lenguaje y herramientas del sistema, sin que un humano confirme cada paso intermedio: solo intervienen las decisiones destructivas, irreversibles o de seguridad.

Herramientas como Claude Code, Cursor o el modo agente de GitHub Copilot funcionan así por defecto. Reciben una instrucción, la descomponen en pasos y ejecutan cada herramienta (leer un archivo, correr un comando, editar código) a través de un bucle de planificar, actuar y observar el resultado.

Por diseño, la mayoría de esos agentes es conservadora. Antes de correr algo irreversible (borrar un archivo, hacer push, instalar una dependencia), se detienen y piden confirmación humana. Esa cautela evita desastres, pero también multiplica las pausas cuando el usuario ya sabe qué quiere construir.

Por qué los agentes de IA autónomos se detienen a cada paso

El post de contextfirst.blog profiló su propio flujo de trabajo (basado en el plugin "superpowers" para Claude Code) y encontró cinco cuellos de botella. El primero: entre 8 y 12 gates de aprobación humana por feature, uno por cada sección del diseño, más revisiones separadas del spec, del plan y del método de ejecución.

El segundo es la ejecución estrictamente secuencial: un implementador, después un revisor, después la siguiente tarea. En el primer benchmark del autor eso se tradujo en una cola de 21 despachos en un solo archivo, como un banco con una sola ventanilla y un almuerzo muy largo.

El tercero es la revisión después de cada tarea, con reintentos cuando la revisión encuentra algo: en un build de 34 minutos, 12 minutos se fueron solo en esas revisiones. El cuarto es correr la batería completa de tests varias veces, una por cada skill que quiere asegurarse de que nada cambió. El quinto es usar el modelo más potente (Opus) en el camino crítico: según el post, escribe código a la mitad de velocidad que Sonnet.

Ninguno de estos frenos es un error de diseño. Cada uno es una red de seguridad razonable cuando el objetivo es que un humano revise cada decisión. El problema aparece cuando el usuario ya sabe exactamente qué quiere construir: ahí la misma red de seguridad se convierte en una reunión de cuatro horas que se programó sola.
Un build de 34 minutos perdió 12 en revisiones repetidas, según contextfirst.blog.

Cómo funciona el modelo de permisos en Claude Code

Claude Code resuelve la primera capa de control con un sistema de permisos declarado en settings.json. Cada acción (correr un comando de shell, editar un archivo, llamar una herramienta MCP) se evalúa contra tres listas: allow (corre sin preguntar), ask (pide confirmación interactiva) y deny (nunca corre, ni siquiera se pregunta).

Las reglas usan patrones por herramienta y argumento, no solo por nombre de comando. Bash(git commit:*) autoriza cualquier commit, pero no un push; Bash(rm -rf:*) se puede poner directamente en deny para que ningún agente, por más que lo pida con buenos modales, borre un directorio completo.

El otro eje es el modo de permisos de la sesión: el modo por defecto pregunta ante cualquier acción no cubierta por una regla; acceptEdits aprueba ediciones de archivo automáticamente pero sigue preguntando por comandos de shell; plan no ejecuta nada hasta que el usuario aprueba el plan completo; y bypassPermissions corre todo salvo lo que esté explícitamente en deny. Superlite y proyectos similares dependen de este último modo combinado con reglas de deny bien pensadas, no de confiar en que el agente se porte bien.

flowchart TD
T["Agente llama una herramienta"] --> C{"Regla en permissions"}
C -->|"allow"| E["Ejecuta sin preguntar"]
C -->|"ask"| H["Hook o prompt interactivo"]
C -->|"deny"| D["Bloqueada, nunca corre"]
H --> F{"Hook decide"}
F -->|"approve"| E
F -->|"block"| D

Hooks: la otra capa de control

Los permisos deciden si una acción corre; los hooks deciden qué pasa antes y después de que corra, con código real en vez de una regla declarativa. Claude Code dispara eventos como PreToolUse (antes de ejecutar una herramienta), PostToolUse (después) y SessionStart (al abrir la sesión), y cada uno puede atarse a un script que recibe contexto en JSON por stdin y devuelve una decisión.

Un hook de PreToolUse atado al matcher Bash ve el comando exacto que el agente está a punto de correr antes de que corra. Si el comando intenta un git push a main, el hook puede devolver un bloqueo con una razón, sin que el modelo tenga que entender ni respetar una instrucción en texto plano.

#!/usr/bin/env bash
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command // empty')
if [[ "$cmd" == *"push"* && "$cmd" == *"main"* ]]; then
  echo '{"decision":"block","reason":"push a main requiere revision humana"}'
  exit 0
fi
echo '{"decision":"approve"}'

Si el agente intenta git push origin main, el hook imprime {"decision":"block","reason":"push a main requiere revision humana"} y Claude Code cancela el comando sin ejecutarlo; para cualquier otro comando, imprime {"decision":"approve"} y la ejecución sigue normal.

sequenceDiagram
participant Agente
participant Hook as Hook PreToolUse
participant Repo as Repositorio
Agente->>Hook: intenta "git push origin main"
Hook-->>Agente: decision block, razon
Agente->>Repo: push cancelado

💭 Clave: El post original lo resume de forma directa: un agente lee una regla escrita en texto y después hace lo que quiere. Por eso las reglas que importan van en código (permisos y hooks), no en una instrucción de párrafo dentro del spec.

Superlite: un caso concreto de agente autónomo de código

Superlite es el plugin de Claude Code que contextfirst.blog construyó para resolver justamente esos cinco cuellos de botella. En vez de pedir aprobación por sección, agrupa las preguntas en un solo lote de hasta cuatro, según el tamaño del pedido: un typo se corrige directo, sin documento de diseño; un cambio a un flujo existente recibe un diseño corto en el chat; un proyecto nuevo recibe un documento único de diseño y plan que el usuario aprueba una sola vez.

Después de esa aprobación única, Superlite solo vuelve a preguntar ante algo destructivo, visible hacia afuera o sensible en seguridad: no va a hacer push a main mientras el usuario está almorzando, pero sí va a hacer todo lo demás sin interrupción.

La pieza central es el plan: en vez de una lista de pasos, Superlite genera un grafo de tareas. Cada tarea declara qué archivos posee, qué interfaces consume y produce, y qué tests tiene que pasar. Las tareas que no comparten archivos ni dependen entre sí corren al mismo tiempo; el ancho del grafo decide cuántos agentes trabajan en paralelo en un momento dado.

Cada decisión que normalmente generaría una pregunta queda registrada como una resolución (ruling): qué se decidió, por qué y qué pasa si estuvo mal. Eso es lo que permite que los agentes de IA autónomos avancen sin supervisión constante sin perder trazabilidad: el usuario vuelve al final y sabe exactamente qué decisión revisar primero, en vez de reconstruir el razonamiento desde cero.

flowchart TD
subgraph Secuencial["Un agente, un paso a la vez"]
A1["Tarea 1"] --> P1["Aprobacion humana"]
P1 --> A2["Tarea 2"]
A2 --> P2["Aprobacion humana"]
P2 --> A3["Tarea 3"]
end
subgraph Paralelo["Varios agentes a la vez"]
B1["Tarea 1"] --> R["Revision automatica"]
B2["Tarea 2"] --> R
B3["Tarea 3"] --> R
end

El grafo de tareas de Superlite decide cuántos agentes corren a la vez, según contextfirst.blog.

Cómo empezar: configurar permisos y hooks en Claude Code

Dependencias antes de empezar: Claude Code instalado, un proyecto con carpeta .claude/ en la raíz, y jq disponible para parsear el JSON dentro del hook (en Linux y macOS casi siempre ya está o se instala con el gestor de paquetes del sistema; en Windows, sin WSL, el mismo hook se escribe en PowerShell con ConvertFrom-Json en una línea).

Primero, crear o editar .claude/settings.json en la raíz del proyecto con reglas de permisos:

{
  "permissions": {
    "allow": ["Bash(npm test:*)", "Bash(git commit:*)"],
    "ask": ["Bash(git push:*)"],
    "deny": ["Bash(rm -rf:*)"]
  }
}

Con esto, Claude Code corre tests y commits sin preguntar, pide confirmación antes de cualquier push y nunca va a ejecutar un rm -rf, sin importar cómo se lo pidan.

Segundo, crear el hook en .claude/hooks/guard-push.sh con el script mostrado en la sección anterior, y darle permiso de ejecución con chmod +x .claude/hooks/guard-push.sh.

Tercero, registrar el hook en el mismo settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{"type": "command", "command": ".claude/hooks/guard-push.sh"}]
      }
    ]
  }
}

Para confirmar que la regla de permisos está activa, corré /permissions dentro de una sesión de Claude Code: lista cada patrón (allow, ask o deny) junto con la herramienta a la que aplica. Para el hook, el chequeo real es pedirle al agente que intente git push origin main: si la configuración está bien, el comando se cancela y aparece la razón push a main requiere revision humana en la salida, en vez de ejecutarse.

Casos de uso reales

Una feature nueva y acotada (un endpoint, un formulario, una migración de datos) es el caso de uso más directo: el usuario aprueba un plan una sola vez y vuelve horas después a código probado, en vez de haber aprobado veinte decisiones chicas una por una.

Un refactor grande que toca muchos archivos se beneficia del grafo de tareas: si el refactor se puede partir en módulos que no se pisan entre sí (por ejemplo, migrar cada ruta de una API de un framework a otro), varios agentes trabajan en paralelo en vez de uno detrás del otro.

Una corrección de bug puntual sigue el camino corto: Superlite detecta que es un cambio chico y lo corrige directo, sin generar un documento de diseño para un typo. El tamaño de la respuesta se ajusta al tamaño del pedido, no al revés.

El caso donde este enfoque no conviene es el opuesto: cuando el usuario todavía no sabe bien qué quiere construir y necesita iterar el diseño en vivo, sección por sección. Ahí el flujo colaborativo (el de Superpowers, con un humano cerca de cada paso) sigue siendo la herramienta correcta.

Comparativa con alternativas

Ninguno de los tres enfoques siguientes es universalmente mejor: la decisión depende de si el usuario ya tiene el diseño resuelto en la cabeza o todavía lo está construyendo junto con el agente.
OpciónCuándo usarlaVentajaLimitaciónAprobación manual en cada pasoDiseño todavía incierto, se decide sobre la marchaControl total, cero sorpresas8 a 12 pausas por feature, no escala a tareas grandesSuperpowers (flujo colaborativo)El usuario quiere revisar spec, plan y ejecución por separadoMáxima trazabilidad y seguridadEjecución secuencial, lenta para specs ya cerradosSuperlite (spec a ejecución autónoma)El spec ya está definido y solo falta construirloUna aprobación, tareas en paralelo, registro de decisionesExige reglas de permisos y hooks bien escritas de antemano

Errores comunes y buenas prácticas

El error más frecuente es activar bypassPermissions sin escribir reglas de deny. El modo asume que todo lo que no está prohibido está permitido, así que un agente con ese modo y una lista de deny vacía puede ejecutar cualquier comando, incluido uno destructivo.

El segundo es confundir una instrucción en el spec ("nunca borres archivos de producción") con una regla real. Esa frase vive en el contexto que el modelo lee. Un cambio de contexto, una instrucción contradictoria más adelante o simplemente una mala interpretación puede hacer que el agente la pase por alto. La regla necesita vivir en código: en settings.json o en un hook, donde se evalúa siempre, sin depender de que el modelo la recuerde.

El tercero, documentado en el propio post de Superlite, es correr Superpowers y Superlite en la misma sesión: ambos inyectan contexto al iniciar la sesión y comparten nombres de skill, así que terminan contradiciéndose. Se elige uno por sesión, no los dos.

⚠️ Ojo: un hook que siempre responde {"decision":"approve"} sin leer el comando no protege nada. Es una ilusión de control. El hook tiene que inspeccionar el tool_input real antes de decidir.

La práctica que mejor funciona es separar las reglas en dos capas: permisos para lo previsible (qué comandos son siempre seguros o siempre peligrosos) y hooks para lo que depende del contenido exacto del comando (a qué rama se hace push, qué archivo se borra). Las dos capas se prueban por separado, antes de confiar en ellas con un spec grande.

Profundizando: el grafo de tareas y el registro de decisiones

Por dentro, el planificador de Superlite no reparte tareas al azar: construye un grafo dirigido donde cada nodo es una tarea con tres propiedades explícitas: los archivos que posee, las interfaces que consume de otras tareas y los tests que tiene que pasar para considerarse terminada. Dos tareas sin superposición de archivos ni dependencias de interfaz quedan en la misma capa del grafo y se disparan juntas.

Esto es distinto de simplemente decirle a varios agentes que trabajen en paralelo sin más: sin la restricción de archivos, dos agentes que tocan el mismo módulo generan conflictos de merge que nadie revisó. El grafo evita el conflicto antes de que ocurra, no lo arregla después.

La revisión automática funciona igual para cada tarea terminada: un segundo agente (no necesariamente el mismo modelo) corre los tests declarados y compara el resultado contra la interfaz prometida. Si falla, se genera una tarea de corrección que vuelve a pasar por el mismo chequeo, sin despertar al usuario, salvo que el chequeo falle repetidamente.

Y cuando el proceso sí necesita al usuario, no lo hace con una pregunta suelta: le entrega la lista completa de resoluciones tomadas durante la ejecución, cada una con su justificación y su costo si resultó ser la decisión equivocada. Así es como los agentes de IA autónomos logran avanzar horas sin intervención y, al mismo tiempo, dejan un rastro auditable.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: cloná un repo de prueba, agregá el hook guard-push.sh de este artículo a .claude/hooks/ y pedile a Claude Code que intente un git push origin main para ver el bloqueo en acción.

Preguntas frecuentes

¿Superlite reemplaza a Superpowers?

No. Superpowers prioriza mantener a un humano cerca de cada paso y Superlite prioriza la velocidad cuando el spec ya está cerrado. Comparten base de código, pero contextfirst.blog recomienda no activar los dos en la misma sesión porque sus skills se pisan.

¿Los hooks pueden bloquear cualquier acción de un agente autónomo de código?

Sí, cualquier acción que pase por un evento con hook registrado, como PreToolUse para herramientas o SessionStart al abrir la sesión. Lo que el hook no intercepta (un evento sin matcher configurado) sigue las reglas normales de permisos.

¿Qué pasa si el agente intenta hacer push a main con la configuración del artículo?

El hook guard-push.sh detecta "push" y "main" en el comando, devuelve {"decision":"block"} con la razón, y Claude Code cancela el comando sin ejecutarlo en el repositorio.

¿Cuántas aprobaciones humanas necesita un build con Superlite?

Una, al aprobar el diseño y el plan. Después de eso, según el post original, solo vuelve a preguntar ante acciones destructivas, visibles hacia afuera o sensibles en seguridad.

¿Los permisos de Claude Code se pueden combinar con hooks?

Sí, y es la combinación recomendada: los permisos cubren reglas previsibles por patrón de comando, y los hooks cubren decisiones que dependen del contenido exacto de ese comando, como a qué rama apunta un push.

¿La IA agéntica autónoma funciona con modelos distintos a Claude?

El mecanismo (permisos declarativos más hooks en código) es específico de Claude Code. Otros entornos agénticos resuelven el mismo problema con sus propios sistemas de políticas, pero el principio de reglas en código, no en texto del prompt, aplica igual.

Referencias

Contextfirst.blog: el post original donde se presenta Superlite, sus benchmarks y el diseño del plugin.- GitHub: anthropics/claude-code: repositorio oficial de Claude Code, con la documentación de hooks y permisos.- Claude Docs: documentación oficial de Anthropic sobre Claude Code y su configuración.- Wikipedia: Software agent: definición general del concepto de agente de software.

Razonamiento latente: la IA que piensa en vectores

lu1tr0n — Mon, 19 Oct 2026 02:31:31 +0000

Un agente de IA que resuelve un problema matemático puede escribir miles de palabras de razonamiento en texto antes de dar la respuesta final, palabra por palabra, como si pensara en voz alta. Un paper publicado el 13 de octubre de 2026 por investigadores de Stanford y Google propone que, en vez de eso, el agente practique razonamiento latente: que piense en vectores matemáticos continuos sin pasar por el lenguaje humano en cada paso intermedio.

El paper se llama Hybrid Reasoning Agents y presenta una arquitectura concreta llamada HybridAgents, pero la idea de fondo es mucho más amplia que esa implementación puntual. Es un cambio en cómo se diseña la mente interna de un agente de IA.

TL;DR

El razonamiento latente encadena vectores continuos en vez de palabras entre los pasos de pensamiento de un agente.- HybridAgents, el modelo que lo combina con texto, mejora 10,4% el desempeño frente a agentes solo-texto o solo-latentes.- Esa combinación recorta entre 35,5% y 54,7% los tokens generados por tarea, según el paper de Stanford de octubre de 2026.- La inferencia corre de 1,8x a 2,6x más rápido y el costo baja hasta 3,7 veces en los 11 benchmarks evaluados.- Inspeccionar el pensamiento se complica: un vector no se lee palabra por palabra como un razonamiento en texto.

¿Qué es el razonamiento latente?

El razonamiento latente es la técnica que permite a un modelo de lenguaje procesar los pasos intermedios de su pensamiento como vectores continuos en su espacio interno, en vez de convertir cada paso en palabras legibles antes de seguir pensando.

La diferencia con una cadena de pensamiento tradicional es fácil de explicar con una analogía. Cuando una persona resuelve un problema mentalmente, no narra cada subpaso en voz alta: piensa en intuiciones y asociaciones difusas, y solo las pone en palabras cuando necesita explicarlas a otra persona. El razonamiento basado en texto obliga al modelo a narrar cada subpaso, aunque nadie lo necesite todavía.

El pensamiento vectorial, en cambio, deja que el modelo mantenga esas asociaciones en su forma nativa, números de alta dimensión, sin pasar por el cuello de botella del vocabulario. Esto no es exclusivo de un paper: distintos equipos de investigación vienen explorando variantes de esta idea desde hace un par de años, bajo nombres como \"cadena de pensamiento continua\".
HybridAgents se evaluó en 11 benchmarks y 3 escalas de modelo.

Por qué importa el razonamiento latente

Todo modelo que razona en texto tiene que traducir cada paso intermedio de pensamiento a palabras, aunque esas palabras nunca las lea un humano. Esa traducción cuesta cómputo: generar un token de texto implica pasar por toda la capa de salida del modelo, el vocabulario completo, aunque el contenido real del pensamiento viva en un espacio vectorial mucho más rico que cualquier palabra individual.

El paper Hybrid Reasoning Agents mide ese costo de forma directa. Un agente que alterna entre texto y vectores logra hasta 54,7% de reducción de tokens generados frente a agentes que razonan solo en texto, y corre de 1,8x a 2,6x más rápido. Eso se traduce en un ahorro de costo de 2,7x a 3,7x según el tamaño del modelo evaluado.

Pero el ahorro no es gratis. Un agente que piense solo en vectores, sin pasar nunca por texto, pierde la capacidad de llamar herramientas externas y de mostrar su razonamiento a un humano. Por eso el diseño híbrido importa más que la pura eficiencia: busca quedarse con lo mejor de los dos mundos sin sacrificar ninguno por completo.

Cómo funciona el modo latente dentro de un agente

Para entender cómo funciona el razonamiento latente en la práctica, conviene mirar el mecanismo que usa HybridAgents para decidir, en cada paso de la generación, si conviene seguir pensando en vectores o volver a texto.

La diferencia técnica central es esta: un modelo de lenguaje estándar solo puede pensar emitiendo tokens discretos de un vocabulario fijo, uno a la vez. Un agente con modo latente puede, en cambio, emitir directamente el vector de activaciones que normalmente alimentaría la siguiente capa, sin forzarlo primero a colapsar en la palabra más probable del vocabulario. Esa diferencia parece pequeña, pero evita una pérdida de información que se acumula paso a paso a lo largo de un razonamiento largo.

flowchart TD
    A["Entrada del usuario"] --> B{"Modo de razonamiento"}
    B -->|"Texto"| C["Cadena de pensamiento en palabras"]
    B -->|"Latente"| D["Vector continuo via HybridLink"]
    C --> E["Memoria de trabajo"]
    D --> E
    E --> F["Accion: respuesta o llamada a herramienta"]

HybridLink: el puente entre dos modos de pensar

El paper describe un módulo liviano llamado HybridLink que habilita transiciones fluidas entre modo texto y modo latente dentro de un mismo proceso de generación. En la práctica, es la pieza que decide, token por token, si lo que sigue debe representarse como una palabra del vocabulario o como un vector sin pasar por esa capa de salida.

Que HybridLink sea liviano importa por una razón práctica: no hace falta reentrenar el modelo entero desde cero para agregarle esta capacidad. El backbone conserva casi todo su conocimiento previo, y HybridLink se encarga solamente de la transición entre modos, lo que simplifica tanto el entrenamiento como el mantenimiento posterior del sistema.

Memoria de trabajo continua: no perder el hilo

El segundo componente es una memoria de trabajo continua que preserva el contexto híbrido, texto y vectores mezclados, sin pérdida a lo largo de varios turnos de conversación o de uso de herramientas. Sin esta pieza, cada cambio de modo implicaría reconstruir el contexto desde cero, perdiendo precisión en el camino.

sequenceDiagram
    participant U as Usuario
    participant A as Agente
    participant H as Herramienta
    U->>A: envia la pregunta
    A->>A: piensa en vectores (modo latente)
    A->>H: llama a una herramienta en modo texto
    H-->>A: devuelve el resultado
    A->>U: responde en lenguaje natural

HybridSFT entrena la coordinacion; HybridRL decide el modo de pensar.

El caso de estudio: cómo Stanford entrenó a un agente para elegir su propio modo de pensar

Enseñarle a un modelo a usar HybridLink no es automático. El paper divide el entrenamiento en dos etapas con nombres propios.

HybridSFT: estabiliza la generación híbrida con herramientas integradas, enseñándole al backbone a coordinarse con HybridLink antes de que el modelo tenga que decidir nada por su cuenta.- HybridRL: una segunda etapa de aprendizaje por refuerzo que le enseña al modelo cuándo conviene pensar en espacio latente y cuándo conviene actuar a través de texto, en vez de seguir una regla fija.

Con ese entrenamiento completo, los autores evaluaron HybridAgents en 3 escalas de modelo distintas, sobre 11 benchmarks que cubren matemáticas, ciencia, medicina, búsqueda y razonamiento agéntico. Comparado con agentes de frontera y frameworks agénticos que cubren tanto métodos basados en texto como en vectores, reportan una mejora consistente de 10,4% en desempeño.

La comparación no fue solo contra otros agentes híbridos. El paper incluye frameworks agénticos de frontera que razonan puramente en texto y modelos que razonan puramente en espacio latente, lo que permite aislar qué parte de la ganancia viene de combinar ambos modos y cuál vendría de todas formas con un modelo más grande.

stateDiagram
    [*] --> ModoTexto
    ModoTexto --> ModoLatente: HybridLink activa el cambio
    ModoLatente --> ModoTexto: necesita usar una herramienta
    ModoTexto --> [*]: entrega la respuesta final

Ejemplos prácticos: qué significa pensar en vectores

No hay todavía una librería instalable que deje experimentar con la arquitectura exacta de HybridAgents fuera del paper, así que el mejor ejemplo práctico es uno conceptual: mostrar por qué dos pensamientos parecidos quedan cerca en un espacio vectorial, que es la propiedad que el modo latente explota.

import numpy as np

pensamiento_a = np.array([0.12, 0.98, -0.05])  # \"quiero resolver esta ecuacion\"
pensamiento_b = np.array([0.15, 0.95, -0.02])  # \"necesito despejar x\"

similitud = np.dot(pensamiento_a, pensamiento_b) / (
    np.linalg.norm(pensamiento_a) * np.linalg.norm(pensamiento_b)
)
print(f\"Similitud coseno: {similitud:.4f}\")

La salida de este script es Similitud coseno: 0.9987. Esos dos vectores representan ideas distintas en palabras (resolver una ecuación y despejar x), pero casi idénticas en el espacio vectorial. Un agente que razona en modo latente puede moverse entre ideas así de cercanas sin tener que materializar ninguna de las dos como texto, y solo convertir el resultado final a palabras cuando le toca responder.

Casos de uso reales

El paper no se queda en matemáticas de juguete. Evalúa la cognición vectorial de los agentes en cinco dominios distintos:

Matemáticas: resolución de problemas donde cada paso intermedio es una operación simbólica (despejar, factorizar, sustituir) que no necesita pasar por una frase completa en español o inglés.- Ciencia: preguntas que requieren encadenar varios hechos verificables antes de llegar a una conclusión, un escenario donde un paso mal razonado arrastra error a todos los siguientes.- Medicina: tareas de razonamiento clínico, donde la cantidad de pasos intermedios suele ser alta y el costo de cada token adicional se multiplica rápido.- Búsqueda: tareas donde el agente necesita decidir qué buscar, evaluar resultados parciales y recién después construir la respuesta completa.- Razonamiento agéntico: tareas que combinan pensar con usar herramientas externas, el escenario donde el modo híbrido se vuelve indispensable porque el modo puramente latente no puede ejecutar una llamada de herramienta.

Errores comunes y buenas prácticas

Asumir que cualquier modelo ya razona en latente: no es así. Tratar al razonamiento latente como una función que viene gratis en cualquier backbone es el error más común; hace falta el módulo HybridLink y las dos etapas de post-entrenamiento, HybridSFT y HybridRL, para que el modelo aprenda a coordinarse.- Tratar al modo latente como una caja negra total: parte del valor del paper es justamente que el razonamiento híbrido sigue siendo parcialmente inspeccionable en sus tramos de texto, a diferencia de un agente puramente latente sin HybridLink.- Ignorar el costo de entrenamiento: pasar de un modelo solo-texto a uno híbrido no es gratis, implica las dos etapas de entrenamiento adicionales antes de ver las ganancias de eficiencia.

⚠️ Ojo: si no podés leer el razonamiento paso a paso de tu agente, tampoco podés auditarlo con la misma facilidad que un chain-of-thought en texto. Eso importa en dominios regulados como medicina o finanzas.

Comparativa con alternativas

EnfoqueCómo representa el pensamientoVentajaLimitaciónCadena de pensamiento en textoPalabras generadas token por tokenTotalmente legible e inspeccionableCada paso intermedio cuesta tokens y cómputoRazonamiento puramente latenteSolo vectores continuos, sin pasar por textoMás eficiente en tokens y cómputoPierde acceso nativo a herramientas y transparenciaRazonamiento híbrido (HybridAgents)Alterna vectores y texto según la tareaReduce tokens hasta 54,7% sin perder el uso de herramientasRequiere entrenamiento adicional (HybridSFT y HybridRL)

Profundizando: qué arriesga un agente que piensa en vectores

El texto es, en el fondo, una compresión con pérdida del pensamiento real de un modelo. Cuando un modelo genera una cadena de razonamiento en palabras, está forzando una representación de alta dimensión a pasar por un vocabulario finito, perdiendo matices en el camino. El razonamiento en espacio latente evita esa compresión.

Esa ganancia tiene un costo que todavía preocupa a buena parte de la comunidad de seguridad en IA: el chain-of-thought en texto, con todos sus defectos, se volvió una herramienta de supervisión. Si un agente razona en vectores que nadie puede leer directamente, esa ventana de inspección se angosta, aunque el agente siga siendo técnicamente más eficiente.

Esa tensión no es nueva en la investigación de seguridad en IA: ya antes de este paper, varios laboratorios discutían si optimizar demasiado la eficiencia de un chain-of-thought en texto terminaba empujando a los modelos a comprimir su razonamiento en formas cada vez menos legibles para un humano. El razonamiento en espacio latente lleva esa discusión un paso más allá, porque ya no se trata de un texto comprimido sino de una representación que nunca pasó por el lenguaje.

Por eso el diseño de HybridAgents no apuesta todo al modo latente. Mantiene el texto disponible para los momentos donde la transparencia o el uso de una herramienta importan más que el ahorro de tokens, y usa HybridRL precisamente para aprender ese criterio en vez de fijarlo a mano.

💭 Clave: el texto es una compresión con pérdida del pensamiento real del modelo. El razonamiento en espacio latente evita esa compresión, pero a cambio pierde la propiedad que hizo útil al chain-of-thought como herramienta de supervisión: que un humano pueda leerlo.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: tomá dos frases con significado parecido, generá sus embeddings con cualquier modelo de sentence-transformers y calculá la similitud coseno como en el ejemplo de este artículo, para ver con tus propios datos qué tan cerca quedan en el espacio vectorial.

Preguntas frecuentes

¿HybridAgents reemplaza a los modelos que razonan solo en texto?

No. HybridAgents es una forma de combinar ambos modos dentro del mismo modelo, no de eliminar el modo texto. El texto sigue siendo necesario para llamar herramientas y para comunicar la respuesta final.

¿El pensamiento vectorial funciona con cualquier modelo de lenguaje?

No de forma automática. Requiere agregar el módulo HybridLink y pasar por las dos etapas de post-entrenamiento que describe el paper, HybridSFT y luego HybridRL. Sin ese proceso, el modelo no sabe cuándo conviene cambiar de modo ni cómo interpretar un vector que viene del modo contrario.

¿Por qué el razonamiento en espacio latente es más difícil de auditar?

Porque un vector continuo no tiene una traducción directa y única a palabras. Un chain-of-thought en texto se puede leer línea por línea; un vector solo se puede analizar con técnicas indirectas, como comparar su similitud con otros vectores conocidos.

¿HybridAgents puede usar herramientas externas mientras piensa en vectores?

Sí, y es justamente el punto del diseño. Cuando el agente necesita llamar una herramienta, HybridLink lo devuelve al modo texto para esa llamada, y vuelve a modo latente después si conviene.

¿Dónde se probó la cognición vectorial de los agentes?

El paper evaluó HybridAgents en 3 escalas de modelo distintas sobre 11 benchmarks de matemáticas, ciencia, medicina, búsqueda y razonamiento agéntico, comparando siempre contra agentes de frontera que razonan solo en texto o solo en vectores.

¿El código de HybridAgents es público?

El paper indica que el código y los datos están disponibles, aunque el resumen público no detalla todavía la URL exacta del repositorio.

Referencias

Hybrid Reasoning Agents (arXiv:2610.18861): paper original de Stanford, Google y colaboradores, publicado el 13 de octubre de 2026.- Chain-of-thought prompting, Wikipedia: contexto sobre el razonamiento en texto que el razonamiento latente busca complementar.- Large language model, Wikipedia: fundamentos generales sobre cómo funcionan los modelos de lenguaje.- NumPy, documentación oficial: referencia de las funciones usadas en el ejemplo de código de este artículo.

Intel 8087: cómo el microcódigo sumaba y restaba en hardware

lu1tr0n — Sun, 18 Oct 2026 20:28:50 +0000

El microcódigo del 8087 multiplicó casi 100 veces la velocidad de la suma en punto flotante frente al 8086, usando apenas 1.648 microinstrucciones grabadas en su ROM. Ese salto convirtió a la PC de IBM en una máquina capaz de recalcular hojas de cálculo y planos de ingeniería sin esperar minutos por cada operación.

Un análisis reciente del die del 8087, hecho con un chip real decapado y fotografiado al microscopio, reconstruyó paso a paso cómo su circuitería ejecuta una suma o una resta en punto flotante, con todos los casos límite que involucran infinitos y ceros con signo.

TL;DR

El coprocesador matemático 8087 ejecuta suma y resta en punto flotante de 80 bits con 1.648 microinstrucciones.- Alinear los significandos antes de sumar es el mismo truco que alinear comas decimales, pero en binario.- El shifter del 8087 ocupa una porción enorme del die porque desplaza una cantidad arbitraria de bits en un solo paso.- Restar dos números cercanos puede exigir normalizar con un desplazamiento de varios bits a la izquierda.- Python con math.frexp y math.ldexp reproduce el mismo algoritmo de alineación y normalización del 8087.

¿Qué es el microcódigo del 8087?

El microcódigo del 8087 es la secuencia de 1.648 microinstrucciones grabadas en la ROM central del primer coprocesador matemático de Intel, lanzado en 1980, que controla paso a paso cómo el sumador, el shifter y el conversor de exponente ejecutan una suma o resta en punto flotante de 80 bits.

Intel lo vendió como chip aparte para el 8086 y el 8088, el procesador que IBM eligió para su PC original. Sin coprocesador, esas CPU resolvían los decimales a pura instrucción entera, con rutinas de software que tardaban cientos de ciclos por cada operación.

Con el 8087 instalado, el mismo cálculo se ejecutaba en circuitería dedicada: un sumador entero, un shifter capaz de mover bits en una sola pasada y un conversor de exponente que detecta desbordes antes de que arruinen el resultado.

Por qué importa la aritmética en hardware

Antes del 8087, un programa que sumara dos decimales en el 8086 debía descomponer la operación en instrucciones enteras: extraer el exponente, alinear bits a mano y recomponer el resultado. Cada paso costaba ciclos de reloj, y una sola suma en punto flotante podía tardar lo mismo que decenas de sumas enteras.

El 8087 resolvió ese cuello de botella metiendo la lógica de alineación y normalización directamente en silicio. Según el análisis del die publicado en el blog de Ken Shirriff, la mejora de velocidad en la suma llegó a casi 100 veces frente al 8086 solo, y las operaciones más complejas, como raíces o logaritmos, ganaron todavía más.

Para 1980 eso significaba que una hoja de cálculo con miles de celdas numéricas, o un programa de diseño asistido, podía recalcular en segundos en lugar de minutos. Ese fue el argumento de venta del 8087 en estaciones de ingeniería y en las primeras versiones de software como Lotus 1-2-3.
El 8087 salió al mercado en 1980 como coprocesador opcional para el 8086 y el 8088.

El formato de 80 bits: así guarda los números el 8087

Internamente, el 8087 no trabaja con el float de 32 bits ni el double de 64 bits que usan los lenguajes modernos. Todas sus operaciones ocurren en un formato propio de 80 bits que Intel llamó temporary real, con más bits de significando que cualquier otro formato que el chip exponía hacia el programador.

Ese formato extendido absorbe el error de redondeo de cálculos intermedios antes de que el resultado final se convierta a 32 o 64 bits. Por eso una secuencia larga de sumas y restas en el 8087 pierde menos precisión que la misma secuencia hecha directamente en formato corto, ya que cada paso intermedio conserva bits de sobra que solo se descartan al final de la cadena.
FormatoBits totalesBits de significandoRango aproximadoShort real3224supera 10⁻³⁶ a 10³⁸Long real6453mucho mayor que el short realTemporary real8064el más amplio de los tres, solo interno al chip

Cómo el 8087 alinea y suma dos números en punto flotante

Un número en punto flotante se guarda como signo por significando por 2 elevado al exponente. El significando sigue la forma 1.bbb…, un 1 inicial seguido del punto binario y el resto de los bits. Así, el binario 1.1 representa 1 + 1/2, es decir 1.5 en decimal, y 1.0011 representa 1 + 1/8 + 1/16, o 1.1875.

Para sumar dos números hace falta igualar sus exponentes antes de sumar los significandos, igual que alinear las comas decimales de 13.5 y 3.5 antes de sumarlas a mano. El 8087 expresa 13.5 como 1.6875 por 2 al cubo y 3.5 como 1.75 por 2 a la uno. La diferencia de exponentes es 2, así que el chip desplaza el significando de 3.5 dos posiciones a la derecha antes de sumar.

flowchart TD
    A["Tomar los dos operandos"] --> B["Comparar exponentes"]
    B --> C["Desplazar el significando menor"]
    C --> D["Sumar los significandos alineados"]
    D --> E{"Hubo acarreo extra?"}
    E -->|"sí"| F["Desplazar 1 bit a la derecha y sumar 1 al exponente"]
    E -->|"no"| G["Resultado ya normalizado"]
    F --> G

La suma de los significandos ya alineados da, en este caso, un resultado que desborda un bit hacia la izquierda. El 8087 normaliza desplazando ese resultado una posición a la derecha y sumando 1 al exponente, hasta que el bit más significativo vuelve a ser un 1. El resultado final es 17.0, igual que sumar 13.5 más 3.5 a mano.

Código: simulando la alineación y la suma como el 8087

El mismo algoritmo de alinear, sumar y normalizar se reproduce en pocas líneas de Python usando math.frexp, que separa un número en significando y exponente, y math.ldexp, que los recompone.

import math

def align_and_add(a, b):
    ma, ea = math.frexp(a)
    mb, eb = math.frexp(b)
    if ea >= eb:
        mb = mb / (2 ** (ea - eb))
        exp = ea
    else:
        ma = ma / (2 ** (eb - ea))
        exp = eb
    mantissa = ma + mb
    if abs(mantissa) >= 1.0:
        mantissa /= 2
        exp += 1
    return math.ldexp(mantissa, exp)

print(align_and_add(13.5, 3.5))

La salida es 17.0, el mismo resultado que calculó el 8087 en el ejemplo de alineación de más arriba.

Cómo funciona la resta: cancelación y normalización a la izquierda

Restar es más delicado que sumar. El resultado puede ser positivo, negativo o exactamente cero, y cuando dos números son parecidos, el resultado queda mucho más chico que ambos operandos. El 8087 alinea los exponentes igual que en la suma, pero después de restar los significandos, el bit más significativo casi nunca queda en la posición correcta, así que la normalización suele exigir desplazar varios bits a la izquierda.

flowchart TD
    A["Alinear exponentes"] --> B["Restar los significandos"]
    B --> C{"El resultado es cero?"}
    C -->|"sí"| D["Devolver +0 o -0 según el signo"]
    C -->|"no"| E{"El significando es negativo?"}
    E -->|"sí"| F["Hacerlo positivo e invertir el signo del resultado"]
    E -->|"no"| G["Normalizar desplazando a la izquierda"]
    F --> G

Tomemos 8 menos 7.5. El chip expresa 8 como 1.0 por 2 al cubo y 7.5 como 1.875 por 2 al cuadrado; alineados, resta 1.0 menos 0.9375 y obtiene 0.0625. Para normalizar ese resultado hasta que el bit líder sea 1, el 8087 desplaza cuatro posiciones a la izquierda y resta 4 al exponente, llegando a 1.0 por 2 a la menos uno, o sea 0.5.

Si el significando de la resta queda negativo, el 8087 lo convierte a positivo e invierte el signo del resultado. Y si la resta da exactamente cero, no hay nada que normalizar: el chip devuelve directamente +0 o -0 según el signo que corresponda.

import math

def align_and_sub(a, b):
    ma, ea = math.frexp(a)
    mb, eb = math.frexp(b)
    if ea >= eb:
        mb = mb / (2 ** (ea - eb))
        exp = ea
    else:
        ma = ma / (2 ** (eb - ea))
        exp = eb
    mantissa = ma - mb
    shifts = 0
    while mantissa != 0 and abs(mantissa)  C["Sumador entero"]
    D["Registros temporales o pila"] --> C
    C --> E["Registro de suma"]
    E --> F["Shifter"]
    F --> G["Normalización"]
    H["Contador de ceros a la izquierda"] --> F
    I["Conversor de exponente"] --> G

El datapath del 8087 ocupa la mitad inferior del die y agrupa los bloques que hacen el trabajo pesado. El sumador entero, en el centro, recibe un operando del registro B y otro de los registros temporales o de la pila de ocho registros del chip; su salida va al registro de suma.

El shifter es, según el análisis del die, el bloque que más espacio ocupa dentro de esa mitad del chip, porque su circuitería permite mover un valor una cantidad arbitraria de posiciones en un solo paso, en lugar de desplazar bit por bit. La operación de alinear significandos, descrita más arriba, depende enteramente de este componente.
El shifter del 8087 puede desplazar un valor una cantidad arbitraria de bits en un único paso.
Junto al shifter trabaja un contador de ceros a la izquierda, que cuenta cuántos bits o bytes sobran del lado izquierdo de un valor para saber cuánto hay que desplazarlo durante la normalización. El conversor de exponente, por su parte, procesa los exponentes de ambos operandos, detecta cuándo un resultado se desborda o se queda sin rango, y ajusta el exponente final.

💭 Clave: El 8087 no gana velocidad solo por tener más transistores: gana porque reemplaza un bucle de software, desplazar bit por bit, por un circuito que resuelve el desplazamiento completo en un solo ciclo.

Casos especiales: infinitos, ceros y signos

Más allá de la aritmética normal, el microcódigo del 8087 dedica buena parte de sus 1.648 microinstrucciones a resolver casos límite. Sumar infinito más un número finito da infinito; sumar infinito positivo e infinito negativo no tiene un resultado numérico válido, así que el chip devuelve un valor especial llamado NaN, de not a number.

Restar dos infinitos iguales en signo también es indeterminado, y el resultado también es NaN. Estos casos no se resuelven con el sumador: el chip los detecta antes, comparando los bits de exponente y significando que identifican a un infinito o un NaN, y salta directo al resultado correcto sin pasar por la lógica de alineación.

El caso del cero con signo es más sutil. Si una resta da exactamente cero, el 8087 no puede normalizar un valor vacío, así que devuelve +0 o -0 según el signo que hubiera dado el cálculo. Esa distinción importa en operaciones posteriores, como dividir por el resultado: 1 dividido por +0 da +infinito, pero 1 dividido por -0 da -infinito.

Comparativa: del software al 8087 y al x87 moderno

La forma de resolver una suma en punto flotante cambió varias veces desde 1980. Esta tabla resume las opciones principales y cuándo tenía sentido cada una.
OpciónCuándo se usabaVentajaLimitaciónSoftware en el 8086Sistemas sin coprocesador, código solo con enterosNo necesita hardware adicionalCada suma en punto flotante cuesta decenas o cientos de ciclosCoprocesador 8087PC de IBM y clones con zócalo para el chip aparteAlineación y normalización en circuitería dedicadaChip extra, zócalo propio y mayor consumox87 integrado desde el 486DXCPU x86 de los 90 y 2000 con registros de 80 bitsMismo set de instrucciones, sin chip apartePila de registros rígida, difícil de optimizar por el compiladorSSE2 y AVXCódigo x86-64 moderno con precisión simple o dobleRegistros planos, vectoriza varias operaciones a la vezNo ofrece la precisión extendida de 80 bits del x87 original

Casos de uso reales

Lotus 1-2-3 y las primeras hojas de cálculo para IBM PC recomendaban el 8087 para recalcular miles de celdas con decimales sin trabar la máquina. Los programas de diseño asistido por computadora de la época, que multiplicaban matrices para proyectar superficies en 3D, dependían todavía más del coprocesador: cada vista en perspectiva implicaba miles de sumas y multiplicaciones en punto flotante.

Las estaciones de ingeniería y los primeros paquetes de simulación numérica también vendían el 8087 como upgrade casi obligatorio. Para 1985, el sucesor 80287 venía integrado de fábrica en varias placas basadas en 80286, señal de que el mercado ya daba por sentado tener un coprocesador matemático a bordo.

Errores comunes y gotchas

Suponer que restar es simétrico a sumar: la resta debe manejar signo negativo y el caso de resultado cero, algo que la suma nunca enfrenta.- Ignorar la cancelación catastrófica: restar dos números muy parecidos deja pocos bits significativos en el resultado, aunque la operación parezca trivial.- Pensar que el x87 sigue siendo el camino rápido: los compiladores modernos para x86-64 prefieren SSE2 o AVX, y reservan el x87 casi solo para el tipo long double de C.- Olvidar los casos de infinito y NaN al validar resultados: una suma con un operando infinito no dispara una excepción, devuelve otro infinito o un NaN según el caso.- Asumir que el desplazamiento es gratis: el shifter del 8087 lo resuelve en un solo paso, pero el software que lo emula bit por bit paga un costo que crece con el tamaño del desplazamiento.

Profundizando: por qué el shifter ocupa tanto espacio en el die

Un shifter bit a bit, que mueve una posición por ciclo, es barato en transistores pero lento cuando hay que desplazar los 64 bits del significando completos. El 8087 resuelve esto con un shifter tipo barril: varias capas de multiplexores donde cada capa decide si desplaza el valor una cantidad fija de posiciones (1, 2, 4, 8…), y la combinación de capas permite cualquier desplazamiento en un solo paso.

Ese diseño cuesta área de silicio, porque cada capa de multiplexores necesita tantas celdas como bits tiene el dato, multiplicadas por el número de capas. Ese costo explica por qué, dentro del datapath, el bloque del shifter resulta más grande que el del sumador entero, aunque el sumador haga aritmética en apariencia más compleja.

El contador de ceros a la izquierda sigue una lógica parecida: en vez de revisar bit por bit desde la izquierda hasta encontrar el primer 1, usa un árbol de comparadores que reduce la búsqueda a unos pocos niveles lógicos. Sin ese circuito, cada normalización de una resta con cancelación numérica tardaría en proporción al tamaño del desplazamiento, algo que el chip no podía permitirse si quería mantener su ventaja de velocidad frente al 8086.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: corré align_and_sub con otro par de números cercanos, como 100.25 y 99.75, y confirmá a mano cuántos bits de desplazamiento predice la normalización antes de ejecutar el código.

Preguntas frecuentes

¿Qué hace distinto al microcódigo del 8087 frente al software?

El microcódigo del 8087 corre dentro del chip y controla circuitería dedicada (sumador, shifter, conversor de exponente) en paralelo. Una rutina de software en el 8086 ejecuta las mismas alineaciones y normalizaciones con instrucciones enteras genéricas, paso por paso.

¿Por qué el coprocesador matemático 8087 necesita un shifter tan grande?

Porque alinear exponentes y normalizar resultados exige desplazar significandos de hasta 64 bits. Hacerlo en un solo ciclo, en vez de bit por bit, es lo que le da al chip su ventaja de velocidad frente a emular la operación en software.

¿Qué pasa si una resta en el 8087 da como resultado cero?

El chip no tiene nada que normalizar, así que devuelve directamente el valor especial +0 o -0, según el signo que hubiera correspondido al resultado antes de simplificarlo.

¿El FPU del 8087 maneja infinitos y valores NaN?

Sí: el 8087 detecta estos casos comparando los bits de exponente y significando antes de entrar a la lógica de suma o resta, y devuelve directamente infinito o NaN sin pasar por el sumador ni el shifter.

¿Sigue usándose el conjunto de instrucciones heredado del 8087 en CPUs actuales?

El set x87 sigue presente en los procesadores x86-64 por compatibilidad, pero los compiladores modernos prefieren SSE2 o AVX para punto flotante y reservan el x87 casi solo para el tipo long double de C.

Referencias

Righto.com: análisis del die del Intel 8087 y su microcódigo de suma y resta en punto flotante.- Wikipedia: historia y especificaciones del coprocesador matemático Intel 8087.- Wikipedia: estándar IEEE 754 para la representación de números en punto flotante.- Wikipedia: formato extendido de 80 bits usado por el x87, heredado del 8087.

Parser combinators en TypeScript, paso a paso

lu1tr0n — Sun, 18 Oct 2026 14:31:38 +0000

Una regex para separar fecha, hora y zona horaria funciona hasta que aparece un formato que no previste, y ahí hay que reescribir la expresión completa desde cero. Los parser combinators resuelven ese problema de otra manera: en vez de una expresión gigante, componés funciones chicas que se van pasando el resto del texto entre sí, como piezas que encajan.

TL;DR

Un parser es una función que recibe texto y devuelve el valor extraído junto con lo que falta por leer.- pSeq, pMap y pOr arman analizadores complejos sin escribir una gramática BNF por separado.- TypeScript tipa cada parser como Parser y el compilador avisa si mezclás tipos distintos.- Parsimmon aplica esta técnica en JavaScript para parsear JSON, fechas o configuraciones propias.- pBind deja que un valor ya leído decida cómo parsear lo que sigue, útil para campos de longitud variable.

¿Qué es parser combinators?

Parser combinators es el nombre de una técnica de programación funcional para construir analizadores sintácticos combinando funciones pequeñas y puras. Cada función, llamada parser, recibe una cadena de texto y devuelve el valor extraído junto con el resto sin consumir. Combinarlos permite armar parsers complejos sin escribir una gramática formal aparte.

Pensalo como una línea de ensamblaje: cada estación toma la pieza que le pasó la anterior, hace su trabajo puntual y entrega el resto a la siguiente estación. Ninguna estación necesita saber qué hace el resto de la línea, así que podés reordenar, quitar o agregar estaciones sin tocar las demás.
La librería Parsec, publicada para Haskell en los años 90, popularizó el patrón de combinar funciones de parseo.

Por qué importan los combinadores de parsers

Entre una regex de una línea y un generador de parsers como ANTLR hay un vacío enorme. El blog de T3 lo plantea con dos extremos. Una regex se vuelve ilegible apenas el formato tiene estructura anidada, y tree-sitter, la librería que impulsa el resaltado de sintaxis de muchos editores de código, es demasiado pesada para un parser que vas a usar una sola vez. Los combinadores de parsers ocupan ese punto medio.

La ventaja aparece en el trabajo diario de un backend: parsear una cabecera HTTP propia, un formato de log, un mini lenguaje de configuración o un protocolo binario simple. Ninguno de esos casos justifica instalar un generador de gramáticas, pero todos se vuelven frágiles con una sola regex gigante que nadie quiere tocar después.

Cómo funcionan los parsers combinables

Así es como los parser combinators consumen la cadena de entrada paso a paso: cada parser recibe el string completo que falta procesar, se queda con la porción que entiende y devuelve el resto para el siguiente. El tipo que describe esa idea en TypeScript es compacto.

type Parser = (input: string) => [T, string];

Un Parser<T> es una función de un string a una tupla con el valor T y el string restante. No hay clase, no hay estado compartido, no hay configuración previa que inicializar.

flowchart LR
A["Texto de entrada"] --> B["Parser 1 consume una parte"]
B --> C["Parser 2 consume la siguiente parte"]
C --> D["Parser 3 consume el resto"]
D --> E["Resultado final y string vacio"]

El parser más chico posible

El parser más simple reconoce dígitos y los convierte en número.

const pNumber: Parser = (input) => {
  const match = input.match(/^\d+/);
  if (match === null) throw new Error("se esperaba un numero");
  const digits = match[0];
  return [Number(digits), input.slice(digits.length)];
};

console.log(pNumber("42 manzanas"));

La salida es [ 42, ' manzanas' ]. El parser cortó los dígitos iniciales y devolvió el número junto con todo lo que todavía no se procesó.

Secuencias con pSeq

Un solo parser no alcanza para nada real. pSeq encadena varios parsers pasando el resto de uno como entrada del siguiente.

sequenceDiagram
participant P as pSeq
participant A as pVerbo
participant B as pEspacio
participant C as pNumber
P->>A: entrada completa
A-->>P: devuelve verbo y resto
P->>B: resto despues del verbo
B-->>P: devuelve espacio y resto
P->>C: resto despues del espacio
C-->>P: devuelve numero y resto final
Note over P: combina los tres resultados en una tupla

const pLiteral = (texto: string): Parser => (input) => {
  if (!input.startsWith(texto)) throw new Error(`se esperaba "${texto}"`);
  return [texto, input.slice(texto.length)];
};

function pSeq(
  ...parsers: { [K in keyof T]: Parser }
): Parser {
  return (input) => {
    const resultados: unknown[] = [];
    let resto = input;
    for (const parser of parsers) {
      const [valor, nuevoResto] = parser(resto);
      resultados.push(valor);
      resto = nuevoResto;
    }
    return [resultados as T, resto];
  };
}

const pMetodo = pLiteral("GET");
const pEspacio = pLiteral(" ");
const pLinea = pSeq(pMetodo, pEspacio, pNumber);

console.log(pLinea("GET 200 restante"));

La salida es [ [ 'GET', ' ', 200 ], ' restante' ]. Cada parser de la secuencia se quedó con su porción y el último dejó el resto sin tocar.

Transformar resultados con pMap y elegir con pOr

pMap aplica una función al valor ya extraído sin tocar el resto del string, y pOr prueba varias alternativas en orden hasta encontrar la primera que no lance error.

function pMap(parser: Parser, fn: (valor: A) => B): Parser {
  return (input) => {
    const [valor, resto] = parser(input);
    return [fn(valor), resto];
  };
}

function pOr(...parsers: Parser[]): Parser {
  return (input) => {
    for (const parser of parsers) {
      try {
        return parser(input);
      } catch {
        continue;
      }
    }
    throw new Error("ninguna alternativa coincidio");
  };
}

const pVerboHttp = pOr(pLiteral("GET"), pLiteral("POST"), pLiteral("DELETE"));

const pEntradaLog = pMap(
  pSeq(pVerboHttp, pEspacio, pNumber),
  ([verbo, _, status]) => ({ verbo, status })
);

console.log(pEntradaLog("POST 201 ok"));

La salida es [ { verbo: 'POST', status: 201 }, ' ok' ]. El parser combinado ya devuelve un objeto útil, no una tupla posicional que hay que recordar cómo leer.

flowchart TD
A["Parsers basicos: pNumber, pLiteral"] --> B["Combinadores de secuencia: pSeq"]
A --> C["Combinadores de eleccion: pOr"]
B --> D["Combinadores de transformacion: pMap"]
C --> D
D --> E["Combinadores de repeticion: pSepBy"]
E --> F["Combinadores dependientes: pBind"]

Ejemplos prácticos y cómo empezar

El combinador que falta para casos reales es el de repetición. pSepBy parsea una lista de ítems separados por un delimitador, algo que una regex puede hacer para casos chicos pero que se vuelve ilegible con separadores anidados.

function pSepBy(item: Parser, separador: Parser): Parser {
  return (input) => {
    const items: T[] = [];
    let resto = input;
    while (true) {
      try {
        const [valor, nuevoResto] = item(resto);
        resto = nuevoResto;
        items.push(valor);
        const [, despuesDeSeparador] = separador(resto);
        resto = despuesDeSeparador;
      } catch {
        break;
      }
    }
    return [items, resto];
  };
}

const pListaNumeros = pSepBy(pNumber, pLiteral(","));
console.log(pListaNumeros("10,20,30 fin"));

La salida es [ [ 10, 20, 30 ], ' fin' ]. El bucle usa while en lugar de recursión a propósito: la recursión en JavaScript y TypeScript no hace tail-call optimization, así que una lista de miles de ítems resuelta de forma recursiva puede desbordar la pila.

Cómo empezar

Para correr estos ejemplos tal cual, necesitás Node.js instalado (versión 18 o superior) y nada más. Los comandos son los mismos en Linux, macOS y Windows con PowerShell, porque son comandos de npm y no del shell del sistema.

mkdir parser-combinators-demo && cd parser-combinators-demo
npm init -y
npm install --save-dev typescript ts-node @types/node
npx tsc --init

Con el proyecto creado, guardá el código de los ejemplos anteriores en un archivo parser.ts y corrélo con:

npx ts-node parser.ts

Para confirmar que el tipado funciona de verdad, cambiá pNumber por un parser que devuelva string dentro de pSeq(pMetodo, pEspacio, pNumber) y corré npx tsc --noEmit. El compilador tiene que fallar con un error de tipos en esa línea, antes de ejecutar nada.

Casos de uso reales

Los parsers combinables aparecen en el código de producción con más frecuencia de la que parece. Un equipo de backend los usa para leer líneas de log con un formato propio, donde cada campo tiene un tipo distinto y una regex terminaría con grupos de captura imposibles de mantener.

También sirven para lenguajes de configuración caseros, el tipo de sintaxis que un equipo inventa para su propia herramienta interna y que no justifica una gramática formal versionada aparte. Y aparecen en protocolos de red simples: formatos donde un campo indica la longitud del que sigue, como se ve más adelante en la sección de combinadores dependientes.

Parsimmon es la librería de parsing combinatorio más usada en el ecosistema de JavaScript y aplica exactamente esta idea para parsear JSON, fechas con formatos no estándar o lenguajes de plantillas propios, sin depender de un generador externo.
El protocolo RESP de Redis y el formato bencode de BitTorrent usan el mismo patrón: longitud seguida de contenido.

Errores comunes y buenas prácticas

Orden en pOr: la primera alternativa que coincide gana, aunque no sea la más específica. Si pLiteral("GET") y pLiteral("GETX") compiten, poné primero la más larga o vas a cortar mal el texto.- Espacios olvidados: si el formato permite espacios entre tokens, hay que consumirlos explícitamente en cada punto donde pueden aparecer, no solo al principio de la cadena completa.- Recursión sin límite: un combinador de repetición escrito con recursión en vez de un bucle puede desbordar la pila con entradas largas, por eso pSepBy usa while en el ejemplo anterior.- Excepciones como control de flujo: usar throw/catch para señalar que un parser falló es simple de leer, pero mezcla manejo de errores con lógica de parseo. Para producción conviene migrar a un tipo Result explícito que distinga éxito de fallo sin lanzar excepciones.- Mensajes de error sin posición: un parser que solo dice "no coincide" es inútil para debuggear un archivo de miles de líneas. Hay que envolver cada parser para que reporte también el índice donde falló.

Comparativa con alternativas

Ninguna de estas técnicas es universalmente mejor; cada una resuelve un rango distinto de formatos.
TécnicaCuándo usarlaVentajaLimitaciónRegexPatrones simples, sin anidamientoNativa en casi todo lenguaje, rápida de escribirIlegible y rígida ante estructura anidadaCombinadores de parsersFormatos a medida con estructura moderada: logs, configs, DSL chicosComposable, tipado, se prueba parser por parserRequiere pensar en funciones puras y backtracking manualGenerador de parsers (ANTLR)Lenguajes grandes con gramática formal estableGenera un parser óptimo desde una gramática declarativaAgrega un paso de build y una gramática separada del códigoParser manual (descenso recursivo)Rendimiento crítico o control total sobre los erroresSin dependencias, control absolutoMás código repetido y más difícil de mantener

Profundizando: de dónde viene esta idea

Los parser combinators heredan esta idea directamente de Parsec, la librería de Haskell de los años 90 que popularizó el patrón de componer parsers con operadores en lugar de generar código desde una gramática. La clave teórica es que cada parser implementa lo que en Haskell se llama una mónada, una estructura que define cómo encadenar operaciones que pueden fallar o depender del resultado anterior.

💭 Clave: pSeq y pMap alcanzan para combinar parsers independientes entre sí, pero no sirven cuando el segundo parser depende del valor que devolvió el primero, no solo de su tipo. Para eso hace falta un combinador más, pBind.

Un caso real de esa dependencia es un campo con longitud variable: primero se lee un número, y ese número dice cuántos caracteres leer después. Es el mismo patrón que usan el protocolo RESP de Redis y el formato bencode de BitTorrent.

function pBind(parser: Parser, fn: (valor: A) => Parser): Parser {
  return (input) => {
    const [valor, resto] = parser(input);
    return fn(valor)(resto);
  };
}

const pTomar = (n: number): Parser => (input) => [input.slice(0, n), input.slice(n)];

const pCampoConLongitud: Parser = pBind(pNumber, (longitud) =>
  pMap(pSeq(pLiteral(":"), pTomar(longitud)), ([, texto]) => texto)
);

console.log(pCampoConLongitud("5:holamundo"));

La salida es [ 'holam', 'undo' ]. pNumber lee el 5, y ese valor decide que pTomar debe cortar exactamente cinco caracteres después de los dos puntos. pSeq no podría expresar esto porque no conoce el valor del parser anterior, solo encadena su resto.

La otra pieza avanzada es el rendimiento del backtracking: cuando pOr prueba varias alternativas sobre la misma posición del texto, puede repetir trabajo si esas alternativas comparten un prefijo largo. La técnica clásica para evitarlo es el packrat parsing, que cachea el resultado de cada parser en cada posición de entrada para no volver a calcularlo.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: tomá el ejemplo de pSepBy de esta guía, modificalo para que ignore espacios opcionales antes y después de la coma usando un parser de espacios en blanco entre item y separador, y probalo contra "10, 20 ,30" para ver dónde falla.

Preguntas frecuentes

¿Los parser combinators reemplazan una gramática formal como BNF?

No necesariamente. Para lenguajes grandes y estables, una gramática declarativa que alimenta un generador como ANTLR sigue siendo más mantenible. Los combinadores de parsers brillan en formatos chicos o cambiantes donde versionar una gramática aparte no se justifica.

¿Qué diferencia hay entre parsers combinables y expresiones regulares?

Una regex describe un patrón plano con backtracking interno oculto. Un parser combinable es una función explícita que se puede testear, componer y tipar por separado; el costo es más código para resolver el mismo patrón simple.

¿El parsing combinatorio es más lento que un parser generado?

Puede serlo si el backtracking recorre la misma porción del texto varias veces. La solución clásica es el packrat parsing, que cachea el resultado de cada parser en cada posición para no repetir trabajo.

¿Necesito saber programación funcional para usar combinadores de parsers?

Ayuda entender funciones de orden superior, pero no hace falta Haskell ni mónadas para empezar. pSeq, pMap y pOr se leen y se escriben como cualquier función de TypeScript o JavaScript.

¿Qué librerías de parsing combinatorio existen en JavaScript o TypeScript?

Parsimmon es la más usada en el ecosistema de Node.js. También hay variantes pensadas para TypeScript puro, todas con la misma idea de parsers chicos combinados con funciones de orden superior.

¿Los parsers combinables sirven para compiladores de lenguajes completos?

Sí, con matices. Proyectos reales los usan para el frontend de lenguajes de tamaño moderado, pero cuando la gramática crece mucho el costo de mantenimiento suele empujar hacia un generador de parsers o un parser de descenso recursivo escrito a mano.

Referencias

T3: Parser Combinators: el artículo original que inspira esta guía, con el tipo Parser y los ejemplos de pSeq y pHello.- Wikipedia: Parser combinator: definición y contexto histórico de la técnica.- Parsimmon en GitHub: librería de parsing combinatorio para JavaScript usada en producción.- ANTLR: generador de parsers de referencia para gramáticas grandes y formales.- tree-sitter: librería de parsing incremental que impulsa el resaltado de sintaxis de editores modernos.

DeepSeek lanza Search API y Fetch API para agentes y RAG

lu1tr0n — Sun, 18 Oct 2026 08:27:55 +0000

DeepSeek acaba de completar su API con dos piezas que le faltaban: búsqueda y lectura de páginas web en vivo. La Search API de DeepSeek y su compañera, la Fetch API, llegan bajo el mismo token Bearer que ya usan los desarrolladores para chat completions, sobre el motor de búsqueda que la empresa opera de forma interna, sin pasar por Google, Bing ni un proveedor externo como SerpAPI o Tavily.

La guía oficial describe dos endpoints REST: uno busca en la web y devuelve resultados estructurados, el otro toma una URL puntual y la convierte en Markdown. Juntos resuelven lo que antes exigía ensamblar herramientas de terceros.

TL;DR

DeepSeek lanza la Search API y la Fetch API, dos endpoints REST para que agentes busquen y lean la web.- La Search API usa el motor de búsqueda propio de DeepSeek y acepta operadores como site:, lang:, after: y before:.- Cada resultado trae un rerank_score de 0 a 3 que mide relevancia, autoridad y frescura combinadas.- Fetch API convierte una sola página web en Markdown listo para que el modelo la lea sin parsear HTML.- Ambos endpoints se autentican con el mismo Bearer token que usa el resto de la API de DeepSeek.

Qué es la Search API de DeepSeek

La Search API de DeepSeek es un endpoint REST que devuelve resultados de búsqueda web estructurados (título, URL, resumen y una puntuación de relevancia) a partir de una consulta de texto, usando el motor de búsqueda que la compañía opera internamente.

Es, en palabras de la propia documentación oficial, una API JSON cruda: no hay capa de chat ni function calling automático de por medio. El desarrollador decide cuándo llamarla, qué hacer con los resultados y en qué momento pasarlos al modelo como contexto, igual que con cualquier integración de RAG armada a mano.
DeepSeek expone ambos endpoints bajo la misma base api.deepseek.com, sin dominio aparte.

Qué pasó

La documentación publicada por DeepSeek detalla dos rutas nuevas bajo la misma base que el resto de la plataforma: POST https://api.deepseek.com/v1/tools/search para buscar, y POST https://api.deepseek.com/v1/tools/fetch para leer una página puntual. Ambas usan la cabecera Authorization: Bearer <DeepSeek API Key> y Content-Type: application/json, exactamente como las llamadas de chat completions.

No es un modelo nuevo ni una actualización de V3 o R1: es infraestructura de soporte, pensada para que agentes y aplicaciones de recuperación aumentada (RAG) consulten la web vigente sin salir del ecosistema de DeepSeek ni sumar un proveedor de búsqueda aparte.

Contexto e historia

DeepSeek construyó su reputación con modelos de pesos abiertos (V3, R1 y sus variantes) ofrecidos a precios muy por debajo de la competencia estadounidense. Pero un modelo, por sí solo, no resuelve que la información cambia todos los días: para responder sobre algo de esta semana, un agente necesita buscar en la web en el momento de la consulta, no solo recordar lo que vio durante el entrenamiento.

Otros laboratorios ya resolvieron esa pieza para sus propios modelos: OpenAI integró navegación web en su API de Responses, Anthropic ofrece una herramienta de búsqueda web nativa para Claude, y Google conecta Gemini con su propio índice mediante grounding. Hasta ahora, un desarrollador que quisiera lo mismo con DeepSeek tenía que contratar aparte una API de búsqueda como Bing, SerpAPI, Tavily o Exa, y después unir esos resultados al prompt a mano. El buscador propio de DeepSeek cierra esa brecha sin que el desarrollador salga de la cuenta que ya tiene.

Detalles técnicos: cómo funciona el buscador propio de DeepSeek

La consulta (query) acepta entre 1 y 128 caracteres Unicode y se reenvía casi intacta al índice interno, lo que significa que los operadores de búsqueda no los procesa DeepSeek: los interpreta el motor que hay detrás. Eso incluye site: y -site: para incluir o excluir dominios, comillas para frases exactas o su negación con -\"frase\", lang: para restringir idioma, y after:/before: para acotar por fecha. Todos se combinan en una sola cadena, por ejemplo DeepSeek site:github.com OR site:huggingface.co lang:en after:2025.

💡 Tip: combinar after: con lang:es es la forma más directa de filtrar ruido cuando el agente solo necesita noticias recientes en español.

Cada resultado trae un campo rerank_score de 0 a 3 que combina señales de relevancia, autoridad y frescura; según la documentación oficial, un puntaje de 1.5 o más ya se considera de alta calidad. El campo snippet es un resumen corto (entre 100 y 200 caracteres) pensado para una interfaz, mientras que summary es más largo (entre 600 y 800 caracteres) y está pensado para que lo lea el modelo directamente.

El parámetro que más cambia el costo de la llamada es need_content. En false (el valor por defecto), el campo content siempre llega vacío: la API solo devuelve metadatos y resúmenes. En true, DeepSeek además descarga la página completa y la entrega en el mismo array de resultados, lo que suma latencia y tokens de contexto si el agente va a pasarle ese contenido al modelo. La Fetch API resuelve el caso en que ya se conoce la URL exacta: en vez de buscar, pide directamente esa página y la devuelve convertida a Markdown, sin el resto de los campos de un resultado de búsqueda.
EndpointCuándo usarloVentajaLimitaciónSearch API (/v1/tools/search)No se conoce la URL, hay que descubrir qué página responde la consultaDevuelve varios candidatos con rerank_score para elegirSin need_content no trae el texto completoFetch API (/v1/tools/fetch)Ya se tiene la URL (de un resultado de Search o de una cita del usuario)Devuelve la página entera en Markdown, lista para el modeloUna sola página por llamada, no busca nada

sequenceDiagram
participant A as Agente o app
participant S as Search API
participant M as Motor interno de DeepSeek
participant F as Fetch API
A->>S: POST /v1/tools/search (query, count)
S->>M: ejecuta la consulta con operadores
M-->>S: resultados con rerank_score
S-->>A: results en JSON
A->>F: POST /v1/tools/fetch (url)
F-->>A: pagina convertida a Markdown

curl https://api.deepseek.com/v1/tools/search \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "DeepSeek Search API site:github.com after:2026",
    "count": 5,
    "need_content": false
  }'

La documentación ilustra la forma de la respuesta con un ejemplo (no son datos de producción, solo el esquema): un array results donde cada elemento trae rerank_score, title, url, snippet, summary, site_name y date. Una búsqueda sin coincidencias no da error: devuelve results: [] con HTTP 200, que es también la forma más simple de confirmar que una cuenta tiene el acceso habilitado. Un 401 en esa misma llamada indica que el Bearer token no tiene el scope de búsqueda activo.

📌 Nota: al ser una API JSON cruda y no una herramienta de function calling, el modelo de DeepSeek no decide solo cuándo buscar: es el código del agente el que llama a /v1/tools/search y después arma el prompt con lo que recibe.
Con need_content en false, el campo content de cada resultado llega siempre vacío.

Impacto y análisis

Para un desarrollador que ya paga por los modelos de DeepSeek, la ganancia inmediata es operativa: un proveedor menos que facturar, un token menos que rotar, y una API con el mismo formato de autenticación que el resto de la plataforma. Eso simplifica el stack de un agente que antes necesitaba la clave de DeepSeek para generar texto y la clave de otro proveedor solo para buscar.

La contrapartida es que la calidad de los resultados depende por completo del índice propio de DeepSeek, que no tiene el historial ni la cobertura documentada públicamente de Google o Bing. La guía tampoco especifica un precio separado para estos endpoints más allá de lo que ya cuesta la cuenta de API: hasta la fecha de este artículo no hay un apartado de pricing propio para Search y Fetch en la documentación pública, así que conviene revisar la sección de precios antes de meter el buscador propio de DeepSeek en un flujo con volumen alto de llamadas.

También hay una arista de privacidad poco comentada: el parámetro localization acepta una IP para ajustar resultados por geografía, lo que implica que, si un agente reenvía la IP real del usuario final, esa dirección queda en la solicitud a DeepSeek igual que pasaría con cualquier buscador que geolocalice consultas.

Qué sigue

Lo que falta por confirmar es si DeepSeek va a exponer estos dos endpoints como function calling nativo dentro de chat completions, para que el modelo decida solo cuándo buscar en vez de que lo orqueste el código del agente, y si va a publicar límites de tasa y una tabla de precios dedicada. También queda por verse si otros laboratorios de pesos abiertos con enfoque similar en costo responden empaquetando su propio buscador en lugar de dejarlo en manos de integraciones de terceros.

📖 Resumen en Telegram: Ver resumen

Probalo vos: hacé un POST a https://api.deepseek.com/v1/tools/search con tu API key y una consulta con site: para ver el array de results antes de conectarlo a un agente en producción.

Preguntas frecuentes

¿Qué hace la Search API de DeepSeek que no haga una búsqueda normal en Google?

Responde en JSON estructurado pensado para que lo lea un modelo, no una persona: cada resultado trae rerank_score, summary y, si se pide, el contenido completo de la página. Usa los mismos operadores de búsqueda (site:, lang:, after:) pero bajo la cuenta y la facturación que ya tiene el desarrollador con DeepSeek.

¿Cómo se autentica la Fetch API de DeepSeek?

Con el mismo esquema que el resto de la plataforma: una cabecera Authorization: Bearer y Content-Type: application/json. No existe una clave separada para búsqueda o fetch.

¿Qué significa el rerank_score que devuelve el buscador propio de DeepSeek?

Es un número de 0 a 3 que combina relevancia, autoridad y frescura de cada página. Según la documentación oficial, 1.5 o más indica un resultado de alta calidad; valores más bajos no significan que la página esté rota, solo que el sistema la considera menos relevante para esa consulta puntual.

¿El buscador propio de DeepSeek reemplaza un pipeline de RAG completo?

No. Cubre la parte de recuperación de contenido público de la web vigente, pero no reemplaza embeddings, bases vectoriales ni el chunking de documentos privados. Para datos propios de una empresa, sigue siendo complementario a un pipeline de RAG tradicional, no un sustituto.

¿Qué pasa si need_content queda en false al llamar al buscador propio de DeepSeek?

El campo content de cada resultado llega vacío; solo se completa cuando need_content se manda en true, lo que además suma latencia porque DeepSeek tiene que descargar la página completa antes de responder.

Referencias

DeepSeek API Docs: guía oficial de Search y Fetch API, con esquemas de request y response.- DeepSeek API Docs: catálogo completo de endpoints de la plataforma, incluida la autenticación Bearer.- DeepSeek: sitio oficial de la compañía y sus modelos.- Wikipedia: historia y contexto de DeepSeek como laboratorio de IA.

Furifont: cómo OpenType incrusta la furigana en la fuente

lu1tr0n — Sun, 18 Oct 2026 02:47:23 +0000

Furifont incrusta la furigana en la fuente misma: no hace falta el tag <ruby> ni una sola línea de CSS para que la lectura en kana aparezca arriba del kanji correcto.

El proyecto, publicado por el desarrollador Anthony Fu en furifont.antfu.me, usa sustituciones contextuales y variantes estilísticas de OpenType (las mismas funciones que combinan letras en una ligadura o cambian el estilo de un número) para resolver un problema tipográfico que hasta ahora dependía de markup externo.

TL;DR

Furifont dibuja la furigana dentro del glifo del kanji usando sustituciones contextuales de OpenType, sin ruby ni CSS.- GSUB, la tabla de sustitución de glifos, elige la lectura correcta según el kanji vecino sin una línea de JavaScript.- Elegir la lectura manualmente es posible con variantes estilísticas cuando un kanji admite varias pronunciaciones.- Sin soporte de esas funciones de OpenType, el navegador muestra el kanji solo, sin romper el resto del layout.- La misma técnica sirve para pinyin, transliteración árabe o cualquier anotación que hoy depende de HTML extra.

¿Qué es Furifont?

Furifont es una fuente OpenType experimental que incrusta la furigana en la fuente mediante sustituciones de glifos: cada kanji con su lectura se reemplaza por un glifo compuesto que ya incluye los caracteres kana en miniatura, sin marcado adicional en el documento.

La furigana en sí no es nueva: los diccionarios y los libros infantiles japoneses la usan desde hace más de un siglo para anotar la pronunciación de un kanji complejo arriba o al costado del carácter principal. Internet resolvió el problema con el elemento <ruby> de HTML, estandarizado por el W3C, pero ese marcado depende de que cada plataforma (un lector de EPUB, un generador de PDF, un editor de texto plano) lo implemente correctamente.

Furifont ataca el problema desde otro ángulo, pidiéndole a la fuente que haga el trabajo en lugar de depender de una etiqueta nueva. Cualquier aplicación que ya sabe renderizar texto con OpenType, que es prácticamente todo el software moderno, muestra la furigana sin ningún cambio de código.

Para alguien que recién empieza a leer japonés, la furigana cumple la misma función que un pequeño cartel de pronunciación al lado de una palabra difícil: no reemplaza aprender el kanji, pero permite leer el texto completo desde el primer día sin frenar cada tres palabras a buscar en un diccionario.

Por qué importa la furigana embebida en glifos

El soporte de <ruby> en la web es parejo, pero fuera del navegador es irregular. Generadores de PDF, motores de slides y varios lectores de EPUB todavía no posicionan la furigana donde corresponde, o simplemente la ignoran. Para un material educativo que necesita verse igual en una app, un PDF impreso y una página web, cada renderer que falla es un dolor de cabeza distinto.

Al mover la anotación a la fuente, Furifont saca ese problema de la ecuación. Si el software sabe mostrar texto en japonés con una tipografía OpenType moderna, algo que cubre a casi todo el software actual, ya sabe mostrar la furigana. No hay que parchear el lector de EPUB ni el generador de PDF.

La inconsistencia no es teórica. Algunos lectores de EPUB posicionan la furigana demasiado cerca de la línea anterior cuando el texto tiene mucho kanji consecutivo, y ciertos generadores de PDF basados en motores de layout más viejos ni siquiera reconocen bien el markup ruby, mostrando la lectura como texto suelto fuera de lugar.

El valor del proyecto no está solo en resolver furigana. Fu lo plantea como demostración de una técnica más amplia de font engineering: cualquier anotación secundaria que hoy dependa de markup (el pinyin sobre un carácter chino, la vocalización sobre una consonante árabe, una transcripción fonética sobre una palabra) se puede empujar hacia la capa de la fuente con las mismas herramientas de OpenType.
La furigana acompaña al kanji en diccionarios japoneses desde hace más de un siglo.

Cómo funciona la furigana en la fuente

Todo pasa en la etapa de shaping, el paso donde un motor de texto convierte una cadena Unicode en una secuencia de glifos con posición. Un navegador, un editor o un sistema operativo no dibuja letras, dibuja los glifos que la fuente le indica, siguiendo las reglas que trae la fuente misma en sus tablas internas.

El pipeline de shaping: de texto a glifo compuesto

Motores de shaping como HarfBuzz (usado por Chrome, Firefox y la mayoría de Linux) o CoreText en macOS reciben la cadena de kanji y consultan la tabla GSUB (Glyph Substitution) de la fuente. Esa tabla define reglas: si aparece tal secuencia de caracteres en tal contexto, sustituí el glifo simple por otro. Furifont define, para cada kanji que soporta, una regla que apunta a un glifo compuesto, y ese glifo nuevo no es solo el trazo del kanji: incluye además los caracteres kana de la lectura dibujados en miniatura, ya posicionados y escalados dentro del mismo contorno.

flowchart TD
A["Texto: kanji y contexto"] --> B["Motor de shaping (HarfBuzz)"]
B --> C["Tabla GSUB: lookup calt"]
C --> D["Existe regla contextual"]
D -->|"Si"| E["Sustituye por glifo compuesto"]
D -->|"No"| F["Muestra el kanji sin furigana"]
E --> G["Glifo con kana en miniatura"]

Sustituciones contextuales (GSUB) para elegir la lectura correcta

La función calt (contextual alternates) es la pieza clave: decide qué glifo mostrar según los caracteres vecinos, no solo según el carácter aislado. Esto importa porque un mismo kanji puede leerse de maneras distintas según la palabra que forma. Una regla calt bien escrita mira el kanji siguiente o anterior y elige el glifo compuesto con la lectura correcta para ese contexto específico.

Variantes estilísticas para las excepciones

El contexto no siempre alcanza para desambiguar. Cuando un kanji admite varias lecturas válidas en el mismo contexto, algo común en nombres propios japoneses, Furifont recurre a las variantes estilísticas, la familia de funciones ss01 a ss20 que el estándar OpenType reserva para que un diseñador o el propio usuario elija manualmente entre glifos alternativos. En lugar de que la fuente adivine, el documento activa una variante estilística específica para forzar la lectura correcta en ese kanji puntual.

Cómo se construye el glifo compuesto

Diseñar cada glifo compuesto es trabajo de tipografía, no de programación. En una herramienta como FontForge o Glyphs, el diseñador toma el contorno del kanji, agrega los contornos de los caracteres kana reducidos a una fracción del tamaño y los posiciona en el espacio superior del glifo, ajustando el avance horizontal para que el conjunto no choque con el glifo vecino. Ese glifo nuevo se guarda con su propio nombre dentro de la tabla de glifos de la fuente (glyf en TrueType o CFF en fuentes OpenType-CFF), y la tabla GSUB simplemente indica que, cuando aparezca el glifo original de ese kanji en ese contexto, hay que usar este otro glifo en su lugar. Herramientas como fonttools, la librería en Python que lee y escribe binarios de fuentes, permiten automatizar buena parte de ese mapeo generando reglas GSUB a partir de una lista de pares kanji-lectura en vez de escribirlas a mano una por una.

Ejemplos prácticos y cómo empezar

Probar la anotación furigana incrustada no requiere compilar nada: alcanza con cargar la fuente vía @font-face y activar las funciones de OpenType correctas desde CSS.

Activar las funciones por CSS

@font-face {
  font-family: "Furifont";
  src: url("Furifont.ttf") format("truetype");
}

.furigana {
  font-family: "Furifont", sans-serif;
  font-feature-settings: "calt" 1;
}

Este bloque carga la fuente y activa calt, la función que dispara las sustituciones contextuales. Con esto, un <span class="furigana"> que contenga un kanji soportado por Furifont ya debería mostrar la lectura en miniatura arriba, sin ningún otro cambio en el HTML.

.furigana-manual {
  font-family: "Furifont", sans-serif;
  font-feature-settings: "calt" 1, "ss03" 1;
}

Acá se suma ss03 para forzar una variante estilística puntual, útil cuando el kanji tiene una lectura ambigua que el contexto solo no puede resolver, por ejemplo un nombre propio. El número de variante depende de cómo Furifont mapeó cada lectura alternativa en su propia tabla GSUB.

Verificar que la sustitución está activa

Firefox trae un inspector de fuentes dentro de las herramientas de desarrollo, en la pestaña Fuentes del panel de Inspector, que lista para el texto seleccionado qué funciones OpenType trae la fuente y cuáles están activas. Si calt aparece marcado y el kanji en pantalla muestra la furigana, la sustitución está funcionando. Si el kanji se ve solo, sin la lectura arriba, lo primero a revisar es que font-feature-settings llegó al elemento y no fue sobrescrito por otra regla con mayor especificidad.

flowchart LR
A["Fuente Furifont cargada"] --> B["Renderizador soporta GSUB contextual"]
B -->|"Si"| C["Muestra kanji con furigana incrustada"]
B -->|"No"| D["Muestra solo el kanji base"]
C --> E["Texto copiado conserva solo el kanji"]
D --> E

Casos de uso reales

Libros electrónicos: el soporte de <ruby> varía entre lectores de EPUB, así que incrustar la furigana en la fuente evita que la lectura desaparezca en un dispositivo que ignora el markup.- Material de aprendizaje de japonés: apps y hojas de práctica que solo necesitan tipear el kanji y dejar que la fuente muestre la lectura.- Documentos y PDFs generados por sistemas que no controlan HTML: reportes, facturas o formularios donde agregar <ruby> no es una opción.- Subtitulado y señalética digital: pantallas que renderizan texto plano sin motor de ruby, donde forzar una variante estilística puntual es más simple que integrar un parser de markup nuevo.- Font engineering general: la misma idea de sustitución contextual sirve para incrustar pinyin sobre caracteres chinos o vocalización sobre consonantes árabes.
OpenType reserva hasta 20 variantes estilísticas, ss01 a ss20, por fuente.

Errores comunes y buenas prácticas
Copiar y pegar pierde la lectura: el texto subyacente sigue siendo solo el kanji, la furigana es puramente visual.- Explosión de glifos: cada combinación de kanji con lectura necesita su propio glifo compuesto, así que una fuente completa no puede cubrir todas las lecturas posibles.- Motores de render antiguos: si el software no implementa GSUB contextual o ignora calt por defecto, el kanji se muestra solo.- Altura de línea: el glifo compuesto ocupa más alto que un kanji normal, así que hay que ajustar el line-height a mano para que la furigana no se corte.

💭 Clave: Furifont resuelve la presentación de la furigana, no su accesibilidad: para un lector de pantalla o un buscador, el texto sigue siendo solo el kanji.

Comparativa con alternativas

La tabla siguiente compara la furigana en la fuente con las alternativas más usadas para anotar lecturas en texto japonés, en la web y fuera de ella.
OpciónCuándo usarlaVentajaLimitación/ HTMLPáginas web donde controlás el markupEstándar, accesible, el texto real incluye la lecturaRequiere marcar cada palabra a mano y soporte del rendererCSS generado (content/attr)Cuando no podés tocar el HTML pero sí el CSSNo duplica el kanji en el DOMNo es accesible para lectores de pantalla ni copiableFurifont (furigana en la fuente)Documentos, PDFs o apps sin control sobre el motor de renderCero marcado adicional, funciona en cualquier texto planoEl archivo de fuente crece y el texto copiado pierde la lecturaImagen o SVG prerenderizadoSeñalética o materiales impresos fijosControl visual totalNo es texto real: no se puede buscar, copiar ni reflow

Profundizando: dentro de la tabla GSUB

La especificación de OpenType define varios tipos de lookup dentro de GSUB, numerados del 1 al 8. Una ligadura simple, como combinar dos letras en un solo glifo, usa el lookup tipo 4. Lo que hace Furifont se acerca más al tipo 6, sustitución contextual encadenada, que permite mirar glifos antes y después del objetivo antes de decidir el reemplazo. Esa es la maquinaria que calt expone al diseñador de la fuente sin que el autor del documento tenga que escribir una sola regla.

El costo de este enfoque es combinatorio. Cada combinación de kanji más lectura que la fuente quiera soportar necesita su propio glifo compuesto, dibujado a mano o generado por script, con la kana en miniatura ya posicionada dentro del contorno. Un kanji con cinco lecturas comunes implica cinco glifos distintos en la fuente, no uno. Esto pone un techo práctico a cuántas combinaciones puede cubrir una sola fuente antes de que el archivo crezca demasiado, así que proyectos como este suelen enfocarse en un vocabulario acotado en lugar de cubrir los miles de kanji de uso común con todas sus lecturas.

Una alternativa técnica que la fuente también podría explotar es GPOS, la tabla de posicionamiento de glifos que usa el mismo mecanismo que acentos y diacríticos combinables en escrituras como el árabe o el hebreo. En vez de reemplazar el kanji por un glifo compuesto, la fuente podría adjuntar los caracteres kana como marcas ancladas sobre el kanji base, reutilizando el mismo glifo del kanji en otros contextos. Esa ruta reduce la explosión de glifos, pero complica el control fino sobre el tamaño y la posición exacta de cada kana, que es justamente lo que un glifo compuesto resuelve de una sola vez.

El shaping ocurre una sola vez por cada corrida de texto y el motor de layout cachea el resultado, así que no hay costo de rendimiento en tiempo de ejecución más allá del que ya paga cualquier texto con ligaduras o kerning. La limitación real es otra: el texto subyacente, lo que queda en el portapapeles, lo que indexa un buscador, lo que lee un lector de pantalla, sigue siendo solo el kanji. La furigana vive en la capa visual, no en los datos, algo que el elemento <ruby> de HTML sí resuelve porque la lectura es texto real dentro del documento.

La idea de resolver anotaciones tipográficas dentro de la fuente, en lugar de en el documento, no es exclusiva de Furifont. Los sistemas de tipografía asiática llevan décadas lidiando con el problema de dónde vive la información de lectura, y el propio ruby de HTML llegó tarde: recién se volvió ampliamente interoperable en navegadores bien entrada la década de 2010. Lo que aporta Furifont es demostrar la técnica completa, de punta a punta, para construir una tipografía con lectura fonética incrustada usando solo funciones estándar de OpenType que cualquier fuente puede adoptar sin esperar un cambio en ningún navegador.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: descargá la fuente de prueba desde furifont.antfu.me, armá un span con font-feature-settings: "calt" 1; y confirmá en el inspector de fuentes de Firefox que la sustitución contextual se disparó.

Preguntas frecuentes

¿Furifont reemplaza al elemento HTML ruby?

No lo reemplaza en todos los casos: <ruby> sigue siendo la opción correcta cuando necesitás que la lectura exista como texto real, accesible y buscable. Furifont tiene sentido cuando el canal de salida no te deja controlar el markup, como un PDF generado automáticamente o un lector de EPUB que ignora <ruby>. Para contenido nuevo donde controlás el pipeline completo, <ruby> sigue siendo la opción más robusta a largo plazo.

¿Qué pasa si el navegador no soporta las funciones OpenType que usa Furifont?

Si el motor de shaping no aplica calt ni las variantes estilísticas, simplemente muestra el glifo base del kanji, sin la furigana. No rompe el layout ni genera un carácter faltante, pero el lector pierde la anotación.

¿Se puede copiar el texto y conservar la lectura en kana?

No. La sustitución ocurre solo en la capa visual del glifo: el texto Unicode subyacente sigue siendo el kanji original, así que copiar y pegar, buscar en la página o pasarlo por un lector de pantalla no recupera la lectura en kana.

¿Furifont funciona con cualquier tipografía japonesa?

No: la anotación furigana tiene que estar diseñada dentro de esa fuente específica, glifo por glifo. No es una función que se le pueda sumar a cualquier tipografía japonesa existente sin rediseñar sus tablas GSUB y agregar los glifos compuestos correspondientes. Migrar una tipografía existente implica, en la práctica, generar una fuente derivada solo para este propósito.

¿La anotación furigana incrustada sirve para otros idiomas además del japonés?

La técnica sí: cualquier escritura que combine un carácter principal con una anotación fonética secundaria, como el pinyin sobre caracteres chinos o la vocalización sobre consonantes árabes o hebreas, puede usar el mismo mecanismo de sustituciones contextuales y variantes estilísticas de OpenType.

¿Cuánto crece el archivo de la fuente al incrustar furigana en los glifos?

Crece en proporción directa a cuántas combinaciones de kanji y lectura soporte: cada combinación nueva es un glifo compuesto adicional en la tabla de glifos. Por eso ninguna fuente de este tipo intenta cubrir los miles de kanji de uso común con todas sus lecturas posibles.

Referencias

Furifont: sitio oficial del proyecto de Anthony Fu, con la demo de furigana incrustada en la fuente.- Wikipedia: historia y uso de la furigana en la tipografía japonesa.- Microsoft Typography: especificación oficial de OpenType, incluida la tabla GSUB y sus funciones de layout.- MDN: documentación de la propiedad CSS font-feature-settings para activar funciones OpenType.- Wikipedia: antecedentes técnicos del formato de fuentes OpenType.

Pele: la librería que renderiza Mermaid a SVG puro

lu1tr0n — Sat, 17 Oct 2026 20:31:08 +0000

Un sitio de documentación carga hoy 1,6 MB de JavaScript solo para convertir texto en diagramas Mermaid en SVG. Pele logra lo mismo con 230 kB comprimidos y sin ninguna dependencia declarada.

La librería acepta la misma sintaxis que ya usás en Mermaid.js, pero cambia cómo se pintan los colores: en vez de pasar un objeto de tema y volver a ejecutar el renderizador, lee variables CSS directamente del navegador.

TL;DR

Pele renderiza sintaxis Mermaid a SVG en un bundle de 230 kB gzip, frente a 1,6 MB de Mermaid.js.- render() devuelve el SVG en 0,05 a 0,3 ms, contra 6 a 82 ms de Mermaid.js.- Las variables --pele-bg, --pele-fg y --pele-line recolorean el diagrama sin volver a renderizarlo.- Cero dependencias directas reducen la superficie de auditoría frente a las 23 de Mermaid.js.- npm install pele habilita render() en cualquier proyecto de JavaScript o TypeScript.

¿Qué es Pele?

Pele es una librería de JavaScript de código abierto que renderiza diagramas Mermaid en SVG sin depender de un motor de layout externo ni de un framework de UI. Pesa 230 kB comprimidos, no declara dependencias directas y expone sus colores como variables CSS que cualquier hoja de estilos puede sobrescribir.

El proyecto vive en pele.run, donde el sitio oficial funciona también como editor interactivo: se escribe sintaxis Mermaid a la izquierda y el SVG resultante aparece a la derecha, con un panel aparte para probar las variables de color en vivo.

La propuesta de valor no es agregar funciones nuevas sobre Mermaid.js, sino resolver un problema puntual: renderizar los mismos diagramas con menos peso y menos superficie de dependencias.
El bundle de Mermaid.js pesa 1,6 MB comprimido frente a los 230 kB de Pele.

Por qué importan los diagramas Mermaid en SVG en documentación técnica

Cada diagrama en una página de documentación suma al JavaScript que el navegador tiene que descargar, parsear y ejecutar antes de mostrar nada. Con Mermaid.js, esa factura ronda 1,6 MB comprimidos y 23 dependencias directas, aunque la página solo muestre tres cajas y dos flechas.

Ese costo pesa distinto según el proyecto. Un blog técnico con un diagrama por artículo lo nota poco. Una herramienta interna que renderiza decenas de diagramas por sesión (un visor de arquitectura, un editor de runbooks, un generador de documentación a partir de código) sí lo nota, porque cada render repite el costo de parseo y layout.

Pele ataca justamente ese caso. Su bundle gzip pesa 230 kB y su tiempo de render va de 0,05 a 0,3 ms, frente a 6 a 82 ms de Mermaid.js. La diferencia se nota más cuanto más diagramas hay en una misma página, porque cada diagrama paga su propio tiempo de render.

Cómo funciona Pele por dentro

La función central de la librería es render(): recibe un string con sintaxis Mermaid y devuelve un objeto con una propiedad svg, que es el markup SVG completo listo para insertar en el DOM. No hay paso intermedio de configuración ni un objeto de tema que pasar como segundo argumento.

La parte que distingue a Pele está en cómo ese SVG define sus colores. En vez de escribir atributos con valores fijos calculados en el momento del render, los elementos del SVG referencian variables CSS, por ejemplo fill="var(--pele-fg)". El navegador resuelve esa variable al pintar, no la librería al generar el SVG.

Esa diferencia es la que permite cambiar de tema sin volver a renderizar. Si el color estuviera fijo en el atributo, cambiar de claro a oscuro obligaría a llamar render() de nuevo y reemplazar el SVG completo en el DOM; con variables CSS alcanza con cambiar el valor de --pele-bg en una regla CSS.

flowchart LR
 A["Sintaxis Mermaid"] --> B["Parser interno"]
 B --> C["Calculo de layout"]
 C --> D["SVG con var(--pele-fg)"]
 D --> E(["Navegador"])

El mismo mecanismo explica por qué la demo oficial permite cambiar colores sin que el diagrama se vuelva a dibujar: el paso "SVG con var(--pele-fg)" del diagrama de arriba ya ocurrió una sola vez, y de ahí en adelante el navegador se encarga del repintado.

Ejemplos prácticos con código progresivo

El primer ejemplo es el equivalente a un hola mundo: tomar un diagrama de flujo simple y mostrarlo en pantalla.

import { render } from 'pele';

const { svg } = render(`flowchart LR
  A[Build] --> B[Test]
  B --> C[Deploy]`);

document.querySelector('#diagrama').innerHTML = svg;
console.log(svg.startsWith(' {
  contenedor.classList.toggle('oscuro');
});

sequenceDiagram
    participant U as Usuario
    participant J as JS de la pagina
    participant C as CSS
    participant S as SVG renderizado
    U->>J: clic en boton modo oscuro
    J->>C: alterna la clase oscuro
    C->>S: el navegador repinta var(--pele-bg)
    Note over S: no se llama render de nuevo

Para confirmar que el theming está realmente activo hay que inspeccionar el elemento en las devtools del navegador: si el atributo fill de un nodo muestra var(--pele-fg) en lugar de un valor hexadecimal fijo, la variable está conectada. Si en cambio aparece un color fijo, algo en el build (un minificador de CSS agresivo, por ejemplo) resolvió la variable antes de tiempo.
Mermaid.js declara 23 dependencias directas; Pele no declara ninguna.

Cómo empezar: instalación y primer render

Lo único que necesitás antes de instalar Pele es tener Node.js y un gestor de paquetes en la máquina; el comando es idéntico en Windows, macOS y Linux.

npm install pele

Si tu proyecto usa otro gestor, el paquete se instala igual con pnpm add pele, yarn add pele o bun add pele.

Con el paquete instalado, el primer render completo en una página HTML queda así:

import { render } from 'pele';

const diagrama = `flowchart TD
  A[Peticion HTTP] --> B{Cache valido?}
  B -- Si --> C[Responder desde cache]
  B -- No --> D[Consultar origen]
  D --> E[Guardar en cache]
  E --> C`;

const { svg } = render(diagrama);
document.querySelector('#diagrama').innerHTML = svg;

No hay paso de inicialización ni un objeto de configuración que crear antes de llamar a render(). Eso es consistente con la cifra de cero dependencias directas: no hay un motor de plugins que configurar primero.

💡 Tip: combinar las variables CSS de Pele con prefers-color-scheme evita escribir JavaScript para el modo oscuro: una media query que redefina --pele-bg y --pele-fg alcanza para que el diagrama respete la preferencia del sistema operativo sin un listener de clic.

Casos de uso reales

El caso más directo es cualquier sitio estático que ya escribe diagramas en sintaxis Mermaid dentro de Markdown: generadores de documentación, wikis internas, blogs técnicos. En vez de cargar el bundle completo de Mermaid.js en cada página, un paso de build puede recorrer los bloques de código marcados como Mermaid y llamar a render() una sola vez por diagrama, dejando el SVG ya resuelto en el HTML final.

Otro caso es el de herramientas internas que generan diagramas dinámicamente a partir de datos: un visor de dependencias entre microservicios, un editor de runbooks de incidentes, un panel que dibuja el estado de una pipeline de CI en tiempo real. Ahí el tiempo de render por diagrama se nota en la latencia percibida de la interfaz.

Un tercer caso es el de editores o extensiones que muestran una vista previa del diagrama mientras el usuario escribe: ahí el costo de re-renderizar en cada tecla es lo primero que se siente si la librería es pesada.

Errores comunes y buenas prácticas

El error más común es olvidar la clase pele (o el equivalente que definas) en un ancestro del SVG. Las variables CSS de Pele no son globales por defecto: si las declarás en una clase que nunca envuelve al contenedor del diagrama, el SVG usa sus valores por defecto y el cambio de color simplemente no aparece.

El segundo error es confundir qué cambios necesitan volver a llamar render() y cuáles no. Cambiar un color definido como variable CSS no lo necesita, el navegador repinta solo. Pero cambiar el contenido del diagrama sí requiere ejecutar render() de nuevo con el string actualizado: las variables CSS resuelven el theming, no la estructura.

⚠️ Ojo: si el texto que le pasás a render() viene de un usuario final y no de tu propio código, tratalo como entrada no confiable antes de insertar el resultado con innerHTML. Un SVG puede incluir elementos como <script> o manejadores de evento embebidos; sanitizar el SVG resultante (por ejemplo con DOMPurify configurado para SVG) es una precaución razonable en cualquier flujo donde el diagrama no lo escribiste vos.

Por último, antes de asumir que Pele corre igual en un script de build de Node que en el navegador, probalo en ese entorno concreto: la demo de pele.run muestra el uso en el navegador, y confirmar que render() no depende de ninguna API específica del DOM es algo que conviene verificar en tu propio proyecto antes de depender de ello en producción.

Comparativa: Pele vs Mermaid.js

La tabla resume las cifras que pele.run publica comparando ambas librerías sobre el mismo tipo de diagrama.
MétricaPeleMermaid.jsBundle (gzip)230 kB1,6 MBTiempo de renderizado0,05 a 0,3 ms6 a 82 msDependencias directas023ThemingVariables CSS, sin re-renderObjeto de configuración de temaPantallas pequeñasAdapta el layoutEscala el diagrama completo
La fila de pantallas pequeñas importa más de lo que parece: adaptar el layout significa reorganizar nodos para que entren en el ancho disponible, mientras que escalar el diagrama completo achica también el texto, que puede quedar ilegible en una pantalla de teléfono.

Profundizando: theming, accesibilidad y límites de Pele

El modelo de variables CSS tiene una ventaja de accesibilidad que no es obvia a primera vista: como el texto del diagrama sigue siendo texto SVG real, no una imagen rasterizada, un lector de pantalla puede leerlo y un usuario puede seleccionarlo y copiarlo. Esto no es exclusivo de Pele, Mermaid.js también emite SVG con texto real, pero es una propiedad que se pierde si en algún punto del pipeline el SVG se convierte a PNG para incrustarlo en un PDF.

La elección entre adaptar el layout o escalar el diagrama completo en pantallas chicas es una decisión de diseño con compromisos en ambas direcciones: reorganizar nodos mantiene el texto legible pero puede alargar mucho el diagrama en vertical, mientras que escalar todo preserva las proporciones originales pero sacrifica legibilidad. Una jerarquía angosta se adapta mejor a reorganizarse; un diagrama ancho con muchos nodos en el mismo nivel sufre más con cualquiera de las dos estrategias.

flowchart TD
 A["Necesitas diagramas Mermaid"] --> B{"Bundle size y dependencias importan?"}
 B -- "Si" --> C["Pele"]
 B -- "No, ya usas Mermaid.js" --> D["Mermaid.js"]
 C --> E(["SVG final"])
 D --> E

Esa decisión también depende de cuánta cobertura de sintaxis necesitás. Mermaid.js acumuló años de tipos de diagrama (Gantt, estados, clases, entidad-relación, mapas mentales, entre otros) y una comunidad grande alrededor de esa sintaxis extendida. Antes de migrar un proyecto completo de Mermaid.js a Pele conviene revisar, diagrama por diagrama, si el tipo que usás está soportado en la documentación de pele.run, no asumirlo porque ambas acepten sintaxis Mermaid.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: abrí el editor interactivo de pele.run, cambiá el valor de --pele-bg desde las devtools del navegador y confirmá en la pestaña Elements que el <svg> sigue mostrando var(--pele-bg) en vez de un color fijo.

Preguntas frecuentes

¿Pele reemplaza completamente a Mermaid.js?

No necesariamente. Pele cubre el caso de renderizar sintaxis Mermaid a SVG con menos peso y un theming más simple, pero Mermaid.js tiene más tipos de diagrama acumulados a lo largo de los años. Conviene revisar si los tipos que usás están soportados antes de migrar un proyecto entero.

¿Los diagramas Mermaid en SVG generados por Pele funcionan sin conexión a internet?

Sí, una vez instalado el paquete, render() corre localmente: no hace ninguna petición de red para convertir la sintaxis en SVG. El resultado tampoco depende de recursos externos para mostrarse, salvo que vos mismo agregues imágenes o fuentes externas dentro del diagrama.

¿Pele soporta todos los tipos de diagrama de Mermaid.js?

El sitio oficial muestra flowcharts en su demo principal; para confirmar la cobertura de otros tipos (secuencia, clases, Gantt, estados) hay que revisar la documentación del proyecto en pele.run en lugar de asumir paridad total con Mermaid.js.

¿Puedo usar Pele con React, Vue o Svelte?

Sí, porque render() devuelve un string de SVG, no un componente atado a un framework. En React se puede insertar con dangerouslySetInnerHTML, en Vue con v-html y en Svelte con {@html}, siempre con las mismas precauciones de sanitización si el contenido viene de un usuario.

¿Qué pasa si el SVG generado por Pele no se ve bien en pantallas chicas?

Pele adapta el layout en pantallas pequeñas en lugar de escalar el diagrama completo, lo que mantiene el texto legible a costa de reorganizar los nodos. Si un diagrama específico sigue viéndose mal, revisar si tiene muchos nodos en el mismo nivel ayuda a diagnosticar el problema.

¿Pele funciona en Node.js sin navegador?

No hay confirmación directa de esto en la documentación pública del proyecto. Antes de depender de un uso en build time o en el servidor conviene probarlo en ese entorno concreto, en vez de asumir que la ausencia de dependencias implica ausencia de APIs del navegador.

Referencias

Pele: sitio oficial del proyecto, con editor interactivo, API de instalación y la comparativa de rendimiento contra Mermaid.js.- Mermaid.js: documentación oficial de la librería que define la sintaxis que ambos proyectos comparten.- MDN: uso de propiedades personalizadas de CSS: referencia sobre cómo funcionan las variables CSS que usa Pele para el theming.

Un ensayo en Nature cuestiona el uso de 'superinteligencia'

lu1tr0n — Sat, 17 Oct 2026 16:27:37 +0000

Nature publicó en octubre de 2026 un ensayo que hace una pregunta incómoda para toda la industria de la inteligencia artificial: si la superinteligencia artificial sigue siendo un término con base científica o ya es solo una etiqueta de marketing. La revista lo plantea justo cuando varios laboratorios afirman en público estar cerca de superar la inteligencia humana en tareas generales.

El ensayo, titulado The science of superintelligence and why AI is still a useful word, no niega que la IA avance. Cuestiona si existe una definición medible de 'superinteligencia' que sirva para algo más que un titular.

TL;DR

Nature publicó en octubre de 2026 un ensayo que cuestiona si la superinteligencia tiene base científica sólida.- DeepMind propuso en 2023 seis niveles de capacidad de IA, de 'sin IA' a 'sobrehumana', en el paper Levels of AGI.- Anthropic ata su Responsible Scaling Policy a niveles ASL medibles, no a la palabra 'superinteligencia'.- La Ley de IA de la UE fija el umbral de riesgo sistémico en 10^25 FLOPs de entrenamiento, no en una etiqueta.- El ensayo no niega el avance de la IA: defiende que 'inteligencia artificial' sigue siendo un término útil.

Qué es la superinteligencia artificial

Superinteligencia artificial es la capacidad hipotética de un sistema de IA para superar a los humanos en prácticamente cualquier tarea cognitiva relevante, incluyendo las que exigen juicio, creatividad y planificación a largo plazo, y no solo en pruebas aisladas de memoria o cálculo.

El término se popularizó dentro de la filosofía de la IA mucho antes de que existieran los modelos de lenguaje actuales, pero carece de una métrica estándar aceptada por toda la comunidad científica. Por eso Nature usa la pregunta como punto de partida: hace falta distinguir entre la ambición declarada por las empresas y lo que de verdad se puede medir en un laboratorio.

Qué pasó

El ensayo repasa cómo el lenguaje de la industria se movió, en apenas unos años, de hablar de modelos de lenguaje a hablar de inteligencia artificial general y superinteligencia casi como sinónimos. El autor sostiene que esa deriva no vino de un avance medible, sino de la ausencia de un criterio compartido: cada laboratorio define la etiqueta a su manera, y esa definición cambia según convenga para una ronda de financiamiento, un anuncio de producto o un debate regulatorio.

El texto no pide abandonar el vocabulario de la IA. Al contrario, defiende que 'inteligencia artificial' como término sigue siendo útil para la ciencia, aunque sea impreciso, porque agrupa un conjunto real de técnicas (aprendizaje profundo, aprendizaje por refuerzo, modelos de lenguaje) que sí se pueden estudiar y comparar. El problema aparece, según el ensayo, cuando se salta directo a 'superinteligencia' sin pasar por una escala intermedia que alguien pueda verificar.

La publicación llega además en un momento en que medios generalistas, no solo especializados, repiten la palabra en titulares sin matizarla. Para una revista científica, esa repetición sin respaldo empírico es justo el tipo de problema que un comité editorial no puede ignorar: cuando un término se vuelve sinónimo de progreso sin que nadie pueda medirlo, deja de servir como categoría científica y pasa a ser una consigna.

Contexto e historia

La idea de medir la IA por niveles, no por una etiqueta binaria, no es nueva. En 2023, investigadores de Google DeepMind publicaron Levels of AGI for Operationalizing Progress on the Path to AGI, un paper que propuso seis niveles de capacidad, de Nivel 0 (sin IA) a Nivel 5 (sobrehumana), cruzados con una segunda escala de generalidad, de tareas estrechas a tareas completamente generales. La propuesta buscaba exactamente lo que Nature reclama ahora: una vara común para medir progreso sin depender de un anuncio de prensa.

Ese marco convive con posturas opuestas dentro de la propia industria. OpenAI nació con la misión declarada de construir una AGI segura y beneficiosa, pero nunca fijó un umbral técnico público para decidir cuándo se alcanza ese punto. Anthropic tomó el camino contrario: en su ensayo Machines of Loving Grace, su director ejecutivo Dario Amodei evita deliberadamente las palabras AGI y superinteligencia, y propone hablar en cambio de 'IA potente', definida por lo que el sistema puede hacer en tareas concretas, no por una comparación vaga con la inteligencia humana en general.

La propia etiqueta 'inteligencia artificial' nació en 1955, cuando John McCarthy decidió organizar el taller de Dartmouth y eligió ese nombre para el nuevo campo, y desde entonces atravesó más de un 'invierno de la IA' en el que buena parte de la comunidad científica dejó de usar el término por el desprestigio que había acumulado. La discusión actual sobre la superinteligencia repite, a otra escala, ese mismo patrón: una palabra que promete demasiado termina por perder credibilidad incluso cuando la tecnología detrás sigue avanzando.
La escala de DeepMind de 2023 define seis niveles de capacidad, de 'sin IA' a 'sobrehumana'.

Detalles técnicos

La disputa sobre el término no es solo semántica: en al menos un caso, una definición de capacidad dispara compromisos de seguridad que una empresa está obligada a cumplir. La Responsible Scaling Policy de Anthropic ata cada nivel de seguridad (ASL, por AI Safety Level) a evaluaciones concretas de capacidades peligrosas: cuánto ayuda un modelo a diseñar un arma biológica, a replicarse de forma autónoma en infraestructura ajena o a ejecutar un ciberataque complejo sin supervisión humana. Si un modelo supera el umbral de una evaluación, la política obliga a reforzar la seguridad del despliegue antes de publicarlo, sin importar cómo se llame esa capacidad hacia afuera.

flowchart LR
A["Nivel 0: Sin IA"] --> B["Nivel 1: Emergente"]
B --> C["Nivel 2: Competente"]
C --> D["Nivel 3: Experta"]
D --> E["Nivel 4: Virtuosa"]
E --> F["Nivel 5: Sobrehumana"]

NivelQué habilitaCapacidad evaluadaCompromiso de seguridadASL-2Modelos de uso general ya desplegadosRiesgo bajo de asistencia en armas o ciberataquesPruebas estándar de seguridad y filtrado de contenidoASL-3Modelos con capacidad real de asistencia peligrosaAsistencia significativa en bioseguridad o ciberofensivaControles de acceso reforzados y auditoría externaASL-4Modelos hipotéticos de mayor autonomíaRiesgo de pérdida de control o replicación autónomaContención técnica adicional, aún no activada en 2026
La escala de DeepMind no mide solo profundidad de la capacidad: también mide generalidad. Un modelo puede ser virtuoso jugando ajedrez (nivel alto) pero estrecho en generalidad, mientras que un asistente conversacional moderno es más general pero rara vez pasa del nivel competente en tareas específicas exigentes. Esa doble vara explica por qué dos laboratorios pueden mirar el mismo modelo y llegar a conclusiones opuestas sobre si ya es superinteligente.

No hay una API ni un comando que devuelva automáticamente en qué nivel está un modelo. Ubicarlo en la escala de DeepMind es una evaluación cualitativa: cada equipo de investigación compara los resultados de sus propios benchmarks contra la descripción de las seis categorías del paper, y dos equipos pueden discrepar en el resultado. Eso es, precisamente, lo que Nature señala como punto débil.

Ni la escala de DeepMind ni la política de Anthropic resuelven el problema de fondo: ambas dependen de evaluaciones internas, hechas por la misma empresa que después decide si lanza el modelo. Nature no pide externalizar esas pruebas, pero el ensayo sí nota que ninguna de las dos escalas tiene hoy una auditoría independiente obligatoria.

Impacto y análisis

La falta de una definición común tiene consecuencias prácticas más allá del laboratorio. Gobiernos que destinan fondos públicos a IA necesitan un criterio para decidir qué proyectos califican como investigación de frontera y cuáles son solo aplicaciones convencionales etiquetadas como superinteligencia artificial para atraer presupuesto.

Para los inversores, el problema es distinto pero relacionado: una ronda de financiamiento valorada en varios miles de millones de dólares puede apoyarse en la promesa de llegar a la AGI sin que exista una forma independiente de verificar cuánto falta para eso. El ensayo de Nature no acusa a ninguna empresa de mentir; argumenta que, sin una métrica común, ni siquiera la propia empresa puede saber con certeza en qué punto de la escala está.

La Ley de IA de la Unión Europea evita el problema de lleno: en lugar de depender de una palabra, fija un umbral técnico medible, el entrenamiento con más de 10^25 FLOPs, para clasificar un modelo como de riesgo sistémico y exigirle evaluaciones adicionales. Es la misma lógica que defiende el ensayo de Nature: una cifra que cualquiera puede verificar pesa más que una etiqueta que cambia de significado según quién la use.

💭 Clave: ninguna política de seguridad de la industria usa hoy la palabra 'superinteligencia' como umbral oficial; todas, incluida la de Anthropic, dependen de pruebas de capacidades concretas y verificables.
La Ley de IA de la UE usa 10^25 FLOPs de entrenamiento como umbral de riesgo sistémico.

Qué sigue

Nature no es la única publicación científica presionando en esta dirección. En los próximos meses se esperan revisiones de los marcos de capacidades de OpenAI, Google DeepMind y Anthropic, que suelen actualizarse cuando aparece una nueva generación de modelos. Si la presión editorial se mantiene, es probable que los laboratorios empiecen a hablar menos de superinteligencia en sus anuncios y más de niveles concretos de capacidad, aunque sea solo para evitar que un ensayo como este los cite como ejemplo de lenguaje inflado.

Lo que no va a pasar pronto es un acuerdo formal entre empresas sobre una sola escala. Cada laboratorio tiene incentivos distintos para definir el progreso a su manera, y ninguna autoridad científica tiene poder para imponer una terminología común.

📖 Resumen en Telegram: Ver resumen

Si te interesa el detalle técnico, leé el paper original Levels of AGI de DeepMind: son pocas páginas y la tabla de niveles se entiende sin necesitar formación en IA.

Preguntas frecuentes

¿Qué dice exactamente el ensayo de Nature sobre la superinteligencia artificial?

Argumenta que el término carece de una métrica científica aceptada, aunque defiende que 'inteligencia artificial' como categoría general sigue siendo útil para la investigación.

¿Quién definió los niveles de AGI que usa este artículo como referencia?

Investigadores de Google DeepMind los propusieron en 2023 en el paper 'Levels of AGI for Operationalizing Progress on the Path to AGI'.

¿Qué es la Responsible Scaling Policy de Anthropic?

Es el marco interno que ata cada nivel de riesgo (ASL) a evaluaciones concretas de capacidades peligrosas, como asistencia en bioseguridad o ciberataques autónomos, en lugar de a una etiqueta como superinteligencia.

¿La IA actual ya alcanzó la inteligencia artificial general?

No hay consenso científico al respecto. Distintos laboratorios usan criterios distintos, que es precisamente el problema que señala el ensayo de Nature.

¿Por qué importa este debate sobre la inteligencia artificial general para alguien que no trabaja en IA?

Porque esa definición influye en decisiones de financiamiento público, en qué exige la regulación y en qué tan creíbles son los anuncios comerciales de las empresas de IA.

Referencias

Nature: ensayo 'The science of superintelligence and why AI is still a useful word'.- arXiv: 'Levels of AGI for Operationalizing Progress on the Path to AGI' (Google DeepMind, 2023).- Anthropic: anuncio oficial de la Responsible Scaling Policy.- Dario Amodei: ensayo 'Machines of Loving Grace' sobre IA potente frente a AGI y superinteligencia.- Wikipedia: contexto general sobre inteligencia artificial general.

Memoria asociativa: el estudio de 2020 que conecta a Hopfield con la atención

lu1tr0n — Sat, 17 Oct 2026 08:41:32 +0000

En 1982, el físico John Hopfield publicó un modelo de red neuronal que, cuatro décadas después, resultó ser la base conceptual del mecanismo de atención que sostiene a GPT, Claude y Gemini. La idea central es la memoria asociativa: una red que guarda patrones completos y los recupera a partir de una versión incompleta o ruidosa, sin usar direcciones exactas como la memoria de una computadora.

El investigador Alex Wang reconstruyó ese vínculo en un ensayo reciente: mostró, paso a paso, cómo partir solo de la idea de guardar y recuperar patrones alcanza para derivar la fórmula de atención sin memorizarla de un paper.

TL;DR

Una red de Hopfield recupera un patrón completo a partir de una versión incompleta o ruidosa de ese patrón.- La energía de la red baja en cada actualización hasta estabilizarse en el patrón memorizado más parecido.- El mecanismo de atención de un transformer calcula la misma recuperación por similitud entre vectores.- Las matrices Query, Key y Value convierten esa búsqueda asociativa en multiplicaciones paralelas en GPU.- Treinta y cinco años después, el paper de atención de 2017 formaliza esa equivalencia matemática.

¿Qué es la memoria asociativa?

La memoria asociativa es un modelo de almacenamiento donde un patrón completo se recupera a partir de una parte de sí mismo o de una versión con ruido, sin usar una dirección exacta como en la memoria de una computadora tradicional; las redes de Hopfield son su implementación clásica.

En una memoria RAM, pedís el dato ubicado en la dirección 0x4F2A y la máquina te lo entrega sin importar qué tan parecido sea a lo que buscabas. La memoria direccionable por contenido invierte ese orden: entrás con un fragmento del dato, un patrón corrupto o incompleto, y el sistema te devuelve el patrón almacenado más parecido. Es la misma lógica que usa tu cerebro cuando reconocés una canción a partir de tres notas.

Por qué importa entender este modelo

La red de Hopfield nació en biofísica, no en ingeniería de software: Hopfield buscaba explicar cómo el cerebro recupera recuerdos completos a partir de pistas parciales. Durante años quedó como una curiosidad de los cursos de redes neuronales, superada en la práctica por arquitecturas más flexibles.

El giro llegó cuando varios investigadores notaron que la regla de actualización de una red de Hopfield continua se parece, término a término, a la fórmula de atención que popularizó el paper Attention Is All You Need en 2017. Entender la recuperación asociativa deja de ser arqueología académica: explica por qué la atención a veces converge a un token equivocado, lo mismo que una red de Hopfield puede estabilizarse en un mínimo de energía incorrecto, y por qué ampliar el contexto cambia la capacidad efectiva de memoria del modelo.

Para quien ajusta prompts o diseña agentes, esta lectura explica un fenómeno conocido: un dato repetido varias veces en el contexto se recupera con más fuerza que uno mencionado una sola vez. En términos de energía, un patrón reforzado varias veces crea un pozo más profundo y más fácil de encontrar para la red.
Hopfield formuló su modelo en 1982, antes de que existieran las GPU modernas.

Cómo funciona una red de Hopfield

Una red de Hopfield clásica tiene N neuronas binarias, cada una con valor +1 o -1. Para memorizar un patrón, la red no lo guarda en una celda: lo codifica en una matriz de pesos W usando la regla de Hebb, donde cada peso W_ij se calcula como el producto de los valores i y j del patrón, con la diagonal en cero para que ninguna neurona se refuerce a sí misma.

La regla de Hebb funciona porque el producto p_i × p_j es positivo cuando dos neuronas coinciden en el patrón memorizado y negativo cuando difieren. Al sumar esos productos en la matriz W, cada par de neuronas aprende a reforzarse o inhibirse según qué tan seguido coincidieron en los patrones guardados: es la versión matemática de la plasticidad hebbiana que se resume desde los años cincuenta como "las neuronas que se disparan juntas, se conectan juntas".

Para recuperar un patrón a partir de una entrada corrupta, la red actualiza cada neurona una por una: cada neurona suma las señales que recibe de las demás, ponderadas por los pesos, y toma el signo de esa suma como su nuevo valor. Repetir esta actualización empuja al sistema hacia abajo en una función de energía E = -0.5 × xᵗWx. Como los pesos son simétricos, cada actualización asíncrona garantiza que la energía nunca sube, así que el sistema converge a un mínimo estable: el patrón memorizado más cercano a la entrada.

Hay dos formas de aplicar la actualización: asíncrona (una neurona a la vez, en orden aleatorio) o sincrónica (todas a la vez). La garantía de que la energía nunca sube solo vale para la actualización asíncrona con pesos simétricos; actualizar todas las neuronas al mismo tiempo puede hacer que el sistema oscile entre dos estados sin converger nunca, un detalle que casi siempre se omite en las explicaciones simplificadas del modelo.

Ese mínimo estable es, por definición, el recuerdo recuperado. La memoria asociativa funciona porque la red no busca una dirección: cae en un pozo de energía que coincide con el patrón original.

flowchart TD
    A["Patron de entrada con ruido"] --> B["Calcular energia de la red"]
    B --> C["Actualizar una neurona segun el signo de su entrada"]
    C --> D{"Bajo la energia?"}
    D -- "Si" --> C
    D -- "No, se estabilizo" --> E["Patron memorizado recuperado"]

La capacidad de una red de Hopfield clásica es limitada: la teoría clásica de Amit, Gutfreund y Sompolinsky de 1985 ubica el límite práctico alrededor del 14% del número de neuronas antes de que los patrones memorizados empiecen a mezclarse entre sí, lo que se conoce como crosstalk. Con 100 neuronas, eso son apenas 14 patrones distintos antes de que la recuperación empiece a fallar.

Ejemplos prácticos: recuperación asociativa en cuatro líneas de Python

El ejemplo más simple cabe en una red de 4 neuronas. Guardamos el patrón [1, -1, 1, -1] y luego le mostramos una versión con un bit invertido, para ver si la red lo corrige:

import numpy as np

pattern = np.array([1, -1, 1, -1])
W = np.outer(pattern, pattern)
np.fill_diagonal(W, 0)

corrupted = np.array([1, -1, -1, -1])  # un bit invertido respecto al original
recovered = np.sign(W @ corrupted)
print(recovered)

La salida es exactamente el patrón original, aunque la entrada tenía un bit distinto:

[ 1 -1  1 -1]

La neurona corrupta, la tercera, que entró en -1 en vez de 1, recibe una señal neta de +3 desde las otras tres neuronas, así que su signo se corrige en una sola actualización. Con patrones más largos la corrección necesita varias rondas, pero el mecanismo es idéntico.

El segundo ejemplo guarda dos patrones a la vez, [1, -1, 1, -1] y [1, 1, -1, -1], que son ortogonales entre sí:

patterns = [np.array([1, -1, 1, -1]), np.array([1, 1, -1, -1])]
W = sum(np.outer(p, p) for p in patterns)
np.fill_diagonal(W, 0)

corrupted = np.array([1, -1, -1, -1])
recovered = np.sign(W @ corrupted)
print(recovered)

La red sigue recuperando [ 1 -1 1 -1] aunque ahora guarda dos patrones, porque al ser ortogonales no interfieren entre sí. Si agregás un tercer patrón correlacionado con alguno de los dos, el riesgo de crosstalk aparece mucho antes del límite del 14% mencionado arriba.

Cómo empezar a experimentar con memoria asociativa

Para correr los ejemplos anteriores en tu máquina solo necesitás Python 3 y NumPy. En Linux y macOS:

python3 -m pip install numpy
python3 hopfield_demo.py

En Windows, el mismo comando usando python en vez de python3 desde PowerShell o CMD.

Guardá el código de los dos ejemplos en un archivo hopfield_demo.py y ejecutalo: no hay API keys, ni dependencias externas, ni GPU necesaria para esta escala de red.

Casos de uso reales de la memoria asociativa

Corrección de errores didáctica: los cursos de redes neuronales usan redes de Hopfield para mostrar cómo un sistema distribuido corrige ruido sin un algoritmo de corrección explícito, por ejemplo recuperando una imagen binaria completa a partir de la mitad de sus píxeles.- Modelos basados en energía: las máquinas de Boltzmann y los modelos de difusión comparten la misma lógica de minimizar una función de energía hasta estabilizarse en un patrón válido, generando un dato nuevo al dejar que el sistema caiga hacia un mínimo de esa superficie.- Capas de atención alternativas: el paper Hopfield Networks is All You Need (2020) propone capas de Hopfield continuo como reemplazo directo de las capas de atención en un transformer, con capacidad de almacenamiento exponencial en vez de lineal.- Interpretabilidad de modelos de lenguaje: pensar la atención como recuperación asociativa permite tratar un fallo de memoria del modelo como una convergencia a un mínimo de energía equivocado, en vez de un misterio de caja negra sin explicación. El paper "Hopfield Networks is All You Need" se publicó en 2020, treinta y ocho años después del modelo original. ## Errores comunes y buenas prácticas

El error más frecuente es sobrecargar la red: guardar más patrones de los que su capacidad permite produce recuperaciones mezcladas, donde la red converge a un patrón espurio que no es ninguno de los memorizados. La solución clásica es reducir la cantidad de patrones o usar patrones poco correlacionados entre sí, como en el ejemplo ortogonal de arriba.

Otro error es romper la simetría de la matriz de pesos W. La garantía de convergencia depende de que W sea simétrica (W_ij = W_ji); si entrenás la red con una regla distinta a Hebb sin verificar la simetría, perdés la garantía matemática de que la energía solo baja, y el sistema puede oscilar sin estabilizarse nunca.

Por último, es común confundir la red de Hopfield clásica, binaria y con actualización iterativa, con su versión moderna continua, que recupera un patrón en un solo paso usando softmax. Son parientes matemáticos, pero tienen propiedades de capacidad y convergencia distintas; tratarlas como intercambiables lleva a conclusiones equivocadas sobre qué tan parecida es la atención real a la red original de 1982.

Comparativa: Hopfield clásica, moderna y atención de los transformers

La tabla resume las tres versiones del mismo principio, de la más antigua a la más usada en producción hoy:
ModeloRegla de actualizaciónCapacidadRelación con la atenciónHopfield clásica (1982)Signo de la suma ponderada, iterativa~0,14 × N patronesAncestro conceptual, actualización discretaHopfield moderna continua (2020)Softmax sobre similitudes, un solo pasoExponencial en NMatemáticamente equivalente a una capa de atenciónAtención de un transformerSoftmax(QKᵗ/√d)·VLimitada por la ventana de contextoCaso particular de recuperación asociativa continua

Profundizando: de la energía discreta al softmax continuo

La versión moderna de la red de Hopfield, descrita en Hopfield Networks is All You Need, cambia las neuronas binarias por vectores continuos y reemplaza la regla de actualización por una función de energía basada en log-sum-exp. El resultado de minimizar esa energía en un solo paso es, término a término, la fórmula de atención: softmax de la similitud entre una consulta y un conjunto de llaves, multiplicada por los valores asociados.

En el lenguaje de un transformer, la consulta (Query) es el patrón corrupto o parcial que entra a la red; las llaves (Key) son los patrones memorizados contra los que se compara por similitud; y los valores (Value) son lo que efectivamente se recupera cuando una llave coincide. La diferencia frente a Hopfield clásica es que la recuperación no itera: el softmax calcula de una sola vez una combinación ponderada de todos los valores, pesada por qué tan parecida es cada llave a la consulta.

sequenceDiagram
    participant Q as Consulta (Query)
    participant K as Llaves memorizadas (Key)
    participant V as Valores asociados (Value)
    Q->>K: compara similitud con cada llave
    K-->>Q: devuelve un peso de similitud por llave
    Q->>V: combina los valores segun esos pesos
    V-->>Q: patron recuperado por asociacion

flowchart LR
    A["Embeddings de entrada"] --> B["Matriz Query"]
    A --> C["Matriz Key"]
    A --> D["Matriz Value"]
    B --> E["Similitud Query-Key"]
    C --> E
    E --> F["Softmax sobre las similitudes"]
    F --> G["Suma ponderada de Values"]
    D --> G
    G --> H["Salida de la capa de atencion"]

La versión continua agrega un parámetro adicional, llamado beta (equivalente al factor 1/√d de la fórmula de atención), que controla qué tan dura es la recuperación. Con beta bajo, la red devuelve un promedio difuso de todos los patrones parecidos a la consulta, como una memoria borrosa; con beta alto, converge a un único patrón memorizado, igual que la red clásica de 1982. Los transformers modernos operan en un punto intermedio: ni promedian todo el contexto por igual ni recuperan un solo token, sino una combinación pesada donde pocos tokens dominan la salida.

Esta lectura no dice que los ingenieros que diseñaron el paper de atención de 2017 partieron de Hopfield; muestra que dos caminos de investigación distintos convergen en la misma fórmula. Lo que sí permite es derivar la atención desde una intuición física, recuperar un recuerdo completo, en vez de memorizarla como una fórmula de álgebra lineal sin motivo aparente.

💭 Clave: la capacidad exponencial de la Hopfield moderna es la razón matemática de que ampliar el contexto de un modelo de lenguaje no multiplique linealmente su capacidad de "recordar": la relación es mucho más favorable que en la red clásica de 1982.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: abrí una terminal, pegá el código de los dos ejemplos en hopfield_demo.py y probá qué pasa si agregás un tercer patrón correlacionado con los otros dos, hasta que la recuperación empiece a fallar.

Preguntas frecuentes

¿Qué diferencia hay entre la memoria asociativa y la memoria RAM de una computadora?

La RAM recupera un dato por su dirección exacta, sin importar su contenido. La memoria direccionable por contenido, en cambio, recupera un patrón completo a partir de una parte de él o de una versión con ruido, comparando similitud en vez de direcciones.

¿Las redes de Hopfield siguen usándose hoy?

La versión clásica de 1982 se usa casi exclusivamente con fines didácticos, por su baja capacidad de almacenamiento. Su versión continua moderna, en cambio, es la base teórica de propuestas activas de investigación para rediseñar capas de atención.

¿Por qué se dice que la atención de los transformers es una forma de memoria asociativa?

Porque la fórmula de atención, softmax de la similitud entre consulta y llaves multiplicada por valores, es matemáticamente equivalente a un paso de actualización de una red de Hopfield continua. Ambas resuelven el mismo problema: recuperar el patrón almacenado más parecido a una consulta parcial.

¿Cuántos patrones puede guardar una red de Hopfield?

La red clásica binaria guarda, de forma confiable, alrededor del 14% del número de sus neuronas antes de que los patrones empiecen a mezclarse. La versión continua moderna eleva esa cifra a un crecimiento exponencial respecto al número de neuronas.

¿Qué es una red de Hopfield moderna o continua?

Es la versión descrita en 2020 que reemplaza las neuronas binarias por vectores continuos y la regla de actualización iterativa por un softmax de un solo paso, logrando mayor capacidad y una conexión matemática directa con el mecanismo de atención.

¿Necesito entender cálculo para seguir este modelo?

No para la intuición: alcanza con álgebra de vectores y la idea de que un sistema cae hacia un mínimo de energía, como una pelota que rueda por una superficie hasta el punto más bajo. El cálculo aparece recién cuando se quiere derivar formalmente la versión continua de 2020.

Referencias

Alex Wang, "You could have invented transformers from memory": el ensayo que deriva la fórmula de atención desde la memoria asociativa.- Wikipedia: Hopfield network: historia y formulación matemática del modelo original de 1982.- Ramsauer et al., "Hopfield Networks is All You Need" (2020): la versión continua y su equivalencia con la atención.- Vaswani et al., "Attention Is All You Need" (2017): el paper original que introdujo el mecanismo de atención de los transformers.

ECDSA: la sospecha de 26 años era un timestamp, no la NSA

lu1tr0n — Sat, 17 Oct 2026 02:31:38 +0000

Un misterio criptográfico de 26 años quedó resuelto en menos de 30 minutos: las semillas de curvas NIST que usa ECDSA no salieron de un hash secreto de la NSA, sino de un generador de números aleatorios de los años 90 sembrado con la hora del sistema. Así lo reveló Anthropic el 16 de octubre de 2026, después de pedirle a un modelo de investigación interno de Claude que rastreara el origen de esos parámetros.

El resultado no es una falla ni un parche urgente. Es la confirmación, casi tres décadas después, de que esos parámetros se generaron sin manipulación oculta.

TL;DR

Claude resolvió en menos de 30 minutos el misterio de 26 años sobre las semillas de ECDSA.- Las semillas de P-192, P-224, P-256, P-384 y P-521 vienen de lrand48(), no de un hash secreto.- El cálculo de la semilla de P-256 necesitó 1.842 iteraciones de un generador sembrado con un timestamp Unix.- Anthropic descarta puertas traseras: el método usado ahora es reproducible por cualquiera.- Jerry Solinas, ingeniero de la NSA fallecido en 2023, dejó en 2015 una pista que resultó errónea.

Qué es ECDSA

ECDSA es el algoritmo de firma digital basado en curvas elípticas que adoptó el NIST en el año 2000 dentro del estándar FIPS 186-2, y que depende de un conjunto de curvas estandarizadas cuyas semillas de curvas NIST permanecieron sin explicación pública durante 26 años.

Hoy, ECDSA firma certificados TLS, protege transacciones de Bitcoin y autentica llaves SSH en millones de servidores. Su seguridad depende de que la curva elíptica subyacente, uno de los cinco pares que define el estándar FIPS 186-2 (P-192, P-224, P-256, P-384 y P-521), no tenga ninguna debilidad matemática escondida a propósito.

Esa curva se define con una ecuación y una constante, llamada b, que a su vez se calcula aplicando una función hash a un número de 160 bits: la semilla. El NIST publicó las semillas junto con las curvas en el año 2000, pero nunca explicó de dónde salieron esos números.

Las curvas elípticas se volvieron populares frente a RSA porque logran niveles de seguridad comparables con claves mucho más cortas, lo que las hizo más eficientes para dispositivos móviles y conexiones de alto volumen. Esa eficiencia explica en parte por qué ECDSA domina hoy buena parte de las conexiones TLS modernas y las firmas de varias criptomonedas basadas en curvas elípticas.
La curva P-256 es una de las cinco curvas primas que define el estándar FIPS 186-2.

Qué pasó con las semillas de curvas NIST

El 16 de octubre de 2026, Anthropic publicó un informe de investigación donde cuenta que un empleado le pidió a un modelo interno de Claude que averiguara, sin pistas previas, cómo se generaron esas semillas. El modelo tardó menos de media hora en encontrar el origen de los parámetros de P-192, P-224, P-256, P-384 y P-521.

La respuesta, según el informe de Anthropic, es que cada semilla salió de lrand48(), el generador de números pseudoaleatorios de las librerías C de Unix, inicializado con una marca de tiempo del sistema. El programa original tomaba 20 bytes por cada vuelta del generador como candidato a semilla; para producir la semilla publicada de P-256 hicieron falta 1.842 iteraciones.

Anthropic lo resume sin dramatismo: “no hay ninguna acción que tomar ni nada que hacer de forma distinta”, dice el informe, que presenta el hallazgo como el capítulo final de una especulación que ya duraba más de dos décadas.

Contexto e historia

La sospecha empezó en el propio texto del estándar. El NIST publicó la semilla de P-256 como esta cadena hexadecimal, sin ninguna nota al pie:

SEED = C49D3608 86E70493 6A6678E1 139D26B7 819F7E90

Los matemáticos Neal Koblitz y Alfred Menezes documentaron la controversia en el ensayo “A Riddle Wrapped in an Enigma”, y durante años circuló una recompensa informal para quien lograra reconstruir el origen de esos números.

La pista más citada venía de Jerry Solinas, el ingeniero de la NSA que trabajó en el diseño original. En 2015 dijo recordar que las semillas salieron de un hash aplicado a una frase en broma, algo como “Give Bob and Jerry a raise”, aunque admitió que ni él ni su colega Bob Reiter guardaban el código ni los detalles. Solinas murió en 2023 sin resolver la duda, y la pista de la frase resultó, según el hallazgo de Claude, completamente falsa.

Detalles técnicos

Claude no intentó repetir la búsqueda de la frase en broma. En cambio, según el informe de Anthropic, planteó una hipótesis distinta: que el software usado en los 90 para generar las semillas se apoyaba en un generador pseudoaleatorio típico de esa época, y que el patrón de ese generador todavía podía reconocerse en los bytes publicados.

Para probarlo, escribió un escáner que deslizaba una ventana de bits sobre cada semilla y comparaba bloques contiguos contra 34 combinaciones de generador y porción de salida. Ahí apareció la señal: en cuatro de diez semillas analizadas, las 20 palabras de 32 bits tenían el bit más alto en cero. Esa coincidencia, por azar, tiene una probabilidad de apenas 1 en 5.810.

Ese patrón es la firma de lrand48(), un generador congruencial lineal que solo devuelve los 31 bits superiores de un estado interno de 48 bits. Con esa pista, Claude probó por fuerza bruta los 2^17 valores posibles de los 17 bits ocultos y confirmó que las siguientes cuatro palabras de cada semilla encajaban exactamente.

Las semillas de las cinco curvas primas del NIST (P-192, P-224, P-256, P-384 y P-521) y cinco más del estándar ANSI X9.62 conservaban aún menos bits por salida, así que la fuerza bruta ya no alcanzaba. Para esas diez, Claude resolvió un problema clásico de retículas con el algoritmo Lenstra-Lenstra-Lovász (LLL), probando cada posible ventana de bits hasta confirmar el mismo patrón en las diez: lrand48() >> 23.
lrand48() forma parte de las librerías C estándar desde los años 90.Técnica usada por ClaudeDónde se aplicóQué resolvióEscaneo bit a bit (34 combinaciones)Las 10 semillas publicadasIdentificar qué generador de los 90 produjo cada semillaFuerza bruta de 2^17 valores4 semillas con bit superior en ceroRecuperar los bits ocultos del estado de lrand48()Reducción de retícula LLL10 semillas (5 NIST primas + 5 ANSI X9.62)Recuperar el estado truncado de lrand48() >> 23

flowchart TD
A["Semilla publicada (ej. P-256)"] --> B["Escaneo bit a bit: 34 combinaciones de PRNG"]
B --> C{"¿Bit superior en cero en las 20 palabras?"}
C -->|"Sí"| D["Fuerza bruta de 2^17 valores ocultos"]
C -->|"No"| E["Reducción de retícula LLL"]
D --> F["Estado interno de lrand48 recuperado"]
E --> F
F --> G["Iteraciones desde un timestamp Unix (1.842 para P-256)"]

💭 Clave: una probabilidad de 1 en 5.810 no es una demostración matemática, es una señal estadística. Lo que convierte el hallazgo en evidencia sólida es que, además de detectar el patrón, Claude reconstruyó bit por bit cada semilla publicada y las 10 coincidieron exactamente.

Impacto y análisis

El resultado no corrige ninguna vulnerabilidad activa. ECDSA sigue siendo tan seguro o inseguro como lo era antes del 16 de octubre de 2026; lo que cambia es la certeza sobre cómo se eligieron sus parámetros.

Durante 26 años, la falta de explicación alimentó la hipótesis de que la NSA pudo haber probado miles de semillas hasta encontrar una que escondiera una debilidad conocida solo por ella. Que el proceso completo dependa de un reloj y un generador público, reproducible por cualquiera con una terminal, reduce drásticamente el espacio para esa manipulación.

La comparación con RSA es útil. El algoritmo RSA no depende de parámetros elegidos por un tercero: cualquiera puede generar su propio par de claves desde cero. ECDSA, en cambio, necesita una curva estándar compartida, y esa dependencia es precisamente lo que mantuvo viva la sospecha sobre el origen de sus parámetros durante más de dos décadas.

Queda una duda honesta. El método muestra cómo se generó cada semilla, pero no cuántos intentos, es decir, cuántas marcas de tiempo distintas, probó la NSA antes de quedarse con el resultado publicado. Si alguien hubiera podido repetir el proceso con miles de timestamps y elegir la curva más conveniente, el reloj por sí solo no lo habría impedido. Anthropic no aborda ese escenario en su informe, y es la pieza que todavía depende de la confianza en el proceso original, no solo en las matemáticas.

Qué sigue

Anthropic no promete ninguna acción de seguimiento: el informe lo llama explícitamente un “capítulo de cierre divertido”. No hay parche, no hay nueva versión de ECDSA ni recomendación de migrar a otra curva por este motivo.

Lo que sí abre es un precedente. Usar un modelo de lenguaje para reconstruir decisiones técnicas de hace 30 años, a partir solo de los bytes publicados, es un método que podría aplicarse a otros estándares con parámetros nunca explicados. La criptografía tiene varios más esperando ese mismo tipo de arqueología.

📖 Resumen en Telegram: Ver resumen

Probalo vos: tomá el seed de P-256 (C49D3608 86E70493 6A6678E1 139D26B7 819F7E90) y seguí el razonamiento completo en el informe original de Anthropic antes de decidir cuánto confiar en una curva de 26 años.

Preguntas frecuentes

¿Qué encontró Claude sobre las semillas de curvas NIST?

Encontró que cada semilla, incluida la de P-256, es el resultado directo del generador lrand48() inicializado con una marca de tiempo Unix, y no de un hash de una frase secreta como se rumoraba desde 2015.

¿Por qué importaban los parámetros de ECDSA antes de este hallazgo?

Porque la NSA entregó esas semillas al NIST en el año 2000 sin explicar su origen, y una curva elíptica con un parámetro elegido a propósito podría, en teoría, esconder una debilidad conocida solo por quien la eligió.

¿Qué es lrand48() y por qué importa para la curva P-256?

Es un generador de números pseudoaleatorios incluido en las librerías C desde los años 90. La semilla de P-256 salió de 1.842 iteraciones de ese generador arrancado con un timestamp del sistema, y el mismo patrón apareció en otras nueve semillas de curvas distintas.

¿Este hallazgo significa que ECDSA tiene una puerta trasera?

No. Es lo contrario: al mostrar que el proceso de generación fue simple, público y reproducible, el hallazgo reduce la probabilidad de que exista una puerta trasera deliberada en las curvas NIST, aunque no descarta por completo que se hayan probado muchas marcas de tiempo antes de elegir la publicada.

¿Qué pasó con la pista de Jerry Solinas sobre el estándar FIPS 186-2?

Solinas, ingeniero de la NSA que ayudó a diseñar el estándar, dijo en 2015 recordar un hash de una frase en broma como origen de las semillas. Murió en 2023, y el hallazgo de Claude en 2026 confirmó que esa pista, repetida durante once años, era incorrecta.

Referencias

Anthropic Research: el informe original donde Claude reconstruye el origen de las semillas de las curvas NIST.- Wikipedia: historia y especificación técnica de ECDSA.- Wikipedia: cómo funciona un generador congruencial lineal como lrand48().- NIST Computer Security Resource Center: fuente oficial del estándar FIPS 186-2 y sus curvas elípticas.

Mercor: solo 208 de 923 ocupaciones con cobertura real de IA

lu1tr0n — Fri, 16 Oct 2026 20:37:49 +0000

Un chatbot resuelve casi cualquier pregunta de programación en segundos, pero nadie sabe si uno hace bien el trabajo real de un electricista, una enfermera o un inspector de seguridad. Según un informe de Mercor, apenas 208 de las 923 ocupaciones de EE.UU. tienen una tarea medida por benchmarks de IA con cinco pruebas o más.

La cifra agregada es más contundente: el 90% de las horas de trabajo pagadas en el país caen en tareas que las pruebas de IA actuales apenas rozan.

TL;DR

Mercor halla que solo 208 de 923 ocupaciones de EE.UU. tienen benchmarks de IA con 5 o más tareas cubiertas.- El 90% de las horas laborales del país caen en tareas con poca o nula cobertura de pruebas de IA.- Veintinueve benchmarks mapean 18.797 tareas O*NET agrupadas en 22 familias laborales, según el estudio.- Seis de 22 familias de empleo, entre ellas salud y educación, no tienen ninguna ocupación bien cubierta.- La cobertura sigue el salario: Computación y Matemáticas llega a 29 de 36 ocupaciones medidas.

Qué es el Benchmark Map de Mercor

El Benchmark Map de Mercor es un índice público que cruza las 923 ocupaciones y las 18.797 tareas de la taxonomía O*NET del Departamento de Trabajo de EE.UU. con 29 benchmarks de IA existentes, para medir qué porción del trabajo real del país tiene al menos una prueba que lo evalúe.

Mercor es conocida en la industria por operar un marketplace que conecta expertos de distintas profesiones con laboratorios de inteligencia artificial para generar datos de entrenamiento y evaluación. Su propio benchmark, APEX, forma parte de los 29 incluidos en este índice, con la ventaja de que la empresa tiene acceso a prompts aún no publicados y puede mapearlos directamente a cada tarea O*NET.

Qué pasó

El informe, publicado por Mercor y disponible como mapa interactivo, cruza la taxonomía O*NET con 29 benchmarks de evaluación de modelos de IA. Según el estudio, de las 923 ocupaciones que componen la fuerza laboral estadounidense, solo 208 tienen al menos una tarea con cinco o más prompts de algún benchmark mapeados a ella.

La cifra agregada confirma el problema: nueve de cada diez horas de trabajo pagadas en el país corresponden a tareas sin ningún benchmark o con una cobertura mínima, según el mismo informe. Mercor agrupó las 923 ocupaciones en 22 familias laborales siguiendo la clasificación oficial de O*NET, y encontró que 6 de esas 22 familias, que incluyen salud y educación, no tienen una sola ocupación con cobertura real.

El mapa divide esas 923 ocupaciones en 22 familias que siguen la clasificación estándar de O*NET, desde Computación y Matemáticas hasta Práctica de la Salud. Cada ocupación aparece como una celda que se colorea según el porcentaje de sus tareas con cobertura, lo que permite ver de un vistazo qué sectores concentran casi toda la atención de las pruebas de IA actuales y cuáles quedan prácticamente a oscuras.
El informe cubre 18.797 tareas repartidas en 923 ocupaciones de EE.UU.

Contexto e historia

Los benchmarks que miden qué tan bien razona o programa un modelo se multiplicaron en los últimos años, pero casi todos nacieron para medir capacidades académicas o de ingeniería de software, no el trabajo que sostiene el resto de la economía. Mercor dice que este Benchmark Map es apenas su primer paso hacia un recurso que planea actualizar de forma continua.

La idea de medir qué tan expuesta está una ocupación a la IA no es nueva. En 2023, los investigadores Tyna Eloundou, Sam Manning, Pamela Mishkin y Daniel Rock publicaron un estudio que etiquetó miles de tareas de O*NET según cuánto podía acelerarlas un modelo de lenguaje. Mercor retoma esas etiquetas binarias de exposición y las cruza con su propio mapa de cobertura para ver si las pruebas de IA realmente se concentran donde la exposición es mayor.

El propio informe reconoce que la saturación de pruebas de IA en ingeniería de software no es casual: ese es el tipo de tarea donde es más fácil automatizar la evaluación, porque hay tests, métricas de éxito claras y repositorios públicos, y donde los laboratorios de IA tienen interés directo en medir el progreso de sus propios modelos. Por eso Mercor impuso un tope de benchmarks por familia laboral al armar su índice de 29 pruebas, para que ingeniería de software y investigación académica no dominaran el panorama como lo hacen en catálogos previos.

Cómo mide Mercor los benchmarks de IA

El mecanismo detrás del mapa es un juez automático. Mercor usa un modelo de lenguaje para leer cada prompt de los 29 benchmarks evaluados y asignarle una o varias tareas de la lista de 18.797 que define O*NET; un mismo prompt puede mapear a varias tareas distintas si evalúa habilidades que se superponen. Una tarea O*NET cuenta como cubierta únicamente si el juez le asignó cinco o más prompts entre todos los benchmarks, no basta con una mención aislada.

Para confirmar que el etiquetado automático no inventaba coincidencias, el equipo comparó las etiquetas del juez con las de expertos humanos sobre APEX, el propio banco de pruebas de Mercor, donde la empresa tiene acceso a prompts todavía no publicados. Esa validación es la que permite afirmar que la cobertura medida no es ruido estadístico, sino una aproximación razonable a qué mide cada prueba.

Los 29 benchmarks del índice se eligieron con cinco criterios:

Disponibilidad pública: al menos 25 tareas públicas, o acceso directo vía APEX en el caso de Mercor.- Tareas agénticas: pedirle al modelo que ejecute una tarea, no solo que responda preguntas sobre ella.- Realismo económico: tareas parecidas a las que una empresa real le pide a un empleado, no acertijos académicos.- Diversidad económica: un tope de benchmarks por familia laboral para que software e investigación no dominen el índice.- Dificultad balanceada: benchmarks que los modelos de frontera todavía no saturan.

Para entender por qué unas ocupaciones tienen más cobertura que otras, Mercor corrió una regresión logística a nivel de tarea: la probabilidad de cobertura se explica con la etiqueta de exposición a la IA de Eloundou et al. y el logaritmo de la masa salarial de la ocupación, calculada multiplicando el salario medio que reporta la Oficina de Estadísticas Laborales por la cantidad de trabajadores y una semana de 40 horas. Los errores estándar se agrupan por familia ocupacional y los intervalos de confianza del 95% usan el método delta.

El resultado de esa regresión es una curva, no una tabla simple: a medida que sube la masa salarial de una ocupación, la probabilidad estimada de que una de sus tareas esté cubierta por algún benchmark sube de manera consistente, y la brecha entre tareas de alta y baja exposición a la IA se mantiene casi constante en todo el rango salarial. Ser una tarea automatizable según Eloundou et al. ayuda, pero ayuda mucho menos que pertenecer a una ocupación bien pagada.

flowchart TD
    A["Taxonomia O*NET: 923 ocupaciones, 18797 tareas"] --> B["Juez LLM etiqueta cada prompt de benchmark con sus tareas O*NET"]
    B --> C["Validacion contra etiquetas humanas en APEX"]
    C --> D{"Tarea con 5 o mas prompts mapeados?"}
    D -->|"Si"| E["Tarea cubierta"]
    D -->|"No"| F["Tarea sin cobertura"]

Impacto y análisis

Solo 29 benchmarks conforman el índice inicial del Benchmark Map.
El hallazgo más incómodo del informe es el patrón detrás del número total de ocupaciones cubiertas, más que el número en sí. Los benchmarks de IA no se reparten al azar entre las 923 ocupaciones: la probabilidad de que una tarea tenga cobertura sube con la masa salarial de la ocupación a la que pertenece, y sube todavía más si esa tarea ya está etiquetada como expuesta a la IA. El ejemplo que da Mercor es contundente: las tareas de abogados, una ocupación de alta exposición y alto salario, están ampliamente cubiertas, pero tareas igual de expuestas en ocupaciones como secretarias legales o empleados de juzgados apenas aparecen en algún benchmark.
Familia laboral (O*NET)Ocupaciones cubiertasCoberturaComputación y Matemáticas29 de 3680,6%Servicio comunitario10 de 1471,4%Legal5 de 771,4%Negocios y Finanzas33 de 4868,8%Administración y oficina21 de 5141,2%Gerencia21 de 5637,5%Arquitectura e Ingeniería19 de 5633,9%Artes y Medios13 de 4032,5%Ventas6 de 2227,3%Ciencia15 de 6025,0%Educación y Bibliotecas9 de 6214,5%Práctica de la Salud12 de 8913,5%
La tabla muestra solo 12 de las 22 familias para no diluir el patrón, pero la tendencia se mantiene en el resto: cuanto más grande es la nómina agregada de una familia laboral, más probable es que algún benchmark la mida, incluso cuando ocupaciones de menor salario comparten el mismo nivel de exposición a la IA según la clasificación de Eloundou et al.

El informe llama a esto la larga cola del trabajo de ingresos medios: ocupaciones como asistentes administrativos, técnicos de laboratorio o coordinadores de proyectos rara vez aparecen en un paper de benchmarks, aunque sumen millones de horas trabajadas al año. Sin una medición directa de esas tareas, cualquier afirmación sobre qué tan buena es la IA en el trabajo real descansa sobre una muestra sesgada hacia el código y las finanzas.

💭 Clave: la exposición a la IA de una tarea importa menos que el salario de la ocupación a la hora de decidir si alguien se molestó en medirla.

Qué sigue

Mercor dice que este mapa es un recurso vivo, no un informe cerrado: planea sumar más pruebas al índice a medida que aparezcan benchmarks con mayor realismo económico, y ampliar la cobertura hacia las familias laborales que hoy quedan en cero, como salud y educación. El objetivo declarado es que cualquiera pueda consultar, ocupación por ocupación, qué tan bien evaluada está la IA frente al trabajo que esa persona hace todos los días.

📖 Resumen en Telegram: Ver resumen

Si evaluás modelos de IA o diseñás benchmarks, abrí el mapa interactivo de Mercor y filtrá la familia laboral de tu propia industria para ver cuántas de sus tareas tienen alguna prueba real detrás.

Preguntas frecuentes

¿Qué mide exactamente el Benchmark Map de Mercor?

Mide qué porción de las 18.797 tareas que O*NET usa para describir el trabajo en Estados Unidos tiene al menos una prueba de modelos de IA que la cubra con cinco o más prompts, agrupando el resultado por las 923 ocupaciones y 22 familias laborales del país.

¿Cuántas de las 923 ocupaciones de EE.UU. están bien cubiertas?

Solo 208 tienen una tarea con cinco o más prompts mapeados por el índice de Mercor; el resto, unas 715 ocupaciones, no alcanza ese umbral o no tiene ninguna prueba asociada.

¿Por qué las ocupaciones legales están mejor evaluadas que las administrativas?

Porque la cobertura del Benchmark Map sigue más de cerca la masa salarial de la ocupación que su exposición real a la IA: abogados, con salarios altos, están bien cubiertos, mientras secretarias legales y empleados de juzgados, con exposición similar según Eloundou et al., quedan casi sin pruebas.

¿Qué es la exposición a la IA de Eloundou et al.?

Es una etiqueta binaria que ese estudio de 2023 asignó a miles de tareas de O*NET según cuánto podía acelerarlas un modelo de lenguaje grande; Mercor la usa como variable de control para separar el efecto del salario del efecto de la exposición real.

¿Mercor seguirá actualizando este índice de benchmarks?

Sí: la empresa lo describe como un primer paso hacia un recurso que planea actualizar de forma continua, sumando benchmarks y ocupaciones conforme aparezcan pruebas con suficiente realismo económico.

Referencias

Mercor Benchmark Map: el informe original con el mapa interactivo de cobertura por ocupación.- O*NET Resource Center: la taxonomía oficial del Departamento de Trabajo de EE.UU. con las 923 ocupaciones y sus tareas.- Eloundou, Manning, Mishkin y Rock (2023): el estudio que etiquetó la exposición de cada tarea de O*NET a los modelos de lenguaje.- Bureau of Labor Statistics, Occupational Employment and Wage Statistics: la fuente de los salarios usados para calcular la masa salarial de cada ocupación.