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, базы данных, аутентификацию, поиск, кэширование, интеграции и бизнес-логику. ИИ ничего из этого не отменяет. Он даёт ещё один способ со всем этим взаимодействовать. Иногда новый слой делает архитектуру лучше, а иногда это просто ещё один слой. Понимать, какой случай у вас, — самое полезное, что стоит вынести из всех этих аббревиатур.