Як працює сучасний ШІ: ШВК, техніки формулювання запитів, RAG, агенти та MCP — пояснення.
Просте пояснення архітектури ШІ: як ШВК прогнозують токени, чотири техніки формулювання запитів, RAG із ембеддингами, цикл агента ReAct та функції MCP.
Джерела: Beyond the Buzzwords: How Modern AI Actually Works (From LLMs to Agents)
LLM, GenAI, RAG, MCP. Абревіатури з’являються швидше, ніж хтось встигає їх знайти, і може здатися, ніби хтось просто кидає літери у стіну. Однак ідеї, що стоять за ними, не є чимось магічним. Якщо позбутися жаргону, кожна з них є досить інтуїтивно зрозумілою. Ось як елементи сучасного ШІ поєднуються між собою у порядку, який полегшує їх розуміння.
Генеративний ШІ та LLM — це не одне і те саме
Люди використовують ці два терміни як синоніми, але один включає в себе інший.
- Генеративний ШІ — це широка категорія. Вона охоплює будь-яку систему, яка створює щось нове: текст, зображення, аудіо чи відео.
- Великі мовні моделі — це одна з гілок цієї категорії. Якщо генеративний ШІ — це „транспортні засоби“, то LLM — це спортивний автомобіль: система, навчена на величезній кількості тексту, щоб вона могла розуміти та створювати людську мову.
Що насправді робить LLM
LLM — це двигун прогнозування, і в ньому немає нічого, що нагадувало б людську думку чи почуття. Найближчою аналогією є найсучасніший автодоповнювач, який коли-небудь створювався.
Ваш вхідний текст розділяється на маленькі одиниці, які називаються токенами — зазвичай це цілі слова або їх фрагменти. На основі всього, що було опрацьовано під час навчання, модель розраховує ймовірність кожного можливого наступного токена. Якщо ви напишете „Чашка гарячого...“, математичні розрахунки можуть показати 90% ймовірності для слова „кави“ та 1% — для слова „цементу“. Модель обирає найімовірніший варіант продовження, додає його та повторює процес з дивовижною швидкістю.
Інженерія запитів
Якщо LLM — це просто машини для прогнозування ймовірностей, як вони створюють якісні есе чи функціональний код? Відповідь значною мірою полягає у тому, як ви формулюєте запити. Інженерія запитів — це практика формулювання запитів так, щоб результат був якомога кориснішим.
Уявіть собі талановитого стажера, який добре знає світ, але нічого не знає про ваші цілі. Нечітке завдання призводить до нечіткого результату, а чітке — до точної роботи.
Існує десятки технік, але чотири з них охоплюють більшу частину того, на що покладаються розробники та активні користувачі.
1. Надання ролі. Дайте моделі певну роль, наприклад "дійте як старший інженер програмного забезпечення, який переглядає кодову базу старих проектів". Це обмежує її словниковий запас та звички форматування, що допомагає уникнути загальних формулювань та спонукає до практичних, конкретних відповідей.
2. Надання прикладів. Перед виконанням справжнього завдання покажіть два-три готові приклади бажаної форми вхідних та вихідних даних. Структури коду та схеми JSON легко можна неправильно прочитати, тож один чіткий приклад "хорошого" результату усуває більшість припущень та помилок у форматуванні.
3. Ланцюгові запити. Розділіть велике завдання на послідовність менших запитів. Один запит може описати архітектуру, наступний — створити схему бази даних, а третій — написати кінцеві точки API на основі цієї схеми. Моделі втрачають концентрацію протягом тривалого часу, тому розділення кожного кроку на невеликі частини забезпечує кращий код та менше помилок під час компіляції.
4. Метазапити. Попросіть модель написати, вдосконалити або виправити сам запит, наприклад: «Я хочу досягти X, тож напишіть найкращий запит для LLM, щоб це зробити». Модель досить добре розуміє власні обмеження, що може заощадити години спроб та помилок.
Усі чотири методи працюють однаково. Керуючи контекстом, ви звужуєте можливості моделі, щоб вона використовувала лише ту частину знань, яка стосується «експертного інженера».
RAG: надання моделі свіжих фактів
У ШІ з великими мовними моделями є вбудована обмеженість — вони застигають у тому стані, у якому були під час завершення навчання. Модель, створена у 2023 році, не може знати, що команда RCB виграла трофей IPL у травні 2026 року. Вона також нічого не знає про приватні матеріали, такі як внутрішні PDF-файли вашої компанії.
Технологія покращення генерації шляхом пошуку інформації, або RAG, усуває цю прогалину. Уявіть іспит з відкритою книгою: замість того, щоб покладатися лише на те, що було запам’ятано давно (базове навчання), ви можете під час відповідей користуватися товстим підручником.
Чотири кроки
- Запит. Ви ставите запитання на кшталт "Якими були наші цілі з продажів у третьому кварталі?"
- Пошук. Перш ніж модель побачить запитання, система шукає у власних документах компанії інформацію про цілі з продажів у третьому кварталі.
- Покращення. Знайдені документи додаються до тексту запиту.
Чому моделі створюють халюцинації
Оскільки LLM — це прогнозувальний механізм слів, його справжня мета — звучати статистично правдоподібно, а не бути фактично точним. Якщо запитати про політику компанії, якої не існує, ви не побачите помилки 404. Модель створить переконливу політику з нічого. Вона не бреше навмисно — вона слідує своїм ймовірностям у напрямку того, що виглядає як правильна відповідь. RAG зменшує це, змушуючи модель ґрунтувати свою відповідь на реальних фактах, які ви надаєте.
Чому пошук такий швидкий
Класичні пошукові системи шукають точні збіги ключових слів, але ШІ має зрозуміти сенс, і саме це є завданням ембеддингів.
Коли завантажуються PDF-файли компанії, спеціалізована модель перетворює текст на довгий список чисел, які відображають його зміст. Ці списки зберігаються у векторній базі даних. Під час постановки запитання система так само перетворює ваше запитання на числа та шукає найбільш схожі результати в базі даних. Саме тому правильний уривок повертається навіть тоді, коли ви формулюєте запитання інакше, ніж у документі.
RAG порівняно з тонкою налаштуваністю
Ці два підходи часто спричиняють плутанину. RAG — це іспит з відкритою книгою: ви передаєте моделі тимчасові нотатки, пов’язані з певним запитанням. Тонкокоригування більше схоже на повернення моделі до аспірантури — воно постійно змінює внутрішні ваги моделі, щоб вона опанувала певний тон, формат чи спеціалізовану лексику, наприклад медичну чи юридичну. Для оновлення фактичних знань RAG є швидшим, дешевшим та значно простішим у керуванні.
Агентський ШІ: від чат-бота до цифрового працівника
Більшість людей досі використовують ШІ пасивно. Ви вводите запит, отримуєте відповідь і обмін закінчується. Агентський ШІ перетворює пасивного асистента на активного агента. Агент отримує мету, набір інструментів та свободу самостійно знаходити способи досягнення цієї мети без постійного керування ззовні.
Робочий процес
Якщо попросити звичайний LLM спланувати п’ятиденну поїздку до Бангалора, він миттєво створить загальний маршрут. Агент працює у циклах, замість того щоб передбачати одну відповідь. Цей підхід називається ReAct — скорочення від reasoning and acting, і він передбачає послідовність мислення, дії та спостереження:
┌────────────────────────┐
│ │
▼ │
[Thought] ──> [Action] ──> [Observation] ─┘
- Мислення — це крок обґрунтування. Модель аналізує запит та вирішує, що робити. Якщо хтось хоче дізнатися про погоду в Хайдарабаді, модель робить висновок, що не знає сьогоднішніх умов, і їй потрібен зовнішній джерело інформації.
- Дія — це вибір моделлю інструменту чи API для виклику, наприклад
call_weather_api(location="Hyderabad"). - Спостереження — це результат з реального світу, який надходить від цього інструменту, наприклад "25°C та дощ"
Потім цикл починається знову. Модель бере спостереження, формує нову думку (тепер у неї є інформація про погоду та можливість написати відповідь) і нарешті відповідає.
MCP: універсальний роз’єм
Коли агенти починають поширюватися, вони стикаються з проблемою: як їм дістатися до решти цифрового світу? Slack, GitHub, Google Drive та Notion організовують свої дані по-різному, і підключення ШІ до кожного з цих сервісів раніше означало створення окремого мосту для кожного додатку.
Model Context Protocol (MCP) — це відкритий стандарт, який функціонує як універсальний порт USB-C для ШІ.
[ AI Model ]
│
▼ (Via MCP - Universal Standard)
[ MCP Server / Plug ]
├── Connected to your Slack
├── Connected to your GitHub
└── Connected to your Local Files
Замість тисяч окремих інтеграцій додатки впроваджують MCP лише один раз. Після цього будь-яка сумісна модель може безпечно читати дані додатку, використовувати його інструменти та розуміти контекст. Саме ця інфраструктура дозволяє агентам обробляти електронну пошту, оновлювати таблиці та працювати з кодовими базами.
Простіший спосіб уявити це
MCP робить для програмного забезпечення те саме, що UPI робив для платежів в Індії. До появи UPI для надсилання грошей потрібно було збирати номер рахунку, код IFSC та назву філії, потім чекати, поки одержувач буде активований, або користуватися п’ятьма додатками-гаманцями, які не могли взаємодіяти один з одним. UPI замінив це на один сканований код, який досягає кожного банку. MCP — це такий самий універсальний інструмент для штучного інтелекту. Розробники більше не повинні писати спеціальний код API, щоб поєднати модель із Slack, потім з GitHub та ще одним додатком. Кожен додаток встановлює стандартний плагін MCP, і будь-яка модель може під’єднатися, читати дані та запускати дії. Це своєрідна автомагістраль, яка дозволяє агентам переміщатися між панеллю Jira, електронною поштою Outlook та продакшн-кодовою базою.
Як усе це пов’язано
Якщо розмістити елементи у правильному порядку, напрямок стає зрозумілим. Генеративні ШІ та LLM навчилися розмовляти, як люди. Інженерія запитів навчила користувачів ефективно відповідати. Технологія RAG забезпечує актуальними фактами та приватними даними. Агентські ШІ тепер вирішують складні проблеми, причому MCP слугує з’єднувальним елементом, який поєднує ці агенти з програмним забезпеченням у всьому світі.
Бум ШІ не стосується того, що машини стають свідомими. Йдеться про те, що машини стають добре пов’язаними, здатними інструментами, а розуміння того, як працюють їхні механізми, допомагає отримати з них максимум користі.