TL;DR
NSVIF — фреймворк, который проверяет следует ли ответ LLM инструкции из промпта. Ключевая идея: разбить сложную инструкцию на мелкие требования (constraints), проверить каждое отдельно, объединить результаты через формальную логику. Метод различает логические требования (проверяемые объективно: количество слов, наличие ключевых фраз, структура) и семантические (субъективные: тон, тема, стиль).
LLM плохо проверяют комплексные инструкции напрямую. Когда в промпте 5-7 требований (формат + тон + ключевые слова + длина + структура), модель теряет фокус и пропускает нарушения. Попроси проверить "всё сразу" — модель скажет "всё ок", хотя половина требований не выполнена. В агентских workflows ошибки накапливаются от шага к шагу — если первый агент пропустил нарушение, следующий работает с битыми данными.
NSVIF использует три шага: (1) извлекает список требований из инструкции и связи между ними, (2) проверяет каждое требование отдельно — логические через код, семантические через LLM-промпт, (3) объединяет результаты и выдает вердикт с объяснением что именно нарушено и почему. Читатель может применить этот принцип мануально в чате — попросить LLM разбить инструкцию, проверить по пунктам, собрать результат.
Схема метода
ИССЛЕДОВАТЕЛЬСКАЯ РЕАЛИЗАЦИЯ (требует код):
ШАГ 1: Formulation Agent → список требований + логическая формула связей
ШАГ 2: Checking Agent → для каждого требования код проверки или LLM-промпт
ШАГ 3: Solver Agent → выполняет Z3 программу → итоговый вердикт + объяснение
АДАПТАЦИЯ ДЛЯ ЧАТА (мануальный workflow):
ШАГ 1: Попроси LLM извлечь требования из инструкции → список пунктов
ШАГ 2: Попроси проверить каждый пункт отдельно → вердикты по пунктам
ШАГ 3: Попроси объединить результаты → итоговый вывод + указание на нарушения
Исследовательская версия требует Python + Z3 solver + multi-agent system. Адаптация для чата — три последовательных запроса в одном диалоге.
Пример применения
Задача: SMM-менеджер получил от клиента бриф на пост про новый тариф интернет-провайдера. Инструкция сложная: тон дружелюбный но профессиональный, формат — 3 абзаца, обязательно упомянуть "безлимитный трафик" и "стабильное соединение", НЕ упоминать конкурентов, длина 80-100 слов, призыв к действию в конце. ChatGPT сгенерировал текст. Нужно проверить — всё ли выполнено?
Промпт (мануальный workflow в чате):
Шаг 1 — Извлеки требования:
Вот инструкция для текста:
[вставить бриф клиента]
Вот сгенерированный текст:
[вставить текст от LLM]
Извлеки из инструкции все требования списком. Раздели на:
- Логические (объективные: количество слов, структура, ключевые фразы)
- Семантические (субъективные: тон, стиль, тема)
Выдай нумерованный список всех требований.
---
Шаг 2 — Проверь каждое требование:
Теперь проверь текст по каждому требованию из списка.
Для каждого пункта выдай:
- Требование
- Выполнено / Не выполнено
- Объяснение (что проверил, почему такой вердикт)
Проверяй каждое требование независимо, не смешивай.
---
Шаг 3 — Итоговый вердикт:
На основе проверки всех требований выдай:
1. Итоговый результат: СООТВЕТСТВУЕТ / НЕ СООТВЕТСТВУЕТ инструкции
2. Список нарушенных требований (если есть)
3. Рекомендации по исправлению
Результат:
Модель выдаст три блока: 1. Список требований — 7-8 пунктов с разделением на логические и семантические 2. Проверка по пунктам — для каждого вердикт + объяснение (например: "Требование 4: упомянуть 'безлимитный трафик' — НЕ ВЫПОЛНЕНО. В тексте эта фраза отсутствует") 3. Итоговый вердикт — "НЕ СООТВЕТСТВУЕТ" + список из 2-3 нарушенных пунктов + что исправить
Вместо размытого "текст хороший" или "что-то не то" — конкретика по каждому требованию и точечные указания на проблемы.
Почему это работает
LLM теряет фокус на композиции требований. Когда в промпте 5-7 условий, модель пытается оценить "общее впечатление" и пропускает конкретные нарушения. Попроси проверить текст на соответствие сложному брифу — модель скажет "в целом соответствует", упустив что ключевая фраза не упомянута или длина превышена на 30 слов.
LLM хорошо проверяет одно простое требование. Спроси "есть ли в тексте слово X" — модель ответит точно. Спроси "какой тон текста" — модель даст внятную оценку. Проблема не в способности проверять, а в способности держать много требований одновременно.
Метод использует divide-and-conquer. Разбивает сложную задачу на серию простых: вместо "проверь 7 условий сразу" даём "проверь условие 1", "проверь условие 2" и так далее. Каждая проверка — в фокусе, результаты — точные. Финальная логика объединения ("все ДА → соответствует", "хотя бы одно НЕТ → не соответствует") тривиальна и не требует LLM.
Рычаги управления:
- Детализация разбиения — можешь объединить похожие требования ("все ключевые слова") или разбить детально ("каждое слово отдельно"). Детальнее → точнее, но дороже по токенам.
- Способ проверки — логические требования можешь проверить сам (посчитать слова, найти фразу Ctrl+F) без LLM вообще. Семантические — через LLM неизбежно.
- Строгость объединения — можешь установить "все требования обязательны" или "критичны только 3 из 7". Адаптируй логику под контекст.
Шаблон промпта
Проверь выполнение инструкции по шагам:
**ШАГ 1 — ИЗВЛЕЧЕНИЕ ТРЕБОВАНИЙ**
Инструкция: {твоя_инструкция}
Ответ LLM: {полученный_текст}
Извлеки из инструкции все требования списком. Раздели на:
- Логические (объективно проверяемые: длина, структура, ключевые слова, формат)
- Семантические (субъективные: тон, стиль, тема, настроение)
Выдай нумерованный список.
---
**ШАГ 2 — ПРОВЕРКА КАЖДОГО ТРЕБОВАНИЯ**
Проверь ответ по каждому требованию из списка отдельно.
Для каждого пункта выдай:
- Номер и формулировка требования
- Вердикт: ВЫПОЛНЕНО / НЕ ВЫПОЛНЕНО
- Объяснение: что конкретно проверил, какие данные учёл, почему такой вердикт
Проверяй требования независимо друг от друга. Не смешивай.
---
**ШАГ 3 — ИТОГОВЫЙ РЕЗУЛЬТАТ**
На основе проверки всех требований выдай:
1. Итоговый вердикт: СООТВЕТСТВУЕТ / НЕ СООТВЕТСТВУЕТ инструкции
2. Обоснование: сколько требований выполнено из общего числа
3. Список нарушенных требований (если есть) с номерами
4. Рекомендации: что исправить для полного соответствия
Что подставлять:
- {твоя_инструкция} — исходный промпт или бриф с требованиями
- {полученный_текст} — ответ LLM, который нужно проверить
🚀 Быстрый старт — вставь в чат:
Вот метод проверки выполнения сложных инструкций через разбиение на требования.
Адаптируй под мою задачу: [опиши что нужно проверить — текст от LLM на соответствие брифу / ответ агента на выполнение инструкций / контент на соответствие гайдлайнам].
Задавай вопросы чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какая инструкция, какой текст проверяем, какие требования критичны — потому что метод требует разделения на логические и семантические требования, и нужно понять контекст задачи. Она возьмёт трёхшаговую структуру из шаблона и адаптирует: извлечёт требования из твоего брифа, проверит по пунктам, выдаст вердикт.
Почему это работает (детали из исследования)
Исследователи протестировали NSVIF на VIFBENCH — бенчмарке из 820 примеров с инструкциями разной сложности (от 2 до 10 требований в одной инструкции). Сравнивали с LLM-as-a-judge (стандартный подход: дай LLM инструкцию + ответ, спроси "соответствует?").
Результаты: NSVIF показал F1 score 77.2% против 51.0% у baseline. Разница особенно велика на инструкциях с 5+ требованиями — там baseline падает до 40-45%, а NSVIF держит 70-75%. Причина: baseline пытается оценить "всё сразу", NSVIF проверяет по пунктам.
Ключевые находки:
Разделение логики и семантики критично. Логические требования (количество слов, наличие фразы) можно проверить объективно через код или ручной подсчёт — точность ~95%. Семантические (тон, стиль) требуют LLM — точность ~70-80%, зависит от субъективности. NSVIF применяет точный метод где можно, LLM — где неизбежно.
Детальный фидбек улучшает исправления. Когда NSVIF указывает "нарушено требование 3: не упомянуто ключевое слово X", LLM исправляет точечно. Когда baseline говорит "что-то не так с текстом", LLM переписывает всё и может сломать то что работало.
Метод масштабируется на длинные инструкции. Тестировали на инструкциях до 10 требований — NSVIF держит качество, baseline деградирует. Для читателя: если бриф содержит 7-8 пунктов, разбиение обязательно.
Механика работы multi-agent системы (для понимания, не для применения):
- Formulation Agent извлекает требования через LLM и кодирует связи между ними в формулу первого порядка (First-Order Logic). Использует Z3 SMT solver для решения constraint-satisfaction problem.
- Checking Agent для логических требований генерирует Python-код (например: return len(text.split()) >= 80 and len(text.split()) <= 100). Для семантических — составляет zero-shot промпт ("Какой тон текста?").
- Solver Agent запускает код и промпты, собирает результаты, решает логическую формулу через Z3, выдаёт вердикт + trace нарушений.
Читателю не нужен код — принцип работает мануально через три запроса в чате. Эффект тот же: разбиение → проверка по пунктам → объединение.
Как исследовали
Исследователи из University of Illinois, USTC и Microsoft Research создали:
NSVIF framework — multi-agent систему на Python с интеграцией Z3 SMT solver. Три агента (Formulation, Checking, Solver) оркестрированы через AutoGen framework. Проверка логических требований — через генерацию кода (codegen), семантических — через LLM-промпты.
VIFBENCH — бенчмарк для оценки верификаторов инструкций. 820 примеров с fine-grained labels: не просто "соответствует/не соответствует", а "какое конкретно требование нарушено и почему". Инструкции синтезированы из 10 типов constraints (8 логических + 2 семантических), скомбинированных с разной сложностью (2-10 constraints в одной инструкции). Ответы LLM — часть сгенерированы и проверены на соответствие, часть мутированы для создания нарушений.
Тестировали на GPT-4o, GPT-4o-mini, Claude-3.5-Sonnet. Сравнивали NSVIF с тремя вариантами LLM-as-a-judge: - Baseline — стандартный промпт "проверь соответствие" - GEPA-CoT — Chain-of-Thought для улучшения reasoning - GEPA-SC — Self-Consistency (5 прогонов + majority vote)
Метрики: Precision, Recall, F1 score, Pass@1 (доля корректных вердиктов).
Ключевой результат: NSVIF +26.2 pp F1 относительно лучшего baseline (GEPA-CoT: 51.0% → NSVIF: 77.2%). На сложных инструкциях (7+ constraints) разница ещё больше: baseline ~40%, NSVIF ~72%.
Также показали что feedback от NSVIF улучшает instruction-following LLM без post-training — просто добавляли детальный trace нарушений в re-prompting, точность выросла на 15-20% относительно обычного "попробуй снова".
Ограничения
⚠️ Избыточность для простых инструкций: Если требование одно ("напиши на тему X"), метод с разбиением дороже по токенам чем прямая проверка. Разбиение оправдано при 3+ требованиях.
⚠️ Субъективность семантических требований: Оценка тона, стиля, настроения зависит от LLM которую используешь для проверки. Разные модели или температуры → разные вердикты. Логические требования объективны, семантические — нет.
⚠️ Стоимость multi-step проверки: Мануальный workflow требует 3 последовательных запроса в чате. Это 3x токенов относительно одного запроса "проверь всё". Для частых проверок — ощутимо по деньгам.
⚠️ Не заменяет экспертную оценку: Метод проверяет соответствие инструкции, не качество контента. Если инструкция требует "упомянуть продукт", метод проверит наличие упоминания, но не оценит убедительность аргументов или креативность подачи.
Ресурсы
Исследование: "Neuro-Symbolic Verification on Instruction Following of LLMs"
Авторы: Yiming Su (University of Illinois Urbana-Champaign), Kunzhao Xu (University of Science and Technology of China), Yanjie Gao (Microsoft Research, corresponding author), Fan Yang (Microsoft Research), Cheng Li (USTC), Mao Yang (Microsoft Research), Tianyin Xu (UIUC)
Связанные работы упомянутые в исследовании: - ComplexBench (Wen et al., 2024) — benchmark для сложных составных инструкций - LLMBar (Zeng et al., 2024) — ранний benchmark для instruction-following, использует preference вместо абсолютной проверки - DSPy (Khattab et al., 2024), PDL (Vaziri et al., 2024), LMQL (Beurer-Kellner et al., 2023) — фреймворки для constrained decoding - LINC (Olausson et al., 2023), Logic-FM (Pan et al., 2023) — использование LLM для формулирования логических утверждений и theorem proving