The first decision in a RAG system is which embedding model to use, and it is the one decision that is most expensive to undo, because the vectors are baked into the index. Here is how I would choose, having got it wrong once.
What you are actually choosing
Three things, and people talk about the first one only.
The dimension. The length of the vector the model returns. It is fixed per model. 384, 768, 1024, 1536, 3072, and a few thousand for the very large ones. It sets the storage cost of your index, and it is the thing you cannot change without re-embedding everything.
The maximum input length. How many tokens of text the model will encode in one go. 256 is common for the small general-purpose models, 512 for some, and the good ones go to 512, 1024 or 8192. If your chunk is 400 tokens and the model takes 256, you are silently truncating, and you will not get an error.
The training domain. A model trained on code and documentation embeds identifiers and API names very differently from a model trained on natural language paragraphs. If your corpus is API documentation, a general-purpose model will still work, and a code-trained one will be noticeably better.
The rule I now use
Index with the smallest model that is good enough, because the cost of a bigger model is paid on every query forever and the benefit is not.
The way to know it is good enough is to build a small set of questions with the right document, and measure recall at 5 before you index the whole corpus. Thirty questions and an afternoon. If the small model gets 80% of them, a bigger model might get 90%, and that 10% is not worth doubling your index size and your query latency.
The number people forget
The embedding cost of indexing is small. The generation cost of answering is large. So the lever that matters is not "which embedding model", it is "how many chunks do you send to the model per question" and "how long is your system prompt".
/tools/token-counter on the chunks and the system prompt, then /tools/llm-cost-calculator for the monthly figure. /learn/embeddings has the vocabulary; /tools/vector-similarity-calculator is for checking two vectors by hand.