Put the steps of a basic RAG query pipeline in order.

A basic **RAG** (Retrieval-Augmented Generation) pipeline runs five steps in a fixed order. First, the user's question is turned into a vector using an embedding model. Same model the documents were embedded with, so the math lines up. Second, the system searches a vector index (Pinecone, Weaviate, Qdrant, pgvector) for the top-k chunks whose embeddings are closest to the query embedding. Cosine similarity is the usual metric. Third, optionally, a reranker like Cohere Rerank or BGE-reranker reads the query and each candidate chunk together and re-scores them. This step is more accurate than embedding similarity but slower, you only run it on the top-k that survived step 2. Fourth, the surviving chunks are assembled into the LLM prompt as context. Fifth, the LLM generates the final answer, grounded in the retrieved text.

Five step pipeline, fixed order: 1. Embed the query with the same embedding model used at index time. 2. Vector search the index for the top-k nearest chunks, typically k=10 to 50. 3. Rerank (optional) with a cross-encoder like Cohere Rerank v3 or BGE-reranker. Cut survivors down to the top 3 to 5 most relevant. 4. Assemble the prompt with the surviving chunks as context, plus the original query and any system instructions. 5. Generate with the LLM. The ordering is **forced by data dependencies**. Embedding has to happen before search because the index is keyed on vectors. Reranking needs candidates, so it follows search. Assembly happens after the final candidate set is fixed because token budget constrains how many chunks make it in. Generation is last because everything else exists to give it grounded context. A common follow-on is **query rewriting** before step 1. It can change a single-turn question into a self-contained one. That's still pre-retrieval, not a different ordering.