Text Embeddings Reveal (Almost) As Much As Text

Retrieval systems store documents as dense embeddings: fixed-length vectors from a model such as GTR or OpenAI's text-embedding-ada-002. A common design sends only the vectors to a hosted vector database and keeps the text elsewhere, on the reasoning that a vector is not the text. This paper asks whether someone holding the vectors, and able to call the same embedding model, can recover the text.

A model trained to map an embedding straight back to text does poorly: on 32-token Wikipedia passages it gets the gist but never the exact passage. The authors' method, Vec2Text, adds a correction loop. It guesses text, embeds the guess with the target embedding model, and feeds the target vector, the guess's vector and their difference into a second model that edits the guess. Repeating this moves the guess's embedding from cosine similarity around 0.92 toward 1.0, at which point the text usually matches. The corrector is a T5-base encoder-decoder of about 235 million parameters, trained on 5 million passages.

On GTR-base embeddings of 32-token passages, 50 correction steps with a sequence-level beam search recovered 92% of passages exactly. On ada-002 embeddings of MSMARCO, it recovered 61% of 32-token passages and 8% of 128-token passages exactly, with most words right in the rest. On clinical notes in which fake names had replaced the redacted ones, it recovered 94% of first names, 95% of last names and 89% of full names. Longer text is harder: across 19 out-of-domain datasets, BLEU falls as passage length rises.

The authors test one defense: adding Gaussian noise to each embedding. At a noise level of 0.01, retrieval quality on BEIR barely moves while reconstruction collapses. They note that the inverter was not trained on noisy vectors, so an attacker who adapts could do better, and that a low BLEU does not stop coarser inferences such as the topic of a note. Their conclusion: treat embeddings with the same care as the raw text.

An embedding is the data, for compliance purposes. If a customer's contracts, tickets or patient notes are embedded, the vector store holds a recoverable copy of their sensitive content, especially for short chunks. Data residency, retention, deletion and access rules that apply to the text apply to the vectors. Say this early, before the architecture review asks.

Hosting vectors elsewhere is not a privacy boundary. A design that keeps text on premises and sends only embeddings to a hosted service moves the data off premises anyway. Popular embedding models are public or reachable by API, which is all this attack needs.

Chunk size changes the exposure. Recovery was near complete at 32 tokens and much weaker at 128. Many RAG systems index small chunks for retrieval precision, and those are the easiest to rebuild. Larger chunks lower exact recovery but do not remove names and topics.

Access control must reach the vector layer. If two tenants share an index, or a service account can read raw vectors, they can read each other's documents with some effort. Keep per-tenant indexes or enforce filters in the database, and do not expose raw vectors through APIs that only need search results.

Noise is a cheap, partial mitigation. The paper's data shows a noise level that keeps 98% of retrieval quality while cutting reconstruction to 13% of its BLEU. Our toy run shows why the right level depends on the corpus: noise that is harmless when the right document is far ahead of the next one starts swapping results when they are close. Test it on the customer's own queries, and do not present it as a guarantee.