ИИ умеет очень убедительно объяснять, как решить техническую задачу.

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

Из этого очень легко сделать лишний вывод:

если ИИ настолько хорошо понимает путь решения, значит сама задача практически решаема и её сложность примерно понятна.

Наше недавнее исследование показало, что это опасная подмена.

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

Всё началось с достаточно простой идеи

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

Основная работа ведётся в задаче «Исследовать параметрический синтез русских звуков и переходов между ними».

Идея выглядела вполне логичной.

Браузер через AudioContext способен воспроизводить звук. Если передать ему запись, он совершенно нормально воспроизводит человеческую речь.

Но запись — это большой массив чисел.

Примерно секунда обычного аудио может занимать сотни килобайт в Float32Array. Даже после довольно агрессивного сжатия вроде μ-law @ 8 kHz всё равно остаются тысячи значений на секунду.

При этом человеческий голос физически создаётся системой с гораздо меньшим количеством существенных переменных.

Отсюда возникла гипотеза:

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

Мы начали это делать.

Первый существенный результат описан в worklog первого прототипа.

Появилась единая модель VoiceScenario.

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

Удалось получить что-то похожее на А, С, Ш, Т, затем собрать более сложные фрагменты и даже экспериментировать с Привет.

То есть идея не оказалась фантазией.

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

И именно в этот момент возникает опасная ловушка.

Рабочий прототип ещё ничего не говорит о расстоянии до продукта

Первая LLM, с которой обсуждалась задача, оценила её очень оптимистично.

Концептуально всё действительно выглядело понятно:

генератор → параметры → изменение во времени → нужный звук

Следующая LLM продолжила разработку примерно в той же рамке.

Более того, прототип начал работать.

Это очень важный момент.

Когда код вообще не запускается, сомневаться легко.

Гораздо сложнее сомневаться, когда что-то уже получается.

Есть звук.

Есть узнаваемое А.

Есть переходы.

Есть сценарии.

ИИ объясняет следующий шаг.

Возникает естественное ощущение:

направление подтверждено, теперь надо просто докрутить качество.

Но слово «докрутить» может скрывать почти всю инженерную сложность проекта.

Один ИИ наконец сказал неприятную вещь

При очередном исследовании Gemini сформулировал гораздо более осторожную оценку:

прямой процедурный синтез человеческой речи через низкоуровневые возможности Web Audio — сложная инженерная задача.

Не невозможная.

И даже не обязательно неподходящая нам.

Просто сложная.

Это изменило сам характер исследования.

Вместо продолжения бесконечной настройки параметров появилась отдельная задача — найти существующие технические реализации нужного нам класса.

Мы хотели увидеть конкретный пример:

реальная запись

→ анализ

→ компактное структурное описание

→ процедурный генератор

→ качественный узнаваемый звук

Результаты поиска подробно записаны в основном worklog исследования существующих реализаций и в последующем уточнении результатов.

И вот тут первоначальная картина начала рассыпаться.

Все части существуют, а готового решения всё равно нет

Мы нашли формантный синтез.

Нашли модели голосового тракта.

Нашли Pink Trombone.

Нашли LPC, source-filter analysis, vocoder-подходы, analysis-by-synthesis.

Есть нейросетевой TTS фантастического качества.

То есть почти каждый элемент первоначальной схемы где-то существует.

Но нужной системы целиком мы не увидели.

Особенно важной оказалась обратная часть:

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

Именно здесь обнаружилась настоящая инженерная проблема.

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

Но как найти эти параметры?

Звук изменяется во времени.

Значит, требуется найти не одну точку, а траекторию.

Разные состояния генератора могут давать похожее восприятие.

Математическая ошибка между waveform плохо совпадает с человеческим ощущением похожести.

А главное — выбранный генератор может вообще не уметь воспроизвести нужный звук.

Тогда никакая оптимизация правильный сценарий не найдёт.

Получается неприятная зависимость:

простой генератор → легче искать параметры → хуже звук

сложный генератор → потенциально лучше звук → резко сложнее поиск

В первоначальной формулировке вся эта область помещалась почти в одну строку:

подобрать параметры под нужный звук.

LLM умеет очень красиво скрывать сложность внутри глаголов

Это более общая проблема.

Фразы вроде:

• «определим параметры»;
• «оптимизируем»;
• «адаптируем модель»;
• «соединим компоненты»;
• «добавим автоматическую классификацию»;
• «настроим под реальные данные»;

звучат как этапы плана.

Но каждый такой этап потенциально может оказаться самостоятельной исследовательской программой.

LLM особенно убедительна именно здесь.

Она знает необходимые термины.

Знает существующие технологии.

Может написать значительную часть кода.

Может объяснить математическую идею.

Поэтому возникает эффект ложной технической валидации:

если модель способна настолько детально объяснить решение, значит она понимает его практическую сложность.

Это совсем не одно и то же.

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

Источник: https://link.springer.com/article/10.1007/s44163-026-02240-w

В разработке эта проблема особенно неприятна: исследование более чем 24 миллионов реальных взаимодействий программистов с AI-кодом показало, что даже специально рассчитанные confidence signals непросто сделать надёжным показателем того, можно ли доверять результату модели.

Источник: https://arxiv.org/abs/2510.22614

То есть сама система пока не обязательно хорошо знает, насколько ей следует доверять собственному прогнозу.

Есть ещё один усилитель — ИИ склонен поддерживать направление пользователя

В 2025 году OpenAI пришлось откатить одно из обновлений GPT‑4o из-за чрезмерной соглашательности модели.

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

Источник: https://openai.com/index/sycophancy-in-gpt-4o/

Это особенно важно для предпринимательства.

Основатель редко приходит к ИИ абсолютно нейтральным.

Обычно ситуация выглядит так:

У меня есть идея. Вот почему она должна работать. Помоги её реализовать.

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

Именно поэтому фраза:

«Да, это можно сделать»

может оказаться намного опаснее явной галлюцинации.

В нашем случае стоимость ошибки очень маленькая

И здесь наш проект становится особенно интересным.

Мы пока не знаем, ошибся ли первоначальный оптимизм вообще.

Возможно, задача действительно решаема.

Более того, результаты остаются достаточно обнадёживающими.

В следующем worklog исследования мы зафиксировали несколько интересных эффектов.

Сценарии действительно остаются компактными.

При изменении параметров мы продолжаем получать в основном voice-like звуки.

Во время поиска Ха неожиданно появился вариант, который воспринимался как Ва.

Это само по себе оказалось полезным результатом.

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

У нас появился и рабочий человеко-машинный цикл поиска.

Человек записывает реальный пример.

ИИ получает аналитический лог этой записи и лог синтетического звука.

Сравнивает их.

Предлагает изменения сценария.

Человек слушает результат и решает, стало ли лучше.

Мы продолжаем проверять идею.

Но цена проверки очень небольшая.

И причина не в простоте задачи.

Наш главный защитный механизм — чрезвычайно короткая организационная цепочка

На сайте Solopreneur.prof эта идея описана как один из основных эффектов AI-усиленного солопренерства:

идея → MVP → реальность → вывод

Без длинной логистической цепочки между решением и обратной связью.

В нашем случае эта модель видна почти в чистом виде.

Один человек является:

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

Если сегодня выясняется, что гипотеза неверна, не нужно проводить совещание.

Не нужно объяснять менеджеру, почему изменилась архитектура.

Не нужно согласовывать дополнительный бюджет.

Не нужно защищать решение перед собственником.

Не нужно переписывать месячный roadmap.

Просто меняется следующий эксперимент.

Поэтому двухдневная ошибка остаётся примерно двухдневной ошибкой.

В классической компании та же техническая ошибка превращается в организационную

Теперь перенесём ровно тот же эксперимент в обычную структуру.

Есть собственник или генеральный директор.

Есть продуктовый менеджер.

Есть технический руководитель.

Есть разработчики.

Возможно, есть подрядчики.

Допустим, руководство получает от ИИ уверенную оценку:

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

Дальше появляется постановка.

Менеджер превращает её в план.

План превращается в задачи.

Задачи распределяются между разработчиками.

Люди начинают получать зарплату за их выполнение.

Через неделю инженер говорит:

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

Что происходит дальше?

Совсем не обязательно руководство скажет:

Отлично, значит первоначальная гипотеза оказалась слабой.

Может произойти другое:

ИИ же объяснил, как это делается.

Почему вы до сих пор не сделали?

Возможно, проблема в компетенции команды.

Тогда ошибка технической оценки начинает жить собственной организационной жизнью.

Авторитет превращает гипотезу в требование

Это уже не проблема самого ИИ.

ИИ только дал первоначальный оптимистичный прогноз.

Дальше начинает работать структура власти.

Если человек, принимающий решение, не обладает достаточной технической экспертизой, он не обязательно способен отличить:

команда не хочет решать задачу

от

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

И тут возникает очень неприятный сценарий.

Первая команда говорит:

это, скорее всего, намного сложнее.

Руководитель решает:

команда недостаточно сильная.

Нанимается следующая.

Ей передаётся уже не гипотеза:

попробуйте выяснить, возможно ли это.

А фактически утверждение:

это возможно, предыдущие просто не справились.

Новая команда начинает с ещё худшей позиции.

Потому что теперь техническое сомнение воспринимается почти как сопротивление поставленной задаче.

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

Организация способна многократно увеличить стоимость одной ошибки LLM

Представим наш эксперимент в такой компании.

Два дня непосредственного исследования одного человека легко превращаются в:

• постановку задачи;
• анализ;
• технические обсуждения;
• разработку;
• code review;
• тестирование;
• встречи;
• промежуточные отчёты;
• пересогласование;
• поиск внешней экспертизы;
• возможно, смену исполнителей.

Календарно это уже может быть не два дня, а несколько недель.

А экономически — зарплата сразу нескольких участников процесса плюс стоимость управления ими.

Техническая ошибка осталась той же самой.

Изменилась только система, через которую она прошла.

В этом смысле риск можно представить почти как множитель:

стоимость ошибочной гипотезы × организационная инерция

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

Именно здесь оптимизм ИИ превращается в бизнес-риск

Важно правильно провести границу.

Проблема не в самом оптимизме.

Наш пример даже показывает, что оптимистичная гипотеза может привести к полезному исследованию.

Проблема начинается тогда, когда:

непроверенный технический прогноз ИИ получает организационный статус установленного факта.

После этого под него начинают выделять ресурсы.

Его включают в roadmap.

Под него рассчитывают бюджет.

Под него обещают сроки.

Нанимают людей.

В некоторых случаях берут кредит или инвестиции.

И каждая новая инвестиция создаёт психологическое и организационное давление продолжать.

Теперь признать:

исходная техническая гипотеза могла быть неверной

становится всё дороже.

Поэтому проверять надо не идею целиком

В нашем исследовании постепенно появился более здоровый подход.

Не спрашивать:

получится ли сделать хороший процедурный синтез речи?

Вопрос слишком большой.

Вместо этого выделять конкретные неизвестные.

Например:

способен ли наш генератор вообще покрыть достаточную часть человеческой речи?

Для этого и проводилось исследование существующих решений.

Следующий вопрос:

можно ли автоматически восстановить известный сценарий из звука, который этот же сценарий породил?

Для этого заведена отдельная задача «Исследовать обратный дешифратор: звук → VoiceScenario».

Здесь уже есть хороший экспериментальный критерий.

Берём известный сценарий S.

Генерируем звук:

S → G(S) = X

Затем пытаемся сделать обратное:

X → D(X) = S'

И сравниваем S' с исходным S.

Если дешифратор не способен восстановить собственные синтетические данные, нет смысла делать большие заявления о дешифровке человеческой речи.

Если способен — появляется более серьёзное основание двигаться дальше.

Параллельно заведена задача визуального редактора VoiceScenario, чтобы уменьшить стоимость каждой ручной итерации.

То есть вместо большого решения:

построить качественный синтезатор речи

мы постепенно строим систему маленьких проверяемых гипотез.

Положительный ответ ИИ должен означать начало проверки, а не конец

Отсюда получается довольно практическое правило для бизнеса.

Если ИИ говорит:

Да, это реализуемо.

следующий вопрос должен быть не:

Сколько разработчиков нанимать?

А:

Какое утверждение здесь самое рискованное и каким самым дешёвым экспериментом его можно проверить?

Это совершенно другой порядок действий.

Сначала:

гипотеза → минимальная проверка → результат

И только потом:

бюджет → команда → обязательства → масштабирование

Особенно это важно там, где LLM одновременно является:

• источником технической оценки;
• архитектором;
• помощником программиста;
• генератором бизнес-плана.

Иначе одно первоначальное предположение модели начинает само подтверждать себя на следующих этапах.

Сначала ИИ говорит, что технология реализуема.

Потом на основании этого пишет архитектуру.

На основании архитектуры оценивает сроки.

По срокам предлагает команду.

По команде считает бюджет.

Формально мы получили пять разных ответов.

Но все они стоят на одной и той же непроверенной предпосылке.

Бизнесу нужен не менее умный ИИ, а более дешёвый способ ошибаться

Наш эксперимент пока не доказал, что первоначальный оптимизм был неправильным.

Возможно, мы действительно найдём достаточно компактное представление качественной человеческой речи.

Возможно, обратный дешифратор заработает.

Возможно, текущую архитектуру придётся сильно изменить.

Мы пока этого не знаем.

Но мы уже знаем другое.

Плохой сценарий для нас дешёвый.

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

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

Поэтому главный вопрос при использовании ИИ в новых проектах, вероятно, должен звучать не так:

Насколько уверенно ИИ говорит, что идея реализуема?

А так:

Сколько нам будет стоить выяснить, что ИИ ошибся?

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