Add hybrid search support with overrideSearchType parameter

[tirtha2shredder]

Summary

This PR adds support for hybrid search functionality to the retrieve tool by implementing the overrideSearchType parameter as requested in the AWS Bedrock Knowledge Base API.

Changes

• Added overrideSearchType parameter to the tool input schema with enum validation for HYBRID and SEMANTIC values
• Implemented parameter validation to ensure only supported search types are accepted
• Updated retrieval configuration to include the overrideSearchType when specified
• Added comprehensive tests covering:
  • Valid HYBRID and SEMANTIC search types
  • Invalid search type validation and error handling
  • Default behavior when parameter is not provided
  • Integration with existing filters and other parameters
  • Agent interface compatibility

API Reference

This implementation follows the AWS Bedrock Knowledge Base API specification:

• KnowledgeBaseVectorSearchConfiguration
• AWS Blog: Hybrid Search Support

Usage Example

# Use hybrid search
result = agent.tool.retrieve(
    text="What is STRANDS?",
    overrideSearchType="HYBRID"
)

# Use semantic search  
result = agent.tool.retrieve(
    text="deployment steps",
    overrideSearchType="SEMANTIC"
)

Testing

All existing tests pass, and new tests have been added to ensure:

• Proper parameter validation
• Correct API calls to AWS Bedrock
• Error handling for invalid values
• Backward compatibility

Backward Compatibility

This change is fully backward compatible - existing code will continue to work without modification, and the new parameter is optional.

[dbschmigelski]

curious about the naming here?

1. Are you using the override prefix to so the agent sets the field less frequently?

2. Is the usage different if you just name this searchType - the default behavior is still the same?

3. Are all knowledge bases able to support both types or can this break older knowledge bases?

[tirtha2shredder]

Great questions. I should have attached the relevant documentation:
https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_KnowledgeBaseVectorSearchConfiguration.html

In answer to your questions:

1. The naming is derived as is from the parameter used in the bedrock API call. This is also what you see in the bedrock console.
2. I can, but I am following the convention of keeping the name same as the underlying bedrock API search param. I see the rest of the class follows the same convention.
3. The documentation says right now only Amazon Opensearch based stores support it with support for other KB types coming soon. I have not tested the API with other KB types, but I have another KB backed by Kendra and the override search option does show up for it, so I am assuming it doesn't break older KBs. That being said, this is an optional parameter and should the API invalidate the request for other KBs, the user may simply opt to not set this field.

[dbschmigelski]

Sounds good on the name.

But for the compatibility, the user doesn't set the field at all (in most cases), the Agent is the one setting the field. The agent can recover with an error message (if its good) but I don't want to waste customer tokens if we know this will happen a lot

[tirtha2shredder]

I validated an API call with a KB that doesn't support hybrid search and it outputs the following:

An error occurred (ValidationException) when calling the Retrieve operation: HYBRID search type is not supported for search operation on index NF4WREDULM. Retry your request with a different search type.

What would you suggest we do here? Should additional documentation over the tool that explicitly states "only supported by amazon opensearch and kendra knowledge bases, do not use with other sources" suffice here?

[tirtha2shredder]

Alternatively I can add a fallback in cases of ValidationException to remove this parameter, but that doesn't seem right to me.