Этап 4 — Продвинутые техники
Продвинутые техники нужны, когда один запрос не даёт стабильного качества.
Темы этапа
- Prompt chaining
- Self-reflection
- ReAct (Reason + Act)
- Tool usage / Function calling
- RAG (как часть комплексной схемы)
Почему цепочка лучше гигантского промпта
Один длинный промпт:
- сложнее тестировать,
- сложнее дебажить,
- чаще ломается при небольших изменениях.
Цепочка коротких шагов:
- лучше контролируется,
- легче мониторится,
- проще откатывается по версиям.
Prompt chaining
Разбивай задачу на этапы:
- нормализация входа,
- классификация/маршрутизация,
- генерация ответа,
- пост-валидация.
Self-reflection
Модель сначала формирует ответ, затем проверяет его по чеклисту ограничений.
Важно: self-reflection не заменяет внешнюю валидацию, но снижает долю грубых ошибок.
ReAct
ReAct сочетает рассуждение и действие:
- план,
- вызов инструмента,
- наблюдение результата,
- корректировка.
Это полезно для агентных сценариев.
Tool usage и RAG
Продвинутые техники особенно сильны, когда модель подключена к:
- API,
- БД,
- файловым источникам,
- поиску.
Что означает контроль в продвинутых workflow
Продвинутый prompting — это не просьба к модели писать более длинные рассуждения. Это управление тем, где именно принимаются решения. Цепочка разбивает решения на небольшие этапы, и у каждого этапа появляются понятный вход, выход и правило проверки. Self-reflection добавляет внутреннюю самопроверку, но при высокой цене ошибки её всё равно нужно проверять внешним кодом. ReAct добавляет действия, а значит добавляет риск: модель может вызвать инструмент не вовремя, если prompt не задаёт строгий критерий вызова.
Перед применением этих паттернов нужно определить состояние workflow. Система должна понимать, что сейчас происходит: классификация, retrieval, черновик, валидация или выполнение действия. Если эти состояния смешаны в одном prompt-е, отладка становится сложной, потому что непонятно, где именно возникла ошибка.
| Техника | Лучшее применение | Обязательный контроль |
|---|---|---|
| Prompt chaining | Многоэтапные задачи | Контракты входа/выхода этапов |
| Self-reflection | Ловля явных нарушений ограничений | Внешняя валидация после проверки |
| ReAct | Задачи с наблюдением и действием | Критерии и лимиты вызова инструментов |
| RAG | Фактические ответы по источникам | Проверка retrieval и цитирования |
Что нужно понимать
- Почему один большой промпт хуже управляемой цепочки.
- Как подключать внешние данные/инструменты без потери контроля.
Объяснение для новичка
Продвинутые техники не означают «заставить модель думать длиннее». Они нужны, когда задача состоит из нескольких разных решений. Например, support-бот сначала должен понять тип обращения, потом найти документы, потом сформировать ответ, потом проверить формат и безопасность. Если всё это поместить в один огромный prompt, трудно понять, где произошла ошибка.
Prompt chaining разбивает процесс на маленькие шаги. У каждого шага есть вход и выход. Первый prompt может только классифицировать запрос. Второй — выбрать источники. Третий — написать черновик. Четвёртый — проверить, что ответ не нарушает правила. Такой workflow проще тестировать: если классификация неверная, не нужно переписывать генерацию ответа.
Self-reflection — это самопроверка модели по чеклисту. Например после черновика модель получает задание: «Проверь, есть ли в ответе неподтверждённые факты, лишняя уверенность и нарушение формата». Но self-reflection не заменяет backend validation. Модель может не заметить свою ошибку, поэтому критичные проверки должны быть внешними.
ReAct нужен, когда модель может действовать: вызвать поиск, API, калькулятор или базу данных. Важно задавать критерий вызова инструмента: когда вызывать, какие параметры разрешены, сколько попыток допустимо, что делать при ошибке. Без этих правил агент может вызвать инструмент слишком рано, слишком часто или с неправильными данными.
Мини-сценарии из практики
- Один огромный промпт решает 5 задач сразу и даёт нестабильный результат: после декомпозиции в цепочку качество растёт.
- Модель делает неверный шаг в середине reasoning: self-reflection на промежуточном результате снижает ошибку.
- Tool usage подключён, но вызывает «лишние» запросы: не задан критерий, когда инструмент действительно нужен.
Быстрые правила принятия решений
- Если задача многосоставная, разбивай её на этапы с отдельными проверками.
- Если цена ошибки высока, добавляй этап самопроверки перед финальным ответом.
- Инструменты вызывай только при явной потребности в внешних данных/действиях.
Вопросы для самопроверки
- Почему цепочка коротких промптов часто надёжнее одного большого?
- Где в цепочке логично ставить контрольные точки качества?
- Как не превратить ReAct в хаотичный «перебор инструментов»?