add Yandex Cloud embeddings connector blueprint

[mkhludnev]

Description

This contributes connector blueprint for Yandex Cloud.

Check List

• [v] New functionality has been documented.
• [v] Commits are signed per the DCO using --signoff.

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.

Note for reviews

I've contributed to OpenSearch before.
And thanks for reviewing it!

Summary by CodeRabbit

• Documentation
  • Added a new guide for configuring a Yandex Cloud AI Studio embeddings connector: cluster trust setup, creating a connector with API-key auth, model parameter and predict-action guidance, registering/deploying embedding models, sample inference requests/responses, placeholder and bearer-token usage, required roles, note on separate connectors for query vs. document processing, and pre/post-processing hook guidance.
  • Added Yandex Cloud entry to the Standard Blueprints list.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Added documentation for a Yandex Cloud AI Studio connector embedding standard blueprint, plus an update to the standard blueprints README. The new doc describes connector creation, parameters/credentials, predict action payloads, model registration/deployment, testing examples, and placeholder/token guidance.

Changes

Cohort / File(s)	Change Summary
Yandex Cloud Embedding Blueprint Documentation docs/remote_inference_blueprints/standard_blueprints/yandexcloud_connector_embedding_standard_blueprint.md	Added a full blueprint describing cluster connection settings; creating a YC Embeddings connector (name, description, version, protocol, modelUri, folder_id); credentials (api_key); single predict action (method, URL, headers, request_body); pre/post-processing hook conventions; placeholder substitution and bearer token/role guidance; note on separate connectors for query vs. document processing; sample _predict request and embedding response.
Standard Blueprints README docs/remote_inference_blueprints/standard_blueprints/README.md	Inserted a new Yandex Cloud entry under the standard blueprints list linking to the embedding blueprint.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Pay attention to: example JSON payloads and header formatting, placeholder substitution syntax, bearer token guidance, and accuracy of pre/post-processing hook descriptions.

Poem

🐇 I nibbled on a JSON byte,
Whispered headers through the night,
URIs lined up in a row,
Tiny embeddings start to grow,
Blueprint bound — I hop with delight.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description is incomplete; it omits the 'Related Issues' section and only partially completes the checklist without addressing API changes or documentation issues.	Add the 'Related Issues' section with issue number(s), and complete all applicable checklist items including API changes and documentation-website updates mentioned in review comments.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: adding a Yandex Cloud embeddings connector blueprint documentation.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 690bc1f and b6be3d1.

📒 Files selected for processing (1)

• docs/remote_inference_blueprints/standard_blueprints/README.md (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: spotless

🔇 Additional comments (1)

docs/remote_inference_blueprints/standard_blueprints/README.md (1)

25-26: Documentation index entry correctly formatted and positioned.

The Yandex Cloud blueprints entry is properly positioned in alphabetical order, follows the consistent formatting of other provider entries, and links to the new standard blueprint documentation. The reference to both text-search-doc & text-search-query model variants aligns with the blueprint content.

Please verify that the link target yandexcloud_connector_embedding_standard_blueprint.md is correctly placed in the docs/remote_inference_blueprints/standard_blueprints/ directory and is accessible.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 87e742e and 8a05765.

📒 Files selected for processing (1)

• docs/remote_inference_blueprints/standard_blueprints/yandexcloud_connector_embedding_standard_blueprint.md (1 hunks)

🧰 Additional context used

🪛 LanguageTool

docs/remote_inference_blueprints/standard_blueprints/yandexcloud_connector_embedding_standard_blueprint.md

[grammar] ~120-~120: Ensure spelling is correct
Context: ...of life?" } } Sample response of Yadex Cloud AI Studio Embedding: json { ...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: spotless

🔇 Additional comments (1)

docs/remote_inference_blueprints/standard_blueprints/yandexcloud_connector_embedding_standard_blueprint.md (1)

45-46: Verify pre/post-processing functions are correct for Yandex Cloud.

The connector references bedrock pre/post-processing functions, but this blueprint is for Yandex Cloud. Verify that these processing functions are:

1. Generic/universal and work correctly with Yandex Cloud API responses, or
2. Should be replaced with Yandex-specific processing functions.

If these are not the correct functions for Yandex Cloud, update them accordingly.

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8a05765 and 5d8dc2c.

📒 Files selected for processing (1)

• docs/remote_inference_blueprints/standard_blueprints/yandexcloud_connector_embedding_standard_blueprint.md (1 hunks)

🔇 Additional comments (1)

docs/remote_inference_blueprints/standard_blueprints/yandexcloud_connector_embedding_standard_blueprint.md (1)

45-46: Clarify why Bedrock pre/post-processing functions are used for Yandex Cloud.

The pre/post-processing functions reference bedrock for a Yandex Cloud connector. Clarify whether Yandex's request/response format is compatible with Bedrock's processing, or if Yandex-specific processing functions should be used instead.

If compatibility is intentional, add a brief comment explaining why Bedrock functions are appropriate here. If these should be Yandex-specific, update them accordingly.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Remove or clarify the duplicate model registration (lines 90–98).

The section shows two separate model registrations:

1. Lines 79–87: yc-embedding with the connector created in section 2 (CTEou5oBdUNOOrVArUAU) and a model_group_id
2. Lines 90–98: YC text embedding model with a hardcoded, unrelated connector_id (nzh9PIsBnGXNcxYpPEcv) and no model_group_id

The second registration uses a connector_id that does not match the one established earlier, making it inconsistent and confusing. Users will not know which registration to follow. The sample response and test section both reference the second registration's model_id, but the instructions don't explain why two registrations are shown.

Either remove the second registration if it's leftover code, or clearly explain when/why to use both variants.

If the second registration should be removed, apply this diff:

 ```json
 POST /_plugins/_ml/models/_register
 {
     "name": "yc-embedding",
     "function_name": "remote",
     "model_group_id": "4THNtZoBdUNOOrVAzj_V",
     "description": "YC embedding model",
     "connector_id": "CTEou5oBdUNOOrVArUAU"
 }

-```json
-POST /_plugins/_ml/models/_register
-{

• "name": "YC text embedding model",
• "function_name": "remote",
• "description": "test model",
• "connector_id": "nzh9PIsBnGXNcxYpPEcv"
  -}
  -```

Sample response:

Then update the sample response and test section to use the first registration's model IDs consistently.

<!-- This is an auto-generated comment by CodeRabbit -->

[nathaliellenaa]

Thanks for the PR @mkhludnev , one high level comment: can you add this blueprint to the readme as well https://github.com/opensearch-project/ml-commons/blob/main/docs/remote_inference_blueprints/standard_blueprints/README.md?

[mingshl]

@mkhludnev thanks for adding this new blueprint!! it looks great, can you also add to repo so that it will direct users from opensearch.org to your blueprint https://github.com/opensearch-project/documentation-website/blob/main/_ml-commons-plugin/remote-models/supported-connectors.md

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.22%. Comparing base (66964af) to head (e477be8).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #4469      +/-   ##
============================================
+ Coverage     80.21%   80.22%   +0.01%     
- Complexity    10242    10255      +13     
============================================
  Files           858      858              
  Lines         44553    44552       -1     
  Branches       5158     5158              
============================================
+ Hits          35739    35743       +4     
+ Misses         6640     6633       -7     
- Partials       2174     2176       +2     

Flag	Coverage Δ
ml-commons	80.22% <ø> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mkhludnev]

@nathaliellenaa done here!

[mkhludnev]

@mingshl done opensearch-project/documentation-website#11693 Thanks for advice!

[mingshl]

I have a question, if I change the modelurl in the predict payload, is it still required the same field inputText?
for example:

POST /_plugins/_ml/models/CzEou5oBdUNOOrVA10Db/_predict
{
  "parameters": {
    "inputText": "What is the meaning of life?", 
   "modelUrl":"gpt://<folder_ID>/<model_name>""
  }
}

if not, then we will create different connectors for different modelUrl is it?

[mkhludnev]

Hello Mingshi
Thanks for reviewing this!
TLDR; yes, one connector for docs and another for query. Blueprint provides just the single one as a pattern.

My understanding is the following:

• in connector we define modelUri, folder_id
• and refers to modelUri, folder_id, inputText in the body

in _predict request we can override modelUri and request another model. But since noone will do it in runtime, my vision is that there should be two connectors: one for docs and one for queries, and they should be linked with two distinguished models. But I omitted such verbose details in the blueprint.