Основи LLM

Одна операція, повторена багато разів

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

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

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

Контекстне вікно — це вся памʼять

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

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

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

Обмеження, які структурні, а не помилки

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

Ще два обмеження випливають із того, як роблять модель. Її ваги заморожені на межі навчання, тож усе пізніше — реліз, зміна цін, інцидент, ваша ж документація з минулого тижня — просто не всередині, і питання про це дає описану вище правдоподібну вигадку, а не зізнання. І той самий промпт не гарантує тієї самої відповіді двічі: вибірка випадкова за побудовою, а навіть за найнижчої температури пакетування й відмінності заліза на боці постачальника лишають точну відтворюваність недосяжною. Будь-який тест, що звіряє точний рядок відповіді, рано чи пізно впаде з причини, ніяк не повʼязаної з вашою зміною.

Як це виявляється в реальній поставці

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

Рядок витрат на LLM-функцію — це майже завжди токени на запит, помножені на кількість запитів, і непомітно росте саме перший множник. Промпти накопичуються: вказівка, додана після кожного інциденту, довший приклад, ще три знайдені документи — а під усім цим історія розмови. Логуйте кількість токенів кожного виклику з першого дня, поруч із затримкою: це єдиний спосіб побачити зростання, і він перетворює туманне «AI-функція подорожчала» на конкретний промпт, який можна підрізати.

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

Де це вироджується

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

Коли це застосовувати

Пов’язані сторінки

• РозробкаПромпт-інженеріяПромпт-інженерія — це робота над інструкцією, за якою діє мовна модель. Промпт — це специфікація, а не замовляння. Фрази, якими обмінюються як трюками, працюють лише тому, що додають інформацію, якої модель інакше не мала; ті, що інформації не додають, не роблять нічого. На цій сторінці — з чого складається промпт, які прийоми справді змінюють результат, як зрозуміти, чи допомогла зміна, і чому недовірений текст у промпті — це межа безпеки, а не питання формулювання.
• РозробкаRAG-архітектураRetrieval-augmented generation (RAG) — це спосіб змусити модель відповідати про дані, на яких її не навчали: спершу знайти доречні фрагменти, покласти їх у промпт і вимагати, щоб відповідь походила саме з них. Тому RAG — це пошукова система з мовною моделлю на кінці, і тому майже кожна хибна відповідь є збоєм пошуку, а не генерації. На цій сторінці — обидва конвеєри, як вимірювати пошук окремо, і проблема прав доступу, що перетворює демо на інцидент.
• РозробкаLLMOpsLLMOps — це практика тримати в продакшені фічу, побудовану на мовній моделі, і вона існує тому, що все, що робить програму придатною до релізу — тест, який падає, дифф, що пояснює зміну, відкат, який повертає вчорашній стан, — припускає, що той самий ввід дає той самий вивід. LLM-функції це припущення ламають, тож практики доводиться перебудовувати навколо цього. На цій сторінці — що заступає набір тестів, чим насправді є артефакт розгортання, що записувати на кожному виклику і як поводяться вартість і затримка, коли приходить справжній трафік.