ChatGPT Voice vs Gemini Live: що обрати для голосової роботи

ChatGPT Voice і Gemini Live підтримують природний голосовий діалог, але слово Live не означає однаковий контракт. ChatGPT документує окремі Live, Advanced і Standard experiences: новий Live працює всередині чату з text, images, web search і memory, тоді як video та screen sharing спочатку лишаються в eligible Advanced mobile experience. Gemini Live у мобільному застосунку документує camera, повний screen sharing, background conversation та окремі connected-app actions.

Для розмови, яка продовжує текстовий ChatGPT workflow, почніть із ChatGPT Voice. Для mobile-first допомоги з камерою, екраном і дозволеними apps перевірте Gemini Live. Це гіпотези для pilot, не рейтинг: plan, region, account class, device, app version, workspace policy та voice mode змінюють surface.

• ChatGPT chat із voice → перевірте Live або Standard.
• Camera, screen і mobile actions → порівняйте Gemini Live з eligible ChatGPT Advanced.
• Managed account → перевірте admin policy на реальному workspace.
• Важлива відповідь → відкрийте джерело й перевірте transcript.

Запишіть provider, product, voice mode, model label, plan, personal або managed account, OS, device, app version, language, region, memory, web search, connected apps, camera, screen sharing, background і lock-screen settings. OpenAI прямо вказує залежність Voice options від plan, workspace settings, region, app version і parental controls. Google також обмежує частину Live можливостей платформою, акаунтом і settings.

Не змішуйте consumer voice із realtime API. Product chat включає власні memory, search, history, safety та entitlement, тоді як API має інший session contract, tools, logging, pricing і lifecycle. Якщо команда будує голосовий продукт, проведіть окремий API eval: успішна мобільна розмова не є integration evidence.

Створіть frozen set із тихої диктовки, шуму, довгої паузи, самовиправлення, перебивання, зміни мови, власної назви, дати, числа та неоднозначної команди. Збережіть reference transcript і acceptance criteria. Оцінюйте omissions, substitutions, interruption handling, semantic task success, latency bucket і повтори; не виводьте абсолютну точність із кількох приємних діалогів.

Після сесії порівняйте почуте значення, видимий transcript і відповідь. Якщо transcript спотворив ім'я або суму, evidence handoff не пройшов. Якщо transcript правильний, але система виконала інший intent, це теж failure. Для date-sensitive відповіді назвіть точну дату, timezone і location та відкрийте cited source.

• Listen → names, numbers, languages і noise.
• Converse → interruption, pause, correction і recovery.
• Ground → citations, exact date і uncertainty.
• Handoff → transcript, decision record і reviewer evidence.

Camera та screen sharing створюють ширшу data boundary, ніж microphone. Gemini попереджає, що під час screen sharing передається весь екран; ChatGPT Advanced також використовує device screen-sharing controls. Закрийте notifications, password manager, customer tabs, health або finance data, увімкніть test profile і попросіть згоду людей у кадрі або звуку. Mute microphone не означає зупинку video чи screen stream.

Перевіряйте visual grounding fixtures: один об'єкт, одна видима UI-помилка та одна заборонена область. Запитайте, що система бачить, перш ніж просити пораду. Після background, app switch або lock/unlock перевірте indicator і state заново: stop/resume behavior різниться, а припущення про завершення передачі не є privacy control.

Gemini Apps підтримує connected apps і для qualifying work або school accounts, але доступ залежить від Workspace edition, location, language, device, Keep Activity та admin enablement. Це не доводить, що конкретна дія доступна саме всередині поточної Gemini Live сесії: перед pilot зафіксуйте surface, account class, app і дозволену operation. ChatGPT Live документує web search і memory, але не connected apps; окремий Voice in Work and Codex у desktop app використовує інші tools та permissions. Кожну дію перевіряйте як authority boundary: identity, target, scope, proposed mutation, confirmation, result і undo.

Створіть harmless fixtures: test calendar event, task або note без реальних адресатів. Попросіть прочитати proposed values, підтвердьте один раз і звірте зовнішній стан. Для compound request окремо перевірте partial-failure contract: Google документує, що якщо одна required app недоступна, жодна з двох дій може не виконатися. Відсутність preview, confirmation, postcondition або rollback переводить workflow в read-only чи manual execution.

Capability snapshot на початку pilot швидко старіє. Перевірте чотири переходи на однакових fixtures: personal → managed account, enabled → admin-disabled app, foreground → background або lock, та Voice mode A → mode B. Після кожного переходу повторно зчитайте effective mode, visible indicators, connected-app availability, history/retention policy та write authority. Старий transcript може залишатися доступним, хоча новий retrieval через app уже заборонений; це різні стани, а не доказ, що revoke не спрацював.

Для ChatGPT окремо не змішуйте Voice in Chat із Voice in Work and Codex: desktop agent coordination має власний tool-and-permission envelope, а Live, Advanced і Standard відрізняються media та transcription behavior. Для Gemini перевірте edition, admin setting, Keep Activity, device і конкретну app operation. Approval receipt зберігає account class, mode, policy version, allowed tools, fixture ID і exact timestamp; зміна будь-якого поля анулює попередню production оцінку.

• Revoke → вимкніть app або Voice policy та перевірте, що новий access fail-closed.
• Switch → змініть mode чи account і повторіть camera, screen, transcript та action probes.
• Resume → протестуйте background, lock/unlock і повернення до foreground без прихованого capture.
• Recover → зафіксуйте user-facing error, manual fallback, audit event і відсутність partial write.

Перевірте, де зберігаються audio, video, transcript і chat, хто може їх переглядати, як видалити сесію та які controls діють для account class. OpenAI пов'язує clips із chat history і описує sharing controls; Google просить враховувати privacy інших людей та має окремі Live data notices. Не переносіть consumer setting на enterprise contract.

Decision record маршрутизує hands-free brainstorming, accessibility support, screen troubleshooting, camera guidance, grounded lookup або low-risk action. Для кожного вкажіть allowed data, approved mode, human checkpoint, fallback to text, evidence requirement, owner і review date. Rollback вимикає camera, screen, apps або voice та переводить задачу в текстовий чи людський канал.

Після product comparison не переносіть переможця одразу в робочий процес. Проведіть vendor-neutral чекліст оцінювання голосового асистента на frozen corpus: окремо перевірте critical tokens, перебивання, factual grounding, transcript, camera або screen boundary, sandbox actions, retention і rollback. Comparison відповідає, які surfaces варто тестувати; evaluation protocol відповідає, чи дозволений конкретний route для вашої ролі, identity та data class.

Promotion record має містити capability manifest, slice verdicts, blocking failures, approved inputs, human checkpoints, evidence destination й expiry. Не усереднюйте приємність голосу з correctness або privacy: сильний quiet conversation не компенсує неправильну дату в календарі, unsupported consequential claim чи невидимий screen-sharing state. Зміна mode, plan, app permission або privacy terms повертає route в re-evaluate.

• Compare → визначте candidate surfaces і intent boundary.
• Evaluate → frozen fixtures та окремі gates за risk slice.
• Promote → лише названі identity, data class і authority.
• Rollback → known-good text або human workflow.

Природне перебивання — це не одна метрика latency. Коли користувач починає говорити поверх відповіді, система має зупинити відтворення, розпізнати новий turn, визначити, чи він виправляє попередню умову, і не продовжувати застарілий план. Google документує окремий перемикач Interrupt Live responses; навіть коли голосове перебивання вимкнене, відповідь можна зупинити дотиком. Для ChatGPT capability receipt повинен називати фактичний Voice experience, device і settings, а не приписувати всім режимам однакову поведінку.

Тестуйте чотири значення перебивання: `stop` — лише зупинити озвучення; `correct` — замінити ім'я, число або дату; `constrain` — додати заборону чи scope; `cancel` — скасувати запропоновану дію. Після кожного turn попросіть коротко повторити чинні constraints до відповіді або tool proposal. PASS вимагає, щоб transcript, усний recap і наступний результат узгоджувалися; швидка зупинка аудіо при збереженні старої дати в намірі є failure, а не успішним barge-in.

• Playback state → чи припинився звук після barge-in.
• Transcript state → чи записано виправлення без змішування двох мовців.
• Intent state → яка умова тепер чинна, а яка явно скасована.
• Action state → чи анульовано старий preview, confirmation або queued write.
• Evidence state → timestamp, fixture, observed result і reviewer verdict.

Не називайте розмову безперервною лише тому, що audio відновилося. OpenAI описує умови завершення background conversation і окремі ліміти для video та screen sharing; Google документує, що camera або screen можуть зупинятися при pause, виході з app чи блокуванні екрана і не завжди поновлюються автоматично. Отже, після кожного переходу треба заново перевірити не тільки microphone, а й media indicator, active chat, remembered constraints, transcript continuity та write authority.

Побудуйте матрицю `foreground → background → lock → unlock → foreground`, а також окремо `usage limit`, `network loss`, `app termination` і `new chat`. Перед переходом задайте harmless canary: кодове слово, synthetic дату, заборонений recipient і вимогу не виконувати дію. Після повернення запитайте current task, constraints і media state. Якщо система не знає відповіді, правильний recovery — позначити context unknown, показати transcript користувачу та почати новий підтверджений turn; не відновлювати consequential intent із здогадки.

• Media continuity → microphone, camera і full-screen sharing перевіряються окремо.
• Semantic continuity → task, corrections і заборони повторюються після resume.
• Conversation continuity → той самий chat не гарантує той самий effective context.
• Authority continuity → старе підтвердження не переноситься через reconnect або new chat.
• Privacy continuity → після unlock або app switch повторно перевіряється visible capture indicator.

Для важливого workflow заздалегідь визначте recovery ladder: повторити усно один раз, показати transcript, перейти до тексту, відкрити authoritative record, потім попросити новий preview. Якщо interruption, noise, language switch або reconnect залишили сумнів щодо імені, суми, адресата чи дати, voice channel більше не має достатньої доказовості. Користувач виправляє значення у видимому тексті, а система створює новий proposal; попередній proposal отримує status `superseded` і не може бути виконаний пізніше.

Проведіть negative drill із sandbox calendar або task list: попросіть створити подію, перебийте під час повторення дати, заблокуйте телефон, відновіть сесію та змініть адресата. Очікуваний результат — жодного write до нового явного confirmation, один чинний preview, правильний зовнішній postcondition і можливість undo. Timeout після можливої дії переходить у `unknown`: спочатку звірте system of record, а не повторюйте команду. Так comparison дає команді не суб'єктивного переможця, а перевірений route із відомою межею відмови.

• Recoverable → transcript видимий, constraints відновлені, новий preview підтверджений.
• Degrade-to-text → critical token або current state неможливо довести голосом.
• Abstain → audience, media capture, account, context чи action state лишається unknown.
• Reconcile-before-retry → зовнішній запис перевірено після timeout або disconnect.
• Rollback → test write скасовано, stale proposal закрито, evidence receipt збережено.