The Weekly Plaiground - 2026.07.21

This past week surfaced up benchmarking and more benchmaring. The GigaOm Radar for Vector Databases V3 set the backdrop along with some blog posts from Qdrant and Elastic on benchmarking. The Gigaom report, with 17 databases evaluated, is the biggest evaluation in sometime. I enjoyed the benchmarking revealed a lot of the underlying considerations for performance in constraints.

NVIDIA release Nemotron-3-Embed-1B, a pruned-and-distilled embedding model that meaningfully outperforms its own prior 1B-class models on multilingual retrieval benchmarks (again benchmarks!) the embedding layer is getting harder to justify building in-house. Alibaba’s Zvec hit v0.6.0 with a headline fix that makes INT4 quantization actually viable (recall jumping from 0.21 to 0.71), which matters for anyone running high-volume similarity search under memory constraints. And on the ingestion side, OpenCrawling surfaced as a framework worth watching for teams that have hit the wall on enterprise RAG security specifically the “Security issue”, ACLs.

This is where we are headed:

1. The embedding model is commoditizing,

2. the vector store is getting cheaper to run,

and the hard unsolved problem is still getting trusted enterprise content into the pipeline without blowing up your security model. This is where my past interesting work has been.

Happy Birthday Bob, Liza, Michelle,

Michael

• Nvidia details its next-generation Vera CPU for AI, setting up challenge to AMD and Intel (CNBC)

• Elastic Releases 9.3.7 (Blog)

• GigaOm Radar for Vector Databases V3 has been released - (Vespa)

Full disclosure: I recently joined the OpenCrawling core steering team as Lead Architect — take that context for what it's worth.

The problem OpenCrawling is trying to solve is real and largely unsolved in the open-source space: most enterprise RAG pipelines strip ACLs at ingestion time and reconstruct permission logic downstream, if at all. OpenCrawling treats that as an architectural defect, not an integration problem. Built by Piergiorgio Lucidi on Java 25, Spring Boot 4, and Virtual Threads, it’s a data federation engine that maps document-level access controls directly into the vector store at write time — so the security boundary follows the document, not the query session. The Open Ingestion Standard (OIS) at its core defines a connector contract targeting pgvector, Elasticsearch, and Qdrant as downstream writers, with Alfresco and SharePoint as initial source connectors. The roadmap I’m helping drive adds Kafka-decoupled embedding worker pools and multi-tenant vector store isolation.

• ACL propagation at ingestion, not query time: Rather than post-filtering retrieval results, OpenCrawling maps source ACLs — including Alfresco’s group and permission model — to vector store metadata at write time, so an LLM prompt only ever surfaces context the requesting user is actually authorized to see.

• Open Ingestion Standard (OIS) as a connector contract: OIS defines the wire format and metadata mapping spec that both source connectors and vector writers must implement — the extensibility hook is the standard itself, not a plugin API, which is an unusual and potentially durable design choice for multi-vendor interoperability.

• BPMN 2.0 workflow narrativization: The OIS has been extended beyond static documents to extract historic BPMN process instances from APS/Activiti, flatten them into semantic text chunks, and make process history queryable via natural language — “why was this invoice rejected?” becomes a RAG query against structured workflow audit data.

• Java 25 Virtual Threads as the concurrency model: The choice to build on Java 25 Virtual Threads rather than reactive frameworks is intentional — the embedding clustering architecture uses a thread-per-document model that’s straightforward to reason about and scales horizontally via Kafka consumer groups rather than requiring reactive programming expertise from contributors.

• Early-stage but architecturally principled: The project is pre-1.0 and the connector surface is narrow today (Alfresco connector is the first production-grade release). Teams evaluating it should weight the architectural approach — ACL-first ingestion, OIS as a standard — more heavily than current connector breadth

Read More at OpenCrawling

NVIDIA dropped this one last week (July 16) and it warrants attention. Nemotron-3-Embed-1B is a dense retrieval embedding model that NVIDIA derived from their 3B-parameter embed model through two rounds of structured pruning and distillation via their ModelOpt NAS toolchain, essentially compressing a larger model down to ~1.14B parameters while chasing the performance envelope hard. The result is a multilingual retrieval model covering 34 languages, outputting 2048-dimensional vectors with a 32k token context window, targeting RAG and semantic search workloads. On the RTEB benchmark it scores 72.38 NDCG@10,a meaningful jump over NVIDIA’s own prior 1B-class models which sat in the 60-62 range.

• Pruning over pretraining: The model wasn’t trained from scratch, it’s a structurally pruned and distilled derivative of Nemotron-3-Embed-3B, with NAS-guided architecture search doing the heavy lifting.

• Benchmark numbers hold up: RTEB 72.38, MMTEB Retrieval 71.05, ViDoRe-V3 text 57.76 — all significantly above the prior NVIDIA 1B-class models (llama-nemotron-embed-1b-v2 at 60.47/59.58), making this arguably the strongest sub-2B embedding model NVIDIA has shipped to date.

• License is not Apache: The model ships under OpenMDW-1.1, not the permissive Apache 2.0 that the underlying Ministral-3B base carries. OpenMDW is a relatively new commercial-use-oriented open license, clear that before dropping this into a production pipeline.

• 32k context, Rust+CUDA runtime: Max sequence length of 32768 tokens with a Rust+CUDA inference engine, the long context is practically useful for chunk-free document retrieval, and the Rust runtime is an interesting architectural choice that should translate to lower latency overhead compared to Python-bound serving stacks.

• Synthetic data at scale: 8.5M+ training samples across 161 dataset files, with synthetic query-document pairs generated using Qwen3, Gemma 4, and NVIDIA’s own Nemotron Ultra 550B, the synthetic data pipeline used to train this is arguably as interesting as the model itself for teams thinking about embedding model fine-tuning.

Read more at huggingface

Alibaba’s in-process vector database, with15.2k stars, released v0.6.0 yesterday with a release that reads with a focus on quantization correctness, FTS maturity, and API completeness. The headline number buried in the notes: INT4 recall on HNSW jumping from 0.2114 to 0.7117 on cohere-1m after adding random rotation to the quantization pipeline.

• INT4 recall (resurrected): Random rotation before INT4/INT8 quantization redistributes variance evenly across dimensions, fixing the recall collapse that made INT4 impractical, HNSW INT4 recall went from 0.21 to 0.71, and even INT8 improved meaningfully. For memory-constrained deployments, this changes the INT4 calculus entirely.

• Pluggable quantizer abstraction signals the roadmap: The new Turbo module introduces a uniform Quantizer interface, with Fp32Quantizer as the first concrete implementation and PQ/RaBitQ explicitly called out as next in line — the architecture is being explicitly structured for compression diversity ahead of those additions.

• Group-by search now a first-class citizen: Top-K per group (rather than global top-K) is now wired across Flat, HNSW, HNSW-RaBitQ, and sparse indexes and surfaced in the Python API, useful for any RAG pipeline that needs diversity or deduplication constraints at query time rather than post-processing.

• FTS is becoming a real Lucene alternative: UAX #29 Unicode word-boundary tokenization (from Unicode 17 tables), Snowball stemmer with 34+ language support, ASCII folding, and block-max skip optimization on conjunction queries delivering 22–38% AND query speedup — this is no longer a bolted-on keyword filter.

• DiskANN build dependency simplified: The hard libaio-dev build-time requirement is gone; libaio now dlopens at runtime with a pread() fallback when absent. Small thing, but removes a friction point for containerized and portable deployments.

Read more at Github