Пілот на демо відпрацьовує бездоганно, у проді агент починає робити дивні речі, команда йде шукати сильнішу модель. Через місяць з новою моделлю повторюється те саме, тільки дорожче.
Спокуса пояснити це якістю моделі велика, бо вона дає зрозумілий наступний крок. А в серпні 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 розбирає, який із ваших процесів описаний достатньо, щоб віддати його агенту, а який спершу треба витягнути в текст. Сторінка послуги — у посиланнях нижче.
І дрібниця, яку зазвичай помічають уже на другому проєкті: опис механіки має жити там, звідки його читає агент, а не в презентації для керівництва. Документ, що лежить окремо від системи, розходиться з реальністю приблизно за квартал, і тоді у вас два джерела правди замість одного.