MCP‑сервер (Message Control Plane) для обработки и маршрутизации телеметрии в реальном времени, мы решили попробовать нечто более декларативное и «из коробки» готовое к бою.
Чтож, возможно в Spring AI его решили переназвать, давайте проверим, поскольку я без понятия как работает Spring AI и не знаю Java, все же убедимся в информации.
Узнаем что такое MCP в контексте Spring AI Сделаем следующие шаги:
2) Посмотрим как выглядит yaml файл и действительно ли вы пишите MCP-сервер и имеете ввиду именно MCP от Anthropic, а не какое-то кастомное название внутри фреймворка/разработчиков/компании
Вывод по Spring AI: название MCP точно не относится к вашему внутреннему сленгу, а относится к open-source протоколу от Anthropic : https://modelcontextprotocol.io/introduction
Докажем что статья или её часть была написана ИИ и не проверена автором Сказанное выше не доказывает, что вы использовали ИИ, так ведь? Чтож давайте сделаем запрос в относительно старую модель, которая вряд-ли имеет контекст (была дообучена, или посмотрела в интернете/раге/любым другими способом) про MCP
Ответ gpt-4o
Как я уже сказал модель не знает что такое MCP и такая проблема была даже у Claude Sonnet 3.7 и все еще сохраняется, потому что данные про MCP не попали в корпус на претрене или другом виде тюнинга, ну и авторы не засунули инфу о нем в системный промпт, тем не менее Claude имел возможность им пользоваться, поскольку это просто стандартные тулы в новой обертке, грубо говоря.
Ответ про MCP от Claude 3.7
Отсюда следует вывод, что автор использовал какую-то из моделей, которая все еще не знает о том, что такое MCP на самом деле, но возможно умеет пользоваться интернетом.
В доказательство того, что модели знают что такое MCP, возьмем Claude Sonnet 4.0
Ответ про MCP от Claude Sonnet 4.0
Вот этот ответ действительно правильный и верный, возможно одна из причин выпуска семейства моделей Claude 4.0 в том, чтоб они могли объяснить что такое MCP ))
Вывод сгенеренному тексту: автор использовал ИИ как минимум для генерации введения, а также перенес в статью незнание LLM о том что такое MCP.
С одной стороны мы все можем ошибаться, однако информация автора о том, что такое MCP явно сгенерена нейронкой и не проверена.
К тому же:
Идеальные комменты в yaml файле
Лично я такие комменты стал бы писать в формате:
# Таймаут AI-запроса в секундах
request-timeout: 180
Поскольку это быстрее и удобнее и не заставляет делать множество табуляций, отступов, что может привести к сдвигу текста и нерабочему файлу из за этого же сдвига.
Либо автор люто пишет пробелы, табуляции и хорошо редачит текст в yaml файлах, либо эту часть также сгенерила нейронка.
Вывод общий Возможно не вся статья сгенерена не самой свежей версией GPT, однако это должно заставить как автора, так и нас задуматься о том, что не нейронка виновата, что выдала нам неверную информацию, а мы виноваты, что не учли особенность технологии, не проверили информацию и продолжаем распространять ложные термины.
И мой фидбэк не в том, что нейронки плохо - нет (это супер круто), он в том, что инфа неверная и вот это уже не круто.
P.S. Извините за духоту. Я сам пользуюсь нейронками, чтобы писать код, редачить текст, переводить слова других людей с русского на русский, нейронки классно умеют править структуру текста для статьи, делать прикольные и кликбейтные заголовки, но тем не менее:
Важно помнить, что ответственность за дезинформацию несем мы сами - как пользователи, особенно "технически продвинутые", как разработчики, особенно если эту дезинформацию распростроняем сами же мы.
Мне кажется это out-of-scope вопрос, который больше подходит для отдельной небольшой статьи. Во первых по вопросу об LLama я предлагаю изучить системную карточку/статью данной модели, а именно конкретной с xxB параметрами модели. Для LLama 3.1 например представлен специальный токен: <|python_tag|> он как раз используется для того чтобы обозначить модели представленный тул. Также в карточке LLama представлено множество примеров того, как на уровне специальных токенов размечается текст, чтобы модель поняла то, что от неё хотят. Также там обозночается, что 8B модель по идее может работать с тулами, но качество может быть сомнительным.
Актуальные модели умеют с этим работать и могут быть дообучены под эти задачи. статьи про это: Toolformer: Language Models Can Teach Themselves to Use Tools: https://arxiv.org/pdf/2302.04761 TOOLFLOW: Boosting LLM Tool-Calling Through Natural and Coherent Dialogue Synthesis: https://arxiv.org/pdf/2410.18447
В контексте агентов с тулами логику можно описать следующим образом: Агент может "вызвать" функцию, вернув json, который эту функцию описывает. В моем примере это выглядит так:
Потому тула начинает выполнять запросы в интернет, например:
{7 items
"content": [10 items
0: {3 items
"title": "Погода В Москве - Gismeteo"
,
"href": "https://www.gismeteo.ru/weather-moscow-4368/"
,
"body": "Погода в Москве на сегодня, подробный прогноз погоды на сегодня для населенного пункта Москва, Москв..."
,
}
1: {3 items
"title": "Прогноз погоды в Москве на 10 дней — Яндекс.Погода"
,
"href": "https://yandex.ru/pogoda/moscow"
,
"body": "Подробный прогноз погоды для Москвы на сегодня, завтра, неделю, 10 дней, месяц на Яндекс.Погоде. Про..."
,
}
В итоге на основе контекста из тулы формируется финальный ответ
Функция выполняется у вас локально, результат её вызова переходит в контекст Input запроса модели. То есть в ваш системный промпт и промпт пользователя подмешивается еще респанс с тулы, из за чего значительно растет расход токенов на input. Модель соответственно анализируя все это выдает финальный ответ, качество которого зависит от системного промпта, запроса пользователя и качества работы самой тулы. В реальности, а не как на игрушечном примере в этой статье, вы скорее всего захотите более явно и подробно описать и через системный промпт те тулы, которые вы хотите использовать, а также само описание тулов также сделаете подробным. Также когда у вас есть конкретно определенный формат вывода, например через модель Pydantic, модель будет подстраивать агрументы в тулу так, чтобы выполнить все что вы указали, при этом формируя аргументы функции не за один раз, а за несколько запросов, пока все поля не будут заполнены (в идеале) Подробнее можно почитать в документации от Open AI: https://platform.openai.com/docs/guides/function-calling?api-mode=responses&example=get-weather#overview.
Ну так далее я указал на короткий пост от nvidia по решению этой проблемы. После запуска одного единственного сервиса (при условии что проприетарное ПО), TGP работает аналогично Винде.
Если бы на Linux было действительно все плохо с дровами для Nvidia, то нейронки на виртуалках с виндой бы обучали.
можно с докером сделать ту же историю, просто прописать условный композ и скрипт чтоб моделька скачалась.
Пользуемся
Вот например на stack overflow эта тема с ollama поднималась: https://stackoverflow.com/questions/78388016/run-ollama-with-docker-compose-and-using-gpu.
Из плюсов не нужно тянуть за собой лишние python зависимости, а кому надо просто через sdk будут обращаться. У ollama есть и свой, есть в langchain, наверное есть и в других фреймворках.
Лет 5 назад эту историю с насосами пытались решить в некоторых нефтегазовых компаниях, тогда хайп по машинному обучению не был таким высоким как сейчас, да и разнообразия выбора алгоритмов тоже не было.
В итоге у кого то это решение сейчас в тестовом режиме, большинство от него просто отказались и остались на старом износе, его проблема в том, что вы просто статистику насоса считаете , а хотелось бы посмотреть на датчик и сказать что скоро произойдет поломка, как вы и сказали.
Мечта для недропользователя - это знать количество дней через которое насос сломается (задача регрессии), однако у нас такое не получилось провернуть, поэтому перешли к задаче поиска аномалий
Эта модель как раз таки строит некоторое мат ожидание относительно параметра телеметрии, например того же ток пэд, дебита жидкости, температуры на входе в уэцн и сопротивления изоляции. Ещё есть такой прекрасный параметр как частота самого тока, но в наших данных его было очень мало, поэтому от данного параметра пришлось оказаться, хотя он своего рода killer feature.
Так вот построив мат ожидание мы смотрим на разницу между тем что выдала модель и что происходит в реальности, на основе этой разницы, если разница небольшая, то все окей, если она превышает установленный порог, то скорее всего это аномалия и скорее всего скоро произойдет поломка.
Тех кто в курсе насколько это возможно мы спрашивали, на сам промысел нас, естественно, никто не звал.
В принципе те параметры которые были выбраны исходили как раз таки из экспертного мнения разработчиков и это тоже была отдельная история по тому как подобрать модель чтоб что-то заработало с одной стороны и с другой было адекватным
1)Строить лес по одному насосу отдельно на самом деле процесс сомнительный, по крайней мере в рамках нашего датасета. 1 цикл жизни это от 200 до 1000 дней (иногда больше, иногда меньше), временной шаг 1 день, насосов суммарно 9 тысяч, выжимка на которой он изначально строился это около 100 скважин (насосов) в одной группе. Ясное дело что метрики будут выше и алгоритм заработает, вопрос эффективно ли делать на каждый насос на большом месторождении отдельную модель? Если у вас 20 насосов, естественно можно навесить изолирующий лес на каждый, или вообще взять авто ML в виде Etna или Prophet для каждого из них и спокойно пить чай. Собственно поэтому переход к Автоэнкодеру и был произведен. Наверное лучше 6 часов один раз потратить на train одной модели (автоэнкодера) и фиксировать её эффективность, чем плодить множество моделей и думать как это все объеденять потом.
LOF не пробовал и вряд-ли снова же его результат будет значительно отличаться от его собратьев. Аномалий в данных много и если алгоритм реагирует на любой чих, то это приводит к ложному срабатыванию, если оно произошло, а условный оператор заказал новый насос, потому что поверил, то этот насос просто будет стоять на складе впустую еще какое-то время до действительной поломки, что не очень хорошо, потому что эти насосы берут в аренду, как правило. Тогда оператор просто перестанет верить в алгоритм и он станет просто не нужным.
Также к этому я приводил пример с cusum на единичной скважине, решение выдает ложные срабатывания:
Переходя к этой задаче я попробовал такой метод как cusum и получил интересный результат. Аномалии явно происходят чаще чем в день выбытия, что объясняло то, почему классификатор не работал. На протяжении всего цикла жизни скважины можно заметить, резкие падения амплитуды, они вызваны геолого-техническими мероприятиями, сменой режима работы скважины и рядом других процессов в ходе эксплуатации.Иногда эта смена режима и есть то самое выбытие и пройзойти оно может действительно заранее.
Cusum (фактический день выбытия 386)
2) Нормализация данных перед обучением Автоэнкодера это Min Max scaler, естественно, а разведочный анализ проводился суммарно сначала на наличие выбросов и пропусков, которых было много, поэтому финальный датасет это уже не 9, а примерно 5,8 тыс. скважин. Потом проводились поиски коррелирующих параметров относительно целевой наработки на отказ, или же самого отказа (F-test, Pearson, Mutual info). Также на единичных скважинах чтобы лучше понять данные и как меняется амплитуда какого-либо параметра перед выбытием
3) Gridsearch в данной задаче это единственный возможный вариант найти оптимальные гиперпараметры, потому что наугад тут не подкрутишь. Естественно набор гиперпараметров был не настолько большим, чтобы проводить его в несколько дней, поэтому как я отметил есть вероятность, что человек со стремлением решить эту задачу через classic ML, запустив gridsearch на много времени получит какой-то адекватный результат. Задавшись вопросом нужен ли мне такой gridsearch я и перешел к Автоэнкодеру. На удивление обучить нейронку просто быстрее, чем перебирать оптимальные гиперпараметры, а еще эмбеддинги от автоэнкодера можно использовать дальше и перейти от них к более простым решениям, что в принципе тоже должно сработать, возможно тот же LOF тут будет к месту.
В первой статье (https://habr.com/ru/articles/800999/) как раз таки об этом и шла речь, 50 признаков в сумме, пытаемся разделить планеты на кандидатов и не кандидатов, в датасете есть начальная разметка данных, а более подробно о признаках можно прочитать здесь: https://exoplanetarchive.ipac.caltech.edu/docs/API_kepcandidate_columns.html поскольку данная статья рассматривалась больше в ключе ML и соответственно призвана выполнять следующее: Определить исходя из отобранных признаков является ли небесное тело, которую обнаружили по спутнику Kepler кандидатом в экзопланету, или же нет. Соответственно подробное рассмотрение признаков в этой статье предусмотрено не было, а ссылка на их описание может помочь тем, кто действительно готов потратить на это своё время и возможно добавить что то от себя.
Ну смотрите в вашей же статье написано что:
Чтож, возможно в Spring AI его решили переназвать, давайте проверим, поскольку я без понятия как работает Spring AI и не знаю Java, все же убедимся в информации.
Узнаем что такое MCP в контексте Spring AI
Сделаем следующие шаги:
1) Открываем документацию Spring AI про MCP: https://docs.spring.io/spring-ai/reference/api/mcp/mcp-overview.html
2) Посмотрим как выглядит yaml файл и действительно ли вы пишите MCP-сервер и имеете ввиду именно MCP от Anthropic, а не какое-то кастомное название внутри фреймворка/разработчиков/компании
yamlвнутри документации выглядит вполне похожим на ваш, но в нем нету некоторых параметров, которые есть у вас, либо же наоборот: https://docs.spring.io/spring-ai/reference/api/mcp/mcp-server-boot-starter-docs.htmlВывод по Spring AI: название MCP точно не относится к вашему внутреннему сленгу, а относится к open-source протоколу от Anthropic : https://modelcontextprotocol.io/introduction
Докажем что статья или её часть была написана ИИ и не проверена автором
Сказанное выше не доказывает, что вы использовали ИИ, так ведь?
Чтож давайте сделаем запрос в относительно старую модель, которая вряд-ли имеет контекст (была дообучена, или посмотрела в интернете/раге/любым другими способом) про MCP
Как я уже сказал модель не знает что такое MCP и такая проблема была даже у Claude Sonnet 3.7 и все еще сохраняется, потому что данные про MCP не попали в корпус на претрене или другом виде тюнинга, ну и авторы не засунули инфу о нем в системный промпт, тем не менее Claude имел возможность им пользоваться, поскольку это просто стандартные тулы в новой обертке, грубо говоря.
Отсюда следует вывод, что автор использовал какую-то из моделей, которая все еще не знает о том, что такое MCP на самом деле, но возможно умеет пользоваться интернетом.
В доказательство того, что модели знают что такое MCP, возьмем Claude Sonnet 4.0
Вот этот ответ действительно правильный и верный, возможно одна из причин выпуска семейства моделей Claude 4.0 в том, чтоб они могли объяснить что такое MCP ))
Вывод сгенеренному тексту: автор использовал ИИ как минимум для генерации введения, а также перенес в статью незнание LLM о том что такое MCP.
С одной стороны мы все можем ошибаться, однако информация автора о том, что такое MCP явно сгенерена нейронкой и не проверена.
К тому же:
Лично я такие комменты стал бы писать в формате:
Поскольку это быстрее и удобнее и не заставляет делать множество табуляций, отступов, что может привести к сдвигу текста и нерабочему файлу из за этого же сдвига.
Либо автор люто пишет пробелы, табуляции и хорошо редачит текст в
yamlфайлах, либо эту часть также сгенерила нейронка.Вывод общий
Возможно не вся статья сгенерена не самой свежей версией GPT, однако это должно заставить как автора, так и нас задуматься о том, что не нейронка виновата, что выдала нам неверную информацию, а мы виноваты, что не учли особенность технологии, не проверили информацию и продолжаем распространять ложные термины.
P.S. Извините за духоту.
Я сам пользуюсь нейронками, чтобы писать код, редачить текст, переводить слова других людей с русского на русский, нейронки классно умеют править структуру текста для статьи, делать прикольные и кликбейтные заголовки, но тем не менее:
Мне кажется это out-of-scope вопрос, который больше подходит для отдельной небольшой статьи.
Во первых по вопросу об LLama я предлагаю изучить системную карточку/статью данной модели, а именно конкретной с xxB параметрами модели.
Для LLama 3.1 например представлен специальный токен:
<|python_tag|>он как раз используется для того чтобы обозначить модели представленный тул.
Также в карточке LLama представлено множество примеров того, как на уровне специальных токенов размечается текст, чтобы модель поняла то, что от неё хотят.
Также там обозночается, что 8B модель по идее может работать с тулами, но качество может быть сомнительным.
У Transformers есть неплохое объяснение того как это можно реализовать, абстрагируясь от Pytorch (в качестве низкоуровневой библиотеки), без каких либо сторонних API эндпоинтов.
На уровне модели:
статья: https://huggingface.co/blog/unified-tool-use
документация: https://huggingface.co/docs/transformers/main/chat_extras#tools
Актуальные модели умеют с этим работать и могут быть дообучены под эти задачи.
статьи про это:
Toolformer: Language Models Can Teach Themselves to Use Tools:
https://arxiv.org/pdf/2302.04761
TOOLFLOW: Boosting LLM Tool-Calling Through Natural and Coherent Dialogue Synthesis:
https://arxiv.org/pdf/2410.18447
В контексте агентов с тулами логику можно описать следующим образом:
Агент может "вызвать" функцию, вернув json, который эту функцию описывает.
В моем примере это выглядит так:
Потому тула начинает выполнять запросы в интернет, например:
В итоге на основе контекста из тулы формируется финальный ответ
Функция выполняется у вас локально, результат её вызова переходит в контекст Input запроса модели. То есть в ваш системный промпт и промпт пользователя подмешивается еще респанс с тулы, из за чего значительно растет расход токенов на input.
Модель соответственно анализируя все это выдает финальный ответ, качество которого зависит от системного промпта, запроса пользователя и качества работы самой тулы.
В реальности, а не как на игрушечном примере в этой статье, вы скорее всего захотите более явно и подробно описать и через системный промпт те тулы, которые вы хотите использовать, а также само описание тулов также сделаете подробным.
Также когда у вас есть конкретно определенный формат вывода, например через модель Pydantic, модель будет подстраивать агрументы в тулу так, чтобы выполнить все что вы указали, при этом формируя аргументы функции не за один раз, а за несколько запросов, пока все поля не будут заполнены (в идеале)
Подробнее можно почитать в документации от Open AI: https://platform.openai.com/docs/guides/function-calling?api-mode=responses&example=get-weather#overview.
Надеюсь смог ответить на ваш вопрос
Ну так далее я указал на короткий пост от nvidia по решению этой проблемы. После запуска одного единственного сервиса (при условии что проприетарное ПО), TGP работает аналогично Винде.
Если бы на Linux было действительно все плохо с дровами для Nvidia, то нейронки на виртуалках с виндой бы обучали.
А не проще ли
устаровить ollama (ос не имеет значения)
Пользуемся
Если надо в прод:
можно с докером сделать ту же историю, просто прописать условный композ и скрипт чтоб моделька скачалась.
Пользуемся
Вот например на stack overflow эта тема с ollama поднималась: https://stackoverflow.com/questions/78388016/run-ollama-with-docker-compose-and-using-gpu.
Из плюсов не нужно тянуть за собой лишние python зависимости, а кому надо просто через sdk будут обращаться. У ollama есть и свой, есть в langchain, наверное есть и в других фреймворках.
В будущем обязательно проверим эффективность данного метода, в сравнении с наработанным baseline, спасибо за идею.
Спасибо ☺️
Лет 5 назад эту историю с насосами пытались решить в некоторых нефтегазовых компаниях, тогда хайп по машинному обучению не был таким высоким как сейчас, да и разнообразия выбора алгоритмов тоже не было.
В итоге у кого то это решение сейчас в тестовом режиме, большинство от него просто отказались и остались на старом износе, его проблема в том, что вы просто статистику насоса считаете , а хотелось бы посмотреть на датчик и сказать что скоро произойдет поломка, как вы и сказали.
Мечта для недропользователя - это знать количество дней через которое насос сломается (задача регрессии), однако у нас такое не получилось провернуть, поэтому перешли к задаче поиска аномалий
Эта модель как раз таки строит некоторое мат ожидание относительно параметра телеметрии, например того же ток пэд, дебита жидкости, температуры на входе в уэцн и сопротивления изоляции. Ещё есть такой прекрасный параметр как частота самого тока, но в наших данных его было очень мало, поэтому от данного параметра пришлось оказаться, хотя он своего рода killer feature.
Так вот построив мат ожидание мы смотрим на разницу между тем что выдала модель и что происходит в реальности, на основе этой разницы, если разница небольшая, то все окей, если она превышает установленный порог, то скорее всего это аномалия и скорее всего скоро произойдет поломка.
Тех кто в курсе насколько это возможно мы спрашивали, на сам промысел нас, естественно, никто не звал.
В принципе те параметры которые были выбраны исходили как раз таки из экспертного мнения разработчиков и это тоже была отдельная история по тому как подобрать модель чтоб что-то заработало с одной стороны и с другой было адекватным
Сразу видно нефтяники вошли в чат, поменяю на схему
1)Строить лес по одному насосу отдельно на самом деле процесс сомнительный, по крайней мере в рамках нашего датасета. 1 цикл жизни это от 200 до 1000 дней (иногда больше, иногда меньше), временной шаг 1 день, насосов суммарно 9 тысяч, выжимка на которой он изначально строился это около 100 скважин (насосов) в одной группе.
Ясное дело что метрики будут выше и алгоритм заработает, вопрос эффективно ли делать на каждый насос на большом месторождении отдельную модель?
Если у вас 20 насосов, естественно можно навесить изолирующий лес на каждый, или вообще взять авто ML в виде Etna или Prophet для каждого из них и спокойно пить чай.
Собственно поэтому переход к Автоэнкодеру и был произведен.
Наверное лучше 6 часов один раз потратить на train одной модели (автоэнкодера) и фиксировать её эффективность, чем плодить множество моделей и думать как это все объеденять потом.
LOF не пробовал и вряд-ли снова же его результат будет значительно отличаться от его собратьев. Аномалий в данных много и если алгоритм реагирует на любой чих, то это приводит к ложному срабатыванию, если оно произошло, а условный оператор заказал новый насос, потому что поверил, то этот насос просто будет стоять на складе впустую еще какое-то время до действительной поломки, что не очень хорошо, потому что эти насосы берут в аренду, как правило. Тогда оператор просто перестанет верить в алгоритм и он станет просто не нужным.
Также к этому я приводил пример с cusum на единичной скважине, решение выдает ложные срабатывания:
2) Нормализация данных перед обучением Автоэнкодера это Min Max scaler, естественно, а разведочный анализ проводился суммарно сначала на наличие выбросов и пропусков, которых было много, поэтому финальный датасет это уже не 9, а примерно 5,8 тыс. скважин. Потом проводились поиски коррелирующих параметров относительно целевой наработки на отказ, или же самого отказа (F-test, Pearson, Mutual info). Также на единичных скважинах чтобы лучше понять данные и как меняется амплитуда какого-либо параметра перед выбытием
3) Gridsearch в данной задаче это единственный возможный вариант найти оптимальные гиперпараметры, потому что наугад тут не подкрутишь. Естественно набор гиперпараметров был не настолько большим, чтобы проводить его в несколько дней, поэтому как я отметил есть вероятность, что человек со стремлением решить эту задачу через classic ML, запустив gridsearch на много времени получит какой-то адекватный результат.
Задавшись вопросом нужен ли мне такой gridsearch я и перешел к Автоэнкодеру. На удивление обучить нейронку просто быстрее, чем перебирать оптимальные гиперпараметры, а еще эмбеддинги от автоэнкодера можно использовать дальше и перейти от них к более простым решениям, что в принципе тоже должно сработать, возможно тот же LOF тут будет к месту.
В первой статье (https://habr.com/ru/articles/800999/) как раз таки об этом и шла речь, 50 признаков в сумме, пытаемся разделить планеты на кандидатов и не кандидатов, в датасете есть начальная разметка данных, а более подробно о признаках можно прочитать здесь:
https://exoplanetarchive.ipac.caltech.edu/docs/API_kepcandidate_columns.html
поскольку данная статья рассматривалась больше в ключе ML и соответственно призвана выполнять следующее:
Определить исходя из отобранных признаков является ли небесное тело, которую обнаружили по спутнику Kepler кандидатом в экзопланету, или же нет.
Соответственно подробное рассмотрение признаков в этой статье предусмотрено не было, а ссылка на их описание может помочь тем, кто действительно готов потратить на это своё время и возможно добавить что то от себя.