План выживания руководителя с новой командой

В новом выпуске мы с Мишей говорим про 5 фатальных ошибок, из-за которых отношения с командой могут не сложиться.

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

Обсуждаем:

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

Видео особенно зайдёт тем, кому:

• уже дали новую команду,
• вот-вот отдадут,
• или кто сейчас в роли тимлида/руководителя чувствует, что отношения с командой шаткие.

Смотреть на YouTube

Смотреть на VK Видео

Аллокаторы в СPython: база

Тема аллокаторов иногда питонистам кажется сложной, потому что в питоне мы их не вызываем явно. Оттого с ними не очень знакомы, так давайте исправлять и знакомиться!

Зачем вообще нужно много разных аллокаторов? Все они делают одно и то же: выделяют память в куче (heap). В зависимости от наших вариантов использования данной памяти - выделять и освобождать её нужно очень по-разному.

Где-то множество мелких объектов, которые часто создаются и очищаются. Где-то несколько больших, которые должны умирать все вместе. Где-то мы работаем в рамках одного потока, где-то несколько потоков будут запрашивать / высвобождать память параллельно.

Например: при парсинге AST мы используем PyArena аллокатор. Он выделяет сразу много памяти, сразу вычищает все за один раз. Что идеально подходит для парсинга.

Но, для рантайма - задачи, конечно же другие. Там есть долгоживущие объекты, есть много мелких краткоживущих, есть довольно большие, есть маленькие. Для таких задач используют "general purpose allocators". Которые в среднем хороши во всем.

Дизайн аллокаторов в CPython

Питон знает, как его будут использовать. Потому поверх базовых GPA есть собственные надстройки.

Документация:
- https://docs.python.org/3/c-api/allocation.html
- https://docs.python.org/3/c-api/memory.html

В CPython есть: malloc, pymalloc, mimalloc и некоторые их варианты для дебага.

Они разделены на три "домена" для аллокаторов, то с чем они работают, какие задачи решают:
- Raw: для выделения памяти для общих задач, например под сишные буферы или IO. Может работать без PyThreadState
- Mem: для выделения памяти для общих задач, но уже с PyThreadState, например под Python буферы, подходит для мелких объектов
- Object: для выделения памяти под конкретные мелкие объекты

Разработчики C-extensions должны понимать, когда какой использовать и под какие задачи.
К счастью, разработчикам на питоне - такое нужно только для любопытства.

А вот таблица, какие реальные аллокаторы используют те или иные C-API функции в разных режимах:

PyMem_RawMalloc -> malloc
PyMem_Malloc -> pymalloc
PyObject_Malloc -> pymalloc

Она правда немного устарела и не отражает Free-Threading сборки, которые требуют mimalloc 🌚
Кто первый успеет сделать PR с исправлением - тот молодец!
О mimalloc мы как-нибудь отдельно поговорим, там нужно рассказывать сильно глубже, в том числе про GC и PyGC_Head.

Зачем питону свой аллокатор?

В CPython есть (был? для free-threading он не используется и не будет) свой аллокатор: pymalloc, основная задача которого – работа с маленькими Python объектами.
Про него полностью тоже нужно писать большой отдельный пост.

Что вообще важно в аллокаторе?
- Стратегия выделения памяти под новый запрос
- Работа с округлениями размера памяти и выравнивание
- Дефрагментация памяти
- Стратегия очистки памяти

struct arena_object {
    uintptr_t address;
    pymem_block* pool_address;
    uint nfreepools;
    uint ntotalpools;
    struct pool_header* freepools;
    struct arena_object* nextarena;
    struct arena_object* prevarena;
};

Но кратко про pymalloc можно сказать следующее:
- Он создает арены по 1MB
- Внутри арены разделены на пулы по 16KB
- Внутри пулы поделены на блоки фиксированного размера

Зачем? Чтобы не аллоцировать часто маленькие кусочки памяти. Что дорого.

Можно ли управлять аллокаторами?

Да! Есть опции для сборки: --without-mimalloc, --without-pymalloc
И даже переменная окружения PYTHONMALLOC, которая позволяет указать, какой аллокатор использовать для всех случаев. Зачем? Прежде всего для дебага. Но можно потестить, вдруг будет давать буст по скорости или потреблению памяти в ваших вариантах использования.

Обсуждение: какой ваш любимый аллокатор? И почему jemalloc?

| Поддержать | YouTube | GitHub | Чат |

git-lfs: храним большие файлы в репозитории правильно

https://www.youtube.com/watch?v=82wj6y2rmR4

Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).

Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем git clone с нуля, но и самое главное – на скорость всех наших сборок (если мы не используем fetch-depth: 1 или аналог, а использовать их надо).

Решение: использовать git-lfs!

Я пригласил замечательного Олега Чирухина @tg_1red2black, чтобы обсудить:
- Как работает git-lfs на базовом уровне?
- Как мигрировать на него с базового сетапа?
- Как он устроен внутри? Поднимаем https://github.com/git-lfs/lfs-test-server и детально смотрим, что там внутри происходит

Ну и конечно чуть-чуть глянули исходники, они, кстати, на #go 🌚️️️️

Обсуждение: как вы храните большие файлы в рабочих проектах? Насколько большие файлы вы храните?

| Поддержать | YouTube | GitHub | Чат |

#llm #petproject

Фреймворк, как привести к успеху любой AI-проект

Самый частый вариант беседы, когда меня просят помочь с проектом:

- Сева, вот смотри, хотим решить проблему X. Понятно?
- Пока да.
- Супер! Короче, мы взяли 15 ИИ-агентов, в них запихали 4 роутера, облили это все графовой базой знаний. И все это на 1.5B квене, который мы специально доучили, но код обучения случайно удалили.
- Уже понятно меньше, но допустим. А что вы от меня хотите?
- Вот оно у нас плохо работает...

Беседа потом идет примерно одинаково. Готовьтесь, дальше не будет никакого роя AI-агентов. Дальше будет нуднота.

Итеративный фреймворк управления проектом

AI — это работа с высокой неопределенностью. Нельзя все спланировать и пустить по канбану. Мы должны быть готовы, что что-то не взлетит. И это нормально. Нужно просто это как можно быстрее понять.

Элементом фреймворка является гипотеза. Гипотеза — это идея, что некоторое изменение улучшит качество AI-проекта. Например, что нужно LLM обновить до GPT 5.1. Гипотеза может быть в одном из трех состояний:

- Прототипирование. Нужно как можно скорее понять, а стоит ли инвестировать силы. Подробнее в статье.

- Оценка качества. Замерили и теперь понимаем успешная ли гипотеза. Гайд по замеру качества.

- Внедрение. Уверены, что гипотеза полезная. Разрабатываем и внедряем.

Любой проект начинается с самого простого и легко поддерживаемого решения. Например, чат-бот. Вначале просто API к GPT + простой промпт. Больше ничего. Смотрим недостатки (время/цена/галлюцинации/etc). Делаем гипотезу. Потом еще одну. Идею вы поняли.

Откуда берутся гипотезы

Нет, не из статей с хабра и даже не с arxiv.org. Гипотезы рождаются из анализа проблем. Типовой анализ выглядит примерно так:

- Собрали репрезентативный список задач в систему. Например, запросы в чат-бот за год.

- Оценили качество текущей системы.

- Разбили примеры с проблемами на понятные группы.

Дальше для групп проблем придумываем гипотезу, которая их должна починить.

Резюме

Только итеративный подход, где мы понимаем смысл каждого шага. Анализ проблем, прототипирование гипотезы, оценка качества, внедрение.

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

Ваше путешествие начинается с одного шага. Так написано на моей беговой дорожке. Уверен, эти ребята знают, о чем говорят.

#llm #petproject

А судьи кто? Гайд по LLM-as-a-judge

Оценка качества — ключ к фрейморку успешного AI-проекта. Если вы не овладете этим навыком, любые ваши AI-успехи, если они и будут, окажутся только случайной удачей. Недавно в моей статье мы бегло просмотрели эту тему.

Сегодня погрузимся в самый популярный метод — оценка качества моделей “LLM-as-a-judge”. В нем вместо оценки ответов людьми мы оцениваем ответы другой "LLM-судьей". Тут обычно все шутят, что критиковать всегда проще, чем творить. Мне шутка уже надоела, но законы жанра. Извините.

Когда использовать LLM-as-a-judge?

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

1) Разметка не слишком интеллектуальная. Она не требует ни:
а) фундаментальных экспертных знаний
б) сложных логических рассуждений
Например, оценить, был ли ответ модели в контексте, LLM-судья может. Но проверить, логически следует ли ответ из контекста, ей будет сложно.

2) Вам нужны очень быстрые итерации.
Гонка, пожар, стартап. Если вам нужно получать оценку качества через часы, а не дни.

3) У вас нет ресурсов.
Не только денег. Обучение разметчиков это обычное преподавание. Это материалы, ответы на вопросы, тесты, экзамены. Регулярные проверки, что они все не забыли и не жульничают. Это требует много сил и отдельного штата специалистов.

Как сделать LLM-судью? Пошаговый план

1) Берем бизнес-эксперта. Человека, который понимает, когда система работает правильно. Вместе с ним прорабатываем критерии, по которым оцениваем. Например, релевантность ответа, безопасность, достоверность и тд.

2) Вместе с экспертом размечаем по критериям репрезентативную корзинку ответов модели. Репрезентативная, значит это случайное подмножество реальных запросов в нашу систему.

3) Переразмечаем, спорим, пока мы с экспертом согласованно не разметим корзинку. Так мы поверяем, что мы сами поняли критерии. В итоге у нас получается «голден корзинка» таких эталонных примеров хороших и плохих ответов.

4) На части этой корзинки тюним LLM-судью. Тестируем итоговое качество на другой части. Тюнить можно по-разному: писать промпты, разбивать задачу на подзадачи (на каждый критерий можно отдельного судью), добавлять агентность. Можно даже файнтюнить LLM. Важно делать это итеративно, как и во всем AI-проекте.

Резюме

Это не просто дешевый, быстрый в разработке подход. Он еще очень гибкий. Если вы хотите поменять критерии качества, намного проще поменять промпты в LLM, чем переучивать 50 людей размечать по-новому.

Если ваша разметка явно не противоречит 3-м пунктам из этого поста, начните с LLM-as-a-judge, а не с разметки людьми. Если не получится, вы всегда сможете часть простых задач разметить LLM, а все сложные отправить людям. Или сможете давать людям LLM-подсказки, чтобы они могли быстрее размечать.

Пробуйте, пишите промпты, замеряйте качество, задавайте мне вопросы. Если оваладете оценкой качества, тогда никакой AI вам не будет страшен.

Ночной пост, для тех кто потерялся в череде новых обновлений ИИ инструментов.

Ответ на вопрос кто такие Cursor, VS Code, Claude Code, AntiGravity и как они работают в интерактивном формате.

К слову, это новый формат ответа от Gemini Pro.
Теперь так, по одному запросу, можно получить сгенерированный лично под вас интерфейс - хоть инструкцию к использованию чего-то, хоть дашборд вашей эксельки.

https://gemini.google.com/share/5eb1ef25134b

#llm #petproject

Ребята, всем привет!

Мы с командой решили вернуться к истокам и разобрать базовые настройки ChatGPT.

Почему это важно, даже если вы профи?

Потому что ИИ — это не про штамповку одинаковых ответов, а про поток, некую сонастройку.
Чтобы нейросеть стала продолжением ваших мыслей, её нужно правильно забрифовать на уровне настроек.

Разобрали со Светой неочевидные фишки, которые мы сами используем каждый день, чтобы улучшить качество отклика.

Заходите посмотреть👇

#llm #petproject

Куда на самом деле движется индустрия LLM (спойлер: вы выбираете не модель - вы выбираете стек).

Пост навеян свежим релизом Opus 4.5, а именно ее доп фичами как Context Editing - нам показывают действительно впечатляющие демки… Но постойте - это же (очередная) не-фича foundation модели. Это не что-то в весах. Это инфраструктурный middleware, который живет между вами и моделью. И если вы проанализируете (особенно глазами разработчика) релизы последнего года, то вы увидите что мы все дальше от бога от LLM как модели, и тем ближе к LLM как infrastructure-as-a-service. Давайте поговорим, куда нас ведет индустрия и что из этого следует, но начнем с начала.

Большинство людей (в том числе многие разработчики) когда говорят про условный ChatGPT не видят весь спектр между "моделью" и "продуктом" - ведь это одновременно и foundation model, и старый добрый completions API, и вполне себе агентный Responses API c Code Interpreter, File Search (RAG прямо в "модельке", ага) и т.д.

Что на самом деле продают вендоры

OpenAI Responses API - это целая инфра, включая NoSQL БД для истории, хранилище файлов и тд. Вы отдали им state management.

Code Interpreter и Code Execution - это PaaS: managed sandbox - $0.03 за сессию платите за инфру, не за "умную модель".

Claude Context Editing - middleware с настраиваемой стратегией pruning (keep last 3 tool uses, clear 5000+ tokens). Оркестрация, а не интеллект.

Google Grounding и Maps tool - dynamic retrieval: модель решает нужен ли поиск, генерит queries, получает доступ к индексу (глубже публичного API), делает reranking, отдает с citations. Вы покупаете gateway к индексу, не модель.

Даже Structured Outputs - это частично заслуга инфры, а не весов - constrained decoding через CFG (конвертит JSON Schema в грамматику, маскирует невалидные токены). Компилятор поверх модели.

Большинство не осознают, как растет пропасть между проприетарными infrastructure-as-a-service от OpenAI/Google/Anthropic и голыми весами open-source моделей. Проприетарные LLM превращаются из inference провайдеров в операционки для intelligence.

Что из этого следует и что следует иметь в виду

1. Понимать уровни зависимости, я выделяю три:
- State (Threads, File API, memory) - критический lock-in, вы не владеете памятью системы
- Execution (Code Interpreter, sandboxes) - средний lock-in, нужна своя инфра для рантайма
- Behavior (Grounding, Computer Use) - средне-высокий, модель часто обучена под "свои" инструменты

Перед использованием любой фичи спрашивайте: "Где живут данные? Кто контролирует логику? Смогу ли я воспроизвести это сам?"

2. Integration Tax vs Migration Tax - ключевая асимметрия. Проприетарные фичи дают быстрый старт, но стоимость выхода растет экспоненциально. Это не обязательно плохо - это trade-off, который нужно делать осознанно.

3. Разделять Core и периферию
Core (ваша уникальная ценность, основа продукта) - инвестируйте в независимость: свой state management, своя оркестрация и тд.
Пример: AI-агент для support как продукт - владение историей диалогов критично, а вот Code Interpreter для внутренней аналитики - это ок.

4. Есть обратная сторона. Чем глубже расходятся продуктовые слои провайдеров, тем сложнее делать model-agnostic продукты, которые работают так же хорошо. Manus поняли это рано - выжали максимум из Anthropic, не пытаясь быть совместимыми со всеми, и сделали продукт-звезду. Возможно, по той же причине Claude Code так хорош?

5. Учитывайте свою стадию. 0→1 (поиск PMF) - максимально используйте проприетарные фичи, скорость важнее. Когда растете - можно строить абстракции: gateway, свой state для core функций. На стадии масштабирования - еще больше контроля и взаимозаменяемости компонентов (interoperability это дорого).

Главное

Проприетарные AI-платформы - это managed infrastructure, как AWS. Вы платите не только деньгами, но и зависимостью. И этот тренд будет расти. Часто это правильный trade-off, особенно на старте. Но это решение нужно принимать с открытыми глазами - понимать, какую часть системы отдаете "в управление", и делать это осознанно для каждого компонента продукта.

#ml #interview

Асессорская разметка: как оценивать согласованность?

Обычно разметка проходит строго по этапам: сбор данных → создание гайда → запуск разметки обычно с перекрытием → агрегация меток → обучение модели → оценка качества.

Допустим, мы хотим получить разметку данных для классификатора сентимента обращений в поддержку. Мы получили метки от трех асессоров для некоторого количества реальных диалогов. Как же понять, насколько качественный результат разметки?

В такой ситуации можно посчитать коэффициент согласованности — agreement. Он показывает долю совпадающих меток между асессорами.

В нашем случае средний попарный agreement — 83,9%, что достаточно неплохо. Но есть подвох: этот коэффициент, так же как и accuracy в случае бинарной классификации, может вводить в заблуждение при дисбалансе классов. В нашем датасете больше 70% меток приходятся на два класса — «Нейтральный» и «Замешательство». Давайте воспользуемся другими статистическими коэффициентами, чтобы удостовериться в высокой согласованности:

📌 Cohen‘s Kappa (Каппа Коэна) — попарный коэффициент. Оценивает нормализованное согласие между двумя асессорами.

Как интерпретировать результаты:

<0,6 — плохая согласованность.
0,6…0,8 — хорошая согласованность, можно использовать в прикладных задачах.
>0,8 — очень высокая согласованность.

📌 Fleiss’s Kappa (Каппа Фляйна) — подходит для оценки согласованности между несколькими (более двух) асессорами.

В нашем случае Каппа Коэна варьируется от 0,7 до 0,84, что указывает на высокую согласованность. Для дополнительной проверки мы взяли несколько сотен случайных примеров из датасета и вручную расставили метки. Оказалось, что в 44% наши и асессорские метки расходились — то есть, асессоры в среднем согласованно ставят неправильные метки. Вот поэтому даже высокие показатели согласованности не гарантируют качественной разметки данных.

Что делать в такой ситуации — расскажем в следующем посте.