Ричард Саттон — не рядовой скептик. Его работы по reinforcement learning легли в основу того, как работают AlphaGo, современные агенты и RL-файн-тюнинг языковых моделей. И именно он сказал прямо: генеративный AI в чистом виде не может делать настоящую науку. Причина — отсутствие встроенного механизма оценки собственных результатов. Новизна возникает, мерцает — и гаснет, потому что системе нечем её зафиксировать и усилить.
Контекст
Саттон разделяет два типа AI-систем. Первый — генеративные модели: GPT, Claude, Gemini и их аналоги. Они предсказывают токен за токеном, опираясь на статистику обучающей выборки. Они могут воспроизвести паттерны науки — написать похожую на статью статью, сгенерировать код, сформулировать гипотезу. Но у них нет внутреннего судьи, который бы сказал: «вот это действительно ново, вот это работает, а вот это — нет».
Второй тип — системы с evaluation loop: встроенной функцией оценки, которая позволяет проверять каждый шаг. Примеры, на которые ссылается Саттон, — AlphaGo и AlphaProof. AlphaGo знает, выиграл он партию или проиграл: сигнал однозначный. AlphaProof работает с формальными доказательствами — математика либо верна, либо нет. Это и есть петля: генерация → проверка → отбор → следующий шаг. Именно так, по Саттону, возникает что-то принципиально новое.
Сам Саттон — соавтор классического учебника по reinforcement learning, лауреат премии Тьюринга совместно с Дэвидом Силвером. Его позиция не антагонистична большим языковым моделям — он просто фиксирует архитектурный предел.
Аналитика
Тезис Саттона попадает точно в болевую точку нынешнего AI-хайпа. Индустрия последние два года строила нарратив: «дай модели достаточно данных и параметров — и она сама разберётся». Но на уровне реальных научных задач это не работает. Генеративный AI хорошо интерполирует внутри распределения обучающих данных — и плохо экстраполирует за его пределы. Именно поэтому GPT-4 может написать убедительную статью о синтезе белка, но не открыть новый механизм фолдинга.
Параллельно в индустрии накапливаются свидетельства того, что agentic-архитектуры с верификацией — это следующий серьёзный рубеж. OpenAI o3, DeepSeek-R1, Claude со встроенным reasoning — все они пытаются добавить именно то, о чём говорит Саттон: внутренний критик, который проверяет цепочку рассуждений до выдачи ответа. Это не генерация — это уже гибрид генерации и поиска.
Для AI-first бизнеса это означает конкретное следствие: применение LLM там, где есть верифицируемый выход — код, тесты, юридические формуляры, математика — принципиально надёжнее, чем там, где выход проверить нечем. Инструменты типа code interpreter, формальные пруверы, unit-тесты как evaluation loop — это и есть прикладная версия аргумента Саттона.
Кейсы применения в бизнесе
B2B-SaaS стартап. Если продукт включает AI-генерацию контракта, отчёта или технического задания — добавь обязательный verification step: юридический чеклист, автотесты на соответствие шаблону, сравнение с предыдущей версией документа. Без этого шага LLM работает вслепую. С ним — ты получаешь evaluation loop и начинаешь видеть, где модель ошибается системно.
Корпорация с legacy. Типичный кейс — AI-ассистент для аналитиков, который генерирует SQL-запросы или финансовые сводки. Без верификации это инструмент с высоким риском тихой галлюцинации. Добавь слой: запрос выполняется на sandbox-данных, результат сравнивается с историческими бенчмарками, аномалии флагируются. Это и есть встроенный критик — ровно то, чего не хватает чистому generative AI.
SMB/локальный бизнес в КР/СНГ. Небольшие команды часто используют ChatGPT или Claude для генерации текстов, переводов, ответов клиентам. Практический вывод: стройте простые evaluation loop даже вручную — например, ротация: один сотрудник генерирует, второй проверяет по чеклисту. Или используй модель дважды: первый промпт генерирует, второй критикует по конкретным критериям. Это работает.
Кейсы в личной жизни
Разработчик. Когда пишешь код с помощью Claude или Copilot — unit-тесты это твой evaluation loop. Не принимай сгенерированный код без тестов. Именно это превращает стохастический процесс генерации в нечто проверяемое. Попробуй TDD с AI: сначала опиши тест, потом проси код.
Контент-мейкер или аналитик. Используй двухшаговую генерацию: первый промпт — черновик, второй — «найди в этом тексте три слабых места: где нет доказательств, где логика рвётся, где сказано общее слово вместо конкретного». Это имитация evaluation loop внутри чат-интерфейса. Качество резко растёт.
Студент или исследователь. Не проси AI написать за тебя вывод по данным. Проси его сформулировать альтернативные гипотезы — и потом проверяй каждую по своим данным. Так LLM работает как генератор пространства гипотез, а верификация остаётся за тобой. Это честная схема, которая не обманывает ни тебя, ни рецензента.
Как применить сегодня
- Перед внедрением LLM в любой процесс задай вопрос: «Как я проверю, что результат правильный?» Если ответа нет — evaluation loop отсутствует и риск высокий.
- Добавь второй шаг критики в любой AI-пайплайн: модель генерирует → модель (или правило, или человек) проверяет по чеклисту.
- Используй инструменты с верифицируемым выходом: code interpreter с запуском кода, формальные валидаторы JSON/SQL, сравнение версий документов.
- Если задача научная или исследовательская — смотри в сторону agentic-систем с reasoning: Claude с extended thinking, o3, DeepSeek-R1. Они ближе к evaluation loop, чем plain completion.
- Прочитай оригинальную статью Саттона и Бартo «Reward is Enough» (2021) — она закладывает философию того, почему сигнал оценки первичен.
«Без возможности оценивать собственные результаты новизна возникает, мерцает — и гаснет.» — Ричард Саттон