Comments 12
Автор молодец и четко разобрал все. На машинном уровне это происходит так - чем точнее и однозначнее описана задача, тем более сфокусировано внимание модели. Ей самой проще писать по такому заданию, не бегая по всему спектру вероятностей.
«Агент тупит» — это диагноз инструкции
Как я люблю эти однозначные утверждения не допускающие вариантов... "На потоке"? Ну если "на потоке", то видимо автор видел некие отличия поведения одной и той же модели скажем того же антропика в зависимости от времени суток (утром в европе нагрузка нижи - модели работают эффективнее, дня недели (выходные чаще всего модели тупят меньше)), подготовки к релизу (там вообще может жесть случаться). Я бы лучше всё-таки прописал бы что "это чаще всего диагноз инструкции".
И, кстати, вдогонку к статье я бы повосетовал это: https://martinfowler.com/articles/harness-engineering.html :)
Если чек-листом с гейтом в CI закрывается любое правило надежнее, чем текстом, то зачем вообще оставлять словесные инструкции, а не переводить все сразу в проверяемый код?
Гейт можно поставить только на правило, у которого уже есть чёткий детерминированный инвариант, а такие в основном появляются постфактум, после второго-третьего тикета с одним и тем же рецидивом (см. историю с замороженным днём — сначала три прилёта, потом реестр). Заранее написать CI-проверку на «ссылка или подчинённая таблица» не получится, там не булево условие, а выбор из контекста: чек-лист с рассуждением или ничего. Ну и в статье прямо показано: даже где гейт есть, полдела делает требование написать RATCHET-OK: <почему> словами.
Кто стрелял из автомата, вероятно, сталкивался с подобным соблазном — довести цель под мушку движением головы, а не автомата. Видимый результат тот же самый, хотя что-то неуловимо не то.
Чувак, ты сделал мой день! :-D
Мне очень не нравятся ваши вводные (первые 3), т.к. я пришёл к почти противоположным.
Рассмотрим 2 промпта:
1. Надо сделать Y, разберись в проекте и сделай хорошо (уточняй у меня по ходу дела непонятное)
vs
2. Надо сделать Y, посмотри в Х1, отрефактори Х2, разберись с Х3, не забудь про X4.
(вы по-сути учите как писать промпт типа 2).
Так вот на "простых" задачах промпт-1 НАМНОГО лучше.
На сложных задачах (как раз готовлю статью на Хабр) - промпт-1 тоже лучше, но агент иногда задаёт плохие уточняющие вопросы.
*) Ещё если вы буквально знаете как сделать сложную задачу от начала и до конца, а также что в этом делании важно, а что второстепенно - то да промпт №2 пожалуй поможет.
И только на средних задачах имеет смысл учится делать промпты №2 и это даст хоть какой-то эффект.
То есть фактически вся ваша статья посвящена довольно специфическим условиям, без указаний границ когда это хорошо.
Статья действительно про узкое применение, если учитывать весь спектр задач к ИИ.
Конкретно про проекты (опуская, что они делаются ИИ-агентами и прочее), идущие несколько месяцев, где требования изменяются/рождаются на ходу и по ходу проекта формируются рамки, которые не хочется каждый раз повторять агенту.
Ваш случай 1 - простые проекты и ничего не прибито гвоздями и, скорее всего, не имеет продолжения. В раках большого проекта мы такое делаем пачками, отвечая на вопросы по ходу и не имея вообще проблем. Тут нет боли, поэтому и не пишем про такое.
Случай 2 - это как раз попытка одним коротким промптом поправить что-то в большом проекте, не поломав больше ничего. Самое приятное в работе с таким промптом, что агент подсвечивает тебе дефекты аналитики и крайние случаи, про которые ты и думать забыл — это прям особый кайф, такие случаи. Это часто экономит пару-тройку кругов ада, если вам знакома ситуация :-)
*) Ещё если вы буквально знаете как сделать сложную задачу от начала и до конца
Да-да! Я вот именно про это: я НЕ ЗНАЮ (тупо не помню) от начала и до конца, и вспоминать не хочу, потому что попутно делаю 3-4 проекта + текучку. Но то, что я однажды постиг и зафиксировал, помнит за меня агент.
Ваш случай 1 - простые проекты и ничего не прибито гвоздями и, скорее всего, не имеет продолжения.
Нет. Даже предыдущие модели (OpenAI 4.6) вполне хороши когда надо вполне комплексно поправить 1 модуль от проекта размером 100-200 [kLoC]. Со словами "надо сделать Y, в модуле Х, разберись-поправь". Уточнения зачастую только мешают. Но это именно кодинг.
Архитектуру (в частности аппаратуры) - даже новые Astra / Fable не тянут, как раз проверял из интереса.
Может, я не понимаю контекст. Никакая модель не может поправить модуль, если в нем отсутствует часть логики — вроде как есть рельсы, карта и семафоры, но вот горки и качество полотна сверху не видно.
Понятно, сейчас любая модель умеет проследить логические цепочки, а если что непонятно, так она выдумает и срежет углы. Любой модели нужны рамки, и все их создают по-разному, и, возможно, ваши рамки закрывают нашу боль, надо уточнять.
Про архитектуру, наконец-то, открыто написано — агентам это нельзя доверить, спасибо. Но я тут про логику и контекст, не архитектуру.
Может, я не понимаю контекст.
вот с++ симулятор, в нём есть l1 кэш, давай сделаем правку, что request и update могут объединяться в одну транзакцию.
Это довольно сложная правка, но уже предыдущее поколение OpenAI 4.6 уже достигли уровня когда не надо ничего разжёвывать (пока логика вашего симулятора как-то соответствует общепринятой - на которой он обучался).
П.С.
Тут интересно про разжёвывание:
во первых он начинает придавать непропорционально большое значение написанному и снижает вес ненаписанного (даже если для условного джуна это было бы само собой разумеющимся)
во вторых некоторые обороты триггерят какое-то поведение - например если написать про какой-то подмодуль "отрефактори", то он в этом подмодуле, да и во всей правке начнёт вести себя куда скованнее, чем хотелось бы (а сколько таких "триггеров" на которые не наткнулись?)
«Агент тупит» — это диагноз инструкции, а не модели