☕️ MCP (Model Context Protocol)?

MCP — это новый стандарт от компании Anthropic, который помогает искусственным интеллектам (например, модели Claude) работать с внешними системами: базами данных, файлами, API и другими инструментами.

Представьте его как "универсальный переводчик" , который упрощает общение ИИ с разными программами без написания сложного кода.

MCP — это не фреймворк или инструмент, а именно протокол, аналогичный: HTTP для интернета, SMTP для обмена сообщениями.

🖥 Пример использования
Представьте, что ваш ассистент (например, ИИ-бот) должен одновременно искать информацию в интернете и обрабатывать голосовые команды. MCP позволяет этим разным системам (поисковой модели и голосовому движку) работать вместе по единому протоколу, не запутавшись в деталях друг друга.

🧐 Как это работает?
MCP строится на клиент-серверной архитектуре и состоит из трёх частей:
— Host (хост): Это среда, где работает ИИ (например, приложение Claude). Он предоставляет доступ к инструментам (БД, API) через MCP. Пример : Вы спрашиваете ИИ: «Проанализируй продажи за квартал». Хост запускает MCP Client, чтобы связаться с базой данных.
— MCP Client (клиент): Часть ИИ, которая формирует запросы к внешним системам. Пример : Если ИИ нужно взять данные из PostgreSQL, MCP Client превращает запрос в структурированный код (например, SQL-запрос).
— MCP Server (сервер): «Переводчик», который связывает ИИ с внешним миром (Google Drive, API, БД). Пример : MCP Server для PostgreSQL получает SQL-запрос от клиента, выполняет его в базе и возвращает результат ИИ.

🧩 Ключевые элементы MCP
Они делятся между клиентом и сервером и реализуют «правила общения»:

Для клиента (MCP Client):
❶ Roots (Корни) — Безопасный доступ к файлам и данным.
Пример : ИИ может открыть файл в Google Drive через MCP Server, но не увидит другие файлы пользователя.
❷ Sampling (Выборка) — Запрос помощи у ИИ для задачи.
Пример : ИИ просит пользователя уточнить, какую именно таблицу из БД использовать.

Для сервера (MCP Server):
❸ Prompts (Инструкции) — Подсказки для ИИ, чтобы он понимал контекст.
Пример : «Ты работаешь с финансовыми данными, используй формат отчета X».
❹ Resources (Ресурсы) — Данные, к которым обращается ИИ.
Пример : Таблицы из PostgreSQL или файлы из Dropbox.
❺ Tools (Инструменты) — Функции, которые ИИ может вызывать.
Пример : Выполнить SQL-запрос, отправить письмо через API или обработать изображение.

🤌 Как это работает на практике?
Сценарий: Вы спрашиваете: «Покажи график продаж за 2023 год».
1. Host (ваш ИИ-ассистент) запускает MCP Client.
2. MCP Client формирует запрос к MCP Server для PostgreSQL: «Получи данные о продажах».
3. MCP Server подключается к БД, выполняет SQL-запрос и возвращает данные.
4. Resources (данные о продажах) и Tools (график) используются для создания ответа.
5. ИИ показывает вам график, используя Prompts (например, «График должен быть в формате PDF»).

🔗 Полезные материалы
— Учебная программа MCP для начинающих от MS
— Документация MCP
— Спецификация MCP
— GitHub репозиторий MCP
— Сообщество MCP

#ai #mcp #bytebytego

☕️ Активность ≠ результат

— «Наша новая функция набрала 70% вовлечённости!»
— «А решает ли она проблему?».

Измерять активность, а не результат — распространённая ошибка. Пользователи могут открывать экран, но не завершать действие.

Активность — это то, что делают люди:
— Количество кликов по кнопке.
— Открытие экрана.
— Время в приложении.

Результат — это то, что меняется у пользователя:
— Сократилось ли время на задачу?
— Исчезла ли боль?
— Улучшилась ли их жизнь?

Пример:
❌ Плохо: «80% пользователей нажали на кнопку “Поделиться”».
✅ Хорошо: «Количество успешных шеров в соцсети выросло на 30%».

❌ Плохо: «В приложении совершается 10 000 поисковых запросов».
✅ Хорошо: «Конверсия после поиска выросла на 15%: пользователи находят нужное и совершают целевое действие»

❌ Плохо: «90% прошли первый этап онбординга!»
✅ Хорошо: «Удержание новых пользователей через неделю выросло до 60%: они создают первый проект в течение дня».

🤌Как перестать гнаться за активностью
❶ Задайте вопрос: «Какая проблема решается?»
Перед запуском функции определите: «Пользователь получит X, потому что Y» . Например: «Пользователь быстрее найдёт нужный документ, потому что поиск будет учитывать синонимы» .

❷ Выберите метрику-результат
Не «сколько открыли поиск», а:
— «На сколько сократилось время поиска?»
— «Сколько запросов завершились успешным действием?»

❸ Сравните «до» и «после» в контексте цели
Если метрика не связана с пользой — игнорируйте её. Даже если цифры впечатляют.

💡 Итого
Если метрика не отвечает на вопрос «Зачем это нужно?» — она бесполезна.

Активность — это шум. Результат — сигнал. Перед каждым релизом полезно задавать вопрос: «Как мы поймём, что это сработало?».

#thoughts #pm #metrics

☕️ "После не значит вследствие": как не обмануться в работе

Знакомая ситуация? Вы запустили новую фичу — и тут же пользователи начали жаловаться. Значит, фича плохая, верно?

Не обязательно))

Сегодня хочу поговорить об одной коварной логической ошибке, которая постоянно подводит даже опытных профессионалов:

корреляция ≠ причинно-следственная связь

Или проще: "после не значит вследствие".


❌ Плохой пример мышления:
"Мы внедрили новый инструмент → через неделю упали метрики → значит, инструмент виноват"

✅ Правильный подход:
"Мы внедрили новый инструмент → через неделю упали метрики. Что ещё изменилось? Какие ещё факторы могли повлиять?"

В работе мы часто сталкиваемся с этой ошибкой:
— Пример 1: После обновления UI количество отказов выросло. Команда сразу делает вывод, что новый дизайн плохой. Но возможно, в тот же день началась сезонная распродажа у конкурента.
— Пример 2: После перехода на новый фреймворк увеличилась скорость загрузки. Все рады, но на самом деле улучшение дал CDN, который подключили параллельно.
— Пример 3: После релиза новой функции выросла конверсия. Продакт рад, но на самом деле это сезонный всплеск спроса.

Как не попадаться в эту ловушку?
— Ищите альтернативные объяснения - когда видите связь между двумя событиями, задайте себе: "Что ещё могло повлиять?"
— Собирайте больше данных - одна метрика не даёт полной картины. Сравнивайте с контрольной группой, анализируйте временные ряды.
— Проводите A/B-тесты - если хотите точно знать причину, единственный надёжный способ — контролируемый эксперимент.
— Задавайте "глупые" вопросы - "А точно ли это связано?", "Может, мы что-то упускаем?", "Как это проверить?"

Помните: в нашем мире всё взаимосвязано. Просто потому что событие B произошло после события A, не значит, что A вызвало B. Иногда это просто совпадение, иногда третий фактор влияет на оба.

Следующий раз, когда в команде начнут искать "виновника" упавших метрик, предложите остановиться и посмотреть шире. Возможно, проблема совсем в другом месте.

#thoughts #analytics #logic