Большие языковые модели пасуют, когда вы просите их сделать слишком много за один раз. Загрузите пятидесятистраничный PDF в окно чата и попросите провести структурированный анализ, оценку рисков и составить резюме для руководства одним махом. Результат обычно поверхностный, запутанный или в корне неверный. Лучший подход — механический. Разделите задачу на отдельные этапы. Передавайте результат первого этапа напрямую на второй и так далее. Anthropic называет этот паттерн «цепочкой промптов» (prompt chaining). Google называет это «последовательным конвейером» (sequential pipeline). Оба названия описывают одно и то же: сборочную линию, где каждая станция выполняет одну конкретную трансформацию.
Как это выглядит на практике
Вместо одного гигантского промпта вы выстраиваете серию небольших, сфокусированных шагов. Представьте команду по комплаенсу, которая обрабатывает оценки безопасности поставщиков. Шаг первый: извлечение чистого текста из отсканированного PDF. Шаг второй: поиск всех упоминаний стандартов шифрования и контроля доступа. Шаг третий: сопоставление этих данных с внутренним чек-листом. Шаг четвертый: подготовка короткой служебной записки для руководителя службы безопасности. Один агент превращает PDF в текст. Следующий агент извлекает конкретные данные из этого текста. Финальный агент пишет резюме на основе этих данных. Ни один из этих шагов не является «звездным», и ни один из них не занимается многозадачностью. Каждая часть хорошо выполняет одну работу.
Вот почему метафора со сборочной линией уместна. На заводе один рабочий не собирает весь автомобиль целиком. Специализация поддерживает высокое качество и сужает спектр возможных ошибок. Та же логика применима и к языковым моделям. Промпт, который запрашивает только извлечение JSON, с меньшей вероятностью начнет галлюцинировать, чем промпт, который в том же запросе требует еще и выражения мнения и форматирования.
Создавайте контрольные точки, а не догадки
Самое слабое звено в любой цепочке — это передача данных. Модель может выдать вежливый отказ, кусок markdown вместо JSON или усеченный ответ. Если этот мусор попадет на второй шаг, вся цепочка развалится. Решение — контрольная точка (gate).
Контрольная точка — это не вызов модели. Это простой код. Вы пишете короткий скрипт, который запускается между шагами. Он может проверять длину вывода, чтобы убедиться, что он не пуст. Он может запустить валидацию по схеме JSON, чтобы подтвердить, что ключи соответствуют ожиданиям третьего шага. Проверка регулярным выражением может подтвердить наличие адреса электронной почты или поля даты еще до того, как будет сформирован следующий промпт. Это останавливает ошибки до того, как вы потратите деньги на плохие результаты. Контрольная точка стоит микросекунды вычислений. Неудачный вызов LLM ниже по цепочке стоит токенов, задержки и вашего душевного спокойствия.
Думайте об этом как о контрольном пункте качества в заводском цеху. Вам не нужен ИИ, чтобы считать детали. Вам нужна линейка.
Когда использовать цепочки, а когда — нет
Цепочка промптов подходит далеко не для каждой задачи. Используйте её, когда работа состоит из фиксированных, повторяющихся шагов. Ежемесячные финансовые отчеты, стандартизированная проверка контрактов и конвейеры анализа логов — хорошие примеры. Если вы можете описать процедуру в виде чек-листа, вы, скорее всего, сможете выстроить цепочку. Также стоит прибегать к цепочкам, когда вам нужна высокая точность при выполнении сложных задач. Разбиение проблемы на этапы заставляет модель обрабатывать по одному логическому слою за раз. Наконец, цепочки проще отлаживать, чем монолитные промпты. Если резюме неверно, вы проверяете извлечение. Если извлечение неверно, вы проверяете исходный текст. У вас есть промежуточные артефакты для изучения.
Избегайте цепочек промптов, если вы заранее не знаете шагов. Исследовательская работа, мозговой штурм без четких рамок или задачи, требующие расследования, не следуют по прямой линии. Также пропускайте этот этап, если скорость — ваш единственный приоритет. Цепочки последовательны; второй шаг не может начаться, пока не завершится первый. Если ваши шаги не зависят друг от друга, запускайте их параллельно. Нет никакого смысла выстраивать цепочку для трех независимых переводов одного и того же документа.
Ловушка жесткости
Обратной стороной всей этой структуры является жесткость. Фиксированная цепочка не может адаптироваться к новым ситуациям. Если поставщик присылает форму с шестью полями, а ваша контрольная точка валидации схемы ожидает пять, линия остановится. Если пользователь загружает документ Word вместо PDF, первый шаг ломается, и остальной части цепочки нечего обрабатывать.
Хуже того, ошибки накапливаются. Ошибка, возникшая на раннем этапе, проходит через всю цепочку. Если экстрактор PDF убирает знак «минус» из финансового показателя, каждый последующий шаг будет воспринимать это неверное число как