Детальний огляд MCP, частина 1: Що таке MCP?
Якщо ви стежите за розвитком ШІ, то напевно чули про протокол контексту моделі (MCP). З моменту оголошення Anthropic про цей новий стандарт у листопаді 2024 року його популярність різко зросла. Існують MCP для надсилання електронної пошти, MCP для пошуку в Інтернеті, MCP, які запускають інші MCP. MCP дозволяють скромним LLM робити запити на витягнення та бронювання квитків на літак. У травні компанія Microsoft навіть оголосила про створення реєстру MCP для Windows, який дозволяє програмам надавати функціональність агентам ШІ.
Неймовірно! Але як? Що таке MCP? Як ним користуватися? Чому він став настільки популярнішим за попередні спроби? Як це дозволяє чат-ботам виконувати завдання в реальному світі? А як ви можете створити свій власний?
Коли ми вирішили створити власний сервер MCP для DeepL API, це здавалося страшним. Але коли ви дійсно зрозумієте, як працюють MCP, як MCP дозволяють агентам знаходити та використовувати інструменти, і як можна створити базовий сервер MCP за допомогою 10 рядків коду, це вже не буде таким страшним. У цій серії публікацій ми спробуємо розвіяти міфи навколо цієї теми. Ми розглянемо:
- що таке MCP
- як використовувати MCP в клієнті ШІ
- як побудувати сервер MCP
Ходімо!
Що означає MCP?
MCP означає «протоколконтекстумоделі».
«Модель»— це модель ШІ. Це може бути будь-яка поверхня ШІ, але зазвичай вона побудована на LLM. Тут ми будемо називати це ШІ-агентом або ШІ-асистентом.
«Контекст»означає обставини, в яких працює агент ШІ. В ШІ ми часто говоримо про «контекстне вікно», яке означає весь контекст, який LLM враховує під час генерування відповіді на запит — історію розмови, системний запит тощо. Щоб MCP працював, поверхня ШІ надає базовому LLM додатковий підказку, що вказує, які інструменти він може використовувати і як їх використовувати.
«Протокол»— це набір правил, що встановлюють спосіб взаємодії двох об'єктів у мережі. Одним із протоколів, який ви використовуєте щодня, є HTTP (HyperText Transfer Protocol) — протокол передачі гіпертексту, який регулює спосіб взаємодії вебсервера та вебклієнта.
Підсумовуючи: «Протокол контексту моделі» — це протокол, який забезпечує контекст, що дозволяє моделям ШІ використовувати зовнішні інструменти та ресурси.
MCP — це відкритий стандарт, винайдений двома інженерами компанії Anthropic. Він використовує JSON-RPC, популярний протокол для визначення викликів функцій. І це натхненно протоколом мови Language Server Protocol, який Microsoft створив для відокремлення логіки обробки мов кодування від IDE.
MCP — це не програмне забезпечення, програма чи API. Але це дає агентам ШІ доступ до всіх цих даних!
Чим займається MCP?
LLM можуть давати розумні та корисні відповіді на запити користувачів. Але вони не мають доступу до зовнішніх служб, не можуть взаємодіяти з іншим програмним забезпеченням і не мають можливості отримувати актуальну інформацію. MCP надає будь-якій поверхні ШІ можливість надсилати запити до будь-якої програмної служби та отримувати відповідь. Це надає агенту ШІ стандартний засіб доступу до зовнішніх інструментів, ресурсів та даних.
Без MCP клієнт ШІ — це просто мозок без тіла, який не має доступу до зовнішнього світу. Завдяки MCP клієнт ШІ може бути агентом!
Хто може використовувати MCP?
Оскільки MCP є відкритим стандартом, будь-хто може реалізувати клієнт MCP або сервер MCP.
Клієнтом може бути будь-яка програма, заснована на LLM. Ви можете використовувати MCP в таких програмах, як Claude Desktop, VSCode, Windsurf та Cursor. Або ви можете використовувати MCP з ШІ-агентом, який ви створили за допомогою фреймворку, такого як LangChain або CrewAI.
Чому MCP став таким популярним?
Однією з причин є те, що це відкритий стандарт. Будь-який агент ШІ може реалізувати MCP, так само як і будь-який інструмент. Це робить його більш привабливим, ніж рішення для продукту конкретної компанії, такі як OpenAI's Виклик функції.
При створенні цього універсального рішення розробники MCP надихалися протоколом Language Server Protocol (LSP). До появи LSP, коли IDE хотіла реалізувати такі функції, як автозавершення або підсвічування синтаксису для певної мови програмування, їй потрібно було створювати власну інтеграцію. Результатом стало те, що творці нещодавно назвали m × n проблемою, в якій людям потрібно було реалізувати мовні сервіси окремо для кожної можливої комбінації IDE/мови. З LSP кожна мова кодування потребує лише однієї бібліотеки інтеграції. А IDE, що підтримує LSP, може підтримувати будь-яку таку мову. Аналогічно, після того як сервіс впровадить сервер MCP, будь-який клієнт ШІ, що підтримує MCP, зможе ним користуватися. Клієнту потрібно лише підтримувати MCP.
MCP є гнучким і в інших аспектах. Він може працювати локально або через мережу. І це від компанії Anthropic, яка користується великою повагою і яка поділиться перевагами відкритого стандарту.
Чому агенти ШІ потребують стандартного протоколу?
Оскільки LLM так добре розуміють і застосовують інформацію, чи не можуть вони вже використовувати будь-яке програмне забезпечення, опис якого міститься в їхніх навчальних даних? Зрештою, LLM вже розуміють, як використовувати багато популярних API, про що ви дізнаєтеся, якщо звернетеся за допомогою до помічника з кодування, такого як Copilot або Sourcegraph.
Але якщо надати LLM доступ до всіх API в його навчальних даних, це призведе до хаосу. Як він буде знати, які API викликати і коли? Як він отримає ваш ключ API та облікові дані, і як він буде використовувати сервіси, що потребують інших видів доступу? А що, якщо ви хочете дізнатися відстань від Канзас-Сіті до Де-Мойна або поточну температуру в Бангкоку? Існує багато способів знайти цю інформацію. Як користувач, ви хочете контролювати дії, які обирає ваша LLM. Це особливо актуально, коли мова йде не про отримання інформації, а про дії, що впливають на світ, наприклад, надсилання електронної пошти або замовлення піци.
Звісно, агент може прочитати і зрозуміти низькорівневу специфікацію OpenAPI або всю документацію API, а потім відповідно виконати виклики API. Але MCP дозволяє розробникам інструментів визначати вищі Послуги, які будуть особливо корисні для агента ШІ, направляючи його в потрібному напрямку. Поки що це сфера, в якій люди все ще перевершують машини.
Таким чином, виявляється, що найкращим способом на даний момент є чітке визначення інструментів і ресурсів, які LLM може використовувати, а також способів їх використання. MCP робить це по-старому, детерміновано — не за допомогою LLM, а за допомогою коду та JSON.
Але як LLM може використовувати інструменти?
По суті, LLM — це машина, яка генерує токени — токени, які люди сприймають як текст, зображення, аудіо тощо. Тож як така машина може мати доступ до інструментів та ресурсів? Як він знає, що має такий доступ, і як він знає, який з них використовувати?
Ключовим моментом є те, що, дійсно, як зазначає Максиміліан Шварцмюллер, LLM можуть спілкуватися із зовнішнім світом лише за допомогою токенів. Вони приймають токени як вхідні дані і генерують токени як вихідні дані. І ці маркери можуть включати сутності, які означають «Я хочу використовувати інструмент». Отже, щоб вказати, що він хоче використовувати інструмент або ресурс, і фактично його використовувати, LLM генерує стандартні токени, які оточуюче програмне забезпечення розпізнає як виклик інструменту і перехопить. Потім це програмне забезпечення викликає сервіс і повертає результат до LLM.
LLM міг би використовувати тут спеціалізовані токени. Але зазвичай він просто використовує певні роздільники та мову — таким чином ви можете модернізувати цю функцію в існуючій LLM, точно налаштувавши її. Наприклад, ви можете використовувати початкові та кінцеві теги в квадратних дужках, які охоплюють JSON, як у цьому зразку виводу агента:
Звичайно! Я можу створити для вас нову електронну таблицю. Зачекай...
[tool-start]
{
"tool": "spreadsheets",
"action": "create"
}
[tool-end]
Саме це і зробили дослідники у своїй статті «Toolformer» 2023 року, яка, як випливає з назви, показала, що «мовні моделі можуть навчитися самостійно користуватися інструментами». У цьому дослідженні автори генерували навчальні дані, які включали представлення тексту викликів API та їхніх результатів. Вдосконаливши LLM за допомогою цих додаткових даних, вони створили LLM, який викликав би ці API для генерування багатообіцяючої відповіді на запит.
Вони використовували простий формат:
[назва_функції(дані) → результат]
Наприклад, знаючи, що LLM мають труднощі з математикою, вони надали інструмент «Калькулятор». Потім вони включили в навчальні дані такі рядки:
З 1400 учасників 400 (або [Калькулятор (400 / 1400) → 0,29] 29%) склали іспит.
та
Назва походить від іспанської мови «la tortuga», що означає [MT(«tortuga») → черепаха] черепаха.
Шляхом точного налаштування LLM за допомогою таких даних вони створили LLM, який знав, як викликати API для генерування найбільш перспективної відповіді на заданий запит.
Але вам не потрібно налаштовувати LLM, щоб він міг використовувати інструменти. Виявляється, все, що потрібно, це підказка. Ця стаття демонструє, як навчити LLM використовувати інструменти з JSON, розділені [[qwen-tool-start]] і [[qwen-tool-end]], виключно за допомогою відповідної підказки.
Ви можете спробувати це самостійно! Просто відвідайте свій обраний чат-бот і скажіть йому:
Вітаємо! Тепер ви можете використовувати інструмент для виконання множення. Коли вам потрібно виконати обчислення, все, що вам потрібно зробити, це ввести наступний синтаксис:
[Математика]
{
"arg1": {value},
"arg2": {value}
}
[/Math]
де, звичайно, кожне {значення} представляє значення, яке ви хочете помножити. Зрозуміло?
Потім дайте LLM математичну задачу і спостерігайте, як він вірно виводить синтаксис, який ви задали для вашого математичного інструменту.
Сучасні LLM все ще використовують інструменти майже так само. Наприклад, Anthropic описує тут , як вони створюють системний підказку для Claude, щоб використовувати інструменти в їх API.
Як LLM обробляє вихідні дані з інструменту?
Як LLM отримує результати роботи інструменту? Знову ж таки, все зводиться до токенів. Як тільки клієнт ШІ отримує вихідні дані від інструменту, він передає їх назад в LLM як вхідні дані, але таким чином, що LLM розуміє, що це вихідні дані інструменту, а не вхідні дані кінцевого користувача.
Збираємо все до купи
Резюмуючи, ось що відбувається, коли LLM використовує інструмент:
- Типи користувачів у введенні даних
- LLM обробляє ці вхідні дані
- Під час генерування вихідних даних LLM «вирішує», що виклик інструменту є найкращим способом завершити роботу. Це означає, що він видає набір токенів, які він навчився знати, що дозволять йому викликати інструмент.
- Клієнт ШІ розпізнає ці токени як щось, що повинно викликати інструмент, перехоплює його, розбирає JSON на параметри та все інше в запиті і відправляє це до відповідного інструменту.
- Інструмент генерує вихідні дані, що може передбачати використання API або не передбачати його. Він повертає це клієнту ШІ, який надсилає його до LLM.
- LLM обробляє вихідні дані інструменту
- LLM використовує цей результат, щоб продовжити створювати відповідь для користувача.
І це моя коротка екскурсія по тому, що таке MCP і як воно реалізується в LLM. У наступному дописі я покажу вам, як використовувати MCP у вашому власному ШІ-клієнті!
Про автора
Як розробник DeepL, Бен Морс допомагає всім бажаючим використовувати DeepL API для доступу до перекладів світового рівня, виконаних за допомогою ШІ. Раніше в Google він був менеджером продукту Chrome і розробником, який виступав за покращення веб-сайтів. До цього він працював інженером-програмістом у New York Times та AOL, а також був музикантом на повний робочий день. Він отримав ступінь бакалавра з інформатики в Гарварді та ступінь доктора філософії з музики в Каліфорнійському університеті в Девісі. Ви все ще можете побачити, як він грає музику з групою Ancient Babies, аналізуючи поп-пісні на Rock Theoryта пише мюзикл, який насправді не про Стіва Джобса.