Chain-of-Thought промптинг: чому відповіді нестабільні
На багатокрокових задачах — розбір договору за пунктами, розрахунок за залежними умовами, діагностика за логами — модель видає зв'язний результат, який суперечить частині вихідних даних.
Правка формулювання допомагає на один-два прогони, далі поведінка знову розходиться: Chain-of-Thought промптинг без управління ланцюгом міркувань стабільності не дає.
Причина в самому способі генерації: відповідь збирається крок за кроком, і увага на кожному кроці розподіляється по всьому запиту. Чим довший вхід, тим вища ймовірність, що конкретна умова — обмеження за строками, виняток із правила, одиниця виміру — не потрапить у поточний крок. Ланцюг міркувань не вибудовується: модель іде до правдоподібного висновку коротким шляхом.
Звідси нестабільні відповіді моделі: той самий запит на різних прогонах дає різні гілки міркувань і різні висновки.
Перевірка на одному вдалому прикладі нічого не говорить про якість відповідей на складних задачах — розходження проявляється на десятках запусків і там, де ціна помилки максимальна.
Втрата умов у запиті — не дефект формулювання, а властивість самої генерації, тому переписуванням питання її не закрити. Потрібен керований ланцюг: явні кроки, перевірка проміжних результатів і правила, за якими модель повертається до вихідних даних. Розбираємо, як це влаштовано в реалізації.
Що дає кероване міркування: вимірювані ефекти
Кероване міркування — це не «розумніша модель», а заздалегідь описаний порядок кроків, який модель проходить до висновку. На багатокрокових задачах це змінює точність відповідей, їхню повторюваність і обсяг ручної перевірки.
Частка правильних відповідей на багатокрокових задачах
Там, де відповідь збирається з кількох послідовних висновків — звірка умов, розбір заявки за регламентом, розрахунок за кількома правилами, — модель без заданої структури втрачає проміжні умови й видає правдоподібний, але неправильний підсумок.
Коли в шаблон вбудовано послідовність «витягти факти → застосувати правило → перевірити підсумок», частка коректних відповідей на таких наборах зростає в рази.
Повторюваність: однаковий вхід — передбачуваний вихід
Без фіксованої схеми той самий запит дає різні відповіді: змінюються аргументи, порядок, іноді висновок — і результат не можна ні вбудувати в автоматику, ні прийняти за формальною ознакою.
Ми задаємо обов'язкові кроки, їхній порядок і критерій, за яким висновок вважається обґрунтованим, — розходження між прогонами скорочується до формулювань, а не змісту.
Скільки ручної перевірки знімається
Ручна перевірка зазвичай покриває всю видачу, бо довіри до окремих відповідей немає.
Після налаштування шаблонів і набору перевірних прикладів оператор дивиться лише гілки з низькою впевненістю та спірні випадки — обсяг вичитки падає, а разом із ним зникає клас помилок «впевнена відповідь без опори на дані», який раніше ловила лише людина.
Режими міркування: порівняння та обмеження
Режим міркування — це бюджет на проміжні кроки, а не «рівень інтелекту» моделі. Чим більше кроків між питанням і відповіддю, тим менше помилок на багатоумовних задачах — і вища затримка. Режим підбираємо під задачу, а не «на максимум».
Нижче — чотири режими та їхні обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пряма відповідь | Витяг полів, класифікація, короткі формулювання | Потрібен розрахунок у кілька кроків — помилиться і не покаже, де |
| Покрокове міркування в один прохід | Арифметика, порівняння умов, розбір правил | Кроки не перевіряються: помилка в середині веде весь висновок |
| Міркування з окремою перевіркою | Розрахунки, вибір із варіантів, відповіді за документом | Вищий час відповіді та витрати на генерацію |
| Розбір через проміжні висновки | Довгі ланцюги умов і багатокрокові інструкції | Потрібні явні правила, інакше кроки розходяться |
Коли прямої відповіді достатньо
Пряма відповідь працює там, де результат — одне значення або коротка мітка: витягти реквізити з договору, розмітити звернення за темою, привести текст до шаблону. Зайві кроки нічого не додають — модель і так влучає в ціль, а час відповіді зростає. Критерій простий: якщо людина відповідає не замислюючись, міркувати не потрібно.
Коли потрібна перевірка другим проходом
Другий прохід потрібен, коли помилка дорожча за затримку: розрахунки, вибір із варіантів, відповіді з опорою на документ. Ми розносимо міркування й самоперевірку моделі по різних викликах: спочатку висновок, потім звірка з вихідними даними й правилами.
Це ловить помилку в середині ланцюга і знижує частку неправильних відповідей, але помітно збільшує витрати.
Порядок робіт: від розбору задач до передачі
Впровадження починається не з вибору моделі, а з розбору задач: де відповідь має супроводжуватися покроковим міркуванням, а де достатньо короткої форми і Chain-of-Thought промптинг лише сповільнить відгук.
Етапи вибудовуємо так, щоб кожен наступний крок спирався на перевірюваний артефакт, а не на враження від показового прикладу.
- Розбір задач і збір реальних запитів: вивантажуємо історію звернень, прибираємо дублі й групуємо за типами — отримуємо набір, що відображає фактичний розподіл задач, а не зручні для показу випадки.
- Розмітка еталонних міркувань: для кожного типу задачі описуємо ланцюг кроків, який приводить до правильної відповіді.
- Складання чорнових наборів підказок: формулюємо кілька варіантів під кожен тип задачі та порівнюємо їх між собою на тих самих прикладах.
- Налаштування правил перевірки: фіксуємо, що вважаємо коректною відповіддю і як відловлюємо міркування, яке приводить до неправильного висновку.
- Прогін на відкладеній вибірці: лише приклади, що не брали участі в налаштуванні, показують реальну стійкість рішення.
- Передача рішення й навчання команди: документація, розбір типових помилок і регламент оновлення наборів підказок.
Розмітка еталонних міркувань
Тут важлива не довжина ланцюга, а його відтворюваність: два розмітники на одному прикладі мають дійти одного висновку. Тому спірні випадки виносимо окремим списком і розбираємо до того, як вони потраплять у набір.
Перевірка на відкладеній вибірці
Відкладена вибірка збирається заздалегідь і не використовується під час налаштування — інакше оцінка показує завченість, а не якість. Дивимося частку правильних відповідей за кожним типом задач окремо: загальний відсоток приховує провали на рідкісних, але важливих запитах.
Що залишається у вас: бібліотека підказок і регламенти
Після запуску рішення у вас залишається не лише працюючий сервіс, а й увесь шар, який ним керує.
Бібліотека підказок, регламент перевірки й документація рішення передаються до вашого репозиторію — у тому самому вигляді, в якому ми користуємося ними самі, без «магії» в чужій інфраструктурі.
- Набори підказок за типами задач: призначення, очікуваний формат відповіді, приклади коректних і відхилених реакцій моделі, включно з ланцюгами міркувань.
- Схеми розбору типових задач: які кроки міркування модель проходить, де точка розгалуження і що вважається неправильним висновком.
- Регламент перевірки: правила звірки відповіді з джерелом, набір контрольних запитів, критерії приймання нової версії.
- Правила оновлення: що перезбирається при зміні моделі чи постачальника, а що переноситься без правок.
- Журнал змін: дата, автор, причина правки, результат прогону контрольного набору до і після.
- Інструкція із супроводу: як додати новий сценарій, не ламаючи наявні, і куди дивитися при просіданні якості.
Як зберігаються й оновлюються набори підказок
Набори лежать у системі контролю версій поряд із кодом сервісу: одна підказка — один файл з описом призначення. Правка потрапляє в основну гілку лише після прогону контрольного набору, а версія моделі фіксується в журналі змін. При її оновленні видно, які сценарії просіли і що саме було виправлено.
Кейс: як зросла точність відповідей на розборі заявок
Що було до
Розбір вхідних звернень ішов одним запитом: модель одразу видавала категорію й рішення.
На неоднозначних формулюваннях — а це помітна частина потоку в кілька тисяч звернень на місяць — висновок виявлявся неправильним, і правилами такі помилки не ловилися: бракувало проміжних кроків, де модель зіставляє факти між собою.
Частка правильних висновків трималася близько двох третин, кожне третє звернення йшло на ручну звірку — до 12 хвилин роботи спеціаліста.
Правила дописували поверх, але це лікувало симптоми: кожне нове формулювання клієнта вимагало чергового винятку, список зростав, а точність стояла на місці.
Що стало після
Розбір розклали на кроки: спочатку витяг фактів з тексту звернення, потім пошук суперечностей між ними, далі звірка з базою правил — і лише після цього підсумковий висновок.
Еталонний корпус із 400 розмічених звернень зібрали в Label Studio, на ньому ж проганяли кожну версію промпту перед викаткою.
- частка правильних висновків — 94% проти 68% до переробки;
- ручна правка — одне звернення з п'ятнадцяти замість кожного третього;
- час розбору скоротився з 12 до 4 хвилин на звернення;
- ескалації старшому спеціалісту — втричі рідше.
Промпт живе як код: зміна проходить прогін за еталоном, і якщо метрика просіла, версія відкочується. Нові типи формулювань розбираються без правки правил — модель доводить ланцюг міркувань сама.
Чим покрокове міркування відрізняється від самоперевірки?
Покрокове міркування — це один прохід: модель розкладає задачу на проміжні кроки і йде ними до відповіді.
На арифметиці, розборі умов і витягу фактів частка правильних відповідей помітно зростає, але видача видовжується — розбір займає основну частину, а сам результат залишається в кінці.
Самоперевірка влаштована інакше: чернетка рішення та його перевірка — різні проходи. Модель спочатку відповідає, потім окремо перечитує відповідь за критеріями задачі та править знайдені місця.
Розділення проходів потрібне там, де помилка в середині ланцюга непомітна ззовні: один неправильний крок дає впевнено виглядаючий, але неправильний підсумок, і без другого проходу його не відловити.
Кожен додатковий прохід збільшує час обробки та обсяг звернень до моделі, а якщо показувати перевірку цілком — і довжину відповіді. На коротких задачах два проходи замість одного помітно додають затримку за того самого результату.
На довгих багатокрокових сценаріях різниця окупається: частка відповідей, які потім правлять вручну, падає.
Вибір режиму ми робимо за ціною помилки, а не за зовнішньою складністю задачі. Де неправильна відповідь видна одразу й легко перевіряється людиною, достатньо покрокового міркування.
Де рішення йде в автоматичний контур — розрахунки, узгодження умов, висновки за документами — додаємо самоперевірку, іноді лише на критичних кроках, щоб не платити за перевірку всієї відповіді.
Самоперевірка теж може помилятися, тому критерії перевірки та поведінку при розходженні описуємо в промпті заздалегідь.
Часті технічні сумніви та обмеження
CoT — не універсальний прийом: на класифікації, витягу полів і перевірці відповідностей покрокове міркування збільшує час відповіді та обсяг виводу без приросту якості.
Ми заздалегідь розмічаємо, де метод дає ефект, а де включати його не потрібно — це частина проєктної роботи, а не налаштування «на око».
Нижче — технічні сумніви, які найчастіше спливають на етапі оцінки: стійкість при зміні моделі, необхідність прикладів міркувань, вимірюваність результату та перенесення підказок у сусідні сценарії.
Що буде при зміні моделі?
Набори підказок прив'язані до сімейства моделі: формулювання, порядок кроків і формат виводу підбираються під конкретну гілку. При переході ми проганяємо перевірний набір запитів і правимо формулювання — зазвичай переноситься більша частина підказок, решту доналаштовуємо.
Чи обов'язкові приклади міркувань у підказці?
Ні, міркування за кроками працює й без розмічених прикладів. Приклади прискорюють вихід на потрібну якість і стабілізують формат, але видовжують підказку та збільшують обсяг виводу в 2-4 рази.
Тому підсумок ми віддаємо в заданому форматі, а хід міркування залишаємо внутрішнім — користувач не бачить зайвого тексту.
Як виміряти ефект, а не повірити на слово?
Збираємо еталонний набір запитів із заздалегідь правильними відповідями та рахуємо частку правильних рішень до і після. Додатково дивимося частку відмов і звернень до людини. Без еталонного набору порівняння залишається смаковим.
Чи можна перенести підказки в інший сценарій?
Частково: структура міркування переноситься, конкретні формулювання — ні. Ми тримаємо підказки окремим шаром із версіями та тестами, тому перенесення в нову задачу — це адаптація та повторний прогін, а не розробка з нуля.
Обговоримо задачу: що уточнити перед стартом
Точна оцінка з CoT-промптингу починається не з шаблону промпту, а з вхідних даних. Якщо надіслати лише опис задачі, ми повернемося з діапазоном у рази ширшим за реальний. Нижче мінімальний набір для оцінки, після якого розмова переходить у план робіт з етапами та строками.
- Приклади запитів — 30-50 реальних формулювань, включно з короткими, з одруками та змішаними мовами.
- Еталонні відповіді — за 20-30 прикладами зафіксований бажаний результат і те, що вважається неприпустимим.
- Типові збої — де поточна логіка помиляється: пропущений крок міркування, підміна факту, обрив на довгому запиті.
- Вимоги до перевірки — які перевірки відповідь проходить перед видачею: звірка з джерелом, формат, обов'язкові поля.
- Обмеження за часом відповіді — скільки секунд чекає користувач і що важливіше: швидкість чи глибина міркування.
- Обмеження за даними — що не можна передавати в зовнішні сервіси, чи потрібна ізоляція контуру.
- Точки інтеграції — звідки надходить запит, куди йде відповідь, хто править шаблон після запуску.
- Цільові метрики — частка правильних відповідей на перевірному наборі, частка відмов «не знаю», розкид між запусками.
З цього набору починається обговорення задачі: проводимо дзвінок за проєктом з інженером, розбираємо спірні приклади, фіксуємо, що вважаємо еталоном, і знімаємо суперечності у вимогах.
За підсумками надсилаємо план робіт — порядок етапів, склад перевірок, документацію та оцінку строків.
