RAG проти MCP: Що насправді потрібно вашому додатку з ШІ

Люди часто запитують, чи їм потрібен 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, який є відкритим кодом та може бути розміщений власноруч, вирішує цю проблему.

Зауважте, що кілька з цих постачальників тепер постачають сервер MCP для продуктів, які насправді спрямовані на пошук інформації. На практиці ці дві концепції поєднуються, а не конкурують.

Часто ставлені запитання

Чи є RAG тим самим, що й MCP? Ні. RAG вставляє отриманий текст у запит, щоб модель могла його прочитати, тоді як MCP дозволяє моделі викликати інструменти та виконувати дії. Один з цих підходів робить модель краще обізнаною, а інший — здатною до дії. Вони працюють на різних рівнях та часто поєднуються в одному додатку.

Чи замінює MCP RAG? Ні, і таке сприйняття призводить до серйозних помилок у проектуванні. MCP лише стандартизує спосіб виклику інструментів. Якщо потрібен семантичний пошук для 50 000 документів, все одно знадобляться ембеддинги, векторна база даних та процес отримання інформації. MCP лише змінює шлях доступу, тож цей процес стає інструментом через стандартний інтерфейс замість індивідуальної інтеграції.

Коли RAG є кращим вибором? Коли відповідь знаходиться у великому, відносно стабільному об’ємі тексту, такому як документація, контракти, політики, наукові статті чи статті підтримки. Це коштує менше за запит та дає відповідь швидше, ніж двосторонній зв’язок через API. Переходьте на MCP, як тільки відповідь залежить від поточного стану чи коли користувач хоче, щоб щось було зроблено, а не пояснено.

Чи відрізняється сервер MCP від API? Зазвичай це шар поверх 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 не може діяти.

Чому триває плутанина

Це порівняння продовжує поширюватися, тому що обидві технології стали популярними приблизно в один і той самий час, і обидві описуються фразою „надає вашому ШІ доступ до ваших даних“. Ця фраза має занадто велике значення. Здатність читати написане — це інша проблема, ніж здатність діяти всередині ваших систем. Якщо правильно розділити ці аспекти, архітектура в значній мірі сформується сама собою.