Which embedding did that passage use?

An answer is being served from retrieval, and you cannot say which vector the passage was stored as. Do not send the sentence again, and do not ask the model which embedding it used, until three things are true. Name the model and the length of the vector you stored for that passage. Show a different passage that was embedded with a different model, or a different length, or that has no vector. Show that you set the model, rather than the model reporting it. If the index does not store the model, write that, and stop calling the sentence retrieved.

This is the vector on one passage. It is not where the passage sat in the prompt. Where the supporting passage sat is an index, or a distance from the start and from the end. A position can be known while the vector that retrieved the passage is unknown, and a vector can be known while the passage sat where the model does not reliably look. It is not the age of the page. When the retrieved page is old compares a date on the passage with the live page. A current page can be embedded with a model you did not record. It is not the temperature on a completion. Which temperature did that call use? is a sampling field on a request you stored. A temperature is not a dimension. It is not the chat model the request hit. Name the model the request hit is the id on a generation. A generation id is not an embedding id. It is not the prompt text. Which prompt did that request send? is the system text, the messages, and the tools. A prompt is not a vector.

None of what follows is a score for this product, and none of it is a promise that a longer vector retrieves better on your corpus. The lengths below are one vendor's current embedding guide. The averages below that are a 2023 benchmark of other models, including one the authors label as an OpenAI similarity embedding. A default length is not the vector you stored. A benchmark average is not your error rate. They do tell you which numbers people mix up when they try to sound precise about an embedding they have not named.

OpenAI's embedding guide prints three model ids and one length shared by all of them as a token cap. text-embedding-3-small defaults to 1536 dimensions. text-embedding-3-large defaults to 3072. Both, and text-embedding-ada-002, list a max input of 8192 tokens. 1536 is not 3072. 8192 is not a dimension. The same table, which assumes about 800 tokens per page, prints pages per dollar: 62,500 for text-embedding-3-small, 9,615 for text-embedding-3-large, and 12,500 for text-embedding-ada-002. 62,500 is not 9,615. 9,615 is not 12,500. 800 is not 8192. The page does not print the product of pages and tokens, so do not replace a pages-per-dollar cell with a multiplication. The performance column on that table, labeled performance on an MTEB eval, is 62.3%, 64.6%, and 61.0% in the same order. 62.3 is not 64.6. 64.6 is not 61.0. A percentage in that column is not a dimension (OpenAI, Vector embeddings).

Shortening is a second cut of that same guide, and it is not a second model. The guide says a text-embedding-3-large embedding can be shortened to 256 and still outperform an unshortened text-embedding-ada-002 embedding of 1536, on the MTEB benchmark, in their sentence. 256 is not 1536. Outperforms, in that sentence, is not a printed score. The page does not give the two MTEB numbers behind the comparison, so do not invent them. A vector store that only accepts 1024 dimensions is their example for passing dimensions 1024 on text-embedding-3-large, which shortens the vector from 3072. 1024 is not 256. 1024 is not 3072. 1024 is not 1536. Passing dimensions when you create the embedding is the approach they suggest. Shortening afterwards, they say, has to be normalized. A truncated vector you did not normalize is not the vector the parameter would have returned. For third-generation models such as text-embedding-3-small, they say to count tokens with the cl100k_base encoding. cl100k_base is an encoding name. It is not a length. Their counting example is the string "tiktoken is great!". That string is not a passage in your index.

The benchmark the guide's percentage column points at is an older paper, and its OpenAI row is not those three model ids. Niklas Muennighoff, Nouamane Tazi, Loïc Magne, and Nils Reimers introduced MTEB as arXiv:2210.07316, version 3, 19 March 2023. The abstract says 8 embedding tasks, 58 datasets, 112 languages, and 33 models. The introduction and the conclusion also say they evaluate over 30 models. 33 is not the phrase over 30. Both are printed. 8 is not 58. 58 is not 112. Of the datasets, 10 are multilingual, and those 10 cover the 112 languages. 10 is not 58. 10 is not 112. The English results table prints a dataset-count row of 12, 11, 3, 4, 15, 10, and 1, and that row's total cell is 56. 56 is not 58. The paper does not print a subtraction that turns 58 into 56, so do not invent the two missing datasets. 15 retrieval datasets is not 1 summarization dataset. 12 classification datasets is not 11 clustering datasets (Muennighoff, Tazi, Magne, and Reimers, MTEB: Massive Text Embedding Benchmark).

The main metric is not one number across the table. For retrieval, the paper says nDCG@10 is the main metric. For semantic textual similarity, and again for summarization, the main metric is Spearman correlation based on cosine similarity. nDCG@10 is not a Spearman correlation. The English table's OpenAI row is labeled OpenAI Ada Similarity, not text-embedding-3-small, not text-embedding-3-large, and not text-embedding-ada-002. Its cells are classification 70.44, clustering 37.52, pair classification 76.86, reranking 49.02, retrieval 18.36, STS 78.60, summarization 26.94, and average 49.52. 49.52 is not 78.60. 18.36 is not 70.44. 26.94 is not 49.02. The guide's 62.3%, 64.6%, and 61.0% are not in this row. 61.0 is not 49.52. A reader who pastes the guide's ada percentage onto the paper's Ada Similarity average has changed the model and the year. Do not.

The best average in that English table is not the OpenAI row, and it does not win every column. ST5-XXL prints 73.42, 43.71, 85.06, 56.43, 42.24, 82.63, 30.08, and average 59.51. 59.51 is not Ada Similarity's 49.52. 42.24 on retrieval is not Ada's 18.36. 82.63 on STS is not Ada's 78.60. 30.08 on summarization is not Ada's 26.94. 73.42 is not 70.44, and the gap is smaller there than on retrieval. The paper's claim is that no single method dominates every task. A higher average is not a higher cell in every column. Their 59.51 is not the guide's 64.6%, and it is not a length of 3072. A leaderboard average is not the model id stored next to your passage.

Do the three proofs on one real passage, in the index you actually query. First, the binding. Copy the passage identifier, the embedding model id, and the length of the stored vector. If the record shows a vector and no model, write that the model was not stored. Do not infer text-embedding-3-small from a length of 1536, because the guide gives an unshortened ada-002 embedding a size of 1536, and because a shortened large model can wear some other length. 1536 is not an id. Second, the other passage. A passage embedded at 3072, or at 256, or not embedded, is not this one. A score from a paper is not that second passage. If you cannot show a passage that differs, you have a single column, not a record. Third, the call. The model id on the request you sent is the one you can defend. A sentence the model writes about "which embedding I used" is the model talking. It is not the request. If the log does not store the embedding call, write that. A missing call is the finding. It is not a reason to tell the customer the passage was retrieved.

Three moves feel like the proof and are a second problem. Re-embedding the whole corpus tonight because two lengths were in the same table, and then describing the old vectors as if they had always been the new length. Asking the guide's 64.6% to stand in for a test you have not run. 64.6 is one vendor's MTEB cell for one model. It is not your recall. Asking a chat model which embedding the retriever used. The chat model was not the embedding call. A position you can point to in the prompt, while the vector is still unnamed, is where the supporting passage sat. Writing the index of the passage does not name the model that retrieved it.

The path is ordinary when one search can name the document it opened without pretending the document is a vector. Haystack is one search across documents, data lakes, and repositories, with indexing as new data arrives. The shape that matters here is one document you can point at, distinct from the next document, in a system an operator can open. That case is not an embedding ledger. Nothing in the description is a headcount, a duration, or a result figure. If the only control on the screen is a search box with no model id behind it, you do not have this proof. You have a query.

There is a version of this afternoon where hiring the path is the wrong purchase. Nothing is in production, so there is no passage being served. No embedding model is being called, because the index is empty or the feature does not retrieve. You have not logged the request. A customer has already seen another customer's document. Naming a model does not close a leak. The wrong value was already a write the agent made. No metric was ever named, so there is nothing for a rescue to miss. The audit that says whether any of that is true is the first one or two weeks of a rescue. The build, if there is one, is scoped after that audit, runs 8 to 12 weeks, and is unpaid if the metric you agreed is missed. Rollout stays behind a human-review gate.

When the passage is real and the index cannot name the model, the missing object is specific. The model id and the length on that vector, a second passage that differs, and a written line that you chose the model. An AI pilot failed to reach production engagement is scoped after an audit, not before it. The call you cannot name is the kind of case the harness has to include, or the next release will retrieve just as fluently and just as unlogged. The harness is AI evaluation and observability. An AI integration sprint is the shape where the acceptance sentence can require the model id on every stored vector. If you do not yet know whether the pilot can be saved, a two-week AI readiness assessment hands you the findings either way. The findings are yours. They are not 62.3, and they are not 49.52.

A subscription status, and the artifact a workflow kept, are different objects: which status is that subscription in? and which artifact did that run keep?. Do not record either on this page. A status is not a dimension. A retention period is not an embedding model.

Before you send the next sentence as retrieved, open the index and write the model and the length. Name the embedding, or write that the model was not stored. Show a different passage that is not this vector. Show that the model id came from the request you sent. Do not ask the model which embedding it used, and do not let a benchmark average stand in for the column you did not save. The guide can tell you which defaults a vendor offers. The binding is the page you can defend.