Дешево сгенерировать, дорого доказать

Первое время нейросеть вызывала восторг, вот это помощник! Пока модель собирает источники, ты открываешь вторую задачу, пока пишет черновик, занимаешься третьей. Через час уже у тебя лежит объем работы, на который раньше ушел бы день. Ключевое слово — лежит.

Нейросеть старательна, но в одной ее ссылке пересказ, в другой описание смежного рынка. Два правдивых факта модель соединила причинной связью, которой в источниках не было. 

И в этом есть занятная асимметрия: ИИ резко снизил стоимость подготовки черновиков и ответов, но не снял вопрос, почему им можно доверять. Хорошо, когда ответ проверяет человек, иногда тест или программа, а если нет? 

Один абзац и десять маленьких долгов

Промт «добавь цифры, причины и примеры» заставит LLM выдать результат убедительнее, но одновременно с этим усложнит работу пользователя. Ему нужно отдельно подтвердить каждую цифру, причинную связь и деталь примера.

Например, для статьи про экономику бизнеса модель пишет: «Рынок вырос на 18% благодаря спросу со стороны малого бизнеса и к 2030 году достигнет 40 млрд долларов». Возникает минимум пять вопросов:

• какой рынок;

• кто посчитал;

• с какого года считается рост;

• откуда известно, что причиной был малый бизнес;

• по какой методике построили прогноз на 2030 год.

Модель все это собрала, причесала и выпустила в одном предложении. Если автору не плевать на качество текста, ему придется разбирать фразу обратно.

Нюанс в том, что отдельные правдивые факты могут сложиться у нейросетей в ложный вывод. Исследователи из National Taiwan University обнаружили ^[1] такой эффект в биографиях, сгенерированных LLM. Модель брала проверяемые сведения о разных людях с неоднозначными именами и соединяла их в один текст.

Каждое утверждение имело источник, а человека, которого описывал абзац, не существовало. Обычные метрики фактичности не замечали подмену и завышали результат. После поправки на неоднозначность сущностей оценки четырех открытых моделей снизились более чем на 10%. Получается, даже если каждый факт по отдельности верен, весь текст может быть ложным. 

А давайте попросим Claude все проверить

Есть соблазн устроить проверку через другие модели, например, ChatGPT пишет, DeepSeek критикует, Claude выбирает победителя. Работать такая схема может, но гарантии никто не даст. В исследовании Verify with Caution авторы проверили ^[2] пять современных метрик фактичности на одиннадцати наборах данных. Метрики расходились между собой, ошибались на перефразировках и хуже находили подтверждение, если нужный фрагмент располагался далеко от проверяемой фразы.

Под контролем людей ситуация не намного лучше. В эксперименте с 80 участниками LLM помогала проверять ^[3]утверждения быстрее обычного поиска при сопоставимой точности. Но если модель давала неверное и убедительное объяснение, люди начинали ей чрезмерно доверять. Показ доводов за и против снижал этот эффект, но значимого преимущества перед поиском не давал. То есть проверка полезнее, когда она опирается на фактчекера другой типа, например, для кода это компилятор и тесты, для статьи – первоисточник. 

Почему код проще проверить, чем стратегию

Проверить код, расчет и прогноз — это проделать три разные работы. В одном случае можно получить однозначный результат за секунды, в другом останется лишь перечислить допущения и ждать, что произойдет на самом деле.

С кодом функция возвращает ожидаемое значение или проваливает тест. Все зеленое — можно выдохнуть, но не слишком сильно. Тесты проверили только то, что им поручили. 

В математике ^[4] требования строже. Система AlphaProof от DeepMind искала доказательства ^[5] на языке Lean. Специальная программа проверяла каждый шаг и отклоняла решение при нарушении правил. Вместе с AlphaGeometry 2 система решила четыре из шести задач Международной математической олимпиады 2024 года и набрала 28 баллов. Столько же требовалось для серебряной медали.

Но Lean не проверял задачу напрямую, сначала кто-то должен был убрать двусмысленность, расписать условия и объяснить системе, что именно нужно доказать. В AlphaProof некоторые доказательства занимали до трех дней поиска, и время уходило не только на сам поиск. Дополнительно появилась другая работа: подготовить задачу так, чтобы проверяющий вообще мог с ней работать.

С данными похожая история. Расчеты тоже можно воспроизвести: сохранить исходные данные, запросы и формулы, а потом повторить все действия. Только точное повторение ^[6] не спасает от плохих данных. Если магазин неверно учитывал возвраты, второй запуск даст ту же ошибочную цифру. Помимо этого, расчет может показать связь между показателями, но сам по себе не докажет, что один из них повлиял на другой.

С текстами сложнее, там все зависит от источников. Цифру иногда достаточно сверить с отчетом. С выводом труднее: приходится читать, в каком контексте она приведена и позволяет ли исследование сделать именно такой вывод.

У стратегии же нет даже такого способа проверки. Можно пересчитать бюджет, изучить рынок и проверить исходные предположения. Но узнать заранее, сработает ли запуск, не получится. Окончательный ответ даст только сам запуск, но вот только к тому времени рынок и потребности ^[7] уже могут поменяться.

Все держится на одном вопросе: стало лучше или нет? AlphaEvolve использует примерно такую логику ^[8]: модель предлагает варианты программ, а автоматические проверяющие сразу показывают, какие из них дают улучшение. 

Варианты запускаются и сравниваются по заданным показателям. Слабые отсеиваются, лучшие идут в следующий круг. По данным DeepMind, найденное системой решение ускорило ^[9] одно из вычислительных ядер Gemini на 23%. Общее время обучения ^[10] модели сократилось на 1%.

Придумать варианты — как раз то, с чем модели справляются хорошо. С вариантами у моделей все нормально, попросишь придумать десять решений — получишь десять, а вот что оставишь…

В инженерии для такой проверки есть оракул. Это правило или механизм, который способен быстро сказать: этот результат подходит, этот нет. С сортировкой у машины есть роскошь, которой часто не хватает в реальном мире: правильный ответ известен заранее. Массив должен остаться тем же, только элементы должны встать в нужном порядке. Никаких споров о вкусе ^[11], контексте или будущем. 

А теперь попробуем дать модели задачу из бизнеса. Например, придумать стратегию выхода нового продукта. Один вариант обещает больше продаж, другой работает на узнаваемость, третий самый незатратный. Какой победил? Через год, возможно, станет понятно, но ждать год после каждого варианта никто не будет.

Ссылка — только начало

Первое, что приходит в голову для проверки ИИ — попросить его показать источники. Пользователь занимает роль рецензента, но ИИ может скинуть несколько отчетов по 80 страниц. Методично их изучить и найти нужное — опять отдельная работа.

Авторы Attribute First, then Generate предложили ^[12] поменять порядок. Не сначала писать ответ, а сначала находить короткие фрагменты источников, на которых этот ответ можно построить. В экспериментах такой подход улучшил связь между утверждением и основанием: проверяющий понимал, откуда взялась конкретная фраза и насколько она опирается на источник.

Ссылка — это начало проверки, дальше начинается самая трудная часть – понять, действительно ли источник подтверждает конкретное утверждение, не потерялся ли контекст.  

В идеальном случае рядом с ответом нужна расшифровка:

• какое утверждение сделала модель;

• на какой фрагмент источника оно опиралось;

• какие данные попали в расчет;

• какую формулу использовали;

• где появились предположения;

• кто или что разрешило двигаться дальше.

Конечно, такой описание не спасает от галлюцинаций. Неверные данные можно аккуратно обработать, а слабый вывод — красиво обосновать. Но хотя бы видно место, где что-то пошло не так. 

Есть еще одна ловушка: происхождение текста легко перепутать с его качеством. Можно доказать, что материал написал человек, и все равно получить ошибку ^[13]. NIST рассматривает ^[14] водяные знаки, аутентификацию, обнаружение синтетического контента, тестирование и аудит как разные способы снижения рисков. В одном из пилотов NIST генераторы смогли подготовить тексты, которые обманули участвовавшие детекторы.

Невыносимая легкость генерации

Самое неприятное в генерации — ошибка редко выглядит ошибкой. Уверенная формулировка, аккуратная структура, и вуаля, все убедительно и грамотно. А проблема спряталась вообще уровнем ниже, поэтому одной проверки в конце мало. 

Хороший промт – это круто, но решает только часть задачи. Получается, пользователю на этапе промта надо уже знать, что можно проверить автоматически, а где нужны человеческие мозги. Здесь возникает параллель с proof engineering, инженерией доказательств. 

Там речь идет о построении доказательств и инструментов, которые помогают их проверять. С нейросетями речь уже не только о том, правильно ли модель вывела ответ, а теперь о всей цепочке вокруг него. 

Парадоксально, но ответ с пробелами иногда лучше законченного. Если модель оставила пометки типа здесь нужен источник или здесь не хватает данных, человек сразу видит фронт работы. Хуже вариант, когда поверили красивому тексту, а потом только стали искать, откуда взялись данные.

Похожую задачу решают исследования проверки промежуточных шагов. Например, в исследовании ThinkPRM авторы обучали ^[15] отдельную модель смотреть на ход рассуждения, не только итоговое решение. По их данным, при использовании 1% процессной разметки из PRM800K ThinkPRM превзошел несколько базовых подходов. Пока это препринт, но направление любопытное.

Ответ есть, а ответственный?

За проверку будут платить компании, у которых ответ нейросети расходится по внутренним чатам и задачам. Например, интернет-магазин публикует на сайте текст с неверным сроком доставки. Если никто из клиентов не пожалуется, можно долго и не догадываться об ошибке. Но если потом бизнес попросит нейросеть сделать договор, в котором будет пункт про сроки доставки, нейросеть перекинет ложный факт и туда. И так раскручивать цепочку можно долго, если нет своевременного вмешательства. 

Эту зависимость уже учитывают в инженерных рекомендациях. NIST определяет риск ^[16] через две величины: вероятность сбоя и тяжесть последствий. На проверку советуют выделять ресурсы соразмерно этим показателям. В профиле для генеративного ИИ рекомендации вполне предметные: сверять источники и ссылки в ответах, сохранять происхождение данных, описывать ограничения системы, приглашать специалистов из нужной области еще при выборе сценария использования.

Европейский AI Act построен ^[17] по тем же принципам. Для большинства систем с небольшим риском дополнительных требований нет. Если ИИ участвует в решении о кредите, трудоустройстве или медицинской помощи, правила строже: нужна документация, история работы системы, проверка качества данных и сотрудник, который следит за ее решениями. В некоторых случаях требуется независимая оценка соответствия.

Так что проверять каждый ответ с одинаковой тщательностью, скорее всего, будет не нужно. Деньги бизнес потратит там, где ошибка способна пройти по всей цепочке и задеть клиента, платеж или юридическое решение.

Есть вероятность, что часть расходов возьмет на себя поставщик сервиса. Он может встроить журнал действий, хранить версии, показывать точный фрагмент источника, запускать тесты и отмечать места, которые не удалось подтвердить.

Остальное — затраты компании, потому что провайдер AI-сервиса не знает внутренние процессы бизнеса, например, как магазин считает возврат с бонусами. Эти правила задают люди, знакомые с конкретным процессом. Они же решают, какую ошибку можно допустить, а после какой операцию надо остановить.

Если представить, как может выглядеть рынок ИИ-сервисов в будущем, получится несколько разных режимов работы:

Первый уровень — черновик. Модель помогает быстро собрать материал, но проверка полностью остается на человеке.

Второй уровень — ответ с источниками, тестами или другими автоматическими проверками. Не гарантия правильности, но уже понятно, откуда взялся результат и что именно можно перепроверить.

Третий уровень —системы, которые сохраняют весь путь, использованные данные, расчеты и промежуточные шаги.

С задачами с высокой ценой ошибки будет работать специалист, который принимает решение и отвечает за него.

Такой шкалы пока нет ни в стандартах, ни в интерфейсах большинства сервисов. Это мой прогноз. Но NIST уже связывает объем проверки с риском, а AI Act назначает разные требования в зависимости от того, где и для чего работает система.

Из этого появляется еще один вопрос: кто и в какой момент решает, что результат достаточно надежный? 

Эксперта часто зовут на финальный просмотр. Вот отчет, вот презентация,. проверьте, все ли хорошо. Только к этому моменту многое уже решено гораздо раньше. Почему взяли именно эти данные? Какие варианты не попали в расчет? Почему одному выводу дали больше веса, чем другому? Эксперт может проверить цифры и логику внутри отчета, но не больше.

Так что, похоже, проблема ближайших лет будет не в дефиците ответов, их уже солить можно. Вопрос в другом: как быстро понять, какой из них стоит использовать, а какой просто хорошо прошел проверку на убедительность.