Why do hash collisions hurt recommendation models so much?

DLRM-style recommender architectures depend on embedding tables that map sparse categorical IDs (user IDs, item IDs) to dense vectors. The table is enormous — billions of users times tens of millions of items times embedding dimension — and cannot fit in single-host memory. The standard engineering response is low-collision hashing: hash IDs into a fixed-size table and accept some collisions where unrelated entities share the same embedding row.

The hidden assumption is that IDs are evenly distributed in frequency, so collisions are rare and harmless. Monolith's empirical observation contradicts this: real recommendation systems have power-law distributions where a small group of users and items have orders of magnitude more occurrences than the rest. A high-frequency user colliding with another high-frequency user produces a corrupted embedding for both — hash collisions are concentrated on the entities the model most needs to represent accurately.

Furthermore, the table grows over time as new IDs are admitted, but conventional frameworks use fixed-size dense tensors. Without elastic growth, hash collisions worsen monotonically. The proposed fix is collisionless embedding tables that admit new IDs dynamically and use direct addressing rather than hashing. The cost is engineering complexity; the benefit is preserving model quality as the system scales. The general lesson: standard ML infrastructure assumptions are silently calibrated for uniform distributions, and recommendation data violates that assumption hard.

Source: Recommenders Architectures