Autor: Márcio M. Carvalho Período do estudo: Dezembro 2025 – Junho 2026 Hardware de referência: NVIDIA GeForce RTX 3060 12 GB · Python 3.13 · NumPy · CuPy/CUDA · Pillow Cobertura de testes: 128+ testes automatizados verdes, correção exata como portão antes de cada medição Natureza deste documento: relatório técnico de demonstração — cada afirmação é acompanhada do método e do número medido Estado do repositório: à frente do preprint publicado (Zenodo v1, DOI 10.5281/zenodo.20821058) — a §10 adiciona quatro protótipos usáveis (memória de agente, observabilidade, checkpoints de modelo, anotações adversas) ainda não numa versão publicada do Zenodo
Bits Hierárquicos (BH) começou como uma hipótese de Dezembro de 2025 (“o byte é uma árvore implícita; hierarquia é interpretação”). Este estudo testou a hipótese em nove ângulos independentes, com medições reais e baselines honestos. O resultado não é “um codec melhor” — é a delimitação precisa de um paradigma:
O BH NÃO comprime sinal denso melhor que JPEG/WebP/AVIF (perde — medido).
O BH É um ENVELOPE ESTRUTURAL que:
(a) torna a estrutura explícita a custo baixo (0–6% do arquivo — medido),
(b) roteia o resíduo de cada região ao especialista certo (orquestração),
(c) oferece múltiplas leituras sobre a mesma estrutura (preview/ROI/prova).
Resultado-âncora (medido): um documento estruturado gravado no formato orquestrado é 2,1× menor que o WebP E permite ler qualquer região por 3–55× menos bytes, no mesmo arquivo — algo que nenhuma ferramenta SOTA oferece junto.
A lei transversal (medida em todos os ângulos): o BH rende exatamente na medida em que o dado é estrutura (gerado por regra, composto, hierárquico) e não sinal (ruído/perceptual). No limite, o payload vira um programa que gera o dado (ganhos de milhares×); a fronteira não é a entropia — é o reconhecimento da estrutura.
Enquadramento conceitual (adicionado após este estudo). Uma varredura
posterior de 20 domínios (applicability/) reformulou o BH de formato de
arquivo para propriedade de representação — a First-Class Interpretation
Representation (FCIR): interpretações rivais mantidas como entidades de 1ª
classe, co-registadas sobre um substrato imutável, sem adjudicação forçada. A
economia de substrato-partilhado que este estudo mede é real mas já é SOTA maduro
na maioria dos domínios; a nossa varredura identificou a FCIR (um nome de
trabalho) como a propriedade que melhor distingue o BH dos domínios avaliados —
um resultado, não uma verdade universal. Ver BH_PRINCIPLE.md.
Toda a investigação seguiu quatro regras, aplicadas sem exceção:
1.1 Declarar antes de medir. Cada terreno definiu alegações falsificáveis com critério de sucesso E de fracasso ANTES da medição. Nenhum número foi prometido a priori.
1.2 Correção como portão. Antes de qualquer comparação de desempenho, a correção exata foi verificada (reconstrução bit-a-bit, igualdade de agregados, prova criptográfica válida). Desempenho só se mede sobre resultado correto.
1.3 Baseline honesto, com a distinção vs-ingênuo / vs-SOTA. Números grandes contra baselines ingênuos (varredura completa, transmitir tudo) são marcados como tais e distinguidos de ganhos contra o estado da arte (WebP, HNSW, OLAP).
1.4 Medição real, autocorreção pública. Usou-se hardware real (RTX 3060,
CUDA events, nvidia-smi dmon). Quando uma medição estava enviesada a favor da
hipótese, foi corrigida em público. Três autocorreções materiais ocorreram e
estão documentadas (§7) — elas são parte da evidência de rigor.
A pergunta inicial — “o BH é um codec melhor?” — foi respondida, medição após medição, com não. A pergunta correta só emergiu no fim da investigação: “o BH é um orquestrador estrutural de representações?” — e a resposta é sim. A chave foi uma separação que resolve a confusão de metade do estudo:
PROBLEMA DO RESÍDUO ≠ PROBLEMA DO PARADIGMA
Tentar comprimir o resíduo (sinal denso) é o problema dos codecs especialistas — e o BH perde nisso. O paradigma do BH é a estrutura, o pertencimento e as leituras. Separadas, cada metade tem veredicto honesto e oposto.
Método: codec quadtree com seleção de interpretação por nó (LEAF/RAMP/DCT), comparado contra PNG/JPEG/WebP em frames 4K, com PSNR casado.
Medições:
Conclusão do terreno: como compressor, o BH perde. O ganho de 48× no gradiente era um canto (conteúdo perfeitamente procedural), não a regra.
Método: árvore de agregação (min/max/sum/count por nó) sobre 1.000.000 de linhas; métrica = linhas lidas; baseline = varredura plana.
Medições:
| query | BH lê | plano lê | ganho | vs |
|---|---|---|---|---|
| SUM global | 0 | 1.000.000 | ∞ | ingênuo |
| SUM range 10% | 1.564 | 99.868 | 64× | ingênuo |
| COUNT chave 2% | 2.048 | 1.000.000 | 488× | ingênuo |
| COUNT valor correlacionado > p99 | 92.736 | 1.000.000 | 11× | ingênuo |
| eixo errado / valor independente / pouco seletivo | ~10⁶ | 10⁶ | 1–2× | fronteira |
Materialização de interpretação: filtro por região (não agregada) lia tudo (1×); com um contador por região no nó → leitura de raiz, 0 linhas (∞) — ao custo de armazenamento que escala com a cardinalidade.
Honestidade: os ganhos são enormes vs varredura ingênua, mas o mecanismo (resumo pré-computado) já é estado da arte (zone-maps, OLAP, materialized views).
Método: árvore de Merkle (SHA-256, domain separation) sobre 1.048.576 itens; gate de correção cripto (prova válida verifica, forjada falha) antes de medir; métrica = bytes/nós.
Medições:
| tarefa | BH lê | baseline ingênuo | ganho |
|---|---|---|---|
| commitment de 1M itens | 32 B (1 hash) | 33,5 MB | 1.048.576× |
| prova de pertença | 644 B (20 hashes) | 33,5 MB | 52.103× |
| localizar adulteração | 40 nós | 1.048.576 re-hashes | 26.214× |
A prova cresce com log n (1k → 10 hashes; 1M → 20). Honestidade: é a construção padrão de Merkle (blockchain/git/CT); o estudo mostra a unificação com os outros terrenos, não inventa cripto.
Método: quadtree-união sobre camadas co-registradas (RGB+profundidade+ segmentação); gate de reconstrução lossless por camada; medição de estrutura-partilhada vs K árvores independentes.
Medições:
Método: medição de movimento de dados (simulação) e tempo de parede real
(CUDA events, RTX 3060), com a carga visível por nvidia-smi dmon.
Medições:
Extrapolação (banda publicada, NÃO medida): o ganho de lote é invariante de hardware (~1.755× da 3060 à B200 — algorítmico, ambos escalam com a banda); o ganho de consulta única encolhe em placas rápidas (992× → 45×), porque o piso de lançamento de kernel é fixo.
Modelo de hardware nativo (projeção rotulada, não medição): com o piso a nível de latência de memória (0,3 µs, físico) em vez de lançamento (2,8 µs, software): latência single 9.747×, lote 5.702× (build near-memory), energia ~1.755× menos (∝ dados movidos — robusto, independe do valor pJ/B).
Honestidade: os números grandes são vs varredura ingênua; o mecanismo (agregado pré-computado) é técnica padrão (OLAP/materialized views). A GPU prova que a face de leitura é real e rápida em hardware; não é um produto isolado.
Método: substrato unificado (estrutura + embeddings) vs pilha costurada (storage + HNSW + cache + índice espacial), sobre ativo co-registrado.
Medições (storage, fatia 1):
| d (embedding) | unificado vs costurado |
|---|---|
| 8 | 4,0× (ganha) |
| 128 | empate |
| 256 | 0,86× (perde) |
| 768–4096 (IA real) | perde |
Autocorreção (embedding progressivo / Matryoshka): ao tratar o embedding como infraestrutura compressível (não payload irredutível) — prefixo no nó interno em vez de full-d — o veredicto move: d=256 → 1,06×, d=1024 → 1,02×, d=4096 → 1,00× (empata). O bulk (embedding de folha) é empate de Shannon; o ganho fica no índice.
Medições (acesso, fatia 2): preview 7,6× · agregado 3,2× · ROI 2,1× · retrieval escopado estreito 1,4× · retrieval largo 0,23× (perde).
Decomposição de dívida arquitetural (stack RAG real): a dívida eliminável é 14–49% (borderline), dominada pela duplicação dos embeddings (payload denso), não pela estrutura. Conclusão: storage de IA densa não é o terreno do BH.
Método (composicional): dado simbólico — conceitos como equações de primitivos partilhados — representado como envelope algébrico vs vetor denso.
Medição: 384× menor (8 MB vs 3,07 GB para 1M conceitos), e responde consultas estruturais (“quais conceitos usam o primitivo X?”) que o vetor denso não consegue formular.
Método (densidade real): dimensionalidade intrínseca de embeddings reais (modelo all-MiniLM-L6-v2, 6.000 palavras PT, PCA).
Medição: 90% da variância em 160 de 384 dimensões (~2,4× compressível). Honestidade: isto é compressibilidade linear (já explorada por PCA/PQ/ Matryoshka), não composicionalidade simbólica. O dado real de linguagem, na geometria do embedding, não é composicional-simbólico — é um subespaço de dimensão média. O 384× vale para dado que é composição; o quanto do mundo real é composicional permanece a aposta em aberto (do domínio simbólico).
Método: o cabeçalho carrega o programa que gera a região (não o resultado); o decoder executa o programa. Teste de generalidade (várias famílias) + ruído + custo escondido.
Medições:
| família gerada por regra | WebP | programa | ganho |
|---|---|---|---|
| anéis | 37,8 KB | 13 B | 2.904× |
| ondas | 46,4 KB | 13 B | 3.572× |
| xadrez | 2,4 KB | 3 B | 809× |
| gradiente | 2,1 KB | 1 B | 2.096× |
Sob ruído (base procedural + ruído α): o programa-aware mantém a vantagem da estrutura em todos os níveis de ruído (subtrai a base conhecida; o WebP-todo paga pela estrutura que não sabe separar). Custo escondido (declarado): o encoder precisa descobrir o programa — o problema inverso, trivial para família conhecida, indecidível em geral (complexidade de Kolmogorov é incomputável). A fronteira do BH não é a entropia do resíduo — é o reconhecimento da estrutura.
Método (orquestração): o BH roteia cada região ao especialista local (plano→constante, gradiente→fórmula, texto→PNG, foto→WebP), comparado contra um-codec-no-todo, em dois conteúdos.
Medições:
| conteúdo | WebP-todo | orquestrado | resultado |
|---|---|---|---|
| foto-pesado | 10,7 KB | 10,8 KB | 1,01× (empata) |
| documento (formas fechadas) | 4,8 KB | 2,2 KB | 2,1× menor |
Dividir em WebP por região (sem rotear paradigmas) perde (1,10×) — o ganho vem do roteamento cross-paradigma, não do corte.
Método (custo do envelope): decomposição dos bytes do BH em framing / estrutura explícita / resíduo. Medição: estrutura explícita = 0–6% do total (3 imagens). O cabeçalho inteligente é barato; o caro era o resíduo (que agora se delega). Responde a “pergunta matadora”: tornar a estrutura explícita custa muito pouco.
Método (a união): documento gravado como .bh, medindo no mesmo arquivo as
duas faces.
Medições:
WebP/AVIF → resíduo ótimo, leitura ÚNICA
PDF → orquestra especialistas, mas lista plana, sem leitura seletiva
OLAP/GPU → leitura seletiva, mas não é formato de representação
.bh → as DUAS faces + hierarquia + pertencimento, num envelope só
A hierarquia rende quando a ESTRUTURA domina o custo, não o SINAL denso.
No limite: payload → PROGRAMA que gera o dado, na medida em que o dado é
gerado por regra. A fronteira não é a entropia — é o reconhecimento da estrutura.
| classe de dado | resultado medido |
|---|---|
| procedural / fórmula | programa minúsculo: 800–3.600× (decode-programa) |
| composicional / simbólico | envelope 384× menor + consultas que o denso não faz |
| estruturado heterogêneo | orquestração 2,1× + leitura seletiva 3–55× |
| agregável / reusado | leitura seletiva ∞–488× (banco), 1.750× (GPU) |
| co-registrado + redundante | wafer+temporal 2,13× (filme) |
| denso / perceptual (foto, áudio, embedding) | perde ou empata — território do conexionismo |
O BH não é um codec — é um orquestrador estrutural. Duas faces, medidas:
A união das duas faces num envelope (2,1× menor E navegável) é o que nenhuma ferramenta SOTA entrega. O valor não está no bloco comprimido — está na estrutura que sabe o que aquele bloco significa.
Três escalas onde o BH sobrevive ao escrutínio:
- "Ganha pelo motivo certo" ≠ "achámos o produto". É validação científica; o
produto exige construção e adoção (engenharia, não benchmark).
- O orquestrador compete com o PDF (incumbente), não com o WebP. Seu diferencial
— hierarquia + leituras múltiplas — é real mas não-provado como necessidade de mercado.
- Os números grandes da face de leitura são vs INGÊNUO; vs SOTA, empatam. O
diferencial é a UNIÃO das faces, não um número isolado.
- O decode-programa exige RECONHECER a estrutura (problema inverso): trivial para
família conhecida, indecidível em geral.
- A casa do BH é dado ESTRUTURA-DOMINANTE; em sinal denso o conexionismo reina,
e o BH o DELEGA — não o enfrenta.
- Um formato morre sem ecossistema. O caminho não é um `.bh` genérico a competir
com Parquet/PDF; é construí-lo nativo num domínio greenfield que já precisa dele.
Três medições foram corrigidas em público quando se mostraram enviesadas:
O BH não inventa as técnicas que usa — ele as unifica. Cada capacidade isolada já existe e é madura; a contribuição é reuni-las num envelope estrutural único. Situamos aqui as quatro famílias de prior art.
Codecs adaptativos por bloco. O JPEG (Wallace, 1991) estabeleceu o modelo “transformada + quantização + entropy coding” com uma base global fixa (DCT). Codecs modernos — AV1/AOMedia (Chen et al., 2018), VVC, JPEG XL — fazem mode decision por bloco, escolhendo modos de predição/transformada por região. O BH-codec compete diretamente nisto e perde (§3.1): falta-lhe a maquinaria de entropy coding, e a seleção por região é o que o AV1 já faz. A diferença do BH não é compressão — é delegar a região ao especialista (§3.9).
Estruturas de leitura seletiva. A leitura “ler o resumo, não os dados” é a base de OLAP/data cubes (Gray et al., 1997), zone-maps e estatísticas por row-group do Apache Parquet, e materialized views. Os ganhos de §3.2 e §3.5 (banco, GPU) são exatamente este mecanismo — enormes contra varredura ingênua, mas já estado da arte. Reconhecemo-los como âncora de credibilidade, não novidade.
Estruturas autenticadas. A face de verificação (§3.3) é a árvore de Merkle (Merkle, 1987), base de Git, Certificate Transparency (Laurie, 2014) e blockchains (Nakamoto, 2008). Não inventamos cripto; demonstramos que a prova-de-Merkle é a mesma leitura-por-objetivo-sobre-hierarquia dos outros terrenos.
Representação compacta e dado-como-programa. Para embeddings, a compressibilidade que §3.6/§3.7 exploram é Product Quantization (Jégou et al., 2011) e Matryoshka Representation Learning (Kusupati et al., 2022); a busca vetorial é HNSW (Malkov & Yashunin, 2018). O “decode-programa” de §3.8 é a direção da complexidade de Kolmogorov (Kolmogorov, 1965; Li & Vitányi) e tem precedente direto no PostScript (página-como-programa, Adobe) e na geração procedural. Formatos auto-descritivos (HDF5, Protocol Buffers, PDF/ISO 32000) provam que “dado que carrega a própria estrutura” funciona.
A lacuna que o BH ocupa. Nenhum destes unifica representação + leitura seletiva + orquestração de especialistas + hierarquia/pertencimento + provas num único envelope. PDF orquestra mas é lista plana sem leitura seletiva; OLAP navega mas não é formato de representação; AV1 adapta por bloco mas com uma família de modos só. A contribuição do BH é a união, não os componentes.
codec X:\bitH\ py -m pytest tests -q · src/bench/{harness,headtohead,portfolio,
heterogeneous,cost_envelope,orchestrate,union}.py
banco X:\bitH\db\ py -m pytest tests -q · src/bench/harness.py
merkle X:\bitH\merkle\ py -m pytest tests -q · src/bench/harness.py
wafer X:\bitH\wafer\ py -m pytest tests -q · src/bench/{harness,film}.py
gpu X:\bitH\gpu\ py -m pytest tests -q · src/bench/{real_gpu,heavy_gpu,extrapolate,native_model}.py
multimodal X:\bitH\multimodal\ src/{probe,fatia2,probe_progressive}.py
composic. X:\bitH\compositional\ {probe_compositional,real_density,decode_program,program_test}.py
dívida X:\bitH\architecture_debt\ debt_decomposition.py
Python: X:/miniconda3/python.exe (NumPy, Pillow, hashlib, CuPy/CUDA, sentence-transformers, sklearn)
Relatórios brutos por terreno: RESULTS_*.md em cada pasta.
O estudo testou Bits Hierárquicos em nove ângulos independentes, com método declarado, correção como portão, baselines honestos e autocorreção pública. O veredicto:
O BH não é um codec melhor — é uma forma diferente de organizar e ler dados estruturados. Onde o dado é estrutura (gerado por regra, composto, hierárquico, agregável, co-registrado), o ganho é real e por vezes de ordens de grandeza, e a sua forma mais profunda é o payload virar o programa que gera o dado. Onde o dado é sinal denso (foto, áudio, embedding), o conexionismo reina, e o papel do BH é delegar ao especialista — não competir. A contribuição única não é um número isolado; é a união, num envelope só, de representação enxuta, leitura seletiva, hierarquia e pertencimento — que nenhuma ferramenta atual oferece junta.
A prova final não é mais um benchmark; é a construção do formato num domínio onde estrutura e pertencimento importam tanto quanto o tamanho.
A construção já não é um passo, mas quatro, e todos partilham um envelope — prova de que o paradigma generaliza entre domínios. Cada um é uma biblioteca Python com demo medida e testes; cada um lê só a fração que a consulta pede, em bytes reais lidos do arquivo.
bhmem — memória de agente. O agente grava memórias estruturadas
(fato/evento/relação + tempo + tópico + proveniência); o formato as expõe pelas
múltiplas leituras.
| leitura | o que devolve | bytes lidos | vs store plano (lê tudo) |
|---|---|---|---|
summary() |
resumo de todos os tópicos | 2,5% | 35× menos |
recall(tópico) |
as memórias de um ramo | 4,0% | 22× menos |
since(t) |
memórias da janela temporal | 9,8% | 9× menos |
provenance(id) |
fonte+caminho de 1 memória | 10,8% | 8× menos |
(Demo: ~90 dias, 60 tópicos, 2 250 memórias; 9/9 testes verdes.)
bhtrace — traces distribuídos (observabilidade). Um trace é uma árvore
(trace → spans → eventos); a estrutura é o índice, os atributos pesados (SQL,
stack traces, headers) são o resíduo.
| leitura | o que devolve | vs store plano |
|---|---|---|
summary() / critical_path() |
o esqueleto sem o payload | 9× menos |
subtree(span) |
um drill-in | 9× menos |
service(name) |
um serviço | 5× menos |
(Demo: trace de checkout com 269 spans, pesado em atributos; 9/9 testes verdes.)
bhckpt — checkpoints de modelo. Um checkpoint é uma hierarquia
(modelo → camadas → tensores → experts); os pesos dominam, a estrutura é minúscula.
| leitura | o que devolve | vs checkpoint plano |
|---|---|---|
summary() |
arquitetura de um modelo de 16 MB lida em 9 KB, sem pesos | 1 779× menos |
expert(i, e) |
carregar um expert MoE sem a mistura | 20× menos |
layer(i) / tensor(name) |
uma camada / um tensor | 12× / 10× menos |
(Demo: transformer de 4 camadas, 2 camadas MoE × 6 experts, 16,2 MB; 8/8 testes verdes.)
bhanno — anotações adversas (a matriz de interpretações adversas). A forma
mais forte das “múltiplas leituras”: o mesmo substrato gravado uma vez, com K
anotadores a colocar camadas co-registadas que discordam. O wafer (§3.4)
generalizado de camadas aditivas para camadas rivais.
| leitura | o que devolve | resultado |
|---|---|---|
| armazenamento | K interpretações rivais vs K cópias independentes | 4,6× menor (5 anotadores) |
adjudicate() |
maioria + concordância, lendo só os labels (sem substrato) | 11× menos que o full |
item_views(id) |
todas as K interpretações de um item (a matriz) | 23× menos |
(Demo: 200 itens, substrato de 6 KB cada, 5 anotadores; 62% de concordância, 75 contestados; 9/9 testes verdes.)
Fronteira honesta, a mesma nos quatro: o BH ganha no acesso estrutural e
delega o resíduo denso (busca full-text → índice invertido; quantização
por-tensor → o seu especialista; recall semântico denso → um índice vetorial).
No bhckpt, a leitura seletiva por-tensor já existe (safetensors) — essa é a
âncora; o novo é a união (hierarquia incluindo o expert MoE como leitura de
1ª classe, roteamento por-tensor, uma face Merkle para proveniência). No
bhanno, o envelope expõe o conflito; não decide quem tem razão.
Isto não são mais ângulos medidos — é a tese virando ferramentas, o mesmo
envelope provado em quatro domínios. O ganho escala com o quanto o dado é
estrutura-dominante — a lei transversal da §4. Ver os READMEs (bhmem/,
bhtrace/, bhckpt/, bhanno/).
“O valor não está no bloco comprimido. Está na estrutura que sabe o que aquele bloco significa.”