Additionally, Elasticsearch's vector search uses approximate kNN by default. I believe most native vector stores would do the same, but depending on the situation, would the option to use exact kNN also be a consideration?

Exact kNN guarantees accurate results but does not scale well for large datasets, which i think may not be suitable for RAG workloads. But if the implementation is not overly complex, providing an additional option may not harm the user either.

I agree. Elasticsearch's QueryDSL allows for various filters to be applied. For example, let's assume a user requests the following query: Query: "Find documents related to this product among documents from January to October 2025" First, we can count the number of documents during that period in Elasticsearch. If it's a suitable number for exact kNN search (for example, 10,000 documents), it might be a more reasonable decision to use exact kNN instead of approximate kNN for the search. Of course, this would add complexity to the ElasticsearchVectorStore implementation. For now, as you mentioned, let's focus on being faithful to the Python version's VectorStore functionality, and we can consider adding Elasticsearch-specific features later.

make sense