Salesforce Patents a Two-Stage Database Search That Cuts AI Query Time
Searching a massive database for the "right" answer is slow when you treat every entry equally. Salesforce's latest patent describes a two-pass approach that runs a cheap, coarse filter first and only breaks out the expensive, precise comparison on what's left.
How Salesforce's two-pass AI search actually works
Today, when an AI assistant searches a database for relevant information, it typically compares your query against every single entry using detailed numerical representations. The bigger the database, the slower and more resource-hungry that gets.
Salesforce's patent describes a two-step shortcut. First, the system converts your query into a heavily compressed, simplified version of itself (think of it like a rough sketch versus a full painting). It uses that rough sketch to quickly scan the entire database and throw out most entries. Only the survivors get compared against the full, detailed version of your query, which is far more accurate but also far more expensive to run.
The result is a search that should be faster and cheaper without losing much accuracy. This is particularly relevant for AI tools that need to pull context from huge databases in real time, like a sales assistant answering a customer question by searching thousands of product documents at once.
… determining, based at least in part on accessing a database, a first subset of rows in the database that satisfy the filter data; determining, based at least in part on comparing the binary quantized embedding with one or more binary quantized embeddings in the first subset of rows in the database, a second subset of rows in the database; …
Translation: First, the system filters the database and quickly checks the rough binary data to narrow down the options.
Inside the binary-then-float filtering pipeline
The patent describes a vector search system (a method of finding items in a database by measuring mathematical similarity rather than keyword matching) that uses two different levels of data compression in sequence.
When a request comes in, the system generates two representations of it:
- A non-binary quantized embedding: a list of decimal numbers that captures the meaning of the query in detail (think many shades of gray).
- A binary quantized embedding: a stripped-down version of the above that uses only 0s and 1s (black or white only), making it much faster to compare mathematically.
The search runs in three stages. First, the system applies any filter data included in the request (for example, "only look at rows tagged with a specific customer or product") to narrow the database down to a relevant subset. Second, it compares the binary (compressed) embedding against binary embeddings in that filtered subset, pulling out the closest matches. Third, and only on that smaller pool, it runs the more expensive comparison using the full non-binary embeddings to find the final best matches.
The output is then sent to a virtual space, which in Salesforce's context likely means an AI agent or CRM interface waiting for context to formulate a response.
The system may determine a second subset of rows by identifying a threshold number of the most similar non-binary quantized embeddings in the first subset of rows relative to the request non-binary quantized embedding and output the data associated with the third subset to a virtual space.
Translation: Then, it performs a precise check using the detailed non-binary data to find the final matches.
What this means for Salesforce's AI assistant products
For Salesforce's AI products, like Agentforce and Einstein, speed on database lookups is a real constraint. Every time an AI agent answers a question, it may need to search tens of thousands of documents or records. A search pipeline that front-loads cheap binary comparisons and reserves the precise math for a smaller candidate pool can shave meaningful time off each query without requiring faster hardware.
The design also pairs with metadata filtering before any embedding comparison happens, which keeps the system from wasting compute on irrelevant rows entirely. Salesforce is clearly investing in the plumbing underneath its AI layer, and this patent sits alongside a broader wave of new Big Tech patents targeting AI search efficiency rather than raw model capability.
The core tradeoff here is accuracy for speed: by using a binary approximation as a pre-filter, the system risks discarding rows that would have ranked highly under the precise comparison. Salesforce's design bets that the binary pass is "good enough" to preserve the actual best matches in its candidate pool, which is a reasonable engineering assumption, but one that can degrade in edge cases where the compressed representation distorts meaning. Whether that tradeoff holds at production scale across Salesforce's diverse customer data is the real open question. For now, it reads as a sensible, if incremental, optimization for large-scale retrieval-augmented AI systems.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
4 drawing sheets from US 2026/0236537 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →