O Que Acontece Quando um ID e Conhecimento, Nao um Endereco
Um Endereco Nao Sabe Nada
Para encontrar Yi Sun-sin em um banco de dados, voce precisa de um ID.
No Wikidata, o ID de Yi Sun-sin e Q8492.
Esse numero aponta para Yi Sun-sin.
Mas a string Q8492 em si nao sabe nada.
Ela nao sabe se se trata de uma pessoa ou um edificio. Ela nao sabe se e um coreano ou um cidadao frances. Ela nao sabe se e uma figura do seculo XVI ou do seculo XXI. Ela nao sabe se a pessoa esta viva ou morta.
Q8492 e um endereco.
Um carteiro entregando correspondencia nao tem ideia do que esta escrito dentro do envelope.
Ele simplesmente olha o endereco no envelope e entrega.
UUID e o mesmo. 550e8400-e29b-41d4-a716-446655440000.
128 bits de numeros aleatorios. Unicos apenas para evitar colisoes –
nao dizem nada sobre o que referenciam.
Nos ultimos cinquenta anos, IDs de bancos de dados funcionaram assim. Um ID e um endereco, e para saber qualquer coisa, voce precisa seguir esse endereco e ler os dados.
Voce Precisa Seguir Para Saber
Por que isso e um problema?
Suponha que voce queira encontrar “um filosofo do sexo masculino de nacionalidade alema nascido no seculo XIX”.
Em um banco de dados tradicional, funciona assim:
1. Filtrar tabela de pessoas onde genero = 'masculino'
2. JOIN com tabela de nacionalidades e filtrar pais = 'Alemanha'
3. JOIN com tabela de datas_nascimento e filtrar ano BETWEEN 1800 AND 1899
4. JOIN com tabela de ocupacoes e filtrar ocupacao = 'filosofo'
Quatro operacoes JOIN. Cada JOIN compara linhas entre duas tabelas. Se as tabelas sao grandes, percorre um indice; se nao ha indice, faz uma varredura completa. Com um bilhao de registros, esse processo leva de segundos a dezenas de segundos.
Por que e tao complexo?
Porque o ID nao sabe nada.
Olhando para Q8492, voce nao consegue dizer se e um alemao ou um coreano,
entao precisa ir a outra tabela para obter essa informacao.
Para cada pergunta, voce precisa seguir para onde o ID aponta. Esse e o custo que bancos de dados pagam ha cinquenta anos.
E Se o ID Ja Soubesse?
Vamos inverter a premissa.
E se o proprio ID contivesse as informacoes essenciais?
E se, simplesmente olhando para o ID, voce pudesse dizer se ele se refere a um humano, de qual pais ele vem, a qual epoca pertence e como e classificado?
Para encontrar “um filosofo alemao do sexo masculino do seculo XIX”, JOINs se tornam desnecessarios.
Varrendo um bilhao de IDs, voce pode determinar instantaneamente se cada um corresponde examinando seus bits.
Essa e a ideia central do Indice Semanticamente Alinhado.
Alinhando Significado no ID
SIDX (Semantically-Aligned Index) e um identificador de 64 bits.
Esses 64 bits nao sao numeros aleatorios. O significado e atribuido a posicao de cada bit.
Os bits superiores carregam a informacao mais importante. Que tipo de entidade e essa? Uma pessoa, um lugar, um evento, um conceito?
Os bits seguintes carregam informacao de classificacao. Se e uma pessoa, de qual epoca? De qual regiao?
Bits inferiores carregam informacoes cada vez mais especificas.
O principio fundamental e este:
A ordem dos bits e a ordem de importancia da informacao.
A classificacao mais fundamental no topo, as distincoes mais granulares na base.
Isso nao e mera ordenacao. Isso e uma filosofia de design.
De Um Bilhao Para Dez Mil, Em Uma Unica Passagem
O poder pratico do SIDX se mostra nos numeros.
O WMS contem um bilhao de entidades. O SIDX de cada entidade tem 64 bits. Tamanho total: 1 bilhao x 8 bytes = 8 GB.
Esses 8 GB cabem inteiramente na memoria.
Voce quer encontrar “entidades que sao humanas e originarias do Leste Asiatico”. Os bits superiores contem uma flag “humano” e um codigo “Leste Asiatico”, entao voce pode filtrar com uma unica bitmask.
mask = 0xFF00_0000_0000_0000 (8 bits superiores: tipo + regiao)
target = 0x8100_0000_0000_0000 (humano + Leste Asiatico)
for each sidx in 1_bilhao:
if (sidx & mask) == target:
adicionar aos candidatos
Essa operacao se paraleliza com SIMD. Com AVX-512, voce compara 8 SIDXs simultaneamente em uma unica instrucao. Varredura de 1 bilhao de entradas: aproximadamente 12 milissegundos.
Em uma GPU? Menos de 1 milissegundo.
Um bilhao de registros reduzidos a dez mil. Filtrar os dez mil restantes em detalhe e instantaneo.
Zero JOINs. Zero travessias de arvore de indices. Apenas um AND bit a bit.
Por Que 64 Bits E Suficiente
No inicio, pensei que um espaco maior era necessario.
32 bytes (256 bits). Um vetor FP16 de 32 dimensoes. Tentei encaixar cada atributo-chave de uma entidade no ID. Se e humano, o genero, nacionalidade, epoca, ocupacao, regiao, status de vida, caminho de classificacao…
Mas entao percebi algo.
O ID nao precisa saber tudo.
Ele so precisa reduzir um bilhao de registros a dez mil. O WMS cuida do resto.
Pense nisso como um ponto de controle. Em um pedagio de rodovia, para determinar que “este veiculo esta indo para a provincia de Gyeonggi” a partir da placa, voce nao precisa saber o que esta carregado no porta-malas.
64 bits e suficiente. Use os bits superiores para capturar tipo e classificacao ampla, e os bits inferiores para classificacao mais fina. 64 bits e mais do que suficiente para reduzir um bilhao de registros a dez mil.
E 64 bits = quatro palavras de 16 bits. Elas fluem naturalmente dentro de um stream. Um ID de 32 bytes tornaria um stream pesado, mas um SIDX de 64 bits e leve e rapido.
Degradacao Graciosa: O Significado Sobrevive Mesmo Quando Bits Sao Truncados
Outra forca do alinhamento semantico sao suas caracteristicas de degradacao.
Como os bits do SIDX sao ordenados do mais ao menos importante, mesmo que os bits inferiores sejam danificados ou truncados, a informacao central nos bits superiores e preservada.
64 bits completos: "Yi Sun-sin, comandante naval do Joseon do seculo XVI"
48 bits: "Oficial militar do Joseon do seculo XVI"
32 bits: "Humano do Leste Asiatico do seculo XVI"
16 bits: "Humano"
8 bits: "Entidade fisica"
A medida que a informacao e truncada, a especificidade e perdida, mas a classificacao mais fundamental sobrevive ate o fim.
Essa e uma implementacao em nivel de bits do principio de “degradacao graciosa”.
Mesmo que uma interrupcao de rede entregue apenas dados parciais, o sistema sabe “nao sei exatamente quem e, mas e pelo menos uma historia sobre um humano” e pode continuar raciocinando.
Um contorno borrado e melhor do que silencio total. Compreensao parcial e melhor do que falha completa.
Uma Consulta Se Torna um ID
A possibilidade mais intrigante que a indexacao semanticamente alinhada abre e esta: uma consulta em linguagem natural pode ser convertida em um SIDX temporario.
Um usuario pergunta: “Quem foi o general que derrotou a marinha japonesa durante a Guerra Imjin?”
O encoder analisa essa pergunta. Humano. Leste Asiatico. Seculo XVI. Relacionado ao militar. Montar esses atributos em bits produz um SIDX temporario.
Esse SIDX temporario varre os bilhoes de SIDXs no WMS. Entidades cujos padroes de bits sao mais similares sobem como candidatas. Yi Sun-sin, Won Gyun, Gwon Yul, Yi Eok-gi…
Cruzar informacoes detalhadas com esses candidatos produz a resposta final.
Isso unifica busca e vinculacao de entidades em um unico mecanismo. Nenhum motor de busca separado necessario. Nenhum pipeline de NER (Named Entity Recognition) separado necessario. Uma unica comparacao de SIDX e tudo o que e preciso.
Por Que Nao uma B-Tree?
Bancos de dados tradicionais usam indices B-Tree.
B-Trees sao excelentes para encontrar um valor especifico em dados ordenados em O(log n). Para “encontrar Q8492”, sao otimas.
Mas para “encontrar todas as entidades que sao humanas e originarias do Leste Asiatico”, sao fracas. Buscas de condicoes compostas requerem interseccao de multiplos indices, e o custo da interseccao cresce acentuadamente com a escala dos dados.
SIDX + varredura exaustiva SIMD adota uma abordagem fundamentalmente diferente.
Se uma B-Tree e uma lista telefonica que rapidamente responde “quem mora neste endereco”, uma varredura SIDX e um perfilamento que rapidamente responde “quem tem essas caracteristicas”.
A natureza da pergunta difere, e a estrutura de dados otima tambem.
| Tipo de Consulta | B-Tree | Varredura SIDX |
|---|---|---|
| Busca por ID especifico | O(log n), otima | Desnecessario (use um hash) |
| Filtragem de condicao composta | Requer JOINs, lento | Um AND bit a bit, rapido |
| Busca de entidade similar | Nao e possivel | Possivel via similaridade vetorial |
| Insercao | O(log n), rebalanceamento | O(1), append |
| Complexidade de implementacao | Alta | Baixa |
O WMS nao usa B-Trees. Ele carrega um bilhao de SIDXs na memoria e realiza uma varredura exaustiva com bitmasks SIMD.
Simples. Forca bruta. Rapido.
A Sabedoria de Huffman
A estrutura de alocacao de bits do SIDX segue o principio da codificacao de Huffman.
Na codificacao de Huffman, simbolos que ocorrem frequentemente recebem codigos mais curtos, e simbolos que ocorrem raramente recebem codigos mais longos.
No SIDX, a informacao de classificacao mais frequentemente necessaria ocupa os bits superiores, e detalhes raramente necessarios ocupam os bits inferiores.
O mesmo principio governa os prefixos de tipo de pacote desta linguagem. O Tiny Verb Edge de maior frequencia recebe o prefixo mais curto. O Event6 Edge de baixa frequencia recebe um prefixo mais longo.
A sabedoria de Huffman permeia cada camada deste design. Nenhum unico bit e desperdicado. O menor custo para a coisa mais importante.
Resumo
Um ID tradicional e um endereco. Um endereco nao sabe nada.
- Quando o ID nao carrega significado, voce precisa segui-lo ate os dados toda vez. Isso e um JOIN.
- Quatro JOINs em um bilhao de registros e lento.
- SIDX codifica significado diretamente no ID atraves do alinhamento semantico.
- Um unico AND de bitmask reduz um bilhao de registros a dez mil. Zero JOINs.
- 64 bits e suficiente. O ID nao precisa saber tudo – so precisa reduzir os candidatos.
- Como a informacao mais importante ocupa os bits superiores, o significado central sobrevive mesmo quando bits sao truncados.
- Converter uma consulta em linguagem natural em um SIDX temporario transforma a busca em uma operacao vetorial.
No momento em que um ID deixa de ser um endereco e se torna conhecimento, as regras do banco de dados mudam.