A core component of generative artificial intelligence (AI) applications is embeddings, which transform complex, high-dimensional data into a format that AI models can effectively process. This paper explores the role of embeddings in generative AI, compares popular embedding models, and provides guidelines for selecting the right embedding model for specific use cases and security.

The Role of Embeddings in Generative AI

Our paper, Securing Vector Databases, introduces the concepts of embeddings in machine learning and AI implementations. Vector embeddings are mathematical representations of objects—typically words or other data points—in a continuous, multi-dimensional space. These embeddings are designed so that the position of each vector (a point in this space) reflects the semantic or contextual relationships between the objects they represent.

The selection of an appropriate embedding technique and embedding model should be informed by several factors, including available computational resources, dataset scale, security, privacy requirements, and the desired level of accuracy. Each method presents its own set of trade-offs, and the optimal choice will depend on the specific requirements of the task at hand.

Types of Embeddings Models

Embedding models generate embeddings, which are vector representations that capture the semantic meaning of data. These models transform input data (like text or images) into a format that machine learning algorithms can effectively process. There are many types of embedding models, ranging from traditional implementations to more advanced neural network models and transformer models.

Term Frequency-Inverse Document Frequency (TF-IDF) and Principal Component Analysis (PCA) are examples of traditional embedding methods. TF-IDF assesses the words within a document corpus and determines their relative importance for text mining or information retrieval tasks. PCA is a dimensionality reduction technique that preserves maximal variance while minimizing the feature set, thereby facilitating data visualization and noise reduction.

Figure 1 is a heatmap that was created using the Python seaborn library to visualize the TF-IDF scores. The features of this heatmap represent the following information:

• Terms (x-axis): These words were extracted from the documents and identified as important based on their TF-IDF scores.
• Documents (y-axis): Each row corresponds to a document from the sample data of Omar’s Document Collection, which includes information about different vulnerabilities.
• Color Intensity: Darker colors indicate higher TF-IDF scores, meaning the term is more important in that document. (SQL injection was the main topic in those documents.)

Figure 1: Heatmap of TF-IDF Scores

Neural network embedding models, such as Word2Vec and FastText, are more sophisticated than traditional models. These embeddings represent words or phrases in a fixed-size vector space, where words that are semantically similar are positioned closer together. For example, Word2Vec uses a shallow neural network to map words into a continuous vector space, where semantic similarity is reflected in vector proximity. FastText was developed by Facebook's AI Research team and builds upon Word2Vec by incorporating subword information. The FastText GitHub repository was archived in 2024 because newer and more powerful models now exist.

Advanced transformer models are used to generate context-dependent embeddings. Their embeddings incorporate attention mechanisms that allow them to weigh the relevance of different words in a sentence based on their context, leading to context-aware embeddings. These models—such as Cohere, OpenAI, GPT, and others that are featured in the Massive Text Embedding Benchmark (MTEB)—produce more nuanced and flexible representations that are particularly suited for complex language understanding tasks.

Commercial Tools

There are commercial tools available for embeddings. In addition to ChatGPT, Open AI also provides embedding models for different applications. Cohere is a company that specializes in creating embedding models and other models for AI applications.

Cohere's Embed service supports embedding models that can generate vector representations of text or classify text according to various criteria. When coupled with classification tools such as their Classify endpoint, these embeddings become even more powerful. They can be applied to a wide range of classification and analytical tasks.

Figure 2: An Example of Embeddings Created Using Cohere’s Playground

Hugging Face Embedding Models

Hugging Face offers a wide range of embeddings covering text, image, audio, and multimodal data from various models. These models can be finetuned using custom data to generate task-specific embeddings. However, some features require logging in, and the platform is less flexible than open-source options.

How Vector Embeddings Work

In vector embeddings, each object (e.g., a word, phrase, sentence, or image) is converted into a vector of numbers. This vector is a fixed length and typically has dozens or hundreds of dimensions, depending on the complexity of the model.

Figure 3: Embeddings Projector from the TensorFlow Project
An example of a graphic representation of high-dimensional embeddings

The key idea behind embeddings is that objects with similar meanings or functions will have similar vector representations. For example, in the context of word embeddings, the vectors for "CVE" and "vulnerability" would be closer to each other in the embedding space than "knight" and "server-side."

Vector embeddings are usually learned through machine learning models. For example, large corpora of text may be used to train word embeddings to predict a word based on its context (e.g., surrounding words). Through this process, the model learns to position words with similar meanings close to each other in the vector space.

External Use vs. Internal Use

Large language models (LLMs) and small language models (SLMs) internally convert their inputs into vector embeddings to process and generate responses. These embeddings are typically confined to the model's internal computations and are not exposed for external use. The key distinction with dedicated embedding models lies in their purpose and utility: embedding models are specifically designed to produce embeddings that are useful outside the internal operations of a single LLM.

Embedding models generate vector representations that capture the semantic essence of the input data, making them highly valuable for a variety of external applications. For instance, these embeddings can be used in semantic search, recommendation systems, clustering, classification, and cross-modal retrieval.

In contrast, the embeddings within an LLM are transient and optimized for the model's immediate task of understanding and generating language, without the necessity for external applicability. Embedding models, therefore, serve as a bridge between raw data and various downstream applications, enabling interoperability and facilitating tasks that require a deep understanding of semantic relationships.

Understanding Cosine vs. Euclidean Distance in Embeddings

Figure 4 demonstrates how semantically similar inputs result in embeddings that are closer in vector space. As the sentences become more similar to the first, the cosine similarities of their embeddings gradually increase. Although it has an entirely different structure than the first sentence, the last sentence has the most similar semantics. Therefore, its embedding is closest to the first sentence in vector space.

Figure 4: Code Example of Semantic Similarity and Proximity

Two popular methods for measuring the similarity or distance between embeddings are cosine similarity (or distance) and Euclidean distance. Cosine similarity measures the cosine of the angle between two vectors in a multi-dimensional space. It is calculated using the dot product of the two vectors divided by the product of their magnitudes:

cosine_similarity(A, B) = (A · B) / (∣∣A∣∣ ∗ ∣∣B∣∣)
Where:
A · B is the dot product of vectors A and B
∣∣A∣∣ and ∣∣B∣∣ are the magnitudes (lengths) of vectors A and B

Cosine distance is simply 1 minus the cosine similarity:

cosine_distance(A, B) = 1 - cosine_similarity(A, B)

Cosine similarity ranges from -1 to 1, where 1 indicates identical direction, 0 indicates orthogonality, and -1 indicates opposite directions. Cosine distance ranges from 0 to 2.

Direction-sensitive measures evaluate the orientation of vectors by focusing on the angles between them, disregarding their magnitudes. For example, let’s say you have two arrows on a graph, each pointing in a certain direction with a certain length. Direction-sensitive measures pay attention only to which way the arrows are pointing, not how long they are, and focus on the angle between the arrows to see how their directions compare. These measures ignore length, even if one arrow is much longer than the other.

If both arrows are pointing straight up, they have the same direction, even if one is longer. If one arrow points up and the other points to the right, the angle between them shows that their directions are different. So, when we use direction-sensitive measures, we're interested in the orientation of the arrows (which way they point) and not their magnitude (how long they are).

Figure 5: 3D Visualization of the Cosine Similarity of Vector Embeddings with PCA

Euclidean distance is the ordinary straight-line distance between two points in Euclidean space. It is calculated using the Pythagorean formula:

Euclidean_distance(A, B) = sqrt(sum((A_i - B_i)^2))
Where A_i and B_i are the i-th components of vectors A and B

Euclidean distance is always non-negative and can range from 0 to infinity. It is a magnitude-sensitive component that considers both direction and magnitude of the vectors.

When to Use Cosine vs Euclidean Distance

Use cosine similarity when you are more interested in the orientation (direction) of the vectors than in their magnitudes. You can also use it when working with text documents of varying lengths because cosine similarity normalizes for document length.

Use Euclidean distance when the magnitude of the vectors is important for your analysis and when you are working in lower-dimensional spaces where Euclidean distance is more intuitive.

There's no one-size-fits-all solution, and sometimes it is worth experimenting with both measures to see which one performs better for your particular problem.

Selecting and Securing Embedding Models

Selecting the right embedding model depends on several factors, including the use case, computational requirements, security, and privacy. Embedding models are key to effective retrieval augmented generation (RAG). They enable the system to understand and match the semantics of queries with relevant documents, enhancing the generation of responses in tasks like question answering or in AI conversational systems.

Embedding models significantly improve the accuracy and relevance of search results by capturing the essence of words or phrases in a continuous vector space. But there can be challenges. Word embeddings often suffer from data sparsity, where infrequent words or phrases are poorly represented. Over time, the meanings of words can change, a phenomenon known as semantic drift. This can cause embeddings to become outdated, reducing their effectiveness in capturing current semantic relationships.

The following are some considerations when selecting embedding models:

• Choose an embedding model that is well-suited for your specific task. For instance, if you're working on sentiment analysis, models that capture contextual nuances like OpenAI’s embeddings, Cohere, and newer models might be more appropriate than traditional word embeddings like Word2Vec.
• Select the appropriate model for domain-specific tasks. For specialized fields like networking and cybersecurity, or for medical and legal texts, domain-specific embeddings that are trained on relevant data can provide better performance than general-purpose models.
• If your application deals with niche vocabulary or requires specific nuances, training your own embeddings might be necessary.
• If your application needs to handle multiple languages, consider models that support multilingual embeddings.
• Higher-dimensional embeddings can capture more information but at the cost of increased computational resources. Selecting the optimal dimensionality involves balancing performance with efficiency.
• High-dimensional embeddings can also lead to increased computational complexity, making them less practical for real-time applications.
• Consider the licensing terms for each model. Open-source models are generally free to use, while proprietary models may offer better performance, but at a cost.

Sensitive Data and External Services

Embedding models often require sending data to external servers for processing, raising privacy concerns. When you send data to an external service for embedding, that data leaves your controlled environment. Some model providers may use your data to further train or improve their own models. This means your data could indirectly contribute to the model's knowledge base. If your data contains confidential or personally identifiable information (PII), sending it to an external service could violate privacy regulations or company policies.

Further, a security breach of the service provider could result in the compromise of your sensitive data. Data is valuable, so model service providers are inclined to retain it for as long as feasible. A compromise of the service provider that occurs years in the future could result in your sensitive data being exposed: a painful reminder that your embedding model once leaked sensitive data.

Note: It's important to understand the difference between embedding models and AI models that are used for inference and the security concerns for each. If an embedding model is trained on sensitive data (like source code or confidential company documents), it can inadvertently memorize and expose that data through the embedding process. This can lead to leakage when those embeddings are used or shared, potentially allowing unauthorized access to sensitive information. AI models used for inference can also introduce risks if they use embeddings that contain sensitive information. If an adversary can exploit these models, they might extract sensitive data through techniques such as model inversion attacks.

Embeddings Inversion Attacks

Embeddings are essentially a machine representation of the original data, meaning they can be as sensitive as the data used to create them. This equivalence makes them a prime target for data theft and privacy attacks. The purpose of encryption is to make it difficult to obtain information about an input; the purpose of embeddings is exactly the opposite—to provide as much information about the input as possible!

Embeddings can be vulnerable to inversion attacks, where attackers can reconstruct the original data from the embeddings. (See Understanding Privacy Risks of Embeddings Induced by Large Language Models for an example.) This introduces a significant risk, especially for sensitive data like source code, intellectual property, or personal information.

In Text Embeddings Reveal (Almost) As Much As Text, Morris et al. explain how they trained a model to recover up to 92% of the original text from embeddings. Notably, they were able to recover PII from embedded clinical notes.

Figure 6 demonstrates the usage of ielabgroup’s Hugging Face instance of Morris’s Vec2Text model. The tokens were encoded with the sentence-transformers/gtr-t5-base model. The encoding was reversed with a model specifically trained to reverse encodings from gtr-t5-base back to their original tokens.

In this example code, we embedded some information about Justin, including his name, a password, the company he works for, and his favorite color. The output is garbled because some of the structural information about the order of words in the text was lost in the process of encoding the sentence to an embedding and back. However, the final output contains enough of the original information that it wouldn’t take an attacker long to learn Justin’s name, guess his password, identify the company he works for, and see his favorite color based off of the reversed embedding. This example shows that enough information can be revealed from embeddings to be useful to a bad actor and harmful to your organization.

Figure 6: Using a Vec2Text Model to Reverse Encodings

Because they are designed to encode as much information as possible from their original inputs, you must treat the sensitivity of embeddings as equivalent to the data from which they are derived.

Developing Embeddings

This section gives an overview of the basic process for using an embedding model for a large corpus. We begin with a single vector, and then we create a chucking method to increase efficiency. Finally, we'll look at ways we can maximize the relevance of search results and scale up our model.

Stage 1: Using a Single Vector

Let’s start with the most straightforward method: embedding an entire document into a single vector. This approach is appealing due to its simplicity and minimal storage requirements. Let's say we have 10,000 documents, and we want to be able to cheaply search them for semantic meaning by building a sort of semantic index that is more reliable than a keyword search.

Embedding Model: We use a high-dimensional embedding model, such as one that produces 4,096-dimensional vectors (like llama3), to capture as much semantic information as possible from the large document.

Embedding Size: Each dimension is represented as a 32-bit float (4 bytes). Thus, the embedding size is:

4,096 dimensions x 4 bytes = 16 KB

Metadata: Assume 1 KB for metadata (e.g., document ID, title)

Total Storage:

16 KB (embedding) + 1 KB (metadata) = 17 KB
1,000 Documents: 17 KB x 1,000 = 17 MB
10,000 Documents: 17 KB x 10,000 = 170 MB

Monthly Storage Cost: The storage costs for such solutions are minimal. We can opt for the lowest tier of any service provider and perform an analysis with considerations for high-availability and multi-region support.

Performance Considerations: While this approach is cost-effective and easy to implement, it has significant performance drawbacks:

• Lack of granularity: A single vector cannot capture the nuanced topics and subtopics within the document.
• Poor search accuracy: Searching for specific information within documents yields low relevance because the embeddings are too coarse.
• Lack of scalability: As the number of documents increases, the embeddings become less distinctive, making it harder to retrieve relevant documents accurately. Users may experience frustration due to irrelevant search results.

Considerations for Improvement: Although we used a high-dimensional model, the single-vector approach still lacks detail. To enhance accuracy, we need a strategy that provides more granular representations of the document’s content.

Stage 2: Creating Your Chunking Strategy

Recognizing the limitations of a single embedding, we move to a more detailed approach of splitting the document into smaller chunks and embedding each one separately.

Chunking is an important step that influences the selection of an embedding model. The way we break down our text data determines the type of embedding that will be most effective for our application. Therefore, when selecting an embedding model, we must consider how we plan to chunk our text to ensure compatibility and optimal performance.

Which method we use for chunking depends on the data and how it will be searched. The embedding model also makes a difference here. The only way to know which method is best is to test different approaches for our data and let end users provide feedback in the early stages. We will just use a general strategy to demonstrate.

Chunk Size: We split documents into chunks of 1,000 characters.

Overlap: We include a 100-character overlap between chunks to preserve context.

Embedding Model: We continue using the 4,096-dimensional embedding model to capture detailed semantics within each chunk and to demonstrate the worst-case scenario of storage costs. The model used for this might be different than the model used for embedding the entire document. It is important should test different models and dimensions.

Total Characters in Document: 10 MB document ≈ 10 million characters.

Number of Chunks per Document:

10,000,000 characters	= 10,000 chunks
1,000 characters per chunk

Embedding Size per Chunk: 4,096 dimensions x 4 bytes = 16 KB

Metadata per Chunk: 1 KB
Total Storage per Chunk: 16 KB + 1 KB = 17 KB

Total Storage per Document:

17 KB x 10,000 chunks = 170 MB
1,000 Documents: 170 MB x 1,000 = 170 GB
10,000 Documents: 170 MB x 10,000 = 1,700 GB (1.7 TB)

Storage Costs: For 1,000 Documents, we would require storage in the medium compute tier, which might be around $700 a month (40–400 GB). For 10,000 Documents, the storage needs would exceed the maximum compute tier, potentially costing $1,100 a month or more.

Performance Improvements:

• Increased Granularity: Each chunk represents a specific part of the document, improving the relevance of search results.
• Better Contextual Understanding: Overlapping chunks help maintain the flow of information, aiding in semantic understanding.
• Enhanced Search Accuracy for Large Corpora: Users can find specific information across thousands of documents more effectively.

Scalability Concerns: Storage costs increase significantly with the number of documents.

Considerations for Embedding Model Selection: High-dimensional embeddings are suitable for capturing complex information in each chunk. But the costs can get out of control very quickly. Such a large number of dimensions might not be necessary. Evaluate lower-dimensional models (e.g., 2,048 dimensions) to see if they can provide similar performance with reduced storage. There is much less semantic meaning in smaller chunks, depending on the data and model. It may be possible to go as low as 386 for the chunks, which would significantly reduce costs. For this example, that would be less than 200GB of storage, which is 20% of the cost of using the larger dimensions.

Stage 3: Maximizing Relevance with Questions

Generating and embedding questions that are related to each chunk will further enhance the application’s ability to retrieve relevant information. Because each question will likely be short and may not have much semantic variance, we can probably use a much lower-dimension model that is geared toward questions. Let’s use a model that is 512 dimensions for this portion.

Question Generation: We use a language model to generate 20 questions that encapsulate the key points of each chunk. These questions serve as semantic summaries, aiding in matching user queries with the most relevant content. We may want to use a few different models to generate the questions for this portion.

Total Questions per Document: 10,000 chunks x 20 questions = 200,000 questions

Embedding Size per Question: 512 dimensions x 4 bytes = 2 KB

Metadata per Question: 1 KB
Total Storage per Question: 2 KB + 1 KB = 3 KB

Total Storage for Questions per Document:

3 KB x 200,000 questions = 600 MB

Total Storage per Document (Chunks + Questions):

170 MB (chunks) + 600 MB (questions) = 770 MB
1,000 Documents: 770 MB x1,000 = 770 GB
10,000 Documents: 770 MB x10,000 = 7,700 GB (7.7 TB)

Cost Implications:

• For 1,000 documents, the storage needs would be well beyond the high compute tier, leading to significantly higher costs.
• For 10,000 documents, the storage would require enterprise-level solutions with substantial monthly costs.

Performance Improvements:

• Improved Relevance: Embedding generated questions enriches the semantic network, improving the system’s ability to match user queries.
• Superior Search Accuracy for Large Corpora: Users can find highly relevant information even in vast document collections.

Cost Challenges: The storage requirements may become prohibitively expensive.

Stage 4: Scaling Up for Large Document Corpora

As we scale from one document to thousands, the choices made in embedding strategies have a magnified impact. Storage requirements increase linearly with the number of documents. Moving into higher storage tiers incurs significantly higher costs.

Performance Benefits vs. Costs

• Diminishing Returns: The incremental improvement in search accuracy may not justify the exponential increase in costs.
• User Expectations: Balance the desired performance level with what users actually need.

Strategic Considerations

• Prioritize High-Value Documents: Allocate more resources to documents that are most critical.
• Optimize Query Handling: Use caching and efficient retrieval algorithms to reduce computational load.
• Monitor Usage Patterns: Analyze how users interact with the system to optimize accordingly.

Testing and Optimizing Embedding Models for Efficient System Operation

Let's go over a few recommendations for testing embedding models and optimizing their dimensions to enhance performance while minimizing resource consumption.

Performance Metrics

To evaluate embedding models effectively, it is important to consider multiple performance metrics:

• Search Accuracy: How well the model retrieves relevant results based on input queries.
• Relevance: The model's ability to prioritize meaningful relationships within the data.
• Computational Efficiency: The resource usage and processing time required by the model.

These metrics provide a comprehensive view of the model's capabilities and limitations.

Figure 7 shows an example of metrics and tools that can be used to assess embedding model performance in Microsoft Azure AI Studio.

Figure 7: Tools in Microsoft Azure AI Studio

A/B Testing

A/B testing involves comparing two versions of a model to determine which performs better under identical conditions. This method helps in:

• Identifying the most effective algorithms or configurations.
• Understanding the impact of changes on user experience.
• Making data-driven decisions for model improvements.

By systematically testing different models or strategies, organizations can optimize their systems for better performance.

Optimizing Embedding Dimensions

Optimizing the dimensions of embeddings is vital for balancing performance with resource constraints.

• Lower-dimensional embeddings require less memory and computational power.
• Proper dimensionality reduction can eliminate noise and redundant information.

 

Acknowledgements

Authors:

• Omar Santos, Distinguished Engineer, Cisco Security & Trust
• Justin Whitaker, Security Architect, Cisco Security & Trust
• John Groetzinger, Technical Leader, CX

Editor: Diane Morris, Content Manager, Cisco Security & Trust

Revision History

Version	Date	Authors	Comments
1.0	07-Oct-2024	Santos, Whitaker, Groetzinger, Morris	Initial public release.