Ваші співробітники не вміють писати промпти: як це видно в результатах

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

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

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

Три симптоми, за якими це видно керівнику

Вам не треба дивитись на самі запити, щоб зрозуміти рівень команди. Достатньо подивитись на результати.

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

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

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

Чому один і той самий запит дає різні відповіді

Це питання ставлять майже на кожному занятті, і відповідь у нього технічна.

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

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

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

Ну і практичний висновок для команди: якщо від задачі потрібна стабільність, а не креатив, це треба прямо написати в запиті, а не сподіватись.

Чого не вистачає типовому запиту в компанії

Розбираючи запити команд, я бачу одні й ті самі чотири дірки.

• Немає ролі і контексту. Модель не знає, для кого пишеться текст і хто його читатиме

• Немає прикладу хорошого результату. Людина знає, як має виглядати, але не описала цього

• В одному запиті кілька задач одразу. Тоді кожна виконується посередньо

• Немає обмежень. Ні обсягу, ні формату, ні заборон

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

Декомпозиція вирішує більше, ніж будь-який шаблон

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

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

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

Мета-промпти: коли просити модель написати запит

Питання, яке звучить майже на кожному занятті: чи можна попросити модель написати промпт замість вас.

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

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

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

Що закріпити в команді, щоб не повторювати щоразу

Промпти, які повторюються, не мають жити в голові у кожного окремо.

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

Мінімальний набір, з якого варто почати:

• три-пʼять типових задач на роль, описаних як готові запити

• один опис того, що вважається хорошим результатом для кожної задачі

• окремо перелік заборон: чого модель робити не має

Один приклад працює краще за сторінку інструкцій

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

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

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

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

Як перевірити рівень команди за пів години

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

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

Далі дивіться не на тексти, а на три речі:

• скільки разів людина зверталась до моделі, поки отримала прийнятний результат

• скільки з фінального тексту вона переписала руками

• чи зберегла вона свій запит кудись, чи він зник разом із чатом

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

Три доповнення, які прибирають половину проблем

Найкоротший набір, який можна роздати команді сьогодні.

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

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

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

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

Головне про промпти в команді

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

У банківському контурі учасники дійшли того самого висновку самі: після навчання вони вирішили цілий рік збирати власну бібліотеку промптів, а чемпіони по вертикалях отримали задачу наповнювати її під свою бізнес-лінію. У технічній команді BetterMe ми йшли глибше і розбирали параметри генерації, бо там це мало прикладний сенс.

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