Why are we accepting silent data corruption in Vector Search? (x86 vs. ARM)

5 points by varshith17 145 days ago | 10 comments

I spent the last week chasing a "ghost" in a RAG pipeline and I think I’ve found something that the industry is collectively ignoring.

We assume that if we generate an embedding and store it, the "memory" is stable. But I found that f32 distance calculations (the backbone of FAISS, Chroma, etc.) act as a "Forking Path."

If you run the exact same insertion sequence on an x86 server (AVX-512) and an ARM MacBook (NEON), the memory states diverge at the bit level. It’s not just "floating point noise" it’s a deterministic drift caused by FMA (Fused Multiply-Add) instruction differences.

I wrote a script to inspect the raw bits of a sentence-transformers vector across my M3 Max and a Xeon instance. Semantic similarity was 0.9999, but the raw storage was different

For a regulated AI agent (Finance/Healthcare), this is a nightmare. It means your audit trail is technically hallucinating depending on which server processed the query. You cannot have "Write Once, Run Anywhere" index portability.

The Fix (Going no_std) I got so frustrated that I bypassed the standard libraries and wrote a custom kernel (Valori) in Rust using Q16.16 Fixed-Point Arithmetic. By strictly enforcing integer associativity, I got 100% bit-identical snapshots across x86, ARM, and WASM.

Recall Loss: Negligible (99.8% Recall@10 vs standard f32).

Performance: < 500µs latency (comparable to unoptimized f32).

The Ask / Paper I’ve written a formal preprint analyzing this "Forking Path" problem and the Q16.16 proofs. I am currently trying to submit it to arXiv (Distributed Computing / cs.DC) but I'm stuck in the endorsement queue.

If you want to tear apart my Rust code: https://github.com/varshith-Git/Valori-Kernel

If you are an arXiv endorser for cs.DC (or cs.DB) and want to see the draft, I’d love to send it to you.

Am I the only one worried about building "reliable" agents on such shaky numerical foundations?

realitydrift 138 days ago |

This reads more like a semantic fidelity problem at the infrastructure layer. We’ve normalized drift because embeddings feel fuzzy, but the moment they’re persisted and reused, they become part of system state, and silent divergence across hardware breaks auditability and coordination. Locking down determinism where we still can feels like a prerequisite for anything beyond toy agents, especially once decisions need to be replayed, verified, or agreed upon.

codingdave 144 days ago |

> We assume that if we generate an embedding and store it, the "memory" is stable.

Why do you assume that? In my experience, the "memory" is never stable. You seem to have higher expectations of reliability than would be reasonable.

If you have proven that unreliability, that proof is actually interesting. But seems less like a bug, and more of an observation of how things work.

varshith17 144 days ago | |

"You seem to have higher expectations of reliability than would be reasonable."

If sqlite returned slightly different rows depending on whether the server was running an Intel or AMD chip, we wouldn't call that "an observation of how things work." We would call it data corruption.

We have normalized this "unreliability" in AI because we treat embeddings as fuzzy probabilistic magic. But at the storage layer, they are just numbers.

If I am building a search bar? Sure, 0.99 vs 0.98 doesn't matter.

But if I am building a decentralized consensus network where 100 nodes need to sign a state root, or a regulatory audit trail for a financial agent, "memory drift" isn't a quirk, it's a system failure.

My "proof" isn't just that it breaks; it's that it doesn't have to. I replaced the f32 math with a fixed-point kernel (Valori) and got bit-perfect stability across architectures.

Non-determinism is not a law of physics. It’s just a tradeoff we got lazy about.

varshith17 145 days ago |

Github repo: https://github.com/varshith-Git/Valori-Kernel

chrisjj 144 days ago |

> Am I the only one worried about building "reliable" agents on such shaky numerical foundations?

You might be the only one expecting a reliable "AI" agent period.

varshith17 144 days ago | |

"You might be the only one expecting a reliable 'AI' agent period."

That is a defeatist take.

Just because the driver (the LLM) is unpredictable doesn't mean the car (the infrastructure) should have loose wheels.

We accept that models are probabilistic. We shouldn't accept that our databases are.

If the "brain" is fuzzy, the "notebook" it reads from shouldn't be rewriting itself based on which CPU it's running on. Adding system-level drift to model level hallucinations is just bad engineering.

If we ever want to graduate from "Chatbot Toys" to "Agentic Systems," we have to lock down the variables we actually control. The storage layer is one of them.

michalsustr 143 days ago | | |

It actually gets worse. The GPUs are numerically non deterministic too. So your embeddings may not be fully reproducible either.