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

# The Missing Link Between Mistral OCR and Optimal Retrieval in Elasticsearch

<ByAuthor />

**The short answer:** Mistral OCR gives you excellent per-page markdown; Elasticsearch gives you two decades of mature full-text search fused natively with k-NN. Wired together naively — flatten, split, index — Mistral's own inline HTML tables get cut mid-row by a fixed-window splitter, and the broken fragments corrupt the BM25 statistics that hybrid search depends on. The missing link is POMA: `PrimeCut().ingest()` consumes the raw `/v1/ocr` JSON, emits hierarchy-preserving [chunksets](/learn/chunking/chunksets) with tables intact, and `records_from_archive()` turns them into documents keyed by a deterministic `chunkset_uuid` — content-free, with the actual text living on a volume `assemble()` reads back 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, with a side-channel `tables[].content` spliced at ref, plus inline image bytes when you set `include_image_base64`. What it doesn't provide: cross-page hierarchy or retrieval units. Details: [The Optimal Chunker for Mistral OCR](/optimal-chunker-mistral-ocr).

**Elasticsearch** provides `dense_vector` fields for approximate k-NN, native BM25 on every analyzed text field, one search request combining `knn` with `bool`/`match`, and `rank` (RRF) fusing both server-side. What it doesn't provide: any opinion about what a document's text field should contain, or protection against feeding it broken fragments. Details: [Elasticsearch Chunking Strategy for RAG](/optimal-chunks-elasticsearch).

## The naive wiring, and where it breaks

The common recipe — `"\n".join(p["markdown"] for p in pages)` → fixed-window splitter → `es.bulk(...)` with a `text` field for BM25 and an `embedding` field for k-NN — breaks in a pair-specific way:

- **Mistral's inline HTML tables get cut mid-row.** A window boundary falling inside a spliced `tables[].content` block leaves half a header row in one document and the data rows in the next.
- **Broken fragments pollute BM25's own statistics.** Those partial-table fragments still land in the analyzed `text` field, skewing term and document frequency counts for the exact-token queries — clause numbers, SKUs, defined terms — that Elasticsearch's BM25 side of hybrid search is supposed to nail.
- **Overlap compounds it.** Splitter overlap writes near-duplicate fragments into the same inverted index, so the corrupted table statistics get counted more than once.

## The pipeline, end to end

```bash
pip install mistralai elasticsearch
```

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

# 1. Mistral OCR — your existing call, unchanged.
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. Chunk the raw result and keep the .poma archive — the volume's source of truth.
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")
es = Elasticsearch("https://localhost:9200")

es.indices.create(index="poma", mappings={"properties": {
    "embedding": {"type": "dense_vector", "dims": embedder.dims, "index": True, "similarity": "cosine"},
    "file_id": {"type": "keyword"},
    "chunkset_index": {"type": "integer"},
}}, ignore=400)

# 3. Content-free ingest — the document 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})
    es.index(index="poma", id=r.id, document={
        "embedding": embedder.embed([r.text])[0],
        "file_id": r.payload["file_id"],
        "chunkset_index": r.payload["chunkset_index"],
    })

# 4. Retrieval — k-NN search, _source returned by default, then assemble.
qv = embedder.embed(["early termination conditions"])[0]
res = es.search(index="poma", knn={"field": "embedding", "query_vector": qv,
                                    "k": 10, "num_candidates": 100})
context = assemble(res, volume=vol)  # -> [{"file_id", "content"}, ...]
```

POMA validates the payload shape up front (a corrupted or mislabeled upload 422s immediately), splices `tables[].content` at ref instead of cutting it, handles all three Mistral image cases, and rebuilds the cross-page heading tree before chunking. The document id — `chunkset_uuid(file_id, chunkset_index)` — is deterministic, so re-indexing the same document never mints duplicates.

## Metadata mapping: POMA fields → Elasticsearch primitives

| POMA field | Elasticsearch primitive | What it enables |
| --- | --- | --- |
| `to_embed` (via `embedder.embed`) | `dense_vector` field | k-NN ranking, fusable with `bool`/`match` via `rank` (RRF) |
| `chunkset_uuid(file_id, chunkset_index)` | document `_id` | deterministic — same chunkset, same document, across re-indexing |
| `file_id` | `keyword` field | `bool.filter` scoping to one document |
| `chunkset_index` | `integer` field, returned by default | required by `assemble()`, no extra flag needed |
| chunk content, page/depth lineage | **not stored in the document** — lives on the `Volume` | fetched by `assemble()` at retrieval, deduplicated into a cheatsheet |

## Frequently asked questions

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

Save the raw `/v1/ocr` JSON, run `PrimeCut().ingest()` with `download_dir`/`filename` to keep the `.poma` archive, turn it into records with `records_from_archive()`, and index each as a document keyed by `chunkset_uuid`. Run a `knn` search and pass the response to `assemble()` — no extra metadata flag needed.

### Why not just split Mistral's markdown and index it straight into Elasticsearch?

Mistral splices tables inline as HTML; a fixed-window splitter cuts them mid-row, and the broken fragments corrupt the term-frequency statistics Elasticsearch's BM25 relies on for exact-token queries — precisely what hybrid search is supposed to nail on OCR'd documents.

### How should a Mistral OCR chunkset be mapped into an Elasticsearch index?

`embedding` as `dense_vector` (dims matching your embedder, `similarity: cosine`), `file_id` as `keyword`, `chunkset_index` as `integer` — one document per chunkset, content itself living on the volume under the content-free pattern.

### Do images in the Mistral OCR result survive the trip to Elasticsearch?

Yes — call `/v1/ocr` with `include_image_base64`, and POMA folds the figure's description into the chunk's `to_embed` text, so it becomes part of a normal, searchable document. Images without bytes or annotation become visible, counted markers.

### Does assemble() need any extra flag to retrieve Mistral OCR chunksets from Elasticsearch?

No — Elasticsearch returns `_source` by default on a `knn` search, so `file_id` and `chunkset_index` come back on every hit without an explicit ask.

## 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)

Same store, different parser: browse [all pipeline recipes](/pipelines/) — Elasticsearch combo pages for other parsers ship alongside this one. Running the fork instead? See [Mistral OCR → OpenSearch](/pipelines/mistral-ocr-to-opensearch).

Foundations: [The Optimal Chunker for Mistral OCR](/optimal-chunker-mistral-ocr) · [Elasticsearch Chunking Strategy for RAG](/optimal-chunks-elasticsearch) · [All pipeline recipes](/pipelines/) · [RAG architecture guide](/guides/rag-architecture/)