Две недели назад я сократил одну строку в системной подсказке для нашего агента исправления кода C++: «Предпочитайте читаемый код» вместо «Будьте кратки». В следующем спринте агент незаметно прекратил вставлять throw std::invalid_argument в парсер. Модульное тестирование...
Две недели назад я сократил одну строку в системной подсказке для нашего агента исправления кода C++: «Предпочитайте читаемый код» вместо «Будьте кратки». В следующем спринте агент незаметно прекратил вставлять throw std::invalid_argument в парсер. Модульные тесты были зелеными, потому что тесты никогда не использовали этот путь. Патч был объединен, и в следующий вторник клиент ввел неверный ввод.
Это редактирование одним словом казалось бессмысленным. Это не так. Модель переосмыслила весь стек инструкций, и мне не пришлось просматривать различия, поскольку подсказки находятся вне контроля версий. Если разработчик таким образом изменил сигнатуру функции, PR не сможет выполнить CI. Для подсказок мы отправляем вслепую.
Поэтому я начал относиться к быстрым изменениям так же, как мы относимся к редактированию кода: как к запросам на изменения, требующим проверки, как к воротам регрессии и пути отката. Эта статья представляет собой рабочий процесс, который я создал, и он достаточно мал, чтобы работать на бесплатном уровне.
Почему быстрое редактирование — это развертываемый артефакт
Большие языковые модели чувствительны к фразеологии, возможно, больше, чем нам хотелось бы признавать. Одно-единственное удаленное прилагательное может изменить порядок весов внимания в десятках токенов, и внезапно генератор кода решает, что обработка ошибок необязательна. Эффект недетерминированный