На демо пилот отрабатывает безупречно, в проде агент начинает делать странные вещи, команда идёт искать модель посильнее. Через месяц с новой моделью повторяется то же самое, только дороже.
Соблазн объяснить это качеством модели велик: такое объяснение даёт понятный следующий шаг. А в августе 2026 года вышел бенчмарк, который измерил совсем другой фактор.
Эксперимент, который измерил цену незаписанного правила
DiG-bench (Discovery in Games) опубликовали 12 августа 2026 года. Работу вела исследовательская группа Thinking About Thinking в сотрудничестве с Оксфордом, Принстоном, MIT, Inria и KAUST; среди соавторов — Юрген Шмидхубер, Джошуа Тененбаум, Томас Гриффитс и Три Дао.
Устроен он так: 70 текстовых игр, у каждой свои правила преобразований. Ни правила, ни условие победы игроку не известны: единственный способ их узнать — взаимодействие, то есть сделать ход, посмотреть, что изменилось, и поправить гипотезу. Игры разложены по семи уровням сложности, 21 игру авторы открыли публично, а 49 оставили закрытыми для честных замеров. Отдельно отмечено, что этих игр больше нигде в интернете нет, так что модель не могла видеть их при обучении — вопрос загрязнения данных здесь просто не возникает.
Авторы провели прямую абляцию: взяли Gemini 3.1 Pro и дали ей те же 70 игр, но на этот раз с текстом правил на руках.
Giving Gemini access to the ground-truth rules of the game, specified in concise natural language, raises the win rate from 18/70 to 69/70 games.
— DiG-bench: Discovery in Games, arXiv:2608.12593
Разницей между этими числами был короткий текст, которого в первом случае просто не существовало. Вывод авторы формулируют без смягчений: главная сложность их бенчмарка — именно выяснить правила.
Что именно давали модели — и чего в том описании не было
Описание, которое подняло результат до 99%, авторы характеризуют очень точно: оно кратко излагало динамику игры и условие победы, но не содержало ничего, что относится к политике поведения, — ни стратегий, ни тактик, ни последовательностей ходов.
These rules summarized the dynamics of the game and the win condition; but they excluded any policy-related information like strategies, tactics or move sequences.
— DiG-bench: Discovery in Games, arXiv:2608.12593
Модели не объясняли, как играть. Ей объясняли, во что она играет и что здесь считается выигрышем.
Компания, когда ей говорят «опишите процесс», обычно пишет ровно ту часть, которую из эксперимента убрали. Получается инструкция: сначала позвони, потом заведи сделку, дальше отправь КП, через три дня напомни. Это последовательность ходов. А механика — какие вообще бывают объекты, в каких состояниях они могут находиться, какие переходы разрешены, а какие нет — остаётся непроговорённой: внутри команды она выглядит очевидностью, о которой неловко говорить вслух.
Механика процесса — это ответы на вопросы, которые на встречах не задают:
- какие бывают сущности (заявка, клиент, сделка, возврат, рекламация) и по какому признаку одна отличается от другой
- в каких состояниях бывает каждая из них и какие переходы между состояниями разрешены
- чего нельзя делать никогда, каким бы разумным это ни выглядело в конкретном случае
- какие есть исключения и по какому признаку их распознают — не «иногда бывает иначе», а «если клиент из списка ключевых, правило другое»
- откуда берётся информация, которой нет в системе, и кто вправе её подтвердить
Условие успеха — отдельный блок, и его не пишут почти никогда:
- по какому наблюдаемому результату видно, что шаг выполнен правильно
- кто или что это проверяет и в какой срок
- чем «сделано плохо» отличается от «сделано неправильно»: это разные события с разной ценой
Разница не косметическая. Инструкция описывает один маршрут и молчит обо всём, что за его пределами, поэтому агент, сошедший с маршрута, остаётся без ориентиров. Описание механики, наоборот, задаёт границы поля: внутри них агент может выбрать собственный путь, а выйти за них не может по определению.
Инструмент получше этого не компенсирует
Естественная реакция на проваленный пилот — поискать обвязку посильнее: другой фреймворк, платформу с памятью, агента с планировщиком. Авторы бенчмарка проверили и эту гипотезу.
Они взяли Prime Agent — Opus 5 внутри продукта Prime Agent, — который незадолго до этого показал 95,5% на публичных играх ARC-AGI-3, и прогнали его на двух самых тяжёлых уровнях DiG-bench. Прироста по сравнению с базовой обвязкой с той же Opus 5 не было. Общий вывод сформулирован осторожно, но однозначно: существующие обвязки дают ограниченный прирост именно в способности к открытию.
Обобщать этот результат не стоит: кое-что агент всё-таки открывает сам. Без правил Gemini всё равно взяла 18 игр, а сильнейшая модель набора, Opus 5, — 50 из 70. Если для каждой игры считать лучшую из всех проверенных моделей, вместе они закрывают 57 из 70, но на двух верхних уровнях — только 9 из 20. То есть неявные правила открываются, только ненадёжно, и срывы приходятся именно на сложные случаи.
Для внедрения отсюда следует вполне практическая вещь. Там, где правила не записаны, вы платите не за лицензию, а разбросом результатов: агент отработает десять заявок как положено, а на одиннадцатой сделает то, чего никто не ждал. И выяснится, что правило, которое он нарушил, действительно нигде не было зафиксировано, — а значит, формально он его и не нарушал.
Где аналогия заканчивается
Бенчмарк измеряет открытие правил через активное экспериментирование в текстовых играх. У игрока там есть песочница: неудачный ход ничего не стоит, попыток можно сделать сотни. Авторы намеренно не оценивают эффективность шагов, чтобы не наказывать за исследование.
Бизнес-процесс устроен иначе. Эксперимент агента здесь — это реальный звонок реальному клиенту, реальная скидка и реальный счёт. Песочницы нет, а цена неудачной гипотезы не нулевая.
Поэтому переносить цифры буквально нельзя: 26% и 99% — результаты текстовых игр, а не показатели автоматизации отдела продаж. Аналогия работает в одну сторону и именно как аналогия: если модель с неограниченным числом бесплатных попыток самостоятельно выиграла 18 игр из 70, то в среде, где каждая попытка стоит денег и отношений с клиентом, оснований рассчитывать на самостоятельное открытие ещё меньше.
Как вытащить механику из головы в текст
Вопрос «расскажи, как ты это делаешь» даёт инструкцию, то есть ту самую последовательность ходов. Механика так не вытаскивается вообще: человек, который выполняет процесс десять лет, собственных правил не видит — для него это не правила, а то, как устроен мир.
Работает другой тип вопросов — о границах и об исключениях:
- «Что будет, если сделать наоборот?» — ответ «ну так никто не делает» почти всегда скрывает непроговорённое правило
- «Когда ты в последний раз отступил от инструкции и почему?» — здесь появляется и исключение, и признак, по которому его распознали
- «Какую ошибку новичок делает в первую неделю?» — это запрещённый переход, которого нет ни в одном документе
- «Как ты понимаешь, что сделано хорошо, ещё до того, как придёт результат?» — критерий успеха, который обычно существует только как ощущение
- «Что ты проверяешь перед тем, как нажать кнопку?» — скрытая предпосылка, без которой шаг не имеет смысла
Документ, собранный после такого разговора, состоит из трёх частей: перечень сущностей и их состояний, перечень запрещённых переходов с причинами, критерий успеха с описанием того, кто и как его проверяет. Стратегии, приёмы и советы «как лучше» сюда не входят — их пишут отдельно и для людей.
Проверить полноту описания можно простым способом: дайте его человеку, который процесса не знает, и попросите назвать ситуацию, в которой документ не подсказывает, что делать. Каждая такая ситуация — ровно то место, где агент начнёт угадывать.
Куда на самом деле уходит бюджет внедрения
Смета пилота обычно состоит из интеграций, промптов, тестирования и подписки на модель. Работы по извлечению неявных правил в ней нет — её либо пропускают со словами «у нас всё описано», либо обнаруживают после запуска, когда она уже обходится в остановленный проект.
Объём этой работы измеряется днями или неделями в зависимости от того, сколько исключений накопил процесс, и заложить её в план честнее, чем потом объяснять, почему пилот не вышел из тестового контура. Auspex ставит её первой именно потому, что она переносима: описанная механика остаётся у вас независимо от того, какую модель вы выберете через год и останется ли вообще на рынке та, с которой начинали.
Эта работа стыкуется с предыдущей частью разбора. В материале «Бизнес, который обновляет себя сам» речь шла о том, почему рост без найма упирается в описание бизнеса, которое живёт в головах сотрудников. DiG-bench добавляет к той картине ценник: показывает, во сколько обходится тот же разрыв, когда на процесс ставят не человека, а агента, и почему докупить обвязку вместо описания не получается.
С чего начать на этой неделе
- откройте регламент процесса, который планируете отдать агенту, и поищите в нём перечень запрещённых действий — если там только последовательность шагов, описания механики у вас нет
- найдите в том же документе предложение, которое отвечает на вопрос «по чему видно, что шаг выполнен правильно»
- спросите человека, который ведёт процесс, когда он в последний раз отступил от инструкции, и запишите признак, по которому он это решил
Если после этой проверки окажется, что процесс держится на памяти двух сотрудников, дело не в модели — и менять её нет смысла.
С таким списком расхождений можно прийти на аудит CRM и автоматизаций. За одну встречу Auspex разбирает, какой из ваших процессов описан достаточно, чтобы отдать его агенту, а какой сначала нужно вытащить в текст. Страница услуги — в ссылках ниже.
И мелочь, которую обычно замечают уже на втором проекте: описание механики должно жить там, откуда его читает агент, а не в презентации для руководства. Документ, который лежит отдельно от системы, расходится с реальностью примерно за квартал, и тогда у вас два источника правды вместо одного.