MCP, RAG і LLM: що насправді робить кожен шар у вашому застосунку

Якщо ви писали софт ще до буму ШІ, то напевно дивувалися, чому раптом усьому знадобилася абревіатура. AI, LLM, RAG, MCP, агенти, векторні бази даних. Багато розробників дивляться на цю купу й думають, що чудово випускали робочі застосунки без усього цього. Чесний спосіб пробитися крізь модні слова — запитати, що кожна з цих частин справді додає до того, що у вас уже є.

Почнімо з того, що ви вже знаєте

Припустімо, клієнт хоче побачити свої останні 5 оплачених транзакцій. Це не якась нова задача, і ваш застосунок уже з нею впорається.

User
 ↓
Application
 ↓
SQL
 ↓
Database
 ↓
Transactions

Запит за цим може бути зовсім простим:

SELECT *
FROM transactions
WHERE status = 'billed'
ORDER BY transaction_date DESC
LIMIT 5;

От і все. Ні ШІ, ні MCP, ні векторної бази, ні агента, і все чудово працює.

Варіації мало що змінюють

Тепер припустімо, що клієнтові потрібні не 5, а 37 транзакцій. Застосунок просто приймає параметр.

limit = 37

Або він просить оплачені транзакції за серпень на суму понад ₹10 000. Бекенд перетворює це на потрібний запит, і знову без жодного MCP.

Зазвичай саме тут з MCP починається плутанина. Хочеться думати, що MCP якось сам розбереться, як запитувати вашу базу. Не розбереться. MCP не знає вашої схеми, не пише вашу бізнес-логіку, не дістає дані сам по собі й не робить застарілим застосунок, який ви вже побудували.

То що ж таке MCP?

Найкоротше визначення, яке витримує перевірку, звучить так: MCP — це спільний протокол, який дає ШІ-застосункам змогу знаходити інструменти й джерела даних і викликати їх однаково.

Уявіть три ніяк не пов'язані системи. Транзакції лежать у базі даних.

Transactions → Database

Звернення до підтримки зберігаються в CRM або Jira, а політики компанії — у RAG-системі на основі векторної бази.

Support Tickets → CRM/JiraCompany Policies → RAG / Vector Database

ШІ-асистентові можуть знадобитися всі три. MCP може опублікувати кожну як можливість, яку асистент знайде й викличе:

get_transactions()
get_support_tickets()
search_knowledge_base()

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

Отже, він марний?

Ні, просто він розв'язує не ту задачу, про яку люди думають насамперед.

Якщо ви робите один застосунок і самі володієте бекендом, викликати свої функції напряму як інструменти цілком розумно. Усе змінюється, коли споживачів кілька.

AI Agent 1
AI Agent 2
AI Agent 3
Customer Chatbot
Internal Copilot

А тепер уявіть, що всім їм потрібен один і той самий набір систем:

CRM
Jira
Databases
Internal APIs
Knowledge Base
Cloud services

У цей момент у вас уже задача інтеграції. Без спільного протоколу кожен ШІ-застосунок вигадував би свій спосіб спілкуватися з кожною системою. MCP натомість пропонує один спільний інтерфейс, і саме тут стандарт починає окуповуватися.

Де місце RAG

З RAG розібратися простіше, бо він відповідає на питання пошуку. Хтось питає, яка політика повернень, а RAG перебирає велику купу документів і повертає потрібні фрагменти.

MCP цього не замінює. Свою RAG-систему можна навіть опублікувати через MCP. Три ролі чітко розділяються:

• RAG знаходить потрібну інформацію.
• MCP дає ШІ стандартний спосіб дістатися до цієї можливості.
• LLM розуміє питання, вирішує, що їй потрібно, і міркує над тим, що повернулося.

Це різні роботи.

Головний урок

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

Ви роками будували API, бази даних, автентифікацію, пошук, кешування, інтеграції та бізнес-логіку. ШІ нічого з цього не скасовує. Він дає ще один спосіб із цим усім взаємодіяти. Іноді новий шар робить архітектуру кращою, а іноді це просто ще один шар. Розуміти, який випадок у вас, — найкорисніше, що варто винести з усіх цих абревіатур.