Skip to main content
AI evaloverengineeringbitcoin

Когда Sol Max закопался в Bitcoin

Sol Max в попытке сделать «идеально научный» eval отказался от обычного генератора случайных чисел и дошел до идеи брать хеш будущего блока Bitcoin. Для бизнеса это важный сигнал: при AI implementation слишком жесткие требования легко раздувают архитектуру, задержки и стоимость без реальной пользы.

Технический контекст

Я такие истории люблю не за мемность, а за очень честный инженерный вывод. Просишь модель сделать «неуязвимый» eval, а она не просто крутит seed в коде, а уже тащит Bitcoin mainnet как источник «по-настоящему непредсказуемой» случайности. Вот тут и видно, как AI implementation может внезапно уехать из здравого смысла в культ абсолютной строгости.

Если отбросить шутки, техническая логика у этого есть. Хеш будущего блока Bitcoin действительно нельзя нормально предсказать заранее, и как источник внешней энтропии это работает. Но я бы на этом месте сразу нажал паузу: для оценки модели мне обычно нужна воспроизводимость, контролируемый seed и понятная статистика, а не десятиминутное ожидание блока и лишняя зависимость от чужой сети.

Меня здесь цепляет не Bitcoin, а сама траектория мышления модели. Ей дали цель «не доверять локальному рандому», и она добросовестно пошла искать более «чистый» источник случайности. Не оптимальный, не дешевый, не быстрый. Просто максимально защищенный от воображаемого изъяна.

И это очень показательно для современных агентных систем. Если в промпте или спецификации оставить дыру уровня «сделай максимально надежно», модель начнет строить AI architecture под крайний случай, а не под реальную задачу. Потом люди удивляются, почему простой eval внезапно требует сетевой доступ, внешние API и полдня на прогон.

Влияние на бизнес и автоматизацию

Для бизнеса вывод простой: опасны не только слабые требования, но и слишком героические. Когда я проектирую automation with AI, я всегда отделяю «статистически достаточно хорошо» от «криптографически безупречно». Эти два режима стоят совершенно разных денег.

Выиграют тут только редкие сценарии, где нужен внешний, публично проверяемый источник энтропии. Проигрывают почти все прикладные пайплайны: eval, A/B-прогоны, внутренние тесты агентов, batch-оценка качества. Там вы получаете задержку, сложность интеграции и хрупкость вместо пользы.

Я у клиентов вижу это постоянно: проблема не в модели, а в формулировке требований. В Nahornyi AI Lab мы как раз такие вещи и приземляем, чтобы AI automation не превращалась в дорогую инженерную фантазию. Если у вас система уже начинает «думать слишком фундаментально» там, где нужен просто рабочий результат, давайте разберем архитектуру и соберем AI solutions for business без лишнего культа совершенства.

Мы ранее разбирали, как prompt injection в саморефлексии Claude приводит к DoS и нарушению автоматизации. Это лишь один из примеров, когда модель выходит за рамки ожидаемого поведения, что перекликается с инцидентом, описанным в этой статье.

Поделиться статьёй