Skip to main content
LLMтокенизацияprompt engineering

Чому LLM не вміють рахувати літери

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

Технічний контекст

Я регулярно бачу той самий «тест на полуницю»: скільки літер у слові, скільки там r, чому модель несе нісенітницю. І так, для prompt engineering це корисний тест, але не на інтелект моделі, а на розуміння її архітектури та того, як ви будуєте AI automation навколо неї.

Проблема дуже приземлена: LLM не читає слово як послідовність символів. Вона отримує токени, зазвичай шматки слів, зібрані токенізатором на кшталт BPE. Для неї strawberry не зобов'язане існувати як s-t-r-a-w-b-e-r-r-y. Часто це 1-2 токени з уже «упакованою» внутрішньою структурою.

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

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

Ось де починається нормальна AI integration: я не змушую LLM рахувати те, що має рахувати інтерпретатор. Я даю моделі роль оркестратора. Нехай вона генерує Python, SQL або JS, а точну операцію виконує середовище виконання.

Що це змінює для бізнесу та автоматизації

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

Виграють команди, які будують AI solutions for business як зв'язку «LLM + tools», а не як магічний чат. Програють ті, хто намагається втиснути в один промпт і міркування, і точне виконання.

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

Ми раніше розбирали, як LLM-проксі та рівень абстракції допомагають знизити vendor lock-in, а також чому модератори часто помилково позначають технічні статті як контент, створений ШІ. Це ще один прояв того, як мовні моделі можуть неправильно інтерпретувати текст, подібно до того, як токенізація заважає їм рахувати літери.

Поділитися статтею