Google Files Patent to Shrink the Memory Its AI Recommendation Systems Use
Every app that guesses what you'll tap next keeps a giant reference book for each kind of data it tracks. Google's filing proposes letting them all share one.
What Google's shared AI lookup table does
You scroll through a feed and the app guesses which item you'll tap next. To make that guess, the AI keeps a huge reference book that turns every detail, like an item's ID or the website it appears on, into a string of numbers it can work with.
Normally each kind of detail gets its own separate book. When there are hundreds of details and millions or even billions of possible values, those books get enormous. Google's filing describes putting everything into one shared book, where a value from one detail can land on the same page as a value from another.
Sharing pages sounds like a recipe for mix-ups, but the filing says the AI can still tell the details apart and that quality holds up. The payoff it describes is less memory, fewer lookups, and faster answers.
… establishing, by the computing system, a multiplexed embedding table in which at least two of the values that are respectively associated with at least two different features of the plurality of features are mapped to a shared vector in the multiplexed embedding table; …
Translation: Google saves memory by forcing different data types to share the exact same storage space.
How hashing lets different features share rows
The patent covers a way to build the lookup tables that machine-learning models rely on. These tables store embeddings (lists of numbers that stand in for a piece of data, such as a product ID or a word, so a model can work with it). Normally every feature, meaning each kind of input like a site or a content ID, gets its own table.
Google's claims describe a multiplexed embedding table instead: at least two values from two different features map to the same row. A hash function (a rule that scrambles any input into a row number) does the assigning, and it is allowed to produce inter-feature collisions, meaning values from different features landing on the same row. One named choice is a 2-universal hash function, a type that keeps collision rates predictable.
The filing also describes several variations:
- Features that need different embedding sizes can map a value to several rows, and the model joins the results together. One example uses sizes of 8, 16 and 64.
- Features with overlapping vocabularies, such as text from a search query and a document, can share the same hash function, which the filing says can slightly improve performance.
- The data can come from several different production systems.
Claim 11 adds the final step: pull an embedding from the shared table, feed it to a model, and output a prediction. The filing says keeping simple row-by-row lookups suits GPUs and TPUs (chips built for AI math), and its math argues that the model can learn to separate features that share rows.
… the multiplexed embedding table allows multiple features to share a single representation space. For example, in the multiplexed embedding table, at least two values that are respectively associated with at least two different features can be mapped to a shared vector (e.g., row) in the multiplexed embedding table.
Translation: Different data features are squeezed into the same rows to cut down on memory waste.
Why a smaller table matters for your recommendations
If this works as described, the services that guess what you'll click, watch or search for could run on less memory and answer faster. That matters because every one of those guesses starts with a lookup, and these tables can hold millions to billions of entries per feature. Shrinking them cuts the hardware bill and the wait. The filing also lists uses well beyond feeds, including translation, image tagging and genetic sequences.
Google says sharing rows does not hurt accuracy and points to an appendix for the evidence, so treat that as the company's own claim for now. The examiner's first review rejected the claims as filed, a routine step that usually leads to amendments, so the final scope may end up narrower than what you see here.
Google's 78th filing in our AI assistant & agent coverage since May follows a cost-dial for chatbots and TV that wakes when you sit.
You will never see a button for this. What you might notice is a feed, search box or recommendation row that responds a little faster, or a service that is cheaper for Google to run.
The idea is clear: stop giving every kind of data its own reference book and make them share. Collisions sound like a recipe for confused predictions, and Google says the model learns to tell the features apart, though the proof sits in an appendix outside this text.
If the quality claim holds, the benefit is invisible but useful: the same answers for less hardware. If it does not, the savings would come with worse guesses that you would feel as odder recommendations.
Get our take in your Top Stories
Liked this breakdown? Add Patentlyze as a preferred source on Google, and our plain-English take shows up more often in your Top Stories the next time Google patent news breaks.
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
5 drawing sheets from US 2026/0320018 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →
Be the first to weigh in