Xberg v1 Open-Source Document Extraction Engine: CPU-Only Local Processing Supporting 101 Formats

In machine learning and data engineering workflows, there's one step that nearly every practitioner considers a "chore" — transforming messy documents into clean, structured text. Whether you're building a RAG (Retrieval-Augmented Generation) system or training domain-specific models, the quality of data preprocessing often directly determines the ceiling of your final results. Recently, the open-source project Xberg released its v1 version, aiming to provide a complete, high-performance local solution for this pain point.

Positioning: The Document Extraction Layer in ML Data Pipelines

The author of Xberg introduced the project on Reddit as an open-source content extraction engine under the MIT license. Its core positioning is crystal clear: serving as the "document-extraction layer" in ML/data pipelines, specifically handling the recurring preprocessing step of "turning messy documents into clean, structured text."

Unlike many solutions that rely on cloud APIs or GPU acceleration, Xberg emphasizes a CPU-only (no GPU required) design philosophy. The direct benefits of this decision include a low deployment barrier, strong reproducibility, and particular suitability for scenarios where data privacy is a concern and documents need to be processed in local or private environments.

In a landscape where AI tools universally chase GPU acceleration, the CPU-only design may seem to go against the grain, but it reflects well-considered engineering logic. GPU resources are often scarce and expensive in enterprise environments, especially in private cloud or edge deployment scenarios. The core bottleneck of document extraction tasks is typically I/O and parsing logic rather than matrix operations, meaning that carefully optimized CPU code can achieve sufficiently good performance. Furthermore, CPU-only solutions have minimal deployment dependencies — any standard server or even a laptop can run them, which greatly simplifies CI/CD workflows and containerized deployments. For enterprises that need to pass SOC 2, HIPAA, or other compliance certifications, reducing hardware dependencies also means reducing the attack surface and audit complexity.

For industries like finance, healthcare, and legal that cannot upload documents to third-party services, local extraction capability is a hard requirement rather than a nice-to-have.

Engineering Design for Scale

You might not have noticed, but Xberg isn't designed just for one-off single-document processing — it was built for scale from the start. It supports batched extraction, streaming, and caching mechanisms. These features are critical when processing tens of thousands of documents: batch processing improves throughput, streaming controls memory usage, and caching avoids resource waste from redundant computation.

Feature Coverage: From 101 Formats to Retrieval-Ready

Xberg's breadth of features is a major highlight. According to the author, it supports up to 101 document formats, covering PDFs, Office documents, images (with OCR), and extending to audio/video transcription as well as URL web content. This means a single tool can cover the vast majority of unstructured data sources in an enterprise.

Structured Output and Retrieval Augmentation

On the output side, Xberg supports both Markdown and JSON formats, and goes far beyond simple text extraction. It can extract tables, metadata, NER entities, keywords, and summaries, and can optionally output chunks and vector embeddings.

Going further, it has built-in support for modern retrieval technologies including SPLADE, ColBERT, and reranking.

SPLADE (SParse Lexical AnD Expansion model) and ColBERT (Contextualized Late Interaction over BERT) represent two important directions in modern information retrieval. SPLADE is a learned sparse retrieval model that uses neural networks to generate sparse vector representations for documents, combining the interpretability of traditional keyword matching with deep semantic understanding, running efficiently on inverted indexes. ColBERT uses a "late interaction" mechanism — it independently generates embedding vectors for each token in queries and documents, then computes fine-grained similarity through MaxSim operations during retrieval. This preserves the precision of deep semantic matching while achieving scalability through pre-computed document representations. Reranking is a two-stage retrieval strategy: first using a lightweight model for fast candidate recall, then using a more precise model for fine-grained ranking of results.

This is extremely developer-friendly for those building RAG systems — in traditional workflows, document extraction, chunking, and vectorization often require chaining together multiple independent tools. Xberg aims to consolidate these steps into a unified pipeline, reducing the burden of glue code and format conversion.

It's worth noting that RAG (Retrieval-Augmented Generation) has become one of the most mainstream architectures in current LLM applications. Its core idea is to retrieve relevant document fragments from an external knowledge base before the model generates an answer, injecting them as context into the prompt to make responses more accurate, verifiable, and up-to-date. RAG system effectiveness is highly dependent on knowledge base quality — if source documents lose critical information during extraction, scramble logical order, or introduce excessive noise, then no matter how sophisticated the retrieval algorithm or how powerful the generation model, the final output will be constrained by "garbage in, garbage out." Xberg's built-in retrieval capabilities mean users can achieve production-grade retrieval quality without deploying separate vector databases or retrieval services.

Technical Foundation: Rust Core and Throughput Optimization

Performance is a selling point Xberg repeatedly emphasizes. Its core is written in Rust, using pooled model sessions and strict memory discipline to ensure throughput.

Rust has seen rapidly growing adoption in data infrastructure in recent years, with notable projects including Apache DataFusion (analytical query engine), Polars (DataFrame library), Tantivy (full-text search engine), and Hugging Face's tokenizers library. Rust's core advantages lie in its ownership system and borrow checker, which eliminate data races and memory safety issues at compile time without the runtime overhead of a garbage collector (GC). This is particularly critical for long-running batch processing services — GC pauses in Java or Go can cause latency spikes, Python's GIL (Global Interpreter Lock) limits true parallel processing, while Rust achieves deterministic low latency and near-linear performance scaling. The "pooled model sessions" design pattern avoids the overhead of repeatedly loading and initializing models for each inference request, similar to the concept of database connection pooling — pre-creating and maintaining a set of reusable model instances, fetching one from the pool when a request arrives and returning it when done.

For data engineers, this design means being able to process larger document collections on limited CPU resources without worrying about memory leaks or sudden performance degradation.

Reproducible Public Benchmarks

Xberg demonstrates considerable transparency in benchmarking. The author claims the benchmarks are public and reproducible, with the test harness running directly in CI — something uncommon among open-source projects. It means anyone can verify the truthfulness of performance claims rather than relying solely on vendor-supplied numbers.

According to their published benchmark results (xberg.io/benchmarks):

• Native PDF extraction: Ranks #1 in quality and table/reading-order fidelity;
• Image OCR: Currently ranks #2, with the author noting ongoing improvements.

Table structure and reading order fidelity are precisely the aspects most prone to failure in document extraction. The root cause is that PDF's underlying format doesn't store logical reading order — it only records each character's absolute coordinate position on the page. For complex layouts like multi-column formatting, cross-page tables, and nested lists, extraction tools must reconstruct the human reading path. Table structure recovery is even more challenging: tables in PDFs are typically not semantic data structures but rather collections of text positioned at specific coordinates with optional lines. Tools need to infer cell boundaries, merged cell relationships, header hierarchies, and more. Once these structures are broken, downstream LLMs will produce hallucinations or errors when processing questions like "please summarize the data in column three of the table."

Many tools can extract text but scramble paragraph order or destroy table structures, preventing downstream LLMs from understanding correctly. Xberg's leading performance in this dimension indicates significant effort in parsing logic, likely employing a hybrid layout analysis strategy combining rules and machine learning.

Integration: Multi-Language Bindings and Service Deployment

In terms of usability, Xberg offers multiple integration paths to accommodate different tech stacks:

• 15 language bindings: Whether your team uses Python, Java, Go, or other mainstream languages, integration is straightforward;
• REST server (xberg serve): Extraction capabilities can be deployed as an independent microservice, shared across multiple applications;
• MCP support: Model Context Protocol, an emerging protocol that enables Xberg to interface more naturally with LLM applications (such as AI Agents).

Model Context Protocol (MCP) is an open protocol standard proposed and promoted by Anthropic in late 2024, designed to provide LLM applications with a unified way to access external tools and data sources. Before MCP, every AI Agent framework had its own tool-calling interface, requiring developers to write separate adapters for LangChain, LlamaIndex, AutoGen, and other frameworks. MCP defines a standardized client-server protocol that lets tool providers implement an interface once and be callable by all MCP-supporting AI applications. Xberg's MCP support means it can serve as the "eyes" of an AI Agent — when an Agent needs to understand a PDF report or video content, it can invoke Xberg's extraction capabilities directly through the standard protocol without writing custom integration code. This interoperability is crucial for building complex multi-Agent systems.

This "library + service + protocol" trinity distribution approach covers deployment patterns from embedded calls to distributed services, reducing friction when deploying in real production environments.

Observations and Thoughts

Overall, Xberg v1 targets a real and frequently encountered engineering pain point. In the current market, document extraction tools are plentiful, but they tend to either focus on specific format types, be tightly coupled to cloud services, or perform poorly on table and layout fidelity. Xberg attempts to consolidate these capabilities with a CPU-only, reproducible, broadly covering, and retrieval-ready solution.

Of course, as a project that just released v1, its actual stability, community ecosystem, and long-term performance at very large scale still need time to be validated. The current #2 ranking in image OCR also shows it hasn't achieved perfection across all dimensions. However, for teams building RAG or data preprocessing pipelines, an open-source, transparent option with documented performance is certainly worth including in the technology evaluation shortlist.

Project: github.com/xberg-io/xberg Benchmarks: xberg.io/benchmarks