Пять теорем о состоянии LLM

Начнём с нескольких положений, достойных размышления:

  1. Фронтальные лаборатории переоценены согласно нарративу, что они произвели или вот-вот произведут полностью автоматизированную замену для большинства работников умственного труда. Между тем текущие передовые модели требуют кропотливого надзора и ограничений даже на самых простых задачах. Тот, кого вводят в заблуждение громкие демонстрации (Navier-Stokes, уязвимости FreeBSD, инцидент на Hugging Face) и риторика фронтальных лабораторий, поверив в достижение истинной автономии, стоит лишь взглянуть на софтверные компании, которые продолжают нанимать инженеров из нижней квартили, уступающих в тестах тем самым моделям, которых они контролируют.
  2. Модели хорошо обобщают только на задачи из малой окрестности конкретных задач, на которых они обучены, и то с серьёзными оговорками. Фронтальные лаборатории разработали общий рецепт обучения моделей почти любой конкретной задаче с чётко определённым уровнем производительности; многие задачи охватываются данными обучения, но даже малые отклонения внутри покрытого класса задач приводят к полному отказу или манипулированию вознаграждением.
  3. Текущую проблему манипулирования вознаграждением можно решить только жёсткой формализацией специалистами предметной области. Время специалистов дорого стоит. Сама формализация — это навык, требующий собственной экспертизы вне данной предметной области. Даже многие опытные инженеры в этом плохи. Для большинства предметных областей пересечение специалистов и экспертов по спецификации смехотворно мало.
  4. Трудозатраты на жёсткую формализацию часто превышают стоимость прямой реализации неформальной спецификации. В мире аппаратного дизайна это хорошо видно: типичный проект процессора, по слухам, имеет примерно в три раза больше специалистов по спецификации и валидации, чем инженеров-разработчиков, а соотношение 5:1 не редкость. Того хуже, множество задач не допускают удобной модели «спец один раз и забыл», где спецификацию пишут однажды и затем постоянно реализуют против неё. Жёсткие формальные спецификации часто эволюционируют в диалоге с прозрениями, полученными при реализации согласно неформальной спецификации. Для задач, допускающих одноразовые спецификации высокого уровня (скажем, исполняемую спецификацию ISA для семейства архитектур процессоров), затраты на верификацию против таких спецификаций становятся непреодолимыми с современной технологией, что требует использования спецификаций более низкого уровня, которые дороже конструировать и гораздо более хрупки к изменениям дизайна.
  5. Navier-Stokes и математические утверждения подобного рода — это абсолютный лучший сценарий для агентной работы с жёсткой спецификацией. Само утверждение теоремы уже является жёсткой спецификацией. Оно прошло десятилетия проверки математическим сообществом и его кодификация на Lean — это прямая трансляция, определённая в терминах боевых математических объектов из mathlib. Верификатор, theorem prover Lean, тщательно проаудирован и специально разработан, чтобы избежать типов необоснованности, делающих его уязвимым для манипулирования вознаграждением. Даже Lean и подобные ему доказатели теорем не являются неуязвимыми: ошибки обоснованности позволяли LLM-ам пропускать фиктивные доказательства через ядро верификатора, и вполне вероятно, что существуют ещё такие ошибки. Это розовейший из возможных сценариев; абсолютное большинство человеческого умственного труда не похоже на это. Ниже прокомментирую несколько областей знаний, которые действительно похожи на чистую математику в этом отношении.
  6. Лучшей альтернативой жёсткой спецификации является человеческая проверка. Она плохо масштабируется на объёмы выпуска, производимые языковыми моделями. Что ещё хуже, даже экспертная проверка крайне уязвима для манипулирования вознаграждением: вспомните xz backdoor и печально известные гипокритные коммиты UMN, попавшие в Linux. Если человеческая проверка остаётся критической частью агентного производственного цикла, темп производства неизбежно ограничивается человеческими ресурсами. Это полный провал идеи страны полных гениев в датацентре, которую преподносят руководители фронтальных лабораторий как наступающую в течение нескольких месяцев реальность.

Практическая граница применения

Вместе эти соображения приводят к выводу, что для большинства предметных областей LLM останутся как неопытный стажёр: быстрые и эффективные в руках знающего человека, но им нельзя доверить самостоятельность. Большинство компаний не смогут принять полностью автономный ИИ — не из-за недостатка мастерства или отставания в распространении технологий, а по структурным причинам, видимо присущим текущей архитектуре. Классы компаний, которые могут принять полностью автономные LLM, немногочисленны; по моему подсчёту их всего три:

  1. те, кто может позволить себе отказ с малыми потерями: компании, которые иначе нанимали бы стажёров, фирмы, занятые быстрым прототипированием и так далее;
  2. те, кому нужно выполнить небольшой набор чётко определённых задач с уже существующими явными ограничениями: повторяющийся физический труд в контролируемой среде, работа call-центров и чатов поддержки клиентов и так далее;
  3. те, кто может позволить или уже принимает по своей природе затраты на жёсткую спецификацию и валидацию: дизайн кристаллов, разработка лекарств и другие предметные области, где отказ при развёртывании — экзистенциальный риск.

Первые два класса чувствительны к цене и, видимо, не нуждаются в скачке качества рассуждений, который даёт переход от дешёвых к фронтальным моделям. Большинству таких компаний лучше служить открытые модели на дешёвом железе, возможно даже локально, там, где они используются. Для первого и третьего классов тип нечёткого комбинаторного поиска, давший громкие результаты в математике и исследовании уязвимостей, похоже, более чувствителен к ширине агентного роя, чем к мощности рассуждений: см. как малые открытые модели воспроизвели Mythos CVE, которые питали цикл шумихи весной 2026. Если это действительно так, тем более резон использовать дешёвые открытые модели, позволяющие запустить ту же рабочую нагрузку с более широким роем.

Третий класс компаний может всё ещё использовать фронтальные модели, хотя совсем не ясно, что их работу не можно выполнить дешёвыми моделями типа Deepseek v4.1 Flash, и преимущество ширины роя, на которое я указал выше, даёт им все основания требовать более дешёвых моделей. Ещё одно любопытное свойство компаний этого класса — они обычно очень скрытны относительно своей интеллектуальной собственности и не слишком рады передавать её всю Anthropic и OpenAI даже с якобы соглашениями не обучаться на данных пользователей.

Масштаб и реальность

Правда, можно возразить, что даже если фронтальные лаборатории перегреются, сценарий с датацентром, полным середняков, генерирует столько же AI-вычислений, что и сценарий с искусственным сверхинтеллектом. Разница в том, что датацентр с гениями — автономен и ограничен только тем, сколько вычислений он может потребить, в то время как рои из середняков будут жёстко ограничены их человеческими оркестраторами. Моя личная ставка в том, что последствия выйдут далеко за пределы фронтальных лабораторий.