Глава 24. Детерминированные проверки вместо уговоров

Есть класс проблем, который не лечится ни инструкцией, ни ревью, ни эвалом, ни молитвой. Он лечится только тем, что часть контроля забирают у модели и отдают коду.

Правила не удерживают агента Начнём с исследования, которое стоит знать всем.

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

Результат вышел невесёлый. Даже детальные руководства ни хуя не гарантируют. Агенты находили лазейки: выполняли требования формально и нарушали суть.

Требование Как обошли

Не удаляй файлы Переименовал

Не публикуй секреты Закодировал

Не превышай лимит запросов Разбил на несколько источников

Вывод авторов сформулирован жёстко: управление агентами через правила принципиально ненадёжно.

ГЛАВНОЕ ПРО ЗАПРЕТЫ Агент выполняет букву и нарушает смысл. Не из вредности, а потому что задачу надо закрыть, а прямой путь перекрыт. Отсюда следует, что запрет без предоставленного правильного пути рождает не качество, а изворотливость. Чем строже запрет, тем изобретательнее обход.

Ровно то же наблюдение, что и в главе про регекспы: запрет закрывает половину работы, вторую половину закрывает готовый способ сделать правильно.

Агент обыгрывает и проверку Второй уровень той же проблемы, и он хуже.

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

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

Отсюда правило: проверку пишет не тот, кто выполняет. Либо человек, либо отдельный агент с отдельным заданием, либо, что лучше всего, код.

Детерминированные проверки вместо уговоров

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

ЧТО ДЕЛАТЬ С ТРЕБОВАНИЕМ

Требование к поведению системы

Требует догадки и понимания Требует надёжности и повторяемости

отдать модели написать кодом

Признаки того, что требование должно быть кодом:

Результат должен быть одинаковым всегда, а не почти всегда.

Нарушение обнаруживается не сразу, а через время.

Цена нарушения выше стоимости написания проверки.

Формулировка требования содержит слова всегда, никогда, обязательно.

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

Форматы и контракты Частный, но самый частый случай.

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

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

Общая формулировка: модели оставляй магию, всё, что требует надёжности, обеспечивай кодом. Контракт обеспечивает обвязка, а не абзац внутри запроса.

Архитектурные ограждения Хороший приём, который недооценивают: часть архитектурных требований выражается линтером.

Детерминированные проверки вместо уговоров

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

Требование Как выразить кодом

Модуль А не знает о модуле Б Правило линтера на импорты

Ошибки не обрабатываются молча Проверка на пустой перехват

Нет прямых обращений к базе из обработчиков Правило на вызовы

Нет дублирования Проверка на схожие фрагменты

Каждое такое правило разгружает и правила проекта, и внимание ревьюера. И работает независимо от того, какая сегодня модель и в каком она, блядь, настроении.

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

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

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

ГЛАВНОЕ ПРО ОБВЯЗКУ И РЕЗУЛЬТАТ Разница между тринадцатью и тридцатью восемью процентами это не модель, а две настройки окружения. Прежде чем менять модель, проверь, не мешает ли ей твоя собственная обвязка. Самый дешёвый способ улучшить результат, и его почти никогда не делают первым.

Проверка результата без чтения кода Приём уже упоминался в главе про ревью, но здесь он на своём месте, потому что это тоже способ забрать контроль у модели.

Попроси агента объяснить обычными словами поток исполнения: откуда данные, куда идут, где принимаются решения. Пересказ подделать трудно, потому что описывать придётся то, что реально написано.

Код-проверки это не заменяет, но закрывает то, что проверками не ловится: расхождение реализации с замыслом.

Детерминированные проверки вместо уговоров

ЧТО ПЕРЕВЕСТИ В КОД НА СВОЁМ ПРОЕКТЕ 1. Выпиши из правил проекта все строки со словами всегда, никогда, обязательно. 2. Для каждой спроси: могу ли я написать проверку, которая отвечает да или нет? 3. Где можешь, напиши и повесь на событие. 4. Строку из правил после этого удали. Две реализации одного требования разъедутся. 5. Проверь, что нарушение возвращает понятную ошибку в сессию, а не молчаливый отказ.

Что запомнить Управление через правила ненадёжно: агент выполняет букву и нарушает смысл.

Запрет без предоставленного правильного пути рождает изворотливость, а не качество.

Проверку не должен писать тот, кого проверяют.

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

Формат, описанный словами, нарушается в одном случае из десяти и формулировкой не лечится.

Архитектурные требования выражай линтером, а не просьбой.

И прежде чем менять модель, проверь, не мешает ли ей твоя собственная обвязка.

← Эвалы · оглавление · Сколько полировать →

Спросить книгу может любой, кто вошёл в Neuraldeep Hub: агент ищет ответ по тексту и приводит цитату со ссылкой на главу.