Model Context Protocol (MCP) Course от Hugging Face

Достойный курс, ещё и бесплатный. Когда я читал whitepaper от Anthropic, казалось, что MCP - это просто некий хаб для функций (tools) с целью унификации API (aka function registry), чтобы в будущем упростить интеграцию инструментов друг с другом. Но все не совсем так. Протокол предполагает наличие, помимо самих функций (Tools), ещё и:
• Resources (Ресурсы): расширенный контекст о системе, доступный только для чтения, например, структура базы данных или список файлов
• Prompts: Готовые, сложные сценарии, использующие Tools и Resources

Кажется, что Tools и Prompts могли бы быть одной сущностью, но они намеренно разделены. Чтобы агент имел выбор: либо просто вызвать конкретный Tool для выполнения 1го действия, либо запустить более сложный Prompt, который под капотом может использовать несколько инструментов и ресурсов для достижения цели.

Понравился пример из курса, когда MCP используется для обеспечения конфиденциальности: например, данные клиента можно обрабатывать локально, на его же стороне, не передавая их на сервер.

P.S. Используя FastMCP, можно поднять такой сервер в несколько строк кода

LLM blending работает но дорого

Если бюджеты позволяют, для улучшения метрик можно комбинировать ответы от разных промптов или LLM, используя агрегацию с помощью другой LLM или majority voting. Как в старых добрых табличных задачках, осталось только до стэкинга дойти.

В статье Are More LLM Calls All You Need на MMLU PHYSICS blending улучшает точность на лёгких вопросах с 88% до 96% при 10 запросах, но на сложных задачах всё не так однозначно. На сложных задачах, где LLM с большей вероятностью выдаёт неверный ответ, при увеличении числа вызовов самый популярный (но ошибочный) ответ чаще побеждает в голосовании, что снижает общую точность. При этом обычный voting работает лучше, чем filter-voting, где итоговый ответ определяет отдельный вызов модели.

А в статье Beyond Majority Voting: LLM Aggregation by Leveraging Higher-Order Information предложены другие методы агрегирования (Optimal Weight, Inverse Surprising Popularity), которые учитывают корреляции и точность между моделями, как итог превосходят простое majority voting. По сути, для ответов моделей просто подбираются оптимальные веса для взвешивания. Это даёт прирост в +0.5% к точности лучшей модели (на датасетах UltraFeedback и ARMMAN, но наблюдается отрицательный эффект на MMLU). И +5% по сравнению с majority voting при 2х запросах и падением эффекта до +1% при 10и моделях. Сильное влияние оказывает некоррелированность ответов - если варианты слишком похожи, прироста почти нет

🚀 Ищу DS в свою новую команду: AI агенты + классика в HR-блок:

Middle+/Senior Data Scientist [Сбер, Блок “Люди и Культура”]

📍Москва (офис/гибрид)

Стек: Python, SQL, GigaChat, LangChain/LangGraph, numpy, pandas, pytorch, LightGBM

Чем предстоит заниматься: разрабатывать ИИ-агентов (например, ИИ-рекрутер) с использованием GigaChat; ранжировать резюме и вакансии; RecSys для обучающего контента; прогнозировать отток и внутренние перемещения сотрудников; автоматизировать HR-процессы; +прямое влияние на продукт

Откликаться на hh https://hh.ru/vacancy/127334738

В октябре проходила конференция Avito.tech.conf for leads & managers. Было приглашение, но посмотрел я только в записи. Непросто сделать интересные доклады на нетехнические тему, но достойное были

• Про запуск GenAI-решений - перед запуском проекта нужно оценить затраты, сделать Proof of Concept, а затем MVP. База.

• Дискуссия про калибровки в бигтехе - кажется, везде всё очень похоже, или, по крайней мере, компании к этому стремятся

Но особенно рекомендую следующие доклады:

• Принятие решений и принципы управления в Tech. Доклад начался с проблем больших компаний, где процессы принятия решений очень долгие. Решение - выстраивать вертикали в компании, сами команды и процессы. Например, на встречах люди понимают свои роли и кто должен принять решение. Руководство должно не участвовать в принятии всех решений, а создавать такие правила и культуру, чтобы на местах принимались правильные решения. Если решение некритичное, не нужно обсуждать его как стратегическое. Интересно про автономность команд: если команды как один большой монолит, то принятие решений потребует вовлечения большого количества других команд, а так делать не надо.

• Найм руководителей. Ключевое — это развивать навыки интервьюера и придумывать хорошие тестовые кейсы, приближенные к предстоящей работе.

• Вертикальный рост менеджера. Тема разбиралась на большом гипотетическом кейсе. Резюмируя: это не просто исполнение обязанностей, а системный путь с обучением, который нужно пройти, зачастую проявляя компетенции следующего грейда

Structured output с помощью схем Pydantic в агентах - уже давно база. Но оказывается тут пошли дальше: с его помощью управляют и ризонингом, и роутингом, и оркестрацией. Подход назвали Schema-Guided Reasoning (SGR). Как бонус, за счёт более строгого управления процессом, чем простым промптом, получаются более надёжные пайплайны. Очень хорошо описано здесь (там цикл статей). Удивительно, но статью на arxiv не нашёл

Достойный блог для досуга от бывшего CTO noname компании, хотя он много где работал, включая Uber, Digg и Yahoo

Moving from an orchestration-heavy to leadership-heavy management role
Анализирует переход менеджера от роли, где он просто распределяет задачи (orchestration), к роли, где он активно участвует в выявлении проблем, их решении и построении стратегии. (problem discovery/selection с solution discovery помимо solution selection и execution с ongoing revision)

Good engineering management is a fad (fad = прогрев) и Career Advice 2025
Атрибуты хорошего менеджера меняются в зависимости от потребностей бизнеса, и здесь важно подстраиваться (см история с LLM). Эта идея перекликается с советами из статьи про карьерные советы о необходимости меняться, так как рынок уже не такой, как 10 лет назад

Components of engineering strategy
Инженерная стратегия создается не интуитивно, а путем последовательного выполнения шагов: исследования, оценки текущего состояния, тестирования, финализации решения с учетом компромиссов, и внедрение. Но странно, что сюда не добавили эффекты/измерения, иначе зачем строить вундервафлю, сразу видно инженерный подход

Productivity in the Age of Hypergrowth / How to evolve an engineering organization / Engineering cost model
Как строить структуры компаний, оценивать людей и т.д. Автор пушит стратегию найма на уровень N-1 при уходе сильных специалистов, но с учетом веса для соблюдения заложенного баланса людей разного уровня. При этом принятие решений по структуре должно исходить из оценки влияния на бизнесовые показатели.

Открытые сезона новогодних корпоративов 🎉

Серьезная подготовка, ребята закодили аналог игры 100к1 с llm’ми чтобы объединять похожие ответы 😎