Чому на однаковий запит ШІ щоразу відповідає по-різному?
На курсі це питання повертається, як квартальна звітність.
Я відповідаю чесно: бо це не алгоритм. Калькулятор на «2+2» завжди дасть чотири. А мовна модель, як продавець на Привозі, намагається вгадати, на яку суму ви розраховуєте. Модель на кожному кроці вибирає наступне слово з варіантів, тому той самий запит дає різні тексти. Це її властивість, а не поломка.
Бухгалтеру від цього не легше, бо в нас процеси повторювані, і ми звикли, що повторюваний процес дає повторюваний результат. Вчора лист до ДПС вийшов чудовим, а сьогодні «трохи не так». Починається знайома гра: порівняти версії, виправити шматочками, переписати абзац, перечитати все знову. Декілька годин на один лист замість обіцяних хвилин. І розчарування: «ШІ не економить час».
А тепер головне. Найчастіше час горить не тому, що модель «неправильно обробила інформацію». Він горить, бо ми не налаштували розмову. Допоможуть три персонажі.
Чому словник має значення? Бо слова тут — це простір для варіантів. Чим ширший словник, яким модель має право користуватися у відповіді, тим більше в неї способів сказати те саме. Чим вужчий, тим менше місця для сюрпризів. Це метафора: насправді модель знає всі слова, а ми просимо її користуватися лише частиною. Тож три персонажі — це три розміри словника:
- Шекспір, близько 12 000 слів: для душі й дозвілля. Обговорення, мозковий штурм, варіанти позиції.
- Авіамеханік, приблизно 900 слів: для податкової. Лист, пояснення, відповідь на запит.
- Елочка, 30 слів: для ШІ-помічника в режимі дедлайну. Зразок, чітке завдання, жодних сюрпризів.
Правило одне: чим дорожча помилка, тим вужчий словник. Тепер по порядку.
Шекспір: говоріть скільки завгодно, але в іншому чаті
ШІ зі словником Шекспіра з його дванадцятьма тисячами слів відповідає «за замовчуванням» розлого, з відступами та прологом «чудове питання!». Для обговорення, порівняння варіантів позиції, мозкового штурму це чудово. Але пускати Шекспіра в той самий чат, де народжується лист до ДПС, не варто.
Дослідники з Microsoft і Salesforce прогнали 15 моделей через понад 200 тисяч симульованих розмов. У багатокрокових діалогах якість у середньому впала на 39%, і здебільшого не тому, що модель «тупішає», а тому, що її відповіді стають менш передбачуваними. Це були не листи до ДПС (код, SQL, математика, підсумки), тож переносимо обережно. Практика проста: обговорили, зафіксували підсумок і відкрили новий чат або проєкт із чистим завданням.
Авіамеханік: для листа до ДПС потрібен словник
На початку жовтня Андрій Карпаті порадив просити модель писати за стандартом ASD-STE100. Його створили для авіамеханіків, для яких англійська не рідна. Суть не в бідності мови, а в однозначності: одна думка в реченні, один термін в одному значенні. Для української такого стандарту немає, але правила можна переказати словами. Для відповіді на лист ДПС це звучить так:
- терміни лише як у Податковому кодексі й у самому листі, один термін в одному значенні;
- речення до двадцяти слів, одна думка в реченні;
- структура незмінна: посилання на лист, факти, норма, прохання;
- чого не знаєш, позначай «[перевірити]» і нічого не вигадуй;
- правки роби лише у виділеному абзаці, решту не чіпай.
Це не робить модель однаковою. Це звужує простір, у якому вона може відрізнятися. І такий текст значно швидше перевіряти: коротке речення з одним терміном видно як на долоні. Мотив у Карпаті той самий: коли моделі беруть на себе більше роботи, наша частина зсувається до нагляду й розуміння.
Елочка: тридцять слів і потрібний стілець
Елочка Щукіна жила на тридцяти словах. Її слова означали все одразу, тому розуміли її лише ті, хто знав контекст. І проблема здебільшого в тому, що ШІ вашого контексту не знає. Просите «напиши коротко» і отримуєте «Блеск! Готово!»: коротко, впевнено, порожньо.
Але тридцять слів можна використати розумно: якщо в моделі є контекст, їй вистачить словника Елочки. Назвемо це методом Остапа: розхвалити шанхайських барсів, показати гарне ситечко й забрати потрібний стілець. Без обману, на відміну від Остапа. У промпті це виглядає так:
- Барси: навіщо все це затівається. «Лист на пояснення розбіжностей у декларації з ПДВ, адресат — інспектор».
- Ситечко: гарний зразок. Ваш минулий вдалий лист.
- Стілець: що саме забрати. Структура, обсяг, що змінювати.
І все це вміщається в тридцять слів:
Лист на пояснення розбіжностей у декларації з ПДВ. Зразок нижче. Така сама структура й тон. Міняй лише дати, суми й номер листа. Чого не знаєш — познач [перевірити]. До 200 слів.
У цьому запиті рівно тридцять слів, як у Елочки. Різниця одна: у кожного слова тут одне значення, а відповідь обмежена двомастами. Це режим для дедлайну: зразок, чітке завдання й жодних сюрпризів.
Налаштувати один раз, а не щоразу
Словник термінів, структуру листа, приклад «золотої» відповіді й перелік перевірок варто покласти в інструкцію проєкту або у власний скіл. Тоді повторюваний процес справді повторюється: не дослівно, а в межах, які швидко перевірити. Гарантії це не дає. Це наближає.
Мораль аудитора: варіативність моделі не лікується, але звужується. Рутину можна віддати ШІ, відповідальність ні. Підпис під листом до ДПС ставите ви.
Джерела
- Andrej Karpathy, допис у X (початок жовтня 2026) — у переказі: Search Engine Journal, OpenAI Founding Member: Make LLMs Write Like An Aircraft Manual; Max Nardit, Karpathy on understanding LLM outputs.
- Laban P., Hayashi H., Zhou Y., Neville J. LLMs Get Lost In Multi-Turn Conversation. arXiv:2505.06120 (2025).
- ASD-STE100, Simplified Technical English — про обсяг затверджених слів (близько 900), у переказі Search Engine Journal.
- Ільф І., Петров Є. Дванадцять стільців.
А ви що закріпили в інструкції, щоб відповідь більше не «плавала»?