Наступна битва в SaaS розгортається над MCP

Протокол контексту моделі (Model Context Protocol) дає ШІ спільний спосіб взаємодіяти з корпоративним програмним забезпеченням. Врушалі Паунікар, директорка з продуктів Carta, вважає, що складніше завдання — вирішити, що відбуватиметься після встановлення зв’язку і яку частину роботи варто доручити мовній моделі.

За останній рік протокол контексту моделі пройшов шлях від відносно маловідомого технічного стандарту до однієї з найважливіших ідей у сфері корпоративного ШІ.

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

Уявіть, що MCP — це електрична розетка у стіні. Це спільний стандарт, до якого можна під’єднати будь-який пристрій, щоб отримати електроенергію. Це зручно, адже стандарт відкритий і працює всюди, але сама розетка нічого для вас не робить. Вам усе одно потрібен електроприлад.

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

Зараз значна частина індустрії SaaS сприймає підключення ШІ так, ніби це вже готовий продукт. Створіть MCP-сервер, відкрийте доступ до потрібних інструментів і даних — і дозвольте моделі діяти далі самостійно.

Для деяких сценаріїв цього достатньо. Але для багатьох корпоративних робочих процесів, особливо фінансових, — ні.

MCP перемагає на рівні підключення

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

Однак сумісність розв’язує проблему доступу, але не пояснює моделі, як саме виконувати роботу.

Значну частину часу я приділяю роздумам про програмне забезпечення для інвесторів на приватних ринках і фінансових команд, де ця відмінність особливо помітна.

Наприклад, надавши системі ШІ доступ до даних про результати діяльності приватного фонду та його портфель, можна отримати кілька способів відповісти на, здавалося б, просте запитання.

Один підхід передбачає використання відповідного розрахунку. Інший може бути спрощеним. А третій — ґрунтуватися на хибному розумінні запиту користувача.

У результаті користувачеві доводиться бути водночас аналітиком, фахівцем із промптингу та контролером якості. Це не той безперешкодний досвід, який обіцяли.

Продукт і далі має визначати підхід

Саме тут стає цікавою наступна ланка технологічного стека. Якщо MCP — це рівень підключення, то над ним розташовуються плагіни та навички: вони пояснюють агенту, як використовувати це підключення для виконання конкретного завдання.

Замість того щоб просто надавати моделі доступ до даних і функцій, вони можуть об’єднувати інструкції, робочі процеси, детерміновані обчислення та інтерфейси.

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

Експертні знання закладено в продукт, а не повністю покладено на модель.

Є докази, що таке поєднання працює. Нещодавно Google протестувала агента для написання коду на основі ШІ, який через MCP мав доступ до технічної документації компанії; потім агенту надали додаткові інструкції для конкретного завдання, пояснивши, як найкраще використовувати цю інформацію. Поєднання такого підключення з інструкціями забезпечило 96.3% успішних проходжень під час оцінювання Google і водночас дало змогу використовувати на 63% менше токенів на кожну правильну відповідь, ніж за стандартного промптингу.

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

Не кожне завдання варто доручати моделі

Великі мовні моделі — це ймовірнісні системи. Гнучкість, завдяки якій вони корисні для написання текстів, дослідження та міркування, менш доречна в робочих процесах, де важливі точність і відтворюваність результатів. Фінанси — показовий приклад: якщо людина очікує, що той самий розрахунок щоразу даватиме однакову відповідь, розбіжності швидко стають проблемою.

Фінансове програмне забезпечення десятиліттями розвивалося в протилежному напрямку. Журнали аудиту, дозволи, стандартизовані розрахунки та відтворювані процеси існують тому, що послідовність має цінність.

ШІ не варто забувати ці уроки. Найкращі корпоративні продукти на основі ШІ знатимуть, коли дозволити моделі міркувати, а коли обмежити її. Ймовірнісні системи доречні, коли корисні судження та інтерпретація. Детерміновані інструменти краще підходять там, де потрібні точність і відтворюваність.

Той самий принцип діє всюди, де ціна помилки у відповіді висока.

Де далі формуватиметься диференціація SaaS

Рівень, що формується над MCP, досі значно менш усталений, ніж сам MCP.

З’явилися різні підходи до плагінів і навичок, але вже триває робота над тим, щоб їх можна було переносити між платформами ШІ, а не прив’язувати до однієї екосистеми.

SaaS-компаніям усе одно доведеться ухвалювати рішення, перш ніж усі стандарти усталяться. Так було завжди.

Альтернатива — відкрити інтерфейс і залишити клієнтам самостійно створювати потрібний їм досвід користування.

ШІ може піти тим самим шляхом. Щомісяця під’єднати агента до корпоративного програмного забезпечення стає дедалі простіше. Перевага дедалі більше полягатиме в тому, що відбувається далі: у робочих процесах, засобах контролю та знаннях предметної галузі, які підказують агенту, як перетворити доступ на надійний результат.