Как я переложил решение вопросов на нейронку

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

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

В общих чертах алгоритм для субагентов состоит из 4 шагов. Внутри шагов — правила и проверки, собранные из принципов разных авторов: «растворить проблему вместо того, чтобы решать» Рассела Акоффа, теория ограничений Элияху Голдратта, забор Честертона («не сноси, пока не узнал, зачем поставили»), односторонние и двусторонние двери Джеффа Безоса, вычитание как первый ход из книги «Subtract» Лейди Клотца, делегирование по риску из Next Move Theory Вани Замесина

Шаг 1: растворить
Агент проверяет, есть ли проблема на самом деле или она надумана. Если проблемы нет — вопрос снимается. Если есть — ищет, не записан ли ответ уже в правилах проекта или в том, как проект устроен

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

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

Шаг 4: спросить меня
Сюда доходит то, что агент не вправе решать сам

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

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

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

Первые результаты этого подхода: из 27 открытых вопросов, которые раньше я разбирал бы сам шаг за шагом, 10 сняты с повестки, 16 агент решил сам и написал мне краткую сводку, и только 1 вопрос дошёл до меня 😧 это безумный буст производительности