feat: Making feast vector store with open ai search api compatible

[patelchaitany]

What this PR does / why we need it:

This PR making the feast vector store api with open ai search api compatible so.

This are the changes are made.

1. New OpenAI-compatible endpoint

• Added POST /v1/vector_stores/{vector_store_id}/search that matches the OpenAI vector store search API
• vector_store_id just maps to a feature view name
• Takes a query string, embeds it via LiteLLM, calls retrieve_online_documents_v2, and returns results in OpenAI's vector_store.search_results.page format
• LiteLLM embedding config goes in feature_store.yaml under a new embedding_model section (model, api_key, api_base, api_version, dimensions

2. Metadata filtering

• New filter_models.py with two Pydantic models: ComparisonFilter (eq, ne, gt, gte, lt, lte, in, nin) and CompoundFilter (and/or, nestable)
• Threaded filters through the entire retrieval stack down to each online store
• Each store translates filters into its native query language:
  • Elasticsearch: Query DSL clauses (term, range, terms, bool)
  • Milvus: boolean expressions like field == 'value'
  • Postgres: parameterized SQL subqueries with entity_key IN (SELECT ...)
  • SQLite: same approach as Postgres, SQLite syntax

3. Numeric storage fix

• Without this change, all values are stored as text, so '9' > '100' is true in filters
• New enable_openai_compatible_store config flag on every store backend
• When enabled, adds a value_num column that stores int, float, double, and bool values natively alongside the existing `value_text

4. Bug fixes picked up along the way

• SQLite BM25 search was reading raw value instead of value_text
• SQLite's query param renamed to embedding since that's what it actually is
• Added input escaping for Milvus query strings

5. Tests

• 160 lines of unit tests for filter models (valid/invalid operators, value types, nested compounds)
• ~320 lines of integration tests covering filtered vector search, filtered text search, OpenAI response shape, and error cases (no embedding config, nonexistent feature view, empty results)

Which issue(s) this PR fixes:

#5615

Misc

---

[ntkathole]

filters are accepted and applied as well

[ntkathole]

I think these all are not needed now, it's duplicate of filter_models.py definitions

[ntkathole]

Suggested change

	class LiteLLMEmbeddingProvider:
	class LiteLLMEmbeddingProvider(EmbeddingProvider):

[ntkathole]

The entire call including the embedding network I/O is wrapped in run_in_threadpool, which blocks a thread waiting for the OpenAI/Ollama HTTP response. LiteLLMEmbeddingProvider.aembed() exists precisely to avoid this. Make retrieve_online_documents_openai async, call await self.embedding_provider.aembed(...) inside it, and then await run_in_threadpool only for the DB retrieval step. The endpoint can then await store.retrieve_online_documents_openai(...) directly without an outer run_in_threadpool.

[patelchaitany]

Done. retrieve_online_documents_openai is now async with await aembed(...). The retrieve_online_documents_v2 call is still in run_in_threadpool since it has no async variant.

[ntkathole]

request.filters.model_dump() can be removed once line 146 uses ComparisonFilter/CompoundFilter directly

[ntkathole]

update date before merge

[ntkathole]

Also add documentation for OpenAI-compatible Vector search endpoint in docs/reference/alpha-vector-database.md and docs/reference/feature-servers/python-feature-server.md

Also, missing docs for how user can use different embedding provider other than litellm

[ntkathole]

looks good to me!

@franciscojavierarceo will you be able to take a look once?

[patelchaitany]

@ntkathole, The CI for the mcp-feature-server-runtime was failing because fastapi_mcp does not handle circular references properly. To fix this, I made changes in mcp_server.py where we inserted a custom schema resolver that handles how reference schemas are resolved. I also verified its logic against the original fastapi_mcp logic -- both produce the same output when there are no self-referencing schemas.