JavaRush/Java блог/Random UA/Як влаштована велика мовна модель
Dr-John Zoidberg
16 рівень

Як влаштована велика мовна модель

Стаття з групи Random UA
учасників

Ви надсилаєте запит, і за секунду в терміналі починає набиратися відповідь. Не з'являється вся одразу, а саме набирається: фрагмент за фрагментом, наче хтось друкує її саме зараз. Іноді перед цим на екрані висить Thinking, відповідь приходить помітно пізніше, зате змістовніша.

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

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

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

Мовна модель оцінює продовження

Почнемо із самого предмета. Велика мовна модель, або LLM, від large language model, - це не програма з вікном і кнопками й не чат. Це механізм, до якого звертаються: йому передають текст розмови, він повертає продовження. Claude Code, вебчат, підказки в редакторі - усе це оболонка навколо такого звернення, і в кожному продукті вона своя.

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

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

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

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

Чим LLM відрізняється від чату й агента

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

  • LLM - сама мовна модель. Отримує контекст і генерує наступне повідомлення.
  • Чат - інтерфейс і програма навколо LLM. Він зберігає історію, складає запит, надсилає його моделі й показує відповідь.
  • Агент - LLM із метою, циклом роботи та інструментами. Він може попросити застосунок прочитати файл, виконати пошук або запустити тест, переглянути результат і вибрати наступний крок.
Спрощена схема трьох вкладених шарів: усередині агента розташований чат, а всередині чату мовна модель. LLM генерує повідомлення, чат додає історію та інтерфейс, агент додає мету, цикл роботи, інструменти й дозволиАгентмета · цикл роботи · інструменти · дозволиЧатінтерфейс · історія · складання контекстуLLMконтекст → наступне повідомленняКожен зовнішній шар додає можливості навколо моделі
LLM - ядро; чат і агент додають навколо моделі свої можливості

Коротко: LLM пропонує рішення, чат організовує розмову, а агент пов'язує рішення моделі з діями в зовнішньому світі.

Токени, а не слова

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

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

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

Одна й та сама думка двома мовами: англійська фраза coffee every morning розбивається на три токени, а українська фраза кава кожного ранку також має три слова, але розбивається на п'ять токенів. Пробіл показано сірим прямокутником усередині наступного токенаАнглійська3 слова, 3 токениУкраїнська3 слова, а токенів уже 5coffeeeverymorningкавакожногоранку
Сірий прямокутник - це пробіл: він нікуди не зникає, а переїжджає всередину наступного токена. Розбиття приблизне, кожна модель має свій словник

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

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

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

Як із токенів складається відповідь

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

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

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

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

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

Що відбувається в терміналі

Те, як відповідь проступає у вікні Claude Code, - не індикатор завантаження, а самі кроки генерації: модель віддає кожен токен, щойно його вибере, а програма одразу виводить його на екран. Тому довга відповідь з'являється поступово, а не виникає вся після паузи.

Чому модель називають великою

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

Перший - обсяг тексту, через який модель пройшла під час навчання: книжки, статті, документація, форуми, код, і все це в кількостях, яких людині не прочитати за кілька життів. Другий - кількість параметрів. Параметр - це одне число всередині моделі, одне з налаштувань, які підлаштовувалися під час навчання. Їх мільярди. У назву відкритих моделей це число виносять прямо: 7B, 14B, 70B, де B означає billion, мільярд.

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

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

Звідки в моделі знання

Джерел лише два, і плутанина між ними дорого коштує.

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

Друге - те, що саме зараз лежить у розмові: ваш запит, усе сказане до нього, вміст відкритих файлів, вивід запущених команд. Це джерело точне, але короткочасне. У параметри воно не переїжджає, і наступна розмова вже нічого про нього не знає.

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

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

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

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

Що означає Thinking

Коли на екрані з'являється Thinking, модель не перемикається в якийсь інший режим свідомості. Їй просто дали місце подумати до того, як вона почне відповідати. Технічно це та сама генерація: спочатку модель пише чернетку для себе - розбирає завдання, оцінює варіанти, сперечається сама із собою, - і лише потім видає фінальний текст. Скільки саме думати, сучасні моделі значною мірою вирішують самі: для простого запитання чернетка коротка або її немає взагалі, для заплутаного - довша.

Один запит може одразу перейти до швидкої відповіді або пройти через розбір завдання й перевірку перед фінальною відповіддюОдин запит - різний бюджет до відповідіШвидкоЗапитШвидка відповідьThinkingЗапитРозбірПеревіркаВідповідьДругий шлях витрачає більше часу й токенів до фінальної відповіді
Один і той самий запит може отримати швидку відповідь або додатковий час на розбір і перевірку

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

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

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

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

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

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

Що працює краще, ніж "подумай як слід"

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

Чого модель не вміє

Список короткий, і знати його краще заздалегідь, ніж з'ясувати під час реального завдання.

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

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

Що це пояснює в поведінці агента

Ось що з цього механізму видно безпосередньо на екрані Claude Code:

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

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

Відео: та сама механіка в картинках

У каналі 3Blue1Brown є коротке відео, яке збирає основне в одну наочну анімацію: токени, ймовірності наступного слова, attention і те, звідки взагалі беруться параметри моделі. Називається воно Large Language Models explained briefly.

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

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

Коментарі
  • популярні
  • нові
  • старі
Щоб залишити коментар, потрібно ввійти в систему
Для цієї сторінки немає коментарів.