Do you anticipate that the vector engine would be changed in a way that fundamentally precluded larger vectors (intentionally)? I would think that the ability to support larger vectors should be a key criteria for any changes to be made. Certainly if there are optimizations to be had at specific sizes (due to power of 2 size or some other numerical coincidence) found in the future we should have ways of picking that up if people use the beneficial size, but I don't understand the idea that we would support a change to the engine that would preclude larger vectors in the long run. It makes great sense to have a default limit because it's important to communicate that "beyond this point we haven't tested, we don't know what happens and you are on your own" but forcing a code fork for folks to do that testing only creates a barrier if they find something useful that they want to contribute back...
On the proposal's thread I like the configurability option fwiw. On Tue, May 9, 2023 at 12:49 PM Bruno Roustant <bruno.roust...@gmail.com> wrote: > I agree with Robert Muir that an increase of the 1024 limit as it is > currently in FloatVectorValues or ByteVectorValues would bind the API, we > could not decrease it after, even if we needed to change the vector engine. > > Would it be possible to move the limit definition to a HNSW specific > implementation, where it would only bind HNSW? > I don't know this area of code well. It seems to me the FloatVectorValues > implementation is unfortunately not HNSW specific. Is this on purpose? We > should be able to replace the vector engine, no? > > Le sam. 6 mai 2023 à 22:44, Michael Wechner <michael.wech...@wyona.com> a > écrit : > >> there is already a pull request for Elasticsearch which is also >> mentioning the max size 1024 >> >> https://github.com/openai/chatgpt-retrieval-plugin/pull/83 >> >> >> >> Am 06.05.23 um 19:00 schrieb Michael Wechner: >> > Hi Together >> > >> > I recently setup ChatGPT retrieval plugin locally >> > >> > https://github.com/openai/chatgpt-retrieval-plugin >> > >> > I think it would be nice to consider to submit a Lucene implementation >> > for this plugin >> > >> > https://github.com/openai/chatgpt-retrieval-plugin#future-directions >> > >> > The plugin is using by default OpenAI's model "text-embedding-ada-002" >> > with 1536 dimensions >> > >> > https://openai.com/blog/new-and-improved-embedding-model >> > >> > but which means one won't be able to use it out-of-the-box with Lucene. >> > >> > Similar request here >> > >> > >> https://learn.microsoft.com/en-us/answers/questions/1192796/open-ai-text-embedding-dimensions >> > >> > >> > I understand we just recently had a lenghty discussion about >> > increasing the max dimension and whatever one thinks of OpenAI, fact >> > is, that it has a huge impact and I think it would be nice that Lucene >> > could be part of this "revolution". All we have to do is increase the >> > limit from 1024 to 1536 or even 2048 for example. >> > >> > Since the performace seems to be linear with the vector dimension and >> > several members have done performance tests successfully and 1024 >> > seems to have been chosen as max dimension quite arbitrarily in the >> > first place, I think it should not be a problem to increase the max >> > dimension by a factor 1.5 or 2. >> > >> > WDYT? >> > >> > Thanks >> > >> > Michael >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
