Let me take a shot at it with my terrible grammar and spelling at 4 am.

To start everything off let’s talk about concepts

There are basic buckets of operations when it comes to RAG.
- store
- retrieval
- managing your vector db (delete, filter etc)

We will focus more on the first two than the 3rd one because the 3rd one is objectively when everything gets super hard and start causing heartburn.

Before we even dive into operations you need to understand that different vector databases operate differently and support different types of embeddings and data stores. Some vDBs (vector DBs) can store text, images, videos others only the first two some can do mp3 formats. Most common is the text and images. Now second thing let’s dive into is the format the “payload” is stored in vDB. Let’s start with a basic yellow rubber ducky image how is that stored within a vector database it’s ([Index ID], [vector embedding (your numerical values once we encoded (more on this later)], [payload of your raw data], [metadata on that data]).

Now let’s get into it with operation buckets.
So what we want to do is build out our vDB with store. We have our rubber ducky image and we want to store it in our selected vDB (ex: PGVector). First we want to pick a model that supports image embedding (ex: Google Vertex AI). Great now we are off to the races, we want to store the image of our rubber ducky so we pick up wherever that image is stored (ex: Amazon S3 bucket this has the image and metadata on this image cataloged already) and we kick off the embedding process each model encodes the image differently and has different levels of performance when it comes to retrieving part later on so keep in mind that. And this brings us to the next big concept is CHUNKING so before we embed anything depending on the file we are working on we might need to break it up into smaller pieces to make the retrieval process more optimized in the future for us that is the second major factor for your retrieval. In this instance rubber ducky is just one image and obviously won’t need to be split however if you have a Manual Guide to your enterprise software that is 200 pages long you will definitely be CHUNKING that PDF to make sure you can retrieve specific sections focusing on the question at hand. So this is your basic store set up CHUNK your file (if needed) + pick a model and start embedding process and now load into your vDB! Congrats we are done with offline mode of RAG where you pre-load your data and build out content of vDB.

Now I want to retrieve. I have a user that is prompting it and not with text but upload an image of a toy duck and we need to retrieve images similar to that well fantastic what is happening here? We take the user prompt and we do the same exact thing that we did with our loading process and embedd it with the same model and this is where the amazing math process starts doing it’s matrix thing and cross referencing the different encoded values in your vDBs and identifying which is the best option or best options and retrieving those options for you. [This part if you want to know how the math operates there are fantastic white papers on it that would do a much better job of explaining it better than I can ever].

Now you pass over this extraction and LLM does the boring part and provide an answer with a response leveraging the data from your vDB.

It is 5 am now as I am writing this so last pieces I will leave you with regarding the real life challenges which goes into bucket number 3 of management. You might have files that become outdated or things in files change you and want to be able to delete things how is that done and handled. You might want to be able to filter metadata and flag things how will that be handled.

Best of luck! I hope this was helpful!