Advanced RAG: Query Translation

🤔Let’s think back

We learned about the “Basic RAG System” beforehand, right? If you did not read that, read from here. We know, a RAG system consists of these parts:

• Indexing + Retrieval

• Augmentation and

• Generation

But these parts are not so useful by themselves. So, we need some optimization on them like this:

• Query Translation

• Routing

• Query Construction

• Indexing + Retrieval

• Augmentation and

• Generation

All these layers are added to get the best results from the LLM models. In this article, we will try to know about “Query Translation” and why it is needed.

What is Query Translation?

📖General Discussion:

We know that RAG works in some context (documents, web, or anything that has relevant data). Now, let’s think we have given a file for Node.js as a context to the RAG. Now, the user might ask this:
“What is fs?”

As humans, we can understand, the user wants to know about “File System” in Node.js. But what if the Node.js documentation does not have the word “fs” in it, instead it has “file system” written everywhere. So, when using RAG, will it find any similarity? And will it be able to perform nicely?

No, right?

Here comes the importance of “Remodeling the User Query”. We need to reshape/enhance/remodel the user’s query for better output. This method is called “Query Translation”.

➡️Definition:

In the context of Retrieval-Augmented Generation (RAG), query translation is the process of transforming a user’s query into a more optimized form to improve the retrieval of relevant information.

📃Methods of Query Translation:

There are a lot of methods in here. Let’s discuss the main ones:

• Parallel Query (Fan Out) Retrieval

• Reciprocate Rank Fusion

• Query Decomposition

• HyDE (Hypothetical Document Embeddings)

These methods are mainly used in the industry. I’m not gonna discuss them in depth here, but in separate articles. Good Luck.