How to Audit Duck.ai Voice Search Against Typed Answers

Separate live voice, dictation, and typed chat

A microphone icon does not create one stable experimental condition. The product documentation describes two audio paths, and typed chat adds a third comparison. Record the mode before recording the answer.

The strictest paired comparison is dictation versus typing with the same final prompt, selected model, chat state, device, location state, and short time window. Live voice can still be audited, but treat it as a separate product path unless DuckDuckGo documents route parity or the interface exposes enough fields to prove it.

Write the question and stopping rule before the run

Choose one question per audit. A transcript-fidelity test asks whether spoken words reached the text field correctly. A retrieval test asks whether the visible source set changed. An answer-support test asks whether cited pages support the claims beside them. Mixing all three into one score hides the failure that needs repair.

For a small manual audit, start with 12 prompts across four jobs: stable facts, recent changes, local questions, and questions that should trigger uncertainty. Use three repetitions per mode when limits allow. Pair the modes inside a short declared window, randomize their order, and keep a clean chat when previous turns could change the answer.

Freeze the environment that the interface exposes

Record the product surface, browser or app, version, operating system, device class, account or subscription state, selected model when visible, reasoning setting, language, country, location permission, microphone permission, date, local time, and chat state. Take a screenshot of the settings that affect the run, but keep the structured row as the analysis record.

Do not record a guessed model. DuckDuckGo’s current voice documentation says live voice uses an OpenAI model but does not name its identifier. Store not disclosed in that field. An explicit unknown is safer than a fabricated control.

Location deserves two fields: permission state and the location expressed in the prompt. A local answer can use the words in the question, device context, current time, or other product behavior. A correct local response does not reveal which input caused it.

Capture the transcript before correcting it

Save four strings when the mode uses audio: the intended prompt, an ordinary-language note of what was actually spoken, the first displayed transcript, and the final submitted text. Do not include raw audio in a public artifact. A voice can be a biometric identifier, and DuckDuckGo’s privacy documentation explicitly asks users to consider that risk.

For dictation, take the raw-transcript capture before editing. Then record each correction or save the final text and a correction count. If the final text becomes identical to the typed control, the pair can test downstream output under visible prompt parity; it no longer tests whether transcription errors affected that output.

For live voice, the transcript and response may form one continuous interaction. Record the visible transcript as presented and note whether the interface allowed correction. Never silently repair a product transcript in the dataset.

Preserve sources before scoring the prose

Copy every displayed source label and URL before following redirects. Store the resolved canonical separately and record where the source appeared: inline, below the answer, in a drawer, or after another interaction. A blank source set is a result, not a row to discard.

Then review answer claims one by one. A linked page may support the nearby statement, contradict it, or be merely related. Record the strongest classification the evidence supports. The citation and recommendation measurement guide explains why source presence, claim support, recommendation, and referral are different events.

Compare within a mode before comparing modes

Generated answers and current web results can vary between repetitions. Calculate stability among typed runs, among dictation runs, and among live-voice runs before comparing one mode with another. If each mode is unstable, a low voice-versus-text source overlap may be ordinary run variance.

For paired source sets, Jaccard overlap equals the number of normalized URLs in both sets divided by the number in either set. Report an empty-pair state when both sets contain no sources instead of assigning a perfect score. Keep the displayed URLs as evidence and use normalized URLs only for comparison.

Stratify results by prompt job. Local and recent questions may move more than stable factual questions. A single blended average can hide that difference. The broader AI search interface-drift guide shows how to keep interface effects and repeat instability separate.

Use the ledger and browser-local analyzer

Download the Duck.ai voice and text audit ledger (CSV). Its 44 fields preserve the environment, privacy decision, transcript path, source set, claim review, completion state, timing, limitations, and reviewer decision for one prompt run. Six rows are marked EXAMPLE-REMOVE; delete them before collecting real observations.

The browser-local pair analyzer reads the same CSV without uploading it. It checks required fields, groups rows by pair, calculates transcript word error rate when a reference and raw transcript exist, compares normalized source sets, and exposes missing parity controls. The summaries describe the loaded file only. They are not Duck.ai benchmarks.

A minimum reviewable pair

• The same pair_id, prompt fixture, run number, and short collection window.
• One typed row and one declared audio-path row.
• The intended, raw, and submitted text saved without invented values.
• Matching visible environment fields or an explicit mismatch reason.
• Displayed and resolved source URLs retained separately.
• A reviewer decision of compare, hold, exclude, or rerun.

Set a privacy boundary before recording

DuckDuckGo says live voice audio is streamed to OpenAI through an encrypted relay, dictation audio is sent for transcription, and neither company retains the audio after the session under the documented contract. It also notes that an unaltered voice can act as a biometric identifier. Those provider statements do not remove the researcher’s responsibility for consent, minimization, local storage, screenshots, and publication.

Use the researcher’s own voice or obtain explicit consent. Keep names, addresses, health details, account data, and private local queries out of the fixture. Publish transcripts and structured observations only when they are necessary, redact identifiers, and set a deletion date for any local audio. If consent or secure handling is unresolved, use typed prompts and stop the audio condition.

Report only the observed boundary

A defensible report names the tested modes, dates, product surface, browser or app, visible model state, language, location permission, prompt fixture, repetitions, transcript capture, correction rule, source normalization, claim rubric, privacy exclusions, missing fields, and stopping rule.

Use language such as “the live-voice and typed paths returned different displayed source sets in 7 of 12 valid pairs.” Do not convert that observation into “voice ranks different sources.” The current documentation does not identify the retrieval provider, prove model parity, or expose a ranking contract for this comparison.

The original page promised a product experiment that was never run. This rebuilt guide preserves the stable URL but replaces the pending-result claim with an executable method. For a separate DuckDuckGo result-page task, use the expanded result previews audit.

Primary documentation

• DuckDuckGo: What’s New, Q2 2026
• DuckDuckGo: Is Duck.ai voice chat and dictation private?
• DuckDuckGo: Duck.ai help

Evidence boundary: these sources document the current product contract and provider statements retrieved September 1, 2026. They do not supply a voice-versus-text accuracy benchmark, retrieval-provider identity, model-parity guarantee, or causal ranking claim.