Главный баг Software 3.0

Представьте: вы пишете идеальный промпт, получаете блестящий код, а на следующий день тот же промпт выдает полную ерунду. Добро пожаловать в Software 3.0 - эру, где Андрей Карпатый (мой любимый вайб кодер) предсказал (вот его крутое выступление), что промпты станут новым «языком программирования». Но у этой революции есть фундаментальная проблема, с которой сталкивается каждый, кто пытался получить от модели два одинаковых ответа подряд

Главный парадокс Software 3.0 в том, что переход к простому языку привел к сложной проблеме - невозможности точно воспроизвести результат. Даже при temperature = 0 (режим, который должен быть максимально детерминированным) модели ведут себя непредсказуемо. Исследования показывают, что вариации в точности ответов от запуска к запуску могут достигать 15%. Откуда берется эта случайность?

➡️ Три уровня недетерминированности LLM
Проблема воспроизводимости - это не просто баг, который можно исправить. Она заложена в саму природу современных вычислений на нескольких уровнях

1. Аппаратный уровень
Когда вы запускаете модель на GPU, вы имеете дело с тысячами параллельных ядер. Из-за особенностей архитектуры и арифметики с плавающей запятой, результат операции (a + b) + c не всегда равен a + (b + c). Порядок выполнения этих микроопераций может меняться от запуска к запуску в зависимости от того, какое ядро закончило вычисления на наносекунду раньше

2. Программный уровень
Библиотеки вроде PyTorch и cuDNN, на которых работают все современные модели, содержат алгоритмы, которые по своей природе недетерминистичны. Например, некоторые операции свертки или пулинга специально сделаны такими для повышения скорости. Разработчики сознательно идут на компромисс, жертвуя воспроизводимостью ради производительности

3. Архитектурный уровень
Современные модели используют архитектуру Mixture-of-Experts (MoE). Представьте, что это команда из нескольких узкопрофильных специалистов (экспертов). Для обработки вашего запроса модель выбирает нескольких наиболее подходящих. Но из-за сложной внутренней маршрутизации, в следующий раз для точно такого же запроса может быть выбран немного другой состав «команды экспертов», что приведет к иному результату

А есть примеры из жизни?
Пример 1️⃣
Недавно показали игровой движок Hunyuan GameCraft от Tencent. Он способен в реальном времени генерировать игровые сцены, но разработчики столкнулись с ключевой дилеммой: либо мир стабилен, но плохо реагирует на действия игрока, либо он отзывчив, но постоянно «плывет» и теряет консистентность. Наглядный пример недетерминированности на практике

Пример 2️⃣
Концепт Gemini Computer от Google. Это операционная система, где каждый элемент интерфейса генерируется LLM на лету. Выглядит футуристично, но в их же демо отлично видно фундаментальную проблему: генерация изначально не подразумевает строгой воспроизводимости. Кнопка «Сохранить», которая была слева, после следующего клика может оказаться справа или вообще изменить название

Пример 3️⃣
Проблему накопления ошибок в LLM отлично иллюстрирует аналогия с квантовыми компьютерами. Представьте, что точность одной квантовой операции - 99%. Звучит неплохо. Но если для вычисления нужно провести 1000 таких операций, общая надежность падает до 0.99^1000, что практически равно нулю. С LLM происходит то же самое: при генерации длинного текста или кода крошечные отклонения накапливаются, и финальный результат «уплывает» далеко от первоначального замысла

➡️ GitLab для эпохи Software 3.0
Так что же делать в этом дивном новом мире?

Лично мне видится решение в виде надстройки для привычных систем вроде GitLab, которая будет версионировать не одну, а сразу три плоскости нашего проекта:

🔵Код - финальный артефакт, как и сейчас
🔵Промпт - инструкция, которая сгенерировала этот код
🔵Модель - конкретная версия LLM (например, Gemini 2.5 Flash Preview 04-17)

Это позволит отслеживать всю цепочку создания продукта и откатываться к стабильной связке «промпт-модель»

Эпоха Software 3.0 требует новых инструментов, и, похоже, нам предстоит их создать 💪