ИИ для жестового языка на телефоне: что уже возможно и чему это учит phone-agent дизайн

Что умеет жестовый ИИ на телефоне сейчас

ИИ для жестового языка на телефоне уже перешел из лабораторного обещания в первую заметную пользовательскую функцию, но границы нужно читать точно. В публикации Google DeepMind о sign-language AI описано, что SL2T приносит ASL-to-English sign dictation в Gboard и Live Transcribe сначала на Pixel 11. Это значит: пользователь, использующий American Sign Language, может получить английский текст из жестового ввода в поддержанных местах, где доступна эта функция.

Это важный milestone для phone accessibility, потому что телефон перестает считать голос единственным «естественным» способом ввода. Для части задач sign-to-text может стать мостом: написать сообщение, ввести текст в поле, участвовать в разговоре, показать свою фразу слышащему человеку или подготовить текст для дальнейшего действия. Но это именно language input, а не доказательство, что жестовый ИИ уже управляет Android, выбирает приложения, отправляет сообщения или выполняет телефонные действия без отдельного подтверждения.

Текущая доступность также не универсальна. DeepMind описывает старт с ASL-to-English на Pixel 11 и говорит о дальнейшем расширении устройств и языков как о будущей работе. Нельзя переносить это на все Pixel, все Android-телефоны, все жестовые языки или все сценарии общения. ASL — один жестовый язык, а не универсальный код жестов для всего мира.

С точки зрения builders phone agents это событие меняет фокус. Доступный ИИ-агент должен принимать, что пользователь может вводить намерение голосом, текстом, жестовым языком, переключателем, текущим экраном или другим способом. Но после ввода остается тот же ответственный путь: понять intent, выбрать target, показать результат, запросить permission и дать возможность исправить ошибку. Если вам нужен голосовой accessibility route для другой аудитории, рядом полезен материал Голосовое управление Android для незрячих и слабовидящих: TalkBack, Voice Access и FoneClaw.

Почему это не транскрипция речи

Жестовый язык в текст Android нельзя понимать как «распознавание речи, только руками». Жестовые языки — самостоятельные естественные языки. В мире существует более 200 жестовых языков, и они не являются одной универсальной системой. ASL отличается от British Sign Language, Russian Sign Language, Japanese Sign Language и других языков так же принципиально, как устные языки отличаются друг от друга.

В жестовом языке значение передается не только handshape. Важны положение рук, движение, направление, пространство перед телом, выражение лица, взгляд, корпус, темп, повторение и пространственные конструкции. Многие элементы происходят одновременно, а не идут линейной цепочкой слов. Поэтому модель должна переводить язык, а не просто подставлять английское слово на каждый жест.

Отсюда вытекает продуктовый урок. Подходы, которые распознают только набор жестов, glove-сигналы или маленький vocabulary, могут быть полезны для команд, но они не равны полноценному sign-language translation. Если телефонный помощник для глухих пользователей принимает только «жест А означает команду Б», он обслуживает ограниченный command interface, а не язык пользователя.

Для phone-agent design это особенно важно. Переведенная фраза может быть естественной, неоднозначной, контекстной или требовать уточнения. Например, человек может sign «ответь ей позже»; агенту все еще нужно понять, кто «она», где открыт conversation, что значит «позже» и нужно ли создать reminder или draft. Sign-to-text дает вход, но не отменяет intent resolution.

Как работает SL2T и где остаются риски

DeepMind описывает SL2T как архитектуру, где телефон сначала работает с визуальным сигналом, а затем модель переводит жестовый язык в текст. По описанию Google, MediaPipe Holistic извлекает pose landmarks на устройстве. Затем geometric coordinates отправляются на сервер, а raw video отбрасывается according to DeepMind. Это важная privacy boundary: не весь процесс полностью локальный, и coordinates не стоит автоматически считать «безрисковыми» во всех юридических или пользовательских контекстах.

Вместо промежуточного этапа «распознать отдельные жесты, потом собрать предложение» SL2T движется к direct landmark-to-text modeling. Это лучше соответствует тому, как работает естественный язык: смысл зависит от последовательности, пространства, мимики и контекста. DeepMind также описывает training scale: более 100,000 часов данных и более 50 sign languages в обучении. При этом initial product support остается ASL to English, и это надо проговаривать отдельно.

Наличие большого training corpus не означает human parity. Официальные примеры DeepMind показывают оставшиеся error types: rare signs, rapid fingerspelling, classifiers, passive constructions и tense. Для пользователя это практический сигнал: переведенный текст нужно проверять, особенно если он станет сообщением, инструкцией, записью в календарь, медицинской заметкой, рабочим письмом или юридически значимой фразой.

SL2T также зависит от физического сценария. Камера должна видеть руки, лицо и корпус. Освещение, framing, движение телефона, фон, скорость signing, left-handed signing, one-handed signing и индивидуальный стиль могут влиять на качество. DeepMind отдельно описывает участие Deaf participants и advisory committee, что важно: accessibility system нельзя строить только из benchmark-таблицы.

Вывод для builders: архитектура sign-to-text должна объяснять, что обрабатывается на устройстве, что уходит на сервер, что удаляется, как долго хранится, какие ошибки типичны и где пользователь исправляет результат. Без этой прозрачности телефонный помощник для глухих пользователей превращается в непрозрачный черный ящик.

Как выбрать доступный ввод и вывод

Доступность ИИ без голоса не сводится к одному решению. Для разных задач нужны разные input и output routes. Иногда лучший ввод — жестовый язык в текст. Иногда typed text. Иногда captions. Иногда RTT during calls. Иногда Switch Access. Иногда visual confirmation, vibration или typed response важнее speech output. Хороший доступный ИИ-агент выбирает modality по задаче, а не ранжирует пользователей.

В справке Android о Live Transcribe описано, что функция превращает nearby speech and sounds в text on screen, поддерживает typed responses, sound labels, history controls и selected offline languages на supported devices. Это не sign-language recognition, но важная часть conversation accessibility.

В справке Android о Live Caption Google описывает captions for supported media and calls и on-device processing для Live Caption. Эту on-device statement нельзя переносить на SL2T, Live Transcribe или FoneClaw. У каждой modality свой privacy model.

Общий набор Android accessibility options шире: обзор Android Accessibility включает screen readers, captions, switch, braille, RTT и другие инструменты. Но availability varies by device. Поэтому accessibility workflow нужно проектировать как toolbox с fallback, а не как одну универсальную функцию.

От жестового ввода к безопасному действию

Переведенный текст не является выполненным действием. Если SL2T превратил ASL в английскую фразу «send this to Alex», телефонный агент все еще должен определить, кто Alex, через какое приложение отправлять, какой текст именно отправляется, есть ли permission, нужен ли draft, что будет видно на экране и как пользователь отменит действие. Доступный input не отменяет safe action design.

Для low-impact tasks достаточно показать текст и дать возможность отредактировать. Для high-impact actions нужна более сильная проверка: отправка сообщения, звонок, удаление файла, изменение настройки, покупка, публикация, calendar invite, share location. Accessible confirmation не может зависеть только от sound. Пользователь должен видеть target, content, app, permission и result в доступной форме: текст, крупный preview, haptic status, focus order, captions или другой non-voice channel.

Самая опасная ошибка — принять translation confidence за action confidence. Модель может правильно перевести фразу, но агент может неверно выбрать приложение или contact. Или наоборот: перевод содержит ambiguity, но action router слишком уверен. Поэтому нужно разделять input confidence, intent confidence, capability routing и execution approval.

В FoneClaw мы применяем такую же логику к любому входу: typed, voice, current-screen context или attachment. Подробный технический слой AutoAttach, Suggest и Fallback описан отдельно в статье Маршрутизация возможностей ИИ-агента Android: AutoAttach, Suggest, Fallback и контроль FoneClaw. Для beyond-voice accessibility важно, что routing помогает выбрать путь, но не authorize execution.

Recovery должен быть равноправной частью UX. Если камера закрыта, сеть пропала, translation неуверенный, contact ambiguous или permission denied, агент должен предложить typed fallback, ручной выбор, сохранение draft, повторный ввод или остановку. У пользователя должна оставаться возможность продолжить без голоса.

FoneClaw через beyond-voice accessibility

Сначала граница: FoneClaw сейчас не заявляет sign-language recognition и не интегрирован с SL2T от Google DeepMind. Мы не распознаем жестовый язык, не переводим ASL-to-English и не сертифицируем продукт как sign-language accessibility tool. Эта статья использует текущий milestone как урок для phone-agent builders: доступность не начинается и не заканчивается voice input.

Что FoneClaw уже делает в этом направлении? Продукт поддерживает typed interaction, user-selected attachments и selected context routes там, где они доступны. Пользователь может формулировать задачу текстом, выбрать контекст, использовать current-screen context по собственному действию, увидеть task state, остановить выполнение и пройти permission recovery. Для многих людей typed route не запасной, а основной способ управлять phone agent.

Мы строим FoneClaw вокруг разделения input, capability routing и action authority. Модель может понять намерение из текста. Capability routing может предложить built-in tool, Skill, Workflow, Plugin или Fallback. Но matching не выполняет действие. Tool policy, approval, result state, stopping и recovery остаются отдельными controls. Это важно для accessibility: пользователь должен не только дать команду, но и безопасно проверить, что телефон собирается сделать.

Пример без sign recognition: пользователь вводит текстом «подготовь сообщение врачу, что я задерживаюсь на 15 минут, но не отправляй». FoneClaw может помочь сформулировать draft, открыть поддерживаемый route, показать текст, удержать задачу в видимом состоянии и остановиться до отправки. Если нет permission или target ambiguous, FoneClaw должен объяснить recovery. Это уже beyond-voice behavior: взаимодействие не зависит от речи и не требует слухового подтверждения.

Текущие user-facing возможности FoneClaw, включая 100+ built-in tools для поддерживаемых Android-действий, описаны на странице функций FoneClaw. Если вам нужен слой текущего экрана и overlay-поведения, отдельный материал Плавающий ИИ-ассистент Android и текущий экран: контекст, действия и контроль показывает, как user-triggered context помогает без скрытого захвата.

Что мы строим дальше как продуктовая команда: больше ясности вокруг input source, context source, approval reason и recovery path. Для accessible agents важно не обещать один волшебный ввод, а дать пользователю выбор: typed, selected context, visual confirmation, stop, fallback и audit trail. Архитектурные вопросы permission и tool confirmation мы раскрываем в статье Идентичность ИИ-агента: разрешения, аудит и подтверждение инструментов.

Аудит с участием глухих пользователей

Доступный ИИ нельзя проектировать только из офиса разработки. DeepMind описывает участие Deaf participants и advisory committee across concept, data, evaluation и impact assessment. Для sign-language technology это не декоративная стадия, а условие качества: язык, тело, камера, social context и privacy lived experience не видны из одного benchmark.

Практичный аудит начинается с language coverage. Какой sign language поддержан? ASL? Другой язык? Dialect? Как система сообщает, что язык не поддержан? Не обещает ли она universal sign-language AI? Затем проверяется signer diversity: возраст, кожа, одежда, handedness, one-handed signing, mobility, camera distance, lighting, background, phone angle, seated and standing use.

DeepMind прямо поднимал практические вопросы вроде left-handed и one-handed signing. Для телефона это критично: пользователь может держать устройство, находиться в транспорте, работать одной рукой, сидеть в плохом освещении или использовать стойку. Если модель хорошо работает только в демонстрационной позе, она плохо переносится в реальную жизнь.

Дальше идут privacy и latency. Видит ли пользователь, что камера активна? Понятно ли, что raw video discarded according to provider, но coordinates sent to server? Есть ли offline fallback? Как быстро появляется текст? Можно ли остановить capture? Как удалить или не сохранять историю, если feature это поддерживает?

Отдельно тестируется error repair. Система должна показывать translated text до отправки, давать легкое редактирование, не стыдить пользователя за поправки и не прятать uncertainty. Для phone-agent actions нужно проверять confirmation: target, app, permission, result, stop, rollback. Один Deaf tester не представляет все сообщество; нужен ongoing participatory process с разными пользователями и сценариями.

Как тестировать workflow без голоса

Перед тем как полагаться на beyond-voice phone workflow, выберите low-risk task. Не начинайте с отправки сообщения, звонка, покупки, удаления файла или изменения безопасности. Подойдет заметка, черновик, поиск, открытие настроек, проверка status или создание unsaved calendar draft.

1. Проверьте input. Если используется sign-to-text, прочитайте переведенный текст и исправьте ошибки до действия.
2. Проверьте target. Контакт, приложение, календарь, файл или setting должны быть видимы до execution.
3. Проверьте permission. Отказ permission должен вести к понятному recovery, а не к скрытому retry.
4. Проверьте confirmation. Подтверждение должно быть доступным без звука: visual, typed, haptic или другой выбранный channel.
5. Проверьте stop. Пользователь должен уметь остановить задачу до внешнего эффекта.
6. Проверьте fallback. Камера, сеть или recognition могут отказать; typed input и ручной route должны оставаться доступны.

Один успешный тест не доказывает универсальную надежность. Но такой reversible workflow показывает главное: accessibility input, phone-agent routing, approval и recovery работают как отдельные слои, а пользователь сохраняет контроль над действием.