bug: BedRock PromptModel not interpretaing YAML environement variable

[lambda-science]

Describe the bug When using the PromptModel node to interact with AWS Bedrock models, when specified in the YAML file the environnement variable are not interpreted. For example this works:

  - name: PromptModel
    type: PromptModel
    params:
      model_name_or_path: anthropic.claude-instant-v1
      max_length: 512
      model_kwargs:
        temperature: 0
        aws_profile_name: my-profile
        aws_region_name: eu-central-1

This doesn't work:

  - name: PromptModel
    type: PromptModel
    params:
      model_name_or_path: anthropic.claude-instant-v1
      max_length: 512
      model_kwargs:
        temperature: 0
        aws_profile_name: ${AWS_PROFILE_NAME}
        aws_region_name: ${AWS_REGION_NAME}

Error message The two mains errors are:

  File "/usr/local/lib/python3.11/site-packages/botocore/session.py", line 422, in get_scoped_config
2023-12-19T10:35:28.264024363Z     raise ProfileNotFound(profile=profile_name)
2023-12-19T10:35:28.264026547Z botocore.exceptions.ProfileNotFound: The config profile (${AWS_PROFILE_NAME}) could not be found

[...]

  File "/usr/local/lib/python3.11/site-packages/haystack/nodes/prompt/invocation_layer/amazon_bedrock.py", line 300, in supports
2023-12-19T10:35:28.264100607Z     raise AmazonBedrockConfigurationError(message=exception.message) from exception
2023-12-19T10:35:28.264103392Z haystack.errors.AmazonBedrockConfigurationError: Failed to initialize the session with provided AWS credentials {}

In my docker container the environnement variable is correctly set:

$ echo $AWS_PROFILE_NAME
my-profile

Full traceback: https://paste.parinux.org/paste/rHgzhjmN#eFOpvvQS+i3wsIZQ77We7c6fifP58On1Vdgj4Nk0oYP

Expected behavior We should be able to specify AWS profile name and region inside the YAML file without hard-coding these values.

Additional context Add any other context about the problem here, like document types / preprocessing steps / settings of reader etc.

To Reproduce My YAML pipeline: https://paste.parinux.org/paste/NertaUEW#x5IoUXGJrfqqEdwdyK5qV244mAffO4KR9OW9TYv7m4a My Docker-compose: https://paste.parinux.org/paste/JUAJW9oJ#AN5SpSQNHjYDrOM3jifRAt9opIJHlycyzvvreWJS70x

FAQ Check

• [x] Have you had a look at our new FAQ page?

System:

• OS: Docker (Ubuntu)
• GPU/CPU: CPU
• Haystack version (commit or version number): v1.23.x
• DocumentStore: ElasticSearch (InMemory in provided example)
• Reader: None
• Retriever: EmbeddingRetriever OpenAI

[lambda-science]

Same for Retriever BTW but this is with latest Haystack v1.x (not implemented in v1.23.x)

  - name: Retriever
    type: EmbeddingRetriever
    params:
      document_store: DocumentStore
      embedding_model: amazon.titan-embed-text-v1
      top_k: 3
      batch_size: 8
      max_seq_len: 1536
      aws_config:
        profile_name: ${AWS_PROFILE_NAME}
        region_name: ${AWS_REGION_NAME}

  File "/opt/haystack/haystack/nodes/retriever/_embedding_encoder.py", line 477, in _initialize_boto3_session
2023-12-20T13:10:52.435238327Z     raise AWSConfigurationError(
2023-12-20T13:10:52.435240321Z haystack.errors.AWSConfigurationError: Failed to initialize the session with provided AWS credentials {'profile_name': '${AWS_PROFILE_NAME}', 'region_name': '${AWS_REGION_NAME}'}
2023-12-20T13:10:52.435242505Z 

In docker container:

haystackd@4605131003ae:/opt/haystack$ echo $AWS_REGION_NAME
eu-central-1

haystackd@4605131003ae:/opt/haystack$ echo $AWS_PROFILE_NAME
dto-sandbox-admin

[ZanSara]

Hello @lambda-science! I might have identified the origin of your problem, even though your specific example was not fully reproducible.

Parameters can be injected in the way you show, but in order for Haystack to know which component they're targeting, you have to prefix them with <component_class_name>_PARAMS_, exactly as you're doing with the api key of the retriever.

Try to replace AWS_REGION_NAME with PROMPTNODE_PARAMS_AWS_REGION_NAME (and the same for the profile name) in your docker compose and in the pipeline YAML, and let me know if that helps! If that was the issue we are going to improve our documentation to make this hidden requirement more evident.