↗Embeddings
Chapter 4 of 5
Notes & sources
Contents ≡
Contents / Chapter 4

04

From query to results

A search system uses vectors to choose candidates. The passage—not its coordinate—is what the reader needs.

Prepare the passages; then receive a query

Return to the help center. We have five passages, each with an ID and source text. A retrieval system can prepare their embeddings ahead of time. When a visitor asks a question, it computes a query embedding and compares it with those prepared vectors.

Let fDf_D encode a document passage did_i, giving pi=fD(di)p_i=f_D(d_i). Let fQf_Q encode the incoming query text xx, giving q=fQ(x)q=f_Q(x). The two paths must produce compatible representations, but need not have identical weights: DPR jointly trains separate query and passage encoders.

FIG 004 Two paths, one compatible space
Two paths, one compatible spacePassage vectors can be prepared before search. A query encoding is compared with stored vectors using compatible encoding paths, then candidate passages are ranked for inspection.BEFORE A QUERYpassages A–Edocument pathstored vectorsAT SEARCH TIMEquery textquery pathquery vector≈score & rankThen inspect the returned source passages. A rank is not a verdict.Two paths, one compatible spacePassage vectors can be prepared before search. A query encoding is compared with stored vectors using compatible encoding paths, then candidate passages are ranked for inspection.BEFORE A QUERYpassages → document path→ stored vectorsAT SEARCH TIMEquery → query path→ query vectorScore pairs. Rank candidates.Read the returned source passages.

Conceptual retrieval flow. Query and document encoders may be the same suitable model or a deliberately compatible pair; matching dimensions alone is not enough.

Equal coordinate counts are not enough. Two maps can each have 100 coordinates while assigning different meanings to their directions. Use a suitable encoder or deliberately compatible pair, together with its intended preprocessing and scoring rule.

Score → rank → inspect

The score produces an ordering of candidate passages. Each result still needs its record ID so that the system can return the original text, title, and source—not merely a list of coordinates.

In our toy example, assign the query q=[1,0]q=[1,0]. With cosine, passage A comes first, and its record gives us “Connect the charger to restore power.” With raw dot product, E comes first instead. This is the geometry from the previous chapter, not a measured search result for the visitor's wording.

Ranking first does not establish that a passage is correct, current, or sufficient to solve the visitor's problem. A similarity score compares representations; it does not check the passage's claims. DPR likewise separates retrieval from the downstream step of extracting an answer.

Where does retrieval end?

It ends, for our purposes, with an ordered set of source passages. A separate step can inspect them, check their applicability, extract an answer, or decide that none helps. Returning a plausible candidate and establishing a supported answer are different accomplishments.

We now have a complete path: text becomes a vector, a rule compares vectors, and a rank selects candidates to read. What can that path—and its attractive geometry—leave out?