Як працюють LLM

Поясніть на пальцях, що LLM робить у своїй основі

Велика мовна модель (large language model, LLM) працює через передбачення наступного токена: вона дивиться на весь текст перед собою й прикидає, який фрагмент найімовірніше йде далі. Токен (token) — не обов'язково ціле слово, а шматок тексту: коротке слово повністю, частина довгого слова, розділовий знак чи пробіл. На кожному кроці модель рахує ймовірності для всього свого словника, обирає один токен, дописує його й повторює цикл уже з довшим входом; таку послідовну генерацію, що спирається на власний попередній вивід, називають авторегресивною (autoregressive). Тобто відповідь не з'являється цілком, а народжується по одному токену. Практичний наслідок: модель не «розуміє» ваш застосунок і не тримає в голові готову відповідь — вона щоразу продовжує текст найправдоподібнішим чином.

Чому кажуть, що в моделі немає окремої «бази фактів»

Бо знання не лежить довідником, який модель гортає, — воно розподілене по вагах (weights), мільярдах числових параметрів, налаштованих під час навчання так, щоб добре передбачати текст. Модель не зчитує факт, а відтворює статистичну закономірність мови, у якій цей факт колись траплявся. Тому вона не шукає правильну відповідь, а генерує найправдоподібніше продовження. Здебільшого правдоподібне збігається з правильним — саме тому LLM узагалі корисна. Але коли правдоподібне й правильне розходяться, модель без вагань видасть правдоподібне; звідси і галюцинації, і застаріла інформація.

Чим претрейн відрізняється від донавчання

Це два різні етапи. Претрейн (pre-training) — базове навчання на гігантському корпусі тексту, де модель мільярди разів передбачає наступний токен; ручна розмітка не потрібна, бо правильна відповідь уже є в самому тексті (наступне слово), тому навчання називають самокерованим (self-supervised). Результат претрейну — потужний автодоповнювач, який усотав граматику, факти й патерни коду, але ще не вміє слідувати проханням: на «напиши тест-кейс» він може дописати щось недоречне, бо просто продовжує текст. Донавчання (fine-tuning) робить із автодоповнювача помічника: спершу instruction tuning на парах «інструкція → добра відповідь», потім часто RLHF. Для QA важливо, що поведінка моделі — наслідок навчання на текстах і людських уподобаннях, а не «чиста логіка».

Що таке RLHF і як воно впливає на поведінку моделі

RLHF (reinforcement learning from human feedback, навчання з підкріпленням на людських оцінках) — етап донавчання, де анотатори порівнюють кілька варіантів відповіді моделі й відзначають кращий, а модель поступово зсувається в бік того, що людям подобається: корисність, безпечність, ввічливість. Наслідок, що прямо стосується QA: модель натренована звучати впевнено й догоджати, тож радше вигадає відповідь, ніж скаже «не знаю». Тому переконлива інтонація — вивчена манера, а не сигнал істинності: модель звучить однаково впевнено і коли має рацію, і коли галюцинує. Плутати тон із правотою — типова пастка.

Що таке температура і як вона впливає на вивід

Температура (temperature) керує тим, наскільки «сміливо» модель обирає наступний токен із розподілу ймовірностей. Близько нуля модель майже завжди бере найімовірніший токен — вивід передбачуваний і стабільний, але одноманітний. Вища температура «згладжує» розподіл, даючи шанс рідкіснішим токенам, — вивід різноманітніший і креативніший, але зростає ризик дурниць і галюцинацій. Точні межі залежать від провайдера (десь 0–1, десь до 2), тож важлива не цифра, а принцип: нижче — стабільніше й нудніше, вище — різноманітніше й ризикованіше. Для QA це важіль: коли треба відтворюваність (генерація за суворим форматом), температуру опускають; коли потрібні ідеї для мозкового штурму — піднімають.

Чим top_k відрізняється від top_p

Обидва обмежують, з яких токенів модель узагалі семплить, відкидаючи «хвіст» малоймовірних. top_k лишає фіксовану кількість — k найімовірніших токенів, решту відсікає. top_p (nucleus sampling) працює за сумарною ймовірністю: бере найменший набір найімовірніших токенів, чия сумарна вага досягає p, і семплить лише з них — тобто розмір набору «дихає» залежно від того, наскільки модель упевнена. Разом із температурою це інструменти балансу «стабільність проти різноманітності». На практиці їх крутять рідше за температуру, але розуміти механізм корисно, щоб не сприймати вивід моделі як магію.

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

Бо на кроці вибору токена працює семплінг (sampling) — випадковий вибір із розподілу ймовірностей, а не завжди найімовірніший варіант. Це закладено в механізм, а не збій: варіативність — норма, за неї відповідають семплінг і температура. Понизити температуру майже до нуля — вивід стане стабільнішим, ближчим до жадібного декодування (greedy decoding). Для тестувальника це фундаментальний зсув: ми звикли, що той самий вхід дає той самий вихід, інакше це дефект, а з LLM однаковість двох прогонів більше нічого не гарантує. Тому асерт на точний збіг відповіді з еталонним рядком — погана перевірка для LLM-фічі.

Чи гарантує температура 0 однаковий вивід щоразу

Ні. Низька температура робить вибір майже жадібним і суттєво стабільнішим, але повної повторюваності не дає навіть на нулі. Причина не в моделі як такій, а в інфраструктурі: обчислення з рухомою комою (floating point), паралельність на GPU й пакетна обробка запитів роблять так, що той самий вхід може зрідка дати інший вихід. Практичний висновок для QA: якщо тест на LLM-фічу спирається на «за температури 0 буде байт-у-байт те саме», він рано чи пізно флакне. Стабільність треба спеціально вимагати й усе одно не розраховувати на стовідсоткову гарантію.

Що таке галюцинація і чому вона стається

Галюцинація (hallucination) — це коли модель упевнено видає правдоподібну, але хибну чи вигадану інформацію: неіснуючий метод бібліотеки, вигаданий селектор, посилання на неіснуючу статтю, хибний номер RFC. Причина прямо випливає з механізму: модель оптимізована передбачати правдоподібний текст, а не істинний, і в неї немає вбудованої перевірки фактів чи способу відрізнити «я справді це знаю» від «це звучить так, ніби могло б бути правдою». Коли ви просите те, чого модель точно не бачила, вона однаково згенерує граматично й стилістично доречну відповідь — бо її робота продовжити текст, а не промовчати. Тому галюцинація — не випадкова вада, а природна поведінка на межі знань. Слабка відповідь на співбесіді — «модель іноді бреше»; сильна пояснює причину й способи знизити ризик.

Що підвищує ризик галюцинацій і як його знизити

Ризик росте на рідкісних чи свіжих речах (конкретні версії, точні сигнатури API), на проханнях назвати точні цифри чи джерела, за вищої температури й на довгих ланцюжках міркувань. Знижують його кількома прийомами: подати факти прямо в промпт замість покладатися на пам'ять моделі, попросити явно позначати невпевненість і — головне для QA — перевіряти вивід виконанням чи авторитетним джерелом. Правило жорстке: будь-який факт від LLM, що впливає на рішення, підлягає окремій верифікації. Це не недовіра до інструмента, а розуміння, що він оптимізує правдоподібність, а не істину.

Що таке knowledge cutoff і як його «обійти»

Межа знань (knowledge cutoff) — момент, до якого зібрано тренувальні дані моделі; усе, що сталося після, у вагах просто відсутнє: реліз бібліотеки, що вийшов пізніше, свіжа вразливість, учорашня зміна у вашому продукті. Небезпека в тому, що модель не скаже «я не в курсі» — вона впевнено видасть застаріле або галюцинацію. «Обходять» це не хитрощами, а джерелом інформації: різницею між параметричним знанням (у вагах, застигле) і контекстом (те, що ви подали в запиті зараз). Свіже й точне дають через контекст — вклеюють актуальну специфікацію, лог чи фрагмент коду прямо в промпт, і модель працює з ним, а не зі своїми застарілими здогадами. На системному рівні цю ідею масштабує RAG.

Яка різниця між параметричним знанням і контекстом

Параметричне знання (parametric knowledge) — те, що зашите у вагах під час навчання: величезне за обсягом, але розмите (модель пам'ятає патерни, а не дослівні цитати) і застигле на knowledge cutoff. Контекст (context) — усе, що приїхало в запиті зараз: сам промпт, вклеєні логи чи шматок коду, фрагмент документації, попередні репліки діалогу; воно свіже, дослівне, але обмежене вікном контексту. Ключове: контекст фактично перекриває параметричну пам'ять — якщо вклеїти актуальний фрагмент API в промпт, модель спиратиметься на нього, а не на застарілий здогад. Звідси практичне правило: не питай LLM про те, що вона мала б пам'ятати, — дай їй це в контексті.

Що таке embeddings і навіщо вони QA

Ембединги (embeddings) — спосіб записати шматок тексту як вектор, тобто довгий список чисел (сотні чи тисячі вимірів). Ключова властивість: тексти зі схожим змістом отримують близькі вектори, навіть якщо слова різні — «кнопка не клікається» і «елемент не реагує на натискання» ляжуть поруч у цьому просторі, а «рецепт борщу» — далеко; близькість міряють, наприклад, косинусною подібністю (cosine similarity). Для QA це відмикає кілька речей: семантичний пошук по документації, тест-кейсах і багах (шукаємо за змістом, а не за збігом слів), дедуплікацію баг-репортів чи тест-кейсів, сформульованих різними словами, кластеризацію схожих падінь. І, звісно, RAG — знайти релевантні фрагменти через ембединги й подати в контекст перед відповіддю.

Що таке RAG і яку проблему він розв'язує

RAG (retrieval-augmented generation, генерація з доповненням пошуком) — підхід, коли перед відповіддю в контекст моделі підтягують потрібні факти: знаходять релевантні фрагменти (часто через embeddings за змістом) і вклеюють їх у промпт. Це прямо лікує дві вади параметричного знання — застарілість (можна підтягнути свіже) і розмитість (модель працює з дослівним джерелом, а не з наближеним спогадом). По суті це системна автоматизація правила «дай факти в контекст». Для QA сама RAG-система стає об'єктом тестування: чи знайшлися правильні фрагменти, чи не загубився релевантний документ, чи модель не проігнорувала поданий контекст на користь власного здогаду.

Чому не можна тестувати LLM-фічу порівнянням «рядок у рядок» з еталоном

Бо вивід недетермінований: семплінг і температура роблять так, що той самий промпт легітимно дає різні формулювання, і навіть за температури 0 стовідсоткової повторюваності немає. Асерт «результат точно дорівнює еталонному рядку» червонітиме на цілком коректних відповідях — тест стане флакі не через баг продукту, а через природу інструмента. Оцінювати треба властивості відповіді, а не її буквальний текст: чи є потрібні поля, чи валідний формат, чи виконується згенерований код, чи семантично збігається з очікуваним. Це окрема велика тема, але корінь — саме в недетермінізмі.

AI згенерував автотест, і він одразу зелений. Чому це радше привід придивитися

Бо зелений колір нічого не доводить сам по собі: LLM легко пише тест, який завжди проходить, бо в ньому немає жодної реальної перевірки — асерт відсутній, пом'якшений або перевіряє тавтологію. Модель оптимізує правдоподібність коду, а не його доказову силу, і «виглядає як робочий тест» не дорівнює «перевіряє те, що треба». Ніхто нічого не запускав і не звіряв, поки ви цього не зробили. Тому зелений тест від AI — сигнал уважно прочитати, що саме він стверджує, і переконатися, що він упаде, коли фіча зламається. Робочий цикл — «згенерував → прочитав критично → перевірив → доробив», а не «згенерував → скопіював → пішов далі».

Коли б ви НЕ довіряли виводу LLM

Скрізь, де результат впливає на рішення й вимагає точності, свіжості чи гарантованої коректності: конкретні селектори й сигнатури API певної версії, точна арифметика й підрахунки «скільки саме», актуальні факти після knowledge cutoff, гарантія повноти покриття, судження про безпеку чи приватність. У всіх цих випадках вивід перевіряю виконанням або авторитетним джерелом, а не приймаю на віру через упевнений тон. І навпаки — довіряю як чернетці там, де потрібен правдоподібний структурований текст: каркас тесту, ідеї edge cases, переформатування вимог, пояснення незнайомої помилки. Червоний прапорець для інтерв'юера — відповідь «AI все зробить сам»; сильний кандидат каже, що AI прискорює, а відповідальність лишається на людині.

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

Кейс 1. Той самий промпт — два різні тести. Це баг генератора?

Ти двічі просиш AI-помічника накидати тест на форму логіну однаковим промптом і отримуєш два різні файли: різні назви тестів, різний порядок кроків, десь getByRole, десь getByLabel. Перша реакція — «інструмент зламався, треба фіксити». Насправді це очікувана поведінка, і плутати її з дефектом — типова пастка новачка в роботі з LLM.

Під капотом на кожному кроці модель рахує розподіл ймовірностей по наступному токену й обирає з нього випадково (семплінг). Уяви проміжок, де модель добирає слово після «Тест впав, бо елемент не»:

знайдено      0.42
видимий       0.31
клікабельний  0.18
активний      0.06
...            ...

За температури близько нуля модель майже завжди візьме «знайдено» — і два прогони збігатимуться. За вищої температури інколи випаде «видимий» чи «клікабельний», і далі текст піде іншою гілкою, бо кожен наступний токен залежить від уже обраних (авторегресивність). Звідси й два різні файли з одного промпту.

Що з цього випливає для рішення:

• Не асертити згенерований код байт-у-байт і не сприймати розбіжність як регресію генератора.
• Якщо потрібна стабільніша форма (той самий каркас, той самий формат) — опустити температуру; але пам'ятати, що навіть на нулі повної повторюваності немає через floating point, GPU й батчинг.
• Оцінювати не текст, а властивості результату: чи компілюється, чи запускається, чи асерт реальний, а не тавтологія.

Кейс 2. AI впевнено кличе метод, якого не існує

Просиш дочекатися видимості кнопки — і отримуєш правдоподібний на вигляд рядок:

// метод waitForSelectorVisible у Playwright не існує
await page.waitForSelectorVisible('#submit');

Виглядає переконливо: у Playwright є waitForSelector, є isVisible, тож склеєна назва waitForSelectorVisible «звучить» так, ніби мала б бути. Але її немає — при запуску впаде помилка, що метод не є функцією.

Це галюцинація, і механізм пояснює її без містики. Модель оптимізована продовжувати текст правдоподібно, а не звірятися з реальним API. На межі знань (точна сигнатура конкретної версії) вона не мовчить, а генерує граматично й стилістично доречний варіант — з тією ж інтонацією впевненості, що й правильний код. Впевнений тон тут — вихований RLHF стиль, а не гарантія існування методу.

Лікування — дати факти й перевірити виконанням, а не сперечатися з моделлю:

// коректний варіант: явне очікування стану через locator
await page.locator('#submit').waitFor({ state: 'visible' });

Що з цього випливає для рішення:

• Свіжу чи точну довідку (сигнатури, селектори, назви методів версії X) не брати з пам'яті моделі — вклеїти актуальний фрагмент API в контекст або звірити з автодоповненням IDE й документацією.
• Оракул тут — типи, лінтер і реальний запуск: те, що компілюється й проходить, а не те, що впевнено написано.

Кейс 3. Довіряти виводу чи верифікувати: таблиця рішень

Рівень довіри до відповіді LLM задає не інтонація тексту, а природа задачі. Груба, але робоча орієнтовна таблиця для щоденних QA-задач:

Логіка одна: там, де достатньо правдоподібного структурованого тексту на широких патернах (чернетки, ідеї, переформатування, пояснення), LLM економить години й бере роль прискорювача. Там, де потрібні точність, свіжість чи гарантована коректність (селектори, API, арифметика, повнота, безпека), вивід — гіпотеза, яку верифікуєш виконанням або джерелом. Відповідальність за результат при цьому лишається на людині: AI прискорює чернетки, а не приймає рішення.

Механізм генерації

• Можу пояснити, що в основі LLM — передбачення наступного токена, а не «розум», який тримає готову відповідь.
• Знаю, що таке токен і що він не дорівнює слову (може бути частиною слова, знаком, пробілом), і розумію авторегресивність: кожен новий токен дописується до входу, і цикл повторюється.
• Можу пояснити, чому в моделі немає окремої «бази фактів»: знання розподілене по вагах як статистика мови.

Як модель навчають

• Знаю різницю між претрейном (self-supervised передбачення токена на корпусі) і донавчанням (робить із автодоповнювача помічника).
• Можу пояснити, що дає instruction tuning і що — RLHF.
• Розумію, чому впевнений тон — наслідок RLHF, а не показник правоти: впевненість і правильність у LLM не пов'язані.

Семплінг і недетермінізм

• Розумію, що таке температура і як вона зсуває баланс «стабільно/нудно» проти «різноманітно/ризиковано».
• Знаю різницю між top_k і top_p (nucleus sampling).
• Можу пояснити, чому та сама модель дає різні відповіді (семплінг — випадковий вибір із розподілу), і знаю, що навіть за температури 0 повна повторюваність не гарантована (floating point, GPU, батчинг).
• Розумію, чому LLM-фічу не тестують порівнянням «рядок у рядок» з еталоном.

Галюцинації

• Можу пояснити, що галюцинація — не збій, а наслідок оптимізації правдоподібності замість істинності, і що вбудованої перевірки фактів немає.
• Знаю, що підвищує ризик (рідкісне/свіже, точні цифри, висока температура, довгі ланцюжки) і що знижує (факти в контекст, позначати невпевненість, перевірка виконанням).
• Не зводжу всі дефекти виводу до галюцинацій: розрізняю ще помилку міркування (reasoning error — хибна логіка на справжніх фактах) і упередження (bias — перекіс із даних навчання), і знаю, що виявляють їх по-різному.

Знання, контекст і knowledge cutoff

• Знаю різницю між параметричним знанням (у вагах, розмите, застигле) і контекстом (свіже, дослівне, обмежене вікном).
• Можу пояснити, що таке knowledge cutoff і чому модель не скаже «не знаю», а видасть застаріле.
• Розумію правило «не питай про те, що модель мала б пам'ятати — дай це в контексті» і як його масштабує RAG.

Embeddings

• Можу пояснити, що ембединг перетворює текст на вектор, і близькі за змістом тексти дають близькі вектори (cosine similarity).
• Знаю практичні застосування для QA: семантичний пошук, дедуплікація багів, кластеризація падінь, RAG.

LLM у роботі QA

• Знаю, де LLM сильна (чернетки, ідеї edge cases, каркас коду, пояснення, рерайт) і де слабка (повнота покриття, точні селектори/API, детермінізм, свіжі факти, арифметика, безпека).
• Можу сформулювати головний принцип: LLM — прискорювач чернеток та ідей, а не оракул істини.
• Розумію, чому зелений автотест від AI — привід придивитися, а не розслабитися, і можу назвати робочий цикл: згенерував → прочитав критично → перевірив → доробив.