Document LLM judgment provider support, retries, and failure reporting

[RexyZhang2001]

Description

Updates the Search Relevance Workbench (SRW) LLM-as-a-Judge documentation to reflect three recent search-relevance and ml-commons changes:

• Provider-neutral LLM judgment generation: LLM-as-a-Judge now works with any provider through an ML Commons connector blueprint, not just OpenAI. Adds a "Using different LLM providers" section and a Bedrock/Claude connector example to judgments.md, and a new LLM judgment blueprints table to supported-connectors.md.
• Judgment failure reporting: A judgment can now finish as COMPLETED with some documents unrated. Adds a "Handling judgment failures" section documenting the failures array, the metadata summary fields (totalQueries, successfulQueries, failedQueries, lastFailureReason), and the Dashboards Judgment view's new Status column.
• Connector-level retries: Adds client_config retry settings to the OpenAI connector example in the LLM-as-a-Judge tutorial and to the new Bedrock example in judgments.md.

Files changed:

• _search-plugins/search-relevance/judgments.md
• _tutorials/llm-as-a-judge-tutorial.md
• _ml-commons-plugin/remote-models/supported-connectors.md

Issues Resolved

opensearch-project/search-relevance#509
opensearch-project/search-relevance#510

Version

3.8

Checklist

• By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.

[github-actions]

Thank you for submitting your PR. The PR states are In progress (or Draft) -> Tech review -> Doc review -> Merged.

Before you submit your PR for doc review, make sure the content is technically accurate. If you need help finding a tech reviewer, tag a maintainer.

When you're ready for doc review, tag the assignee of this PR. The doc reviewer may push edits to the PR directly or leave comments and editorial suggestions for you to address (let us know in a comment if you have a preference).

[heemin32]

I think it might be easier for user to understand by showing the actual response of judgement in json format and explain each field instead of using table format.

[RexyZhang2001]

added in new commit

[heemin32]

Thanks for the update. However, I think below is enough here.

### Handling judgment failures

Generating a judgment sends one LLM request for every query-document pair. Occasional failures are expected at scale: for example, the provider might throttle a request or a request might time out. To make these failures self-healing, configure retries on the connector you use for the judgment, using the connector's `client_config` settings (`max_retry_times`, `retry_backoff_policy`, and related options). For more information, see [Connector blueprints]({{site.url}}{{site.baseurl}}/ml-commons-plugin/remote-models/blueprints/#configuration-parameters).

For the remaining, you can merge in existing Managing judgment lists section.

[RexyZhang2001]

addressed this part in new commit

[heemin32]

These field explanations would be better placed in ML's connector documentation page. Here in the tutorial, since we're not covering every connector field anyway, it's more appropriate to highlight a few important ones in narrative form rather than as a table.

[RexyZhang2001]

added in new commit

[heemin32]

Suggested change

A judgment can finish with a `status` of `COMPLETED` even if some documents weren't rated. Check `metadata.failedQueries` or each query's `failures` array to confirm that every document received a rating. In OpenSearch Dashboards, the Judgment view's ratings table includes a **Status** column, labeled **Rated** or **Failed** for each document, so missing ratings are visible without inspecting the raw judgment document.

[heemin32]

Please update metadata field here.

[RexyZhang2001]

Updated the example to LLM_JUDGMENT type instead of IMPORT_JUDGMENT. For IMPORT_JUDGMENT, we currently don't support showing metadata information and failedQueries as LLM_JUDGMENT does. Also removed all the redundant description, please check again

[heemin32]

We can remove everything from this line onward — the parameter name is self-explanatory.

[heemin32]

LGTM. Thanks!