Vector & full-text fused for agentic retrieval

Retrieval modes measured by accuracy

Hybrid is consistently one of the most accurate forms of agentic retrieval, and Infino is one of the few engines that runs it natively.

Sources: Azure AI Search, 2023 ↗  ·  BEIR ↗  ·  RRF, SIGIR 2009 ↗

Why hybrid is expensive, and why it isn't here

Running both retrievers on a search engine or a vector database means keeping the corpus and its vectors resident on hot block storage, in nodes that stay on. Infino reads the same rows from your bucket and meters the query work, so the bill tracks traffic.

5B documents, 10M queries a month, 1 KB rows, each engine holding the text and a 1024-dimension vector. Model your workload →

Retrieval results are returned as a table

hybrid_search takes the table, the text column and the words to match, then the embedding column and the query vector. What comes back is an ordinary table: your columns plus a score, so WHERE, ORDER BY, and LIMIT work on it like any other query.

-- BM25 + vector, fused inside the engine
SELECT   _id, subject, score
FROM     hybrid_search(
           'tickets',                               -- one table, one snapshot
           'body', 'disk full on ingest',           -- keyword side (OR)
           'embedding', :q, 200                     -- vector side, 200 deep each
         )
WHERE    priority IN ('p0', 'p1')
ORDER BY score DESC
LIMIT    20;

• The keyword index and the embeddings sit inside the same Parquet files.
• Both searches read one version of the table, so the two sides can never be out of step with each other.
• The last argument, 200, is how many rows each side returns before they are merged.

Because the result is a table, the rest of the question stays in the same statement. Here the same call feeds a GROUP BY, asking for 5,000 rows a side so the counts cover the whole match set instead of the first page.

-- Which services retried a failed request, by team?
SELECT   team,
         count(DISTINCT service) AS services     -- which services
FROM     hybrid_search('events', 'message',
                       'retry failed request',
                       'embedding', :q, 5000)     -- BM25 + vector, fused
GROUP BY team                                    -- by team
ORDER BY services DESC;

The full query surface →

How two lists become one ranking

The two searches report different things. BM25 gives a relevance score, where a bigger number is a better match. Vector search gives a distance, where a smaller number is a better match. Adding them would be meaningless, so the engine throws both numbers away and uses each row’s position in its list.

• A row scores 1 / (60 + position) for each list it appears in. First place is worth 1/61, tenth place 1/70. Near the top counts for more, and the gap between positions shrinks as you go down.
• A row found by both searches collects both scores, so the rows they agree on rise to the top. A row only one search found still keeps its place in the ranking.
• There is nothing to tune. You do not set a weight between keyword and vector, and the same query returns the same order every time.

The arithmetic, and what sits around retrieval →

Go deeper on hybrid search

• what is hybrid search? The two retrievers, the fusion arithmetic, k and recall, and how to see where the two disagree.
• queries/ The table-valued functions, and real queries: joins, full outer joins, and window functions over search results.
• object-storage/ A three-copy retrieval stack compared with one engine reading the files in place.
• patterns/ More retrieval patterns: scoped filters, CASE-routed verification, pinned snapshots.

Hybrid search questions