Regarding Hard-coded Elastic index vector dimension size

[xdave]

Context / Scenario

In trying to setup a custom LLM and also use the Elasticsearch integration, it's constantly complaining about the dimension size being different than the index mapping when ingesting documents.

Question

Is there a roadmap item or timeline on when this will be implemented?

kernel-memory/extensions/Elasticsearch/Elasticsearch/ElasticsearchMemory.cs

Line 78 in a1f280c

const int Dimensions = 1536; // TODO: make not hardcoded

Took me at least a whole day to figure out that this was hard-coded while trying to setup a custom LLM.

[dluc]

/cc @afederici75 FYI

[afederici75]

@dluc The merge between my repo and this one missed something apparently.
If you look at https://github.com/freemindlabsinc/kernel-memory/blob/1618cc6c31d15166ba1da61f96b04ef6d4030cd4/extensions/Elasticsearch/Elasticsearch/ElasticsearchMemory.cs#L48 you will see it uses a non-hardcoded value.
I am not at home with my environment and I am a little "handicapped" from here, but how do you want to proceed about this?

[afederici75]

Ok, just to close this conversation: I verified the current \main contains the non-hardcoded version and that all tests pass. I did not issue any PR since before xdave had his issue so I cannot think what generated xdave's initial challenge, but now it's definitely the version with the configurable vectorSize.