Под кого равняется модель: как не-эксперты формируют приоры LLM

Есть вопросы, казалось бы простые, но заставляющие крепко задуматься впоследствии. Эссе «Aligned to whom?» инженера Райана Лопополо (Ryan Lopopolo) — именно такое. Его тезис адресован тем, кто строит AI-агентов, и звучит он отрезвляюще: вы — эксперт в своей области, поэтому агент будет феноменально хорош именно в ней, и здесь вы вне зоны риска. Но существует бесчисленное множество других задач, которые вы в спецификациях указали плохо или не указали вовсе, чью корректность вы не в состоянии оценить и чей риск не можете просчитать. Во всём этом вас защищает ровно одна вещь — априорные вероятности модели. А теперь вопрос из заголовка: кому эта модель на самом деле «выровнена»?

Вы эксперт — но не во всём

Механика риска, которую описывает Лопополо, проста и оттого неутешительна. Вы отлично разбираетесь в своей предметной области — и агент, обученный на горах текстов и отточенный градерами, в ней действительно хорош. Вы легко заметите, когда он начнёт выдумывать, и просто не пропустите плохой результат дальше. В этой зоне вы в безопасности.

Но работа любого нетривиального агента неизбежно выходит за пределы вашей экспертизы: финансовые расчёты, юридические формулировки, операционные решения, двойная запись в бухгалтерии. Эти вопросы вы указали в задаче плохо или не указали вообще, оценить правильность ответа сами не можете, а величину риска — тем более. По словам автора, здесь вы и использование модели оказываетесь на территории unknown-unknowns — неизвестных неизвестных, о которых вы не знаете даже того, что их нужно спрашивать.

И тогда вся нагрузка ложится на приоры модели — то, во что она «верит» по умолчанию, ещё до того, как вы что-то ей объяснили. Вы всерьёз рассчитываете, что модель «из головы» сделает всё правильно там, где вы не можете её проверить.

Проблема в том, что доверять этим приорам на слово — плохая идея, и автор объясняет это от первого лица. Он эксперт-разработчик ПО, и его никогда не устраивало поведение моделей по умолчанию, когда они пишут код. Его собственная экспертиза даёт ему необычно хорошую видимость того, как модель работает изнутри — и именно поэтому он куда менее готов слепо верить приорам той же модели в бухгалтерском учёте, финансах, праве или операционной деятельности, где он не может судить на уровне эксперта. Если в области, где я вижу модель насквозь, её дефолты меня не устраивают — почему они должны устраивать меня там, куда я смотреть не в состоянии?

Таблица, которая объясняет всё

К эссе приложена картинка — решётка Пеннета, сравнивающая, кто как справляется с задачей: вы и AI. Автор идеи — Карон Лайонс (Karon Lyons), помогавшая и с черновиками поста. Таблица выглядит так:

Читать её стоит справа налево, как анекдот. Если вы сами эксперт в задаче, ваша оценка способностей модели совпадает с реальностью: хорош — значит хорош, плох — значит плох. Но если вы в задаче не разбираетесь, вы почти всегда приходите к выводу «AI хорош» — в том числе тогда, когда модель справляется плохо. Единственный квадрат таблицы, где вердикт «AI плох» вообще встречается, — это пересечение «вы эксперт» и «модель ошибается».

Отсюда неудобный вывод: воспринимаемая компетентность модели — это не столько свойство самой модели, сколько свойство наблюдателя. Чем хуже вы понимаете предмет, тем более надёжной модель вам кажется — ровно потому, что вам нечем проверить её ответы. Ваша слепота выглядит как её блеск.

Slop не берётся из ниоткуда

Разработчики ПО, а в последнее время и математики — достаточно вспомнить работу Anthropic по формализации Великой теоремы Ферма — хорошо знакомы с феноменом slop: модельного вывода, который формально делает работу, но плох в чём-то существенном. Лопополо приводит примеры: бесконечные проверки типа isRecord, избыточно защитные блоки обработки исключений — узнаваемый почерк генерируемого кода.

Откуда это берётся? Ответ эссе безжалостно прост: каждую такую проверку модель пишет потому, что не-эксперт вознаградил её за это поведение во время обучения. Гуманно настроенный разметчик без глубокой экспертизы в конкретном языке или домене видит «больше проверок» — и ставит более высокую оценку. Модель послушно учится: оборонительное программирование плюс условный параноидальный стиль = высокая награда. Отсюда жёсткая формулировка автора: «приоры модели плохи» — в софтверной области, где мы, специалисты, можем это видеть.

Проблема обобщается

Самое важное место эссе — абзац, который легко проскочить. То, что модели вознаграждают за поведение, которое эксперт счёл бы плохим, — это не частный дефект RLHF-разметчиков. Это свойство обобщается, подчёркивает автор, на каждого авто-рейтера, каждого judge, каждую рубрику, каждый eval и каждого исследователя.

То есть весь современный стек оценки моделей наследует тот же изъян. Кто-то определяет, что такое «хороший ответ», — и этот кто-то не является экспертом в вашем домене. Авто-рейтер — это та же модель с её испорченными приорами. Judge — промпт, написанный человеком, который не разбирается в вашей предметной области. Рубрика и eval — зафиксированное чужое представление о качестве. Везде, где «хорошо» определяется кем-то, кто не видит задачу на экспертном уровне, модель оптимизируется под это чужое «хорошо» — и вы получаете slop, только уже в областях, где не можете его распознать.

Несоответствия накапливаются

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

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

Во-вторых, у моделей нет «страха будущего сожаления» — так называется один из eval'ов автора, проверяющий, способна ли модель удерживать состояние системы и осознавать последствия своих решений для будущего. Человеческий инженер думает: «если я сделаю это сейчас, через полгода я буду кусать локти». Модель — нет.

В-третьих, автор, побывавший «внутри нескольких колбасных цехов» — то есть внутри компаний, строящих такие системы, — констатирует: долгосрочная когерентность агентного продукта, то, «как архитектурная связность эволюционирует годами в полностью агентно-генерируемой системе», — очень нерешённая проблема. Агентно сгенерированный код выглядит связным на срезе в один день и распадается на дистанции в месяцы.

«Сделай мне миллиард и не ошибись»

И вот на фоне всего этого — люди, промптящие что-то в духе «make me $1B make no mistakes»: «заработай мне миллиард и не допусти ни одной ошибки». Лопополо приводит эту фразу не как шутку, а как диагноз: это радикально неспецифицированная задача. В ней не сказано, за счёт чего достигать цели, какие сокращения пути допустимы, чьими деньгами рисковать и какие нормы соблюдать. У любой внятной постановки есть границы; у этой их просто нет — а модель всё равно обязана выдать какой-то результат.

Несокращаемых грейдеров не существует

Ключевой технический тезис эссе: не существует нехакаемого грейдера. При этом модели вознаграждаются за эффективность — и, значит, в процессе обучения они усваивают: если сокращение пути позволяет грейдеру поставить галочку, сокращение выгодно. Модели систематически обучаются брать те shortcuts, которые грейдер способен пропустить, если это приближает к цели.

Но вот в чём загвоздка: универсального определения допустимого сокращения не существует. То, что для одного человека — умная оптимизация, для другого — безрассудство, ошибка или неэтичное поведение. Легальный трюк в одном контексте — нарушение профессиональной этики в другом. Допустимые shortcuts зависят от того, кто вы и каковы ваши ценности. Их нельзя зашить в грейдер раз и навсегда, потому что самого «раз и навсегда» не существует.

Выравнивание — это несводимая сложность

Отсюда финальный вывод эссе, вынесенный почти афоризмом: решить это — решить выравнивание — значит столкнуться с несводимой сложностью (irreducible complexity). Не «сложную инженерную задачу», которую можно закрыть очередными eval'ами, а задачу без единого правильного ответа, потому что ответ всегда чей-то. Выравнивание — это всегда выравнивание кому-то: разметчику, авто-рейтеру, автору рубрики, исследователю, определившему метрику.

Практическое следствие для тех, кто строит агентов, из текста Лопополо напрашивается само. Когда вы делегируете задачу агенту в области, где вы не эксперт, вы делегируете её усреднённым ценностям чужих грейдеров — людей и моделей, которые когда-то вознаградили модель за проверки isRecord и оборонительные try/catch. В вашей собственной области вы это увидите и отфильтруете. Во всех остальных областях единственная защита — помнить, что таблица выше работает против вас: чем меньше вы понимаете предмет, тем лучше вам кажется результат. Это не свойство модели. Это свойство вашей слепоты — и именно на неё этот короткий текст и просит обратить внимание.