TL;DR
Validation by Demonstration (проверка через показ) — подход, в котором вы не пишете критерии проверки заранее, а правите один ответ модели. Затем LLM по вашей правке, исходному и исправленному тексту и контексту (код, ошибка) выводит правило в формате «КОГДА — ТО». Правило можно прочитать, поправить и применить ко всем остальным ответам.
Главная находка: критерии «из головы» почти всегда неполные. Люди не могут заранее перечислить все случаи, они понимают, чего хотят, только когда видят конкретный плохой ответ. Проверяющие смотрели на ответ рядом с исходными данными и правили его под конкретный случай. Но решение оставалось локальным: через десять примеров то же суждение приходилось принимать заново. Если же просто попросить модель «сформулируй критерии» обычным текстом, получается больше дублей и хуже исправляются кривые критерии.
Суть метода в четырёх шагах: правка → правило КОГДА-ТО → проверка правила → массовое применение. Условие («когда») описывает ситуацию и во входных данных, и в ответе. Действие («то») описывает, как менять ответ. Правила не фиксируются раз и навсегда: вы применяете их к новым примерам, смотрите, где сработали зря, и уточняете.
Схема метода
ШАГ 1: Берёте один ответ модели, правите его → пара «было / стало» + комментарий «почему»
ШАГ 2: LLM выводит правило из правки → КОГДА [условие по входу И ответу] → ТО [как менять]
ШАГ 3: Вы читаете правило, сужаете/расширяете условие → утверждённое правило
ШАГ 4: LLM проверяет остальные ответы: подходит условие? → если да, применяет действие
ШАГ 5: Смотрите, где правило сработало зря или промахнулось → возврат к шагу 3
Шаги 2 и 4 — отдельные запросы. Шаг 3 делает человек.
Пример применения
Задача: Владелец магазина одежды на Wildberries использует LLM для черновиков ответов на отзывы. Из 300 черновиков он поправил один: покупательница жалуется, что футболка села после стирки. Модель написала три абзаца извинений и предложила промокод. Владелец оставил два предложения, предложил обмен и убрал промокод. Теперь ему нужно превратить эту правку в правило и прогнать по остальным 299 ответам.
Промпт (шаг 2, вывод правила):
Ты помогаешь превратить мою правку в правило проверки.
Отзыв покупателя:
«Футболка села после первой стирки на 40 градусах. Брала L, теперь как S. Разочарована.»
Черновик ответа модели (было):
«Здравствуйте! Нам очень жаль, что вы столкнулись с такой ситуацией. Мы всегда стремимся делать лучшие товары и глубоко сожалеем о доставленных неудобствах. В качестве извинения дарим вам промокод на 10% на следующую покупку. Надеемся, вы дадите нам ещё один шанс!»
Мой вариант (стало):
«Здравствуйте! Жаль, что футболка села. Напишите нам в чат заказа — оформим обмен или возврат. Состав и режим стирки указаны на бирке: 30 градусов, без сушки.»
Мой комментарий: убрал воду, убрал промокод — на жалобы на качество промокоды не даём. Добавил конкретный шаг и ссылку на режим стирки.
Выведи правило в формате:
КОГДА: [условия, которые нужно проверять в отзыве И в черновике]
ТО: [что именно изменить в черновике]
Добавь:
- 2 примера отзывов, где правило должно сработать
- 2 примера, где правило срабатывать не должно, но легко ошибиться
- Что в моей правке осталось неясным (спроси, не додумывай)
Результат: Модель выдаст правило в формате КОГДА-ТО: условия (жалоба на качество, в черновике есть промокод или длинные извинения) и действия (убрать промокод, сократить, добавить шаг решения). Затем она покажет примеры, где правило должно и не должно сработать, и задаст уточняющие вопросы. Например, нужно ли убирать промокод при жалобе на доставку. Вы поправите условия и во втором запросе (шаг 4) отдадите правило вместе с остальными отзывами.
Почему это работает
Слабость. Человек плохо формулирует критерии заранее: чтобы предусмотреть все случаи, нужно сначала увидеть плохие ответы. Правки при этом остаются «одноразовыми»: исправили один ответ, а на следующем те же ошибки. Критерии обычным текстом получаются расплывчатыми и дублируют друг друга.
Сильная сторона LLM. Модель хорошо делает две вещи. Первая — обобщать из примера: по паре «было → стало» и комментарию она угадывает, что именно изменилось и почему. Вторая — судить по условию, которое трудно проверить программно («жалоба на качество», «ответ слишком длинный»). Это семантические метки, и модель их присваивает неплохо.
Как метод их соединяет. Вы делаете то, что умеете, — правите конкретный пример. Модель делает то, что умеет, — превращает правку в правило. Формат «КОГДА — ТО» заставляет отделить условие (когда правило включается) от действия (что менять). Поэтому правило читаемо: вы видите, где оно сработает, и можете его сузить. Когда правило прогоняется по остальным примерам, видны ложные срабатывания, и вы уточняете условие.
Рычаги управления: - Комментарий к правке. Чем точнее объясните «почему», тем меньше модель домысливает. Без комментария правило будет угадано по тексту. - Условие «КОГДА». Сужайте его, если правило срабатывает зря. Расширяйте, если пропускает похожие случаи. - Примеры «не должно сработать». Они прямо показывают границы правила. - Контекст для условия. Добавьте в КОГДА не только ответ, но и исходные данные (отзыв, код, письмо клиента). В исследовании проверяющие судили именно по паре «вход + ответ». - Вопрос «что осталось неясным». Он заставляет модель задавать вопросы, а не выдумывать.
Шаблон промпта
Шаг 1–2. Вывод правила из правки:
Ты помогаешь превратить мою правку ответа в переиспользуемое правило проверки.
<Контекст>
Задача, для которой модель делала ответ: {задача}
Входные данные: {вход: письмо клиента / отзыв / код / запрос}
<Было>
{исходный ответ модели}
<Стало>
{мой исправленный ответ}
<Почему>
{мой комментарий: что не так было и почему я так исправил}
Выведи правило в формате:
КОГДА: [условия, которые нужно проверить во входных данных И в ответе модели]
ТО: [какое именно изменение нужно внести в ответ]
Затем:
1. Дай 2 примера, где правило должно сработать.
2. Дай 2 примера, где оно не должно сработать, но легко ошибиться.
3. Перечисли, что в моей правке осталось неясным. Задай вопросы, не додумывай.
Шаг 4. Применение ко всей пачке:
Вот утверждённые правила проверки:
<Правила>
Правило 1:
КОГДА: {условие}
ТО: {действие}
Правило 2:
КОГДА: {условие}
ТО: {действие}
Вот пары «вход — ответ модели»:
{пронумерованный список пар}
Для каждой пары:
1. Проверь условие КОГДА каждого правила. Процитируй фрагмент входа или ответа, на который опираешься.
2. Если условие выполнено — примени ТО и покажи исправленный ответ.
3. Если не выполнено — напиши «правило не применимо» и коротко почему.
4. В конце выведи таблицу: номер пары — какие правила сработали — изменён ли ответ.
5. Отдельно пометь пары, где ты не уверен, сработало ли правило.
🚀 Быстрый старт — вставь в чат:
Вот шаблон проверки через показ. Адаптируй под мою задачу: [твоя задача — например, ответы поддержки, посты, письма клиентам].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, для какой задачи делались ответы, что было на входе, что именно вы исправили и почему. Это нужно для условия «КОГДА»: правило опирается и на входные данные, и на сам ответ. Она возьмёт структуру шаблона и соберёт готовый промпт под вашу задачу.
Важно: точный формат языка правил из статьи вынесен в приложение, которого в доступном тексте нет. Шаблон выше — реконструкция по описанию: КОГДА-условия над входом и ответом, ТО — правка.
Ограничения
⚠️ Одного примера мало: по одной правке можно вывести много разных правил. Модель выберет одно, не обязательно ваше. Поэтому в метод встроены проверка человеком и примеры «не должно сработать».
⚠️ Условия нельзя проверить формально: «жалоба на качество» или «слишком длинно» оценивает модель, и она может ошибаться. Без выборочной проверки результатов вы не узнаете, где правило промахнулось.
⚠️ В статье это отдельная система, не промпт: результаты получены на интерфейсе с подсветкой совпадений и пакетным применением. Вручную в чате вы повторите логику, но не получите тех же цифр.
⚠️ Одна область и одна модель: проверяли на проверке обратной связи по коду в учебном курсе Python, правила выводила GPT-4o. Переносимость на ответы поддержки, тексты или письма — логичная, но в статье не проверялась.
⚠️ Небольшая выборка: 16 преподавателей, в основном сравнение с обычными текстовыми критериями.
Как исследовали
Сначала команда посмотрела, как люди проверяют ответы LLM без всякой поддержки. Десять преподавателей по Python просматривали сгенерированные комментарии к работам студентов. Из 178 эпизодов проверки примерно в 70% люди сверяли ответ с кодом студента и правили его по контексту. Но правка оставалась локальной, одни и те же суждения приходилось повторять. Отсюда идея: правка — это неявное правило «если в ситуации X, то ответ должен меняться так».
Затем сделали пробную систему на GPT-4o, которая превращает правку в структурное правило КОГДА-ТО. Её сравнили с обычными критериями на естественном языке (12 участников в предварительном исследовании). Там при критериях текстом люди создавали заметно больше дублей. Из 83 созданных критериев составили словарь: чаще всего просили краткость (около трети), запрет на готовые решения (около четверти), обязательные темы в ответе, стиль кода, структуру и тон.
В основном исследовании 16 преподавателей работали в обеих условиях. С ValiAssist ответы соответствовали их же критериям в 91% случаев против 57% у текстового базового варианта. Точность исправления плохих критериев выросла с 32% до 77%. Журналы показали, что преподаватели не писали критерии один раз, а несколько раз прогоняли, смотрели и правили. Правило уточняется через показ, где оно срабатывает. Оставшаяся часть методологии в доступном тексте обрезана.
Адаптации и экстраполяции
🔧 Техника: добавить «покажи, где не сработало» → меньше ложных срабатываний
Перед применением правила ко всей пачке попросите модель сначала прогнать 10 случайных пар и вывести отдельно те, где она сомневается:
Прежде чем применять правило ко всем, прогони его на 10 случайных парах.
Покажи, где ты сомневаешься, сработало ли условие.
Предложи, как уточнить КОГДА, чтобы убрать сомнения.
Словарь типичных намерений (из статьи) как стартовый список критериев. Если не знаете, с чего начать, просмотрите десять типичных намерений: краткость; запрет на готовые решения; обязательные темы; стиль; структура; суть, а не частный случай; объём совета; пояснение ошибки; позитивный тон. Спросите себя, какие из них применимы к вашим ответам, и покажите модели одну правку на каждое.
Ресурсы
- ValiAssist: Scaling LLM-generated Programming Feedback Validation by Demonstration — Xiaohang Tang, Rehema Abulikemu, Peng Gao, Yan Chen, Virginia Tech (США)
- Упомянутые родственные работы: EvalGen, EvalLM, Evalet, Policy Maps (проверка и критерии для генерации); FixPropagator (перенос исправления на другие работы); Programming by Demonstration (общий подход)