Більшість людей вміють створювати промпти для LLM. Але вбудувати таку модель у продукт, який витримує реальний трафік — це зовсім інша гра. Якщо ви хочете перейти від друку в чат-вікні до випуску AI-продуктів у продакшн, вам потрібно розуміти, як насправді взаємодіє весь стек. Це не магія. Це конвеєр окремих інженерних завдань, і кожен рівень має свої типи помилок.
Дозвольте мені розповісти, як працює сучасна AI-система: від моменту, коли ви вводите слово, до моменту, коли агент виконує завдання.
Основа: як мислять моделі
У своїй основі велика мовна модель робить лише одну річ: вона передбачає наступний токен. Цим токеном може бути наступне слово, частина слова або навіть символ. Усе інше — поезія, код, міркування — є емерджентною поведінкою, що виникає в результаті виконання цього єдиного завдання у великих масштабах.
Шлях від вашого промпту до відповіді моделі виглядає так.
Токенізація — це перший крок. Сирий текст не має сенсу для нейронної мережі, тому модель розбиває ваші слова на частини та зіставляє кожну частину з числом. Слово «tokenization» може перетворитися на три окремі токени. Фраза «New York» може стати одним або двома, залежно від словника. Ці числа не є довільними; вони походять із фіксованого словника, який модель вивчила під час навчання.
Коли слова стають числами, їм потрібен зміст. Ембедінги (embeddings) перетворюють ці числа на вектори — довгі списки значень з рухомою комою, які розміщують схожі поняття поруч у математичному просторі. «King» і «Queen» знаходяться близько одне до одного. «Paris» і «Berlin» групуються разом, але в іншому «районі», ніж «Python» або «JavaScript».
Але самі по собі вектори втрачають порядок. Позиційне кодування (positional encoding) вказує моделі, де саме в реченні знаходиться кожен токен. Без нього речення «The dog bit the man» та «The man bit the dog» виглядали б однаково.
Потім настає механізм уваги (attention mechanism). Саме тут модель аналізує всі токени у вхідних даних і вирішує, які з них важливі для передбачення наступного. Коли ви запитуєте: «Коли була заснована компанія і хто зараз нею керує?», моделі потрібно пов'язати «founded» із датою, а «leads» — з ім'ям CEO. Увага створює ці зв'язки.
Ці операції складаються в шари — часто їх десятки, — де ранні шари обробляють синтаксис, а пізніші вибудовують абстрактні міркування. Десь посередині нейронні мережі прямого поширення (feed-forward networks) зберігають фактичні асоціації. Саме тут модель утримує знання про те, що Париж — столиця Франції, або що певний API очікує JSON-пейлоад. Це не зовсім база даних, а стиснута мережа ваг, яка активує певні патерни.
Нарешті, декодування (decoding) перетворює внутрішні векторні представлення назад у зрозумілі людині токени. Модель не «знає», що пише англійською; вона просто ранжує тисячі можливих наступних токенів і вибирає найбільш імовірний, знову і знову, поки не досягне умови зупинки.
Рівень RAG: надання моделям пам'яті
Базова модель «заморожена» в часі. Її ваги охоплюють інтернет лише до певної дати відсікання, і вона не може отримати доступ до ваших приватних документів, якщо ви не надасте їх їй. Це робить її марною для більшості бізнес-завдань. Retrieval-Augmented Generation, або RAG, вирішує цю проблему, надаючи моделі зовнішню бібліотеку, до якої вона може звертатися перед відповіддю.
Концептуально налаштування є простим, але на практиці воно вимагає точності. Спочатку ви берете свої документи та застосовуєте чанкинг (chunking). Ви не закидаєте стосторінний PDF у вікно промпту. Ви розбиваєте його на абзаци, розділи або семантичні блоки, достатньо малі, щоб поміститися в межах контекстного вікна моделі, але при цьому зберігають зміст.
Кожен чанк проходить через модель ембедінгів (embedding model) і стає вектором, так само як і токени всередині LLM. Ці вектори зберігаються у векторній базі даних (vector database) — спеціалізованому сховищі, призначеному для пошуку за схожістю, а не для точного пошуку. Коли користувач ставить запитання, ви створюєте ембедінг його запиту і запитуєте базу даних: «Які чанки за змістом найближчі до цього вектора?»
Пошук лише за векторами часто пропускає точні збіги. Хороша продакшн-система використовує гібридний пошук (hybrid search), поєднуючи пошук за ключовими словами з семантичною схожістю. Якщо хтось запитує «SLA-99 compliance», вам потрібен документ, який буквально містить цей рядок, а не просто той, що здається схожим за змістом.
Після пошуку переранжування (re-ranking) відсіює шум. Початковий пошук може повернути двадцять чанків, але лише три або чотири з них дійсно корисні. Переранжувальник оцінює релевант
RAG lets a model read. Agents let it act.
An agent is fundamentally an LLM stuck inside a loop. It observes, reasons, acts, and then observes again. If you ask an agent to book a flight, it does not just describe how booking works. It breaks the task into steps, calls the right functions, reads the responses, and adjusts.
The loop looks like this. Observe: the agent reads the current state—your request, the results of previous tool calls, any errors. Reason: the LLM decides what to do next, often by generating a structured plan or selecting from predefined options. Act: it calls a tool.
Tools are how agents touch the real world. They are defined with JSON schemas that tell the model exactly what parameters an API needs. The LLM does not make arbitrary HTTP requests. It fills in a schema. "Call the weather API with city: London and units: metric." If the tool returns a temperature, the agent feeds
