Que sucede cuando un ID es conocimiento, no una direccion
Una direccion no sabe nada
Para encontrar a Yi Sun-sin en una base de datos, necesitas un ID.
En Wikidata, el ID de Yi Sun-sin es Q8492.
Este numero apunta a Yi Sun-sin.
Pero la cadena Q8492 en si misma no sabe nada.
No sabe si se trata de una persona o un edificio. No sabe si es coreano o ciudadano frances. No sabe si es una figura del siglo XVI o del siglo XXI. No sabe si esta vivo o muerto.
Q8492 es una direccion.
Un cartero que entrega correo no tiene idea de lo que esta escrito dentro del sobre.
Simplemente mira la direccion en el sobre y lo entrega.
UUID es igual. 550e8400-e29b-41d4-a716-446655440000.
128 bits de numeros aleatorios. Unico solo para evitar colisiones –
no te dice nada sobre lo que referencia.
Durante los ultimos cincuenta anos, los IDs de las bases de datos han funcionado asi. Un ID es una direccion, y para saber algo, debes seguir esa direccion y leer los datos.
Hay que seguirlo para saber
Por que es esto un problema?
Supongamos que quieres encontrar “un filosofo varon de nacionalidad alemana nacido en el siglo XIX”.
En una base de datos tradicional, esto funciona asi:
1. Filtrar la tabla de personas donde genero = 'masculino'
2. JOIN con la tabla de nacionalidades y filtrar pais = 'Alemania'
3. JOIN con la tabla de fechas de nacimiento y filtrar anio BETWEEN 1800 AND 1899
4. JOIN con la tabla de ocupaciones y filtrar ocupacion = 'filosofo'
Cuatro operaciones JOIN. Cada JOIN compara filas entre dos tablas. Si las tablas son grandes, recorre un indice; si no hay indice, realiza un escaneo completo. Con mil millones de registros, este proceso toma de segundos a decenas de segundos.
Por que es tan complejo?
Porque el ID no sabe nada.
Mirando Q8492, no puedes decir si es aleman o coreano,
asi que debes ir a otra tabla para obtener esa informacion.
Para cada pregunta, hay que seguir a donde apunta el ID. Este es el costo que las bases de datos han pagado durante cincuenta anos.
Y si el ID ya supiera?
Invirtamos la premisa.
Y si el ID mismo contuviera la informacion esencial?
Y si, simplemente mirando el ID, pudieras saber si se refiere a un humano, de que pais es, a que epoca pertenece y como esta clasificado?
Para encontrar “un filosofo varon aleman del siglo XIX”, los JOIN se vuelven innecesarios.
Escaneando mil millones de IDs, puedes determinar instantaneamente si cada uno coincide examinando sus bits.
Esta es la idea central detras del Indice Semanticamente Alineado.
Alinear el significado en el ID
SIDX (Semantically-Aligned Index) es un identificador de 64 bits.
Estos 64 bits no son numeros aleatorios. Se asigna significado a la posicion de cada bit.
Los bits superiores contienen la informacion mas importante. Que tipo de entidad es? Una persona, un lugar, un evento, un concepto?
Los siguientes bits contienen informacion de clasificacion. Si es una persona, de que epoca? De que region?
Los bits inferiores llevan informacion cada vez mas especifica.
El principio clave es este:
El orden de los bits es el orden de importancia de la informacion.
La clasificacion mas fundamental arriba, las distinciones mas granulares abajo.
Esto no es mera ordenacion. Es una filosofia de diseno.
De mil millones a diez mil, en una sola pasada
El poder practico de SIDX se muestra en los numeros.
WMS contiene mil millones de entidades. El SIDX de cada entidad es de 64 bits. Tamano total: mil millones x 8 bytes = 8 GB.
Estos 8 GB caben completamente en memoria.
Quieres encontrar “entidades que son humanas y originarias de Asia Oriental”. Los bits superiores contienen una bandera “humano” y un codigo “Asia Oriental”, asi que puedes filtrar con una sola mascara de bits.
mask = 0xFF00_0000_0000_0000 (8 bits superiores: tipo + region)
target = 0x8100_0000_0000_0000 (humano + Asia Oriental)
for each sidx in 1_billion:
if (sidx & mask) == target:
add to candidates
Esta operacion se paraleliza con SIMD. Con AVX-512, comparas 8 SIDX simultaneamente en una sola instruccion. Escanear mil millones de entradas: aproximadamente 12 milisegundos.
En una GPU? Menos de 1 milisegundo.
Mil millones de registros reducidos a diez mil. Filtrar los diez mil restantes en detalle es instantaneo.
Cero JOIN. Cero recorridos de arbol de indices. Solo un AND a nivel de bits.
Por que 64 bits es suficiente
Al principio, pense que se necesitaba un espacio mayor.
32 bytes (256 bits). Un vector FP16 de 32 dimensiones. Intente meter cada atributo clave de una entidad en el ID. Si es humano, su genero, nacionalidad, epoca, ocupacion, region, si esta vivo, ruta de clasificacion…
Pero entonces me di cuenta de algo.
El ID no necesita saberlo todo.
Solo necesita reducir mil millones de registros a diez mil. WMS se encarga del resto.
Piensalo como un punto de control. En un peaje de autopista, para determinar que “este vehiculo se dirige hacia la provincia de Gyeonggi” por la matricula, no necesitas saber que hay cargado en el maletero.
64 bits es suficiente. Usa los bits superiores para capturar tipo y clasificacion amplia, y los bits inferiores para clasificacion mas fina. 64 bits es mas que suficiente para reducir mil millones de registros a diez mil.
Y 64 bits = cuatro palabras de 16 bits. Fluyen naturalmente dentro de un flujo. Un ID de 32 bytes haria pesado el flujo, pero un SIDX de 64 bits es ligero y rapido.
Degradacion elegante: el significado sobrevive incluso cuando los bits se truncan
Otra fortaleza de la alineacion semantica son sus caracteristicas de degradacion.
Porque los bits de SIDX estan ordenados de mas a menos importante, incluso si los bits inferiores se danan o truncan, la informacion central en los bits superiores se preserva.
64 bits completos: "Yi Sun-sin, comandante naval de Joseon del siglo XVI"
48 bits: "Oficial militar de Joseon del siglo XVI"
32 bits: "Humano del este de Asia del siglo XVI"
16 bits: "Humano"
8 bits: "Entidad fisica"
A medida que la informacion se trunca, se pierde especificidad, pero la clasificacion mas fundamental sobrevive hasta el final.
Esta es una implementacion a nivel de bits del principio de “degradacion elegante”.
Incluso si una interrupcion de red entrega solo datos parciales, el sistema sabe “no se exactamente quien es, pero al menos es una historia sobre un humano” y puede continuar razonando.
Un contorno borroso es mejor que el silencio total. La comprension parcial es mejor que el fallo completo.
Una consulta se convierte en un ID
La posibilidad mas intrigante que abre la indexacion semanticamente alineada es esta: una consulta en lenguaje natural puede convertirse en un SIDX temporal.
Un usuario pregunta: “Quien fue el general que derroto a la armada japonesa durante la Guerra Imjin?”
El codificador analiza esta pregunta. Humano. Asia Oriental. Siglo XVI. Relacionado con lo militar. Ensamblar estos atributos en bits produce un SIDX temporal.
Este SIDX temporal escanea los mil millones de SIDX en WMS. Las entidades cuyos patrones de bits son mas similares emergen como candidatas. Yi Sun-sin, Won Gyun, Gwon Yul, Yi Eok-gi…
Cruzar informacion detallada con estos candidatos produce la respuesta final.
Esto unifica busqueda y vinculacion de entidades en un solo mecanismo. No se requiere motor de busqueda separado. No se requiere pipeline de NER (Named Entity Recognition) separado. Una sola comparacion SIDX es todo lo que se necesita.
Por que no un B-Tree?
Las bases de datos tradicionales usan indices B-Tree.
Los B-Tree sobresalen encontrando un valor especifico en datos ordenados en O(log n). Para “encontrar Q8492”, son optimos.
Pero para “encontrar todas las entidades que son humanas y originarias de Asia Oriental”, son debiles. Las busquedas por condiciones compuestas requieren intersectar multiples indices, y el costo de la interseccion crece drasticamente con la escala de datos.
SIDX + escaneo exhaustivo SIMD toma un enfoque fundamentalmente diferente.
Si un B-Tree es una guia telefonica que responde rapidamente “quien vive en esta direccion”, un escaneo SIDX es un perfilado que responde rapidamente “quien tiene estas caracteristicas”.
La naturaleza de la pregunta difiere, y tambien lo hace la estructura de datos optima.
| Tipo de consulta | B-Tree | Escaneo SIDX |
|---|---|---|
| Busqueda por ID especifico | O(log n), optimo | Innecesario (usar hash) |
| Filtrado por condiciones compuestas | Requiere JOIN, lento | Un AND a nivel de bits, rapido |
| Busqueda de entidades similares | No es posible | Posible via similitud vectorial |
| Insercion | O(log n), rebalanceo | O(1), append |
| Complejidad de implementacion | Alta | Baja |
WMS no usa B-Tree. Carga mil millones de SIDX en memoria y realiza un escaneo exhaustivo con mascaras de bits SIMD.
Simple. Fuerza bruta. Rapido.
La sabiduria de Huffman
La estructura de asignacion de bits de SIDX sigue el principio de la codificacion de Huffman.
En la codificacion de Huffman, los simbolos que ocurren con frecuencia reciben codigos mas cortos, y los simbolos que ocurren raramente reciben codigos mas largos.
En SIDX, la informacion de clasificacion mas frecuentemente necesitada ocupa los bits superiores, y los detalles raramente necesitados ocupan los bits inferiores.
El mismo principio gobierna los prefijos de tipo de paquete de este lenguaje. El Tiny Verb Edge de mayor frecuencia obtiene el prefijo mas corto. El Event6 Edge de baja frecuencia obtiene un prefijo mas largo.
La sabiduria de Huffman recorre cada capa de este diseno. Ni un solo bit se desperdicia. El menor costo para lo mas importante.
Resumen
Un ID tradicional es una direccion. Una direccion no sabe nada.
- Cuando el ID no lleva significado, debes seguirlo hasta los datos cada vez. Eso es un JOIN.
- Cuatro JOIN a traves de mil millones de registros es lento.
- SIDX codifica significado directamente en el ID a traves de la alineacion semantica.
- Un solo AND con mascara de bits reduce mil millones de registros a diez mil. Cero JOIN.
- 64 bits es suficiente. El ID no necesita saberlo todo – solo necesita reducir los candidatos.
- Porque la informacion mas importante ocupa los bits superiores, el significado central sobrevive incluso cuando los bits se truncan.
- Convertir una consulta en lenguaje natural a un SIDX temporal convierte la busqueda en una operacion vectorial.
El momento en que un ID deja de ser una direccion y se convierte en conocimiento, las reglas de la base de datos cambian.