Diecisiete mil señales

Mi bóveda de Obsidian contiene 17.913 notas de señales. Cada una es un artículo de investigación, publicación de blog, aviso de seguridad o discusión comunitaria que mi escáner identificó como potencialmente relevante para uno de los nueve temas que monitoreo: seguridad de IA, agentes LLM, Claude/Anthropic, SwiftUI/iOS, sistemas de diseño, programación creativa, investigación en ML, ciencia y seguridad. Esta es la capa operativa de lo que llamo infraestructura de gusto — la idea de que el juicio estético y editorial debe codificarse en sistemas, no aplicarse de manera improvisada.

De esas 17.913 señales, he leído quizás 200 con detenimiento. Otras 500 influyeron en una decisión, una publicación de blog o una elección de diseño. Las 17.213 restantes son ruido que escaneé, puntué y archivé sin actuar al respecto.

El ruido no se desperdicia. El ruido es el instrumento.

El problema de la puntuación

Cada señal recibe una puntuación compuesta de 0 a 1, ponderada en cuatro dimensiones: relevancia (¿coincide con mis temas?), accionabilidad (¿puedo hacer algo con ella?), profundidad (¿tiene sustancia?) y autoridad (¿es creíble la fuente?). Las señales que superan 0,55 se escriben en carpetas de dominio. Las que están entre 0,40 y 0,55 van a la bandeja de entrada. Por debajo de 0,40 se descartan.

Los umbrales están calibrados, no elegidos arbitrariamente. Emergieron de meses de escaneo, revisión de lo que caía en cada categoría y ajustes hasta que la relación señal-ruido se sintió correcta. 0,55 era demasiado alto inicialmente (se perdían artículos que resultaron ser importantes). 0,30 era demasiado bajo (la bandeja de entrada se llenaba de basura). Los umbrales actuales producen aproximadamente 15-30 escrituras de dominio y 10-20 elementos en bandeja de entrada por escaneo en todos los temas.

El sistema de puntuación tiene sesgos que comprendo:

Los artículos de investigación comienzan con 0,75 de autoridad. Un artículo de arXiv con categoría y palabras clave coincidentes obtiene 0,75 antes de cualquier evaluación de contenido. Esto es deliberado: la investigación revisada por pares de campos relevantes tiene una credibilidad base que las publicaciones de blog y las discusiones de HN no tienen.

Los avisos de seguridad comienzan con 0,95 de autoridad. Un CVE del NVD o un GHSA de GitHub obtiene una puntuación alta independientemente del contenido, porque la existencia misma de un aviso de vulnerabilidad es la señal. El contenido es secundario frente al hecho.

Las discusiones de HN comienzan con 0,55 de autoridad. Las discusiones comunitarias son valiosas para el sentimiento y el descubrimiento, pero poco confiables para los hechos. Una historia de HN con muchos puntos sobre un nuevo artículo es un mecanismo de descubrimiento, no una fuente. El artículo en sí es la fuente.

Estas líneas base codifican mi juicio sobre la confiabilidad de las fuentes. Una persona diferente con prioridades diferentes establecería líneas base diferentes. Las líneas base no son verdades objetivas. Son una opinión codificada sobre de dónde proviene la confianza. La metodología completa de puntuación está documentada en mi pipeline de puntuación de señales.

Lo que enseña el ruido

La mayoría de los escaneos producen 80-100 escrituras de dominio y 20-40 elementos en bandeja de entrada. La mayoría es ruido: artículos que nunca leeré, avisos para software que no uso, discusiones sobre temas que monitoreo pero sobre los que no actúo.

El ruido enseña tres cosas:

La forma del campo. Cuando los escaneos de ai-safety devuelven consistentemente artículos sobre interpretabilidad mecanicista y RLHF, eso me dice dónde está enfocada la comunidad investigadora. Cuando los escaneos de llm-agents producen de repente cinco artículos sobre revisión de código agéntica en una semana, eso me indica que se está formando una tendencia. Los artículos individuales pueden ser ruido. La distribución de frecuencia es señal.

La línea base para la sorpresa. Un artículo con puntuación de 0,65 en el tema de ai-safety es poco notable. Un artículo con puntuación de 0,91 es sorprendente. La sorpresa solo tiene significado porque tengo una línea base de cómo se ve un 0,65. El ruido establece la línea base. La señal es la desviación respecto a esa línea base.

Las brechas en mi cobertura. Cuando ocurrió el ataque a la cadena de suministro de LiteLLM, mi pipeline de scan-intel lo detectó a través de coincidencia de palabras clave en HN. En ese momento, el pipeline no tenía fuentes de avisos de seguridad (NVD, OSV, GHSA). La brecha era invisible hasta que un incidente cayó por ella. Amplié el pipeline para añadir tres fuentes de avisos de seguridad la semana siguiente. El ruido de esas nuevas fuentes me está enseñando cómo se ve el tráfico normal de avisos. La próxima brecha será visible antes.

La expansión

El pipeline comenzó con 6 fuentes. Ahora tiene 12:

Cada fuente añadió ruido. Cada fuente también detectó algo que las demás pasaron por alto. La vulnerabilidad de path traversal de LangChain apareció en GHSA pero no en HN. El artículo de Claudini sobre autoresearch apareció en arXiv 12 horas antes que en HN. El credential stealer de LiteLLM apareció en OSV con el identificador MAL-2026-2144 que NVD aún no tenía.

El sistema de deduplicación basado en alias colapsa los duplicados entre fuentes. El mismo CVE que aparece en NVD, OSV y GHSA produce una nota de señal, no tres. En la primera ejecución en vivo, 6 de 85 señales de seguridad fueron deduplicadas por alias. La tasa de deduplicación aumentará a medida que las fuentes maduren.

La disciplina del triaje

Diecisiete mil señales exigen una disciplina de triaje. La mía es simple: escanear la salida, leer las puntuaciones altas, archivar el resto.

Un escaneo típico tarda 3 minutos en ejecutarse y 2 minutos en revisarse. Leo cada señal por encima de 0,80 (normalmente 2-5 por escaneo). Reviso rápidamente el rango de 0,60-0,80 en busca de sorpresas. Ignoro todo lo que está por debajo de 0,60 a menos que una palabra clave me llame la atención.

El escaneo es habitual. Escaneo matutino, escaneo vespertino. Algunos días producen más de 100 escrituras de dominio (cuando cae un nuevo lote de arXiv). Algunos días producen cero (cuando la ventana retrospectiva de 7 días ya ha sido completamente deduplicada). La varianza es normal. El hábito es constante.

Las señales que más importan son las que cambian lo que construyo o escribo. El artículo de Claudini (0,83) se convirtió en una publicación de blog. El ataque a la cadena de suministro de LiteLLM (0,67 desde HN, luego confirmado vía OSV con 0,62) se convirtió en una publicación de blog y dos actualizaciones de citas en publicaciones existentes. El dataset LICA (encontrado manualmente, no por scan-intel) se convirtió en un plan para un motor de gusto en diseño. El artículo de SlopCodeBench (0,77) se convirtió en un candidato a cita para la publicación sobre contexto compuesto.

La mayoría de las señales no se convierten en nada. Se archivan silenciosamente en la bóveda, establecen la línea base y esperan el día en que una nueva señal se conecte con una antigua y produzca un insight que ninguna de las dos contenía por separado.

La bóveda como memoria

La bóveda no es una lista de lectura. No tengo la intención de leer las 17.213 señales que no he leído. La bóveda es una memoria consultable de lo que el campo produjo durante el tiempo que he estado observando — una forma de topología del conocimiento donde la estructura de las conexiones importa más que cualquier nodo individual.

Cuando escribo una publicación de blog sobre seguridad en la cadena de suministro, puedo buscar en la bóveda cada señal etiquetada con “security” y “supply-chain” en los últimos 90 días. La búsqueda devuelve el ataque a LiteLLM, el compromiso de Trivy, el benchmark MCPTox, el ataque Clinejection y una docena de CVEs que afectan paquetes de infraestructura de IA. Cada uno es una cita potencial, un dato o un contraargumento.

Cuando planifico una nueva función, puedo buscar señales relacionadas con el dominio. El dataset LICA apareció en una ejecución de scan-intel como una señal de design-systems con puntuación de 0,72. No lo habría encontrado mediante una búsqueda dirigida porque no estaba buscando datasets de diseño gráfico. El escaneo lo sacó a la superficie porque las palabras clave (“design systems”, “typography”) coincidían. La bóveda hizo la conexión.

Las 17.213 señales no leídas no son esfuerzo desperdiciado. Son contexto indexado que puedo consultar cuando lo necesite. El escaneo es barato. La indexación es automática. El valor es latente hasta el momento en que una pregunta se conecta con una respuesta que fue archivada hace meses. Esto es contexto compuesto en la práctica: cada señal depositada hoy puede convertirse en la pieza faltante de una síntesis futura.

FAQ

¿Qué herramientas usas?

El escáner es un script personalizado en Python (scan_intel.py, ~1.200 líneas) que obtiene datos de 12 fuentes, puntúa con un motor de triaje, deduplica en tres capas (URL, ID de artículo, alias de avisos) y escribe notas en markdown en una bóveda de Obsidian. La bóveda usa Dataview para consultas. La configuración está en JSON. El estado (IDs vistos) se almacena en JSON con poda de 90 días.

¿Cuánto cuesta esto?

Cero. Todas las fuentes son APIs de nivel gratuito o feeds RSS públicos. arXiv, Semantic Scholar, OSV y la API de Algolia de HN no requieren autenticación. NVD tiene un nivel gratuito con límites de tasa (5 solicitudes cada 30 segundos). Los avisos de GitHub usan la CLI gh que se autentica mediante tu sesión existente de GitHub.

¿Cómo evitas la sobrecarga de información?

Con los umbrales de puntuación y la disciplina de triaje. Dedico 2 minutos por escaneo a revisar la salida. Las señales por debajo de 0,60 se archivan sin leerlas. La bóveda crece, pero mi atención no escala con ella. La bóveda es una memoria, no una tarea de lectura.

¿Puedo usar este sistema?

La arquitectura es portable: obtener datos de APIs, puntuar con criterios ponderados, deduplicar, escribir en una base de conocimiento. Las fuentes, palabras clave y umbrales específicos están calibrados para mis intereses. Necesitarías definir tus propios temas, palabras clave y líneas base de autoridad. El motor de puntuación y la lógica de deduplicación son agnósticos al dominio. Mi guía de Obsidian cubre la arquitectura de la bóveda y los patrones de consulta en detalle, y mi publicación sobre el recuperador híbrido explica cómo combino búsqueda por palabras clave y búsqueda semántica sobre este corpus.