Люди за это деньги платят

"Не используйте технологию в продукте только потому, что это круто!"

Некоторые ML инженеры имеют черту усложнять решение проблемы с самого начала. В контексте LLM они сразу же хотят утонуть в файн тюнинге... Подбор гиперпараметров, наблюдать за validation loss и чистить датасеты!!! ведь это и есть настоящая ЭЙАЙ наука, скажут они.

По факту, в контексте LLM, в большинстве случаев это over-engineering, то бишь использование огромной кувалды для забивания гвоздиков.

Предлагаю свой ментальный фреймворк для решения задач любого типа:

Шаг 0.
Ты уверен, что хочешь спуститься в бездну галлиционирющих ЛЛМ? Может быть задача решается с помощью regex или обычной проги?
Если да, то можешь смотреть прикреплённую блок-схему.

<смотрит блок схему 🤔>

<досмотрел, ставит огонёчек, репостит>

TL;DR

Тюнить модель != RAG

когда вы тюните модель вы изменяете параметры нейронной сети, во время RAG вы просто обогащаете контекст модели

Ты не хочешь тюнить большую языковую модель, поверь мне!!!
- Поддержка продукта построенного над натюненой моделью будет куда более комплексной чем использование API
- Подготовить хороший датасет это дни или недели скучнейшей работы
- Тренировка стоит деньги, например H100 сейчас стоит 3$ в час, это несколько десятков миллионов input токенов для gemini
- Скорее всего ты просто сломаешь модель и она станет тупее первого grokа
- Если что-то выглядит/звучит круто, это не значит, что это стоит сразу же применять
- Через 4 месяца выходит новая модель, будешь всё перетюнивать?

#ai #dev_help

@makebugger

Самый полезный пост про кастомные MCP в вашей жизни

Если вы последний год не жили под камнем, то вы точно слышали заморскую аббревиатуру MCP (эм си пи). Это такой протокол, который позволяет языковым моделям взаимодействовать с внешними функциями и сервисами.
Он работает по принципу Remote Procedure Call, то есть модель может вызвать функцию, которая исполняется на другом сервере или в другом приложении.

Короче, чтобы каждый не писал кастомные tools для взаимодействия с внешними ресурсами и сервисами, ребята из Anthropic решили стандартизировать всё это мракобесие и теперь вы можете без забот подключить к вашему кодинг агенту кучу MCP tools (о самом полезном MCP я писал 👉 тут) с помощью которых он может взаимодействовать с различными системами во время выполнения поставленной задачи.

Но если с использованием MCP всё понятно, то как нам написать свой кастомный MCP server? В интернете есть куча стартапов и SaaS (пример) которые сгенерируют вам готовый MCP сервер по вашей OpenAPI спецификации, но проблема в том, что это жёсткий антипаттерн, который, к сожалению, в индустрии встречается крайне часто.

Ну а чо, просто обернуть готовые REST эндпоинты в MCP tools и готово, теперь агент может взаимодействовать с нашим приложением, бюджет освоен, стейкхолдеры с довольным лицом и покрасневшими щёчками добавляют плашку «эй ай копайлот» к своему продукту.

Почему это плохо и так делать не надо?

Давайте представим ситуацию у нас есть проект где есть users и teams.
Есть следующие эндпоинты:

• GET /user/:id – получить конкретного пользователя по айдишнику
• PUT /user/:id – изменить информацию о пользователе
• GET /teams – получить все команды
• GET /teams/:id – получить конкретную команду по айдишнику

Вы заворачиваете эти эндпоинты в MCP tools один в один. Дело сделано.

Теперь представьте, что юзер просит агента: «Добавь Сашу из команды маркетинга в команду разработки».
Простой запрос, в UI вы бы просто выбрали человека из дропдауна и нажали кнопочку. Но агент с вашими REST-обёртками начинает танцевать балет из пяти актов:

 1. Вызывает GET /users чтобы найти всех Саш
 2. Парсит ответ в поисках нужного Саши
 3. Вызывает GET /teams чтобы найти команду маркетинга (проверить что Саша там)
 4. Вызывает GET /teams снова чтобы найти команду разработки
 5. Наконец вызывает PUT /user/:id с UUID Саши

Пять вызовов вместо одного. И это я ещё упростил, в реальности там может быть проверка прав доступа, валидация, логирование и всякая другая хрень.

Но это ещё не всё, дальше веселее. Проблема номер два – UUID это кошмар для LLM. Языковые модели галлюцинируют UUID-ы как проклятые. Они могут решить что
a1b2c3d4-e5f6-7890-abcd-ef1234567890
это валидный айдишник пользователя просто потому что он похож на UUID который вы передали в контексте.

И вот ваш агент пытается обновить пользователя который не существует, получает 404, начинает ретраиться, жрёт токены и в итоге сдаётся, а юзер сидит и думает «ну и хрень это вашэ эй-ай».

К тому же, UUID токенизируется крайне неэффективно. Один UUID это примерно 23 токена в зависимости от модели, а если у вас в ответе приходит массив из сотни пользователей с их UUIDs, то сами можете представить качество такого context engineering’а.

Что делать с UUID почитайте 👉 тут.


Итак, наш запрос: «Добавь Сашу из маркетинга в команду разработки»

Это конкретное действие с понятной бизнес-логикой. Но ваш REST API думает ресурсами: юзер, команда, их свойства.

Агент хочет выполнить действие 
moveUserToTeam(user: "Саша из маркетинга", targetTeam: "разработка")

а получает набор CRUD операций которые надо самому оркестрировать.
И вот агент начинает дирижировать этим оркестром: проверить, получить, обновить, проверить ещё раз… А если где-то в середине что-то упало? У REST API нет транзакционности. Через несколько запросов вы останетесь с Сашей, который наполовину в маркетинге и наполовину в разработке…

А как же правильно?

Ответ в комментах (место закончилось)
👇

#dev_help #ai

@makebugger

Важное о ЭМ СИ ПИ – да, опять
_
Антропики опубликовали действительно важную статью о проблемах MCP серверов. О некоторых косяках я уже писал 👉тут, сейчас на работе мы разрабатываем проект, где эти проблемы раскрылись во всей красе и разрушили изначальные планы по срокам.

Что не так с текущим подходом

У нас есть supervisor агент, делегирующий работу на reAct субагентов, которые напрямую взаимодействуют с MCP тулами. Всё ломается, когда агент должен оркестрировать что-то сложнее чем "добавь нового пользователя". Например: "измени команду пользователя X на команду с названием Z".

Допустим, что наш MCP сервер это просто обёртка над RESTом с классическими CRUDами:

get_user(), update_user(), create_user(), delete_user(), get_team(), update_team()...

см. прикреплённую картинку для наглядности.

Проблема 1️⃣
Декларация ВСЕХ тулов включается в контекст при каждом вызове модели, даже если тебе нужно использовать 10% из них. В контекст летит куча мусора, который никак не помогает модели выполнить задачу. Единственные кто в выигрыше – провайдеры моделей, которые получают больше денег за токены из-за MCP серверов, которые ты накатил в своё IDE и забываешь их выключать когда они тебе не особо нужны 😏

Проблема 2️⃣
Промежуточные результаты жрут контекст. Чтобы изменить команду юзера X, нужно 3 вызова MCP тулов — каждый постепенно наполняет окно своим выводом и ошибками. О context management писал 👉тут.

Почему лучше дать модели писать код

На рабочих созвонах с другими AI-чадами мы пришли к выводу: надо дать модели возможность просто писать и исполнять код. Код модели пишут куда лучше, чем вызывают тулы, и это логично. До 2023 года парадигмы tool calling вообще не существовало – провайдеры тренируют модели вызывать тулы на синтетических данных, которых никогда не было на GitHub. Заставлять LLM работать через tool calling это как отправить Прелепина на месячные курсы китайского, а потом попросить написать роман на этом языке. Мб получится... но партия не будет довольна (ни та, ни та)! 😏

Решение от Anthropic

Вместо прямого вызова тулов представить MCP серверы как код-библиотеки. Агент взаимодействует с ними через написание и исполнение кода.
MCP серверы представляются как файловая структура с TypeScript функциями:

servers/
├── user_management/
│   ├── getUser.ts
│   ├── updateUser.ts
│   ├── createUser.ts
│   └── index.ts
├── team_management/
│   ├── getTeam.ts
│   ├── updateTeam.ts
│   ├── createTeam.ts
│   └── index.ts

Агент загружает в контекст только те тулы, которые нужны для задачи, исследуя файловую систему.

Что это даёт на практике?

• Progressive disclosure: Модель навигирует по файлам и читает определения по требованию, а не все сразу. В примере Anthropic это сокращает использование токенов со 150,000 до 2,000 – экономия 98.7%.

• Фильтрация данных: Агент обрабатывает большие датасеты в среде исполнения. Вместо загрузки 10,000 строк из таблицы, можно отфильтровать нужные в коде и вернуть только 5.

• Эффективный control flow: Циклы, условия и обработка ошибок через привычные паттерны кода вместо цепочки отдельных tool calls.

• Privacy: Промежуточные результаты остаются в среде исполнения и не попадают в контекст модели. Можно даже автоматически токенизировать PII — модель видит [EMAIL_1], а реальные данные текут напрямую между системами.

• State persistence: Агент может сохранять промежуточные результаты в файлы и создавать переиспользуемые функции. Это завязывается с концепцией Skills с которой я ещё не до конца разобрался и мнения на этот счёт не имею, но идея в том, что со временем агент САМ наращивает свой тулбокс высокоуровневых возможностей.


AI инжиниринг сейчас — это как web development до 2010. Всё пишется в сыром HTML/CSS + JS, ещё непонятно, что мы будем использовать через 3-5 лет. Однозначных best practices просто нет, все учатся на ходу.
Экспертов с 15+ годами опыта в этой сфере не существует, а интервью на AI Engineer часто проводят люди, которые сами перекатились в ИИ-тусовку буквально вчера. И, лично для меня, в этом и кайф этой ниши 🚀

[источник]

#dev_help #ai

@makebugger

Желание эффективных менеджеров пихать ИИ туда куда не надо – главный источник финансирования автора этого канала

Итак, представим ситуацию 1️⃣, вы забыли пароль от аккаунта. Что делать?

До 2022 года вы бы нажали на кнопку «Забыл пароль» и сделали новый, так? Так?..

В ситуации ИИ революции, которая вихрем отбирает тёплые просиженные места у работяг, вы захотите написать ИИ Агенту 🤖

«Дорогой, ИИ Агент, пожалуйста переделай мне пароль, я его забыл»

после пинг-понга из пары сообщений, ошибки и медленной генерации токенов на половину экрана вы достигнете поставленной цели.

Зачем это делается?
1. Чтобы люди с культями смогли ресетнуть пароль голосом.
2. Чтобы у Соколовского была работа.
3. В этом году остался бюджет который надо куда-то потратить.
4. Чтобы потешить C-level кабанычей тем, что в компанию вошёл ИИ (теперь она воскреснет).

Все из выше перечисленных ответов верны. Я как честный и добросовестный ИИ Инженер интересуюсь

Не кажется ли вам, что здесь **уй не упал никакой ИИ и с ним будет больше мороки?

ответ убил (скриншот прикреплён).

Ситуация 2️⃣, допустим, вы разрабатываете приложение Яндекс Лавка, в голову менеджменту пришла идея добавить ИИ агента с которым вы будете мило беседовать и рассказывать какие вкусы читос вам нравится больше всего (конечно же пицца и кетчуп). Через этого агента можно сделать всё то же, что через графический интерфейс, только в разы медленнее и не до конца.

Я спрашиваю:

А какой долгосрочный план для развития этого агента? В чём собственно цель?

Ответ менеджмента:

Полностью избавиться от графического интерфейса, чтобы пользователи через нашего бота продукты заказывали

выводы, как говорится, делайте сами.

Ситуации реальные, страшные и смешные. Сейчас все хотят купить ИИ, чтобы не отставать от конкурента, часто это доходит до абсурда.

Я не жалуюсь, тут в моём болоте ИИ Инжиниринга не ощущаю «очко на рынке» о котором все говорят, хотя может быть потому что я тот ещё туз 😅
_
Полезное:

Для своих клиентов с кучей идей я всегда делаю Discovery фазу основной итог которой это матрица где Y это Business Value Potential, а X – Tech Feasibility (100 огоньков и скину пример в комменты 👍), на этот график наносятся точки, где каждая точка это безумная идея менеджмента по внедрению ИИ с оценкой по технической и бизнес стороне.

Все точки делятся на три группы:
1. Рекомендую к покупке (клиенту легче купить готовое решение, чем платить за девелопмент)
2. Рекомендую делать самому (мой потенциальный заказ)
3. Деприоритизовано

Для части точек из первого квадранта вы хотите подготовить простенький Proof of Concept.

Сэкономили клиенту деньги, которые бы он потратил на разработку ненужных ему инструментов. Вот только большинство бизнесов не хотят за Discovery платить, предпочитая вбухать тысячи долларов в разработку мёртворождённого ИИ-калеки.

#dev_help #ai

@makebugger