Главное про AI - Вадим Жартун

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

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

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

Иначе не выйти на результат, который можно отправить клиенту без второго круга правок.

НОРМА ИТЕРАЦИЙ: ЦИФРЫ ИЗ ПРАКТИКИ

Цифры по количеству итераций разные, и почти все авторы сходятся в диапазоне от 5 до 15 для не-инженерных задач. Исследовательская работа «From Tool to Teammate: LLM Coding Agents as Collaborative Systems» (arXiv, март 2026) зафиксировала, что для выхода на стабильное качество разметки требуется от 8 до 12 итераций на одну настройку шаблона. Методология PIV (Plan-Implement-Validate) от MindStudio формулирует жёстче: для чётко поставленной, ограниченной задачи типично одна-две итерации, три и больше обычно означают, что шаг планирования был неверным. В среднем нормальная рабочая настройка требует серии итераций, а одна-две — случай тривиальной задачи с готовым шаблоном. Практический отчёт Alibaba Cloud «From ReAct to Ralph Loop» (январь 2026) разбивает итерации по размеру задачи: маленькие задачи — 5–10 итераций, средние — 20–30, большие — больше. Для офисного работника это даёт конкретную разметку: на письмо клиенту 3–5 итераций, на проверку рисков в договоре 5–8, на построение нового шаблона для отдела 10–15. Эти цифры — не проклятие LLM (большой языковой модели). Это нормальный объём работы по отладке любой новой процедуры. Разница в том, что у LLM итерация занимает секунды, а у живого подрядчика — дни.

РАБОЧИЙ ЦИКЛ «НАПИСАЛ — ПРОВЕРИЛ — ПОПРАВИЛ»

Зная ожидаемый объём итераций, полезно понимать, как они устроены изнутри.

Anthropic в инженерном блоге «Effective context engineering for AI agents» (сентябрь 2025) разбирает цикл оптимизации промпта до уровня конкретных шагов. Шаг первый — сформулировать критерии успеха в измеримом виде: не «ответ должен быть хорошим», а «в 95 из 100 тестовых запросов модель возвращает JSON с заполненными полями a, b, c». Шаг второй — собрать минимальный репрезентативный набор тестов, лучше всего из реальных примеров, на которых раньше обжигались. Шаг третий — взять минимальный промпт и самую сильную модель, прогнать тестовый набор, зафиксировать, на каких именно примерах результат не сошёлся с критерием. Шаг четвёртый — менять по одной переменной за раз: либо формулировку роли, либо порядок шагов, либо формат вывода, — снова прогонять, фиксировать.

Шаг пятый — после стабилизации базового результата добавлять ограничители: правила на случай нехватки данных, примеры из обучающей выборки на corner-cases (редкие пограничные случаи, на которых модель обычно спотыкается), ограничение формата. Это инженерная дисциплина, и она применима к офисной задаче напрямую. Вместо «тестового набора» — папка из десяти прошлых писем клиентам, на которых вы обожглись. Вместо «JSON-валидации» — галочка в чек-листе рисков договора.

Цикл нужен не для того, чтобы «подбирать слова». Цикл нужен, чтобы превратить свой опыт в инструкцию, которая стабильно даёт нужный результат.

ЧАСТЫЙ ПРОВАЛ: ДОПИСЫВАТЬ ПРАВИЛА ВМЕСТО СМЕНЫ ПОРЯДКА

Стратегия «напишу подлиннее и добавлю побольше правил» — распространённый провал, особенно когда проблема на самом деле в порядке шагов. Здесь важно зафиксировать эмпирическое подтверждение из сторонних гайдов: добавление новой инструкции в середину системного промпта сдвигает акценты модели, и старые правила теряют силу.

Один мой клиент, юрист по корпоративным спорам, в какой-то момент собрал 14 правил в системный промпт своего AI-ассистента. Стало хуже, не лучше. Когда я попросил его убрать всё, кроме трёх ключевых правил, и переставить их в нужном порядке — «сначала определи тип документа, потом вытащи обязательные реквизиты, потом сформируй вывод» — точность по тестовой выборке из 20 договоров поднялась с 38% до 71%.

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

ЭВОЛЮЦИЯ РЕКОМЕНДАЦИЙ ANTHROPIC И OPENAI ЗА ДВА ГОДА

Правила игры в промпт-инжиниринге заметно сдвинулись с 2024 по 2026 год: часть «классических» советов теперь работает хуже, часть новых стала обязательной. Я держу в голове пять ключевых сдвигов, и они видны в официальных гайдах обеих компаний.

– Цепочка рассуждений по запросу больше не нужна для reasoning-моделей. В 2022 году Wei и соавторы показали, что просьба «давайте думать по шагам» поднимает качество на арифметических задачах — в оригинале по Wei et al. 2022: «let’s think step by step». В 2026 году Anthropic Opus 4.7+, OpenAI o3 и GPT-5, Google Gemini 3 умеют «рассуждать» сами. Параметр reasoning_effort (у OpenAI) или effort (у Anthropic: low, medium, high, xhigh, max) или thinking_level (у Google) заменяет ручную просьбу. Просить модель «давай по шагам» — избыточный шум. Подробнее об этом мы поговорим в блоке «Рассуждение».

– Структурные теги вместо голого текста. Anthropic в Claude Prompting Best Practices рекомендует оборачивать примеры и инструкции в XML-подобные теги — формат разметки, похожий на HTML: открывающий тег, содержимое, закрывающий тег, — выделяя блоки «пример» и «инструкция». Google Gemini идёт тем же путём. Это не косметика: теги помогают модели отделять блоки и не «размывать» их друг в друга, особенно в длинных системных промптах.

– Длина промпта перестала быть проблемой. Старая школа говорила: «чем короче — тем лучше». В 2026 году это не так. Модели с контекстом 200K (Claude 4.x, GPT-5) и до 1M (Claude 4.8) спокойно держат большие системные промпты. Вопрос теперь не «укладывается ли в 4K токенов», а «не конкурируют ли инструкции в системном промпте друг с другом за внимание». Shopify, про которую я ещё скажу в этой главе, на масштабе 50+ инструментов упёрлась не в длину, а в то, что каждая новая правка ломает поведение в неожиданном месте.

– Примеры по-прежнему помогают, но меньше, чем раньше. Исследование Min и соавторов (EMNLP 2022) показало, что для reasoning-моделей few-shot (подача нескольких