Open with this line, it always lands: "yesterday we decided WHAT to feed the model, today we decide HOW it gets turned into numbers." Keep it short, move on fast, the good stuff is next slide.
Say the keyword count out loud before you show the number: zero shared words. That's the whole pitch for semantic search over keyword search, right there, don't over-explain it after.
3-large query (3072d) vs 3-small index (1536d)
→ ValueError, the vectors aren't even the same length
Same 384-dim, the exact same sentence, two different models
→ cos = 0.230, reads as "barely related" and it's identical text
Broken #1 is the boring one, it crashes and you fix it in five minutes. Broken #2 is the one that's bitten actual teams in prod: no error, no stack trace, retrieval just quietly returns garbage. Say it plainly: same dimensions doesn't mean same space. Only the same model gives you that. Tell them to version-lock the embedding model the same way they'd lock a database schema, and don't let anyone swap it "real quick" without re-embedding everything.
Got non-English text in the corpus? Multilingual model, no debate.
Its max tokens has to beat your chunk size or it just truncates.
More dims, more nuance. Also more storage and slower search.
Heavy jargon? A general model will blur terms together. Fine-tune.
Point at the negative numbers and just let that sit for a second. The English-only model doesn't merely miss the connection between EN and FR, it scores them as if they're pointing the opposite direction. Then flip to the multilingual row and watch the same pair jump to 0.86-0.94. Same sentence both times.
MiniLM caps out at 256 tokens so it truncated the doc way before it ever reached "ZEBRA-42." It never saw it, so of course the score is negative. And nothing tells you this happened, no error, no warning, the call just returns and looks fine. Loop back to notebook 02 here: chunk size has to respect the embedding model's max tokens or you get exactly this, quietly.
Funny thing, truncated actually scored a hair higher here, 0.591 vs 0.560. Don't oversell that, it's not "truncated is better," it's noise on one pair. The real point: at 12x smaller you're still carrying almost all of the useful signal, that's the headline, not this one coin flip.
Ask the room: "to a supply-chain analyst, are these the same metric?" They'll say no pretty fast once you push. On-time delivery is just timing. Perfect order rate also folds in accuracy and completeness, it's a stricter, broader metric. The general model can't tell, it just sees two similar-sounding phrases about deliveries and scores them mid-high. If your domain is full of terms like this, that's your cue to fine-tune on labeled query-passage pairs, or lean on metadata filters instead of trusting the embedding alone.
| What's in this notebook | What you'd actually deploy |
|---|---|
| all-MiniLM-L6-v2 (2021, 22M params), fast and tiny, good for a live demo | BGE-M3 (multilingual, hybrid retrieval by default) or Qwen3-Embedding (currently on top of the open-weight leaderboard) |
| text-embedding-3-small/large | Still the current OpenAI option, nothing's replaced it as of this session |
Say it plainly so it sticks: the iron rule and the four axes don't care which model name you plug in, they hold either way. We picked MiniLM because it downloads in ten seconds mid-class, not because it's what belongs in production. Don't let anyone walk out thinking MiniLM is the answer.
| Time | Segment |
|---|---|
| 0-5 min | Quick recap: we have chunks, now they need to become vectors we can compare |
| 5-12 min | Paraphrase vs. unrelated demo, heatmap and scatter, let it sink in |
| 12-20 min | The iron rule, run both broken scenarios live, don't skip the crash |
| 20-34 min | Four axes back to back: language, context window, dimensions, domain fit |
| 34-40 min | 2026 model note, then straight into Notebook 05, vector databases |