Eu me frustrei com resultados medianos de RAG no início (GPT-3.5, libs Python, vetores “mágicos”). Resolvi atacar UX, performance e previsibilidade: escrevi um banco vetorial em Rust, medi tudo (benchmarks públicos), padronizei o pipeline (BM25 + HNSW + SQ-8 + chunks 200–500 tokens) e empacotei com APIs REST/MCP/UMICP. Resultado: busca precisa, latência estável e setup zero dependências externas. Hoje o Vectorizer já conversa com o Transmutation (converter PDF/DOCX/XLSX/HTML/áudio/vídeo → Markdown), e está pronto para virar a “espinha” de RAG, MoE e treino incremental.
Antes de tudo: contexto
Programo há 20+ anos. No boom de IA, meu “starter pack” foi GPT-3.5, um pouco de TensorFlow, modelos de STT e análise semântica. Funcionava… mas não era confiável.
O jogo virou com o Cursor somado a Claude-3.7/4, Grok-Code-Fast-1, Opus e GPT-5 — passei a entregar ordens de grandeza mais rápido. No fim de 2024, integrei LangChain ao meu framework e comecei a usar Qdrant, Pinecone, Neo4j e pgvector. Sem um “reasoning” consistente e com UX frágil, os resultados foram ruins.
Quando mergulhei nos MCPs, ficou óbvio: a dor era UX + previsibilidade. E performance.
Por que Rust e não “o combo Python + GPU”?
Queria previsibilidade de latência, controle fino de memória e binários enxutos.
O ecossistema Python é ótimo para pesquisa, mas para produção (especialmente em edge/on-prem) eu queria outra curva de custo/manutenção.
Em Rust, mesmo sem saber Rust no início, consegui “brigar” de igual pra igual com soluções prontas — e medir tudo, sem “magia”.
O que eu testei (e por que mudei de rota)
Avaliei diversos embeddings e medidas de similaridade: TF-IDF, BM25, BERT, SVD, MiniLM, Bag-of-Words, Char n-gram, ONNXs como:
sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2intfloat/multilingual-e5-small,intfloat/multilingual-e5-basesentence-transformers/paraphrase-multilingual-mpnet-base-v2Alibaba-NLP/gte-multilingual-basesentence-transformers/distiluse-base-multilingual-cased-v2,LaBSE
Conclusão prática: a melhora real desses embeddings (no meu cenário) não justificava a complexidade operacional. Voltei ao BM25 (implementação nativa em Rust), normalizei o pipeline e foquei no índice.
Benchmarks públicos (com reprodutibilidade)
Dimensões de vetores & memória/qualidade
https://github.com/hivellm/vectorizer/blob/main/benchmark/reports/dimension_comparison_20251001_201620.mdOperações básicas (insert/update/search)
https://github.com/hivellm/vectorizer/blob/main/benchmark/reports/core_operations_20251001_193533.md
→ 4.6k ops/s insert e 2.3k ops/s update (projeto com <30 dias, 100% gerado por IA, zero código manual).Escala e degradação do índice
https://github.com/hivellm/vectorizer/blob/main/benchmark/reports/scale_benchmark_20251001_203703.md
→ A partir de 10k vetores/coleção, multi-index (por collection split) mantém a performance.Quantização (SQ-8)
https://github.com/hivellm/vectorizer/blob/main/benchmark/reports/quantization_benchmark_20251001_202454.md
→ ~4× menos memória com perda mínima de qualidade.
A fórmula que funcionou
HNSW + BM25 (512D) + Quantização SQ-8 + Chunks 200–500 tokens
HNSW como índice principal (rápido e consistente).
BM25 512D (representação “clássica”, simples e previsível).
SQ-8 para cortar memória mantendo qualidade.
Chunking disciplinado (200–500 tokens) para melhorar recall/precisão sem verborragia.
Essa combinação, empacotada como MCP, deu acerto cirúrgico nas buscas dentro do Cursor — inclusive com modelos locais (LM Studio, GPT-OSS-20B) me retornando os trechos corretos de projetos vetorizados.
UX > tudo: por que senti diferença na prática
Auto-mapeamento de dados locais de projetos de software.
Collections segmentadas (e fácil migrar para multi-index por collection >10k vetores).
Setup zero dependência externa (sem “traga seu modelo x, y, z”).
REST, MCP e UMICP já prontos, com um dashboard simples pra testar.
O Vectorizer não é “só um índice”: é runtime de contexto que orquestra ingestão, chunking, index e consulta de forma opinionada.
Transmutation: o “irmão” que faltava
Em 13/10 adicionei o Transmutation (feito literalmente em 1 dia com ajuda do Cursor + Vectorizer):
Converte PDF, DOCX, XLSX, HTML (e mais) para Markdown consistente.
OCR (Tesseract) + STT (Whisper) para áudio/vídeo → Markdown.
Integração direta com o Vectorizer (ingestão → chunking → index).
Repo: https://github.com/hivellm/transmutation
Próximos passos:
Embeddings de imagem (coleções “vision” para LLMs multimodais).
CUDA/Metal/Vulkan nativos para o índice (GPU).
Projeto em Rust para manipular VRAM + shaders (core GPU-native).
Onde chega: RAG, MoE e treino incremental
RAG confiável (contexto “mínimo suficiente” com latência previsível).
MoE: collections como especialistas (roteamento por domínio).
Treino incremental: usar o Vectorizer como memória persistente de fatos/snippets.
Persistência de contexto quase “infinita” — minhas contas indicam ~11 bilhões de tokens numa máquina comum com 32GB RAM, sem GPU e sem API.
Quer testar?
Repo do Vectorizer: https://github.com/hivellm/vectorizer
Setup simples, binário Rust.
APIs REST, MCP e UMICP embutidos.
Dashboard provisório para explorar collections e consultas.
Benchmarks públicos e reprodutíveis.
O projeto está pré-alpha (inevitáveis bugs), mas já uso diariamente e os resultados têm sido excelentes.
Conclusão
Em poucos dias, com Rust + disciplina de benchmark + foco em UX, saí de RAG inconsistente para um motor vetorial que me atende agora — e que já está puxando Transmutation, GPU nativa e vision embeddings.
Se RAG/MoE é parte do seu stack e você quer previsibilidade e custo sob controle, experimenta o Vectorizer. Pior cenário: você mede e descobre exatamente onde dói. Melhor cenário: você para de sofrer com o “hype pipeline” e volta a entregar.