LLM and RAG systems use embeddings to search for documents or conversation content.

For example, let’s say we have the following sentence:

"고객사 A와 1억 원 규모의 보안 교육 계약을 체결했다."

An embedding model converts this sentence into a numerical array like this:

[0.132, -0.847, 0.291, ...]

This numerical array is an embedding vector.

This often leads to the following question:

If embedding vectors are obtained, can the original text be fully restored through reverse-engineering?

To get straight to the point, the original text is not automatically restored solely from embedding vectors.

However, if an attacker obtains the embedding model, candidate data, search API, and metadata together, they can infer a significant portion of the original text’s meaning or specific attributes.

Embeddings are Not Encrypted Data

An embedding is not the result of encrypting text.

Encryption is designed to accurately restore the original text if a valid decryption key is available.

In contrast, an embedding represents the semantic features of a sentence in a high-dimensional numerical space.

원문 텍스트
    ↓
임베딩 모델
    ↓
벡터

Therefore, the following inverse transformation relationship generally does not hold:

벡터
  ↓
단순 역계산
  ↓
정확한 원문

During the embedding process, some information such as word order, expression style, and sentence structure may be lost.

For example, the following two sentences are different but can have similar vectors:

"고객사 A와 1억 원 규모의 계약을 체결했다."

"A사와 약 1억 원 상당의 계약을 맺었다."

Because their meanings are similar, they are likely to be placed close to each other in the embedding space.

Why Original Text is Retrieved in RAG

Seeing the original text output as a result of vector search in a RAG system might lead to the misunderstanding that vectors are reverse-transformed into the original text.

However, the actual structure is usually as follows:

원문 문서 ──────────────┐
                       │
                       ├─ 문서 저장소
                       │
                       └─ 임베딩 생성 → 벡터 DB

The search process is as follows:

사용자 질문
   ↓
질문 임베딩 생성
   ↓
벡터 DB에서 유사 벡터 검색
   ↓
벡터에 연결된 문서 ID 확인
   ↓
문서 저장소에서 원문 조회

In other words, the original text appears not because the vector was restored, but because the original text or document chunk linked to the vector was retrieved.

A vector DB can actually store data like this:

{
  "id": "doc-1042",
  "vector": [0.132, -0.847, 0.291],
  "metadata": {
    "user_id": "user-a",
    "source": "contract-document",
    "text": "고객사 A와 1억 원 규모의 계약을 체결했다."
  }
}

In this structure, if an attacker can access metadata or original text fields, there is no need to reverse-engineer the embedding.

Therefore, in practice, a failure in vector DB access control can be a more direct risk than an embedding restoration attack.

Typical Methods for Reverse-Engineering Embedding Vectors

1. Candidate Sentence Comparison Attack

The simplest method is for an attacker to create several plausible candidate sentences and vectorize them using the same embedding model.

탈취한 벡터
    ↕ 코사인 유사도 비교
후보 문장 벡터

For example, an attacker might prepare candidates like these:

"고객사는 삼성SDS다."
"고객사는 LG CNS다."
"고객사는 SK C&C다."

Each sentence is embedded and then compared with the stolen vector.

The content included in the original text can be inferred through the candidate with the highest similarity.

This attack is particularly effective under the following conditions:

If the embedding model is known
If the range of candidate sentences is narrow
If sentences are short and standardized
If choices are limited, such as names, company names, or disease names
If the attacker can call the same embedding API

For example, if it’s known that the contract status is one of the following three, inference becomes easier:

계약 체결
계약 검토
계약 취소

Even if the entire original text cannot be restored, the status can be identified.

2. Nearest Neighbor Dictionary Attack

An attacker can also create a dictionary by pre-embedding a large number of sentences or documents.

문장 사전
   ↓
대량 임베딩 생성
   ↓
벡터 인덱스 구축
   ↓
탈취한 벡터와 최근접 문장 검색

For example, there might be candidate data like this:

candidate_texts = [
    "관리자 비밀번호가 변경되었습니다.",
    "고객의 주민등록번호가 포함되어 있습니다.",
    "계약 금액은 1억 원입니다.",
    "보안 교육 계약이 취소되었습니다."
]

The attacker embeds these candidates and then finds the sentence closest to the stolen vector.

This method has a high chance of success with data such as:

Standard contracts
Email templates
Customer service scripts
Performance review forms
Medical record codes
Public technical documents
Repeatedly used internal documents

If the original text is similar to existing public documents or standard phrases, significant information can be obtained just by searching for the nearest sentence.

3. Embedding Inverse Transformation Model

Another method is for an attacker to train a separate decoder model.

The attacker prepares a large number of text and embedding vector pairs.

텍스트 → 임베딩 모델 → 벡터

Then, they train an inverse model like this:

벡터 → 디코더 모델 → 텍스트 추정

If sufficient training data is available, the model can take a vector as input and generate a sentence similar to the original text.

For example, let’s say the original text is as follows:

"고객사 A와 1억 원 규모의 보안 교육 계약을 체결했다."

The restoration result might look like this:

"A사와 약 1억 원 규모의 보안 교육 계약을 맺었다."

While not exactly the same sentence, the core meaning can be largely restored.

For this reason, embedding reverse-engineering is closer to semantic restoration than exact string recovery.

4. Attribute Inference Attack

An attacker might try to discover only specific attributes rather than restoring the entire original text.

For example, questions like these:

이 벡터에는 금융정보가 포함되어 있는가?
특정 회사명이 들어 있는가?
질병 관련 내용인가?
계약 금액이 포함되어 있는가?
보안 사고 내용인가?

The attacker can train a classifier that takes vectors as input.

Embedding
    ↓
속성 분류기
    ↓
"금융정보 포함 확률 92%"

This method can be more realistic than full original text restoration.

Actual attackers don’t need to know every sentence.

For example, knowing just the following information can be problematic:

Presence of a specific disease
Existence of a contract with a specific company
Inclusion of personal information
Occurrence of a security incident
Participation in an internal project
Use of a specific technology

This type is called an attribute inference attack.

5. Membership Inference Attack

Membership inference is an attack that verifies whether specific data is included in a vector store.

For example, an attacker might want to know:

"A사 계약서가 이 데이터베이스에 존재하는가?"
"특정 직원의 인사평가 문서가 포함되어 있는가?"
"특정 환자의 진료기록이 학습 또는 검색 데이터에 들어 있는가?"

Even if the original text cannot be directly viewed, the mere existence of the data can be sensitive information.

For example, the exposure of a company investigating a specific security incident could be problematic.

6. Iterative Inference Using Search API

Even if an attacker cannot access the vectors themselves, they can infer information by repeatedly calling the search API.

For example, by repeating questions like these:

"A사와 계약했는가?"
"A사 계약 금액은 1억 원 이상인가?"
"A사 계약은 교육 계약인가?"
"A사 계약 시점은 2026년인가?"

If search result rankings or similarity scores are provided, an attacker can narrow down information by slightly altering queries.

질문 변경
   ↓
유사도 점수 확인
   ↓
더 높은 점수가 나오는 방향 탐색
   ↓
원문 의미 추정

This structure can be viewed as a search oracle or similarity oracle.

The risk increases particularly if the API exposes the following information:

Detailed similarity scores
Search rankings
Document IDs
Metadata
Number of documents found
Difference in results before and after filtering

7. Coordinate Optimization-Based Attack

An attacker can create an arbitrary sentence and then gradually modify words or expressions to find a direction that gets closer to the target vector.

초기 문장 생성
   ↓
단어 또는 문장 구조 변경
   ↓
임베딩 생성
   ↓
목표 벡터와 유사도 측정
   ↓
유사도가 높아지는 변경 유지

For example, they might start with the following sentence:

"어떤 회사와 계약했다."

Then, they change it little by little as follows:

"A사와 계약했다."
"A사와 교육 계약을 체결했다."
"A사와 1억 원 규모의 교육 계약을 체결했다."

If the similarity score continues to increase, a sentence with a meaning close to the original text can be found.

The more precise the similarity score provided by the API, the easier such optimization attacks can become.

8. Exfiltration of Metadata and Original Text Linkage Information

In practice, this is the most direct attack.

A vector DB may store not only embeddings but also metadata like this:

{
  "vector": [0.132, -0.847, 0.291],
  "metadata": {
    "tenant_id": "company-a",
    "user_id": "user-1004",
    "document_name": "2026-contract.pdf",
    "chunk_text": "계약 금액은 1억 원이다."
  }
}

In this case, the attacker does not need to reverse-engineer the embedding.

If read access to the vector DB is obtained, the following information can be directly exposed:

Original text chunks
User ID
Tenant ID
File name
Storage location
Document title
Author
Conversation ID
Document URL

Therefore, a vector DB should be viewed not as a simple search index but as a sensitive information store.

Conditions that Make Embedding Reverse-Engineering Easier

The exposure of embedding vectors does not always mean the original text can be restored.

However, the more of the following conditions are met, the higher the success rate of an attack.

If the same embedding model is known

If an attacker knows the model being used, they can vectorize candidate sentences in the same way.

For example, if the model name, dimensionality, and normalization method are public, comparison attacks become easier.

If the embedding API can be freely used

If an attacker can generate embeddings without limit, they can repeatedly compare various candidate sentences.

If the range of original text candidates is narrow

Inference is easier if choices are limited, as follows:

승인
거절
검토 중

Conversely, for long, free-form documents, accurate original text restoration is much more difficult.

If the sentence is short

Short sentences contain less information, which reduces the candidate space.

For example, the following sentence is relatively easy to infer:

"계약이 취소되었다."

On the other hand, a long sentence with mixed topics is difficult to restore accurately with a single vector.

If the chunk size is small

In RAG, documents are divided and stored in small units.

문서
  ↓
300~500 토큰 단위 청크
  ↓
각 청크 임베딩

If a chunk is too small, a single vector can directly represent a specific sentence or sensitive information.

If metadata is exposed along with it

If the following information is available, an attacker can significantly narrow down the range of candidates:

파일명
부서명
작성자
문서 유형
날짜
고객사명
사용자 ID

If similarity scores are provided in detail

If similarity scores are exposed with decimal precision, an attacker can gradually modify sentences to find a direction that gets closer to the target vector.

Does Having Only Vectors Mean the Original Text Comes Out As Is?

It is necessary to distinguish precisely.

Vector Search

벡터
  ↓
연결된 문서 ID 확인
  ↓
저장된 원문 조회

In this case, the original text was not reverse-engineered.

It was retrieved directly from the original text linked to the vector.

Embedding Reverse-Engineering

벡터
  ↓
후보 비교 또는 디코더 분석
  ↓
원문의 의미나 속성 추정

In this case, the original text is inferred probabilistically.

Even if the exact same string does not appear, core content or sensitive attributes may be exposed.

Therefore, the following expression is more accurate:

Obtaining embedding vectors does not automatically restore the original text as is. However, by comparing candidate sentences, inferring attributes, training decoders, and analyzing search APIs, the meaning or sensitive information of the original text can be estimated.

Are ChatGPT Conversation Histories Also Stored Only as Vectors?

It cannot be definitively stated how a specific service stores conversation histories based solely on publicly available information.

How conversation history, memory, and search indexes are managed in terms of database structure is part of the service provider’s internal design.

Therefore, one should not assert the following:

모든 대화 원문이 임베딩 벡터로만 저장된다.
벡터를 역변환하면 모든 대화가 그대로 나온다.

In typical services, the following elements may exist separately:

대화 원문 저장소
검색용 임베딩 인덱스
사용자 메모리
메타데이터
로그 및 감사 기록

Embeddings are primarily used for search and similarity comparison, and the actual original text is often managed in a separate storage.

What Should Be Checked in a Security Audit?

Checking only the possibility of embedding reverse-engineering is insufficient.

In actual LLM and RAG security audits, the following items may be more important:

Data Isolation Between Users

It is necessary to check whether User A can search User B’s documents.

user_id = A
tenant_id = company-a

If such filters are missing during search, other users’ data may be exposed.

Tenant-Unit Access Control

In a multi-tenant environment, data separation by organization is essential.

tenant-a의 문서
tenant-b의 문서

Access scope should be restricted before search, not after vector search when permissions are checked.

Minimize Metadata

Original text, email addresses, social security numbers, API keys, etc., should not be unnecessarily stored in the vector DB.

Keep Search Scores Private

Detailed similarity scores can be used by attackers for iterative inference.

It is best not to expose scores to external users if not necessary.

Query Rate Limiting

The following controls are needed to prevent attackers from comparing thousands of candidate sentences:

Rate limiting
사용자별 요청 제한
이상 질의 탐지
반복 패턴 탐지

Encrypt Both Embeddings and Original Text

Vectors are not original text, but they can contain sensitive information.

Therefore, embedding data should be protected at the same level as the original text.

저장 데이터 암호화
전송 구간 암호화
키 관리
접근 로그
권한 분리

Conclusion

Embedding vectors are not just random numbers.

They contain the semantic features of the original text, so with appropriate auxiliary information, attacks like the following are possible:

후보 문장 비교
최근접 이웃 검색
임베딩 역변환 모델
속성 추론
멤버십 추론
검색 API 반복 분석
메타데이터 탈취

However, simply reversing a vector does not mean the original text comes out as is.

More precisely, it is as follows:

Embeddings are not ciphers that can directly decrypt the original text, but if an attacker obtains the model, candidate data, search interface, and metadata, they can infer the meaning or sensitive attributes of the original text.

In practice, failures in vector DB access control, tenant separation errors, metadata exposure, and original text linkage information leakage can pose more direct risks than embedding reverse-engineering itself.

Therefore, embedding vectors should be treated not as simple search data but as sensitive information at a level similar to the original text.

Can the original text be fully restored by reverse-engineering embedding vectors?