Source: http://www.poma-ai.com/docs/pipelines/mistral-ocr-to-mongodb-atlas

# The Missing Link Between Mistral OCR and Optimal Retrieval in MongoDB Atlas

<ByAuthor />

**The short answer:** Mistral OCR gives you excellent per-page markdown; MongoDB Atlas gives you vector search folded directly into the aggregation pipeline you already run. Wired together naively — flatten, split, embed, insert — they still produce mediocre RAG, because nothing in between rebuilds the document's hierarchy or respects Atlas's projection rules. The missing link is POMA: `PrimeCut().ingest()` consumes the raw `/v1/ocr` JSON, emits hierarchy-preserving [chunksets](/learn/chunking/chunksets), and `vektoria`'s content-free ingest pattern writes only routing metadata into Atlas while `assemble()` reconstructs prompt-ready context from a volume at query time.

## What each end of the pipeline actually provides

**Mistral OCR** (`/v1/ocr`, `mistral-ocr-latest`) returns `pages[]`, each with an `index` and a `markdown` string — headings, lists, and tables recovered *within* each page, image bytes inline when you set `include_image_base64`. What it doesn't provide: cross-page hierarchy (a heading on page 41 has no machine link to the chapter that opened on page 3) or retrieval units. Details: [The Optimal Chunker for Mistral OCR](/optimal-chunker-mistral-ocr).

**MongoDB Atlas** provides a `$vectorSearch` aggregation stage on an Atlas-managed vector index, compound hybrid search via Atlas Search, and ordinary document fields for `$match` filtering — all inside the aggregation pipeline you already operate. What it doesn't provide: any opinion about what a document should hold, or which fields survive to the output. It ranks whatever you embedded and returns whatever you `$project`, including nothing at all if you forget. Details: [MongoDB Atlas Chunking Strategy for RAG](/optimal-chunks-mongodb-atlas).

## The naive wiring, and where it breaks

The common recipe — `"\n".join(p["markdown"] for p in pages)` → `RecursiveCharacterTextSplitter` → embed → `col.insert_one(...)` per chunk → a bare `$vectorSearch` query — breaks in a pair-specific way:

- **Mistral's page indices vanish at the join**, so no `$match` predicate can scope by page, and per-document filtering is all that's left of Atlas's field-level flexibility.
- **Overlap inflates the collection with near-duplicate documents,** each embedded and indexed separately — more vector-index entries to rank through for no retrieval benefit, the same waste any redundant insert would cause.
- **The aggregation pipeline drops the exact fields `assemble()` needs.** A `$vectorSearch` stage on its own returns Atlas's default projection, not your custom `metadata` field — without an explicit `{"$project": {"_id": 1, "metadata": 1, "score": {"$meta": "vectorSearchScore"}}}` stage immediately after it, `file_id` and `chunkset_index` never make it into the result, and `assemble()` returns an empty context list from hits that scored just fine.

## The pipeline, end to end

```bash
pip install mistralai pymongo
```

```python
import os
from mistralai import Mistral
from pymongo import MongoClient
from poma import PrimeCut
from poma.vektoria import assemble, records_from_archive, Volume
from poma.embeddings import get_embedder

# 1. Mistral OCR — your existing call, unchanged. Save the raw result JSON.
mistral = Mistral(api_key=os.environ["MISTRAL_API_KEY"])
ocr = mistral.ocr.process(
    model="mistral-ocr-latest",
    document={"type": "document_url", "document_url": "https://example.com/contract.pdf"},
    include_image_base64=True,
)
with open("contract.mistral-ocr.json", "w") as f:
    f.write(ocr.model_dump_json())

# 2. The missing link — raw result JSON in, a portable .poma archive out.
client = PrimeCut()  # reads POMA_API_KEY
client.ingest("contract.mistral-ocr.json", download_dir="archives", filename="contract.poma")

embedder = get_embedder("local:BAAI/bge-small-en-v1.5")
vol = Volume("s3://your-bucket/poma")
mongo = MongoClient(os.environ["MONGODB_ATLAS_URI"])
col = mongo["poma"]["chunksets"]

# Atlas vector index (numDimensions, similarity) is created once via the Atlas UI/API,
# named "poma_vec" here — not through the pymongo driver itself.

# 3. Content-free ingest — the collection holds only routing metadata; content lives on the volume.
records = records_from_archive("archives/contract.poma")  # -> list[Record] (id, text, payload)
for r in records:
    vol.write_doc(r.payload["file_id"], {"file_id": r.payload["file_id"],
                                          "chunks": r.payload["chunks"], "text": r.text})
    col.insert_one({
        "_id": r.id,
        "embedding": embedder.embed([r.text])[0],
        "metadata": {"file_id": r.payload["file_id"], "chunkset_index": r.payload["chunkset_index"]},
    })

# 4. $vectorSearch retrieval — $project the metadata explicitly, then assemble.
qv = embedder.embed(["early termination conditions"])[0]
hits = list(col.aggregate([
    {"$vectorSearch": {"index": "poma_vec", "path": "embedding",
                       "queryVector": qv, "numCandidates": 200, "limit": 10}},
    {"$project": {"_id": 1, "metadata": 1, "score": {"$meta": "vectorSearchScore"}}},
]))
context = assemble(hits, volume=vol)  # -> [{"file_id", "content"}, ...]
```

POMA validates the Mistral payload shape up front (a corrupted or mislabeled upload 422s immediately), handles all three Mistral image cases, strips running headers/footers, and rebuilds the cross-page heading tree before chunking. Retrieved chunksets share ancestor lineage across a document — `assemble()` deduplicates that lineage into one prompt-ready cheatsheet, the same discipline that answers our reference legal-document benchmark with **337 tokens** instead of **1,542** for a recursive-splitter baseline. [Methodology here](/document-ingestion-chunking-rag).

## Metadata mapping: POMA fields → MongoDB Atlas primitives

| POMA chunk field | MongoDB Atlas primitive | What it enables |
| --- | --- | --- |
| `to_embed` | `embedding` field, covered by the Atlas Vector Search index | ANN search via `$vectorSearch` |
| `file_id` | `metadata.file_id`, ordinary document field | `$match`/filter scoping to one document |
| `page` (from Mistral `pages[].index`) | volume document, not a field | content-free retrieval, cheatsheet assembly |
| `depth` | volume document, not a field | content-free retrieval, cheatsheet assembly |
| `chunkset_index` | `metadata.chunkset_index`, must be `$project`-ed | `assemble()` dedup and ordering |
| chunkset lineage (content) | not stored in the collection — lives on the `Volume` | content-free documents, smaller cluster footprint |

## Frequently asked questions

### How do I get Mistral OCR results into MongoDB Atlas for RAG?

Save the raw `/v1/ocr` JSON, run `PrimeCut().ingest()` on it, then pull `records_from_archive(...)`, write each chunkset's content to a volume, embed its `to_embed` text, and `insert_one` the vector plus a `metadata` document (`file_id`, `chunkset_index`) into an Atlas Vector Search-indexed collection. Retrieve with `$vectorSearch` and `assemble()`.

### Why does POMA's assemble() return nothing from my MongoDB Atlas results after a Mistral OCR ingest?

The aggregation pipeline drops fields you don't project. A `$vectorSearch` stage must be followed by `{"$project": {"_id": 1, "metadata": 1, "score": {"$meta": "vectorSearchScore"}}}` — without it, `file_id`/`chunkset_index` never reach the result and `assemble()` gets nothing back.

### What MongoDB Atlas fields should Mistral OCR chunksets carry?

An `embedding` field covered by the Atlas Vector Search index, plus a `metadata` document holding only `file_id` and `chunkset_index` — enough for `$match` to scope by document alongside the vector stage. `page` (from Mistral's `pages[].index`) and `depth` stay on the volume document with the rest of the chunkset content, not as separate Atlas fields.

### Why not just split Mistral OCR's markdown and insert it into MongoDB Atlas directly?

Concatenation discards page indices and heading levels, and splitter overlap inserts near-duplicate documents that inflate the vector index for no retrieval benefit. Atlas then ranks context-free fragments exactly as faithfully as it would rank real chunksets.

### Can I combine Mistral OCR content with MongoDB Atlas's hybrid search?

Yes — Atlas Search's compound query type combines BM25-style text matching with `$vectorSearch` results in one pipeline, useful for OCR'd business documents whose exact tokens (clause numbers, invoice IDs) dense embeddings tend to blur.

## Related recipes

Same parser, different store: [Mistral OCR → Qdrant](/pipelines/mistral-ocr-to-qdrant) · [Mistral OCR → Pinecone](/pipelines/mistral-ocr-to-pinecone) · [Mistral OCR → pgvector](/pipelines/mistral-ocr-to-pgvector)

Foundations: [The Optimal Chunker for Mistral OCR](/optimal-chunker-mistral-ocr) · [MongoDB Atlas Chunking Strategy for RAG](/optimal-chunks-mongodb-atlas) · [All pipeline recipes](/pipelines/) · [RAG chunking guide](/guides/rag-chunking/) · [POMA chunksets](/learn/chunking/chunksets)