Как работает Ptichi: технология тренировки речи, которую мы строим

Человек выбирает конкретную задачу, говорит, слушает первую попытку, меняет одну вещь, говорит снова и сравнивает. После этого тот же навык нужно перенести на другие слова, а позже — проверить ещё раз.

В самом коротком виде метод выглядит так:

задача → попытка A → прослушивание → один приём → попытка B → новые слова → повторная проверка

Снаружи это должно ощущаться просто. Внутри мы строим несколько технических слоёв, чтобы эта простота не была иллюзией.

Важно разделять текущее состояние продукта. На сайте уже доступны бесплатные упражнения и текстовые способы практики. Настольное приложение для macOS на Apple Silicon и Windows 11 x64 находится в разработке; публичных установщиков пока нет. Автоматическое сопровождение текста и часть измерений остаются планируемыми или экспериментальными направлениями, а не выпущенными функциями.

Почему нам недостаточно «проанализировать голос»

Речь слишком легко превратить в дашборд.

Можно измерить длительность пауз, скорость, энергию, изменения высоты основного тона, количество слов и десятки других признаков. Проблема начинается после измерения: что человеку делать дальше?

Даже точное число может не отвечать на полезный вопрос.

Если приложение сообщает «темп 153 слова в минуту», это ещё не говорит, был ли темп подходящим для этого объяснения. Если график показывает изменение интонации, из него автоматически не следует, что слушатель правильно понял контраст. Если модель уверенно выдаёт «confidence 82», это не превращает уверенность в измеряемое физическое свойство голоса.

Поэтому архитектура Ptichi начинается не с метрики, а с тренировочной задачи.

Например:

• сохранить важное условие в конце фразы;
• сделать границу между двумя мыслями слышимой;
• не растворить главное слово внутри длинного ответа;
• использовать паузу для планирования ответа вместо цепочки заполнителей;
• закончить утверждение так, чтобы оно не звучало как случайный вопрос;
• объяснить техническую мысль так, чтобы слушатель мог восстановить её структуру.

Метрика полезна только тогда, когда помогает проверить такую ограниченную задачу.

Основной механизм: Listening Loop

Рабочее название центрального цикла — Listening Loop.

Вместо «запишите речь и получите отчёт» цикл должен вести человека через несколько последовательных состояний.

1. Выбрать, что тренировать

Начинать с пустой кнопки Record — плохой продуктовый сценарий. Если человек пришёл тренировать интервью, объяснение сложной темы или паузы, приложение должно сразу дать содержательную задачу.

Поэтому мы строим Ptichi вокруг программ и библиотеки практики.

Программа — не просто папка с упражнениями. Она задаёт последовательность: что тренируем сейчас, зачем это нужно слушателю, что считать изменением и какой следующий шаг имеет смысл.

2. Получить подготовленный материал

Мы называем такой материал practice score — тренировочная партитура речи.

Это не сценарий с «единственно правильным» исполнением. Текст может показать границу мысли, смысловой акцент, условие, которое нельзя потерять, или место, где полезно проверить окончание фразы.

Например:

Мы можем начать в пятницу / но только после проверки безопасности.

Знак границы не означает «сделать паузу ровно 430 миллисекунд». Он показывает тренировочную задачу: слышно ли, что вторая часть ограничивает первую?

Главное преимущество подготовленного материала — повторяемость. Мы знаем, какой текст использовался, какая версия упражнения применялась и какой навык проверялся. Это намного надёжнее, чем генерировать новый совет во время каждой попытки и потом пытаться понять, что именно изменилось.

3. Проверить запись до анализа

Факт, что аудиопоток открылся, ещё не означает, что запись пригодна.

Микрофон может быть выбран, но сигнал окажется слишком слабым. USB-устройство может исчезнуть во время попытки. Операционная система или драйвер могут применять обработку. На macOS может измениться режим микрофона. На Windows конкретный путь захвата может вести себя иначе после упаковки приложения.

Поэтому в Ptichi появляется отдельный слой — Microphone Passport.

Его задача не выставить микрофону рейтинг. Он должен ответить на более скучные, но важные вопросы:

• есть ли сейчас пригодный речевой сигнал;
• какое устройство использовалось;
• не поменялись ли важные параметры между попытками;
• можно ли доверять конкретному измерению при таком пути захвата;
• нужно ли остановить анализ и попросить повторить запись.

Если контекст записи изменился, система не должна притворяться, что Take A и Take B полностью сопоставимы.

Попытка A сначала должна стать слышимой человеку

Мы намеренно не хотим превращать AI в первый голос в комнате.

После Take A пользователь должен иметь возможность сначала послушать себя и понять задачу. Это важная часть продукта: человек учится замечать признаки самостоятельно, а не только ждать оценки модели.

Дальше автоматическая система может помочь, но её ответ должен быть ограниченным.

Не:

«Вот 17 вещей, которые нужно исправить».

А:

«В этой попытке проверь окончание ключевого утверждения. Сделай ещё один дубль, сохранив остальное примерно тем же».

Рабочая сущность для такого ответа — Intervention Card: одна коррекция или один вопрос для прослушивания, причина, граница применимости и задача на перенос.

Почему одна коррекция лучше двадцати

Речь многомерна. Во время одной фразы одновременно меняются дыхание, артикуляция, темп, паузы, громкость, высота, ритм, структура мысли, выбор слов и эмоциональная подача.

Если менять всё одновременно, сравнение разваливается.

Ptichi пытается удерживать маленький эксперимент:

Что произойдёт, если изменить только X?

Это не означает, что человеческая речь действительно состоит из независимых ползунков. Не состоит. Но для тренировки полезно уменьшать количество меняющихся переменных настолько, насколько это разумно.

Поэтому Take B нужен не как шанс «сказать красиво», а как проверка конкретного вмешательства.

Take B ещё не доказывает обучение

Это важное ограничение всей системы.

Человек может сделать идеальную вторую попытку просто потому, что запомнил подсказку или почти скопировал предыдущую фразу.

Поэтому после A/B нужен transfer — тот же навык на новых словах.

Если тренируем смысловую границу, меняем предложение. Если отрабатываем ответ на интервью, меняем вопрос или содержание примера. Если работаем с окончанием утверждения, переносим приём в другую фразу.

И только потом имеет смысл спрашивать: получилось ли не воспроизвести упражнение, а использовать принцип?

Позже появляется ещё один слой: retest. Навык проверяется снова после интервала, а не только внутри одной удачной сессии.

Прогресс — это не одна линия на графике

Одна из самых опасных идей для тренировочного продукта — свести прогресс к одному числу.

В Ptichi мы хотим разделять как минимум четыре состояния:

1. Completion — человек действительно прошёл упражнение.
2. Controlled change — нужное изменение появилось в повторной попытке.
3. Transfer — оно сохранилось на другом тексте или в новой формулировке.
4. Retention — навык проявился при более поздней проверке.

Это разные утверждения.

Серия выполненных уроков ещё не означает, что речь изменилась. Красивый Take B ещё не означает transfer. Успешный transfer в одной сессии ещё не доказывает retention.

Поэтому Learning State в Ptichi должен хранить не «ваш голос стал 87/100», а историю того, что тренировалось, что получилось воспроизвести, что пока неизвестно и что стоит попробовать дальше.

Автоматический анализ будет модульным, а не всемогущим

Мы не хотим одной модели, которая якобы «понимает речь целиком».

У разных проверок разные требования к доверию.

Для одной задачи может быть достаточно знать тайминг границы. Для другой нужен ASR, чтобы понять, где человек находится в тексте. Для третьей полезно сравнить энергетический контраст. Для четвёртой автоматический вывод вообще может быть недостаточно надёжным — тогда лучше оставить человеку запись и вопрос для самопроверки.

Так появляется принцип capability-specific trust: доверять не «анализатору Ptichi вообще», а конкретной способности в конкретных условиях.

Если система не уверена, правильное поведение — не придумать уверенный совет, а сказать, что автоматическая проверка здесь ограничена.

Real-time нужен, но он не должен мешать говорить

Мы исследуем real-time слой, но его роль тоже намеренно ограничена.

Во время попытки интерфейс прежде всего должен:

• надёжно сохранить запись;
• показать состояние захвата;
• при необходимости следовать за подготовленным текстом;
• пережить повтор слова, пропуск строки или возврат назад;
• перестать угадывать, если потерял позицию.

Мы не хотим, чтобы пользователь одновременно говорил, смотрел на бегущие оценки, исправлял пять индикаторов и думал о содержании ответа.

Поэтому live-помощь должна быть тихой. Основная тренерская обратная связь появляется после попытки.

Почему локальная архитектура для нас важна

Речь часто содержит рабочие детали, имена, черновые мысли, ответы для интервью и вещи, которые человек не собирался публиковать.

Настольный Ptichi проектируется так, чтобы запись и основной анализ по умолчанию оставались на устройстве.

Это влияет не только на приватность. Local-first архитектура меняет сам продукт:

• можно быстрее переслушивать собственные попытки;
• локальная история становится нормальной частью тренировки;
• приложение не обязано превращать каждую запись в облачный объект;
• диагностические логи можно строить metadata-first, не прикладывая автоматически речь или транскрипт;
• некоторые модели и измерения можно выбирать с учётом возможностей конкретного компьютера.

Текущий Ptichi.site при этом вообще не записывает аудио и не запрашивает доступ к микрофону. До выпуска desktop-приложения упражнения с записью выполняются через привычный диктофон пользователя.

Надёжность — отдельная часть технологии

Для speech-продукта легко показать красивый интерфейс раньше, чем система научится отличать собственную ошибку от ошибки пользователя.

Мы поэтому разделяем несколько вопросов:

Работает ли программа технически?

Достоверно ли конкретное измерение на проверенном аудио?

Стабильно ли всё работает на реальном целевом компьютере и с реальным устройством?

Помогает ли такой тренировочный протокол человеку?

Это четыре разных уровня доказательства.

Успешный unit test не доказывает качество измерения. Хороший результат алгоритма на подготовленном файле не доказывает работу USB-микрофона после suspend/resume. Рабочая запись не доказывает, что упражнение улучшает навык.

Поэтому в проекте есть отдельные reliability gates и лабораторные сценарии для проблем захвата. Некоторые вещи можно проверить детерминированно. Другие требуют физического Windows/macOS железа и упакованных сборок.

Если доказательства пока нет, продукт должен говорить «не проверено», а не повышать уверенность формулировки.

Что человек в итоге должен видеть

Внутри система может быть сложной. Пользователь не должен управлять этой сложностью.

Первый слой Ptichi мы сводим к понятной модели:

Home — что тренировать дальше.

Train — программы, библиотека и текущая практика.

Recordings — свои попытки, повторное прослушивание и сравнение.

Progress — что изменилось, что пока неизвестно и какой следующий навык имеет смысл.

Settings — настройка, а не отдельный мир продукта.

Глубокие метрики, provenance, ограничения измерений и технические детали должны быть доступны, когда они нужны, но не становиться первым экраном.

Проект может быть сложным внутри и оставаться простым снаружи.

Что доступно сейчас, а что мы строим

Доступно на Ptichi.site сейчас

• бесплатные упражнения и руководства;
• текстовая практика без записи на сайте;
• материалы по самостоятельному прослушиванию;
• англоязычный текстовый помощник для подготовки сообщения;
• опубликованные тренировочные тексты и объяснения техник.

В разработке

• desktop-приложение для macOS Apple Silicon и Windows 11 x64;
• локальная запись и воспроизведение;
• сравнение Take A / Take B;
• программы и библиотека практики;
• история записей и тренировочных состояний;
• Microphone Passport и более явная проверка готовности записи.

Планируемые и экспериментальные направления

• надёжное следование за подготовленным текстом во время речи;
• ограниченные автоматические наблюдения по конкретным навыкам;
• перенос на новые формулировки и поздние retest-сессии как часть продукта;
• более богатая система авторинга тренировочных материалов;
• более длинная история изменения конкретных речевых навыков.

Это направления разработки, а не обещание, что функции уже доступны.

Где здесь AI

AI для нас — компонент, а не продуктовая идея.

Он может помочь распознать речь, сопоставить попытку с текстом, найти участок записи, подготовить черновую разметку или дать ограниченную семантическую подсказку.

Но продуктовый вопрос остаётся прежним:

Что человек должен сделать в следующей попытке — и как мы поймём, что именно это изменилось?

Если AI не помогает ответить на этот вопрос надёжно, его присутствие не делает тренировку лучше.

Поэтому сила Ptichi должна возникать не из названия конкретной модели, а из связки:

программа + подготовленный материал + надёжная запись + ограниченная обратная связь + сравнение + transfer + история

Модели будут меняться. Тренировочный протокол и данные о собственном прогрессе пользователя должны переживать смену моделей.

Каким проектом мы хотим сделать Ptichi

В конечном счёте Ptichi — это не «программа для записи голоса».

Мы строим рабочее место для deliberate practice речи.

Человек может прийти с очень разными задачами: интервью, assessment, презентация, объяснение архитектуры, история из опыта, сложный вопрос, английская речь, микрофонная запись или просто желание звучать яснее.

Вместо абстрактного «улучшайте голос» система должна превратить задачу в серию маленьких проверяемых тренировок.

И хороший финал такой системы немного парадоксален: со временем она должна быть нужна меньше.

Сначала Ptichi помогает заметить изменение. Потом помогает повторить его. Затем усложняет контекст, убирает подсказки и проверяет перенос. Цель — не научить человека хорошо пользоваться Ptichi. Цель — чтобы нужный речевой навык остался, когда Ptichi уже не открыт.

Попробуйте принцип до выхода приложения

Для самого базового цикла Ptichi пока не нужен специальный софт.

Возьмите короткий реальный текст и обычный диктофон.

1. Запишите попытку A.
2. Выберите только одну вещь: паузу, окончание утверждения, смысловой акцент или границу мысли.
3. Запишите попытку B, стараясь не исправлять всё остальное одновременно.
4. Сравните только выбранный признак.
5. Скажите новую фразу с тем же приёмом.

Если на пятом шаге изменение исчезло, это полезная информация. Вы не «провалили тест». Вы нашли границу навыка.

Именно вокруг такой границы мы и строим Ptichi.