Description

franciscojavierarceo

opened on Sep 15, 2025

Issue body actions

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.

Reacted by Nikhil Kathole, Shuchu Han, Hao Xu, Aniket Paluskar and Jonathan Zarecki

Activity

1. franciscojavierarceo

   added

   kind/featureNew feature or requestNew feature or request

   on Sep 15, 2025
2. franciscojavierarceo commented on Sep 15, 2025

   

   franciscojavierarceo

   on Sep 15, 2025

   MemberAuthor

   More actions

   CC @shuchu @HaoXuAI @ntkathole

   Reacted by Shuchu Han
3. shuchu commented on Sep 17, 2025

   

   shuchu

   on Sep 17, 2025

   Collaborator

   More actions

   I agree. We need to support this feature.

   Reacted by Francisco Javier Arceo
4. franciscojavierarceo

   changed the title [-]Support OpenAI Search API[/-] [+]Support a Search API (maybe OpenAI's Search API)[/+] on Sep 22, 2025
5. haoxu0 commented on Sep 23, 2025

   

   haoxu0

   on Sep 23, 2025

   Collaborator

   More actions

   LGTM
   The only thing is making sure the dependencies are separate from the main sdk to avoid library size explosion:)

   Reacted by Francisco Javier Arceo

   Reacted by Francisco Javier Arceo
6. patelchaitany commented on Feb 23, 2026

   

   patelchaitany

   on Feb 23, 2026

   Contributor

   More actions

   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.
7. franciscojavierarceo commented on Feb 23, 2026

   

   franciscojavierarceo

   on Feb 23, 2026

   MemberAuthor

   More actions

   @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.
8. patelchaitany commented on Mar 12, 2026

   

   patelchaitany

   on Mar 12, 2026

   Contributor

   More actions

   I have some question regarding this -

   1. 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.

   2. API Layer vs. Retrieval Layer Compatibility

   • There are two possible approaches for OpenAI compatibility:

     1. 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.

     2. 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
9. ntkathole

   assigned

   patelchaitany

   on Mar 25, 2026

Issue actions