Явные требования бьют красивую структуру: полнота описания важнее формата подачи задач LLM

Задача: Вы хотите, чтобы LLM по единым правилам оценивала резюме кандидатов на вакансию в вашей компании и выдавала решение — звать на интервью или нет. Нужно, чтобы разные промпты давали одинаковый результат, без случайных отклонений.

Промпт:

Ты — рекрутинговый ассистент. Оцени резюме кандидата по следующим правилам:

функция: оценка_кандидата
цель: vынести решение — «Приглашаем» или «Отказ»

входные данные:
  резюме: текст резюме кандидата
  вакансия: название должности и требования

обязательные критерии:
  - опыт: минимум 2 года в релевантной области
  - образование: высшее или незаконченное высшее
  - город: Москва или готовность к переезду

шаги оценки:
  1. Проверь каждый обязательный критерий
  2. Если хотя бы один обязательный критерий не выполнен — решение «Отказ»
  3. Если все обязательные критерии выполнены — посчитай дополнительные баллы:
     - Опыт от 5 лет: +2 балла
     - Знание английского B2+: +1 балл
     - Наличие кейсов или портфолио: +1 балл
  4. При равном счёте у нескольких кандидатов — приоритет тому, у кого больше лет опыта
  5. Если опыт тоже равен — приоритет кандидату с более поздней датой последнего места работы

поведение в граничных случаях:
  - Опыт не указан: считать как 0 лет
  - Город не указан: считать как «неизвестно», применить правило отказа
  - Резюме пустое или нечитаемое: вернуть «Невозможно оценить — нужно больше данных»

формат вывода:
  Решение: [Приглашаем / Отказ / Невозможно оценить]
  Баллы: [число]
  Причина: [1-2 предложения]

Вот резюме:
[ВСТАВЬТЕ РЕЗЮМЕ]

Результат: Модель выдаст структурированный вердикт по каждому кандидату в едином формате. Главное — она будет стабильно обрабатывать граничные случаи: отсутствующий город, пустое поле опыта, одинаковый счёт у двух кандидатов. Без явных правил для этих случаев модель каждый раз угадывала бы по-своему, и результаты расходились бы от запуска к запуску.

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

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

Структурированные форматы (YAML, псевдокод) помогают вам не пропустить важные поля. Когда вы пишете ошибки: ... или граничные случаи: ... как явный раздел — это напоминание заполнить его. Проза такого напоминания не даёт — легко уйти в середину и забыть про хвосты.

Рычаги управления: - Добавить раздел граничные_случаи: → модель перестаёт угадывать при нестандартных входах - Добавить правила_разрешения_конфликтов: → убирает случайность при равных вариантах - Заменить прозу на YAML-структуру → когда не уверены что описали всё — структура подскажет пропущенные поля - Убрать явные правила → если нужно дать модели свободу интерпретации (креативные задачи)

функция: {название_задачи}
цель: {что должна вернуть}

входные данные:
  {поле_1}: {описание и тип}
  {поле_2}: {описание и тип}

шаги выполнения:
  1. {первый шаг}
  2. {второй шаг}
  3. {третий шаг}

правила при конфликтах:
  - Если {ситуация_А}: {что делать}
  - Если {ситуация_Б}: {что делать}

граничные случаи:
  - {поле} не указано: {как обработать}
  - {поле} пустое: {как обработать}
  - {невозможная ситуация}: {что вернуть}

формат вывода:
  {поле_результата}: [{варианты}]
  {пояснение}: {описание}

Вот входные данные:
{ваши_данные}

Что подставлять: - {название_задачи} — глагол + объект: оценка_заявки, классификация_отзыва, генерация_ответа - {правила_при_конфликтах} — самое важное: что делать когда два варианта равны, или условие частично выполнено - {граничные_случаи} — что делать с пустыми, нечитаемыми, нестандартными входами - {формат_вывода} — чем строже формат, тем стабильнее результат

🚀 Быстрый старт — вставь в чат:

Вот шаблон явной спецификации задачи. Адаптируй под мою задачу: {ваша задача}.
Задавай вопросы, чтобы заполнить все поля — особенно граничные случаи и правила при конфликтах.

[вставить шаблон выше]

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

⚠️ Только для задач с чёткими правилами: При субъективных или творческих задачах явная спецификация всех граничных случаев невозможна по природе — количество исключений бесконечно. Метод работает там, где «правильный ответ» в принципе можно описать правилами.

⚠️ Не компенсирует неполноту знаний: Если вы сами не знаете что делать в граничном случае — YAML-структура это не скроет, а обнажит. Модель либо спросит, либо угадает. Это плюс (пробел будет замечен), но нужно быть готовым к ответу.

⚠️ Слабые модели продолжают реагировать на формат: Для небольших или устаревших моделей формат по-прежнему важен даже при полном описании. Для сильных (GPT-4 уровня) формат уходит на второй план, когда всё прописано.

⚠️ Code stub — ловушка самодовольства: Если вы даёте только сигнатуру или заголовок («напиши функцию X, которая делает Y»), это хуже, чем полное описание прозой. Пустой каркас без правил даёт ложное ощущение структуры — а контент не передаёт.

Команда из Mizuho-DL Financial Technology взяла пять задач на реализацию алгоритмов машинного обучения — сортировка по топ-к, K-means, механизм внимания и другие — и написала каждую задачу в семи разных форматах: простая проза, LaTeX-псевдокод, Markdown-секции, YAML-подобная структура, JSON-подобная структура, Python-заглушка и псевдокод из PDF. Каждую версию скормили трём моделям (GPT-5.4 mini, Gemma 3 4B, Llama 3.2 3B) в 10 повторах — итого 4 020 сгенерированных реализаций.

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

Самое интересное: когда исследователи добавили в промпт полное описание (все числовые правила, поведение при ошибках, тай-брейкинг) — GPT-5.4 mini перестала замечать разницу между форматами вообще, 50 из 50 сравнений дали одинаковый результат. Gemma 3 4B и Llama 3.2 3B продолжили реагировать на формат даже при полном описании. Это важный сигнал: для сильных моделей формат — не принципиален, если контент полный. Для слабых — структура всё ещё помогает.

function: top_k_distribution
signature: "def top_k_distribution(logits, k, temperature=1.0):"
inputs:
  logits: nonempty one-dimensional NumPy array
  k: positive integer
  temperature: positive float
steps:
  - keep min(k, len(logits)) entries
  - break ties by smaller index
  - apply stable softmax to retained logits divided by temperature
output: probability vector with zero probability outside the retained entries
errors: raise ValueError for invalid logits, k, or temperature

Контекст: Исследователи так описали функцию распределения top-k для сравнения форматов. Та же задача писалась и прозой, и псевдокодом, и JSON-структурой. YAML-подобный формат показал второй результат после LaTeX-псевдокода при неполном описании — и исчезающую разницу при полном.

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

правила_приоритета:
  - Если два варианта равнозначны по критерию А: смотри критерий Б
  - Если и критерий Б равен: выбирай вариант с меньшим порядковым номером
  - Если правило определить невозможно: вернуть «требуется ручная проверка»

Напишите задачу в YAML-шаблоне и попросите LLM найти незаполненные поля:

Вот моя спецификация задачи в YAML-формате.
Найди все поля, где я не указал поведение в граничных случаях 
или правила разрешения конфликтов. Для каждого пробела задай 
уточняющий вопрос.

[ваш YAML-промпт]

LLM превращается в вашего рецензента: она видит структуру и указывает на незаполненные разделы. После ответов — дополняете спецификацию и запускаете основную задачу.

Название работы: Which Algorithm Specification Formats Help Language Models Implement Machine Learning Algorithms?

Авторы: Masahiro Kato (Data Analytics Department, Mizuho-DL Financial Technology; University of Tokyo), Taka Kato (NP-hard Inc.)

Связанные бенчмарки: PaperBench (Starace et al., 2025), ResearchCodeBench (Hua et al., 2025), SciReplicate-Bench (Xiang et al., 2025)

Дата: Июль 2026