Универсальный взлом LLM

Где-то с месяц назад вышла статья об универсальном способе выводить модель за рамки ее ограничений – делиться системным промптом или запрещенной инфой вроде инструкций по созданию биологического оружия.

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

Но кое-что помешало.

Прежде чем писать мысли, стараюсь проверять их на практике. Так что попытался подобрать такой системный промпт, на котором взлом не сработает. Результат двух заходов – ни одной успешно-стабильной защиты внутри промпта.

Так что сначала будет о том, как и почему оно работает. Дальше выводы, что это значит для AI-продуктов. И как все-таки делать защиту "извне" – в конце поста. Сам промт из статьи для взлома – в комментах.

Почему работает:

* Дело именно в структурированном вводе – если ввод очень похож на файлы конфигурации по сути и по форме (XML, JSON, YAML), то LLM и принимает их за конфигурацию – ее собственные настройки.

* Очень любопытно, что этот паттерн-матчинг оказывается сильнее чем специальное обучение на различие system_prompt/user_prompt.

* Тот факт, что это работает для разных моделей – говорит о том, что это не какой-то особенный способ, а скорее общая проблема в текущих методах обучения LLM.

* Многослойная атака. Чтобы усилить работу основного механизма мимикрии под файлы конфигурации, авторы добавили еще два слоя: role-play и обфускацию через leet speak. Это норм обход защиты, в которой явно прописаны критерии взлома.

Как это влияет на бизнес:

* Если ваша конкурентное преимущество – это ваша доменная экспертиза (а это так для большинства успешных AI-продуктов), то у вас проблемы. За последний месяц утекло много промптов от известных компаний (даже от тех, кто ну точно шарит).

* Вы можете реверс-инжинирить их подходы до того, как они сделают это с вами.

* А самим быстрее учиться защищаться.

Как защититься:

Отдельный запрос с проверкой по чек-листу + structured_output + temperature=0.

Пример для вдохновения:

{
  "involves_role_play": <bool>,
  "contains_leet_speak": <bool>,
  "looks_like_policy": <bool>,
  "is_trying_to_get_system_prompt": <bool>,
}

Это доп.шаг, который увеличивает время ответа, а у части моих клиентов есть жесткие ограничения на это. Для таких случаев делаем два запроса в параллель (основной и проверочный). Так у нас происходит проверка во время генерации основного результата. И если проверка пройдена, просто отдаем его, а если нет, то отбрасываем и баним юзера 🙃. Так мы иногда тратим токены впустую, но проверка происходит без доп. затрат по времени.

———

Очень советую посмотреть на структуру промпта в комментах. Это может помочь и ваши системные промпты лучше писать.

Ну а глобально, это еще раз подтверждает, что мы пока не можем нормально контролировать поведение AI. Учитывайте это при планировании на год-два.

Пост про AI кодинг оказался одним из самых зарепосченных в канале.

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

Я бы читал по 2-3 за раз и делал бы себе напоминалки, чтобы дочитать остальные – материал реально крутой, за такой люди деньги берут, обидно навечно похоронить его в сохраненках.

- Vibe Cursor Coding

- AI / Vibe coding - советы и best practices

- Как получилось, что юристы используют среду для разработчиков?

- Stitch: от вайб-кодинга к вайб-дизайну и обратно

- Как я бросил курсорить и начал шотганить

- Вайб-кодим Google Apps Script для офисных задач: как LLM превращает часы рутины в минуты магии

- Context7 — один из лучших инструментов для AI-разработки

- Топовый AI Coding Workflow: Cursor & AI Studio

- Как Cursor AI превращает текст в готовые макеты Figma

- Простое веб-приложение за 30 минут с помощью Lovable

Как я уже писал:

Никто сейчас на самом деле не знает как правильно. Кроме тех, кто сам постоянно экспериментирует. И тех, кто на них подписан

Бэкенд без бэкенда (для нетехнарей)

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

У них нет своего бэкенда и даже n8n они не используют. Все что они делают, это создают Ассистента в личном кабинете разработчика openai, и скидывают его IDшник в какую-то UI обертку.

Это круто, потому что помогает дойти до бизнес-ценности с минимальными техническими затратами (то, за что я часто борюсь и в себе, и в компаниях, с которыми работаю)

Но при таком подходе есть серьезные ограничения. Самое банальное – недавно наткнулись на то, что ассистент не знает дня недели, а это важно для бизнес-процесса.

Классическое решение – дернуть на бэкенде datetime.now() и подставить в системный промпт (так же делают и openai со своим chatgpt).

Но у нас нет бэкенда, что делать?

Для таких ситуаций есть расширения – tools. Они дают LLMке получить информацию извне.

Это работает так:

Вместо текста ответа, она в специальном формате пишет одну из трех штук:

* "я хочу сейчас сделать вот такой запрос к вот этому внешнему сервису"
* "я хочу запустить вот такой код"
* "я хочу сделать семантический поиск текста по файлам, которые мне дали"

После этого, внешний для LLMки детерминированный скрипт выполняет ее желание и подсовывает ей результат. LLMКа запускается заново, но уже с новой инфой – например, результатом выполнения кода или данными о погоде.

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

———

Это супер простой кейс, но сам паттерн очень мощный – т.к. можно писать любой код, это делает возможности ассистентов практически неограниченными даже для совсем нетехнических пользователей. Можно даже попросить GPT сделать запросы к Google Gemini, хаха

Завожу новую рубрику #залайканные_комменты

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

Буду выкладывать их и тут, чтобы делиться тем, чему учусь, не только с читателями этих каналов и чатов, но и с вами 🤗

Например, вот коммент к посту про использование MCP серверов.

Просто можно поделить системы на два типа:

1. Клиентские универсальные агенты, которые могут в широкий набор изначально неизвестных действий. Работают с human-in-the-loop, который накидывает задачи и валидирует и корректирует результаты

Примеры: computer use, cursor agent, chatgpt

2. Узконаправленные production пайплайны, заточенные на конкретный бизнес процесс с ограниченным количеством возможных веток поведения и поэтому нормально тестируемые.

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

———

Первый всегда будет работать хуже второго, но будет дешевле и быстрее сделать за счет универсальности базовой системы. Вот там и будут нужны MCP.

Во втором типе MCP вредны. На моей практике, пайплайны лучше делать через structured output, задизайненный под конкретный шаг пайплайна, и всякие паттерны типа роутер, для того чтобы эти шаги определять.

Контекс: MCP сервера позволяют подключать в LLM внешние инструменты и модель сама решает в какой момент ими пользоваться.

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

Уже писал про важность работы с PDF как основным источником актуальных знаний.

Недавно была волна постов про новый отчет Mery Meeker. Раньше она делала ежегодный Internet Report – анализ всей интернет экономики, наверное, один из самых известных и уважаемых в венчурном мире. В этот раз репорт называется Trends – AI

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

Про выбор идеи для создания продуктов:

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

Конкурируйте за счет отраслевой экспертизы и скорости интеграции

Хотя горизонтальные платформы (вроде ChatGPT) на слуху, немедленное, высокоценное внедрение в корпоративном секторе часто происходит в вертикально-специфичных ИИ-решениях, которые понимают отраслевой язык, рабочие процессы и требования соответствия

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

Про ИИ-интеграции

У предприятий огромные объемы данных, но они часто разрознены, неструктурированы или не «готовы к ИИ».

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

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

Общие штуки:

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

Классика, когда сливают бюджет на AI там где он не нужен, просто чтобы том-менеджменту отчитаться что компания в тренде

CEO NVIDIA: «вы потеряете работу не из-за ИИ, а из-за того, кто использует ИИ» (стр. 336)

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

особенно актуально для 2,6 млрд человек, которые еще не подключены к интернету и могут сразу начать использовать ИИ-интерфейсы

Тут мне понравилась мысль, что есть огромный рынок, который "не испорчен" UXом "старого" интернета и под них можно запускать такие продукты, на которые не нужно будет переучивать. Вижу тут возможность про продукты для детей, которые только начинают знакомиться с диджитал миром. Хочется верить образовательные, но в реальности ждем таймкиллеры 🥴

И немного реализма в AI-hypetrain:

При этом, реальное использование ИИ в производстве товаров/услуг в США все еще относительно невысоко (~7% компаний в Q1:25, стр. 328-329).

Рост вакансий в области ИИ, заявления CEO о том, что ИИ создаст новые рабочие места и повысит производительность (стр. 325-327, 331-336). Одновременно — признание, что «каждая работа будет затронута» и некоторые рабочие места будут потеряны

...приведет ли это к значительному росту неравенства, если выгоды от ИИ сконцентрируются у владельцев капитала и высококвалифицированных специалистов, способных работать с ИИ?

Растущее энергопотребление дата-центров, особенно ИИ-ориентированных (стр. 124-128). США потребляют 45% мировой электроэнергии дата-центров. Сможет ли технологический прогресс в энергоэффективности компенсировать экспоненциальный рост спроса на вычисления?

Пум-пум-пум

———

Оригинальный репорт – первым комментом

Лайфхак про видео

Проблема фокуса и лайфхак

Если вы используете AI в работе, то точно сталкивались с ситуацией, когда даете задание LLMке, пока ждете результата переключаетесь на другую задачу, а про первую вспоминаете спустя пол часа (в лучшем случае).

У меня бывает доходит до абсурда – я переключаюсь между задачами по нескольким проектам, играя роль оркестратора. В этот момент чувствую себя СДВГшником, и от постоянной смены контекстов очень устаю. А сидеть и пялиться в монитор несколько минут в ожидании задачи – невыносимо.

Как решить эту проблему я пока не понял, но зато понятно как решать проблему с возвратом фокуса – нотификашки.

Например, я постоянно использую копеечный Perplexity с deepresearch для сбора инфы из интернета, а иногда и их новый Perplexity Lab, чтобы делать простые веб прототипы. И теперь мне приходит уведомление, когда новая задача выполнена.

Но так как я не только разраб, который использует AI, но и разраб самих AI решений, то часто мне нужно ждать, пока обработаются все тестовые запросы внутри системы, которую разрабатываю, и можно будет посмотреть на метрики (помним, что evaluation is a king сейчас – нормальный evaluation пайплайн – ключевое отличие здорового процесса разработки AI систем).

Обычно я все эксперименты делаю в jupyter ноутбуках (внутри cursor), чтобы перезапускать отдельные шаги и быстро визуализировать что угодно. Запустил ячейку с экспериментом, пошел смотреть на результаты прошлого шага и формировать изменения для следующего.

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

На маке вот так:

subprocess.run([
    'osascript', '-e',
    'display notification with title "Task Complete" subtitle "ProjectX" sound name "Glass"'
]);

А так можно произнести любой текст

os.system('say "My lord, your data has been prepared!"')

Работа стала и эффективнее и веселее

P.s. это все на стороне сервера => если вы через подключаетесь к удаленной машине, то работать не будет.

Upd: в комментах @YakovLitvin версию для винды принес, спасибо ему

Проектный менеджмент в AI и личный опыт

"В AI использовать классический айтишный проектный менеджмент – стрелять себе в ногу" – нарратив, которую я все чаще слышу от опытных ИИ интеграторов. Дальше – почему я согласен и как сам строю процесс

Дело в том, что в разработке AI решений гораздо больше неопределенности. Разработать сайт – достаточно предсказуемая штука. Да, там вылезет что-то, чего не было в тз или ошибки проектирования не позволят добавить "очень нужную функцию", которая понадобилась заказчику.

Но с AI системами все по-другому. Это в самой своей сути всегда немного исследовательский проект. Получится ли добиться нужной точности? А если другую архитектуру попробовать? А другую модель? А если форматирование данных с json поменять на xml? А что если ошибки не в поведении системы, а в самой разметке тестовых данных? А как это понять?

Это все – набор экспериментов. Результатом является не разработанная система, а проверенные гипотезы + выводы. Все как в науке => проектный менеджмент нужен похожий скорее на академический, чем на айтишный.

Но заказчику нужны не выводы, а рабочий продукт. Как быть?

Я свои заказы практически всегда делю на два ключевых этапа: исследовательский и интеграционный

Исследовательский

* Цель – проверить гипотезы и разработать LLM-core часть.

* Заказчик на вход дает примеры данных, с которыми система работает:
* Набор документов для извлечения данных
* Аудиозаписи для транскрибации
* Переписку продажников, которую хотим анализировать на ошибки

* В идеале получить еще разметку – ожидаемые результаты. Это может быть то, какой результат сейчас получают вручную

* На выходе тоже данные – результаты работы системы. И если есть разметка, то еще и сравнение с ней – где совпадает, а где нет (высший пилотаж, если даем еще и анализ почему)

* Никакой рабочей системы, продакшена и интерфейсов. Данные на вход, данные и метрики на выход,

* Если результаты исследования устраивают – идем дальше

Интеграционный

* Цель – обернуть llm-систему в сервис/приложение и интегрировать в существующие процессы.

* Я стараюсь вынести требования к прайваси именно сюда, чтобы они не тормозили на первом этапе. Тут уже может быть и разворачивание инфраструктуры в своем контуре, и работа с локальными моделями, и переезд в Azure вместо обычного OpenAI API.

* Много погружения в существующие процессы или код для бесшовной интеграции. Для примера, на текущем проекте идем в два этапа:
* Сначала внутренний сервис, который сотрудники используют под своим контролем – вручную детектим проблемы, которые не видели на тестовых данных.
* А когда основные edge-кейсы обработаны, выносим в самостоятельный сервис без участия человека.

* Настраиваем мониторинги, деплой, A/B тесты, ретраи с exponential backoff, фоллбэки на других провайдеров для надежности. Короче, продакшн

* По большей части обычная айтишная разработка.

———

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

Заказчик экономит время и деньги, а я – сохраняю репутацию (чтобы не было "вон столько денег потратили, а пользоваться не возможно").

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

И люди просто отказывались делать такие обновления. Да, в идеале оно все абстрагировано друг от друга. Но в реальности я такого не видел 🤷‍♂️

Кстати, бонус: если на исследовательском этапе метрики не устраивают, не обязательно отказываться от дальнейшей разработки. Можно менять подход к интеграции в сторону "копайлота". Работает AI + человек, который следит за ошибками и направляет систему, работая за целую команду.

Этот вроде простой подход наработан "кровью и потом". Если знаете, кому этот пост может быть полезен, поделитесь с ними, вам будут благодарны. А я буду рад, если рефлексия над моими ошибками поможет кому-то избежать своих

Очень узкий лайхак, который сэкономил мне много часов

! Только для тех, кто разрабатывает свои AI системы

Пишу только потому что его нет в официальной документации, и мне самому было бы полезно узнать о нем откуда-то

Вводные:
1. Я сейчас активно использую Gemini в качестве поискового движка вместо эмбеддингов
2. Я работаю с PDFками
3. Я использую OpenAI-compatible API (тут гугл красавчики, конечно)
4. У OpenAI API нет поддержки пдфок

Короче, хочется и все плюшки OpenAI формата использовать, и при этом специфичные для гугла фичи, типа умения кушать PDF в обычном chat completion режиме.

Оказалось, есть незадокументированный способ это сделать. Используем методы OpenAI для загрузки изображений, но меняем image/png на appication/pdf. Всё!

messages = [
    {
        "role": "user",
        "content": [
            {
                "type": "text",
                "text": prompt,
            },
            {
                "type": "image_url",
                "image_url": {"url": f"data:application/pdf;base64,{base64_file}"},
            },
        ],
    },
]

P.s. помним, что google читает пдфки с потерями (на вход идет раза в три меньше токенов, чем если грузить пдфку текстом). Для надежности лучше перегнать пдфки в текст, например в markdown через MarkerPDF и сравнить метрики двух подходов. На многих задачах оказывается, что достаточно отправлять PDF напрямую (+ в комментах потестили)

Понял, что даже примерно не знаю имплементацию обработки pdf у гугла. Есть ли там OCR? А текст, который прям текстом в pdf лежит, он сохраняет текстом или как картинку читает? Отправил Perplexity рисерчить за меня (внизу русская версия).

Из интересного:

1. Все страницы обрабатываются как картинки (не ожидал, я думал, хотя бы часть текста передается как текст)
2. Каждая страница кодируется 258 токенами вне зависимости от плотности инфы (значит, страницы с очень плотной инфой будут разбираться с ошибками)

Вывод – берем самые плотные страницы из данных с которыми работаем и бенчмаркаемся на них, прежде чем использовать нативную поддержку pdf в google gemini

P.s. а еще это значит, что если будет проблема со сломанными шрифтами (а в реальности такое бывает), то gemini сможет прочитать такой файл, об который текстовый пайплайн сломается (пример в комментах).

Привет!

Я Коля и этот канал – такая же смесь разных штук, как и я сам. Прошел путь от хардкорных оптимизаций на C++ до ML инжиниринга и управления продуктом, чтобы в 2023 уйти строить "my own software company".

По пути пожил на 4х континентах, несколько лет преподавал в университе (придумав забавную систему, которую студенты назвали "коля-коинами"), 4 месяца покатался по Западной Африке автостопом, занимался сценической импровизацией и переговорными чемпионатами, сжал все свои вещи до 35л рюкзака.

↑ Это я рассказываю, чтобы за аватаркой канала было немного реального человека со своими "приколами"

Сейчас строю свои микро-продукты (тут скоро будет ссылка на пост с провалами), веду консультации и делаю ИИ интеграции для чужого бизнеса (часто вообще не айтишного – выше ценность). Обычно хвастаюсь, что начал внедрять GPT-3 в существующий бизнес еще до выхода ChatGPT в 2023м.

Делюсь тем, что узнаю по пути. Стараюсь писать про практический опыт, ошибки и личное мнение – то, что нельзя вытащить LLMкой из новостной ленты.

Все лучшие посты тут, а вот три моих любимых:

Инсайты из чатов. как выкачать и проанализировать любую переписку

Вайб-кодинг без вайб-кодинга. Мой подход к разработке с AI спустя 2,5 года

Как я перестал откладывать

Записаться на консультацию:

@nikolay_sheyko

Подборка всех лучших постов (обновляется)

Для всех:

Инсайты из чатов. как выкачать и проанализировать любую переписку

Транскрибация и саммари звонков здорового человека

Как получилось, что юристы используют среду для разработчиков?

Универсальный взлом LLM и чем это грозит бизнесу

Самообман LLMками

Про разработку AI систем

Structured output, почему это база и как это использовать

Главная проблема GPT – не экспертиза, а контекст. И вот как её решить

Проектный менеджмент в AI и личный опыт: почему айтишные подходы – зло

Инсайты из моего эфира про context engineering у Влада NGI

Эмбеддинги сосут

Про разработку с AI тулами:

Вайб-кодинг без вайб-кодинга. Мой подход к разработке с AI спустя 2,5 года

Мой топ постов из других каналов о разработке с AI инструментами

Как хостить свои поделки, не превращаясь в девопса

Как дизайнить собесы под использование ИИ

Личное:

Выбирать скуку

Как я перестал откладывать: магия «задач-черновиков»

Быть фаундером стартапа – плохой способ заниматься инновациями

Что использовать для evaluation или как я очень удивился

Тут Ринат отлично объясняет зачем нужен evaluation в AI продуктах – нормально построенный механизм проверки качества позволяет избежать таких ситуаций:

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

Про это в целом давно все говорят (см выше скрин твиттера президента OpenAI от 2023), но про реализацию на практике – почти ничего не вижу. Значит надо писать.

Я строил eval пайплайны для LLMок еще в конце 22го, до выхода chatgpt, продолжаю строить их и сейчас для клиентских проектов. Обычно я даже не начинаю работать над проектом, пока нет данных, и не начинаю разрабатывать саму LLM-систему, пока не сделал систему проверки качества.

По сути есть два основных варианта, как делать:

1. Писать полностью свой кастомный код конкретно под задачу
2. Использовать какие-то готовые инструменты типа OpenAI Evals, который уже встречался тут

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

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

2. Нужно настраивать визуализацию. С разными отображениями. Сравнение ключевых метрик между экспериментами. Табличка по конкретному эксперименту. Фильтрации по каким-нибудь подмножествам. Графики.

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

———

Я полез смотреть, что сейчас есть на рынке и ужаснулся. Расплодилось очень много модных инструментов для LLM-evaluation. Они все позволяют достаточно гибко настраивать проверку по каждому отдельному объекту (см картинку OpenAI Evals), но при этом суммарная метрика по всем объектам из датасета – это всегда просто усреднение. То есть – тупо accuracy. Я напишу отдельный пост, почему это почти всегда плохая метрика, а сейчас важен сам факт:

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

P.s. а ко мне пришли с задачей multi-label классификации, и мы хотим f-score с увеличенным весом recall

Я не понимаю, почему так, если честно. Видимо, рынок evals еще в очень незрелом состоянии. Или просто все, кто разбирается в ML метриках, тоже идут по первому пути и считают все сами.

Итог

Справедливости ради, я все-таки нашел инструмент, где можно самому задавать общую метрику – это wandb.com, который исторически как раз был инструментом для классических ML и DS, но запустил у себя новый продукт weave для LLM evals.

Это прям рекомендация, особенно на python. На js/ts нужного функционала сильно меньше – там f-score уже не получится сделать.

А вы на какой стороне?

❤️ – использовать готовые инструменты
👍 – кастомить под задачу
😈 – еvals не нужны, просто вручную смотришь, что норм работает

Самые частые микро-советы с консультаций:

XML > json (для данных)

XML sections > Markdown headers (для промптов в целом)

Gemini flesh lite > Embeddings search

Gemini > whisper

Порядок экспериментов:
1. Без ризонинга 2. Общий ризонинг 3. Кастомный ризонинг

Кастомный ризонинг делать через поля в structured_output. 1 поле – 1 шаг.

Бейзлайн решение на закрытой мощной дорогой модели – верхняя оценка возможностей. Релевантно, даже если решение нужно делать на открытых моделях

Ваншот запрос (с интерактивным редактированием и перезапуском) > чат с кучей коррекционных сообщений

"Before start, ask questions to clarify what remains unclear/ambiguous. Then wait for my response, then proceed with the initial task"

AI делает опытных разработчиков менее продуктивными

Нашумевшая статья, про то, что использование ИИ снижает эффективность разработки. А самое интересное, что участники исследования думают, что производительность только увеличилась. Шах и мат, ИИ-энтузиасты.

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

У этой статьи сразу несколько серьезных проблем:

1. Выборка всего из 16 участников. 16, КАРЛ.

2. Пишут, что было 250 задач. Но если вчитаться, оказывается, что это не на участника, а всего. То есть 16 участников по 16 задач. Если посмотреть на графики в аппендиксе, то видно, что у результатов нет статзначимости 🤥

3. Никто из них не имел серьезного опыта с ИИ-инструментами для разработки. Кривая входа в больших проектах в кодинг с ИИ – очень крутая. Это лендос на lovable собрать за выходные может любой дизайнер/продакт. Но большой проект – это всегда сложная инженерия с кучей нюансов

4. Результаты оценивали в среднем, хотя в контексте предыдущего пункта полезнее всего смотреть на верхней перцентиль – на сколько увеличилась эффективность эффективность у тех, у кого получилось найти эффективные паттерны использования.

———

Удивительно (нет), но у 4 разработчиков эффективность выросла (у двух – почти x2), причем лучший результат был у того, кто уже немного пользовался Cursor до эксперимента. Что только подтверждает связь между умением пользоваться инструментом и производительностью (вау?).

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

Кстати, если хотите провести такое обучение у себя в компании, напишите мне, хочу пилот сделать.

Ну а у авторов статьи получилось красиво хайпануть, еще и нигде не скрывать инфу (СМИ все равно сами вытащат "нужное"). Кстати, очень похожим образом в свое время получилось хайпануть у DeepSeek. Остается только учиться

Кстати, Влад из комментов к посту выше позвал меня на эфир в понедельник (21.07 в 19:00).

Будем разбираться, что за новый хайповый термин Context Engineer, чем это отличается от ушедшего в небытие Prompt Engineer. А самое главное, зачем управление контекстом нужно всем, кто много использует ИИ и как избежать основные грабли.

Кодить уметь не нужно. Целевая аудитория – все активные пользователи ИИ. Бонусом будет мини воркшоп от меня, как без программирования делать динамические сборщики контекста.

Чтобы не пропустить, можно добавить ивент в календарик тут

Ссылка на эфир: https://t.me/NGI_ru?livestream

UPD: https://meet.google.com/pac-uetx-vja

Неделю назад я был на эфире у Влада про Context Engineering. Наконец у меня дошли руки выписать несколько мини-тейков, чтобы не смотреть все два часа (некоторые достаточно противоречивые, как мы любим):

* Контекст-инжиниринг – часть промпт-инжиниринга. Просто теперь все важнее не только правильно собирать слова в инструкции, но и подтягивать релевантные данные извне.

Примеры:
* Дамп дневника → понимает личный контекст → лучше ответы на вопросы про отношения или зоны личностного роста, ошибки мышления
* Информация с созвонов компании → точнее ответы на бизнес вопросы
* Выгрузка тг канала → перенимает стиль текста и зоны фокуса при анализе инфы
* Документация → корректное использование библиотек (кстати, context7 MCP, кто еще не)

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

На техническом уровне это объясняется слабым навыком моделей фильтровать неважную часть контекста – "если в условиях это зачем-то дано, значит, мне нужно это как-то использовать"

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

* Другой полезный паттерн – стараться решить задачу в один-два запроса вместо того, чтобы бесконечно корректировать в режиме долгого диалога. То есть, если не получается, то менять исходный запрос, а не писать новые сообщения-корректировки.

Спекулятивное объяснение: в режиме диалога каждая фраза юзера – отдельная инструкция и модели сложно собрать их в одну непротиворечивую, да еще и не зацикливаться на подтверждении своих прошлых ответов.

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

* Просите модель собрать для вас инструменты для сбора данных. На эфире мы попробовали два способа, актуальных для неразработчиков (не требуют деплоя):
1. Самодостаточный html файл, который открывается в любом браузере
2. JS код, который вставляем в браузерную консоль.

* Есть еще варианты всяких агентов, где деплой уже настроен (Lovable, Perplexity Labs, Manus, Google Apps) или вообще ChatGPT Interpreter, который сам напишет код, сам его запустит.