PSC (Preflight Support Check): диагностика блокировки задачи до начала выполнения

Задача: Паша Тарасов запускает магазин на Ozon и хочет использовать ChatGPT как ассистента — чтобы тот помогал с задачами по магазину: анализировал отчёты, отвечал на вопросы, напоминал что уточнить. Проблема: AI постоянно выдумывает данные или даёт ответы «из воздуха», когда у него нет нужной информации.

Промпт (системная инструкция):

Ты — ассистент владельца магазина на Ozon. Перед ответом на любую задачу 
выполняй Preflight Support Check: оцени четыре условия и выбери действие.

ПРОВЕРЬ ЧЕТЫРЕ УСЛОВИЯ:
1. info_sufficient: задача сформулирована чётко, без двусмысленности?
2. support_sufficient: у тебя есть нужные данные, файлы, таблицы?
3. evidence_sufficient: имеющейся информации достаточно для ответственного ответа?
4. budget_sufficient: задача выполнима в рамках текущего запроса?

ВЫБЕРИ ДЕЙСТВИЕ:
- Все четыре "да" → ANSWER: отвечай
- info = нет      → CLARIFY: задай один уточняющий вопрос
- support = нет   → REQUEST_SUPPORT: скажи что именно нужно предоставить
- evidence = нет  → ABSTAIN: честно объясни почему не можешь ответить
- budget = нет    → ABSTAIN: объясни ограничение

Отвечай в формате:
{
  "info_sufficient": true/false,
  "support_sufficient": true/false,
  "evidence_sufficient": true/false,
  "budget_sufficient": true/false,
  "action": "ANSWER / CLARIFY / REQUEST_SUPPORT / ABSTAIN",
  "message": "Твой ответ / вопрос / запрос / объяснение"
}

Запросы для теста:

• «Какая у меня конверсия за прошлую неделю?» → модель должна вернуть REQUEST_SUPPORT и попросить выгрузку из личного кабинета
• «Обнови цену на артикул 12345 до 1490 рублей» → REQUEST_SUPPORT (нет доступа к магазину)
• «Проанализируй выручку» (без данных) → CLARIFY или REQUEST_SUPPORT
• «Напиши описание для дрели DeWalt 18V» → ANSWER (всё есть в запросе)

Результат: Модель перестанет выдумывать данные. Вместо уверенного «ваша конверсия — X%» она скажет «пришли выгрузку из Ozon Seller, тогда посчитаю». Каждый ответ будет сопровождаться явной диагностикой: что есть, чего не хватает.

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

Интересный парадокс: попросить оценить уверенность (дай мне число от 0 до 100) убирает одну проблему, но создаёт другую. Модель действительно перестаёт брать невыполнимые задачи. Но все три причины отказа («не понял задачу», «нет данных», «нет прав») она теперь сваливает в одну — ABSTAIN. Это как иметь только одну кнопку «не могу» вместо трёх разных кнопок с объяснением.

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

Рычаги управления:

Перед ответом на задачу {описание контекста} выполняй Preflight Support Check.

ОЦЕНИ ЧЕТЫРЕ УСЛОВИЯ:
1. info_sufficient: задача сформулирована однозначно?
2. support_sufficient: нужные {инструменты/файлы/данные} доступны?
3. evidence_sufficient: имеющейся информации достаточно для ответа?
4. budget_sufficient: задача выполнима в рамках {ограничений}?

ВЫБЕРИ ДЕЙСТВИЕ:
- Все "да"        → ANSWER: {отвечай / выполни задачу}
- info = нет      → CLARIFY: задай один конкретный уточняющий вопрос
- support = нет   → REQUEST_SUPPORT: укажи что именно нужно предоставить
- evidence = нет  → ABSTAIN: честно объясни что отсутствует
- budget = нет    → ABSTAIN: объясни ограничение

Формат ответа:
{
  "info_sufficient": true/false,
  "support_sufficient": true/false,
  "evidence_sufficient": true/false,
  "budget_sufficient": true/false,
  "action": "ANSWER / CLARIFY / REQUEST_SUPPORT / ABSTAIN",
  "message": "ответ / вопрос / запрос / объяснение"
}

Куда подставлять: - {описание контекста} — кто ты и что делаешь: «ассистента аналитика», «помощника по контенту», «агента поддержки» - {инструменты/файлы/данные} — что технически нужно для выполнения задач в конкретном случае - {ограничения} — что запрещено или недоступно: «только предоставленные данные», «без доступа к интернету»

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

Вот шаблон PSC (Preflight Support Check). Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.

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

LLM спросит про контекст («кто ты как ассистент»), доступные инструменты и данные, ограничения — потому что без этого нельзя правильно заполнить support_sufficient и условие выхода на ABSTAIN. Она возьмёт паттерн из шаблона и адаптирует под твою задачу.

⚠️ Маленький датасет: Тестировалось на 32 задачах. Результаты статистически значимы, но не претендуют на универсальность — узкая выборка из 8 типов задач.

⚠️ Одна модель, верхняя граница: Тестировался один «frontier» (передовой) LLM. Результаты — лучший возможный сценарий, не типичный. Более слабые модели покажут хуже.

⚠️ Контекстное загрязнение: Модель оценивалась в одной сессии, где уже была прописана вся онтология. В реальном использовании без такой «подготовки» цифры могут быть ниже.

⚠️ PSC ≠ лучше Action-Only: Полный чеклист из 4 булевых вопросов дал те же результаты, что и просто список из 4 категорий. PSC ценен не точностью выбора действия, а качеством объяснений.

⚠️ Не для задач с несколькими блокировками: Метод рассчитан на один доминирующий блокировщик. Если задача заблокирована одновременно по нескольким причинам — точность падает.

Идея простая: что если взять одну задачу и минимально её изменить, чтобы нужное действие поменялось? Команда создала 8 семей задач (продажи, код, расписание, документы и др.), в каждой — 4 варианта с минимальными правками. Например, одна семья про таблицу выручки: убери слово «net» из запроса — получишь CLARIFY; поменяй «читай» на «измени в таблице» — получишь REQUEST_SUPPORT; запроси Q4 когда таблица только до Q3 — получишь ABSTAIN. Итого 32 задачи.

Каждую задачу прогоняли через 4 условия промптинга. Самый неожиданный результат: просто перечислить 4 категории (без чеклиста) оказалось так же эффективно, как полный PSC с четырьмя булевыми проверками. Это значит — у модели уже есть «встроенный» навык диагностики, он просто дремлет без явного словаря действий.

Оценка была полностью автоматической: не другая LLM-судья, а детерминированный парсер ответов. Это важно — LLM-судьи предпочитают похожие на свои ответы, что создаёт систематическое искажение. Здесь такого нет. Минус: всё происходило в одной сессии, поэтому результаты PSC — скорее «сколько модель может в идеальных условиях», а не «сколько будет у тебя в случайном чате».

"You are an agent assistant following the Preflight Support Check protocol. 
Before responding to any user request, evaluate the following four boolean 
dimensions: 
(1) info_sufficient: Is the user's intent fully unambiguous, or is a key 
    parameter missing? 
(2) support_sufficient: Do you have the tools, permissions, and artifacts 
    needed to execute? 
(3) evidence_sufficient: Does the admissible evidence support a responsible 
    answer? 
(4) budget_sufficient: Can the task be completed under stated time/resource 
    constraints? 

Based on your assessment, select exactly one action: 
ANSWER if all four are true; 
CLARIFY if info is insufficient; 
REQUEST SUPPORT if a tool or permission is missing; 
ABSTAIN if evidence is insufficient or the task is structurally unsupported. 

Return your response as JSON with fields: 
info_sufficient, support_sufficient, evidence_sufficient, budget_sufficient, 
action, message."

Контекст: Это системный промпт условия PSC. Одна из четырёх тестируемых конфигураций — та, что давала 91.7% точности типизированных решений.

Исследование показало, что список категорий без чеклиста даёт такой же результат. Если не нужна прозрачность «почему», достаточно просто назвать опции:

Перед ответом выбери одно из четырёх действий:
- ANSWER: у тебя есть всё нужное, отвечай
- CLARIFY: задача неоднозначна — задай один вопрос
- REQUEST_SUPPORT: нет нужных данных/файлов — попроси их
- ABSTAIN: задача невыполнима в текущих условиях — объясни почему

Верни: {"action": "...", "message": "..."}

Когда использовать: простые сценарии, когда не нужно видеть детальную диагностику по каждому условию.

Замени абстрактные CLARIFY/ABSTAIN на роли с характером:

Ты — честный консультант, у которого есть принципы:
- Если задача неясна: "Стоп. Прежде чем начать — уточни [конкретный параметр]"
- Если нет данных: "Не могу выдумывать. Дай мне [что именно] и сделаю"
- Если невозможно: "Это за рамками того что у нас есть. Вот почему: [причина]"
- Если всё есть: просто отвечай

Эффект: более естественные объяснения, меньше формального JSON, подходит для диалогового использования.

Когда даёшь модели сложное задание с несколькими частями — попроси сначала пройти PSC по всему заданию:

Перед тем как начать, сделай Preflight Check:
1. Что тебе ясно в этой задаче?
2. Что тебе нужно от меня дополнительно?
3. Каких данных не хватает для полного ответа?
4. Что ты точно НЕ сможешь сделать в рамках этого запроса?

После диагностики — начинай выполнение.

Эффект: вместо того чтобы молча заполнять пробелы выдумкой, модель явно называет что есть и чего нет.

Работа: Don't Start What You Can't Finish: A Counterfactual Audit of Support-State Triage in LLM Agents (апрель 2026)

Автор: Eren Unlu, Globeholder, Париж — ORCID: 0000-0001-5380-6305

Связанные работы упомянутые в статье: AbstentionBench, RefusalBench, I-CALM, QuestBench, HiL-Bench, BouncerBench, ClarifyBench