Model Context protocol (MCP)

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Сьогодні ми багато чуємо про протокол контексту моделі (MCP). Ця стаття розгляне його призначення, функціональність та переваги, які він пропонує для створення генеративних AI-застосунків.

Проблема інтеграції зовнішніх ресурсів з великими мовними моделями

Сьогодні створення застосунків, що працюють на великих мовних моделях (LLM), є відносно простим. У вас є ваш застосунок, і ви безпосередньо взаємодієте з інстансом LLM.

[Ваш Застосунок] <---> [Велика Мовна Модель]

Однак LLM мають обмеження:

  • Обмежені знання: Їх навчають на певному наборі даних до певної дати, і вони не розуміють пропрієтарних або нових даних.
  • Нездатність взаємодіяти із зовнішніми інструментами: Вони не можуть за своєю природою викликати інші сервіси або виконувати дії поза межами свого навчання.

Щоб подолати ці обмеження, ми часто хочемо, щоб наші застосунки надавали LLM додаткові можливості, підключаючи їх до зовнішніх ресурсів:

[Ваш Застосунок]
|
±-- [Зовнішній Сервіс з API]
|
±-- [Додаткові Знання/Дані]
|
±-- [Локальні Ресурси Машини (наприклад, Файли)]
|
[Велика Мовна Модель]

Традиційно при створені інтеграції виникають труднощі:

  1. Складність iнтеграції API: Застосунок повинен розуміти та імплементувати специфічні API кожного сервісу, до якого він хоче підключитися. Кожен сервіс може мати різний API, що вимагає значних зусиль розробки.
  2. Опис можливостей для LLM: Розробник застосунку повинен з’ясувати, як описати можливості цих зовнішніх сервісів та даних у промптах, щоб LLM знала про їхню доступність і могла запитувати їх використання.

Це передбачає створення складних промптів, щоб повідомити LLM про доступні інструменти та знання, а потім обробку запитів LLM на виконання цих інструментів та отримання інформації. Весь цей процес значно ускладнює створення AI-застосунків.

Рішення: протокол контексту моделі (MCP)

Протокол контексту моделі (MCP) має на меті вирішити цю проблему, визначаючи стандартний спосіб для AI-застосунків взаємодіяти з різними зовнішніми сервісами, надаючи LLM додатковий контекст уніфікованим чином.

Уявіть собі перехід від численних пропрієтарних портів на задній панелі ранніх комп’ютерів до універсального стандарту USB-C. USB-C визначає як фізичне підключення, так і протокол зв’язку, спрощуючи взаємодію пристроїв. MCP прагне зробити те саме для AI-застосунків та зовнішніх ресурсів.

Архітектура MCP: модель клієнт-сервер

MCP використовує архітектуру клієнт-сервер:

[AI Застосунок] --- (Протокол MCP) ---> [Сервер MCP] <---> [Базовий Сервіс/Ресурс]

Для кожного зовнішнього сервісу або ресурсу, з яким AI-застосунок хоче взаємодіяти, він створює локальний об’єкт клієнта MCP. Відповідно, існує сервер MCP, який діє як посередник між клієнтом MCP та конкретним базовим сервісом або ресурсом.

[AI Застосунок]
|
±-- [Клієнт MCP 1] --- (MCP) ---> [Сервер MCP A] <---> [Сервіс A (наприклад, API)]
|
±-- [Клієнт MCP 2] --- (MCP) ---> [Сервер MCP B] <---> [Сервіс B (наприклад, База Даних)]
|
±-- [Клієнт MCP 3] --- (MCP) ---> [Сервер MCP C] <---> [Локальний Файл]

Ключові аспекти цієї архітектури:

  • Однозначне відображення: Існує однозначний зв’язок між інстансом клієнта MCP та конкретним інстансом сервера MCP.
  • Абстракція протоколу: Клієнту MCP потрібно лише розуміти протокол MCP. Йому не потрібно знати специфіку API базового сервісу.
  • Серверно-специфічна логіка: Сервер MCP відповідає за розуміння власного протоколу базового сервісу (наприклад, конкретного API, мови запитів до бази даних, операцій з файловою системою) та перетворення запитів MCP на ці власні виклики.
  • Спрощена інтеграція: Постачальникам сервісів потрібно лише розробити один сервер MCP для свого сервісу, що дозволяє будь-якому AI-застосунку, який підтримує MCP, взаємодіяти з ним.

Сервери MCP: локальні та віддалені

Хоча ідеальним сценарієм може бути розміщення серверів MCP віддалено разом із сервісами, які вони представляють, поточна реальність полягає в тому, що більшість серверів MCP працюють локально в середовищі AI-застосунку.

[AI Застосунок] <---> [Локальний Сервер MCP] <---> [Віддалений Сервіс]

Це насамперед пов’язано з поточною роботою над стандартизацією протоколів безпеки та автентифікації для віддаленого зв’язку з сервером MCP. Наразі постачальники сервісів зазвичай пропонують свій сервер MCP як ізольований контейнер, який розробники запускають локально. Потім локальний сервер MCP обробляє зв’язок з віддаленим сервісом, використовуючи його існуючі механізми (наприклад, HTTP).

Рефлексія: виявлення можливостей

Однією зі значних переваг MCP є його можливість рефлексії. Коли клієнт MCP встановлює сесію з сервером MCP, клієнт може запитати сервер про його можливості. Сервер MCP може надавати інформацію про:

  • Ресурси: Структуровані дані або документи, які LLM може запитувати для отримання інформації (наприклад, для Retrieval Augmented Generation).
  • Інструменти: Функції, які можна викликати для виконання дій (наприклад, запит до API, доступ до локального файлу). Опис кожного інструменту включає його назву, опис та JSON-схему, що визначає необхідні вхідні параметри.
  • Промпти: Попередньо визначені інструкції або шаблони, які можуть допомогти застосунку краще формулювати промпти для LLM під час взаємодії з базовим сервісом.

Клієнт MCP може запитувати всі можливості одночасно або надсилати окремі запити на списки інструментів, ресурсів та промптів. Сервер відповідає корисним данними, що описує кожну доступну можливість, включаючи її назву, опис та схему вхідних даних.

# Приклад взаємодії клієнта MCP з сервером
client_session = mcp.create_client_session(connection_details)
available_tools = client_session.list_tools()
print(available_tools)
# Вивід може бути:
# [
# {
# «name»: «get_current_time»,
# «description»: «Отримує поточний час для заданого часового поясу.»,
# «parameters»: {«timezone»: {«type»: «string», «description»: «Часовий пояс для отримання часу.»}}
# },
# ...
# ]

Як MCP забезпечує взаємодію з LLM

  1. Реєстрація серверів MCP: AI-застосунок реєструє потрібні сервери MCP.
  2. Виявлення можливостей: Під час ініціалізації клієнта застосунок запитує кожен сервер MCP про його доступні інструменти, ресурси та промпти.
  3. Агрегування можливостей: Застосунок складає список усіх доступних можливостей з усіх підключених серверів MCP.
  4. Доповнення промптів LLM: Під час взаємодії з LLM застосунок включає цей список доступних інструментів та ресурсів у промпт.
  5. LLM генерує план: Якщо LLM визначає, що йому потрібен доступ до зовнішньої інформації або виконання дії, він генерує план, в якому вказує, який інструмент або ресурс використовувати та необхідні параметри.
  6. Застосунок виконує план: Застосунок отримує план і використовує відповідний клієнт MCP, щоб запросити вказану дію у відповідного сервера MCP.
  7. Повернення інформації до LLM: Сервер MCP виконує запит і повертає результат застосунку.
  8. Контекстуальна взаємодія з LLM: Потім застосунок включає результат від сервера MCP у наступний промпт до LLM, дозволяючи йому продовжити розмову або завершити завдання.

Сама LLM нічого не знає про базовий MCP. Вона просто бачить опис доступних інструментів та ресурсів у промпті та інструктує застосунок використовувати їх, коли це необхідно. Фреймворк MCP обробляє весь зв’язок та перетворення за лаштунками.

Переваги використання MCP

  • Спрощена інтеграція: Розробникам не потрібно вивчати тонкощі API кожного сервісу. Вони взаємодіють лише зі стандартизованим протоколом MCP.
  • Зменшення зусиль розробки: Інтеграція нових сервісів стає значно простішою, оскільки розробникам потрібно лише підключитися до відповідного сервера MCP.
  • Динамічне виявлення можливостей: Застосунок може динамічно виявляти можливості підключених сервісів під час виконання.
  • Покращена функціональність LLM: LLM може безперешкодно використовувати зовнішні знання та інструменти, не вимагаючи явного, складного інжинірингу промптів для кожного сервісу.
  • Стандартизований підхід: MCP сприяє послідовному та сумісному способу взаємодії AI-застосунків із зовнішніми ресурсами.
  • Легше впровадження сервісів: Постачальники сервісів можуть зробити свої сервіси доступними для ширшого кола AI-застосунків, просто реалізувавши сервер MCP.

Впровадження та майбутні напрямки

Основні гравці, такі як Microsoft, активно інвестують в MCP. Його інтегрують у такі платформи, як Semantic Kernel, Copilot Studio та GitHub Copilot.

Azure API Management також розглядається як потенційний AI-шлюз та спосіб захисту віддалених серверів MCP шляхом накладання існуючих механізмів автентифікації. Azure API Center може служити репозиторієм для компонентів MCP.

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

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

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Це цікава тема.
Пропоную продовжувати обговорення в цьому топіку. dou.ua/forums/topic/53402
Там вже є коментарі

Підписатись на коментарі