Ollama Embedding Truncation: Diagnose Long Inputs Before Indexing

Updated 25 October 2026 · Sources & corrections

If retrieval finds facts near the beginning of a document but misses details near its end, truncation is one possible cause. It is not the only one: extraction, chunking, indexing and retrieval can each lose information. This guide separates those checks before you replace a model or rebuild an index.

Scope: native embeddings, not chat context

You need a running local Ollama instance, an installed embedding-capable checkpoint and the exact text your ingestion process submits. The examples use http://127.0.0.1:11434/api/embed. Use a model tag from your own installation. They do not apply unchanged to legacy embedding endpoints, OpenAI-compatible APIs or a proxy with different limits.

The official embedding endpoint reference documents the default truncation setting. The embedding guide covers single and batch inputs. A chat model’s configured context is not evidence of what a separate embedding request accepts.

1. Check the text before the model sees it

Save a controlled copy of the extracted text, its source identifier and extraction version. Confirm that the missing fact actually appears in that text, including its ending. A PDF extraction failure cannot be repaired by changing the embedding API.

For a synthetic diagnostic document, place distinct facts near the beginning, middle and end and write a question for each. Keep the answers and source locations as a small evaluation set. Do not insert invented facts into real source documents. Avoid logging private document bodies into shared diagnostics.

2. Make an oversized input fail visibly

Save this illustrative JSON as embed-request.json. Replace the model placeholder with your installed embedding tag and the input with one controlled failing text. The short placeholder itself is not an over-context test. You can check the file syntax with python -m json.tool embed-request.json; the Python JSON documentation describes this validator. Valid JSON does not establish that the request fits the model.

{
  "model": "YOUR_LOCAL_EMBEDDING_TAG",
  "input": "Replace this with the exact controlled input being diagnosed.",
  "truncate": false
}

With the curl executable available, send the file from its directory. The one-line command works in a POSIX shell or PowerShell when curl.exe is used on Windows instead of curl:

curl --silent --show-error --include --max-time 120 -H "Content-Type: application/json" --data-binary "@embed-request.json" http://127.0.0.1:11434/api/embed

The response headers and body are both displayed. Inspect the HTTP status and error text; curl can finish successfully as a process even when the server returned an HTTP error. Do not parse the combined headers and body as a single JSON document. For installation or connection problems, use our Ollama setup guide.

If the body reports a context-length problem with truncation disabled, reduce the input into explicit chunks and retry a controlled chunk. If a timeout, connection failure or different error appears, diagnose that error first. Do not convert every failure into an empty vector or retry forever. There is no universal character-to-token conversion or chunk size that fits every checkpoint.

3. Split with traceable boundaries

Prefer meaningful boundaries such as sections or paragraphs, then verify each final input against the chosen model and deployment. A source heading, task prefix or other text added by your application is also part of the submitted input. Check the checkpoint’s documentation for any required query/document formatting rather than copying another model’s prefixes.

Keep the chunking procedure stable and versioned. If you use overlap, record it and account for duplicate passages during retrieval. Chunking is an application decision, not a guarantee of better search quality. Compare known-answer retrieval on your own documents before replacing the existing index.

Illustrative ingestion record — fill from your actual run
source_id:
source_revision_or_checksum:
extraction_version:
chunking_version:
chunk_id:
source_start_and_end:
embedding_model_and_revision:
submitted_input_checksum:
truncate_setting:
request_status:
vector_write_status:

Record failures as failures and preserve the source-to-chunk mapping. For a batch request, check that the response contains the expected number of vectors before associating them with chunks; do not silently zip a shortened result list onto the inputs. Keep pending results separate from committed index records until your checks pass.

4. Separate input coverage from vector compatibility

A vector of the expected length is a compatibility check, not a document-coverage certificate. Changing embedding dimensions does not restore text omitted earlier in ingestion. If you also changed checkpoints or vector dimensions, follow our embedding dimension and index-contract guide before mixing old and new records.

Evaluate the beginning, middle and ending questions separately. Inspect which chunk each retrieved result points to, then check the underlying passage. A correct generated answer alone can hide a retrieval miss, while a retrieval miss does not by itself prove API truncation.

When the direct request and your application disagree

Compare the actual request bodies and destinations. A wrapper may omit the flag, split text before sending it or apply its own input limit. A router may use another backend. Record server and client versions and reproduce the issue with one input. If direct behaviour contradicts the documented contract, retain that reproduction for version-specific investigation instead of assuming an index rebuild will fix it.

Your next step is to trace one missing fact from extraction through chunk storage, request status, vector write and retrieval. Repair the earliest stage where the evidence diverges, then rerun the small evaluation before expanding ingestion.