Глава 13. Pipeline вместо одного большого промпта

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

Когда задача становится сложной, новичок добавляет в prompt ещё инструкций:

• сначала прочитай документ;
• потом выдели факты;
• потом проверь противоречия;
• потом напиши резюме;
• потом классифицируй риск;
• потом верни JSON;
• потом не забудь стиль компании;
• потом будь кратким;
• потом не галлюцинируй.

В какой-то момент prompt превращается в договор с демоном. Формально всё прописано. Практически никто не понимает, почему оно иногда работает.

Production-подход другой: разбить работу на этапы.

Пример пайплайна для обработки документа

Задача: из договора извлечь ключевые условия, найти риски и подготовить summary для менеджера.

Плохой вариант: один prompt на 200 строк.

Хороший вариант:

1. document_preprocess — очистить текст, разбить на секции.
2. clause_extract — извлечь условия в структурированный формат.
3. risk_detect — найти риск-флаги по каждому условию.
4. evidence_attach — привязать риск к цитате/странице.
5. summary_generate — сделать человеческое резюме.
6. quality_check — проверить, что summary не содержит утверждений без evidence.

Каждый этап имеет свой вход, выход, схему и evals.

Почему pipeline лучше

• Легче тестировать.
• Легче менять модель на отдельных этапах.
• Можно использовать маленькую модель там, где не нужна большая.
• Проще повторять только упавший шаг.
• Видно, где именно деградирует качество.
• Можно сохранять промежуточные артефакты.
• Стоимость становится управляемой.

Pipeline сложнее одного API-вызова. В production важнее не короткий код, а сложность, которую можно локализовать, измерить и чинить по частям.

Когда pipeline — оверинжиниринг

Честности ради: не всякую задачу надо резать на этапы. Один вызов достаточен, когда:

• задача укладывается в одно действие: классифицировать, переписать, суммировать короткий текст;
• промежуточные результаты никому не нужны;
• качество на вашем golden dataset уже приемлемо;
• latency критична, а каждый этап добавляет секунды.

Правило простое: этап появляется тогда, когда у него есть свой выход, который вы хотите проверять, кэшировать или переиспользовать. Резать ради красоты схемы — тот же самообман, что и один prompt на 200 строк, только дороже.

Чеклист главы

• Каждый этап пайплайна имеет свой вход, выход и схему.
• Промежуточные артефакты сохраняются — упавший шаг можно перезапустить отдельно.
• Для каждого этапа выбрана своя модель по принципу «самая дешёвая из достаточных».
• Качество измеряется поэтапно: видно, какой шаг деградирует.
• Число этапов оправдано: у каждого есть потребитель его выхода, а не «так красивее».

Практикум

Задача 13.1 — распилить монстра. ⭑⭑

Возьмите типовой «монстр-prompt»: одна инструкция на 100+ строк, которая по тексту вакансии должна извлечь требования, сопоставить с резюме кандидата, оценить соответствие по пятибалльной шкале и написать вежливый отказ или приглашение. Спроектируйте pipeline: этапы, схемы входа/выхода каждого этапа, где LLM, а где обычный код.

Критерии приёмки:

• Схема пайплайна нарисована или описана: этапы, стрелки, форматы данных между ними.
• Минимум один этап не использует LLM вообще (сопоставление извлечённых требований — это работа кода).
• Для каждого этапа указано: какая модель (маленькая/большая — условно), почему.
• Ответ на вопрос: какой этап сломается первым при смене модели и как вы это заметите.

Подсказки:

1. Начинайте проектирование с конца: какое финальное решение нужно и из каких проверяемых кусков оно собирается.
2. Оценка «соответствует ли кандидат» и генерация «вежливого письма» — задачи с разной ценой ошибки. Их точно не стоит делать одним вызовом.

Задача 13.2 — реализовать и сравнить. ⭑⭑⭑

Реализуйте оба варианта из задачи 13.1: монолитный prompt и pipeline из 3–4 этапов. Прогоните на одном наборе из 10 пар «вакансия + резюме» (можно сгенерировать). Сравните: качество извлечения требований, стабильность формата, суммарные токены, latency.

Критерии приёмки:

• Есть таблица сравнения по четырём измерениям на одинаковых данных.
• Найден хотя бы один вход, где монолит ломается, а pipeline деградирует частично (например, извлечение сработало, оценка — нет).
• Написан вывод: в каких условиях монолит был бы допустим (см. раздел про оверинжиниринг).

Подсказки:

1. Не удивляйтесь, если pipeline окажется дороже по токенам: вы платите за контроль, а не за экономию. Экономия придёт, когда дешёвая модель заберёт часть этапов.