When using AWS Bedrock Knowledge Base's metadata filtering, there's a key challenge with how metadata is handled during response generation. The metadata attributes (like your document_name) are not automatically included in the content that gets passed to the foundation model for response generation.

Here's what's happening:

1. Your metadata filtering is working correctly for retrieval - it's finding the right document based on the document ID in the metadata.
2. However, when the content is passed to the model via the search_results placeholder in prompt templates, only the document content is included, not the metadata.
3. This is why the model doesn't "see" the document ID and can't acknowledge it found the specific document you requested.

To solve this issue, you have a few options:

1. Include document IDs in the content itself: The most straightforward solution is to include the document ID within the actual document content, so it's visible to the model during response generation.

2. Custom prompt engineering: Modify your prompt template to explicitly include metadata. For example, you could create a custom prompt that prepends each search result with its metadata information:

Here are the search results:
Document ID: {document_name}
Content: {content}

You would need to implement this in your application code by processing the retrieved references and constructing this format before sending it to the model.

3. Pre-processing during ingestion: During the knowledge base ingestion process, you could modify your documents to include metadata information at the beginning of each document.

4. Post-processing in your application: After receiving the response from the model, you could modify it in your application code to include references to the document IDs that were found.

The key insight is that metadata filtering is primarily designed for retrieval accuracy (finding the right documents), not for including that metadata in the context provided to the model. You'll need to bridge this gap with one of the approaches above to ensure the model can acknowledge the document IDs in its responses.
Sources
Integrating metadata filtering within Bedrock flows | AWS re:Post
Multi-tenancy in RAG applications in a single Amazon Bedrock knowledge base with metadata filtering | AWS Machine Learning Blog

You are seeing the expected behavior of Amazon Bedrock Knowledge Bases. Metadata filtering is fully supported during retrieval, but metadata attributes are not injected into the model prompt during response generation.

1. Why this happens

In Bedrock Knowledge Bases:

• Metadata (from metadata.json) is used only during the vector search filtering step.
• Retrieved documents are returned in the API response under retrievedReferences, including both content and metadata.
• When the model is invoked, the $search_results variable in the prompt template contains only the text content, not the metadata.

This behavior is documented in:

• Knowledge Bases Prompt Variables → $search_results contains the retrieved content text
• RetrieveAndGenerate API → metadata is returned in retrievedReferences, not injected into the model input

Because of this separation: The retriever correctly finds the document using document_name, but the model cannot “see” that field in the prompt and therefore cannot confirm the ID.

2. Can metadata be added to $search_results?

Not at this time.

There is no configuration in Agents, Knowledge Bases, or RetrieveAndGenerate that changes how $search_results is formatted.

Metadata is intentionally kept out of the model prompt and is available only in the API response.

3. Practical Solutions

A) Add document IDs to the content itself

If the model must recognize IDs such as DOC-123-2025, include them inside the document content:

Document ID: DOC-123-2025
<original document content>

Because $search_results includes only content text, this ensures the model can reason about the ID during generation. This is the simplest and most reliable fix.

B) Use a custom RAG pipeline (manual retrieve → custom prompt → InvokeModel)

If you want the model to use metadata directly, you need to bypass the managed generation step:

1. Call Retrieve or the retrieval portion of your Knowledge Base.
2. Read both content and metadata from retrievedReferences.
3. Construct your own prompt, for example:

<doc>
  <document_name>DOC_123_2025.csv</document_name>
  <content> ... </content>
</doc>

4. Call InvokeModel directly with your prompt.

This gives full control over how metadata is presented to the model.

C) Prepend metadata during ingestion

At ingestion time, you can modify documents to include identifiers (title block, header, etc.) before chunking. This ensures the ID becomes part of the text that’s embedded and retrieved.

4. Summary

• Bedrock does not persist metadata into $search_results today.
• Metadata is used for retrieval filtering, not for model reasoning.
• To make the model aware of document IDs, you must either:
  • Include IDs inside the content, or
  • Build a custom RAG pipeline that injects metadata into the prompt.

This behavior is consistent with current Knowledge Bases and RetrieveAndGenerate design.

Thank you.

Sources

Amazon Bedrock Knowledge Bases – metadata filtering https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-knowledge-bases-now-supports-metadata-filtering-to-improve-retrieval-accuracy/

Knowledge Base Retrieve and Generate https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-retrieve-generate.html

Knowledge Base Retrieve API https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-retrieve.html