Глава 14. Инструменты и когда обвязка вредит

Три предыдущие главы учили строить. Эта учит расхуячивать, и она едва ли не важнее.

Инструмент это контракт Сначала короткая часть про инструменты, она примыкает по смыслу.

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

Пункт Вопрос, на который отвечает

Схема входа Что можно передать и в каком виде

Предусловия Когда вызывать нельзя

Побочные эффекты Что изменится в мире

Таймаут Сколько ждать и что считать отказом

Идемпотентность Что будет при повторном вызове

Права Кому и в каком режиме доступен

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

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

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

Главный вред обвязки это не объём Теперь про снос.

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

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

Инструменты и когда обвязка вредит

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

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

Три инструкции требуют разного

Тратит рассуждение на разрешение конфликта Получает один критерий вместо трёх запретов

до задачи доходит меньше рассуждение идёт на дело

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

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

Примеры в интерфейс. Пример сужает поиск. Выразительный параметр не сужает.

Всё сразу в постепенное раскрытие. Ревью и верификация выносятся в скиллы по требованию. Файл правил становится деревом файлов, а не единой свалкой.

Повторы в описания инструментов. Поведение можно описать там, значит в правила оно не идёт.

Память в правилах в автоматическую память. Разное живёт по-разному.

Простые спецификации в богатые референсы. Спецификацией может быть набор тестов, функция из другого проекта, макет интерфейса. Рубрика оценки тоже референс.

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

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

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

Инструменты и когда обвязка вредит

РЕВИЗИЯ ОБВЯЗКИ 1. Сложи всё, что накопил, в отдельную папку и отключи. 2. Поработай неделю. Записывай каждый случай, когда пришлось объяснять руками. 3. Верни только то, что встретилось два раза и больше. 4. Возвращая, спроси себя, где этому место: правило, скилл, хук или описание инструмента. 5. Повторяй раз в квартал. Это не разовая уборка.

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

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

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

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

Что проверяем За сколько видно

Тест прошёл Секунды

Функция работает Минуты

Регрессия не всплыла Дни

Архитектура выдержала изменение требований Месяцы

Систему всё ещё можно развивать Годы

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

Инструменты и когда обвязка вредит

Противоположная крайность Чтобы картина была полной, стоит знать и радикальный ответ, который у практиков тоже работает.

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

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

Это не совет всем. Это напоминание, что тяжёлый процесс не единственный ответ, и что выбор между ними определяется ценой ошибки, а не модой.

Что запомнить Инструмент это контракт из шести пунктов. Неназванный пункт однажды выстрелит.

Внешние интерфейсы заворачивай в утилиты: сборка запросов на лету даёт выдумки.

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

Давай критерий вместо списка запретов. Критерий переносится на новые ситуации.

Раз в квартал отключай всё и возвращай только то, на чём спотыкаешься повторно.

Постоянно живут только проверки. Инструкции стареют.

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

Модуль 4. Контекст и память Четыре главы про главный ресурс.

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

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

← Хуки и детерминированные гарантии · оглавление · Контекст как единственный ресурс →

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