An engineer adds a reranking configuration to the Retrieve calls made by a production service. The same configuration works from the engineer's own console session against the same knowledge base, but the service receives an access denied error on every reranked request while unreranked requests continue to succeed. The knowledge base, the Region and the request body are otherwise identical. What is the most likely cause?
- A.
Reranking is available only through the console and the AWS Management Console session is therefore the only context in which a reranker model can be applied to knowledge base results, so the service must replicate the reordering in application code.
- B.
The reranker model must be enabled per knowledge base rather than per caller, and the engineer enabled it for the console session only, so the service will succeed once the same model is attached to the knowledge base resource itself.
- C.
Reranked requests exceed the maximum request size for the Retrieve operation because the candidate documents are echoed back into the request, and the service is receiving an access denied error as the generic response to an oversized request body.
- D.
The service's execution role has permission to retrieve from the knowledge base but not to invoke the reranker model, which is a separate model invocation that requires its own permission.
Show answer
Answer: D
Reranking is a separate model invocation and needs its own permission on the caller's role.
- A. Reranking is available through the API on Retrieve and RetrieveAndGenerate, not only in the console.
- B. The reranker is specified in the request configuration rather than attached to the knowledge base resource.
- C. Candidate documents are not echoed into a knowledge base Retrieve request, and size limits do not return access denied.
- D. The reranker is a separate model invocation requiring its own permission on the calling role.