{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/en/autor/alexander-bock/"},"categories":["AI Development"],"content":{"markdown":"A customer types \"Can I get my money back?\" into your help center. The answer sits in an article called \"Refund policy\", but the keyword search finds nothing, because the two texts share no words. **Embeddings** solve this problem. They turn text into numbers that capture its meaning, so software can find texts that mean the same thing even when the words differ.\n\nThis is part 1 of Level 2 (Intermediate) in our AI Development learning path. You will learn what an embedding is, how similarity search works, what a vector database adds and which settings matter in practice. Part 2 uses all of this to build a [RAG pipeline step by step](/en/ai-development/learn/retrieval-augmented-generation-step-by-step/).\n\n## Embeddings turn meaning into coordinates\n\nAn embedding is a list of numbers, also called a **vector**, that an **embedding model** computes for a piece of text. Typical embedding models return several hundred to a few thousand numbers per text. You can read them as coordinates: every text becomes a point in a space with that many dimensions. Texts with a similar meaning end up close together. Unrelated texts end up far apart.\n\nNobody can picture hundreds of dimensions, so the figure squeezes the idea into two. Each dot is a short support question. The model was never told which topic a question belongs to. The groups appear because similar questions get similar numbers.\n\n![Scatter plot with three groups of support questions — billing, delivery, account — and a new question that lands next to the billing group](/images/learn/en/embeddings-and-vector-databases-map.webp \"Example: support questions as points on a map of meaning, simplified to two dimensions. The new question lands next to the refund topics.\")\n\nThree properties matter in practice:\n\n- **One model per index.** Vectors from different embedding models live in different spaces. You must embed your documents and your search queries with the same model. When you switch models, you embed everything again.\n- **Meaning beats wording.** \"Money back\" and \"refund\" land close together. With a multilingual embedding model, the German \"Rückerstattung\" lands there too.\n- **Similar is not the same as true.** \"The fee is refundable\" and \"The fee is not refundable\" talk about the same thing, so their vectors can be very close. Embeddings find related text. They do not check facts.\n\n## How similarity search works\n\nTo search, you embed the question with the same model and compare its vector with the stored vectors. The closest ones are the best matches. Developers call this a **nearest neighbor search**. The number of results you ask for is called **top-k**, for example the top 5.\n\n\"Close\" is usually measured with **cosine similarity**. It compares the direction of two vectors — in other words, the angle between them. A value of 1 means the same direction. The lower the value, the less related the texts. Some models are built for other measures, such as the dot product or the Euclidean distance. Use the measure that your model's documentation recommends.\n\n![Arrows from one point: the question, a close arrow for the refund policy, a wider angle for shipping times and a large angle for password reset](/images/learn/en/embeddings-and-vector-databases-similarity.webp \"Similarity as an angle: the smaller the angle between two vectors, the more related the texts.\")\n\nTwo practical rules follow from this:\n\n1. **Scores are relative.** A score such as 0.8 means different things for different models. Never copy a threshold from a blog post. Find yours by testing real questions.\n2. **Exact terms need help.** Product codes, names and error numbers such as \"E-4012\" easily get blurred in a vector. Many systems therefore combine vector search with classic keyword search. This is called **hybrid search**.\n\nHere is the whole idea in a few lines of Python. `embed()` stands for any embedding API or local model:\n\n```python\nimport numpy as np\n\ndef cosine(a, b):\n    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))\n\ndocs = [\"Refunds are possible within 30 days.\",\n        \"Shipping takes 2 to 4 business days.\",\n        \"Reset your password under Settings.\"]\ndoc_vectors = [embed(d) for d in docs]        # once, when you build the index\n\nquestion = embed(\"Can I get my money back?\")  # same model for the question!\nscores = [cosine(question, v) for v in doc_vectors]\nbest = scores.index(max(scores))\nprint(docs[best])  # -\u003e \"Refunds are possible within 30 days.\"\n```\n\n## What a vector database adds\n\nWith a few thousand texts, your program can simply compare the question with every vector. With millions of vectors and many users, that gets too slow. A **vector database** stores the vectors and builds an **index** for **approximate nearest neighbor search** (ANN). The index finds almost the best matches, much faster than a full comparison. The price is a small loss of **recall**: now and then, a good match is missed. Common index types are graph-based (HNSW) or cluster-based (IVF). Most databases let you tune the balance between speed and recall.\n\nA vector database stores more than numbers. Each record usually has four parts:\n\n![A record with four labeled parts — ID, vector, text and metadata — and a note on how a query uses them](/images/learn/en/embeddings-and-vector-databases-record.webp \"What a vector database stores for each chunk: an example record.\")\n\nThe **metadata** makes a vector database useful in a real product. With **metadata filters**, you can search only German texts, only documents updated this year, or only documents the current user is allowed to see. The last filter matters most. If search ignores permissions, an AI feature can show confidential content to the wrong person.\n\nYou do not always need a separate database. This table helps you choose:\n\n| Situation | Good option | Why |\n|---|---|---|\n| Prototype or small data set (thousands of chunks) | Search in memory inside your app | No extra service to run |\n| Your data already lives in PostgreSQL | A vector extension such as pgvector | One database, vectors next to your other data |\n| Millions of vectors, many queries, little time for operations | A managed vector database such as Pinecone | The provider runs the index and the scaling |\n| You do not want to build the pipeline yourself | A platform for AI apps on your own data, such as Devs.ai | Apps and agents on your data, according to the vendor |\n\nPinecone is listed in our [tool comparison for AI Development](/en/ai-development/#tools) as a managed vector database:\n\n{{\u003c tool-shot \"pinecone\" \u003e}}\n\nSome teams run an open-source embedding model themselves, for example to keep full control over the model and its version. Small embedding models run on an ordinary CPU. For large batch jobs, GPU clouds such as [Runpod](/en/ai-development/#tool-runpod) rent compute by usage, according to the vendor.\n\n## Chunk size: how much text goes into one vector\n\nLong documents are split into **chunks**, and each chunk gets its own vector. One vector for a 40-page manual would blur all its topics into a single point. Also, the model that later writes an answer needs short, relevant passages, not whole files.\n\nThe size of a chunk is a trade-off:\n\n![Three ways to split the same document: many tiny chunks, chunks along the headings, one large chunk — with their effects](/images/learn/en/embeddings-and-vector-databases-chunks.webp \"Chunk size is a trade-off: too small loses context, too large mixes topics.\")\n\n- **Too small:** a chunk like \"It is valid for 30 days\" has lost its context. What is valid?\n- **Too large:** a chunk that covers refunds, shipping and warranty gets a vague vector. It matches many questions a little and none of them well. It also costs more tokens when you send it to a model later.\n\nA practical starting point: split along the structure of the document (headings, paragraphs, list items), aim for a few hundred **tokens** per chunk, and let neighboring chunks overlap by a sentence or two. Add the document title and the heading to each chunk. Then \"It is valid for 30 days\" becomes \"Refund policy › Deadlines: It is valid for 30 days\". Test with real questions and adjust. If tokens are new to you, read [APIs, tokens and context windows](/en/ai-development/learn/apis-tokens-and-context-windows/) from Level 0 first.\n\n## Where embeddings help beyond chatbots\n\nEmbeddings are best known as a part of RAG, where they find the passages a chatbot needs. But they solve many other problems without generating any text:\n\n| Use case | How embeddings help | Example |\n|---|---|---|\n| Semantic search | Finds matches by meaning, not by keyword | Help center, intranet, product search |\n| Duplicate detection | Very close vectors mean nearly identical content | Merge tickets that describe the same bug |\n| Recommendations | Shows items close to what someone just read | \"Similar articles\" under a blog post |\n| Clustering | Groups thousands of texts into themes | Sort customer feedback into topics |\n| Classification | Compares a new text with labeled examples | Route a ticket to billing or support |\n| Outlier detection | Texts far away from every group stand out | Spot unusual requests in a queue |\n\n{{\u003c callout type=\"try\" \u003e}}\nTest semantic search on your own data. Take 20 answers from your FAQ and embed them. Then write five new questions in your own words, without copying phrases from the answers. Check whether the right answer is in the top 3 results for each question. If it is not, look at the text you embedded first: unclear or overloaded chunks are the most common cause.\n{{\u003c /callout \u003e}}\n\n## Mistakes that cost you later\n\nMost problems with embeddings do not show up in a demo. They appear weeks later, when data changes or the index grows. These six are the most common:\n\n| Mistake | What happens | Better |\n|---|---|---|\n| Switching the embedding model without a new index | Questions and documents live in different spaces; results look random | Store the model name with the index; embed everything again after a switch |\n| Relying on vectors alone | Product codes, names and error numbers get lost | Add keyword search (hybrid search) |\n| Storing vectors without metadata | No filters for language, date or permissions | Save source, date, language and access group with every chunk |\n| Copying a similarity threshold | Too many or too few results | Choose thresholds by testing your own questions |\n| Forgetting updates and deletions | Old or deleted content still shows up | Update or delete vectors whenever the source changes |\n| Treating vectors as harmless numbers | Sensitive text can partly be recovered | Protect vectors like the original text |\n\nThe last point surprises many developers. In one study, researchers reconstructed most short test texts exactly from their embeddings (Source: Morris et al., \"Text Embeddings Reveal (Almost) As Much As Text\", EMNLP 2023, arxiv.org). So if a text is confidential, its vector is confidential too. Store both only in services that your company has approved for that kind of data.","text":"A customer types \u0026ldquo;Can I get my money back?\u0026rdquo; into your help center. The answer sits in an article called \u0026ldquo;Refund policy\u0026rdquo;, but the keyword search finds nothing, because the two texts share no words. Embeddings solve this problem. They turn text into numbers that capture its meaning, so software can find texts that mean the same thing even when the words differ.\nThis is part 1 of Level 2 (Intermediate) in our AI Development learning path. You will learn what an embedding is, how similarity search works, what a vector database adds and which settings matter in practice. Part 2 uses all of this to build a RAG pipeline step by step.\nEmbeddings turn meaning into coordinates An embedding is a list of numbers, also called a vector, that an embedding model computes for a piece of text. Typical embedding models return several hundred to a few thousand numbers per text. You can read them as coordinates: every text becomes a point in a space with that many dimensions. Texts with a similar meaning end up close together. Unrelated texts end up far apart.\nNobody can picture hundreds of dimensions, so the figure squeezes the idea into two. Each dot is a short support question. The model was never told which topic a question belongs to. The groups appear because similar questions get similar numbers.\nExample: support questions as points on a map of meaning, simplified to two dimensions. The new question lands next to the refund topics. Three properties matter in practice:\nOne model per index. Vectors from different embedding models live in different spaces. You must embed your documents and your search queries with the same model. When you switch models, you embed everything again. Meaning beats wording. \u0026ldquo;Money back\u0026rdquo; and \u0026ldquo;refund\u0026rdquo; land close together. With a multilingual embedding model, the German \u0026ldquo;Rückerstattung\u0026rdquo; lands there too. Similar is not the same as true. \u0026ldquo;The fee is refundable\u0026rdquo; and \u0026ldquo;The fee is not refundable\u0026rdquo; talk about the same thing, so their vectors can be very close. Embeddings find related text. They do not check facts. How similarity search works To search, you embed the question with the same model and compare its vector with the stored vectors. The closest ones are the best matches. Developers call this a nearest neighbor search. The number of results you ask for is called top-k, for example the top 5.\n\u0026ldquo;Close\u0026rdquo; is usually measured with cosine similarity. It compares the direction of two vectors — in other words, the angle between them. A value of 1 means the same direction. The lower the value, the less related the texts. Some models are built for other measures, such as the dot product or the Euclidean distance. Use the measure that your model\u0026rsquo;s documentation recommends.\nSimilarity as an angle: the smaller the angle between two vectors, the more related the texts. Two practical rules follow from this:\nScores are relative. A score such as 0.8 means different things for different models. Never copy a threshold from a blog post. Find yours by testing real questions. Exact terms need help. Product codes, names and error numbers such as \u0026ldquo;E-4012\u0026rdquo; easily get blurred in a vector. Many systems therefore combine vector search with classic keyword search. This is called hybrid search. Here is the whole idea in a few lines of Python. embed() stands for any embedding API or local model:\nimport numpy as np def cosine(a, b): return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)) docs = [\u0026#34;Refunds are possible within 30 days.\u0026#34;, \u0026#34;Shipping takes 2 to 4 business days.\u0026#34;, \u0026#34;Reset your password under Settings.\u0026#34;] doc_vectors = [embed(d) for d in docs] # once, when you build the index question = embed(\u0026#34;Can I get my money back?\u0026#34;) # same model for the question! scores = [cosine(question, v) for v in doc_vectors] best = scores.index(max(scores)) print(docs[best]) # -\u0026gt; \u0026#34;Refunds are possible within 30 days.\u0026#34; What a vector database adds With a few thousand texts, your program can simply compare the question with every vector. With millions of vectors and many users, that gets too slow. A vector database stores the vectors and builds an index for approximate nearest neighbor search (ANN). The index finds almost the best matches, much faster than a full comparison. The price is a small loss of recall: now and then, a good match is missed. Common index types are graph-based (HNSW) or cluster-based (IVF). Most databases let you tune the balance between speed and recall.\nA vector database stores more than numbers. Each record usually has four parts:\nWhat a vector database stores for each chunk: an example record. The metadata makes a vector database useful in a real product. With metadata filters, you can search only German texts, only documents updated this year, or only documents the current user is allowed to see. The last filter matters most. If search ignores permissions, an AI feature can show confidential content to the wrong person.\nYou do not always need a separate database. This table helps you choose:\nEmbeddings and Vector Databases Explained Situation Good option Why Prototype or small data set (thousands of chunks) Search in memory inside your app No extra service to run Your data already lives in PostgreSQL A vector extension such as pgvector One database, vectors next to your other data Millions of vectors, many queries, little time for operations A managed vector database such as Pinecone The provider runs the index and the scaling You do not want to build the pipeline yourself A platform for AI apps on your own data, such as Devs.ai Apps and agents on your data, according to the vendor Pinecone is listed in our tool comparison for AI Development as a managed vector database:\nPinecone: Vector database for AI applications such as search and retrieval. Image: source pinecone.io. Pinecone in our comparison → Some teams run an open-source embedding model themselves, for example to keep full control over the model and its version. Small embedding models run on an ordinary CPU. For large batch jobs, GPU clouds such as Runpod rent compute by usage, according to the vendor.\nChunk size: how much text goes into one vector Long documents are split into chunks, and each chunk gets its own vector. One vector for a 40-page manual would blur all its topics into a single point. Also, the model that later writes an answer needs short, relevant passages, not whole files.\nThe size of a chunk is a trade-off:\nChunk size is a trade-off: too small loses context, too large mixes topics. Too small: a chunk like \u0026ldquo;It is valid for 30 days\u0026rdquo; has lost its context. What is valid? Too large: a chunk that covers refunds, shipping and warranty gets a vague vector. It matches many questions a little and none of them well. It also costs more tokens when you send it to a model later. A practical starting point: split along the structure of the document (headings, paragraphs, list items), aim for a few hundred tokens per chunk, and let neighboring chunks overlap by a sentence or two. Add the document title and the heading to each chunk. Then \u0026ldquo;It is valid for 30 days\u0026rdquo; becomes \u0026ldquo;Refund policy › Deadlines: It is valid for 30 days\u0026rdquo;. Test with real questions and adjust. If tokens are new to you, read APIs, tokens and context windows from Level 0 first.\nWhere embeddings help beyond chatbots Embeddings are best known as a part of RAG, where they find the passages a chatbot needs. But they solve many other problems without generating any text:\nEmbeddings and Vector Databases Explained (2) Use case How embeddings help Example Semantic search Finds matches by meaning, not by keyword Help center, intranet, product search Duplicate detection Very close vectors mean nearly identical content Merge tickets that describe the same bug Recommendations Shows items close to what someone just read \u0026ldquo;Similar articles\u0026rdquo; under a blog post Clustering Groups thousands of texts into themes Sort customer feedback into topics Classification Compares a new text with labeled examples Route a ticket to billing or support Outlier detection Texts far away from every group stand out Spot unusual requests in a queue ▸Try it\nTest semantic search on your own data. Take 20 answers from your FAQ and embed them. Then write five new questions in your own words, without copying phrases from the answers. Check whether the right answer is in the top 3 results for each question. If it is not, look at the text you embedded first: unclear or overloaded chunks are the most common cause.\nMistakes that cost you later Most problems with embeddings do not show up in a demo. They appear weeks later, when data changes or the index grows. These six are the most common:\nEmbeddings and Vector Databases Explained (3) Mistake What happens Better Switching the embedding model without a new index Questions and documents live in different spaces; results look random Store the model name with the index; embed everything again after a switch Relying on vectors alone Product codes, names and error numbers get lost Add keyword search (hybrid search) Storing vectors without metadata No filters for language, date or permissions Save source, date, language and access group with every chunk Copying a similarity threshold Too many or too few results Choose thresholds by testing your own questions Forgetting updates and deletions Old or deleted content still shows up Update or delete vectors whenever the source changes Treating vectors as harmless numbers Sensitive text can partly be recovered Protect vectors like the original text The last point surprises many developers. In one study, researchers reconstructed most short test texts exactly from their embeddings (Source: Morris et al., \u0026ldquo;Text Embeddings Reveal (Almost) As Much As Text\u0026rdquo;, EMNLP 2023, arxiv.org). So if a text is confidential, its vector is confidential too. Store both only in services that your company has approved for that kind of data.\n","words":1653},"date":"2026-10-14","description":"How embeddings turn text into coordinates of meaning, how similarity search works and what a vector database adds: index, filters and chunks.","image":"https://abxk.ai/images/cover/embeddings-and-vector-databases.webp","json":"https://abxk.ai/en/ai-development/learn/embeddings-and-vector-databases/index.json","kind":"page","language":"en","learning_path":{"category":"ai-development","level":2,"level_name":"Intermediate"},"modified":"2026-10-14","related_tools":["Pinecone","Devs.ai","Runpod"],"section":"ai-development","tags":["embeddings","vector-database","semantic-search","retrieval"],"title":"Embeddings and Vector Databases Explained","translations":[{"json":"https://abxk.ai/de/ai-development/learn/embeddings-and-vector-databases/index.json","language":"de","url":"https://abxk.ai/de/ai-development/learn/embeddings-and-vector-databases/"}],"url":"https://abxk.ai/en/ai-development/learn/embeddings-and-vector-databases/"}