A transit rider-alert model confuses two stations with similar-sounding names when matching free-text complaints. Which foundation concept best explains that mix-up?

Text embeddings map phrases into vector space, where semantically or lexically related strings become near neighbors. When a rider-alert model confuses similarly named stations, free-text complaints may retrieve, classify, or route to the wrong stop because embedding similarity is not the same as operational identity. This is embedding neighborhood behavior, not a network service failure. DHCP lease exhaustion on station Wi-Fi controllers can deny devices addresses and disrupt connectivity, but it does not make an NLP matching layer swap station identities. An SMTP relay fault could delay rider alerts, but it would not change how station names are matched. Missing HSTS headers on the transit mobile site weaken browsers’ HTTPS upgrade guarantees; that web transport hardening gap is unrelated to embedding-based station mix-ups. Exam caveat: similar names can also confuse string matching, fuzzy search, or speech-to-text, not only dense embeddings, so read the stem for the foundation concept being tested. RAG retrieval returning the wrong station document is another embedding or ranking failure mode, with operational impact equal to a classifier mix-up. In practice, maintain a canonical station gazetteer with unique IDs, constrain matching to ID lookup after entity resolution, test near-duplicate station pairs, require confirmation when similarity scores are ambiguous, and separate rider-facing names from internal identifiers in alerts. A wrong station in an alert is a safety and trust failure, so treat embedding collisions as a first-class quality gate.