Support different embedding types of model response

[zane-neo]

Description

Support different embedding types of model response

Related Issues

#1006

Check List

• New functionality includes testing.
• New functionality has been documented.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.36%. Comparing base (3c7f275) to head (24cdeeb).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1007      +/-   ##
============================================
- Coverage     80.47%   80.36%   -0.12%     
+ Complexity     1000      998       -2     
============================================
  Files            78       78              
  Lines          3411     3412       +1     
  Branches        578      578              
============================================
- Hits           2745     2742       -3     
- Misses          425      427       +2     
- Partials        241      243       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[martin-gaievski]

Can you provide sample request/response for each of new embedding type? Is the type configurable on the client side (neural search in this case), or model is smart enough to switch between types? Any changes required from user to use new type(s), for instance do they need to recreated model connector and index mapping?

[zane-neo]

Can you provide sample request/response for each of new embedding type? Is the type configurable on the client side (neural search in this case), or model is smart enough to switch between types? Any changes required from user to use new type(s), for instance do they need to recreated model connector and index mapping?

Sample of different embedding types:

{
    "float": [
        [
          -0.03933716,
          -0.04534912,
          -0.088256836,
          -0.084350586,
          ...
        ]
    ],
    "binary": [
        [
          -127,
          90,
          103,
          ...
        ]
    ],
    "int8": [
        [
          -50,
          -58,
          -113,
          ...
        ]
    ],
    "ubinary": [
        [
          1,
          218,
          231,
          ...
        ]
    ],
    "uint8": [
        [
          78,
          70,
          15,
          ...
        ]
    ]
}

The type is configurable in model side, in the connector specifically. When user wants to switch to a different embedding type, user needs to recreate a new model with different embedding type in the connector, also user should do a reindex to ensure the embeddings are using the new embedding type result, in this case, a new index should created and after the reindex user can specify alias on original index to new one. We don't consider modifying index mapping as we can only add new field in existing index mapping, not able to modify an existing field.

[yuye-aws]

@zane-neo Plz resolve the conflicting files. The code looks good to me.