Як оцінити AI-голосового асистента: практичний чекліст

Голосовий асистент не є одним продуктом для всіх задач. Hands-free brainstorming, навігація екраном, навчальна розмова, customer support, медична нотатка й команда на зміну календаря мають різні наслідки. До вибору сервісу запишіть роль, користувача, середовище, дозволені дані, очікуваний результат, систему запису та помилку, після якої тест зупиняється. Окремо позначте, чи асистент лише говорить, читає приватні джерела або може запропонувати зовнішню дію.

Зафіксуйте authority ladder: відповідь без дії, read-only lookup, підготовка чернетки, дія після явного підтвердження або заборонена дія. Голос не повинен скорочувати контроль лише тому, що confirmation прозвучало природно. Для платежів, публікації, доступів, медичних чи юридичних рішень асистент готує інформацію, а уповноважена людина перевіряє її в авторитетній системі.

• Use case → хто говорить, де, навіщо і який результат приймається.
• Data boundary → мікрофон, камера, екран, файли, memory та connected apps.
• Authority → read, propose, confirm або заборонити.
• Stop condition → помилка, витік, відсутність evidence чи rollback.

Перед тестом запишіть provider, product surface, voice mode, plan, account class, device, OS, app version, region, language, network profile, microphone, headphones, permissions, memory, search, apps, camera, screen sharing і background settings. Порівнюйте consumer assistant лише з consumer assistant; realtime API, dictation і meeting recorder мають інші session, retention, tool та pricing contracts.

Побудуйте frozen corpus із 24–40 коротких сценаріїв. У ньому мають бути тихе мовлення, типовий кімнатний шум, довга пауза, перебивання, самовиправлення, зміна мови, власні назви, дати, валюти, схожі слова, неоднозначна команда й запит, на який слід відмовитися відповідати без доказу. Для кожного fixture збережіть reference meaning, допустимі варіанти, критичні токени й acceptance rule; не публікуйте вигаданий загальний відсоток точності з одного пристрою.

Listening gate відокремлює те, що людина сказала, від того, що система зрозуміла. Reviewer порівнює критичні імена, числа, заперечення, мову та intent із reference. Звичайна орфографічна різниця може бути несуттєвою, але пропущене «не», неправильна сума або інша дата є blocking failure для відповідного use case. Якщо продукт показує transcript, перевіряйте його окремо: transcript після розмови може не бути дослівним доказом почутого аудіо.

Turn-taking gate перевіряє barge-in, паузу для обдумування, background speech, echo, app switch, lock screen, втрату мережі та повернення до розмови. Запишіть, чи система зупинила відповідь, зберегла останню correction і не прийняла чужий голос за команду. Один tester виконує однаковий сценарій у рандомізованому порядку, а blind reviewer оцінює записаний outcome без назви продукту там, де це дозволяє політика.

• Meaning preserved → intent і критичні токени не змінені.
• Barge-in → система припиняє стару відповідь і приймає correction.
• Silence → довга пауза не створює вигадану команду.
• Recovery → після network або app interruption видно поточний state.

Для factual tasks дайте точну дату, timezone, jurisdiction і source policy. Після spoken answer відкрийте посилання або authoritative record, розбийте відповідь на atomic claims і позначте supported, partial, contradicted, stale чи unsupported. Citation поруч із відповіддю не доводить кожне речення; відсутність зручного екрана не дозволяє голосу приховати джерело. Consequential unsupported claim блокує маршрут незалежно від природності голосу.

Evidence handoff має пережити завершення сесії. Збережіть run ID, manifest, prompt meaning, transcript або дозволену нотатку, source URLs, supporting passages, critical corrections, result, reviewer і expiry. OpenAI прямо зазначає, що Voice transcript може не збігатися з розмовою, тому за потреби reviewer фіксує critical claim вручну, не видаючи transcript за дослівний запис. Якщо доказ неможливо безпечно експортувати, продукт лишається для low-consequence conversation, а не для auditable decision.

Створіть test profile без реальних листів, notifications, паролів, клієнтських вкладок і персональних фото. Для camera fixture покажіть один дозволений об'єкт та одну заборонену область; для screen fixture — навчальний UI з навмисною помилкою. Попросіть асистента спочатку описати видимий scope, потім виконати завдання. Перевірте indicators і те, коли stream припиняється після hold, app switch, background або screen lock.

Google документує, що Gemini Live передає повний екран під час screen sharing, а його поведінка stop/resume залежить від hold і lock. У ChatGPT camera та screen також залежать від mode, eligibility і mobile controls. Ці офіційні описи встановлюють capability boundary, але не доводять безпеку конкретної організації. Люди в кадрі або записі мають дати належну згоду; локальні правила запису перевіряє відповідальний owner.

• Minimize → test profile, закриті notifications і один потрібний frame.
• Consent → видима й зрозуміла згода учасників за чинними правилами.
• Indicator → окремо перевірити microphone, camera та screen state.
• Resume test → після hold або lock не припускати попередній стан.

Для календаря, нотатки, повідомлення чи connected app використайте sandbox identity та неіснуючих зовнішніх адресатів. Асистент має повторити target, дату, timezone, зміст і наслідок до підтвердження. Tester підтверджує один раз, після чого окремо звіряє postcondition у зовнішній системі. Плавна spoken acknowledgement не є доказом, що дія відбулася саме один раз і з правильними полями.

Перевірте duplicate request, ambiguous recipient, correction after preview, permission revoke, timeout і undo. Якщо немає надійного preview, idempotency або rollback, залиште маршрут read-only чи manual. Не використовуйте voice pilot для реальних покупок, production deploy, permission grants або масових повідомлень. Authority розширюється лише після окремого risk review, а не після високої оцінки діалогу.

Перевірте account-specific правила збереження audio, video, screen, transcript і chat; training controls; видалення; admin settings; human review; export і retention. OpenAI пов'язує clips із chat history та описує окремі controls, а Google Privacy Hub пов'язує Gemini Live data з Keep Activity і налаштуваннями recordings. Не переносіть поведінку personal account на Business, Enterprise, school або API contract.

Accessibility не зводиться до голосу. Перевірте captions, text fallback, mute/hold, keyboard або switch access, читабельність transcript, контроль темпу, повторення, correction і роботу з різними акцентами без твердження про універсальну доступність. Залучіть представників цільової групи за згодою та не збирайте sensitive attributes без необхідності. Окремо виміряйте reviewer minutes, recovery time, support burden і battery/network constraints.

Не усереднюйте всі тести в один красивий score. Сформуйте verdict за slices: quiet conversation, noisy environment, multilingual use, grounded lookup, visual assistance та sandbox action. Для кожного встановіть blocking failures і допустимий fallback. `Approve` дозволяє названий scope; `restrict` прибирає camera, connected action або sensitive data; `reject` повертає workflow до тексту чи людини; `re-evaluate` чекає на виправлення або нову capability.

Decision record містить approved manifest, routes, data classes, human checkpoints, evidence destination, owner, review date та rollback. Зміна mode, plan, privacy terms, app permissions, model behavior, device fleet або failure pattern запускає новий прогін frozen corpus. Rollback вимикає voice, camera, screen і connected apps, скасовує sandbox actions, відкликає sharing та повертає останній approved text або human workflow.

• Approve → лише конкретні slices, identity та data classes.
• Restrict → прибрати ризиковий input або write authority.
• Reject → зберегти known-good text чи human route.
• Re-evaluate → повторити corpus після material change.

Станом на серпень 2026 року назва продукту вже недостатня для відтворюваного тесту. OpenAI окремо описує Live як новіший Voice surface на GPT-Live-1 / GPT-Live-1 mini: він підтримує природний turn-taking, web search, memory, text та images, але на launch surface не підтримує video, screen sharing, connected apps або plugins. Video і screen sharing залишаються окремою capability eligible mobile Advanced Voice. Тому manifest має фіксувати не просто «ChatGPT Voice», а точний mode, plan, account/workspace, device, app version, region і ввімкнені capabilities. Інакше два reviewers формально тестують один бренд, але фактично різні системи.

Gemini Live має інший capability contract: Google документує camera і full-screen sharing у mobile Live. Screen sharing автоматично зупиняється, якщо Live поставлено on hold або екран заблоковано, і не відновлюється автоматично після resume/unlock; його треба ввімкнути повторно. Це не дрібна UI-деталь, а окремий state-transition test: evaluator має перевірити, що після hold, lock, app switch або reconnect система не успадковує старий visual scope мовчки.

Privacy manifest також version-bound. OpenAI прямо попереджає, що Voice transcripts не є verbatim record, а audio/video retention залежить від voice surface і data controls. Google Gemini Apps Privacy Hub, оновлений 10 серпня 2026 року, окремо описує Live transcripts, recordings, video/screenshares та Keep Activity. Тому privacy verdict не переноситься між personal, workspace, plan або provider surfaces і має перевірятися на дату promotion.

• Freeze exact surface → provider + mode + plan + account/workspace + device + app version + region.
• Separate capability gates → voice, image, camera, screen, search, memory, connected apps і external actions тестуються окремо.
• Test state transitions → hold, lock, background, reconnect і permission revoke не повинні неявно відновлювати попередній scope.
• Re-check privacy → retention, training controls, transcript semantics і deletion перевіряються на поточних account-specific terms.

NIST 7 серпня 2026 року опублікував initial public draft TEVV-Athlon (NIST AI 200-2) як розширюваний підхід до test, evaluation, verification and validation AI-систем у реальних application contexts. Це draft, а не фінальний стандарт, але його напрям корисний для voice evaluation: вимоги, fixtures, середовище, human factors і observed outcomes мають бути прив'язані до конкретного use case, а не до абстрактного рейтингу моделі.

Практичний release packet тому зберігає два рівні доказу. Component evidence описує listening, turn-taking, transcript, retrieval або tool behavior; outcome evidence підтверджує, що користувач отримав правильний результат у system of record без небезпечного side effect. Якщо spoken response звучить ідеально, але календар містить неправильний timezone, screen scope лишився невідомим або external action не підтверджений authoritative postcondition, outcome gate залишається FAIL або UNKNOWN.

• Requirement → конкретний task, risk tolerance і blocking failures.
• Fixture → frozen audio/visual/action scenario з reference outcome.
• Observation → trace, transcript limitation, source evidence та authoritative postcondition.
• Decision → PASS, RESTRICT, FAIL або UNKNOWN по risk slice; один середній score не маскує critical failure.