Task 1.5: Design retrieval mechanisms for FM augmentation.

• ANo chunking, after splitting each manual into one separate file per chapter beforehand

  Incorrect

  With no chunking each file becomes one chunk, so whole chapters are embedded as single vectors, which hurts precision and inflates the context sent to the model.

• BSemantic chunking with a high breakpoint percentile threshold and a larger buffer size

  Incorrect

  Semantic chunking groups sentences by meaning, which helps unstructured text, but a high threshold just makes chunks larger and reintroduces the ranking problem. It has no parent expansion.

• CFixed-size chunking with 100-token chunks and a 50% overlap between consecutive chunks

  Incorrect

  Very small fixed chunks with heavy overlap improve matching but still hand the model only a fragment of the procedure.

• DHierarchical chunking with small child chunks and larger parent chunks

  Correct

  Hierarchical chunking searches on small child chunks for precise matching and then replaces them with their parent chunks, so the model receives the broader procedure around the match.

The symptoms describe the precision versus context trade-off that hierarchical chunking was built for: match on small children, answer with the larger parent. Expect fewer results than numberOfResults, because children that share a parent collapse into one.

• ARe-create the data source with semantic chunking so that each part's description stays in one chunk

  Incorrect

  Chunk boundaries are not the cause. The issue is that dense vectors do not reliably match exact identifiers, and chunking changes cannot fix that.

• BAdd a reranker model with a higher number of reranked results to reorder the retrieved passages

  Incorrect

  A reranker reorders what retrieval returned. It cannot surface a passage that was never retrieved, which the team already observed.

• CIncrease numberOfResults to 100 so that the passage with the part number is more likely to be included

  Incorrect

  More semantic results add noise and tokens but do not make an embedding model better at matching an arbitrary code, so the passage can still be missing.

• DSet overrideSearchType to HYBRID so that keyword matching on the raw text is combined with vector search

  Correct

  Hybrid search combines vector search with a search of the raw text, so exact tokens such as part numbers are matched. OpenSearch Serverless with a filterable text field supports it.

Embeddings capture meaning but are weak at exact identifiers such as SKUs, error codes and part numbers. Hybrid search adds keyword matching on the raw text. It is available for Aurora (RDS), OpenSearch Serverless and MongoDB vector stores that have a filterable text field.

• ACall AgenticRetrieveStream so that a foundation model plans sub-queries across iterations

  Incorrect

  Agentic retrieval also decomposes questions, but it currently supports only managed knowledge bases, and this one is customer-managed.

• BEnable query decomposition in the orchestration configuration of RetrieveAndGenerate

  Correct

  Query decomposition breaks a complex query into smaller sub-queries and runs them, which retrieves chunks for each portfolio. It is configured with the QUERY_DECOMPOSITION transformation type.

• CEnable implicit metadata filtering so that the model generates a filter on the portfolio name

  Incorrect

  Implicit filtering derives one filter from the query. A filter for one portfolio would exclude the other, and the question needs both.

• DAdd a reranker model so that the chunks about the second portfolio are moved to the top

  Incorrect

  A reranker can only reorder retrieved chunks. If no chunks about the second portfolio were retrieved, reranking cannot add them.

Multi-part questions need multiple retrievals. On a customer-managed knowledge base, the built-in way is query decomposition in RetrieveAndGenerate. Agentic retrieval goes further, with iterative planning across knowledge bases, but requires a managed knowledge base.

• APublish an Amazon API Gateway REST API with an OpenAPI definition that wraps the Retrieve API

  Incorrect

  A REST API with an OpenAPI definition is a fine API-first design, but it is not an MCP interface, so each framework would still need custom integration code.

• BGive each team an IAM role that allows the Retrieve API and let each team write its own retrieval tool

  Incorrect

  Direct Retrieve calls work, but every team would write and maintain its own integration, which is what the platform team wants to avoid.

• CConfigure the gateway's inbound authorizer to validate JSON Web Tokens issued by the corporate identity provider

  Correct

  A gateway must have inbound authorization, and the OAuth (JWT) option validates tokens from the company's identity provider before any tool call reaches the knowledge base.

• DCopy the knowledge base content into a separate vector store for each team and let each team host its own MCP server

  Incorrect

  Duplicating the index multiplies storage and synchronization work and spreads security controls across five teams.

• EAdd the managed knowledge base to an Amazon Bedrock AgentCore Gateway as a target through the built-in connector

  Correct

  A managed knowledge base can be a target of an AgentCore Gateway, which exposes it as an MCP tool that any MCP-compatible framework can discover and call.

Consistent access to retrieval means one standard interface. An AgentCore Gateway turns the managed knowledge base into an MCP tool, and its inbound JWT authorizer ties every call to the corporate identity provider.

• ASwitch to no chunking so that each file becomes one chunk

  Incorrect

  No chunking fits documents already split into small files. Whole files make retrieval less precise, and the team must keep fixed-size chunking.

• BReduce the fixed chunk size from 300 to 100 tokens

  Incorrect

  Smaller chunks fit when chunks mix too much unrelated text. They add boundaries, so more sentences get split.

• CSet an overlap percentage between consecutive chunks

  Correct

  Fixed-size chunking lets you set an overlap percentage between consecutive chunks, so text at a boundary also appears in the neighboring chunk, at the cost of some extra index size.

• DRaise numberOfResults from 5 to 10 for each query

  Incorrect

  More results help when relevant chunks rank just below the cutoff. A split fact stays split, and both halves still have to be retrieved.

Boundaries are the weak point of fixed-size chunking. Overlap repeats text across neighbors so a sentence near a boundary survives intact in at least one chunk.

• ARe-embed the corpus with a higher-dimension embedding model

  Incorrect

  Vectors with more dimensions need a new index filled with re-embedded chunks, which the team cannot build this quarter.

• BSend the top ten passages to the model instead of three

  Incorrect

  More passages help when the prompt budget allows them. Here the budget allows only three.

• CRe-create the data source with larger chunks and re-sync it

  Incorrect

  Larger chunks help when chunks lack context, but changing chunking requires re-ingesting the data.

• DAdd a reranker model before the top three passages are kept

  Correct

  A reranker scores the relevance of retrieved results to the query and reorders them, which works on the existing index and adds only a reranking call.

Retrieval finds candidates and reranking orders them. When the right passage is found but ranked too low, rerank before truncating.

• ACreate a separate embedding model per product line

  Incorrect

  Different embedding models do not separate the documents, and queries must use the same model as the index.

• BApply a metadata filter on product_line in each request

  Correct

  Metadata filters restrict retrieval to documents whose attributes match, such as the customer's product line.

• CAsk the model to ignore other product lines

  Incorrect

  Instructions do not stop other passages from taking result slots.

• DLower the chunk size of every manual

  Incorrect

  Chunk size does not limit results to one product line.

Use metadata you already have. Filters narrow retrieval to relevant documents before generation.

• AAdd semantic search with vector embeddings of the articles and the queries

  Correct

  Embeddings represent meaning, so an article can match a question that shares no keywords with it.

• BUpload a synonym file as a custom package for the index analyzer

  Incorrect

  Synonym files fit a known, bounded list of equivalent terms. Thousands of free-form phrasings cannot be kept in synonym lists.

• CAdd a reranker model on top of the keyword results

  Incorrect

  A reranker reorders retrieved results. It cannot surface an article that keyword search never retrieved.

• DExtract key phrases from each query with Amazon Comprehend before searching

  Incorrect

  Key phrases are noun phrases taken from the user's own words. Searching on them is still keyword matching.

When users and authors use different words, the fix is a different retrieval method, not more keyword tuning.

• ANo chunking, so that each transcript is kept as a single chunk

  Incorrect

  No chunking treats each document as one chunk, so every transcript would become one long chunk that spans many topics.

• BFixed-size chunking with a larger maximum token size per chunk

  Incorrect

  Larger fixed-size chunks fit when answers need longer passages. Boundaries still follow token counts, so each chunk would mix even more topics.

• CSemantic chunking with a tuned breakpoint percentile threshold

  Correct

  Semantic chunking divides text by meaning, splitting where sentences become dissimilar beyond a breakpoint percentile threshold. It uses a foundation model, which is the extra cost the firm accepts.

• DDefault chunking with a higher numberOfResults on each query

  Incorrect

  More results help when relevant chunks rank just below the cutoff. Here they would add more blended chunks to each answer.

Choose the chunking strategy from the shape of the content: structure-based splits need structure, and unmarked topic shifts need boundaries chosen by meaning.