Repository navigation
Support a Search API (maybe OpenAI's Search API) #5615
Description
Is your feature request related to a problem? Please describe.
Feast introduced the standard language in the AI/ML era on feature stores, particularly the language around "online features".
In the Agentic era, OpenAI has defined the API for inference with it's Chat Completions API. It has now introduced the Responses API (their answer for an agent-native API) and this API supports "File Search".
Many frameworks have empowered the open source community by being compatible with OpenAI's inference APIs. Compatibility with the Search API could empower Data Scientists and Machine Learning Engineers to drive impact in their RAG and Agentic applications.
I would like us to consider: (1) broadly supporting a Search API and (2) compatibility with OpenAI's File Search API.
Describe the solution you'd like
Ideally, we would support a Search API and the OpenAI one seems convenient but supporting the OpenAI one would probably imply the need to support Files and Vector Stores APIs, which may be larger scope than we want.
We would support the Vector Store APIs and Search APIs.
Describe alternatives you've considered
We could follow the OpenSearch Spec but this seems less AI native.
Additional context
We've introduced this functionality in another community I am working with and I think it could be impactful here as well. We already have retrieve_online_documents which does text and image search, so this extension already has a decent foundation.
Before choosing to support this, it'd be great to hear from the community if there is interest.
Activity
franciscojavierarceo commentedon Sep 15, 2025
CC @shuchu @HaoXuAI @ntkathole
shuchu commentedon Sep 17, 2025
I agree. We need to support this feature.
[-]Support OpenAI Search API[/-][+]Support a Search API (maybe OpenAI's Search API)[/+]haoxu0 commentedon Sep 23, 2025
LGTM
The only thing is making sure the dependencies are separate from the main sdk to avoid library size explosion:)
patelchaitany commentedon Feb 23, 2026
Hey @franciscojavierarceo I have One doubt here what do mean by the vector store API here dose it going to be used to create vector store (Described in the OpenAI vector store API docs) or it is going to be used for the file upload.
franciscojavierarceo commentedon Feb 23, 2026
@HaoXuAI yeah agree but I don't think t his will warrant a blow up in dependencies as it's just honoring the REST API layer.
patelchaitany commentedon Mar 12, 2026
I have some question regarding this -
Currently, Feast does not have a built-in text embedding module in its serving path. The existing retrieve_online_documents and retrieve_online_documents_v2 APIs require the caller to provide pre-computed embedding vectors — Feast does not convert raw text queries into embeddings itself.
API Layer vs. Retrieval Layer Compatibility
There are two possible approaches for OpenAI compatibility:
REST API translation layer only: Add new FastAPI endpoints in feature_server.py that accept OpenAI shaped requests, translate them into calls to the existing retrieve_online_documents_v2, and reshape the response to match OpenAI's format. The retrieval itself remains unchanged the compatibility is purely at the HTTP boundary.
Deeper retrieval-layer integration: Introduce OpenAI-compatible abstractions deeper in the stack (e.g., at the OnlineStore or Provider level), so the vector store backends natively return data in a format closer to OpenAI's response schema. This would avoid serialization/deserialization overhead from converting between Feast's internal protobuf-based OnlineResponse format and OpenAI's JSON response format on every request.
CC : @ntkathole @shuchu @HaoXuAI @franciscojavierarceo