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

«идеальный» пример. Важно, чтобы он показывал формат и метки, а содержание может быть приближённым. Второе: если corner-case действительно сложный и метки в нём нестандартные, few-shot на нём поднимет качество. Но если corner-case стандартный — лучше потратить время на хорошие инструкции, а не на «идеальный» пример.

Примеры — это формат, не истина.

БЛОК «ИСТОРИЯ»: ПАМЯТЬ ДИАЛОГА

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

БЛОК «ЗАДАЧА»: СУТЬ ЗАПРОСА

Задача — это «что конкретно нужно сделать прямо сейчас». Формулировка должна быть одна, ясная, измеримая. Плохо: «сделай с этим что-нибудь полезное». Хорошо: «Извлеки из письма клиента имя, компанию, ИНН, сумму задолженности и срок оплаты. Верни в формате JSON с полями name, company, inn, amount, due_date». Разница — в проверяемости. Первую формулировку нельзя проверить: что значит «полезное»? Вторую — можно, прогнав на 10 письмах и сверив с эталоном.

Задача без измеримости — это пожелание, а не инструкция.

БЛОК «РАССУЖДЕНИЕ»: ПОШАГОВЫЙ CHAIN-OF-THOUGHT

Для сложных задач блок рассуждения заставляет модель сначала пройти по логической цепочке, а потом выдать ответ. Просьба «давайте думать по шагам» (в оригинале Wei et al. 2022: «let’s think step by step») поднимала качество на арифметических и логических задачах в 2022 году.

В 2026 году это уже шум для reasoning-моделей — мы разобрали это в подразделе про сдвиги в рекомендациях и ещё вернёмся к этому в разделе про CoT. Но если вы работаете со старой моделью или с задачей, где рассуждение нужно «показать» для аудита, явная инструкция вроде «перед ответом перечисли 3 ключевых риска, потом дай рекомендацию» остаётся полезной.

БЛОК «ФОРМАТ»: ФОРМА ОТВЕТА

Формат — это «в каком виде вернуть результат». Markdown с заголовками, JSON, таблица, проза, список — каждая задача требует своего. Если формат не зафиксирован, модель выбирает сама, и от запроса к запросу формат «плавает». Это причина, почему автоматический парсинг ответов ломается: разработчик рассчитывал на JSON, а модель выдала прозу с JSON-блоком внутри.

OpenAI предлагает для борьбы с этим два уровня. JSON-режим (JSON mode): модель обязана вернуть валидный JSON, но структура не фиксирована. Структурированный вывод (Structured Outputs): модель обязана вернуть JSON, точно соответствующий предоставленной JSON-схеме. Разница в надёжности: JSON-режим даёт валидный JSON в большинстве случаев, но структура может плавать. Структурированный вывод почти всегда совпадает со схемой — модель физически не может вернуть JSON с другими полями.

Anthropic идёт другим путём: рекомендует XML-теги и предзаполнение — задать начало ответа и позволить модели дописать остальное. Google Gemini предлагает responseSchema — аналог Structured Outputs от OpenAI.

БЛОК «ПРЕДЗАПОЛНЕНИЕ»: PREFILL В ПЕРВОМ ТОКЕНЕ

Предзаполнение — это техника, при которой вы заранее пишете первые несколько слов или символов ответа модели, и она вынуждена продолжить именно с этой точки. Если в API-запросе (программном вызове к модели) вы поставите в сообщении ассистента <final_verdict>, модель не сможет начать с приветствия или объяснения — она продолжит после тега и выдаст чистый вердикт.

В Opus 4.6 в феврале 2026 эту возможность убрали, и одно это показывает, насколько серьёзно индустрия относится к управлению форматом вывода. Anthropic в руководстве по миграции рекомендует переходить на Structured Outputs, системные промпты или параметр output_config.format — настройку формата ответа на уровне API. Практический вывод: если вы строите пайплайн «чат → парсер JSON → CRM», можно либо пользоваться Structured Outputs (если у вас enterprise-доступ и схема описана заранее), либо комбинировать prefill + JSON mode + пост-валидацию.

На июнь 2026 года prefill — устаревающий приём. В новых кодовых базах его лучше не закладывать.

ПРОПУЩЕННЫЙ БЛОК: ПРЕДСКАЗУЕМЫЙ СИМПТОМ В ОТВЕТЕ

Каждый блок в системном промпте закрывает конкретный класс сбоев. Отсутствие блока даёт предсказуемый симптом.

Нет блока «Контекст» — модель отвечает «общим голосом», без доменной специфики. В юридическом вопросе она звучит как учебник для первокурсника, а не как практикующий юрист. Нет блока «Тон» — модель отвечает развёрнуто, когда нужна одна строка, или наоборот. Нет блока «Фон» — модель путает формат полей, называет «дату заключения» там, где в исходнике «дата вступления в силу». Нет блока «Инструкции» — модель сваливает всё в один ответ, и непонятно, что было сделано, а что пропущено. Нет блока «Примеры» — на corner-case модель ошибается в каждом третьем случае, даже если базовые случаи отрабатывает идеально. Нет блока «Формат» — модель отвечает прозой, а вам нужен JSON для дашборда. Нет блока «Предзаполнение» — модель пишет вступление «Конечно, вот ваш ответ…», которое ломает парсер и добавляет секунды к обработке.

Когда результат «плывёт» в конкретном месте, ищите, какой блок пустует. Диагноз ставится по симптому.

ОБЯЗАТЕЛЬНЫЕ БЛОКИ И ТЕ, БЕЗ КОТОРЫХ МОЖНО ОБОЙТИСЬ

Эти симптомы объясняют, почему для офисной задачи обязательны пять блоков: контекст (роль), тон, инструкции, задача, формат. Эти пять закрывают около 80% сценариев. Блок «фон» нужен часто: если у вас стабильная структура данных, описание один раз кешируется и сокращает расходы. Блок «примеры» нужен для пограничных случаев — это мы ещё отдельно разберём в разделе про few-shot. Блоки «история», «рассуждение» и «предзаполнение» подключаются по ситуации: история нужна в длинном диалоге, рассуждение для сложной задачи, prefill если работаете со старой моделью или не хотите заводить полноценный pipeline валидации по схеме.

Anthropic, OpenAI и Google сходятся в одном: если вы не указали формат явно, модель выберет сама, и в 30–60% случаев выберет не то, что нужно. Это правило работает и в обратную сторону: если вы указали формат и не указали задачу, модель выдаст правильно отформатированную пустоту.

Системный промпт — это фундамент дома. Вы не видите его после постройки, но если он кривой, дом перекашивается. Можно поставить хорошие стены, окна, двери — но если фундамент поехал, всё напрасно.

Хороший системный промпт не бросается в глаза. Он просто делает каждый последующий ответ стабильным. Плохой заметен сразу: то модель «плывёт» по тону, то забывает формат, то выдаёт «Конечно!» перед сутью. Если вам приходится в каждом запросе заново объяснять «не пиши вступление, отвечай в JSON, не выдумывай», — проблема не в запросе, а в системном промпте. Эти правила должны жить там, а не в каждом пользовательском