RAG isn't just vector search
Wiring up an embedding model and a vector database is the easy part. The question that determines whether a RAG is actually useful is different: what are you indexing, and when does it go stale? A RAG fed by content that changes (approved posts, past decisions) needs continuous reindexing, not a one-time setup at launch.
Dynamic few-shot instead of a frozen prompt
On LuxenCrest, the editorial brief and the QA scoring rubric draw directly on already-approved posts — retrieved by similarity at generation time, not copied once into a static prompt. The system improves with history without anyone having to touch the prompt for every new campaign.
Retrieval quality matters more than model size
A bigger model doesn't compensate for retrieval that surfaces off-topic passages. The similarity threshold used to filter, the chunk size, and the number of results returned weigh more on final quality than the choice of LLM itself.
What it costs to maintain
A production RAG also means a vector database to evolve, embeddings to regenerate if the model changes, and a token budget to watch on every retrieval call — operating costs a prototype never has to carry.