3
MrJ
4 min de leitura ·

🗜️Crompressor: A Fronteira Open Source: Eu Preciso da Ajuda de Vocês para Publicar (Zenodo/ArXiv) - Papel2-Tabnews

Esta é a terceira e última parte documentada por mim (por enquanto) da fundação do ecossistema Crompressor.
Se você acabou de chegar, entenda a base deste projeto lendo a Parte 1: A Ilusão da Compressão (O Triunfo P2P) e sinta o peso dos meses de desenvolvimento escovando bits com Go lendo a Parte 2: Jornada Insana de 30 Dias.

Hoje o foco não é exibir mais provas sobre código ou explicar algoritmos O(1). O foco hoje é humildade e senso de comunidade. O Crompressor virou um monstro Orquestrador que foge do controle de apenas um desenvolvedor solitário. Eu estruturei o repositório inteiramente, organizei o Git Submodules, mas esbarrei em uma parede e não sei como passar.

1. O Abismo Científico: Como Validar Pesquisa Fora da Faculdade?

Ao longo desta jornada documentada no GitHub, eu cheguei a escrever 7 papéis formais e técnicos (papers) abordando o Limite de Shannon, os teoremas da Distância de Hamming aplicados na memória Go, Vetorização Quantizada de matrizes brutas e os relatórios estritos das falhas de compressão isolada (V1 a V4) perante o Zstandard contra o esmagador êxito da Deduplicação de Borda P2P (99.4% em blocos de 4KB).

A questão dura é: Eu nunca publiquei absolutamente nenhum artigo científico na minha vida.
E eu não tenho filiação formal de uma universidade famosa atrelada ao meu e-mail. Eu estou querendo levar esse motor para ser testado criticamente na base do Zenodo ou nos pré-prints do ArXiv, plataformas globais onde a tecnologia séria e os doutores operam e testam papers. E eu peço socorro abertamente a essa comunidade que domina essas rotas:

  • Como é o processo de submissão do ArXiv/Zenodo no mundo real? Como funciona sem vínculo acadêmico?
  • Quais os formatos e jargões que as revistas exigem?
  • Como peço Endorsements (recomendações) justas sendo um engenheiro Open-Source do Brasil?

Ainda não decidi exatamente como organizar esses papéis na plataforma de publicação. Por isso, faço esse apelo público aos acadêmicos que assinam o TabNews: sejam meus guias e mentores nesse processo de Publishing. Eu tenho os dados, eu tenho o código, eu tenho o benchmark de 4KB gravado; só preciso de orientação sobre o protocolo acadêmico.

2. Conteúdo e Vídeos a Caminho (O Crompressor Visual)

Muitos pediram explicações mais interativas e provas irrefutáveis executadas na tela. Eu levo a usabilidade Open Source muito a sério.
Em breve (e com o aval das próximas pesquisas e estabilizações), eu pretendo gravar e disponibilizar publicamente vídeos e documentários técnicos mostrando exatamente, na prática:

  1. A tela dividida entre dois servidores virtuais instalados, trocando dados pesados instantaneamente via Cérebro CROM.
  2. Como auditar, testar e empacotar dados usando o nosso .cromdb na interface de linha de comando.
  3. Demonstrações reais da redução de tráfego (onde você verá o pacote original de 460MB voando pela rede na forma de 2 Megabytes).

Quero democratizar a matemática pesada com testes em vídeo rápidos e de linguagem simplificada, sem perder a densidade de bit que sustenta a engine.

3. O Convite Final e o "Call to Action"

Se você tem curiosidade de ver onde tudo isso está agrupado e organizado agora mesmo:
A cesariana foi feita e o código central consolidado com os submodules está aqui:
🔗 Repositório Orquestrador: github.com/MrJc01/crompressor-orquestrador
🔗 Comunidade CROM: crom.run/comunidade

No link da comunidade você encontrará nosso Discord e o grupo do WhatsApp. Podem me achar lá em ambos para conversarmos diretamente. Estou muito ansioso com tudo o que construímos, e espero o pior (testes brutais de estresse que quebrem tudo de novo) como um bom programador. :)

Se você entende as mecânicas obscuras do ArXiv, Zenodo, repositórios Peer-Review de CS (Computer Science) ou se você é pesquisador com tempo disponível: deixe seu comentário abaixo. Mande mensagens. Abram issues de colaboração no nosso GitHub da pasta papeis.

O mercado de tecnologia não evolui apenas fazendo chamadas na nuvem da AWS. Ele evolui reescrevendo infraestruturas em linguagens compiladas. E nós precisamos unir forças da base hacker e acadêmica para firmar essas tecnologias globais desenvolvidas internamente. Aguardo o socorro ou as pedradas nos comentários abaixo!

Carregando publicação patrocinada...
4

Estou um pouco atrasado, mas como já publiquei artigo científico em congresso BR (Qualis A3), acho que posso te dar minha visão

Sobre Orientação e Vínculo Acadêmico
Eu sugiro que você procure um orientador, ou seja, alguém que esteja dentro do meio científico. Sei que pode parecer complicado saber por onde começar, mas você não precisa estar matriculado para publicar; ter alguém vinculado a uma universidade faz TODA a diferença. O meio acadêmico, infelizmente, não é perfeito e o "quem indica" e o jogo de cartas marcadas ainda pesam. Com certeza existe algum professor de federal que vai se interessar pelo projeto; você seria o autor principal e ele o orientador.

Como achar esse orientador? (Networking de qualidade)
Cara, da para entra no Google Scholar, busca por termos que tenham a ver com o seu trampo (Data compression, P2P networks, sistemas distribuídos, Go language, etc.) e filtra pelos trabalhos mais recentes, ptbr etc.

  • Faz uma lista de uns 10 professores que publicaram algo relevante.
  • Começa a trocar ideia com eles. Manda e-mail ou procura no LinkedIn. Não chega pedindo favor, chega trocando figurinha: "Vi seu paper X, achei doideira, estou trabalhando nesse motor aqui e queria sua visão técnica".
  • Muitas vezes, esses caras vão tirar suas dúvidas, te dar um feedback ou dar um vacuo
  • Dica: É uma chance de ouro pra fazer networking. Tem uns verdadeiros crânios nas federais, eu conheci alguns e o nível é surreal.
    OBS: a Biblioteca Digital (SOL - SBC Open Lib) é um ótimo lugar para achar paper e emails dos professores/orientadores, vai ter q dar um stalkeade e tal. n sei ao certo qual seria a cadeira/disciplina, talvez ORI (organização e recuperação de informação) sei q tem congresso dessa matéria.

O Processo de Submissão
Hoje em dia, a maioria dos congressos usa o sistema JEMS. Você terá que criar uma conta, provavelmente com vínculo à SBC. O processo é o seguinte: você submete seu paper, ele é avaliado por pares e, se aprovado, você precisa pagar a inscrição para cobrir os custos do evento. Fora isso, ainda tem estadia e deslocamento por sua conta (é possível conseguir bolsa de apoio, mas no seu caso é improvável). (estou resumindo, existe pormenores, normalmente o orientador q ajuda nestas partes)

Como o Clacerda falou, foque em congressos que tenham a ver com o tema aqui no BR. Eu evitaria tentar um congresso internacional (Qualis A1) por hora; no futuro é outra história.

Escrita Científica e Formatação
Um aviso importante: os textos que você chamou de "papers" provavelmente não seriam considerados como tal no meio acadêmico. Eles estão mais para documentações técnicas típicas de .md. A estrutura de um artigo científico é bem diferente, exige uma linguagem mais robusta e formatação em .tex (tex é o santo graal, recomendo DEMAIS), vc q usa I.A vai preferir compilar ele local na IDE, é um pouco chato de instalar, usa a extensão LaTeX Workshop do James-Yu, mas tem instalar perl etc, procura tutorial yt) .

  • Dica de ouro: Aprenda a usar o Overleaf/latex. Escolha algum template da ACM (posso te enviar depois) — dá para usar direto no site ou compilar local na sua IDE.
  • O trabalho: A escrita é bem mais chata e difícil do que parece. Citar dezenas de artigos é o esperado. As LLMs ajudam muito, mas cuidado para o texto não ficar genérico; fica muito óbvio quando foi feito por I.A. se você não moldar o prompt/estrutura. Esse seu projeto daria um artigo bem denso e longo eu acho.

Resumão

  1. Busque um orientador vinculado a uma federal (crie essa rede de contatos, fale com quem já publica).
  2. Crie um ambiente em .tex (Overleaf ou na IDE) e aprenda a usar comandos como \cite etc etc.
  3. A escrita científica é muito específica. Recomendo assistir aos vídeos da Elsevier e "afiar o machado" antes de sair escrevendo, para evitar o retrabalho e o estresse que são típicos nessa fase.

Pretendo fazer uns posts futuros dando dicas mais detalhadas, mas sempre acabo enrolando, então qualquer coisa manda mensagem. Enfim, muito doq falei é meio obvio tbm, mas espero ter ajudado. Vlw flw!

att: Para achar papers para citar o caminho é o arxiv, cuidado tem muito artigo lixo lá, vc n quer citar artigos ruins e nem sequer perder tempo lendo eles, foque em pegar artigos de renomes (autores de grandes faculdades MIT etc, paper q são de congressos de peso. Existem algumas dezenas de congressos no mundo que são os mais relevantes da área, vc começa a vasculhar neles, normalmente é free o acesso, caso n consiga o pdf use o sci-hub site, mas o annas archive é melhor ainda, vc ja deve saber oq é ORCID e DOI.

1
4

Hey man,
Eu tentei ler o texto do post e acessei o site do crom tentando entender de que se tratava, depois eu acessei seus repositórios no github para obter mais algumas dicas que ajudassem a montar o quebra-cabeças.
Eu fiquei com a impressão que você tem bastante bagagem técnica (entende bastante de desenvolvimento de software) e que você está bem autoconfiante e empolgado com o projeto! Isso é bom! São recompensas da dedicação.
Eu acho que faltou foco. O escopo está muito amplo. Os usuários ficam perdidos porque tem bastante opção.
Eu acho que você devia escrever bastante codigo html-css-js para o chrome sem node nem nenhum server. Não sei bem explicar por que, mas acho que isso te coloca no ponto de vista do user e isso é importante.

1

Fala ae! Primeiro de tudo: muito obrigado pelo tempo que você investiu lendo o post, explorando o site e investigando os repositórios no GitHub para montar o quebra-cabeças. Isso tem um valor imenso para mim.

Sobre o seu feedback: você está coberto de razão.

Quando alguém entra no site hoje, a impressão é exatamente essa de "falta de foco". Tem o Crompressor (infraestrutura pesada em Go), tem o OmniFiles (gerenciador de arquivos), o Cromva (segundo cérebro), a linguagem Verbo, etc. Quem chega de fora toma um susto e pensa: "O que diabos esse cara está tentando vender?".

A resposta sincera é que a CROM não é um "produto" clássico de startup tentando resolver um problema único. É um laboratório Open Source focado num movimento de Soberania Digital. O ecossistema é amplo porque a intenção é criar uma "malha" de ferramentas para os desenvolvedores e usuários escaparem do aprisionamento das grandes Big Techs.

Sobre a sua sugestão excelente de "escrever bastante código html-css-js para o chrome sem node nem nenhum server para se colocar no lugar do usuário": É exatamente isso que norteia a fundação de grande parte das ferramentas da CROM!

Se você notar na seção "Ferramentas" e nos "MiniApps" do site, eles seguem rigorosamente esse seu conselho:

  • O P2PFile roda via WebRTC puro, transferindo arquivos direto pelo navegador sem passar por nenhum backend meu.
  • O OmniFiles é um gerenciador de arquivos universal que roda inteiramente client-side.
  • O Cromva e as ferramentas de conversão usam a filosofia "Local-First", processando mídias direto no browser do usuário sem uploads desnecessários.

Ou seja, eu concordo 100% com a sua visão. Colocar o poder de processamento diretamente no navegador do usuário (sem depender de um servidor nas sombras processando tudo) é a única forma de garantir a posse real do dado e a privacidade absoluta.

O Crompressor (a infraestrutura pesada em Go que motivou os posts) entra nisso como a fundação debaixo dos panos. Ele foi criado para que, no futuro, todas essas aplicações front-end possam conversar entre si de forma ultra-rápida via P2P Edge, sem precisarem gastar fortunas centralizadas na AWS.

Vou pegar o seu conselho e repensar urgentemente a porta de entrada (onboarding) do site. Preciso deixar a separação entre "o que é infraestrutura complexa" e "o que são ferramentas simples pro usuário" muito mais clara, para não causar essa sensação de metralhadora de projetos.

Valeu mesmo pelo feedback afiado e honesto!

4

O que você provavelmente quer descobrir agora é outra coisa: quais são as “casas naturais” do Crompressor.

Ou seja: quais comunidades, conferências, periódicos e workshops discutem a intersecção entre compressão, deduplicação e sistemas P2P.

Mesmo que você não submeta de cara, vale destrinchar esses lugares para entender como a comunidade fala, quais benchmarks usam, quais datasets, quais métricas, qual é o formato dos papers e quais trabalhos você precisa citar.

Eu começaria por aí: mapear 5/10 venues/papers próximos, ler a introdução/metodologia/avaliação deles e adaptar seus textos para esse idioma acadêmico. Não é só “publicar”; é entrar na conversa certa.

E sobre e-mail universitário não é pré-requisito. O que pesa mesmo é o trabalho estar bem escrito com metodologia reproduzível e claims calibradas.

O vínculo acadêmico facilita muito é o acesso às bases de publicações científicas, bibliotecas digitais e periódicos pagos.

Mas isso também tem caminhos. As universidades públicas permitem acesso local às bases dentro da própria biblioteca/campus. Às vezes basta ir até uma biblioteca dessas e acessar as bases IEEE, ACM, Springer, Elsevier através de uma máquina lá.

A parte mais importante talvez seja transformar “eu tenho um motor que funciona” em “eu tenho uma questão de pesquisa, uma hipótese e um experimento reproduzível”.

Depois que você fizer esse dever de casa provavelmente já vai saber exatamente quais pesquisadores poderiam te dar um endorsement justo.

E aí o caminho nem é chegar pedindo nada logo de primeira. O melhor é mandar um e-mail simples: “estou trabalhando nisso, acho que conversa com tal trabalho seu. Se tiver interesse de dar olhada". Pronto.

1

@clacerda, esse comentário vale mais do que muito tutorial de "como publicar papers". Obrigado de verdade.

Você acertou em cheio no ponto cego: eu estava focado em provar que funciona e pulando a parte de entrar na conversa certa. Mapear as venues, entender como a comunidade fala, quais benchmarks e datasets usam — isso muda tudo. É a diferença entre gritar sozinho e sentar na mesa certa.

Anotei tudo. Vou começar exatamente por aí: mapear 5-10 venues/papers próximos (USENIX FAST, ACM SIGCOMM, IEEE storage), ler a metodologia deles e adaptar a linguagem dos meus textos. E a dica do e-mail simples pros pesquisadores é ouro — sem pedir nada, só mostrar o trabalho e ver se conversa.

Vou seguir isso no tempo e ritmo que eu conseguir, mas a direção agora está mais clara. Valeu demais! 🤝

Qualquer ajuda ou apenas curiosidade, é bem vindo. https://crom.run/comunidade

4

Posso estar falando besteira, mas acho que isso vai abrir minha cabeça nos teste com modelos LLM. Fico inconformado com modelos bons dependerem de GPU.

O objetivo é rodar modelos pesados com mínimo de memória.

Cheguei em algumas opções:

Usar GGUF INT4 + Candle (Rust) para inferência otimizada
Ativar PagedAttention + KV quantization no runtime
Implementar offloading CPU/RAM para camadas não ativas
Considerar MoE (só ativa 10-20% dos parâmetros por token)

Para rodar "inteligência pesada" em CPUs simples, não basta comprimir pesos. É preciso mudar o paradigma de inferência. Alguma arquitetura que contorne o gargalo físico/matemático dos transformers tradicionais.

Quantizar para 4 bits reduz armazenamento, mas não muda o padrão de acesso à memória nem a complexidade algorítmica. O gargalo persiste. Mas ainda acho que é uma questão matemática pesada.

1

@bugzoid, você NÃO está falando besteira. Essa dor é real e é exatamente o problema que estou atacando em 4 repositórios satélites do Crompressor. O comentário que você fez me motivou a publicar essa pesquisa que estava no laboratório.(crompressor-semantico)

A tese que defendo é: quantizar pesos para 4 bits é o começo, não o fim. Como você mesmo disse, reduz armazenamento mas não muda o padrão de acesso à memória. O que eu fiz foi levar os conceitos do Crompressor (Codebook, LSH, XOR Delta) direto pra dentro da inferência neural. Alguns resultados reais:

  • Codebook como substituto de tensores: No MNIST, treinar APENAS o codebook do Crompressor (em vez dos pesos individuais) atingiu 97.56% de accuracy com 40.8x menos parâmetros. Com K=256 chegou a 98.08% — superando o baseline de pesos Float32.
  • KV Cache via Codebook: No GPT-2 rodando numa Tesla T4, comprimir o KV Cache com ponteiros CROM deu 94.2% de redução real de memória.
  • CROM-Chat (Pesquisa 9): Uma LLM generativa experimental rodando inferência inteira em Go puro, CPU only, zero dependência de GPU. Usa uma arquitetura inspirada no LLaDA (difusão bidirecional) com RAG via LSH. Está crua ainda, mas roda e gera texto em milissegundos.

A ideia central: em vez de quantizar e torcer para caber na RAM, usar o Codebook do Crompressor como espaço de aprendizado — os pesos não são floats, são ponteiros O(1) para padrões num dicionário. Isso muda o paradigma de acesso à memória, que é exatamente o gargalo que você identificou.

Os repos onde essa pesquisa vive:

Essa pesquisa não está pronta — está viva. Mas os números não mentem. Valeu por levantar esse ponto! 🔬