Document embedding latency as a retrieval-side design decision - #78
Open
jasperblues wants to merge 1 commit into
Open
Document embedding latency as a retrieval-side design decision#78jasperblues wants to merge 1 commit into
jasperblues wants to merge 1 commit into
Conversation
Every vector retrieval embeds the query before it can search. When the query is a user's message and the result is needed to build a prompt, that embedding call is on the critical path — nothing can be sent to the model until it returns. Measured in a deployment on text-embedding-3-small over ~3000 propositions: 300-355ms to embed and search, returning zero propositions for a greeting, with projection and provenance free. The cost is the round trip, not the vector search, and the retrieval was correct — a greeting genuinely matches nothing. The expense is finding out there is nothing to retrieve, paid on every turn. Records the asymmetry that makes this easy to fix: ingestion-side embedding is throughput-bound and off the critical path, retrieval-side is latency-bound and on it, so a local ONNX model belongs on the retrieval side. Notes the constraint from durable-storage that query and stored vectors must share model and dimension. Also records what does NOT fix it, because both are the intuitive first answers and neither survives measurement: async/parallel retrieval (on the critical path by construction) and deadline-bounding (trades determinism, and any memory- dependent eval, for latency). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Docs only. Records a finding from chasing per-turn chat latency downstream, so the next person doesn't have to measure it again.
What it says
Every vector retrieval embeds the query before it can search. When the query is a user's message and the result is needed to build a prompt, that call is on the critical path — nothing can be sent to the model until it returns.
Measured on
text-embedding-3-smallover ~3000 propositions:Two things worth reading carefully: the cost is the embedding round trip, not the vector search — the graph side is fast and with no hits there's nothing to project. And the retrieval was correct; a greeting genuinely matches nothing. The expense isn't retrieving, it's finding out there's nothing to retrieve, paid on every turn.
Why it belongs in dice
The asymmetry is a property of the design, not of one deployment:
Nothing in retrieval assumes both use the same model — the embedding service is injected. The doc notes the constraint from
durable-storage.mdthat query and stored vectors must share model and dimension, so this only works as the same model served locally, not a different one.Also records what does not fix it
Both are the intuitive first answers and neither survives measurement, so they're written down explicitly:
🤖 Generated with Claude Code