Can Feast manage embedding vectors for Retrieval-Augmented Generation (RAG) applications?

All answers to this question.

While Feast isn't a vector database like Pinecone or Weaviate, it is an excellent "service layer" for your RAG context. In a modern AI stack, you typically use a vector DB for semantic search and Feast for the "structured" metadata. For example, your vector DB finds the relevant paragraphs, but Feast provides the user's recent history, subscription tier, and preferences. You can store embeddings as "List" or "Tensor" types in Feast's online store (like Redis) for extremely fast retrieval. This hybrid approach is how you build truly personalized LLM applications that aren't just summarizing text but are actually aware of the specific user's current state.

   Answered 2025-10-05 by Valerie Hudson

Does Feast support the specialized indexing required for fast similarity searches if we decide to store all our vectors there?

   Answered 2025-10-06 by Patrick Sullivan

• Not natively, Patrick. Feast is an "exact match" store (point-wise retrieval). If you need to find the "nearest neighbors" of a vector, you still need a dedicated vector index. However, once you have the IDs of the top-k documents from your vector DB, you can use Feast to rapidly fetch all the associated features (like document weight, author trust score, or fresh snippets) in a single batch call. This "two-stage retrieval" is the industry standard for high-performance RAG systems, and Feast is the best tool for that second stage of context enrichment.

     Commented 2025-10-07 by Craig Whitaker

Feast is perfect for storing the "features" of your embeddings, such as which version of the encoder was used to create them.

   Answered 2025-10-08 by Monica Weaver

• Good point, Monica. Tracking embedding versions is critical when you're experimenting with different transformer models in production.

     Commented 2025-10-09 by Douglas Graham