Directional Stimulus Prompting (DSP) — техника из работы Li et al. на NeurIPS 2023: обучаемая policy-модель создаёт подсказки к конкретному входу, а целевая black-box LLM остаётся без дообучения. Ниже — полный исходник, два заполненных запроса и отдельный ручной эталон.
Что такое DSP и откуда взялась техника
Directional Stimulus Prompting (DSP) — это подход к управлению чёрным ящиком большой языковой модели через вспомогательные подсказки. В первичной работе, представленной на 37-й конференции NeurIPS 2023, авторы Zekun Li, Baolin Peng, Pengcheng He, Michel Galley, Jianfeng Gao и Xifeng Yan описывают схему так: вместо прямой настройки LLM используется небольшая обучаемая policy-модель, например T5, которая генерирует направляющий стимул для каждого входного запроса. На авторской странице проекта (leezekun.github.io/DSP-Prompting) сказано, что эти стимулы работают как «nuanced, instance-specific hints and clues» — тонкие подсказки, привязанные к конкретному входу, и направляют LLM к нужному результату, например к включению определённых ключевых слов в резюме.
Ключевое отличие от методов, дополняющих LLM знанием из внешних источников: в статье NeurIPS подчёркивается, что направляющий стимул генерируется исключительно на основе входного запроса. Внешние базы знаний здесь не привлекаются.
Обучение policy-модели в оригинальном исследовании идёт в два этапа. Сначала — supervised fine-tuning на небольшом наборе размеченных данных. Затем — reinforcement learning, где награда определяется метрикой качества на целевой задаче, например ROUGE для суммаризации, или другими мерами соответствия вроде человеческих предпочтений. Авторы проверяли подход на суммаризации, генерации ответов в диалоге и chain-of-thought рассуждениях.
Здесь важно разграничение. Оригинальная техника DSP — это обученная policy-модель, которая сама порождает подсказки под каждый вход. Ручные подсказки, которые читатель составит сам, — практический учебный аналог входных hints. Это не проведённое обучение policy и не воспроизведение эксперимента из статьи. Ручной набор подсказок помогает применить идею направляющего стимула на практике, но не заменяет собой обученную модель.
| Что сравниваем | Оригинальная DSP | Ручной аналог |
|---|---|---|
| Кто создаёт подсказки | Обучаемая policy-модель (например, T5) | Человек |
| Обучение | SFT, затем RL | Не проводится |
| Целевая LLM | Black-box, без дообучения | Та же логика: без дообучения |
| Награда | Метрика задачи (ROUGE и др.) | Нет |
| Статус | Исследовательская техника | Учебный приём |
Полный исходник и два запроса
Возьмём один исходный текст — объявление библиотеки. Все запросы ниже заполнены целиком, без плейсхолдеров вида {текст}.
Исходник:
Библиотека Северная закрывает читальный зал 12 ноября для замены освещения. Абонемент продолжает работать обычно. Зал откроется 14 ноября в 10:00. Возврат книг в период закрытия принимают через ящик у входа.
Первый запрос — базовый, без направляющих подсказок:
Составь краткое объявление для посетителей. Используй только факты исходника. Исходник: Библиотека Северная закрывает читальный зал 12 ноября для замены освещения. Абонемент продолжает работать обычно. Зал откроется 14 ноября в 10:00. Возврат книг в период закрытия принимают через ящик у входа.
Второй запрос — с направляющими подсказками, тот же исходник приведён полностью:
Составь краткое объявление для посетителей. Используй только факты исходника. Направляющие подсказки: читальный зал; закрытие 12 ноября; открытие 14 ноября в 10:00; абонемент работает; возврат через ящик. Исходник: Библиотека Северная закрывает читальный зал 12 ноября для замены освещения. Абонемент продолжает работать обычно. Зал откроется 14 ноября в 10:00. Возврат книг в период закрытия принимают через ящик у входа.
Разница между двумя запросами ровно одна — строка с направляющими подсказками. Она перечисляет ключевые точки, которые объявление должно покрыть: читальный зал, дату закрытия, точное время открытия, работу абонемента и способ возврата. Подсказки не добавляют новых фактов, они лишь выдвигают на передний план те, что уже есть в исходнике.
Читатель может передать оба запроса одной модели и сравнить ответы. Здесь нет фактических двух ответов, замера точности или утверждения об улучшении — это учебная заготовка для собственной проверки.
Ручной эталон ответа
Отдельно от запросов приведём ручной эталон ответа. Это не запрос к модели и не полученный от модели ответ — это текст, написанный человеком, с которым читатель может сверить факты.
Читальный зал библиотеки Северная закрывается 12 ноября и откроется 14 ноября в 10:00. Абонемент продолжает работать. В период закрытия книги принимают через ящик у входа.
Эталон нужен как точка отсчёта по содержанию. Он фиксирует, какие именно факты обязаны сохраниться в ответе, независимо от формулировок. Модель может перестроить предложения, изменить порядок, добавить вежливое обращение — эталон проверяет не стиль, а наличие и точность сведений.
Четыре опорные точки эталона: закрытие читального зала 12 ноября, открытие 14 ноября в 10:00, работающий абонемент и возврат книг через ящик у входа. Если ответ модели теряет любую из них или искажает, эталон показывает расхождение.
Четыре проверки фактов
Проверка 1. Сохранить закрытие 12 ноября и точное открытие 14 ноября в 10:00. Дата открытия — 14 ноября в 10:00, поэтому в ответе не должно появиться «закрыт весь день 14 ноября». Граница открытия указана точно.
Проверка 2. Не допустить ложного закрытия всей библиотеки. Закрыт лишь читальный зал. Абонемент продолжает работать, и это отдельный факт, который следует сохранить.
Проверка 3. Возврат книг в период закрытия идёт через ящик у входа. Способ возврата — самостоятельная деталь, её нельзя опустить или заменить.
Проверка 4. В ответе нет придуманных цен, контактов и дат. Каждая направляющая подсказка сверена с исходником. Подсказки не создают новых фактов, они лишь направляют внимание.
Эти четыре проверки дают читателю готовый чек-лист. Неполнота ответа фиксируется как результат будущей проверки. Никаких обещаний победы DSP над базовым запросом здесь нет: сравнение проводит сам читатель на своём материале.
| Проверка | Что контролируем | Признак ошибки |
|---|---|---|
| 1 | Закрытие 12 ноября, открытие 14 ноября в 10:00 | «Закрыт весь день 14 ноября» |
| 2 | Закрыт только читальный зал, абонемент работает | «Библиотека закрыта» |
| 3 | Возврат через ящик у входа | Способ возврата пропущен |
| 4 | Нет новых цен, контактов, дат | Появились лишние сведения |
Как применить приём к своей задаче
Порядок действий для своего материала. Сначала соберите исходник — короткий текст с фактами, которые обязаны попасть в ответ. Затем составьте базовый запрос: задача плюс инструкция использовать только факты исходника плюс сам исходник. После этого добавьте строку направляющих подсказок — перечислите ключевые точки через точку с запятой. Наконец, напишите ручной эталон ответа и сверьте с ним то, что вернёт модель.
Подсказки формулируйте как короткие именные группы: «читальный зал», «закрытие 12 ноября», «открытие 14 ноября в 10:00». Каждая подсказка должна опираться на факт из исходника. Если подсказка вводит сведение, которого в исходнике нет, она перестаёт направлять и начинает добавлять.
Приём применим там, где ответ должен покрыть заранее известный набор пунктов: объявления, сводки, инструкции, ответы на частые вопросы. В каждом случае строка подсказок перечисляет эти пункты, а эталон фиксирует их наличие.
Как разбирать расхождение между запросом и эталоном
Проверка начинается с того, что читатель сопоставляет ответ модели не с текстом подсказок, а с ручным эталоном. Подсказки лишь перечисляют опорные точки, тогда как эталон задаёт полный набор обязательных сведений. Поэтому первое действие — выписать из эталона все факты по отдельности и отметить, какие из них присутствуют в полученном ответе, а какие отсутствуют или искажены.
Типичная ошибка возникает при чтении строки подсказок как готового содержания. Читатель видит перечень читальный зал; закрытие 12 ноября; открытие 14 ноября в 10:00 и переносит эти формулировки в ответ дословно, теряя связь между ними. Тогда появляется фраза вроде зал закрыт 12 ноября, открытие 14 ноября, где пропадает точное время и остаётся двусмысленность относительно того, работает ли зал в промежутке. Эталон показывает, что граница открытия указана точно, и именно её нужно сохранить.
Вторая ошибка связана с расширением объекта закрытия. В исходнике речь идёт о читальном зале, а абонемент работает в обычном режиме. Если ответ объединяет их в одну формулировку, читатель теряет различие между двумя зонами библиотеки. Действие здесь простое: сверить каждое упоминание закрытия с эталоном и убедиться, что оно относится только к читальному залу.
Третья ошибка — пропуск способа возврата книг. Эта деталь не входит в даты и не бросается в глаза при беглом чтении, но эталон фиксирует её отдельным предложением. Если ответ её опускает, проверка 3 отмечает неполноту. Читателю стоит заранее решить, считается ли пропуск этой детали критичным для его задачи, и зафиксировать это решение до сравнения, чтобы не подгонять критерий под увиденный результат.
Отдельного внимания требует вопрос о новых сведениях. Подсказки не создают фактов, поэтому любая цена, контакт или дополнительная дата в ответе — сигнал, что модель вышла за пределы исходника. Действие читателя: пройти по ответу и для каждого числового или контактного сведения найти подтверждение в исходном тексте. Если подтверждения нет, сведение помечается как привнесённое.
Полезно вести разбор в виде короткой таблицы: факт из эталона, наличие в ответе, характер расхождения. Такая запись помогает отделить неполноту от искажения. Неполнота означает, что факт отсутствует; искажение — что он передан неверно. Эти два случая требуют разных выводов, и смешивать их не стоит.
Наконец, результат сравнения остаётся наблюдением читателя на его собственном материале. Он не превращается в утверждение о превосходстве одного запроса над другим и не заменяет проверку на других исходниках. Разбор показывает, где именно ответ разошёлся с эталоном и какое действие поможет это заметить в следующий раз.
Частые вопросы
Что такое Directional Stimulus Prompting простыми словами?
Это способ управлять большой языковой моделью через вспомогательные подсказки к конкретному входу. В оригинальной работе NeurIPS 2023 подсказки создаёт небольшая обучаемая policy-модель, а целевая LLM остаётся без дообучения. Подсказки направляют содержание ответа к нужному результату.
Чем DSP отличается от обычного промптинга?
В нашем базовом запросе есть задача и исходник. В оригинальной DSP к конкретному входу добавляют направляющий стимул, который создаёт обученная policy-модель.
Можно ли применять DSP без обучения модели?
Да, как учебный приём. Ручные подсказки — практический аналог входных hints. Это не воспроизведение эксперимента из статьи и не обучение policy-модели, а способ применить идею направляющего стимула на своём материале.
Что такое policy-модель в DSP?
Это небольшая обучаемая модель, например T5, которая генерирует направляющий стимул для каждого входного запроса. Её обучают через supervised fine-tuning, затем через reinforcement learning с наградой по метрике задачи.
Как проверить, что подсказки не добавили лишних фактов?
Сверьте каждую подсказку с исходником. Если сведение есть в исходном тексте — подсказка допустима. Если появились новые цены, контакты или даты — уберите подсказку. Ручной эталон ответа служит точкой сверки по содержанию.