Перевод с разбором · для Сони

Цепочка промптов

Что это

Большую задачу можно решать одним длинным промптом или разбить на несколько последовательных. Цепочка промптов (prompt chaining) — это второй вариант: ты делаешь не один API-вызов, а 2–3 последовательных, передавая выход одного как вход другого.

Anthropic в оригинале формулирует так: «Adaptive thinking делает большинство многошаговых рассуждений внутренне. Явные цепочки промптов всё ещё полезны, когда нужно инспектировать промежуточные выходные данные или закрепить конкретную структуру пайплайна». Это применимо и к OpenAI: GPT-5.4-mini справляется со сложными задачами в один шаг, но иногда разбить — выгоднее.

Когда разбивать на цепочку

• Нужно увидеть промежуточный результат. Если ты хочешь проверить, как модель «поняла» вопрос, прежде чем она даст финальный ответ — это два шага: «вот что ты понял» → «теперь делай».
• Разные шаги требуют разных моделей. Например, классификация — на дешёвой модели; ответ пользователю — на основной. Это разные API-вызовы.
• Логика ветвится. «Если пользователь спрашивает про задачу — иди в ветку А; если про эмоции — в ветку Б». В одном промпте обе ветки конкурируют; в цепочке первый запрос определяет тип, второй — обрабатывает.
• Самокоррекция. Сгенерировал черновик ответа — попросил модель оценить его по критериям — попросил переписать. Это надёжнее, чем «сразу выдай идеальный ответ».

Когда НЕ разбивать

• Задача однородная. «Ответь пользователю эмпатично и по делу» — один шаг.
• Стоимость и задержка важнее качества. Каждый шаг — отдельный round-trip к OpenAI: и токены, и секунды. Для бота, где пользователь ждёт ответ, два-три шага — это ощутимая задержка.
• Шаги идеально складываются в один промпт. Иногда «разбиение» — это просто подробная инструкция «сначала рассуждай, потом отвечай»; это лучше делать через CoT в одном запросе, не в цепочку.

Пример: многошаговая диагностика целей

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

В один промпт это плохо помещается. В цепочку — естественно:

1. Шаг 1: классификация. Дешёвый запрос: «Это сообщение содержит признак долгосрочного интереса/цели? да/нет». Если нет — выходим из цепочки, обычный ответ.
2. Шаг 2: извлечение. «Сформулируй цель из сообщения пользователя одной фразой. Если данных недостаточно — напиши вопрос для уточнения». Возвращает либо черновую цель, либо вопрос.
3. Шаг 3: верификация. «Вот черновая формулировка цели: X. Соответствует ли она тому, что ты хотел сказать?» — отправляется пользователю как ответ от бота.
4. Шаг 4 (после ответа пользователя): сохранение. Если ответ «да» — вызывается tool save_goal. Если «нет» или уточнение — возврат к шагу 2 с новым контекстом.

Шаги 1, 2, 4 — внутренние, пользователь их не видит. Только шаг 3 выходит в Telegram.

async def handle_message(user_id: int, text: str) -> str:
    notes = await db.get_user_notes(user_id)

    # Шаг 1: классификация (дешёвая модель)
    is_goal_signal = await classify_goal_signal(text)
    if not is_goal_signal:
        return await regular_chat(user_id, text)

    # Шаг 2: извлечение
    extracted = await extract_goal(text, notes)
    if extracted.needs_clarification:
        return extracted.clarifying_question

    # Шаг 3: верификация (отправляется пользователю)
    return f"Я вижу это так: «{extracted.goal}». Я правильно поняла?"

    # Шаг 4 — в обработке следующего сообщения
    # if user_confirmed: await db.save_goal(user_id, extracted.goal)

Пример: самокоррекция плана

Пользователь просит план дня. Без самокоррекции бот часто выдаёт идеальный план «на бумаге», который не работает в жизни (10 задач на 8 часов, без учёта переходов и перерывов).

Через цепочку:

1. Шаг 1. Сгенерировать черновик плана.
2. Шаг 2. Попросить модель оценить черновик по критериям: «реалистично ли по времени? есть ли запас на переключение? нет ли перегрузки в одном слоте?».
3. Шаг 3. Попросить переписать с учётом замечаний.

Что выгадывает: качество плана растёт заметно. Что теряется: задержка втрое и токены втрое. Применять только там, где это оправдано — например, для ежедневного утреннего планирования, не для каждого мелкого вопроса.

Чего не делать

• Не делай длинных цепочек «потому что так интереснее». Каждый шаг — стоимость и задержка. Если работает в один шаг — пусть будет один.
• Не клади в шаги несвязные задачи. Цепочка — про «развить один результат», не про «сделать пять разных дел». Несвязные задачи — это пять отдельных API-вызовов, не цепочка.
• Не путай цепочку с историей чата. История чата — это разговор пользователя с ботом, в нём роль ассистента — Лана. Цепочка — это внутренние шаги обработки одного запроса. В цепочке system prompt и user message — твои, специально для этого шага, не «диалог с пользователем».
• Не теряй промежуточные результаты. Если шаг 2 что-то посчитал, и шаг 3 этого не получил — толку от разбиения нет. Логируй промежуточные ответы (хотя бы в logging.info), чтобы потом понять, на каком шаге что-то пошло не так.

Памятка

• Цепочка — несколько последовательных API-вызовов с передачей выхода в следующий вход.
• Применяй, когда нужны промежуточные результаты, ветвление или самокоррекция.
• Не применяй ради сложности — каждый шаг стоит токенов и времени.
• Самые рабочие цепочки в твоём боте: диагностика целей и самокоррекция плана.
• В каждый шаг передавай нужный контекст явно (история, заметки) — шаги не делятся им автоматически.