Lab 01
Vector DB on AWS
Physical twin of the lab path
- What
- The same ingest → hash → index → query → rank path, drawn as AWS boxes: Ingress, Corpus, Embed, Store, Query embed, k-NN, Egress.
- Why
- The live lab hashes in RAM. This page is the production-scale picture of those jobs.
- What you are seeing
- The region picture shows Browser → Edge → named lab steps → egress. Stage boxes below are the same twin grouped as the live Flow column.
Teaching map only. This playground hashes word tokens in process memory — no Bedrock, no OpenSearch, no AWS keys, and no prompts leave the machine.
Region picture
Browser to edge, then named lab steps inside a region, then metrics and egress.
- Edge
- Orchestrate
- Model
- Storage
- Search
- Policy
Browser
Edge
Region
Vector DB physical architecture on AWS
Query path
Named steps, same order as the lab
Titan embed
pgvector option
metrics only
Browser
egress
Stage boxes
The same twin, grouped the way the live Flow column lights.
A query API in front of a vector index. No generation — only embed and rank. The production twin of this lab’s FastAPI preview/query routes.
Source texts land in object storage, then get chunked. Locally those are the short cards in data/examples/vector-cards.md.
This lab hashes content words into 64 signed bins — a transparent stand-in for a model embedder. On AWS you would call Bedrock Titan (or Cohere) instead of the hash.
Vectors live next to their text. Locally that is LocalVectorIndex in process memory. On AWS it is a vector engine that can add OCUs under load.
The question must use the same embedder as the cards. Here: the same word-token hash. On AWS: the same Titan model ID you used at ingest.
Cosine distance (1 − dot of L2-normalized vectors). Lower is closer. The lab shows a closeness bar so the geometry is obvious.
Return ranked neighbors. Metrics only — not the query string in logs.