Bedrock Knowledge Bases: vectors, indexing, retrieval

The ingestion pipeline a sync job runs

1. Data source

   Amazon S3 is the workhorse; connectors exist for the web crawler, Confluence, SharePoint, and Salesforce.

2. Parse & chunk

   Documents are split per your chunking strategy — fixed-size, hierarchical, semantic, none, or a custom Lambda.

3. Embed

   An embeddings model (e.g., Titan Text Embeddings) turns each chunk into a vector. Changing this model later means re-embedding everything.

4. Vector index

   Vectors + chunk text + metadata land in the vector store you chose at creation.

5. Retrieve / RetrieveAndGenerate

   Query-time: embed the question, search the index (top-k, filters, optional hybrid), optionally generate.

Chunking strategies — set at the data source

Fixed-size (tokens per chunk + overlap) is the default workhorse; hierarchical keeps parent–child chunks so retrieval can return the small match with its larger context; semantic splits on meaning boundaries; none indexes each document whole (for pre-chunked files); a custom Lambda does anything else. Changing strategy means re-ingesting the source.

Metadata and filtering

Sidecar metadata files attach fields (department, year, product) to documents; queries can then filter before vector search — the cheap fix when "retrieval mixes up product A and product B docs".

Keeping it current — sync jobs

Ingestion is not continuous: a sync (StartIngestionJob) re-processes new/changed/deleted source documents. Fresh documents that never show up in answers usually mean nobody re-synced — the ops side of this lives in the retraining module.

Semantic vs hybrid search

Semantic (vector) search is the default. Hybrid adds keyword matching where the vector store supports it — the tell is exact-string content: part numbers, error codes, names an embedding may blur.