GPT en 200 líneas & Publicidad dentro de chats - Noticias de Hacker News (1 mar 2026)

Empecemos por el experimento educativo más llamativo: Andrej Karpathy presentó “microgpt”, un proyecto minimalista que implementa el bucle completo de entrenamiento e inferencia de un GPT en un solo archivo de Python, sin dependencias. No es un “modelo grande”; es una pieza de artesanía didáctica. Incluye lo esencial: un dataset pequeño —unos 32.000 nombres humanos—, un tokenizador a nivel de caracteres con un token especial de inicio de secuencia, un motor de autograd escalar hecho desde cero y un Transformer simplificado tipo GPT‑2. Incluso mete RMSNorm, Adam y el ciclo de muestreo. Lo interesante no es solo que “funcione”, sino lo que te obliga a ver: cómo se construye el grafo de cómputo con operaciones escalares, cómo se propagan gradientes sin tensores, y cómo una arquitectura diminuta —16 dimensiones de embedding, 4 cabezas, 1 capa, bloque de 16 tokens y apenas 4.192 parámetros— aprende a completar nombres. Tras 1.000 pasos, la pérdida baja desde algo parecido al azar hasta valores sensiblemente mejores, y al muestrear con temperatura genera nombres plausibles. También muestra una progresión por etapas, de bigramas a atención, para que puedas “ver nacer” un GPT paso a paso.

Y ya que estamos en el lado pedagógico, aparece un contraste muy sano: Carnegie Mellon lanza “10-202: Introduction to Modern AI”, impartida por Zico Kolter. El enfoque es moderno en el sentido práctico: lo que está detrás de sistemas tipo ChatGPT, Gemini o Claude. La promesa, alineada con microgpt, es que los componentes base —aunque se escalen brutalmente— son conceptualmente simples y se pueden implementar en pocas centenas de líneas. La asignatura se apoya en tareas de programación para construir gradualmente un chatbot mínimo: empiezas con modelos lineales y PyTorch, avanzas a redes neuronales, self‑attention y Transformers, y llegas a fine‑tuning supervisado y métodos post‑training, incluyendo alineamiento e incluso refuerzo para modelos de razonamiento. Hay versión online gratuita con vídeos y ejercicios autocorregidos, aunque sin exámenes. Y un detalle relevante: permiten usar asistentes de IA en los deberes, pero recomiendan que la entrega final sea tuya; en quizzes y exámenes, prohibición total. En otras palabras: IA para apoyar, no para sustituir el aprendizaje.

Para quienes no quieren meterse aún en Transformers, pero sí entender ML “con lupa”, un artículo de MLU‑Explain repasa árboles de decisión con una claridad muy práctica. Construyen el concepto como una cascada de reglas if‑then: divides el espacio de características por umbrales —por ejemplo, diámetro y altura— y acabas con regiones que apuntan a una clase: Manzano, Cerezo u Roble, en su dataset de juguete. Lo potente aquí es la explicación de cómo se eligen los cortes: entropía como medida de impureza e “information gain” como la ganancia al reducir esa mezcla tras un split. Presentan ID3 como algoritmo voraz: prueba particiones, calcula entropías ponderadas en hijos y elige lo que más reduce la incertidumbre. Y ponen el aviso que muchos olvidan: si sigues dividiendo hasta que todo sea “puro”, probablemente estás memorizando ruido. Eso conecta con el trade‑off sesgo‑varianza, la inestabilidad de los árboles y por qué random forests o boosting suelen ganar en robustez.

Cambiemos de tema dentro de IA, pero sin salir del “producto”: Anthropic está empujando una función llamada “Import Memory” para Claude. La idea es facilitar el salto desde otros asistentes: si llevas meses enseñándole a otro chat tus preferencias —tono, formato, restricciones, cómo programas o cómo redactas—, puedes exportar ese contexto con un prompt, y luego pegar el resultado en la configuración de memoria de Claude. Lo relevante no es el copy‑paste en sí, sino el planteamiento de UX: hacer que tu “primera conversación” se sienta como la número cien. También subrayan dos promesas: que puedas ver y editar todo lo que se recuerda, y que los contextos de proyectos estén separados para que no se contaminen entre sí. Y sí, esto está ligado a planes de pago, lo cual nos lleva al siguiente bloque: monetización.

Aquí entra una demo bastante mordaz, pero funcional: 99helpers lanzó un “Ad‑Supported AI Chat Demo”. Básicamente, un chat de IA que te enseña —sin disimulo— cómo podría financiarse un asistente si el coste de cómputo aprieta. El sitio está diseñado como experiencia educativa para marketers, PMs y desarrolladores, y despliega un catálogo completo de formatos publicitarios dentro de la interfaz. Hay un interstitial a pantalla completa antes de chatear, con cuenta atrás. Hay banners y laterales persistentes alrededor de la ventana de conversación. Hay “respuestas patrocinadas”, donde el modelo mezcla recomendaciones de producto dentro de la respuesta. Y también anuncios de texto contextuales insertados entre bloques, emparejados con el tema de la conversación. Cuando detecta intención de compra, aparecen tarjetas de producto con imagen, precio y llamada a la acción. Además, simulan retargeting y segmentación por ubicación. El punto más interesante es el peaje freemium: cinco mensajes gratis, y luego te pide “ver” un anuncio —otro conteo de cinco segundos— para desbloquear más, o te empuja al plan sin anuncios. La demo también compara economía de suscripción versus economía publicitaria: interrupciones, incentivos de calidad —¿optimizar para clicks o para utilidad?—, privacidad y uso de datos para targeting, escalabilidad y métricas tipo CPM/CPC/CPA frente a cuotas mensuales. Dicen que las respuestas vienen de un modelo real, pero que las marcas son ficticias; y que registran chats para mejorar el servicio, no para venderlos a anunciantes. Aun así, el ejercicio deja una pregunta incómoda: ¿cuánto “ruido” aceptaríamos a cambio de un chat barato?

Pasemos a infraestructura web y seguridad: Google, desde el equipo de Chrome de Web segura y networking, anunció un programa para hacer certificados HTTPS resistentes a futuros ordenadores cuánticos sin disparar el coste en ancho de banda y latencia de TLS. El problema es conocido: los algoritmos post‑cuánticos tienden a tener firmas y claves más grandes, y meter eso en cadenas X.509 tradicionales —más Certificate Transparency— puede hacer el saludo TLS pesado. La propuesta que están empujando, alineada con el grupo PLANTS del IETF, son los Merkle Tree Certificates, o MTC. En lugar de cargar con una cadena de certificados y firmas voluminosas, una CA firma un “Tree Head” que representa potencialmente millones de certificados, y el navegador recibe una prueba compacta de inclusión en un árbol de Merkle. Según Google, esto reduce drásticamente los datos de autenticación en el handshake y hace la transparencia inherente: si no estás en el árbol público, no existes. El plan de despliegue va por fases: primero, pruebas con tráfico real junto a Cloudflare, siempre respaldadas por un X.509 clásico por si algo falla. Luego, hacia Q1 de 2027, invitarían a operadores de logs de CT con historial sólido para ayudar a arrancar árboles MTC públicos. Y en Q3 de 2027 apuntan a un Chrome Quantum‑resistant Root Store paralelo, con opción de protecciones anti‑downgrade para sitios que quieran exigir solo certificados resistentes a cuántica. También deslizan cambios de política: emisión ACME‑only, revocación más moderna centrada en compromisos de clave, y validación de control de dominio reproducible y auditable públicamente.

Ahora una historia pequeña, pero deliciosa para quienes depuran sistemas: el “misterio” de Linux donde, al interceptar malloc con LD_PRELOAD y registrar reservas, el primer malloc de muchos programas aparece como 73.728 bytes, es decir, unos 72 KB. El autor lo investigó construyendo un allocador propio y, muy importante, un logger “seguro” que no recursione pidiendo memoria al registrar: buffers en stack y syscalls de bajo nivel. Con gdb y símbolos, vio que ese primer malloc no viene de tu programa ni de libc, sino de libstdc++. Concretamente, del código de manejo de excepciones: libstdc++ crea perezosamente un “emergency pool” para poder lanzar excepciones incluso si malloc falla más tarde. Ese pool se materializa como una arena reservada al inicio, y su tamaño por defecto en 64 bits coincide con esos ~72 KB por cómo se calculan número de objetos y tamaño de objeto. ¿La parte práctica? Puedes modificarlo con GLIBCXX_TUNABLES: bajando el conteo de objetos reduces esa primera reserva; poniéndolo a cero, lo desactivas. Esto también explica falsos sustos en Valgrind: programitas C++ que “no hacen nada” y aun así muestran memoria “still reachable”. No siempre es una fuga: a veces es ese colchón para excepciones, y depende de versión y configuración si se libera al final para que la salida sea más limpia.

Y cerramos con rendimiento de bases de datos: Tomas Vondra pone en duda un consejo repetido casi por inercia en PostgreSQL: “baja random_page_cost porque ahora hay SSD”. Ese parámetro, con default 4.0 desde hace unos 25 años, influye en si el planner prefiere un index scan “aleatorio” o un seq scan “secuencial”. Vondra mide el coste real comparando escaneo secuencial e indexado en una tabla de ~4,4 GB, con caché deliberadamente limitada y direct I/O para no confundir con el caché del sistema operativo. El resultado es contraintuitivo: la diferencia entre acceso secuencial y aleatorio sigue siendo enorme, incluso en SSD, y su estimación efectiva de random_page_cost cae en el rango 25–35 en varias máquinas; en almacenamiento remoto, más. ¿Por qué importa? Porque si el planner subestima lo aleatorio, elige index scans con demasiada alegría y puede terminar hasta 10× más lento en ciertas selectividades. También matiza algo clave: los bitmap scans cambian el juego porque vuelven el patrón de acceso más secuencial y permiten prefetch, pero el modelo de costes de Postgres no captura bien ese prefetching. Conclusión: no hay un número mágico; tocar random_page_cost sin medir puede empeorar. Su recomendación es ajustar con observabilidad real —latencias, pg_stat_statements— y entender tu carga: OLTP con working set en caché no se comporta igual que consultas grandes con I/O real.

Dos apuntes rápidos para cerrar el bloque de “construcción de software”. Primero, en frontend aparece Float64 Vertex, un framework SPA en un solo archivo, sin build step, que intenta juntar ideas de React, Ractive‑Load y jQuery, manteniendo compatibilidad con jQuery. Ofrece un wrapper tipo jQuery para DOM y eventos, un ajax wrapper con forma familiar, templates estilo Mustache con re-render al actualizar estado y un reconciliador “fiber” con createElement, render, lazy y hooks como useState, useEffect, useMemo y context. Es una propuesta para quien quiere algo autocontenido y pragmático. Y segundo, una pieza más cultural: Hannah Ilea habla de “houseplant programming”, software pequeñito y personal, hecho para una sola persona, donde “funciona en mi máquina” puede ser el estándar correcto. Lo contrapone a producción —donde, como dice el chiste, “hay un número de teléfono al que llamar si se rompe”— y propone no pedir perdón por proyectos idiosincráticos que cumplen su objetivo. También introduce “bouquet programming” para scripts de un solo uso. En tiempos de obsesión por escalabilidad y pulido, es un recordatorio útil: a veces un programa casero es exactamente lo que necesitas.