RAG против MCP: что на самом деле нужно вашему приложению ИИ
RAG против MCP: RAG читает документы, а MCP взаимодействует с динамическими системами. Оба реализованы в коде; финансовый ассистент может быть создан тремя способами, и существует простое правило для выбора.
Источники: RAG vs MCP: A Complete Guide for Developers in 2026
Люди часто спрашивают, нужен ли им RAG или MCP, словно это два конкурирующих варианта в меню. На самом деле это не так, и как только каждый из них становится понятен, выбор становится почти механическим. Вот краткое изложение.
- RAG пополняет знания модели тем, чего она никогда не видела во время обучения, загружая соответствующий текст в промпт. Модель его читает.
- MCP — это стандартный протокол, с помощью которого модель может вызывать инструменты и взаимодействовать с системами. С его помощью модель выполняет действия.
- Простой способ их разделения: RAG отвечает за содержимое ваших документов, а MCP — за возможности ваших систем.
- Они не конкурируют. RAG — это техника, а MCP — протокол, поэтому вопрос «RAG или MCP?» похож на вопрос «кэширование или HTTP?»
- Любые изменения, такие как цены, запасы или остатки на счетах, плохо подходят для использования технологии RAG. Векторная база данных возвращает информацию, заложенную при индексации, а не данные, актуальные в данный момент.
- Большие объемы в основном статического текста, такого как документация, контракты или правила, неэффективно обрабатываться исключительно с помощью MCP. Это приводит к необходимости выполнения API-запросов для вопросов, на которые хорошо построенный индекс может ответить мгновенно.
- Большинство производственных систем в 2026 году сочетают оба подхода: MCP используется для получения свежих данных и выполнения действий, а RAG — для обеспечения модели стабильными знаниями из конкретной области.
Возьмем вопрос, который кажется простым, но на самом деле нет: каков коэффициент P/E компании Apple сегодня? Если использовать технологию RAG, результатом будет уверенный, грамотно сформулированный, но неверный ответ. Если использовать MCP, ответ будет правильным.
Тот же домен, тот же пользователь, совершенно другая архитектура. Далее рассматриваются обе идеи с самых основ, создаётся финансовый ассистент тремя способами, и в конце приводится правило принятия решений, которое можно применить без долгих раздумий.
Что такое RAG
Это аббревиатура от Retrieval-Augmented Generation. Если говорить простым языком, это три этапа: извлечение фрагментов текста, наиболее релевантных вопросу пользователя, дополнение запроса путём вставки этих фрагментов и затем генерация ответа на основе этого полученного контекста.
Представьте экзамен, на котором запрещены конспекты, но снаружи комнаты ждёт исследовательский ассистент. Вопрос просовывают под дверь, ассистент бежит в библиотеку, выбирает три лучшие страницы и снова просовывает их под дверь, после чего ответ пишется на основе этих страниц. Ничего не было изучено — просто нужные страницы появились в нужный момент.
Это и есть RAG. Веса модели никогда не меняются, поскольку редактируется только промпт, а не сама модель.
Почему здесь нужна векторная база данных
Самой сложной является первая стадия — поиск подходящих страниц. Поиск по ключевым словам часто терпит неудачу, так как вопросы людей редко содержат те же слова, что и исходный текст. Кто-то задаёт вопрос о «компаниях, теряющих деньги», в то время как в документе говорится о «отрицательном чистом доходе»: нет общих слов, но смыслы идентичны.
Эмбеддинги решают эту проблему. Такая модель преобразует текст в вектор — список чисел, при этом схожие по смыслу выражения оказываются рядом друг с другом. «Компании, теряющие деньги» и «отрицательный чистый доход» становятся «соседями», несмотря на отсутствие общего словаря. Векторная база данных хранит эти векторы и быстро отвечает на вопрос: что находится ближе всего к этому?
RAG в коде
Ниже приведена минимальная реализация без использования фреймворков, поэтому все компоненты видны. Она содержит несколько финансовых фрагментов, встраивает их, ранжирует их по коэффициенту косинусного сходства с вопросом и передаёт лучшие результаты в модель чата.
from openai import OpenAI
client = OpenAI()
# Your knowledge base, already chunked.
DOCUMENTS = [
"The P/E ratio divides share price by earnings per share. "
"When earnings are negative, P/E is undefined and usually shown as N/A.",
"EV/EBITDA is often preferred over P/E for capital-intensive companies "
"because it is unaffected by capital structure and depreciation policy.",
"The PEG ratio adjusts P/E by the expected earnings growth rate. "
"A PEG below 1.0 is traditionally read as undervalued.",
]
def embed(text: str) -> list[float]:
"""Turn text into a vector."""
response = client.embeddings.create(
model="text-embedding-3-small",
input=text,
)
return response.data[0].embedding
def cosine_similarity(a: list[float], b: list[float]) -> float:
"""How close are two vectors? 1.0 means identical direction."""
dot = sum(x * y for x, y in zip(a, b))
norm_a = sum(x * x for x in a) ** 0.5
norm_b = sum(y * y for y in b) ** 0.5
return dot / (norm_a * norm_b)
# Index once, reuse many times. In production this lives in a vector DB.
INDEX = [(doc, embed(doc)) for doc in DOCUMENTS]
def retrieve(question: str, k: int = 2) -> list[str]:
"""Step 1: find the most relevant chunks."""
q_vector = embed(question)
scored = [
(cosine_similarity(q_vector, vector), doc)
for doc, vector in INDEX
]
scored.sort(reverse=True)
return [doc for _, doc in scored[:k]]
def answer(question: str) -> str:
"""Steps 2 and 3: augment the prompt, then generate."""
context = "\n\n".join(retrieve(question))
prompt = (
f"Answer using only the context below.\n\n"
f"Context:\n{context}\n\n"
f"Question: {question}"
)
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": prompt}],
)
return response.choices[0].message.content
print(answer("What do I use when a company has negative earnings?"))
Посмотрите, что произошло. Модель никогда не обучалась на этих трёх фрагментах текста, однако она дала правильный ответ, потому что в её запрос попал нужный фрагмент.
Обратите также внимание на этот ограничение. RAG может возвращать только те данные, которые были индексированы. Если коэффициент P/E компании Apple изменился сегодня утром, а индекс был сформирован в прошлом месяце, RAG будет указывать значение прошлого месяца и выглядеть абсолютно уверенным в нём. Именно из-за этого ограничения и появился MCP.
Что такое MCP
MCP, Model Context Protocol, был представлен компанией Anthropic в ноябре 2024 года. Сообщается, что в декабре 2025 года он перешёл в Agentic AI Foundation — проект Linux Foundation, поэтому теперь он поддерживается в Claude, ChatGPT, Gemini, Cursor и VS Code и не является частным форматом одного поставщика.
Это стандарт для подключения ИИ-моделей к инструментам. Это не техника, а протокол, относящийся к той же семье, что и HTTP или SQL.
До появления USB-C у каждого устройства был свой собственный разъем, поэтому пятнадцать устройств означали пятнадцать несовместимых кабелей. Инструменты искусственного интеллекта выглядели именно так до появления MCP. Подключение 10 приложений ИИ к 100 инструментам могло потребовать написания до 1 000 индивидуальных интеграций, каждая из которых требовала отдельного обслуживания. MCP сокращает это до одного стандарта: поставщик инструмента реализует протокол один раз, и каждый совместимый клиент может им пользоваться, в то время как приложение ИИ реализует клиентскую часть один раз и может взаимодействовать со всеми инструментами.
Что предоставляет сервер MCP
- Инструменты — это функции, которые можно вызвать. Вызов такого кода, как
get_stock_price("AAPL.US"), запускает реальный код и возвращает реальный результат. - Ресурсы — это данные, которые может читать модель, такие как документация или содержимое файлов.
- Подсказки — это шаблоны, которые можно использовать повторно, и они позволяют объединить несколько инструментов в один полноценный рабочий процесс.
MCP в коде
Рабочий сервер представляет собой небольшую структуру. Приведённый ниже пример включает поиск цитаты и сравнение двух тикеров, и это всё.
from mcp.server.fastmcp import FastMCP
import httpx
mcp = FastMCP("finance-tools")
@mcp.tool()
def get_current_price(ticker: str) -> dict:
"""Get the latest price for a stock ticker.
The docstring matters more than you'd think. It is what the
model reads to decide whether to call this tool at all.
"""
response = httpx.get(f"https://api.example.com/quote/{ticker}")
return response.json()
@mcp.tool()
def compare_tickers(ticker_a: str, ticker_b: str) -> dict:
"""Compare two tickers on price, market cap and P/E ratio."""
return {
"a": get_current_price(ticker_a),
"b": get_current_price(ticker_b),
}
if __name__ == "__main__":
mcp.run()
Одна команда регистрирует его в Claude Code:
claude mcp add finance -- python /path/to/server.py
Теперь модель может выполнять действия. Она не просто читает информацию о ценах, а получает её напрямую.
Деталь, которую легко упустить из виду: документация служит интерфейсом. То, будет ли модель вообще вызывать какой-либо инструмент, зависит от того, как описан этот инструмент. Нечеткое описание приводит к тому, что инструмент никто не использует, и это обычная причина, по которой правильно установленный сервер MCP кажется неактивным.
Практические различия
Если сравнивать их вместе, они отличаются по своей природе и назначению. RAG — это техника, которая читает данные из индекса; MCP — это протокол, позволяющий взаимодействовать с живыми системами. RAG делает модель более осведомленной, а MCP — более способной к действию. RAG дешев и быстр в использовании за один запрос, поскольку основан на векторном поиске, тогда как стоимость MCP определяется стоимостью используемого API. RAG становится устаревшим вместе с индексом, а MCP возвращает информацию, которая сейчас имеется в исходном источнике.
Это правило укладывается в одно предложение. Ответ в документе? RAG. Ответ в системе? MCP.
Попробуйте на реальных вопросах. «Что означает коэффициент PEG?» находится в документе, поэтому RAG. «По какой цене торгуется Microsoft?» находится в системе, поэтому MCP. «Оформить заказ» или «отправить этот отчет» — это действие, поэтому MCP в любом случае, так как механизм поиска не может выполнять действия. «Что говорит наша политика возврата средств о товарах, уже открытых?» — это набор статического текста, поэтому RAG.
Почему люди продолжают спрашивать, одно ли это
Эта путаница имеет одну причину. Сервер MCP может публиковать документацию в качестве ресурса, и это напоминает процесс поиска информации. Разница между ними заключается в размере и механизме работы. Ресурсы включают ограниченный набор документов, которые модель может найти по идентификатору, тогда как RAG обрабатывает тысячи документов, при этом необходимо с помощью семантического ранжирования выделить три наиболее релевантных.
Эти два подхода также можно объединить. Внутри сервера MCP можно запустить целую схему RAG и представить её модели в виде инструмента search_knowledge_base. Затем модель вызывает этот инструмент, который является частью MCP, а этот инструмент выполняет операцию поиска информации, что и составляет часть RAG.
Один ассистент, созданный тремя способами
Абстрактные сравнения имеют свои ограничения, поэтому рассмотрим ассистента для финансового анализа, созданного каждым из способов, чтобы понять, где возникают проблемы. Финансы — хороший пример для тестирования, поскольку в этой области сосуществуют два типа вопросов: определения, которые никогда не меняются, и цифры, которые меняются каждую секунду. Для рыночных данных подходит поставщик вроде EODHD, поскольку он предоставляет традиционный REST API и официальный сервер MCP, что позволяет сравнивать архитектуры без необходимости менять поставщиков данных на протяжении всего процесса.
Версия А: только RAG
Создайте индекс корпуса финансовых знаний, а затем отвечайте на вопросы на его основе. Корпус представляет собой список кратких определений; в реальной системе его объем составляет несколько тысяч дополнительных фрагментов.
# Building a knowledge base of financial concepts
CORPUS = [
"Market capitalization equals share price multiplied by shares outstanding.",
"The P/E ratio compares share price to earnings per share.",
"Free cash flow is operating cash flow minus capital expenditures.",
"A dividend yield above 6% often signals either a falling share price "
"or an unsustainable payout ratio.",
# ...plus a few thousand more chunks
]
После индексации поступает концептуальный вопрос:
# Index them, then:
answer("Explain what a high dividend yield might indicate")
Этот случай работает отлично. Концепция не меняется со временем, ответ находится в корпусе, а система поиска его находит. Теперь вопрос к аудитории:
answer("What is Apple's current dividend yield?")
Это тоже проваливается, причем самым ужасным образом. Модель находит фрагмент текста, объясняющий, что такое доходность дивидендов, вспоминает, что во время обучения усвоила какие-то цифры по Apple, и генерирует что-то вроде «Доходность дивидендов Apple составляет примерно 0,5%». Ответ звучит уверенно, имеет правильный формат, но, возможно, устарел на несколько месяцев, при этом ничто в системе не выявляет эту проблему. Именно этот способ сбоя RAG люди недооценивают: он не вызывает ошибок, а возвращает плавно сформулированный, устаревший текст.
Вариант B: только MCP
Здесь модель подключена к актуальным данным.
# EODHD publishes two endpoints. v2 uses OAuth, v1 uses an API key.
claude mcp add --transport http eodhd https://mcp.eodhd.com/v2/mcp
Если задать вопрос снова, тот же самый вопрос теперь приводит к другому результату. Модель вызывает функцию resolve_ticker("Apple"), чтобы получить AAPL.US, затем использует инструмент для анализа фундаментальных показателей, чтобы получить сегодняшние данные. Эти цифры можно считать надежными, поскольку они получаются путем запроса, а не хранятся в памяти.
Два подхода к проектированию на таком сервере стоит изучить независимо от того, какой поставщик услуг вы используете, поскольку они решают проблемы, с которыми сталкивается любая система вызова инструментов. Во-первых, функция разрешения идентификаторов акций является инструментом первого класса. Пользователи говорят «Apple», в то время как API требуют AAPL.US; пользователи называют «Deutsche Bank», а API ожидают DBK.XETRA. Разрешитель, способный обрабатывать названия, частичные идентификаторы акций и ISIN, а также предлагать альтернативы, когда компания торгуется на нескольких биржах, вместо того чтобы просто делать угадывания, устраняет возможные сбои. Многие сбои при вызове инструментов в финансовых агентах происходят именно на этом этапе.
Во-вторых, документация встроена в виде ресурсов. Сообщается, что сервер поставляется с более чем ста страницами собственной документации API в формате ресурсов MCP, что позволяет модели проверять, какие параметры принимает конкретный эндпоинт, не тратя при этом вызов API. С архитектурной точки зрения это интересно: небольшая структура типа RAG, работающая внутри сервера MCP, где статические справочные материалы выступают в роли ресурсов, а актуальные данные — в роли инструментов, причем каждый из них выполняет свою функцию наилучшим образом.
Версия C: и то, и другое, то, что поставляется
По отдельности ни одна из версий не обеспечивает удовлетворительного результата. Вариант на основе RAG не может сообщить текущую цену, а вариант на основе MCP тратит вызов API на объяснение коэффициента P/E. Реальный дизайн направляет каждый вопрос в соответствующую подсистему.
def route(question: str) -> str:
"""Decide which subsystem answers this question."""
# Signals that the question is about live state
live_signals = ["current", "today", "now", "latest", "price", "quote"]
if any(signal in question.lower() for signal in live_signals):
return "mcp" # fetch it
return "rag" # look it up
Приведенный выше тест на ключевые слова преднамеренно упрощен. В производственных маршрутизаторах обычно используется следующая модель: предоставляются инструменты поиска и инструменты с доступом к актуальным данным, каждый из них подробно описывается, и система сама выбирает подходящий вариант. Разделение на категории остается неизменным.
На практике все происходит следующим образом:
- Вопрос «Что измеряет коэффициент P/E?» направляется в RAG: ответ получается мгновенно и практически бесплатно.
- Вопрос «Каков коэффициент P/E у Microsoft в настоящее время?» направляется в MCP: ответ актуален и требуется всего один вызов API.
- Вопрос «Высок ли коэффициент P/E у Microsoft по сравнению с другими компаниями в своей отрасли?» требует использования обоих инструментов: MCP для получения числового значения и RAG для получения контекста отрасли, который позволяет его интерпретировать.
Именно в третьем типе вопросов сочетание инструментов приносит наибольшую пользу, и они также наиболее близки к реальным вопросам пользователей.
Сравнения, которые путаются с этим
Еще три пары понятий часто путаются с вопросами, связанными с RAG и MCP, но каждая из них легко проясняется.
MCP против API. Сервер MCP обычно является оберткой вокруг API, а не его заменой. Разница заключается в целевой аудитории: REST API подходит для разработчика, который изучает документацию и пишет код интеграции, тогда как сервер MCP предназначен для модели, которая находит инструменты во время выполнения и читает их описания, чтобы определить, какой из них использовать. Основной API по-прежнему необходим, причем стандарт MCP унифицирует способ, которым модель находит и вызывает его. Вызывайте API напрямую из кода приложения с детерминированным поведением, а используйте MCP тогда, когда модели необходимо выбирать операцию во время выполнения.
MCP против агента. Они существуют на разных уровнях, поэтому сравнивать их — ошибка категорий. Агент — это та часть, которая рассуждает, планирует и принимает решения; MCP является его инструментом для взаимодействия с внешним миром. Без MCP агент может мыслить, но не действовать, а сервер MCP без агента не имеет пользователей. Claude Code в данном случае является агентом, а серверы MCP выполняют роль его «рук».
RAG против тонкой настройки. Оба метода влияют на возможности модели, но при этом используют разные подходы. Тонкая настройка изменяет веса модели и обучает её определённому поведению: тону, формату, стилю в конкретной области, единообразной структуре. Этот процесс дорог и медленный, а обновление знаний требует повторного обучения. RAG не меняет веса модели, а изменяет запрос и обучает её фактам; обновление в этом случае заключается в переиндексации документа, что занимает секунды. Как правило, используйте тонкую настройку для определения поведения модели, а RAG — для формирования её знаний. Если ответ меняется при изменении документа, это RAG. Если же он меняется при изменении руководства по стилю, возможно, речь идёт о тонкой настройке.
Выбор технологической стековой сборки
Любой, кто разрабатывает одну из этих частей, может выбирать среди множества решений, существующих в 2026 году.
Для части, связанной с RAG, требуется векторная база данных. Qdrant легко размещается локально в Docker и поставляется с официальным сервером MCP, поэтому к одному индексу можно получить доступ из скрипта или из Claude Code. Chroma — самый простой вариант для старта: он запускается за несколько минут без необходимости настройки инфраструктуры. Weaviate и Pinecone представляют собой более серьезные альтернативы, причем Pinecone предоставляет полный уровень обслуживания для команд, которые не хотят заниматься настройкой чего-либо сами. Что касается оркестрации, то LlamaIndex остается наиболее специализированной платформой для решения задач по поиску и индексации, тогда как LangChain имеет более широкий функционал, но является более тяжелым в использовании.
С точки зрения MCP, Composio объединяет множество приложений через единственный конечный пункт и загружает инструменты в нужный момент, что снижает нагрузку от работы десятков серверов. Arcade.dev рассматривает аутентификацию как ключевую проблему, вставляя токены OAuth в процесс выполнения инструментов, не выдавая их модели, что критично при участии нескольких пользователей. Mem0 относится к обеим категориям: это сервер MCP, предназначенный для работы с семантической памятью, то есть для поиска информации.
Далее идет вопрос наблюдаемости. Когда обе части системы работают, важно видеть, какие запросы на поиск возвращают бесполезные данные, а какие вызовы инструментов терпят неудачу; Langfuse, будучи open-source и позволяющим самостоятельную развертку, решает эту проблему.
Стоит отметить, что несколько поставщиков теперь предоставляют сервер MCP для продуктов, основная функция которых — поиск информации. На практике эти две концепции скорее сближаются, чем конкурируют.
Часто задаваемые вопросы
Является ли RAG тем же, что и MCP? Нет. RAG вставляет полученный текст в промпт, чтобы модель могла его прочитать, тогда как MCP позволяет модели вызывать инструменты и выполнять действия. Один из подходов делает модель более осведомленной, а другой — более функциональной. Они работают на разных уровнях и часто используются вместе в одном приложении.
Заменяет ли MCP RAG? Нет, и такое восприятие приводит к серьезным ошибкам в проектировании. MCP лишь стандартизирует способ вызова инструментов. Если требуется семантический поиск для 50 000 документов, всё равно необходимы эмбеддинги, векторная база данных и пайплайн поиска. MCP лишь изменяет способ доступа, так что пайплайн становится инструментом через стандартный интерфейс вместо индивидуальной интеграции.
Когда RAG является лучшим выбором? Когда ответ находится в большом, относительно стабильном объеме текста, таком как документация, контракты, правила, научные статьи или статьи с поддержкой. Этот метод стоит дешевле за запрос и обеспечивает более быстрые ответы по сравнению с двусторонними запросами к API. Переходите на MCP, как только ответ зависит от текущего состояния или когда пользователь хочет, чтобы что-то было сделано, а не объяснено.
Чем MCP-сервер отличается от API? Обычно MCP представляет собой слой поверх API. API — это сама возможность, а MCP — это стандартный способ для модели обнаруживать и вызывать ее. Разработчики читают документацию API во время разработки; модели читают описания инструментов MCP во время работы.
Требуется ли MCP векторная база данных? Нет. У MCP нет собственного компонента по поиску информации. Векторная база данных используется только в том случае, если инструмент, который вы предоставляете, поддерживает семантический поиск; в таком случае она находится за этим инструментом, а не рядом с ним.
Может ли сервер MCP работать с RAG внутри себя? Да, и это распространённая практика в производственных средах. Создайте обычную систему поиска и предоставьте её как отдельный инструмент, например search_internal_docs. Модель вызывает один инструмент, а встраивание данных и векторный поиск выполняются на фоне.
Что дешевле? После индексации RAG обычно оказывается более экономичным за один запрос: это небольшой вызов для генерации встраиваемых данных плюс поиск в векторной базе. MCP стоит столько, сколько стоит API, стоящий за ним; эта стоимость может варьироваться от низкой для получения котировок до высокой для работы в браузере или обработки документов. Дорогостоящей ошибкой является отправка вопросов в MCP, которые мог бы обработать статический индекс.
Как MCP связан с A2A? Они решают разные задачи. MCP соединяет модель с инструментами, а A2A (Agent-to-Agent) позволяет агентам обмениваться информацией. Один агент может обратиться к базе данных через MCP и передать задачу специализированному агенту через A2A, таким образом они дополняют друг друга, а не конкурируют.
Как можно быстро сделать выбор? Представьте, что запрос необходимо выполнить снова через час. Если ответ изменится, речь идет о динамическом состоянии, и требуется использование MCP. Если нет — это стабильные знания, и тогда нужен RAG. Затем следует узнать, хочет ли пользователь, чтобы что-то произошло, потому что в любом случае потребуется MCP: RAG не может действовать.
Почему сохраняется путаница
Это сравнение продолжает появляться, потому что обе технологии стали популярны примерно в одно и то же время, и обе описываются фразой «предоставляет вашему ИИ доступ к вашим данным». Эта фраза имеет слишком большое значение. Способность читать написанное — это другая проблема, чем способность действовать внутри ваших систем. Если правильно разграничить эти аспекты, архитектура в значительной степени формируется сама собой.