Промпти для міркувань і логіки

Основи ШІ-інженерії | Складність: [COMPLEX] | Час: 80-100 хв

Передумови: Основи промптів із цього розділу, а також впевнене порівняння виходів моделі з контрактом завдання. Якщо вам спершу потрібна базова лексика контрактів, поверніться до вступу з основ промптів у покажчику розділу.

Що ви зможете зробити

До кінця цього модуля ви зможете:

Проєктувати промпти для пробудження міркувань у завданнях на математику, діагностику, планування, класифікацію та прийняття рішень — не перетворюючи кожен запит на довгий ритуал ланцюга міркувань.
Відрізняти промпти для міркувань від моделей міркувань, вирішуючи, коли каркас промпту допомагає звичайній моделі, а коли модель із нативним бюджетом обдумування варто залишити з її власним внутрішнім слідом.
Порівнювати zero-shot CoT, few-shot CoT, самоузгодженість, промптинг «від простого до складного», «сплануй і виконай», верифікаторні промпти, ReAct і дерево думок як різні точки контролю витрат і керування.
Оцінювати нативні засоби контролю бюджету міркувань у API різних провайдерів, називаючи, що саме вони бюджетують, чого не гарантують і коли додаткова затримка виправдана.
Побудувати невеликий експеримент, у якому одне завдання надсилається з трьома стратегіями міркування, результати порівнюються за рубрикою та фіксується, яка стратегія має увійти до багаторазової бібліотеки промптів.

Чому цей модуль важливий

Основи промптів навчили вас писати компактний контракт завдання: завдання, контекст, обмеження та форма виходу. Промпти для міркувань додають друге запитання. Вони запитують, скільки когнітивної роботи модель має виконати перед відповіддю і яка частина цієї роботи має спрямовуватися промптом, а не самою родиною моделей.

Це розрізнення важливе, тому що найвідоміша порада щодо ланцюга міркувань була відкрита в попередню епоху моделей. Фраза «Let’s think step by step» стала пам’ятною, оскільки Kojima та ін. показали, що проста zero-shot підказка могла розблокувати кращі багатокрокові міркування на кількох арифметичних, символьних і логічних завданнях у старіших попередньо натренованих та інструктивно доналаштованих моделях. Урок ніколи не полягав у тому, що кожен промпт має показувати довгий чорновик.

Урок полягав у тому, що деякі моделі потребували зовнішньої підказки, щоб припинити відповідати через доповнення шаблону й почати розкладати завдання. Сучасні моделі міркувань змінили базову лінію. Передові провайдери тепер надають нативні засоби контролю міркувань або обдумування, тож модель може витратити додатковий прихований або структурований бюджет обдумування перед остаточною відповіддю.

Це означає, що робота промпт-інженера зміщується від «примусити до ланцюга міркувань» до «обрати правильну поверхню міркування». Іноді найкращий промпт каже «розв’яжи уважно й поверни лише остаточну відповідь плюс перевірки». Іноді найкраще налаштування API підвищує зусилля міркування, тоді як видимий промпт залишається простим.

Іноді найкращий робочий процес розділяє роботу на планувальника, виконавця та верифікатора, оскільки завдання потребує системи, а не розумнішого абзацу. Режим відмови легко пропустити, тому що погані промпти для міркувань часто виглядають вражаюче. Відповідь із пронумерованими кроками, причинно-наслідковою мовою та впевненим висновком може здаватися ґрунтовнішою за коротку відповідь.

Вона також може бути повільнішою, дорожчою, більш вразливою до заякорювання та не більш правильною. Примушування до видимого міркування для простого пошуку може витрачати токени без підвищення якості. Нав’язування покрокового каркасу справжній моделі міркувань може змістити модель у бік слабкого плану користувача замість того, щоб дозволити моделі використати її нативний прихований слід.

Прохання «поясни своє міркування» також може змусити модель раціоналізувати відповідь, яку вона вже обрала, створюючи відшліфовану історію, а не надійний доказ. Цей модуль розглядає промпти для міркувань як інженерні інструменти. Ви навчитеся, коли використовувати легку підказку, коли надавати приклади, коли брати вибірку з кількох шляхів, коли розкладати завдання, коли запитувати окремого верифікатора і коли витрачати токени на пошук або бюджет міркувань.

Ви також навчитеся, коли зупинитися. Майстерність рівня senior — не застосовувати кожен патерн міркування. Майстерність рівня senior — підібрати клас завдання, можливості моделі, бюджет затримки, потребу в аудиті та ціну помилки.

Бойова історія

Гіпотетичний сценарій: платформна команда мала зрілий промпт для тріажу інцидентів, написаний для чат-моделі без міркувань. Старий промпт починався з довгого каркасу: визнач симптоми, перелічи гіпотези, міркуй покроково, оціни кожну причину, переглянь оцінку після кожного рядка журналу, потім відповідай. На старій моделі цей каркас допомагав, оскільки сповільнював модель і примушував відповідь до форми, придатної для діагностичного аналізу.

Пізніше команда перенесла той самий робочий процес на передове розгортання з міркуваннями та ввімкненим обдумуванням. Спочатку якість впала. Модель надто буквально слідувала успадкованому каркасу, переоцінювала ранні гіпотези та витрачала видимий бюджет виходу на описування перевірок, які нова модель уже могла виконувати внутрішньо.

Виправленням був не більший промпт. Виправленням було прибрати більшу частину старого вступу з ланцюгом міркувань, залишити контракт доказів інциденту, підвищувати бюджет обдумування лише для випадків із кількома сигналами та просити стислу відповідь із доказами, невизначеністю та наступними командами верифікації. Урок не в тому, що старі промпти погані.

Урок у тому, що промпт може стати прошарком сумісності для вчорашньої моделі. Коли родина моделей змінюється, промпти для міркувань потрібно перевалідовувати, як будь-який інший інтерфейс.

Кут промпт-інженерії

Нещодавно об’єднаний модуль Reasoning-Model RL: GRPO, RLVR та DeepSeek-R1 пояснює, як поведінку міркування можна тренувати, винагороджувати й оцінювати всередині розробки моделей. Цей модуль залишається на етапі інференсу. Ви тут не обираєте PPO, GRPO чи тренувальний цикл із верифікатором.

Ви обираєте промпт, стратегію вибірки, послідовність інструментів, верифікаторний промпт і бюджет міркувань API для завдання, яке потрібно розв’язати сьогодні. Ця межа тримає два модулі взаємодоповнюючими. Модуль про GRPO запитує, як модель навчається міркувати під тиском винагороди.

Цей модуль запитує, як розробник застосунку має пробуджувати, обмежувати й верифікувати міркування від моделі, яка вже існує. Якщо ви запам’ятаєте лише одне речення, запам’ятайте це: промпти для міркувань є зовнішніми каркасами, тоді як моделі міркувань мають внутрішню або серверну машинерію міркувань. Зовнішні каркаси корисні, коли додають відсутню структуру.

Вони стають шкідливими, коли дублюють, обмежують або відволікають модель, яка вже має кращу процедуру міркування.

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

Промпт для міркувань — це патерн інструкції, який просить модель виконати проміжну когнітивну роботу. Він може казати «міркуй покроково», надавати опрацьовані приклади, розкладати завдання на підзадачі, брати вибірку з кількох кандидатних шляхів або просити окремого верифікатора критикувати відповідь. Каркас живе в промпті або обв’язці.

Він видимий для вас, легкий для редагування і часто переносний між провайдерами. Модель міркувань — інша річ. Це родина моделей або режим обслуговування, натренований і налаштований витрачати додаткові обчислення на складні задачі перед створенням остаточної відповіді.

Процес міркування може бути прихованим, підсумованим, зашифрованим як стан або видимим лише через метадані — залежно від постачальника й моделі. Важливим засобом контролю є не фраза «міркуй покроково». Важливим засобом контролю є здатність моделі виділяти обчислення на міркування, іноді через нативний параметр API, який встановлює зусилля, бюджет токенів або адаптивну поведінку.

Це розрізнення змінює проєктування промпту. На старішій інструктивній моделі zero-shot підказка CoT може перетворити одноетапну відповідь на багатокрокову спробу. На сучасній моделі міркувань та сама підказка може здебільшого змінити видимий стиль остаточної відповіді.

Вона також може споживати бюджет виходу, заохочувати жорсткий шлях або розкривати часткове обґрунтування користувачеві, який потребував короткого рішення. Ставтеся до промпту як до поверхні керування, а не як до доказу того, що модель поміркувала правильно. Практичне питання — чи потребує завдання зовнішньої структури.

Якщо завдання має приховані залежності, промпт із декомпозицією може допомогти, оскільки змінює план роботи. Якщо завдання має одну верифіковану відповідь, самоузгодженість може допомогти, оскільки незалежні шляхи можуть зійтися до того самого результату. Якщо завдання — простий пошук, каркас ланцюга міркувань зазвичай додає витрат, не змінюючи відповіді.

Якщо завдання обслуговується моделлю міркувань із налаштованим бюджетом обдумування, опишіть результат і критерії верифікації перед тим, як приписувати шлях. Таблиця нижче є корисним класифікатором першого наближення.

Клас завдання	Каркас CoT імовірно допомагає?	Модель міркувань імовірно допомагає?	Бажана поверхня промпту
Простий пошук у наданому тексті	Ні	Зазвичай ні	Пряма відповідь із цитатою або посиланням на поле
Багатокрокова арифметика або символьні маніпуляції	Часто	Часто	Мінімальна підказка до міркування або зусилля міркування плюс фінальна перевірка
Тріаж інцидентів зі змішаними доказами	Іноді	Часто	Таблиця доказів, гіпотези, відсутня інформація, прохід верифікатора
Довге планування із залежностями	Часто	Часто	Декомпозиція, «сплануй і виконай», контрольні точки інструментів
Творча ідеація без об’єктивної відповіді	Іноді	Іноді	Різноманітні кандидати та критерії відбору, а не довгий CoT
Рекомендація, чутлива до безпеки	Самого CoT недостатньо	Іноді	Окремий верифікатор безпеки/доказів та обмеження політик

Не читайте таблицю як твердження про бенчмарки. Читайте її як контрольний список маршрутизації. Модель, домен, якість даних і рубрика оцінювання все одно вирішують відповідь.

Для кожного повторюваного робочого процесу проведіть невелике порівняння перед стандартизацією промпту. Порівняння має включати щонайменше один прямий промпт, один промпт із каркасом та один варіант із нативними міркуваннями провайдера, коли вони доступні.

Мінімальне правило рішення

Використовуйте видимий каркас міркування, коли каркас змінює структуру завдання. Наприклад, «розклади цю міграцію на кроки, впорядковані за залежностями, перш ніж складати runbook» змінює роботу, оскільки граф залежностей є артефактом. Використовуйте нативне зусилля міркування моделі, коли завдання складне, але бажана остаточна відповідь стисла.

Наприклад, «розв’яжи конфлікт розкладу та поверни обраний план плюс два відхилені альтернативні варіанти» виграє від приватного пошуку без показу кожного шляху. Використовуйте верифікаторний промпт, коли правильність можна перевірити за критеріями, відокремленими від чернетки. Наприклад, «перевір, чи план порушує будь-яке заявлене обмеження розгортання» дає моделі іншу роль і вужчу ціль.

Використовуйте міркування на основі пошуку лише тоді, коли неправильні відповіді достатньо дорогі, щоб виправдати кілька гілок. Наприклад, план виправлення на продакшені може виправдати генерацію кандидатів, оцінювання гілок і бектрекінг. Пошук назви функції — ні.

Чому «поясни своє міркування» недостатньо

«Поясни своє міркування» просить розповідь. Воно не визначає, чи має міркування бути вичерпним, достовірним, стислим, перевіреним або відокремленим від остаточної відповіді. Воно також запрошує модель зробити так, щоб відповідь звучала обґрунтованою постфактум.

Це корисно для навчання, але слабко для продакшен-рішень. Кращий промпт називає артефакт міркування, який вам потрібен. Просіть «припущення, докази та нерозв’язані ризики», коли проблема в невизначеності.

Просіть «підзадачі та порядок залежностей», коли проблема в декомпозиції. Просіть «кандидатні відповіді та голосування більшістю», коли проблема в крихкому одношляховому декодуванні. Просіть «висновки верифікатора за цими критеріями приймання», коли проблема в правильності.

Вихід має відповідати роботі людини-рев’юера. Коли рев’юеру потрібно аудитувати докази, просіть посилання на докази та висновки. Коли рев’юеру потрібна лише відповідь, просіть відповідь і коротку перевірку впевненості.

Коли рев’юер — програма, просіть структуровані поля та запускайте окремого верифікатора. Промпти для міркувань добрі лише тоді, коли вони полегшують наступний крок рев’ю.

Варіанти ланцюга міркувань

Промптинг із ланцюгом міркувань просить модель створити або використати проміжне міркування перед остаточною відповіддю. Початкова родина технік важлива, тому що вона дала практикам спосіб пробуджувати багатокрокову поведінку без зміни ваг моделі. Вона також створила погану звичку: ставитися до «CoT» як до однієї техніки, а не родини засобів контролю.

Zero-shot CoT є найменшим членом родини. Він додає підказку на кшталт «Let’s think step by step» перед відповіддю. Kojima та ін. показали, що ця проста підказка покращила кілька бенчмарків міркувань для моделей, які вони досліджували.

Підказка приваблива, тому що її дешево спробувати, легко запам’ятати, і вона не потребує прикладів. Вона також груба. Вона не навчає специфічного для завдання патерну міркування, не обмежує остаточну відповідь і не верифікує результат.

Few-shot CoT додає приклади, які показують бажаний патерн міркування. Замість того, щоб просто казати моделі міркувати, він демонструє, як задачу слід розкласти й розв’язати. Це допомагає, коли завдання має багаторазову структуру: текстові задачі, обґрунтування класифікації, застосування правил або структурована діагностика.

Ризик — перенавчання на прикладах. Модель може копіювати поверхневу форму прикладів, хибні припущення або багатослівність, а не базову стратегію міркування. Самоузгодженість змінює декодування, а не лише видимий промпт.

Wang та ін. запропонували брати вибірку з різноманітних шляхів міркування й обирати найбільш узгоджену остаточну відповідь. У прикладних термінах ви запитуєте модель кілька разів, видобуваєте остаточні відповіді й використовуєте голосування або верифікатора для вибору результату. Це може підвищити надійність, коли задача має одну правильну відповідь, але багато можливих шляхів розв’язання.

Це менш корисно, коли завдання суб’єктивне, недоспецифіковане або дороге для вибірки. Наступна таблиця розділяє варіанти за тим, що ви контролюєте.

Варіант	Що ви надаєте	За що платите	Найкраще підходить	Основний ризик
Zero-shot CoT	Коротка підказка до міркування	Одна довша відповідь	Швидкий тест на старіших моделях або моделях без міркувань	Багатослівна раціоналізація без кращої точності
Few-shot CoT	Опрацьовані приклади з міркуванням	Токени промпту плюс одна відповідь	Повторювана родина завдань зі стабільним патерном	Приклади навчають випадкового стилю або припущень
Самоузгодженість	Кілька вибіркових шляхів міркування	Кілька завершень і логіка вибору	Об’єктивні відповіді з різноманітністю шляхів	Вартість швидко зростає, і голосування може винагородити поширені неправильні відповіді

Використовуйте zero-shot CoT як зонд, а не як усталену поведінку. Якщо пряма відповідь зазнає невдачі через пропуск кроків, спробуйте легку підказку. Якщо підказка допомагає, замініть її більш специфічним для завдання артефактом перед продакшеном.

Наприклад, «перелічи обмеження, розв’яжи, потім перевір остаточну відповідь» зазвичай краще, ніж загальна покрокова фраза, оскільки називає роботу, яка вам потрібна. Використовуйте few-shot CoT, коли приклади визначають метод. Приклади мають бути короткими, правильними, репрезентативними та відокремленими від живого вводу.

Вони також мають слідувати тому самому вихідному контракту, що й бажана відповідь. Якщо приклади містять довгі приховані обчислення, а продакшен-відповідь має бути стислою, показуйте стислий підсумок міркування, а не розлогий чорновик. Використовуйте самоузгодженість, коли один вибірковий шлях надто крихкий.

Одна генерація може зробити хибний поворот на початку й ніколи не відновитися. Кілька шляхів зменшують цю крихкість, якщо завдання має стабільну остаточну відповідь. Однак голосування більшістю не є оракулом істини.

Якщо всі вибірки поділяють одну хибну концепцію або беруть одне хибне припущення з промпту, голосування лише робить неправильну відповідь більш стабільною на вигляд.

Шаблони промптів

Прямий промпт має залишатися вашою базовою лінією. Він дає вам найшвидшу, найдешевшу відповідь і показує, чи модель уже справляється із завданням. Якщо базова лінія проходить вашу рубрику, не додавайте CoT лише тому, що це здається серйознішим.

Завдання: Розв'яжіть головоломку розкладу нижче.
Вихід: Поверніть остаточне призначення та одне речення, що називає вирішальне обмеження.

Zero-shot зонд CoT має бути малим. Він має просити остаточну відповідь окремо, щоб ви могли порівняти остаточну правильність, не відволікаючись на пояснення.

Завдання: Розв'яжіть головоломку розкладу нижче.
Метод: Опрацюйте обмеження уважно перед відповіддю.
Вихід: Поверніть "Остаточне призначення:" з відповіддю, потім "Перевірка:" з одним реченням.

Few-shot CoT промпт має показувати формат міркування, не ховаючи живе завдання. Використовуйте один або два приклади, коли патерн зрозумілий. Використовуйте більше лише тоді, коли межа завдання достатньо тонка, щоб виправдати додаткові токени промпту.

Приклад:
Ввід: A має бути перед B. C не може бути першим. Впорядкуйте A, B, C.
Підсумок міркування: A перед B залишає A-C-B або C-A-B. C не може бути першим, отже залишається A-C-B.
Остаточно: A-C-B

Новий ввід:
{{puzzle}}

Поверніть ті самі два поля: Підсумок міркування та Остаточно.

Обв’язка самоузгодженості зазвичай знаходиться поза промптом. Вона бере вибірку з кількох завершень, видобуває остаточну відповідь і вибирає голосуванням або верифікатором. Якщо ви реалізуєте її вручну, запишіть кількість вибірок, температуру, правило видобування та правило розв’язання нічиєї.

Інакше пізніший рев’юер не зможе відтворити, чому одна відповідь перемогла.

Запустіть N незалежних вибірок з однаковим контрактом завдання.
Видобудьте лише значення після "Остаточно:" з кожної вибірки.
Оберіть відповідь із найбільшою кількістю голосів.
Якщо голоси рівні, надішліть рівні відповіді верифікаторному промпту з початковими обмеженнями.

Коли CoT надлишковий

CoT надлишковий, коли завдання не потребує проміжного міркування. Якщо відповідь буквально присутня в наданому тексті, просіть видобування з цитатою. Якщо завдання — перетворення формату, використовуйте схему або приклад, а не слід міркування.

Якщо модель уже розв’язує завдання прямо з високою надійністю, каркас — це здебільшого затримка і стиль. CoT також надлишковий, коли нативний режим міркування моделі виконує важку роботу. Для нативних режимів обдумування, налаштувань зусилля міркування та контролів бюджету обдумування провайдер уже виділяє приховані або структуровані ресурси міркування.

У такому разі ваш промпт має визначати мету, обмеження, межі доказів і форму остаточної відповіді. Приписування списку кроків, розробленого людиною, може бути корисним для відповідності вимогам або аудиту, але його варто тестувати, а не припускати. Найкращий компроміс — часто «підсумок міркування» замість повного міркування.

Попросіть модель надати остаточну відповідь, ключове обмеження, яке вирішило відповідь, і коротку верифікацію. Це дає рев’юеру достатньо для аналізу, не змушуючи модель викривати або імітувати довгий чорновик. Для чутливих до безпеки налаштувань використовуйте окремого верифікатора замість того, щоб просити ту саму відповідь виправдати себе.

Промптинг із декомпозицією

Промптинг із декомпозицією розбиває складне завдання на менші завдання перед розв’язанням. Він відрізняється від загального CoT тим, що проміжний артефакт — це не просто розповідь. Артефакт — це набір підзадач, план, граф або порядок виконання, який можна перевірити.

Декомпозиція допомагає, коли завдання має структуру залежностей. Промптинг «від простого до складного» (Least-to-Most), представлений Zhou та ін., просить модель розкласти складну задачу на простіші підзадачі й розв’язати їх послідовно. Кожна розв’язана підзадача стає контекстом для наступної.

Цей патерн корисний, коли остаточна задача складніша за приклади або коли важливе узагальнення від легкого до складного. Для промпт-інженерів ключова ідея — не точне налаштування бенчмарку зі статті. Ключова ідея в тому, що розв’язання менших задач може створити надійні проміжні кроки.

Промптинг «сплануй і виконай» (plan-and-execute) відокремлює «виріши, що робити» від «зроби це». Планувальник пише компактний план із залежностями, припущеннями та умовами зупинки. Виконавець виконує кожен крок, часто використовуючи інструменти або документи.

Верифікатор перевіряє, чи результат задовольняє початкову мету. Цей патерн підходить для агентної роботи, оскільки виходи інструментів можуть змінювати наступний крок. Структурований граф завдань іде на один рівень далі.

Замість лінійного списку промпт просить вузли, залежності, входи, виходи та перевірки валідації. Це корисно, коли кілька підзадач можуть виконуватися паралельно або коли одне рішення обмежує інше. Це надмірність для малої відповіді, але цінність для міграцій, реагування на інциденти, планування релізів і багатофайлових змін коду.

Діаграма: Вибір стратегії декомпозиції

+------------------+       +----------------------+       +----------------------+
| Zero-shot CoT    |       | Від простого до      |       | Дерево думок         |
|                  |       | складного            |       |                      |
+------------------+       +----------------------+       +----------------------+
| Один шлях        |       | Впорядковані         |       | Розгалуження         |
| Низька вартість  |       | підзадачі            |       | кандидатів           |
| налаштування     |       | Середня вартість     |       | Висока вартість      |
| Добрий зонд      |       | налаштування         |       | налаштування         |
| Слабкий          |       | Добре для            |       | Добре для пошуку     |
| аудиторський     |       | залежностей          |       | Відсікання, придатне |
| слід             |       | Послідовність,       |       | для рев'ю            |
|                  |       | придатна для рев'ю   |       |                      |
+------------------+       +----------------------+       +----------------------+
         |                          |                              |
         v                          v                              v
Використовуйте, коли      Використовуйте, коли         Використовуйте, коли кілька
модель пропускає          задачу потрібно              правдоподібних шляхів
очевидні кроки, але       зробити легшою через         конкурують, а хибні
завдання мале.            розв'язані частини.          гілки дорого коштують.

Діаграма навмисно практична. Вона не каже, що дерево думок завжди краще за «від простого до складного». Вона каже, що дерево думок витрачає більше бюджету на дослідження гілок, тож завдання має виправдовувати цей бюджет.

Для більшості повсякденних інженерних промптів достатньо невеликої декомпозиції або циклу «сплануй і виконай».

Шаблон «від простого до складного»

Використовуйте цей шаблон, коли остаточне завдання можна розкласти на простіші підзадачі, відповіді на які живлять пізніші кроки. Промпт просить спочатку декомпозицію, потім розв’язує кожну підзадачу, потім дає остаточну відповідь.

Завдання: Розв'яжіть задачу нижче.

Спочатку розкладіть задачу на найменші корисні підзадачі.
По-друге, розв'яжіть підзадачі в порядку залежностей.
По-третє, використайте розв'язані підзадачі для отримання остаточної відповіді.

Вихід:
- Підзадачі
- Розв'язання
- Остаточна відповідь
- Перевірка за початковими обмеженнями

Поширена помилка — дозволити декомпозиції стати декоративною. Якщо підзадачі не живлять розв’язання, модель просто написала довшу відповідь. Попросіть модель явно посилатися на відповіді попередніх підзадач у пізніших кроках.

Це робить ланцюг залежностей достатньо видимим для аналізу.

Шаблон «сплануй і виконай»

Використовуйте «сплануй і виконай», коли завдання потребує дій, викликів інструментів або кількох документів. Планувальник має бути достатньо коротким для рев’ю. Виконавцю слід дозволити переглядати план лише тоді, коли нові докази спростовують припущення.

Завдання: Виконайте описану нижче інженерну зміну.

Фаза планування:
- Визначте необхідні файли або джерела даних.
- Перелічіть кроки в порядку залежностей.
- Назвіть припущення та умови зупинки.

Фаза виконання:
- Виконуйте по одному кроку за раз.
- Після кожного кроку фіксуйте докази та будь-яку зміну плану.

Остаточний вихід:
- Підсумок змін
- Перевірені докази
- Залишкові ризики

Цей патерн важливий для ШІ-агентів, оскільки промпт стає легкою обв’язкою. Він не дає моделі перестрибувати безпосередньо від мети до редагування. Він також дає людині-рев’юеру контрольні точки: чи план відповідав завданню, чи виконання слідувало доказам, і чи остаточна відповідь закрила початковий контракт?

Шаблон структурованого графа завдань

Використовуйте граф завдань, коли робота має розгалужені залежності. Граф не потребує важкої формальної мови. Таблиці часто достатньо.

Поверніть граф завдань із такими стовпцями:

Вузол: короткий ідентифікатор
Мета: що цей вузол вирішує або виробляє
Входи: необхідні докази або попередні вузли
Вихід: артефакт, створений вузлом
Валідація: як перевірити вузол
Залежить від: ідентифікатори вузлів, які мають завершитися першими

Графові промпти допомагають уникнути поширеної помилки планування: виконання роботи в порядку її згадування, а не в порядку залежностей. Вони також виявляють паралельну роботу. Якщо два вузли не мають спільної залежності, обв’язка може запустити їх незалежно або доручити різним агентам дослідити їх.

Саме тут промпт-інженерія починає торкатися інженерії обв’язки.

Режими відмови декомпозиції

Декомпозиція може зазнати невдачі, створюючи хибну впевненість. Акуратний список підзадач може приховати той факт, що модель вигадала відсутню інформацію. Вимагайте, щоб декомпозиція позначала невідомі входи.

Якщо підзадачу неможливо розв’язати з наданого контексту, правильна відповідь — «заблоковано через відсутні докази», а не вгадане значення. Декомпозиція також може зазнати невдачі, заморожуючи ранній поганий план. Якщо перша підзадача неправильна, кожна наступна відповідь може успадкувати помилку.

Для агентних робочих процесів додайте правило перегляду: після появи нових доказів порівняйте їх із планом і перегляньте лише зачеплені вузли. Це правило не дає моделі або сліпо слідувати застарілому плану, або постійно переплановувати без прогресу. Нарешті, декомпозиція може бути надто дорогою.

Якщо завдання — одноетапне перетворення, декомпозиція додає затримку та навантаження рев’ю. Тест простий: якщо видалення декомпозиції не робить відповідь важчою для перевірки, вона вам, імовірно, не потрібна. Використовуйте декомпозицію, коли вона створює корисний проміжний артефакт, а не коли вона просто прикрашає відповідь.

Верифікація міркувань

Верифікація міркувань використовує окремий промпт, прохід, модель, інструмент або рубрику для перевірки виходу. Верифікатор — це не те саме, що просити початкову відповідь «бути обережною». Він отримує початкове завдання, запропоновану відповідь та явні критерії.

Його робота — знаходити порушення, відсутні докази, непослідовні кроки або небезпечні припущення. Верифікаторний промпт працює найкраще, коли критерії є зовнішніми щодо чернетки. Наприклад, схема, тестовий набір, політика, арифметичний ключ відповідей, критерії приймання або набір доказів інциденту дають верифікатору щось конкретне для порівняння.

Верифікатор працює гірше, коли єдиний критерій — «чи звучить це розумно?» У такому разі він може стати другою генерацією того самого упередження. Найпростіший верифікаторний промпт є змагальним, але вузьким.

Він не має спочатку переписувати відповідь. Він має проаналізувати відповідь, повернути висновки та вказати точний порушений критерій. Лише після того, як висновки перелічені, промпт для виправлення має створити нову відповідь.

Завдання верифікатора: Перевірте запропоновану відповідь за початковим завданням і критеріями.

Входи:
<task>
{{original_task}}
</task>

<criteria>
{{acceptance_criteria}}
</criteria>

<proposed_answer>
{{draft_answer}}
</proposed_answer>

Вихід:
- Рішення пройшов/не пройшов
- Висновки, кожен прив'язаний до одного критерію
- Відсутні докази
- Мінімальна пропозиція з виправлення

Самоверифікація працює для деяких класів задач. Вона може виявляти порушення формату, пропущені розділи, арифметичні помилки, суперечності між полями відповіді та очевидні непідкріплені твердження. Вона особливо корисна, коли відповідь можна перевірити за рубрикою, яка не була вже задоволена стилем.

Вона також допомагає, коли верифікаційний промпт змінює роль моделі з творця на аудитора. Самоверифікація зазнає невдачі, коли моделі бракує доказів, необхідних для перевірки відповіді. Вона також зазнає невдачі, коли чернетка й верифікатор поділяють одну хибну концепцію, коли критерії приймання розмиті або коли вихід переконливий, але не обґрунтований.

Якщо завдання є високоризиковим, використовуйте іншу модель, детермінований інструмент, людину-рев’юера або тестову обв’язку на додачу до самоверифікації. Важливий момент — незалежність. Верифікатор, який бачить ті самі оманливі докази й отримує ту саму широку інструкцію, може відтворити ту саму помилку.

Підвищуйте незалежність, змінюючи роль, звужуючи критерії, приховуючи чернетку до повторного формулювання критеріїв, використовуючи окрему родину моделей або додаючи перевірки на основі інструментів. Не називайте це верифікацією, якщо це лише ще один прохід написання.

Патерни верифікатора

Використовуйте верифікатор доказів, коли твердження мають бути обґрунтовані наданими документами. Верифікатор перевіряє, чи кожне твердження має рядок джерела, цитату або запис журналу. Він має розрізняти «непідкріплене» та «хибне».

Непідкріплене означає, що набір джерел не доводить твердження. Хибне означає, що набір джерел суперечить твердженню. Використовуйте верифікатор логіки, коли обмеження взаємодіють.

Для розкладу, впорядкування залежностей, рішень контролю доступу або головоломкоподібних завдань верифікатор має переформулювати обмеження та перевірити остаточну відповідь за кожним із них. Це краще використання видимого міркування, ніж просити початкову відповідь описувати кожен крок. Вихід верифікатора — це контрольний список.

Використовуйте верифікатор безпеки, коли відповідь може спричинити шкоду або порушення політики. Верифікатор перевіряє розкриття даних, припущення щодо дозволів, деструктивні операції, межі приватності та умови ескалації. Цей модуль лише вводить патерн.

Наступний модуль, Безпека та оцінювання промптів у плані розділу, глибше розглядає безпеку та оцінювання ланцюгів міркувань. Використовуйте контрактний верифікатор, коли вихід потрапить до бібліотеки промптів або автоматизації. Верифікатор перевіряє плейсхолдери, поля вводу, схему виходу, поведінку відмови, режими відмови та нотатки версій.

Це безпосередньо пов’язано з Бібліотеками та контрактами промптів у плані розділу, де промпт стає підтримуваним артефактом, а не одноразовим повідомленням.

Виправлення після верифікації

Не просіть верифікатора мовчки виправити все. Мовчазне виправлення приховує патерн дефекту від рев’юера. Просіть спочатку висновки, потім виправлення окремим кроком, використовуючи лише ці висновки та початкове завдання.

Це створює невеликий аудиторський слід. Ремонтний промпт має зберігати правильні частини чернетки. Інакше модель може виправити одну проблему, регресуючи іншу.

Добра інструкція з виправлення каже: «Перегляньте лише розділи, названі у висновках верифікатора, збережіть усі розділи, що пройшли перевірку, і повторно запустіть контрольний список приймання.» Це повільніше, ніж «спробуй ще раз», але легше для довіри. Коли верифікація неодноразово зазнає невдачі, припиніть змінювати промпти й проаналізуйте завдання.

Докази можуть бути недостатніми, критерії можуть конфліктувати, або модель може бути неправильним інструментом. Повторювані цикли самоверифікації можуть створювати ілюзію строгості, тоді як система залишається недоспецифікованою. Хороші промпт-інженери знають, коли промпт більше не є вузьким місцем.

Дерево думок і міркування на основі пошуку

Дерево думок узагальнює ланцюг міркувань від одного шляху до багатьох кандидатних шляхів. Yao та ін. описують фреймворк, де модель досліджує зв’язні проміжні думки, оцінює вибори та може дивитися вперед або повертатися назад. У прикладних термінах ви генеруєте кілька кандидатних наступних кроків, оцінюєте їх, зберігаєте перспективні гілки й продовжуєте, поки не з’явиться остаточна відповідь.

Міркування на основі пошуку корисне, коли перший правдоподібний шлях часто хибний. Приклади включають комбінаторні головоломки, планування за обмежень, проєктування стратегій, складне налагодження та рішення, де ранні припущення можуть замкнути відповідь у пастці. Метод не безкоштовний.

Якщо ви генеруєте три гілки для чотирьох кроків, ви вже помножили виклики й токени. Додайте верифікацію на кожному кроці — і бюджет зросте знову. Бюджет виправданий, коли вартість неправильної відповіді вища за вартість пошуку.

План виправлення продакшен-інциденту може виправдати дослідження гілок, оскільки хибний шлях може змарнувати людський час або збільшити ризик простою. Слоган продукту, імовірно, не потребує дерева думок. Спочатку використовуйте дешевші методи різноманітності, якщо завдання не має справжньої пошукової структури.

Простий промпт у стилі дерева думок має три ролі: генератор, оцінювач і контролер. Генератор пропонує кандидатні думки. Оцінювач оцінює їх за критеріями.

Контролер обирає, які гілки продовжувати. Ці ролі можуть бути однією моделлю в окремих промптах, кількома моделями або обв’язкою навколо одного API.

Промпт генератора:
Маючи поточний стан і мету, запропонуйте три різні наступні кроки міркування.
Кожен крок має назвати припущення, яке він перевіряє, і докази, яких потребує.

Промпт оцінювача:
Оцініть кожен крок від 1 до 5 за здійсненністю, відповідністю доказам і ризиком.
Відхиліть будь-який крок, що порушує заявлене обмеження.

Правило контролера:
Залиште два найкращі кроки, якщо обидва не мають оцінку нижче 3.
Якщо всі кроки мають оцінку нижче 3, зупиніться й запитайте відсутню інформацію.

Правило контролера — це частина, яку багато команд пропускають. Без нього дерево думок стає «попросіть багато ідей». Обв’язка потребує обмежень гілок, умов зупинки, правил розв’язання нічиєї та способу не дати моделі неодноразово досліджувати ту саму ідею різними словами.

Пошук — це алгоритмічний патерн, а не відчуття.

Коли витрачати бюджет пошуку

Витрачайте бюджет пошуку, коли завдання складні, розгалужені та придатні для перевірки. Складність означає, що прямий промпт часто зазнає невдачі. Розгалуженість означає, що є кілька правдоподібних шляхів, які не можуть бути всі правильними.

Придатність до перевірки означає, що у вас є критерії, тести або докази, за якими можна оцінити гілки перед остаточним вибором. Якщо будь-яка з цих умов відсутня, пошук може бути театром. Для суб’єктивних завдань використовуйте генерацію кандидатів і ранжування, а не мову дерева думок.

Для неоднозначних завдань ставте уточнювальні запитання перед розгалуженням. Для простих завдань використовуйте прямий промпт і витратьте збережені токени на покриття оцінювання в іншому місці. Міркування на основі пошуку заслуговує свого місця лише тоді, коли дереву пошуку є що реально шукати.

Мала пошукова обв’язка

Наведеної нижче псевдообв’язки достатньо для багатьох експериментів із промптами. Це не продакшен-код. Вона називає стан, який ви повинні відстежувати, якщо пізніше автоматизуєте цей патерн.

state = початкова_задача
branches = [state]

for depth in 1..max_depth:
  candidates = generate_next_moves(branches)
  scored = evaluate_candidates(candidates, criteria)
  branches = keep_top_k(scored, k=2, min_score=3)
  if solved(branches) or no_viable_branch(branches):
    break

return best_final_answer(branches)

Відстежуйте кількість викликів моделі, згенерованих токенів, токенів верифікатора та реального часу виконання. Якщо пошукова обв’язка покращує правильність, але потроює затримку, продуктове рішення все одно може бути «ні». Якість міркування — не єдина метрика.

Вартість, затримка, терпіння користувача та навантаження рев’ю є частиною проєктування промпту.

ReAct: Чергування міркування та дії

Ланцюг міркувань, декомпозиція та дерево думок — усі покращують те, як модель міркує на основі інформації, що вже є в промпті або кандидатній гілці. ReAct, скорочення від reasoning and acting (міркування та дія), змінює цикл. Модель чергує крок міркування, інструментальну дію та спостереження, а потім використовує спостереження, щоб вирішити, що робити далі. Це робить ReAct корисним, коли правильність залежить від фактів, обчислень, стану репозиторію, журналів, результатів пошуку або іншої інформації, яку модель не повинна вигадувати з пам’яті.

Важливий зсув полягає в тому, що слід міркування більше не є лише пояснювальним текстом. Він стає контролером для використання інструментів. Обв’язка ReAct зазвичай нав’язує малу граматику, таку як Thought, Action, Observation та Final Answer; модель пропонує наступну дію, застосунок виконує лише дозволені інструменти, а спостереження додається до наступного виклику моделі. Ось чому ReAct знаходиться між промптами для міркувань та агентними фреймворками: це все ще патерн промпту, але він стає надійним лише тоді, коли обв’язка розбирає дії, записує спостереження, обмежує ітерації та відхиляє невідомі інструменти.

Питання: Яка висота Ейфелевої вежі у футах?
Думка: Мені потрібна надійна висота в метрах перед конвертацією одиниць.
Дія: lookup("eiffel tower height meters")
Спостереження: 330
Думка: Мені потрібен коефіцієнт перетворення метрів у фути.
Дія: lookup("meters to feet")
Спостереження: 3.28084
Думка: Тепер я можу обчислити 330 * 3.28084.
Дія: calculate("330 * 3.28084")
Спостереження: 1082.6772
Думка: Я маю вихідне значення, коефіцієнт перетворення та обчислення.
Остаточна відповідь: Ейфелева вежа має приблизно 1 083 фути заввишки.

Використовуйте ReAct, коли модель повинна вийти за межі промпту, щоб зібрати або перетворити інформацію. Не використовуйте його як більш драматичну форму ланцюга міркувань для завдань, які вже повністю специфіковані. Промпт для видобування дати ліцензії, імовірно, не потребує ReAct. Асистент підтримки, який повинен перевірити поточні події розгортання, перевірити обмеження лише для читання та обчислити вплив бюджету помилок, може потребувати його, оскільки кожне спостереження може змінити наступну безпечну дію.

Наведена нижче міні-обв’язка навмисно детермінована, щоб ви могли запустити її без ключа API. У реальному застосунку scripted_reasoner був би замінений викликом моделі, але парсер, дозволені інструменти, журнал спостережень і обмеження максимальної кількості кроків — це частини, які вам усе одно потрібно тестувати.

from __future__ import annotations

import ast
import operator
import re
from collections.abc import Callable


ACTION_RE = re.compile(r'^Action:\s*(\w+)\("([^"]*)"\)', re.MULTILINE)
FINAL_RE = re.compile(r'^Final Answer:\s*(.+)$', re.MULTILINE)
OPERATORS = {
    ast.Add: operator.add,
    ast.Sub: operator.sub,
    ast.Mult: operator.mul,
    ast.Div: operator.truediv,
    ast.USub: operator.neg,
}


def safe_eval(expression: str) -> float:
    """Evaluate a tiny arithmetic expression without exposing Python eval."""
    tree = ast.parse(expression, mode='eval')

    def walk(node: ast.AST) -> float:
        if isinstance(node, ast.Expression):
            return walk(node.body)
        if isinstance(node, ast.Constant) and isinstance(node.value, (int, float)):
            return float(node.value)
        if isinstance(node, ast.UnaryOp) and type(node.op) in OPERATORS:
            return OPERATORS[type(node.op)](walk(node.operand))
        if isinstance(node, ast.BinOp) and type(node.op) in OPERATORS:
            return OPERATORS[type(node.op)](walk(node.left), walk(node.right))
        raise ValueError(f'Unsupported expression: {expression}')

    return walk(tree)


def lookup(query: str) -> str:
    facts = {
        'eiffel tower height meters': '330',
        'meters to feet': '3.28084',
    }
    return facts.get(query.lower(), 'unknown')


def calculate(expression: str) -> str:
    return f'{safe_eval(expression):.4f}'


def scripted_reasoner(transcript: str) -> str:
    """Stand in for an LLM so this example stays runnable and repeatable."""
    if 'Observation:' not in transcript:
        return 'Thought: I need the trusted height in meters.\nAction: lookup("eiffel tower height meters")'
    if '330' in transcript and '3.28084' not in transcript:
        return 'Thought: I need the unit conversion factor.\nAction: lookup("meters to feet")'
    if '3.28084' in transcript and '1082.6772' not in transcript:
        return 'Thought: I can now calculate meters to feet.\nAction: calculate("330 * 3.28084")'
    return 'Thought: I have the facts and calculation.\nFinal Answer: The Eiffel Tower is about 1,083 feet tall.'


def run_react(question: str, max_steps: int = 5) -> str:
    tools: dict[str, Callable[[str], str]] = {
        'lookup': lookup,
        'calculate': calculate,
    }
    transcript = f'Question: {question}\n'

    for _ in range(max_steps):
        response = scripted_reasoner(transcript)
        transcript += response + '\n'

        if FINAL_RE.search(response):
            return transcript

        match = ACTION_RE.search(response)
        if not match:
            raise RuntimeError(f'Could not parse action from: {response}')

        tool_name, argument = match.groups()
        if tool_name not in tools:
            raise RuntimeError(f'Tool is not allow-listed: {tool_name}')

        transcript += f'Observation: {tools[tool_name](argument)}\n'

    raise RuntimeError('ReAct loop stopped before a final answer')


if __name__ == '__main__':
    print(run_react('How tall is the Eiffel Tower in feet?'))

Обв’язка показує мінімальну форму безпеки. Модель не виконує довільний код; вона видає рядок дії, який застосунок розбирає. Застосунок володіє реєстром інструментів, аргументами інструментів, журналом спостережень і правилом зупинки. Якщо ці межі слабкі, ReAct може зазнати невдачі звичайними способами: безкінечний цикл, виклик інструмента, який не має бути доступним, прийняття застарілих спостережень або трактування спостереження як доказу, коли це лише ще один непевний вхід.

Практичний промпт ReAct має, отже, називати доступні інструменти, вимагати одну дію за виклик, вимагати Final Answer, коли подальші інструменти не потрібні, і казати моделі зупинитися, коли спостережень недостатньо. Обв’язка має потім примусово виконувати ці правила, а не довіряти, що промпт виконає їх сам. Коли ви додаєте довговічний стан, розгалуження, переривання від людини або кількох працівників, той самий цикл міркування-і-дії стає концептуальним мостом до агентної оркестрації в стилі LangGraph.

API зусиль міркування

Засоби контролю міркувань від вендорів легко зрозуміти неправильно. Вони не роблять кожну відповідь правильною. Вони не замінюють контекст завдання, межі доказів або оцінювання.

Вони виділяють або спрямовують додатковий бюджет обдумування на боці моделі перед або під час генерації відповіді. Цей бюджет може покращити складні завдання на міркування, але він також споживає час, токени, контекст і гроші.

Більшість нативних засобів контролю потрапляє в три категорії: рівень зусилля, явний бюджет токенів обдумування або адаптивний режим, де модель вирішує, скільки роботи заслуговує запит. Ці засоби контролю спрямовують роботу на боці моделі, але вони не доводять, що відповідь правильна або що додаткові витрати виправдані.

Знімок ландшафту — станом на червень 2026. Усе швидко змінюється; перед тим як покладатися на конкретику, звіряйтеся з документацією виробника.

Поточні приклади включають моделі OpenAI серії o та засоби контролю міркувань GPT-5, режими обдумування Claude, засоби контролю бюджету обдумування Gemini та системи міркувань у стилі DeepSeek-R1. Документація API Gemini описує thinkingBudget для моделей серії Gemini 2.5 та thinkingLevel для моделей Gemini 3; thinkingBudget спрямовує використання токенів обдумування, нуль може вимкнути обдумування для підтримуваних моделей, динамічне обдумування може адаптувати бюджет до складності запиту, а фактичне використання може бути нижчим або вищим за запитаний бюджет. Ставтеся до цього як до датованої карти для пошуку в API, а не як до довговічного уроку.

Довговічний урок — маршрутизувати нативні засоби контролю бюджету міркувань із доказами, підкріпленими оцінюванням, замість того щоб припускати, що ручка провайдера покращує кожне завдання.

Урок API простий. Зусилля міркування — це засіб контролю обслуговування, а не заклинання промпту. Використовуйте його, коли завдання достатньо складне, щоб додаткові обчислення моделі з імовірністю змінили результат.

Уникайте його, коли завдання — просте видобування, форматування або пошук. Вимірюйте і якість, і вартість, перш ніж робити його усталеним.

Тип контролю	Що ви контролюєте	Що це дає	Що це коштує	Наслідок для промпту
Рівень зусилля	Грубе налаштування міркування від низького до високого	Більше або менше прихованих обчислень міркування	Затримка, використання контексту, витрати токенів, ціна	Тримайте видимий промпт сфокусованим на завданні, доказах і контракті остаточної відповіді
Бюджет токенів обдумування	Максимальний або цільовий бюджет для внутрішньої роботи	Більш контрольована внутрішня рефлексія для складних завдань	Варіативність бюджету, затримка, складність обробки стану	Ставтеся до бюджету як до підказки й оцінюйте фактичні виходи
Адаптивний режим обдумування	Дозвіл моделі вирішувати, коли потрібна додаткова робота	Менше ручної маршрутизації для трафіку змішаної складності	Менш передбачувані витрати та затримка	Віддавайте перевагу високорівневим цілям і критеріям перед приписувальними списками кроків

Коли зусилля міркування окупається

Зусилля міркування окупається, коли модель потребує утримувати кілька обмежень, досліджувати альтернативи або верифікувати виведену відповідь. Приклади включають математичні виведення, нетривіальне проєктування коду, багатокрокове планування, насичену інструментами агентну роботу та рішення з компромісами. Воно особливо корисне, коли остаточна відповідь має бути короткою, але внутрішній пошук складний.

Зусилля міркування не окупається, коли відповідь уже очевидна з контексту. Якщо користувач запитує значення видимого поля, додаткове обдумування — марнотратство. Якщо промпт просить JSON-перетворення, структуровані вихідні дані або валідація схеми важливіші за приховане міркування.

Якщо крок пошуку повертає точну відповідь, цитуйте джерело замість витрачання великого бюджету міркування. Використовуйте бюджетну драбину. Почніть із найдешевшого промпту та налаштування моделі, яке правдоподібно розв’язує завдання.

Переходьте до каркасу, нативного зусилля міркування, самоузгодженості або пошуку лише після того, як спостерігаєте невдачі. Записуйте режим відмови, який виправдав ескалацію. Ця звичка не дає бібліотекам промптів накопичувати дорогі ритуали, які ніхто не може захистити.

Наслідки для вартості

Зусилля міркування впливає на вартість у трьох місцях. По-перше, приховані токени або токени обдумування можуть бути платними або зараховуватися в ліміти генерації залежно від політики провайдера. По-друге, довше міркування збільшує реальну затримку, що може порушити очікування користувачів або тайм-аути сервісів.

По-третє, стан обдумування може споживати контекст або бюджет кешу, зменшуючи, скільки місця залишається для доказів і результатів інструментів. Вартість також впливає на оцінювання. Якщо ви тестуєте лише найвище налаштування міркування, ви можете випустити робочий процес, надто дорогий для рутинного використання.

Якщо ви тестуєте лише найдешевше налаштування, ви можете пропустити реальну здатність моделі на складних випадках. Добре оцінювання включає дешеві, середні та дорогі налаштування на репрезентативній вибірці. Результатом має бути правило маршрутизації, а не одне глобальне налаштування.

Наприклад, маршрутизуйте просте видобування до прямих промптів, маршрутизуйте середні діагностичні завдання до структурованої декомпозиції, а високоризикові багатокрокові завдання — до зусилля міркування плюс верифікатор. Це операційно чесніше, ніж казати кожному промпту думати сильніше. Це також робить вартість видимою для рев’юерів.

Антипатерни та правила рішень

Перший антипатерн — примушування CoT для простих пошуків. Якщо відповідь є в тексті джерела, просіть точну відповідь і місце в джерелі. Каркас ланцюга міркувань дає моделі більше простору для перефразування, неправильного прочитання або вигадування зв’язку.

Правильна верифікація — це цитування, а не більше міркувань. Другий антипатерн — примушування CoT для справжньої моделі міркувань без тестування. Нативний прихований слід моделі може бути кращим за ваш шлях на рівні промпту.

Якщо вам потрібна аудитованість, просіть стислий підсумок міркування, припущення, докази та перевірки. Не вимагайте автоматично довгого видимого чорновика. Третій антипатерн — використання «поясни своє міркування» як позначки якості.

Фраза змінює презентацію надійніше, ніж правильність. Вона може змістити відповідь у бік правдоподібної історії, особливо коли модель уже вгадала висновок. Просіть натомість конкретний артефакт міркування: обмеження, підзадачі, кандидатів, докази, висновки верифікатора або відхилені альтернативи.

Четвертий антипатерн — ховання остаточної відповіді всередині міркування. Це ускладнює автоматизоване видобування, людське рев’ю та голосування самоузгодженості. Завжди відокремлюйте остаточну відповідь від підсумку міркування або перевірок.

Для повторюваних робочих процесів робіть остаточне поле машиночитаним. П’ятий антипатерн — використання самоузгодженості без правила видобування. Якщо кожна вибірка форматує відповідь по-різному, голосування стає ручною інтерпретацією.

Визначте маркер відповіді, правило нормалізації, кількість вибірок, температуру та правило розв’язання нічиєї перед запуском вибірок. Інакше ви не зможете сказати, чи метод покращив міркування, чи просто створив більше тексту для вибору. Шостий антипатерн — трактування верифікатора як незалежного, коли він таким не є.

Якщо верифікатор отримує ті самі розмиті критерії, той самий оманливий контекст і ту саму широку роль, що й генератор, він може благословити ту саму помилку. Зробіть верифікацію вужчою, заснованою на критеріях, і бажано відокремленою за роллю, моделлю чи інструментом. Сьомий антипатерн — перетворення кожного складного промпту на дерево думок.

Міркування на основі пошуку дороге й потребує оцінювання гілок. Якщо ви не можете визначити гілку, оцінку та правило зупинки, у вас, імовірно, не дерево думок. У вас запит на кілька чернеток.

Восьмий антипатерн — збереження старих каркасів після оновлення моделі. Бібліотеки промптів часто кодують обхідні шляхи для попередніх моделей. Коли ви переходите на модель міркувань або змінюєте налаштування зусиль API, повторно запускайте порівняння промптів.

Видаляйте каркаси, які більше не виправдовують себе.

Контрольний список рішень

Поставте сім запитань перед додаванням машинерії міркування. Відповідь вирішує патерн.

1. Чи відповідь безпосередньо присутня в надійному контексті?
   Використовуйте видобування з цитуванням.

2. Чи правильність залежить від зовнішніх фактів, обчислень або стану
   системи, які модель не повинна вигадувати з пам'яті?
   Використовуйте ReAct: чергуйте міркування з дозволеними
   інструментальними діями та спостереженнями під обв'язкою
   з обмеженнями ітерацій.

3. Чи завдання потребує кількох залежних кроків?
   Використовуйте декомпозицію або «сплануй і виконай».

4. Чи завдання має одну об'єктивну остаточну відповідь, але крихкі шляхи?
   Використовуйте самоузгодженість або верифікатора.

5. Чи родина моделей уже підтримує нативне зусилля міркування?
   Спробуйте засоби контролю зусиль, перш ніж писати жорсткий видимий чорновик.

6. Чи неправильна відповідь достатньо дорога, щоб виправдати пошук за гілками?
   Використовуйте дерево думок з оцінюванням гілок і правилами зупинки.

7. Чи можна перевірити результат за критеріями, тестами або доказами?
   Додайте прохід верифікатора перед додаванням більшої генерації.

Контрольний список тримає проєктування міркувань прив’язаним до форми завдання. Він також запобігає поширеній організаційній помилці: один успішний промпт стає універсальним шаблоном. Промпти для міркувань мають бути модульними.

Репетитор з математики, асистент тріажу інцидентів, рецензент коду й узагальнювач політик не потребують однакового каркасу обдумування.

Чи знали ви?

Стаття Kojima та ін. про zero-shot CoT зробила одну коротку фразу знаменитою, але ширший урок статті полягав у тому, що промптинг може пробуджувати латентну поведінку міркування без специфічних для завдання прикладів.
Самоузгодженість — це стратегія декодування та відбору, а не просто довший промпт; вона потребує кількох вибіркових шляхів і правила для вибору остаточної відповіді.
Промптинг «від простого до складного» найкорисніший, коли відповіді на підзадачі справді живлять пізніші підзадачі, що робить проміжну роботу ланцюгом залежностей, а не декорацією.
Бюджети обдумування та засоби контролю зусиль міркування від вендорів можуть покращити складні завдання, але вони також є засобами контролю вартості, оскільки приховане міркування може споживати токени, контекст, затримку або бюджет кешу.

Типові помилки

Помилка	Чому це трапляється	Як виправити
Додавання «міркуй покроково» до кожного промпту	Фраза пам’ятна і здається ґрунтовною, навіть коли завдання — пошук	Використовуйте пряме видобування для простих завдань і резервуйте зонди CoT для спостережуваних багатокрокових невдач
Збереження старого каркасу CoT після переходу на модель міркувань	Бібліотека промптів зберігає обхідні шляхи сумісності з попередньої моделі	Повторно запускайте прямі, каркасні варіанти та варіанти із зусиллям міркування після кожної зміни моделі
Запит повного міркування, коли достатньо підсумку	Рев’юери хочуть упевненості, але отримують довгий чорновик, який не аудитуватимуть	Просіть остаточну відповідь, ключові докази, припущення та одну верифікаційну перевірку
Використання few-shot CoT прикладів із невідповідним стилем	Приклади навчають багатослівності, припущень або формату разом із патерном міркування	Тримайте приклади короткими, репрезентативними, правильними та узгодженими з продакшен-контрактом виходу
Запуск самоузгодженості без нормалізації	Голосування базується на людській інтерпретації, а не на відтворюваному полі відповіді	Визначте маркер остаточної відповіді, правило нормалізації, кількість вибірок і правило розв’язання нічиєї
Дозвіл декомпозиції вигадувати відсутні докази	Модель заповнює невідомі підзадачі, щоб послідовність рухалася	Вимагайте, щоб кожна підзадача позначала відсутні входи та зупинялася, коли доказів недостатньо
Трактування верифікаторного промпту як незалежного за замовчуванням	Верифікатор поділяє контекст генератора, упередження моделі та розмиті критерії	Дайте верифікатору явні критерії, вузьку роль та розділення за інструментом або моделлю, коли ризик високий
Використання дерева думок без оцінювання гілок	Промпт просить багато ідей, але ніколи не контролює пошук	Визначте генерацію гілок, критерії оцінювання, відсікання, максимальну глибину та умови зупинки

Тест

1. Промпт просить модель видобути дату завершення терміну дії зі вставленої ліцензії. Чи варто додавати «Let's think step by step»?

Ні. Це завдання прямого видобування. Кращий промпт просить точну дату та рядок джерела або поле, де вона з’являється. Ланцюг міркувань додає затримку й дає моделі більше простору для перефразування або домислювання. Якщо джерело неоднозначне, попросіть «кандидатів на дату та чому кожен із них може бути датою завершення», а не загальний покроковий каркас.

2. Модель без міркувань зазнає невдачі в трикроковій арифметичній текстовій задачі, перестрибуючи до неправильної операції. Який варіант CoT є найдешевшим першим зондом?

Використовуйте малу zero-shot підказку в стилі CoT, але зробіть її специфічною для завдання: «уважно опрацюйте величини, потім поверніть Остаточно та Перевірку». Якщо це допомагає, замініть загальну підказку чіткішим контрактом завдання або few-shot прикладом. Не переходьте одразу до самоузгодженості чи дерева думок, поки не дізнаєтесь, що один каркасний шлях усе ще зазнає невдачі.

3. Команда мігрує зі старішої чат-моделі на модель із нативним бюджетом обдумування, і її старий покроковий каркас починає знижувати якість відповідей. Що їм варто протестувати?

Вони мають порівняти прямий контракт завдання, стислий промпт із підсумком міркування та нативне для провайдера налаштування зусилля міркування або обдумування. Старий каркас може обмежувати внутрішній шлях міркування нової моделі. Залиште межі доказів і критерії виходу, але приберіть приписувальні кроки, якщо вони не дають вимірюваних покращень на оцінювальному наборі команди.

4. Коли промптинг «від простого до складного» перевершує загальну інструкцію ланцюга міркувань?

«Від простого до складного» краще, коли завдання можна розкласти на менші підзадачі, і кожна розв’язана підзадача стає входом для пізнішої роботи. Цінність — у ланцюзі залежностей. Якщо підзадачі не живлять розв’язання, промпт лише створив довше пояснення, а не сильніший процес міркування.

5. Чому самоузгодженість усе одно може обрати неправильну відповідь?

Самоузгодженість бере вибірку з кількох шляхів і обирає поширену остаточну відповідь, але поширена не означає правильна. Якщо кожна вибірка поділяє одне хибне припущення, неоднозначність промпту або оманливий контекст, голосування може підсилити помилку. Використовуйте нормалізацію, правила розв’язання нічиєї та верифікатора, коли завдання має обмеження, які можна перевірити.

6. Що робить верифікаторний промпт сильнішим за прохання до початкової відповіді «перевірити ще раз»?

Сильний верифікатор має вузьку роль, отримує початкове завдання та запропоновану відповідь і перевіряє за явними зовнішніми критеріями. Він повертає висновки, прив’язані до критеріїв, перед виправленням. «Перевірити ще раз» слабке, тому що часто просить ту саму модель із тим самим широким контекстом створити ще одну люб’язну відповідь, а не проаналізувати контракт.

7. Коли дерево думок варте бюджету?

Його варто розглядати, коли завдання складне, розгалужене та придатне для перевірки. Має бути кілька правдоподібних шляхів, спосіб оцінювати гілки та достатній ризик від неправильної відповіді, щоб виправдати кілька викликів. Без оцінювання гілок і правил зупинки дерево думок стає дорогим запитом на багато чернеток.

8. Що насправді контролюють API зусилля міркування та бюджету обдумування?

Вони спрямовують або виділяють роботу обдумування на боці моделі, часто через приховані токени міркування, структуровані блоки обдумування, адаптивне зусилля або бюджети токенів обдумування. Вони не гарантують правильності, не замінюють контекст і не усувають потреби у верифікації. Вищі налаштування можуть покращити складні завдання, але також можуть збільшити затримку, використання токенів, тиск на контекст і вартість.

Практична вправа: Порівняння трьох стратегій міркування

Сценарій вправи: ви проєктуєте промпт для асистента підтримки, який виконує тріаж невдалого розгортання на основі обмежених доказів. Завдання навмисно достатньо мале для ручного виконання, але достатньо реалістичне, щоб показати відмінності між прямим відповіданням, декомпозицією та верифікацією. Використовуйте ту саму модель для всіх трьох стратегій, якщо ви явно не тестуєте нативне зусилля міркування провайдера.

Тримайте температуру, контекст і формат виходу стабільними, щоб стратегія міркування була основною змінною.

Вихідне завдання

Докази:
- Deployment з назвою web було оновлено о 10:20 UTC.
- Нові Поди застрягли в ImagePullBackOff.
- Поле образу: registry.example.com/web:2026-05-25.
- Попередній тег образу був registry.example.com/web:2026-05-24.
- Журнали контейнера недоступні, оскільки контейнер ніколи не запускається.
- Інженер має доступ до простору імен лише для читання.

Питання:
Який найімовірніший наступний діагностичний крок і що асистент повинен уникати рекомендувати?

Стратегія A: Прямий промпт

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

Вихід:
- Наступний діагностичний крок
- Обґрунтування
- Уникайте рекомендувати

Запустіть промпт один раз. Запишіть, чи відповідь залишається в межах доказів, чи уникає тверджень на основі журналів і чи поважає доступ лише для читання. Це базова лінія.

Якщо вона проходить, дорожчий каркас міркування має заслужити своє місце.

Стратегія B: Промпт із декомпозицією

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

Спочатку розкладіть докази на:
- Спостережувані факти
- Висновки, підкріплені цими фактами
- Відсутня інформація
- Дії, дозволені при доступі лише для читання

Потім дайте відповідь:
- Наступний діагностичний крок
- Обґрунтування
- Уникайте рекомендувати

Запустіть промпт один раз. Порівняйте з прямим промптом. Шукайте краще відокремлення доказів, а не просто більше слів.

Якщо декомпозиція вигадує стан реєстру або пропонує дію на запис, позначте це як невдачу.

Стратегія C: Чернетка плюс верифікатор

Завдання генератора:
Дайте відповідь на питання тріажу розгортання, використовуючи лише наведені нижче докази.
Поверніть наступний діагностичний крок, обґрунтування та уникайте рекомендувати.

Завдання верифікатора:
Перевірте запропоновану відповідь за цими критеріями:
- Використовує лише надані докази
- Не стверджує, що журнали контейнера існують
- Не рекомендує змінювати стан кластера
- Називає наступний діагностичний крок лише для читання
Поверніть пройшов/не пройшов і висновки.

Запустіть генератор, потім запустіть верифікатор на відповіді генератора. Якщо верифікатор знаходить проблему, виправте лише поле, що зазнало невдачі, і запустіть верифікатор знову. Не дозволяйте верифікатору мовчки переписувати всю відповідь.

Таблиця порівняння

Заповніть цю таблицю своїми результатами.

Стратегія	Правильний наступний крок?	Поважає докази?	Поважає доступ лише для читання?	Вартість і затримка	Рішення для бібліотеки
Пряма
Декомпозиція
Чернетка плюс верифікатор

Критерії успіху

Ви запустили одне вихідне завдання з прямим промптом, промптом із декомпозицією та робочим процесом чернетка-плюс-верифікатор.
Ви порівняли остаточні відповіді за використанням доказів, доступом лише для читання, відсутньою інформацією та вартістю, а не судили за тим, яка відповідь звучала найрозумніше.
Ви визначили щонайменше один випадок, де видиме міркування допомогло, було надлишковим або погіршило відповідь.
Ви написали рекомендацію в один абзац, яка проєктує промпти для пробудження міркувань для завдань діагностики, планування та прийняття рішень, не перетворюючи багаторазовий промпт підтримки на загальний ритуал ланцюга міркувань.
Ви назвали наступне оцінювання, яке виконали б перед застосуванням обраної стратегії до продакшен-інцидентів.

Очікуваний аналіз

Прямий промпт може вже знайти правильний наступний діагностичний крок: перевірити події завантаження образу, назву образу, існування тегу або доступ до реєстру командами лише для читання. Він має уникати рекомендації перевіряти журнали контейнера, оскільки докази кажуть, що контейнер ніколи не запускається. Він також має уникати перезапусків розгортання, змін образу або редагувань секретів, оскільки інженер має доступ до простору імен лише для читання.

Промпт із декомпозицією кращий лише тоді, коли покращує обґрунтування. Сильна декомпозиція відокремить спостережувані факти від імовірного висновку: ImagePullBackOff вказує на посилання на образ, автентифікацію реєстру, політику завантаження або мережевий шлях, а не на збій середовища виконання застосунку. Слабка декомпозиція роздує відповідь довгою історією інциденту.

Робочий процес із верифікатором найсильніший, коли генератор робить тонке порушення. Наприклад, якщо генератор каже «перевірте журнали» або «перезапустіть розгортання», критерії верифікатора мають це зловити. Робочий процес повільніший, але додатковий прохід може бути виправданий для промптів підтримки, які неодноразово впливають на поведінку оператора.

Джерела

Large Language Models are Zero-Shot Reasoners — Kojima та ін.; верифіковане джерело для zero-shot CoT і підказки «Let’s think step by step».
Self-Consistency Improves Chain of Thought Reasoning in Language Models — Wang та ін.; верифіковане джерело для кількох вибіркових шляхів міркування та вибору відповіді.
Least-to-Most Prompting Enables Complex Reasoning in Large Language Models — Zhou та ін.; верифіковане джерело для декомпозиції на простіші підзадачі.
Tree of Thoughts: Deliberate Problem Solving with Large Language Models — Yao та ін.; верифіковане джерело для пошуку серед проміжних думок.
ReAct: Synergizing Reasoning and Acting in Language Models — Yao та ін.; верифіковане джерело для чергування слідів міркування з інструментальними діями та спостереженнями.
Chain-of-Thought Prompting Elicits Reasoning in Large Language Models — Wei та ін.; верифіковане фонове джерело для few-shot CoT прикладів.
Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models — Wang та ін.; верифіковане фонове джерело для планування перед розв’язанням.
Let’s Verify Step by Step — Lightman та ін.; верифіковане фонове джерело для питань верифікації процесу та результату.
DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning — верифіковане фонове джерело для тренування моделей міркувань, перехресно пов’язане тут лише для розрізнення промптингу на етапі інференсу від тренування моделей.
Документація Anthropic щодо розширеного обдумування — верифікована документація виробника для режимів обдумування Claude і бюджетів токенів.
Найкращі практики промптингу Anthropic Claude: можливості обдумування — верифіковані настанови виробника щодо промптів обдумування та адаптивної поведінки обдумування.
Документація OpenAI щодо моделей міркувань — верифікована документація виробника для моделей міркувань і зусилля міркування.
Настанови OpenAI щодо останніх моделей: використання моделей міркувань — верифіковані настанови виробника для поточних засобів контролю міркувань і міркувань щодо маршрутизації.
Документація Gemini щодо обдумування — верифікована документація виробника для thinkingBudget, динамічного обдумування та засобів контролю обдумування Gemini.

Наступний модуль

Переходьте до Безпеки та оцінювання промптів у плані розділу, де патерни верифікації з цього модуля стають безпековими воротами, наборами даних для оцінювання та регресійними тестами для промптів, насичених міркуваннями.