# A cited AI answer can still be wrong: the retrieval bug we found in ZettaVector > Source: > Published: 2026-08-27 16:50:12+00:00 We asked our agent a simple question: “How can I get in touch?” It returned `email@joes.com` . The answer included a valid citation to the company homepage. It was also wrong. The address belonged to a fictional lead in a product demo. The real business address appeared in the footer of the same page. Our system found both addresses, then assigned the wrong role to the first one. ## The answer passed the obvious checks This was not a fabricated address. It was not a failed crawl. It was not a missing chunk. The retrieved page contained the returned text, so the citation validator accepted it. Several parts of the grounding pipeline were working: - The homepage had been crawled and indexed. - The retrieval result contained relevant contact evidence. - The returned email existed in the cited source. - The source reference matched the retrieved chunk. The failure happened after retrieval. The contact recovery path scanned the evidence in citation order and selected the first syntactically valid email. SIMPLIFIED RETRIEVED EVIDENCE [1] Live results dashboard Joe's Pizza · 87 · email@joes.com Bright Smile Dental · 82 · contact@smile.com [2] NexalLabs · Enterprise · Feedback wchisasa@outlook.com © 2026 NexalLabs. All rights reserved. The first chunk described product output. The second chunk described the business. A regular expression could identify each email, but it could not identify what each email represented. ## The flawed assumption The original recovery behavior was equivalent to this simplified code: ``` js for (const source of retrievedEvidence) { const email = findFirstEmail(source.text) if (email) { return email } } ``` This logic answered one question: Does the retrieved evidence contain a valid email address? That check was necessary, but it was too weak. Contact recovery also needed to ask whether the page presented that address as an official way to reach the business. ## A citation proves origin, not meaning Citations are useful because they let a reader inspect the source behind an answer. They do not prove that the system interpreted the source correctly. | CHECK | WHAT IT ESTABLISHES | |---|---| | Valid citation | The cited source contains the referenced text. | | Grounded claim | Retrieved evidence supports the words in the answer. | | Contextually correct answer | The evidence has the role and meaning assigned to it. | Our answer satisfied the first two checks. It failed the third. The source contained `email@joes.com` , but the page presented it as sample lead data, not the company contact address. ## We changed selection into ranking The fix evaluates every retrieved email candidate. Each candidate receives a score based on nearby text. The system then sorts by score and uses source order only to break a tie. Strong business-contact signals add weight: - Direct labels such as “contact,” “email,” “support,” or “sales” - Contact phrases such as “get in touch” - Business context such as “enterprise” or “feedback” - Footer signals such as a copyright mark or “all rights reserved” Demo and interface signals subtract weight: - “Demo,” “sample,” “prospect,” or “lead” - “Dashboard,” “results table,” or “outreach hook” - Table headings such as “business,” “score,” or “website quality” - Several email addresses inside the same chunk The production logic also applies a minimum score to email candidates. If every address looks like example data, contact recovery returns nothing. The agent does not expose the least bad candidate. ``` js const candidates = evidence .flatMap(findEmailCandidates) .filter(candidate => candidate.score >= minimumScore) .sort(byScoreThenSourceOrder) return candidates[0] ?? null ``` This is simplified code. The important change is the decision boundary. Finding a matching string is no longer enough. RESULT AFTER CONTEXT SCORING Demo table candidate email@joes.com score: rejected Business footer candidate wchisasa@outlook.com score: selected ## The refusal case matters as much as the success case We added two regression tests around the production failure. - Place multiple realistic demo addresses before the footer address. The footer address must win. - Provide a page that contains only a demo lead address. The system must say that the available information does not specify a business email. The second case protects the more important behavior. When evidence is ambiguous or low quality, the system should not turn a plausible string into an official claim. ## What we took from the bug ### Retrieval order is not authority order Similarity ranking finds text related to the question. It does not establish which part of a page is authoritative. A product demo can be highly similar to a contact query because it contains names, companies, and email addresses. ### Example content is dangerous evidence Realistic examples are useful to visitors. They are also easy for an automated system to mistake for business facts. Demo tables, testimonials, templates, and screenshots need stronger contextual treatment. ### Deterministic code still needs semantic safeguards This failure came from a deterministic recovery path, not a model response. Removing model variability did not remove the need to reason about meaning. ### Grounding is a pipeline A grounded system needs more than retrieval and citations. It also needs exact source binding, claim validation, context-aware selection, and a safe refusal path. A pass at one stage does not guarantee a correct final answer. ## What this fix does not solve This change addresses contact selection when retrieved pages contain several email candidates. It does not solve every retrieval or grounding failure. Ambiguous phone-number questions, sentence fragments, and repeatability across identical queries require separate tests. We track those cases independently. The goal is not to label the pipeline “solved.” The goal is to make each failure observable, reproducible, and harder to repeat. ## The standard we want ZettaVector answers questions on behalf of a real business. A response can affect whether a visitor trusts that business or reaches the right person. “The text appeared somewhere on the page” is not a sufficient standard. A useful cited answer needs the right source, the right claim, and the right interpretation. This bug gave us the source and the claim. Fixing it required us to handle the meaning too.