Один большой промпт часто становится первым шагом и довольно быстро заводит команду в тупик.
Когда задача становится сложной, новичок добавляет в prompt ещё инструкций:
- сначала прочитай документ;
- потом выдели факты;
- потом проверь противоречия;
- потом напиши резюме;
- потом классифицируй риск;
- потом верни JSON;
- потом не забудь стиль компании;
- потом будь кратким;
- потом не галлюцинируй.
В какой-то момент prompt превращается в договор с демоном. Формально всё прописано. Практически никто не понимает, почему оно иногда работает.
Production-подход другой: разбить работу на этапы.
Пример пайплайна для обработки документа
Задача: из договора извлечь ключевые условия, найти риски и подготовить summary для менеджера.
Плохой вариант: один prompt на 200 строк.
Хороший вариант:
document_preprocess— очистить текст, разбить на секции.clause_extract— извлечь условия в структурированный формат.risk_detect— найти риск-флаги по каждому условию.evidence_attach— привязать риск к цитате/странице.summary_generate— сделать человеческое резюме.quality_check— проверить, что summary не содержит утверждений без evidence.
Каждый этап имеет свой вход, выход, схему и evals.
Почему pipeline лучше
- Легче тестировать.
- Легче менять модель на отдельных этапах.
- Можно использовать маленькую модель там, где не нужна большая.
- Проще повторять только упавший шаг.
- Видно, где именно деградирует качество.
- Можно сохранять промежуточные артефакты.
- Стоимость становится управляемой.
Pipeline сложнее одного API-вызова. В production важнее не короткий код, а сложность, которую можно локализовать, измерить и чинить по частям.
Когда pipeline — оверинжиниринг
Честности ради: не всякую задачу надо резать на этапы. Один вызов достаточен, когда:
- задача укладывается в одно действие: классифицировать, переписать, суммировать короткий текст;
- промежуточные результаты никому не нужны;
- качество на вашем golden dataset уже приемлемо;
- latency критична, а каждый этап добавляет секунды.
Правило простое: этап появляется тогда, когда у него есть свой выход, который вы хотите проверять, кэшировать или переиспользовать. Резать ради красоты схемы — тот же самообман, что и один prompt на 200 строк, только дороже.
Чеклист главы
- Каждый этап пайплайна имеет свой вход, выход и схему.
- Промежуточные артефакты сохраняются — упавший шаг можно перезапустить отдельно.
- Для каждого этапа выбрана своя модель по принципу «самая дешёвая из достаточных».
- Качество измеряется поэтапно: видно, какой шаг деградирует.
- Число этапов оправдано: у каждого есть потребитель его выхода, а не «так красивее».
Практикум
Задача 13.1 — распилить монстра. ⭑⭑
Возьмите типовой «монстр-prompt»: одна инструкция на 100+ строк, которая по тексту вакансии должна извлечь требования, сопоставить с резюме кандидата, оценить соответствие по пятибалльной шкале и написать вежливый отказ или приглашение. Спроектируйте pipeline: этапы, схемы входа/выхода каждого этапа, где LLM, а где обычный код.
Критерии приёмки:
- Схема пайплайна нарисована или описана: этапы, стрелки, форматы данных между ними.
- Минимум один этап не использует LLM вообще (сопоставление извлечённых требований — это работа кода).
- Для каждого этапа указано: какая модель (маленькая/большая — условно), почему.
- Ответ на вопрос: какой этап сломается первым при смене модели и как вы это заметите.
Подсказки:
- Начинайте проектирование с конца: какое финальное решение нужно и из каких проверяемых кусков оно собирается.
- Оценка «соответствует ли кандидат» и генерация «вежливого письма» — задачи с разной ценой ошибки. Их точно не стоит делать одним вызовом.
Задача 13.2 — реализовать и сравнить. ⭑⭑⭑
Реализуйте оба варианта из задачи 13.1: монолитный prompt и pipeline из 3–4 этапов. Прогоните на одном наборе из 10 пар «вакансия + резюме» (можно сгенерировать). Сравните: качество извлечения требований, стабильность формата, суммарные токены, latency.
Критерии приёмки:
- Есть таблица сравнения по четырём измерениям на одинаковых данных.
- Найден хотя бы один вход, где монолит ломается, а pipeline деградирует частично (например, извлечение сработало, оценка — нет).
- Написан вывод: в каких условиях монолит был бы допустим (см. раздел про оверинжиниринг).
Подсказки:
- Не удивляйтесь, если pipeline окажется дороже по токенам: вы платите за контроль, а не за экономию. Экономия придёт, когда дешёвая модель заберёт часть этапов.