Options A and E are correct because the failure pattern is caused by exceeding the model’s usable context window and by sending too much raw customer data directly to the FM. Amazon Bedrock Knowledge Bases follows the RAG pattern by splitting source content into manageable chunks, converting chunks into embeddings, storing them in a vector index, and using semantic similarity to retrieve relevant content for a user query. This supports option E because the application can index customer purchases, profiles, and review-related information, then retrieve only the most relevant records for the current recommendation request instead of stuffing all raw data into one prompt.

Option A is also correct because chunking and staged synthesis are standard ways to handle inputs that exceed an FM’s context capacity. Processing smaller segments avoids context-length-exceeded errors, and a final synthesis call can combine intermediate findings into a complete recommendation. This is especially useful when the company says it wants the system to consider all customer data, not merely truncate older or less important data. Amazon Bedrock Knowledge Bases also lets teams configure how content is chunked for storage and retrieval, which supports a structured approach rather than an oversized one-shot prompt.

Option B is not sufficient because truncating “less important” data conflicts with the requirement to consider all customer data. Option C violates the implied design direction because the company wants to use Knowledge Bases, and simply choosing a larger context model does not solve long-term growth of customer histories. Option D is technically incorrect: model parameters such as max_tokens control output generation limits, not the model’s maximum context window, and different Claude models have model-specific maximum values. You cannot use additionalModelRequestFields to bypass the FM’s context limit.

==========