П’ятнадцять концепцій LLM, розглянутих через одне запитання від бота-підтримки
Пройдіться з допомогою AI-асистента через одне запитання клієнта, щоб дізнатися, що насправді роблять моделі, токени, ембеддинги, контекст, RAG, агенти та механізми оцінки, і де кожен з них закінчується.
Клієнт відкриває вікно чату магазину та запитує, чи можна ще повернути навушники, куплені десять днів тому. Через кілька секунд асистент читає запит, перевіряє правила повернення товару магазину та пояснює можливі варіанти. Цей діалог здається простим, але він проходить через низку різних компонентів: текст перетворюється на числа, навчений модель обробляє їх, додаток може шукати внутрішні документи, а також може викликати інструмент для початку процедури повернення.
Термінологія, яку використовують інженери для цих кроків (токени, ембеддинги, інференс, RAG та інші), легко повторюється та може бути неправильно застосована. У цьому посібнику розглядаються п’ятнадцять основних термінів у порядку їх значущості для конкретного запиту; вони поділені на те, що відбувається до того, як клієнт звернеться, що відбувається під час формування відповіді, та що необхідно для того, щоб система могла діяти та їй довіряти. Для кожного поняття наводиться його визначення, чому воно має значення з інженерної точки зору та які хибні уявлення воно найчастіше спричиняє. Розглядайте цей список як основу, а не як повне описування всієї галузі; для більш детальної інформації про те, що варто вивчити далі, перегляньте нашу ієрархічну карту концепцій інженерії ШІ.
До того, як надійде запитання: модель та спосіб її навчання
Усе, що відбувається в цьому розділі, сталось задовго до того, як клієнт відкрив чат. Це визначає, що саме може робити асистент.
1. Модель: функція перетворення вхідних даних у вихідні
Модель — це математична система, яка перетворює вхідні дані у вихідні за допомогою шаблонів, отриманих з даних. Одна модель класифікує фотографії тварин; інша прогнозує часи доставки. Мовна модель працює з текстом та генерує його, прогнозуючи ймовірні наступні елементи поступово, крок за кроком.
Проста аналогія — це учень, який вирішив тисячі практичних задач. Стикаючись з новою задачею, він застосовує те, чого навчився під час практики, замість того щоб шукати ідентичне запитання. Ця аналогія є недосконалою, оскільки моделі не вчаться та не розуміють так, як люди, але вона передає основну ідею узагальнення на основі прикладів.
У сценарії магазину модель мови розуміє запитання та складає відповідь. Однак готовий продукт також включає інтерфейс користувача, джерела даних та, можливо, інструменти.
- Значення для інженерії: моделі є спеціалізованими. Та, яка вміє писати лаконічний текст, не обов’язково добре справляється з прогнозуванням попиту чи оцінкою ризиків шахрайства.
- Поширена помилка: ототожнення „моделі“ з „застосунком“. Модель — це лише один із кількох компонентів.
2. Параметри: числа, які кодують поведінку
Нейронна мережа містить дуже велику кількість налаштовуваних значень, які називаються параметрами. Найбільш відомим типом є ваги; ще одним є зсуви. Разом вони визначають, як перетворюється інформація під час її проходження через мережу.
Уявіть собі пульт керування, вкритий регуляторами: їх поворот змінює звук, а зміна параметрів — результати вихідної обробки. Навчання — це процес, який дозволяє керувати цими регуляторами.
Те, що навчився мовний модель, розташоване у величезних числових масивах. Зазвичай не існує окремого місця, де б зберігалося твердження на кшталт „Париж — це столиця Франції“. Частину тексту для навчання можна запам’ятати дослівно, але модель не є пошуковим архівом документів, які вона бачила.
- Інженерна значимість: кількість параметрів впливає на потреби у зберіганні, пам’яті та обчислювальних ресурсах, а також на її функціональність. Більша модель не гарантує кращих результатів для вашого конкретного завдання.
- Поширена помилка: уявлення про параметри як про базу даних зі збереженими відповідями. Насправді це налаштування, які були навчені.
3. Навчання: практика з зворотним зв’язком
Навчання коригує параметри моделі за допомогою даних та певної мети. Для мовних моделей стандартною метою є прогнозування наступного токену.
Візьмемо речення для навчання „Столицею Франції є Париж“. Моделі показують початок речення, вона формує прогноз щодо наступного елемента, а система навчання вимірює розбіжність між цим прогнозом та справжнім наступним токеном. Потім параметри коригуються для зменшення похибки. Повторюючи цей процес з величезною кількістю прикладів, це більше нагадує тренування з корекціями, ніж копіювання тексту до сховища.
Модель магазину була навчена ще до того, як з’явився перший клієнт. Це надало їй загальних мовних навичок, але ніщо не гарантує, що вона знає поточні правила повернення товару саме цього магазину.
- Інженерна значимість: вибір даних та форм об’єктів визначає як можливості моделі, так і типи помилок, які вона робить.
- Поширена помилка: припускати, що модель, яка опанувала мовні закономірності, також перевірила факти. Це не так.
4. Transformer: архітектура, яку використовують більшість мовних моделей
Transformer — це конструкція нейронної мережі, яка поєднує механізм уваги з іншими шарами обробки для перетворення вхідних даних у корисні результати. Уявіть собі конвеєрний завод: кожна станція удосконалює роботу, яка надійшла до неї, замість того щоб починати знову з неопрацьованого тексту.
У мовній моделі, заснованій на трансформерах, представлення токенів проходять через низку повторюваних шарів. Механізм уваги поєднує інформацію з різних позицій, інші компоненти трансформують представлення кожної позиції, а інформація про положення дозволяє моделі розрізнити фразу „собака кусає чоловіка“ від фрази „чоловік кусає собаку“. Кінцеве представлення перетворюється на оцінку для кожного можливого наступного токену, ці оцінки конвертуються у ймовірності, і обирається один токен.
- Інженерна значимість: знання архітектури допомагає поєднати інші концепції. Токени надходять у модель, ембеддинги їх представляють, механізм уваги встановлює зв’язки між ними, а вікно контексту визначає обсяг інформації, яку модель може сприймати.
- Поширена помилка: плутати архітектуру з навченою моделлю. Трансформер — це креслення; навчена модель — це конкретна інстанція з отриманими параметрами.
Поки генерується відповідь: від тексту до токенів до результату
Тепер користувач натискає «Надіслати». У цьому розділі описано, що відбувається під час цього запиту.
5. Інференція: запуск навченого моделювання
Інференція означає виконання навченого моделювання на новому вхідному даних для отримання результату. Якщо навчання — це тренування, то інференція — це складання іспиту.
Коли надходить запит від навушників, модель обробляє наданий вхідний даний, використовуючи наявні у неї параметри. У звичайному режимі роботи вона не перенавчається після кожного повідомлення; її параметри залишаються незмінними під час відповідей. Для генерації тексту процес інференсу є циклом: обчислюються ймовірності наступного токена, обирається один, він додається та процес повторюється до завершення відповіді. Те, як працює крок „обрати один“, є окремою темою, яка розглядається у нашому посібнику з температури, top-k та top-p.
- Значення для інженерії: саме під час інференсу визначаються затримки та витрати на обробку за кожен запит, тому це впливає на користувацький досвід та вартість послуг.
6. Токен: одиниця тексту, яку насправді бачить модель
Токен — це фрагмент тексту, визначений токенізатором. Залежно від токенізатора це може бути ціле слово, частина слова, знак пунктуації або інший фрагмент. Для ілюстрації: слово „headphones“ може залишатися цілим при використанні одного токенізатора, а розділятися на „head“ та „phones“ — іншого. Ніколи не припускайте, що одне слово дорівнює одному токену.
Кожен токен мапується на цілочисельний ID, і модель перетворює ці ID на числові представлення перед їх обробкою.
- Значення для інженерії: кількість токенів визначає, чи підходить вхідний даний, якою буде довжина результату та яка зазвичай є вартість виклику API. Однакове значення може потребувати різної кількості токенів у різних мовах чи форматах; наприклад, JSON та код часто токенізуються інакше, ніж звичайний прозовий текст.
- Поширена помилка: плутання токенів та їхніх ідентифікаторів. Токени — це фрагменти тексту; ідентифікатори — їхні числові позначення.
7. Ембеддинги: значення як положення у просторі
Ембеддинг — це числове представлення певного елемента: токену, речення, документа чи зображення. Зазвичай це вектор — упорядкований список чисел.
Уявіть собі розташування бібліотеки на карті так, щоб книги на схожі теми знаходилися поруч одна з одною. Ембеддинг надає кожному елементу координати на такій карті, що дозволяє вимірювати схожість. Добре підібраний модель ембеддингів для пошуку може розмістити запитання «Як повернути цей елемент?» поруч із запитанням «Яка у вас політика повернення?», навіть якщо ці запитання майже не мають спільних слів.
Корисно розрізняти два способи використання ембеддингів. У мовному моделі токен-ембеддинги є частиною способу представлення вхідних даних. У системі пошуку документні ембеддинги використовуються для пошуку релевантного матеріалу. Ідеї пов’язані, але способи представлення та навіть самі моделі, які їх створюють, часто відрізняються.
- Інженерна релевантність: саме ембеддинги забезпечують функціонування пошуку та пошуку інформації на основі значень.
8. Запит: інструкції та матеріали, які ви надаєте
Запит — це все, що надається моделі для керування її відповіддю: інструкції, запитання користувача, приклади та додатковий текст.
Порівняйте два запити. „Поясніть процедуру повернення“ — це розпливчасто. „Використовуючи наведену нижче політику, вирішіть, чи можна повернути навушники, куплені десять днів тому; якщо бракує необхідної інформації, запитайте її та не вигадуйте правил“ — це чітко визначає завдання, джерела інформації та алгоритм дій у разі проблем. Це різниця між тим, щоб попросити друга „купити щось у магазині“ та дати йому список із бюджетом.
У асистенті остаточний запит зазвичай формується додатком: інструкції розробника, повідомлення клієнта та текст політики, отримані з бази знань.
- Значення для інженерії: точні запити зменшують неоднозначність та дозволяють перевіряти очікувану поведінку.
- Поширена помилка: покладання на інструкції запиту як на засіб безпеки. Інструкції впливають на поведінку, але не забезпечують дотримання правил доступу. Усе, що ні в якому разі не повинно трапитися, потребує контролю поза межами моделі.
9. Вікно контексту: обмежений простір роботи
Вікно контексту — це кількість інформації, яку модель може обробити за один раз, вимірювана у токенах. Уявіть собі стіл: під час роботи ви можете розкласти на ньому нотатки, але його поверхня є обмеженою.
У цьому просторі знаходяться системні інструкції, історія розмови, отримані документи та результати роботи інструментів; залежно від системи, генерований результат також нараховується у межах ліміту. Коли розмова стає занадто довгою, додаток мусить втрутитися — наприклад, видаливши старі повідомлення, узагальнивши їх або знову отримавши необхідні фрагменти за потреби.
Контекст та параметри — це різні речі. Параметри були визначені під час навчання; контекст — це інформація, яка надається лише для поточного завдання.
- Інженерна значущість: потрібно свідомо планувати обсяг простору. Додавання більшої кількості тексту не означає надання більш корисного тексту, а неактуальний матеріал може відволікати модель.
- Поширена помилка: сприймати велике вікно як необмежену пам’ять або припускати, що кожна деталь у ньому буде використана правильно.
10. Увага: взаємозв’язок частин вхідних даних
Увага — це механізм, за допомогою якого модель поєднує інформацію з різних частин вхідних даних. Візьмемо повідомлення про те, що навушники були доставлені вчора, але замовлені за десять днів до цього. При розгляді питання про повернення товару може виявитися вирішальним те, чи починається лічення з моменту доставки чи купівлі, і саме увага дозволяє представленню питання відображати зв’язок між доставкою, замовленням та цими двома моментами часу.
У повсякденному житті це схоже на перечитування відповідних речень у тексті перед тим, як відповісти на запитання про нього. З технічної точки зору увага обчислює числові показники релевантності між позиціями та використовує їх для створення зважених комбінацій інформації. Різні компоненти та шари можуть виявляти різні види зв’язків.
- Інженерна значимість: концепція уваги пояснює, чому формулювання, порядок та навколишній текст змінюють відповідь, що має велике значення під час створення запитів та розбиття документів на частини.
- Поширена помилка: сприйняття ваг уваги як повного пояснення логіки моделі. Це лише один математичний сигнал, а не прозорий опис того, чому була отримана певна відповідь.
Орієнтація та адаптація моделі
Лише навчання моделі не може дати знань про поточну політику цього магазину. Дві техніки подолують цю прогалину зовсім різними способами.
11. RAG: знайдіть інформацію, потім відповідайте
Retrieval-Augmented Generation — це пошук відповідної інформації у момент запиту та її включення до контексту моделі, щоб відповідь могла на неї посилатися. Це схоже на іспит з відкритою книгою: книга є у розпорядженні, але студент все одно мусить зрозуміти запитання, знайти потрібну сторінку та правильно її застосувати.
Для продавця процес зазвичай виглядає так:
- Надходить запитання клієнта.
- Програма шукає у документах правил відповідні уривки.
- Найбільш відповідні уривки додаються до запитання у формулюванні завдання.
- Модель пише відповідь, ґрунтуючись на цих уривках.
Отримання інформації може ґрунтуватися на пошуку за ключовими словами, вбудованих моделях або їхньому поєднанні. Важливо те, що цей підхід не впливає на параметри моделі. Існуюча стаття RAG explained: how AI systems retrieve fresh knowledge on demand детальніше розглядає аспекти отримання інформації.
- Інженерна значущість: RAG — це спосіб, яким додатки використовують приватні, спеціалізовані або часто змінювані документи без необхідності повторного навчання.
- Поширена помилка: припущення, що RAG робить відповіді правильними. Він скорочує кількість непідтверджених відповідей, але система все одно може завантажити неправильний уривок або неправильно інтерпретувати правильний.
12. Тонке налаштування: додаткові вправи для більш вузької задачі
Тонку налаштування — це продовження навчання вже обученого моделі, зазвичай на меншому, спеціалізованому наборі даних, спрямованому на досягнення певної мети. Це схоже на те, як носій англійської мови практикується у складних відповідях для підтримки клієнтів.
Компанія може використовувати тонку налаштування з парами запитань клієнтів та ідеальних відповідей, щоб навчити модель послідовного тону, формату вихідних даних чи поведінки під час виконання спеціалізованих завдань. На відміну від вказування правил у запиті, тонке налаштування змінює навчені параметри або додає елементи, які впливають на поведінку моделі. Воно також може включати знання з конкретної галузі, проте є неефективним механізмом для фактів, які часто змінюються, оскільки кожна зміна вимагатиме нового циклу навчання.
- Значимість з інженерної точки зору: тонке налаштування є ефективним, коли повторювану поведінку неможливо стабільно досягти за допомогою простих запитів.
Коли система діє та як зрозуміти, що вона працює
Остання група тем стосується проблем, які виникають, що змінюється, коли асистент може виконувати певні дії, та як оцінити загальну ефективність.
13. Галюцинації: плавні, впевнені та без підтвердження
Галюцинація — це вихідний текст, який є хибним, вигаданим або не підтвердженим відповідними доказами. Припустимо, магазин дозволяє повернення товарів протягом семи днів, але асистент впевнено відповідає, що всі навушники можна повернути протягом тридцяти днів. Це твердження звучить правдоподібно та добре сформульоване, проте воно також є хибним.
Основною причиною є те, що мовні моделі генерують ймовірні продовження тексту, замість того щоб перевіряти твердження проти реальності. Висока ймовірність наступного токена нічого не говорить про те, чи є повне твердження правдивим. Галюцинації проявляються у вигляді вигаданих політик, цитат, людей, цифр та навіть сфабрикованих результатів роботи інструментів.
- Значення для інженерії: добре сформульована неправильна відповідь може завдати реальної шкоди, тому системам потрібні надійні докази, перевірка результатів та офіційний спосіб визнання невизначеності.
- Поширена помилка: сприйняття впевненої формулювання за надійність.
14. Агент: вибір та виконання кроків для досягнення мети
Штучний інтелект-агент — це система, яка використовує модель для прийняття рішень та виконання кроків щодо досягнення мети, зазвичай шляхом використання інструментів. Звичайний чат-бот може пояснити процес повернення товару; агент може знайти інформацію про замовлення, перевірити його придатність та скласти заявку на повернення.
Типовий цикл обробки заявок на повернення:
- Читаємо мету клієнта.
- Визначаємо, яка інформація відсутня, наприклад запис про замовлення.
- Використовуємо інструмент для пошуку замовлень, наданий додатком.
- Оцінюємо результат згідно з правилами.
- Або готуємо повернення товару, або ставимо уточнювальне запитання, або передаємо справу людині.
Модель ніколи не звертається до бази даних самостійно. Додаток надає доступ до інструменту, перевіряє дозволи та виконує операцію; модель лише пропонує виклик. Рівень автономії сильно варіюється — від одного виклику інструменту до довгих багатокрокових послідовностей, і не кожна фіксована автоматизація заслуговує на назву „агент“. Для отримання додаткової інформації про сам цикл дивіться розділ про розуміння AI-агентів: цілі, інструменти, пам’ять та цикл агента.
- Інженерна значимість: дії потребують чітких меж, обробки помилок та контрольних точок схвалення. Складання заявки на повернення грошей — це не те саме, що її схвалення.
- Поширена помилка: ототожнення здатності до дії з дозволом діяти без нагляду.
15. Оцінка: докази того, що додаток працює
Оцінка — це систематичне вимірювання того, наскільки добре модель чи повноцінний AI-додаток виконує свою поставлену задачу. Уявіть велосипед: перш ніж їздити на ньому в дорожніх умовах, необхідно перевірити гальма, кермо та колеса за різних умов, незалежно від того, наскільки гарний він виглядає.
Для асистента з поверненням коштів корисний набір тестів має включати принаймні:
- Замовлення, яке однозначно підходить для повернення.
- Замовлення, заявка на повернення якого надійшла після закінчення дозволеного терміну.
- Запитання, у якому не вказана дата покупки.
- Два документи політики, які суперечать один одному.
- Спроба знайти замовлення, яка провалилася.
- Спроба отримати повернення коштів, на яке клієнт не має права.
Оцінюйте правильність відповідей: чи підтверджуються вони доказами, чи належним чином виражена невизначеність, чи безпечно використовуються інструменти, а також час відгуку та витрати. Враховуйте ситуації, які команда не використовувала під час створення системи; тестування лише на знайомих прикладах перебільшує її якість.
- Релевантність для інженерії: демонстрація показує, що один приклад спрацював. Оцінка дозволяє зрозуміти, як часто система працює та де виникають проблеми.
- Поширена помилка: оцінювати стиль формулювань моделі замість того, щоб протестувати всю програму від початку до кінця.
Основні висновки
- Модель — це лише одна частина ШІ-застосунку; джерела даних, запити, інструменти, права доступу та тести визначають більшість аспектів її роботи в реальних умовах.