mirror of
https://github.com/qdrant/landing_page.git
synced 2026-09-25 22:18:30 +02:00
fixing structure
This commit is contained in:
@@ -26,15 +26,13 @@ tags:
|
||||
|
||||
Language models have exploded on the internet ever since ChatGPT came out, and rightfully so. They can write essays, code entire programs, and even make memes (though we’re still deciding on whether that's a good thing).
|
||||
|
||||
But as brilliant as these chatbots become, they still have limitations in tasks requiring external knowledge and factual information. Yes, it can describe the honeybee's waggle dance in excruciating detail. But it becomes far more valuable for us if it can also generate insights from any data that we want rather than just from its original training data.
|
||||
But as brilliant as these chatbots become, they still have **limitations** in tasks requiring external knowledge and factual information. Yes, it can describe the honeybee's waggle dance in excruciating detail. But they become far more valuable if they can generate insights from **any data** that we provide, rather than just their original training data. Since retraining those large language models from scratch costs millions of dollars and takes months, we need better ways to give our existing LLMs access to our custom data.
|
||||
|
||||
While you could be more creative with your prompts, it is only a short-term solution. LLMs can consider only a **limited** amount of text in their responses, known as a [context window](https://www.hopsworks.ai/dictionary/context-window-for-llms). Some models like GPT-3 can see up to around 12 pages of text (that’s 4,096 tokens of context). That’s not good enough for most knowledge bases.
|
||||
|
||||

|
||||
|
||||
|
||||
The image above shows how a basic RAG system works. Before forwarding the question to the LLM, we have a layer that searches our knowledge base for the “relevant knowledge” to answer the user query. Specifically, in this case, the spending data from the last month. Our LLM can now generate a relevant non-hallucinated response about our budget.
|
||||
|
||||
While you could be more creative with your prompts, it is only a short-term solution. LLMs can consider only a limited amount of text in their responses, known as a [context window](https://www.hopsworks.ai/dictionary/context-window-for-llms). Some models like GPT-3 can see up to around 12 pages of text (that’s 4,096 tokens of context). That’s not good enough for most knowledge bases.
|
||||
The image above shows how a basic RAG system works. Before forwarding the question to the LLM, we have a layer that searches our knowledge base for the "relevant knowledge" to answer the user query. Specifically, in this case, the spending data from the last month. Our LLM can now generate a **relevant non-hallucinated** response about our budget.
|
||||
|
||||
As your data grows, you’ll need efficient ways to identify the most relevant information for your LLM's limited memory. This is where you’ll want a proper way to store and retrieve the specific data you’ll need for your query, without needing the LLM to remember it.
|
||||
|
||||
@@ -43,17 +41,17 @@ Vector databases store information as vector embeddings. This format supports ef
|
||||
This article will focus on RAG systems and architecture. If you’re interested in learning more about vector search, we recommend the following articles: [What is a Vector Database?](https://qdrant.tech/articles/what-is-a-vector-database/) and [What are Vector Embeddings?](https://qdrant.tech/articles/what-are-embeddings/).
|
||||
|
||||
|
||||
# RAG architecture
|
||||
## RAG architecture
|
||||
|
||||
At its core, a RAG architecture includes the retriever and the generator. Let's start by understanding what each of these components does.
|
||||
At its core, a RAG architecture includes the **retriever** and the **generator**. Let's start by understanding what each of these components does.
|
||||
|
||||
|
||||
# The Retriever
|
||||
### The Retriever
|
||||
|
||||
When you ask a question to the retriever, it uses vector search to scan through a vast knowledge base. It then pulls out the most relevant pieces of information to help answer that query. There are a few different techniques it can use to know what’s relevant:
|
||||
When you ask a question to the retriever, it uses **similarity search** to scan through a vast knowledge base of vector embeddings. It then pulls out the most **relevant** vectors to help answer that query. There are a few different techniques it can use to know what’s relevant:
|
||||
|
||||
|
||||
## How indexing works in RAG retrievers
|
||||
#### How indexing works in RAG retrievers
|
||||
|
||||
The indexing process organizes the data into your vector database in a way that makes it easily searchable. This allows the RAG to access relevant information when responding to a query.
|
||||
|
||||
@@ -71,7 +69,7 @@ As shown in the image above, here’s the process:
|
||||
All the generated vector embeddings are stored in a knowledge base of indexed information. This supports efficient retrieval of similar pieces of information when needed.
|
||||
|
||||
|
||||
## Query vectorization
|
||||
#### Query vectorization
|
||||
|
||||
Once you have vectorized your knowledge base you can do the same to the user query. When the model sees a new query, it converts this query into a vector using a similar process.
|
||||
|
||||
@@ -79,12 +77,12 @@ We use the same preprocessing and embedding techniques. This ensures that the qu
|
||||
|
||||

|
||||
|
||||
## Retrieval of relevant documents
|
||||
#### Retrieval of relevant documents
|
||||
|
||||
Using the query vector, the system then starts the search to find the most relevant document snippets or passages. We can use the following techniques to find relevant information:
|
||||
|
||||
|
||||
### Sparse vector representations
|
||||
##### Sparse vector representations
|
||||
|
||||
A sparse vector is characterized by a high dimensionality, with most of its elements being zero.
|
||||
|
||||
@@ -99,14 +97,14 @@ The classic approach is keyword search, which is scanning documents for the exac
|
||||
If you’re interested in going deeper, refer to our article on [Sparse Vectors](https://qdrant.tech/articles/sparse-vectors/).
|
||||
|
||||
|
||||
### Dense vector embeddings
|
||||
##### Dense vector embeddings
|
||||
|
||||
This approach uses large language models like [BERT](https://en.wikipedia.org/wiki/BERT_(language_model)) to encode the query and passages into dense vector embeddings. These models are compact numerical representations that capture semantic meaning. Vector databases like Qdrant store these embeddings, allowing retrieval based on semantic similarity rather than just keywords using distance metrics like cosine similarity.
|
||||
|
||||
This allows the retriever to match based on semantic understanding rather than just keywords. So if I ask about "compounds that cause BO," it can retrieve relevant info about "molecules that create body odor" even if those exact words weren't used. We explain more about it in our [What are Vector Embeddings](https://qdrant.tech/articles/what-are-embeddings/) article.
|
||||
|
||||
|
||||
### Hybrid search
|
||||
#### Hybrid search
|
||||
|
||||
However, neither keyword search nor this type of semantic vector search is perfect. Keyword search may miss relevant information expressed differently, while vector search can sometimes struggle with specificity or neglect important statistical word patterns. Hybrid methods aim to combine the strengths of different techniques.
|
||||
|
||||
@@ -126,7 +124,7 @@ Some common hybrid approaches include:
|
||||
When you combine the powers of different search methods in a complementary way, you can provide higher quality, more comprehensive results. Check out our article on [Hybrid Search](https://qdrant.tech/articles/hybrid-search/) if you’d like to learn more.
|
||||
|
||||
|
||||
# The Generator
|
||||
### The Generator
|
||||
|
||||
With the top relevant passages retrieved, it's now the generator's job to produce a final answer by synthesizing and expressing that information in natural language. The generator is typically a large pre-trained language model like GPT, BART or T5.
|
||||
|
||||
@@ -142,7 +140,7 @@ So the generator takes not only the query as input but also the relevant documen
|
||||
There are two main ways the generator can incorporate this retrieved-context:
|
||||
|
||||
|
||||
## Sequence-to-sequence (Seq2Seq) approach
|
||||
#### Sequence-to-sequence (Seq2Seq) approach
|
||||
|
||||
Imagine you have the query "What causes body odor?" and the retriever returns a relevant passage about compounds that create smell. In the seq2seq approach, the generator is given the query and the full retrieved passage together as a single long string of text as input.
|
||||
|
||||
@@ -151,7 +149,7 @@ For example: Input = "What causes body odor? <passage> Certain compounds like
|
||||
The generator then treats this as a standard seq2seq task - taking the whole input sequence and generating the output answer sequence token-by-token from start to end.
|
||||
|
||||
|
||||
## Token-by-token approach
|
||||
#### Token-by-token approach
|
||||
|
||||
In this method, the query and retrieved passages are kept separate. Every time the model generates an answer, the model can examine different portions of the retrieved passages as relevant context.
|
||||
|
||||
@@ -170,15 +168,10 @@ The token-by-token approach allows more flexible referencing of the evidence, bu
|
||||
The retriever and generator don't operate in isolation - they are connected modules where the output of one feeds into the other to produce the final generated response. The image above shows how they’re integrated.
|
||||
|
||||
|
||||
|
||||
<p id="gdcalert7" ><span style="color: red; font-weight: bold">>>>>> gd2md-html alert: inline image link here (to images/image7.png). Store image on your image server and adjust path/filename/extension if necessary. </span><br>(<a href="#">Back to top</a>)(<a href="#gdcalert8">Next alert</a>)<br><span style="color: red; font-weight: bold">>>>>> </span></p>
|
||||
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
# RAG at scale
|
||||
### RAG at scale
|
||||
|
||||
While dense vector retrieval provides powerful semantic matching capabilities, it also comes with computational challenges when working with large knowledge bases. This is where specialized vector database engines like Qdrant play a key role in optimizing the retrieval process for RAG architectures.
|
||||
|
||||
@@ -188,33 +181,33 @@ While dense vector retrieval provides powerful semantic matching capabilities, i
|
||||
|
||||
|
||||
|
||||
## Vector Indexing & Compression
|
||||
#### Vector Indexing and Compression
|
||||
|
||||
Qdrant employs advanced indexing data structures and vector compression algorithms to efficiently store and search through billions of dense embeddings. Methods like Hierarchical Navigable Small World (HNSW) graphs and [quantization techniques](https://qdrant.tech/documentation/guides/quantization/) for rapid nearest neighbor search over the high-dimensional vector space.
|
||||
|
||||
[Binary Quantization](https://qdrant.tech/articles/binary-quantization/), for example, saves on memory, and scales up to 30x at the same cost by compressing the raw embeddings into highly compact representations. Combining these indexing and quantization methods allows Qdrant to perform similarity searches over large vector datasets with extremely low latencies even with large-scale datasets.
|
||||
|
||||
|
||||
## Filtering & Reranking
|
||||
#### Filtering and Reranking
|
||||
|
||||
Real-world retrieval often requires filtering by structured metadata like sources, timestamps, etc. Qdrant supports filtering searches by arbitrary key-value metadata properties associated with each vector embedding.
|
||||
|
||||
You can then exploit approximate nearest neighbor search capabilities to further refine and re-rank the candidates based on precise distance calculations.
|
||||
|
||||
|
||||
## Distributed Scalability
|
||||
#### Distributed Scalability
|
||||
|
||||
As the number of vectors and query volumes scale, Qdrant provides a distributed clustered architecture with automated sharding and replication mechanisms. This enables high availability and horizontal scaling to handle extremely large vector workloads across multiple nodes.
|
||||
|
||||
Whether dealing with millions or billions of vectors spanning diverse knowledge sources, such optimized vector similarity engines are critical for RAG models to quickly retrieve the most relevant evidence from their broad knowledge bases in a performant manner.
|
||||
|
||||
|
||||
# Where is RAG being used?
|
||||
## Where is RAG being used?
|
||||
|
||||
Because of their more knowledgeable and contextual responses, RAG models are finding widespread application across various domains today, especially when factual accuracy and depth of knowledge are required.
|
||||
|
||||
|
||||
## Real-World Applications:
|
||||
### Real-World Applications:
|
||||
|
||||
Question answering: This is perhaps the most prominent use case for RAG models. They power advanced question-answering systems that can retrieve relevant information from large knowledge bases and then generate fluent answers. Example applications include: For example, AI assistants and chatbots for customer support, research, tutoring, and more.
|
||||
|
||||
@@ -225,7 +218,7 @@ Data-to-text generation: By retrieving relevant structured data, RAG models can
|
||||
Multimedia understanding: RAG isn't limited to text - it can retrieve multimodal information like images, video, and audio to enhance understanding. Answering questions about images/videos by retrieving relevant textual context.
|
||||
|
||||
|
||||
# Creating your first RAG chatbot with Langchain, Groq, and OpenAI
|
||||
## Creating your first RAG chatbot with Langchain, Groq, and OpenAI
|
||||
|
||||
Are you ready to create your own RAG chatbot from the ground up? Daniel Romero’s instructional video is the perfect starting point. It guides you through:
|
||||
|
||||
@@ -241,7 +234,7 @@ After building your RAG chatbot, you'll be able to evaluate its performance agai
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/O60-KuZZeQA?si=jkDsyJ52qA4ivXUy" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
|
||||
|
||||
|
||||
## What’s next?
|
||||
### What’s next?
|
||||
|
||||
Have a RAG project you want to bring to life? Join our [Discord community](discord.gg/qdrant) where we’re always sharing tips and answering questions on vector search and retrieval.
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 608 KiB After Width: | Height: | Size: 608 KiB |
Reference in New Issue
Block a user