TL;DR
PSCI — техника, которая перестраивает работу с большими документами: сначала модель извлекает из контекста все неявные правила и ограничения в отдельный «контракт», затем генерирует ответ строго по этому контракту, потом проверяет себя и чинит нарушения. Четыре шага в правильном порядке вместо одного прямого запроса.
Главная находка: модели проваливаются не потому, что не могут найти нужную информацию в документе — содержание они находят хорошо. Они проваливаются потому, что игнорируют скрытые правила: форматы, порядок, специальные флаги, граничные случаи — всё то, что разбросано по документу, но ни разу явно не упомянуто в вашем вопросе. Вы спрашиваете «сделай X», а в документе где-то на 15-й странице написано «если встречается случай Y — обязательно добавь метку Z». Модель отвечает правильно по содержанию, но нарушает это правило — и ответ неверен. Проблема не в незнании, а в том, что правила не активированы как ограничения.
Исследователи подтвердили: 95.5% таких правил буквально есть в тексте документа — модель способна их извлечь, если явно попросить. Но без такой просьбы она их пропускает при генерации. PSCI устраняет этот разрыв: шаг 1 — извлечь все правила в список, шаг 2 — ответить по списку, шаг 3 — проверить каждое правило, шаг 4 — починить нарушения.
Схема метода
Выполняется последовательно — каждый шаг отдельным запросом или в одном структурированном промпте.
ШАГ 1: ИНДУКЦИЯ СПЕЦИФИКАЦИЙ
Вход: документ/контекст + задача
Действие: извлечь все неявные правила, ограничения, форматы
Выход: контракт K = {k1, k2, ..., kn} — пронумерованный список обязательств
ШАГ 2: ГЕНЕРАЦИЯ ПО КОНТРАКТУ
Вход: задача + документ + контракт K
Действие: создать черновик Y0, следуя каждому пункту K
Выход: черновик ответа
ШАГ 3: ПРОВЕРКА (adversarial checker)
Вход: задача + документ + контракт K + черновик Y0
Действие: проверить каждый пункт Ki
Выход: диагноз d = [(ki, статус, причина)]
статус: ВЫПОЛНЕН / ЧАСТИЧНО / НАРУШЕН
ШАГ 4: ПОЧИНКА
Вход: всё выше + диагноз d
Действие: исправить только ЧАСТИЧНО и НАРУШЕНО, сохранить правильное
Выход: финальный ответ Ŷ
Пример применения
Задача: Ты — продавец на Wildberries, получил 40-страничный регламент оформления карточек товара от бренда-поставщика. Нужно написать карточку для новой позиции — средства от комаров. В регламенте разбросаны десятки требований: запрещённые слова, обязательные предупреждения, формат артикула, структура описания, правила размещения знаков безопасности. Если нарушить хотя бы одно — карточка уходит на доработку.
Промпт (Шаг 1 — Индукция спецификаций):
Ты — эксперт по оформлению товарных карточек.
Ниже — регламент бренда по созданию карточек товара на маркетплейсах:
[РЕГЛАМЕНТ]
{вставить текст регламента}
[/РЕГЛАМЕНТ]
Моя задача: написать карточку для средства от комаров «АнтиМоскит Про 200мл».
Перед тем как писать карточку — извлеки из регламента ВСЕ обязательные требования, которые относятся к этой задаче. Особое внимание:
— формат и структура (порядок блоков, длина, заголовки)
— запрещённые слова и формулировки
— обязательные предупреждения и маркировки
— граничные случаи и исключения
— точные фразы или метки, которые нужно использовать дословно
Оформи как пронумерованный список: «Обязательство N: [описание правила]».
Не пиши карточку пока — только список обязательств.
Промпт (Шаг 2 — Генерация по контракту):
Вот список обязательств из регламента:
{список из шага 1}
Теперь напиши карточку товара для «АнтиМоскит Про 200мл»,
строго следуя каждому пункту списка.
Промпт (Шаг 3 — Проверка):
Проверь карточку против каждого обязательства.
Список обязательств:
{список из шага 1}
Карточка:
{карточка из шага 2}
По каждому пункту укажи:
— ВЫПОЛНЕН / ЧАСТИЧНО / НАРУШЕН
— Если не ВЫПОЛНЕН: что именно нарушено и где
Только проверка, не переписывай карточку.
Промпт (Шаг 4 — Починка):
Вот карточка с диагнозом нарушений:
Карточка: {из шага 2}
Диагноз: {из шага 3}
Исправь только пункты со статусом ЧАСТИЧНО и НАРУШЕН.
Всё остальное оставь без изменений.
Выдай финальную карточку.
Результат: В финале будет карточка, которая явно прошла проверку по каждому требованию документа. Процесс прозрачен — вы видите список правил из шага 1, видите диагноз из шага 3, видите что именно исправлено. Особенно ценно для документов с десятками скрытых ограничений: технических регламентов, договоров, корпоративных политик, требований маркетплейсов.
Почему это работает
Слабость LLM: Модель генерирует ответ, держа в фокусе ваш вопрос. Всё, что явно связано с вопросом, она видит хорошо. Но требования из документа, которые к вопросу напрямую не привязаны, остаются на периферии — они не активированы как ограничения генерации. Представьте: вы читаете задание и краем глаза замечаете сноску на полях. Содержание зафиксировали, но при написании ответа сноска "выпала". Именно это и происходит с распределёнными по документу правилами.
Сильная сторона LLM: При прямом вопросе «извлеки все правила из этого документа» модель справляется отлично. Исследование показало: когда модели явно задавали задачу извлечения, она восстанавливала 94.4% скрытых требований с долей противоречий менее 0.5%. Возможность есть — нужна правильная активация.
Как метод использует это: PSCI разделяет задачу на два отдельных акта. Сначала полное внимание направлено только на извлечение правил из документа — без отвлечения на написание ответа. Потом генерация идёт под явным контролем этих правил. Проверщик смотрит не на качество текста в целом, а на конкретный пункт контракта — это гораздо точнее, чем "покритикуй себя".
Рычаги управления: - Детализация шага 1 → чем подробнее попросите разбить типы правил (форматы / запреты / граничные случаи / точные фразы), тем полнее контракт - Шаги 3-4 можно пропустить для простых документов → экономия токенов, небольшой документ, цена ошибки низкая - Шаг 3 можно заменить конкретным специалистом-ролью: «Ты — строгий юрист-проверяльщик» → острее критика - Глубину шага 1 можно регулировать: «только критические требования» vs «абсолютно все, включая мелкие»
Шаблон промпта
Универсальный шаблон для всего PSCI-цикла в одном месте:
=== ШАГ 1: ИЗВЛЕЧЕНИЕ СПЕЦИФИКАЦИЙ ===
Прочитай следующий документ с задачей извлечения, а не ответа:
[ДОКУМЕНТ]
{текст документа, регламента, требований}
[/ДОКУМЕНТ]
Моя задача: {описание того, что нужно создать/написать/сделать}
Извлеки из документа ВСЕ требования, которые относятся к этой задаче:
— обязательные форматы и структуры
— запреты и ограничения
— граничные случаи и исключения
— точные формулировки или метки, которые нужно соблюсти дословно
— условия полноты (что должно быть ОБЯЗАТЕЛЬНО включено)
Оформи как пронумерованный список. Только список, без ответа на задачу.
=== ШАГ 2: ГЕНЕРАЦИЯ ===
Теперь выполни задачу, строго следуя каждому пункту из списка выше.
Перед ответом напиши: «Выполняю с учётом [N] обязательств из контракта».
=== ШАГ 3: ПРОВЕРКА ===
Прежде чем считать задачу выполненной — проверь черновик выше
против каждого пункта контракта.
Для каждого пункта: ВЫПОЛНЕН / ЧАСТИЧНО / НАРУШЕН + причина (если не ВЫПОЛНЕН).
Только проверка.
=== ШАГ 4: ПОЧИНКА ===
Исправь все пункты со статусом ЧАСТИЧНО и НАРУШЕН.
Сохрани всё остальное без изменений. Выдай финальный ответ.
Плейсхолдеры:
- {текст документа} — регламент, политика, ТЗ, договор, инструкция
- {описание того, что нужно создать} — «написать карточку товара», «составить ответ клиенту», «подготовить отчёт по форме»
🚀 Быстрый старт — вставь в чат:
Вот шаблон метода PSCI (контракт спецификаций). Адаптируй под мою задачу: {твоя задача}. Задавай вопросы, чтобы заполнить поля. [вставить шаблон выше]LLM спросит какой документ/регламент у вас есть и что именно нужно создать — потому что PSCI работает только когда есть конкретный источник правил и конкретный результат. Она возьмёт паттерн из шаблона и подстроит формулировки под вашу задачу.
Ограничения
⚠️ Нужен документ с правилами: Метод работает только когда есть конкретный источник спецификаций — регламент, ТЗ, руководство, договор. Для задач «из головы» без опорного документа PSCI не даёт преимущества над обычным промптом.
⚠️ 4 шага = 4 запроса: Полный цикл требует нескольких сообщений и больших токенов. Для коротких документов или задач с низкой ценой ошибки достаточно шагов 1-2.
⚠️ Шаг 1 сам может пропустить что-то: Если документ очень длинный (40K+ токенов), контракт в шаге 1 может быть неполным — модель не захватит 100% правил. Помогает явно перечислить типы правил, которые искать (форматы, запреты, флаги, граничные случаи).
⚠️ Не для субъективного контента: Метод заточен под задачи с проверяемыми критериями. Для текстов, где нет жёстких правил (свободный креатив, вопросы мнений), преимущество минимально.
Как исследовали
Идея была обидно простой: взяли свежий бенчмарк CL-Bench с 1 899 задачами — каждая задача это большой документ (в среднем 10K токенов, до 65K) плюс вопрос, плюс 16+ критериев оценки. Задачи писали люди-эксперты, чтобы исключить утечку в обучающие данные. Сначала проверили самое очевидное объяснение плохих результатов: «модели не могут найти нужное в длинном тексте». Запустили 12 разных методов улучшения поиска и обработки контекста — RAG, GraphRAG, RAPTOR, Reflexion и другие. Ни один не дал больше +0.78 процентных пунктов над простым запросом с полным контекстом. Это был сигнал, что проблема не там.
Тогда вручную разобрали все 31 592 критерия оценки: что именно они проверяют — содержание ответа или соблюдение правил? Выяснилось, что 55.4% критериев оценивают именно правила и ограничения, а не факты. Причём в провальных задачах, где модель ошибалась ровно на одном критерии, 75.3% этих последних ошибок были именно нарушениями правил, а не фактическими ошибками. Потом проверили трассируемость: есть ли эти правила в документе вообще? 95.5% — есть. Модель их физически видела, но не применяла.
Самое неожиданное: когда модели просто прямо сказали «извлеки все правила из этого документа», она покрывала 94.4% скрытых критериев. Возможность была всегда — просто никто её не активировал. PSCI проверяли на трёх моделях разного размера и все три показали одинаковый прирост ~+5-6 п.п., а 17 последовательных аблаций чётко показали: перепутай контракт → результат падает ниже базового; убери контракт, оставь проверку → результат возвращается к базовому. Это доказывает — работает именно контракт, а не дополнительные вычисления.
Адаптации и экстраполяции
1. Двухшаговый PSCI для быстрых задач
Для небольших документов или когда время важнее идеала — оставить только шаги 1 и 2. Уже это даёт большую часть прироста (шаг 1 один отвечает за ~63% общего улучшения по данным аблаций).
Прочитай документ и сначала составь список всех требований к {задача}.
Потом сразу выполни задачу, следуя каждому пункту списка.
[ДОКУМЕНТ]
{текст}
[/ДОКУМЕНТ]
2. Персонализированный проверщик → острее критика
🔧 Техника: безликий проверщик → специалист-роль
Шаг 3 по умолчанию — нейтральная проверка. Замените на конкретного специалиста, чтобы получить более острое и профильное замечание:
Ты — придирчивый юрист, специализирующийся на договорном праве. Проверь этот договор против каждого пункта списка требований. Отмечай малейшие отклонения.Работает для любой профессиональной области: регулятор, редактор, технический директор.
3. Комбинация с Chain-of-Thought на шаге 2
Если по документу нужно не просто выполнить задачу, но и объяснить своё решение — добавьте в шаг 2 инструкцию думать вслух. Это особенно полезно для сложных регуляторных документов, где важно видеть, как модель интерпретирует каждое правило.
Выполни задачу, следуя контракту обязательств.
Для каждого пункта контракта сначала напиши «Применяю пункт N: [как именно]»,
потом включи результат в ответ.
Ресурсы
Работа: Agentic Context Learning with Self-Discovered Specification (preprint, 2025)
Бенчмарк: CL-Bench (Dou et al., 2026) — 1,899 задач, 31,592 критериев оценки
Авторы: Jike Zhong, Ming Li, Yuxiang Lai, Ziyan Yang, Jingyu Xie, Jihyung Kil, Zheda Mai, Shao-Yuan Lo, Xiang Ren, Konstantinos Psounis, Yuanyuan Lei
Университеты: University of Southern California, University of Florida, Emory University, Adobe Research, The Ohio State University, National Taiwan University
Контакт: jikezhon@usc.edu