ChatGPT – это не одна модель. Их много, и это круто

OpenAI подробно рассказали, как выбирать модели под разные задачи, чтобы работать максимально эффективно и экономично

📌GPT-4o
Универсальный помощник для повседневных задач. Отлично справляется с письмами, краткими сводками, идеями и лёгкой аналитикой. Понимает текст, картинки, таблицы, документы и даже видео
💬 Примеры:
– Сделать саммари после встречи
– Написать письмо клиенту после запуска проекта
– Придумать идеи презентации по наброскам и скриншотам

📌 GPT-4.5
Лучше всего подходит для текстов, где важен EQ, креативность и убедительность.
💬 Примеры:
– Яркий пост для LinkedIn про тренды ИИ
– Чёткое описание нового продукта
– Письмо а-ля «мы облажались, но вот как мы это исправим»

📌 OpenAI o4-mini
Самая быстрая и экономичная модель для технических вопросов, STEM-задач, программирования и визуальных рассуждений.
💬 Примеры:
– Быстро исправить ошибку в коде
– Извлечь данные из CSV-файла
– Кратко объяснить научную статью

📌 OpenAI o4-mini-height
Модель с дополнительной точностью и глубиной для более-менее сложного программирования, математики и технических объяснений.
💬 Примеры:
– Решить сложное уравнение и объяснить по шагам
– Написать и потестить SQL-запросы
– Подробно объяснить сложную научную тему простыми словами

📌 OpenAI o3
Мощная модель для стратегических задач, глубокого анализа данных, продвинутого программирования и аналитики.
💬 Примеры:
– Проанализировать рынок и предложить стратегию
– Построить многоступенчатый прогноз на основе большого CSV
– Разработать бизнес-стратегию с визуализациями и цифрами

📌 OpenAI o1-pro
Медленная, но максимально точная модель для комплексных аналитических задач, требующих высокого уровня точности.
💬 Примеры:
– Подробный анализ рисков перед запуском продукта
– Многостраничное резюме исследовательских данных
– Алгоритмы и расчёты для финансового прогноза с обоснованием

💡

Чем мощнее моделька, тем выше цена или жестче лимиты

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

#AI@mrtnv_prism

AI Tooling ≠ Function Calling
– в чём разница и зачем это знать

Многие путают AI tooling и function calling, используя эти термины как синонимы. Но это разные уровни взаимодействия LLM с внешним миром.
Разберемся, в чём разница и почему это важно.

Сразу ловите TL;DR:

🟢AI tooling – это общий подход к интеграции моделей с инструментами. Function calling – конкретный механизм вызова функций. А Pydantic помогает структурировать данные для надёжной работы.

🔍 В чём разница?

AI tooling – широкое понятие:
➡️Включает любые способы расширения возможностей LLM
➡️RAG – поиск и подключение внешних документов к контексту
➡️Плагины и расширения
➡️Интеграции с внешними сервисами
➡️Агентные системы

Function Calling – конкретный механизм:
➡️Структурированный способ вызова функций
➡️ Часть AI Tooling, но не весь туллинг
➡️ Формализованный протокол взаимодействия
➡️ Поддерживается нативно многими моделями

🛠️ Pydantic: мост между LLM и кодом

Pydantic решает ключевую проблему function calling – валидацию и структурирование данных:

from pydantic import BaseModel, Field

class WeatherQuery(BaseModel):
    city: str = Field(description="Название города")
    units: str = Field(default="celsius", pattern="^(celsius|fahrenheit)$")
    
# Модель генерирует JSON, Pydantic валидирует

Преимущества Pydantic:
➡️Типизация: чёткие схемы данных
➡️Валидация: автоматическая проверка параметров
➡️Документация: описания полей помогают LLM
➡️Конвертации: автоматическое преобразование типов

Наглядный пример:

# AI Tooling: общий подход
class AIAssistant:
    def __init__(self):
        self.tools = {
            "search": SearchTool(),
            "calculator": CalculatorTool(),
            "database": DatabaseTool()
        }
    
    # Function calling: конкретная реализация
    def execute_function(self, function_call):
        # Pydantic для валидации
        validated_params = FunctionParams(function_call.params)
        return self.tools[function_call.name].execute(validated_params)

❗️Тренды и будущее

Стандартизация: унификация подходов между провайдерами
Нативная поддержка: встроенные Pydantic-схемы в API
Композиция функций: сложные цепочки вызовов
Автодискавери: LLM сама находит нужные инструменты

🟢

Главное понимать

: AI tooling – это множество подходов, function calling – конкретный инструмент, а Pydantic – обеспечивает надёжную валидацию данных.

🟢

Правильный инструмент → правильное решение → меньше проблем → генерим value

#AI@mrtnv_prism
#AITools@mrtnv_prism

@mrtnv_prism

А/Б-тесты [1/3]: базовый гайд для принятия решений на основе данных

💡Регулярно слышу от менти и коллег вопросы про A/B-тесты. И так же часто вижу, как на основе плохо поставленных экспериментов делают выводы, которые потом превращаются в ненужные фичи, неработающие редизайны и сломанные воронки.
Эта серия – для тех, кто строит продукт и принимает решения на основе данных: продакт-менеджеров, аналитиков, инженеров. Здесь — короткие и практичные принципы A/B-тестирования, которые помогут отделять реальные улучшения от случайного шума.
В продуктовой разработке изменения часто оценивают по росту метрик: выше конверсия, быстрее флоу, больше кликов. Но рост цифр сам по себе ничего не доказывает.

🟢A/B – это не просто запуск двух версий. Это метод, у которого есть правила. И если их игнорировать – легко сделать выводы, которые ничего не значат.

🎯 Что такое А/Б-тест

Представим: есть абстратный интернет-магазин. Мы

хотим проверить, какая кнопка "Купить" работает лучше

– красная или зелёная?

А/Б-тест – это эксперимент, который позволяет сравнить гипотезу через сравнение двух вариантов:

➡️50% посетителей – старую красную кнопку (группа А)
➡️50% посетителей – новую зелёную кнопку (группа Б)

Через определенный период времени сравниваем результаты. Если зелёная кнопка принесла больше покупок – огонь! Но как убедиться, что это не случайность? Здесь и нужна статистика...

🔬 Начинаем с гипотезы

Перед тестом всегда формулируется пара предположений (гипотез). Например:

➡️"Зелёная кнопка не изменит продажи" (H₀, нулевая гипотеза)
➡️"Зелёная кнопка увеличит продажи" (H₁, альтернативная гипотеза)

Важный нюанс: можно проверять изменение в одну сторону (только рост) или в обе (любое изменение). Но пара гипотез нужна всегда.

📐 Планируем эксперимент

Сколько продаж нужно для надёжного результата? Если у вас 10 покупок в день, а вы хотите увидеть рост на 5% – потребуются недели тестирования.

Ключевые вопросы перед стартом:

– Какой минимальный эффект имеет смысл? (5% роста? 10%?)
– Сколько пользователей нужно для теста?
– Как долго будем тестировать?

💼 Где применять А/Б-тесты

Интернет-магазин: какой дизайн карточки товара продаёт лучше?
Медиа: какой заголовок статьи привлечёт больше читателей?
Email: когда лучше отправлять рассылку – утром или вечером?
Офлайн-ритейл: на какой полке товар продаётся лучше?
AI-продукты: какой алгоритм рекомендаций удерживает пользователей дольше?

❗️Типичные ошибки (и их цена)

– "О, конверсия выросла на 20%! Останавливаем тест!" → Слишком рано. Может быть случайность.
– "Запустим на 100 пользователях" → Слишком мало. Результат ненадёжен.
– "Тестируем 10 вариантов одновременно" → Растёт шанс увидеть несуществующий эффект.
– "В прошлый вторник сработало!" → А это была не Чёрная пятница случайно?

✅ Чек-лист для запуска теста

– Что конкретно хотим проверить?
– Какую метрику будем измерять?
– Сколько пользователей нужно для теста?
– Как долго будем тестировать?
– Учли ли сезонность и особенности аудитории?

🟢

А/Б-тест работает, когда всё сделано правильно.

Продуманный дизайн + корректная интерпретация = реальный инсайт

Далее расскажу → Почему p-value ≠ вероятности успеха и как правильно интерпретировать результаты тестов

#ABtesting@mrtnv_prism

@mrtnv_prism

Codex – AI, который пишет и тестирует код сам

OpenAI запустила Codex – нового агента внутри ChatGPT, который пишет код, находит баги, пишет тесты и делает Pull Request. Все в облачной песочнице, без установки и лишней возни.

📌 Что он умеет
– Понимает проекты на GitHub
– Пишет и дорабатывает код
– Запускает код и тесты (а потом сам ищет ошибки)
– Работает параллельно и автономно

Codex работает на новой модели codex-1 (на базе o3), специально обученной для задач программирования.

🔗 Подробнее – тут

Пока раскатали только для Pro-аккаунтов, для Plus обещают скоро. Будем тестить 😎

@mrtnv_prism

Статистические тесты и метрики [2/3]: что на самом деле измеряют ваши эксперименты

← В предыдущем посте мы разобрали основы А/Б-тестов и типичные ошибки

💡TL;DR – понимание метрик помогает отличить реальный эффект от шума. Чтобы понять, есть ли изменения на самом деле, важно не только p-value, но и размер эффекта, мощность теста и контекст.

🎯 Что такое статистический тест

Это математический способ ответить на вопрос: «Изменение реально или случайно?»
Представьте, что подбрасываете монетку. Если выпало 6 орлов из 10 бросков, это вполне нормально. Но если 60 орлов из 100 – уже подозрительно, а 600 из 1000 – почти наверняка монетка нечестная.

💡Статистический тест помогает нам определить эту границу "подозрительности" в цифрах.

📊 Ключевые метрики

Когда говорят о статистических тестах, часто упоминают три ключевых понятия:
1️⃣Уровень значимости (α) – это риск увидеть эффект там, где его нет. Обычно его устанавливают на уровне 5%. Проще говоря, мы соглашаемся, что в 5 случаях из 100 будем ошибаться, считая случайность настоящим эффектом.
2️⃣Мощность теста (1−β) – это шанс обнаружить эффект, если он реально существует. Стандарт — 80%. То есть, если изменение действительно работает, мы хотим заметить это в 80% случаев.
3️⃣p-value – самое запутанное понятие. Это вероятность получить такие же (или более экстремальные) результаты, если на самом деле никакого эффекта нет. Низкий p-value говорит: "такой результат маловероятен, если эффекта нет, значит, эффект скорее всего есть".

📋 Как интерпретировать p-value без головной боли

Вот простая шпаргалка по p-value (условно, важен контекст):
➡️Если p < 0.01: "У нас очень сильные доказательства в пользу эффекта"
➡️Если p < 0.05: "У нас достаточные доказательства в пользу эффекта"
➡️Если p > 0.05: "Доказательств недостаточно, чтобы утверждать наличие эффекта"

💡Чем меньше p-value, тем весомее доказательства того, что вы видите реальное изменение, а не случайный шум.

🔍 Четыре возможных результата теста

1️⃣Правда выявлена: эффект есть, и тест его обнаружил. Идеальный результат.
2️⃣Ложная тревога: эффекта нет, но тест показал, что он есть. Это ошибка I рода (вероятность = α). Вы внедряете изменение, которое не работает.
3️⃣Упущенная возможность: эффект есть, но тест его не обнаружил. Это ошибка II рода (вероятность = β). Вы отказываетесь от изменения, которое могло бы принести пользу.
4️⃣Корректный результат: эффекта нет, и тест это подтвердил. Всё правильно.

💼 Реальные примеры из практики

➡️Email-кампания: персонализированные письма увеличили открываемость на 3% с p-value = 0.001. Эффект небольшой, но мы уверены, что он реальный.
➡️AI-чатбот: замена GPT-3.5 на GPT-4 улучшила разрешение клиентских тикетов на 22%, p-value = 0.02. Эффект значительный и статистически подтверждённый.

⚡ MDE (Minimum Detectable Effect) и размер выборки

Перед тестом определите минимальный значимый эффект (MDE) – наименьшее изменение, которое имеет смысл искать. Это влияет на размер выборки.

💡Пример: для обнаружения роста конверсии с 10% до 10.5% (MDE = 0.5%) потребуется около 31 000 пользователей на вариант (при α = 0.05 и мощности 80%)! Вот почему многие тесты "не видят" эффект – просто недостаточно данных

✅ Несколько правил успешных тестов

– Фиксируйте метрики и MDE до запуска. Определите минимальный эффект, который хотите увидеть.
– Рассчитывайте размер выборки заранее. Маленькие изменения требуют больших выборок.
– Смотрите на результаты комплексно. p-value + доверительные интервалы + бизнес-контекст.
– Различайте статистическую и практическую значимость. Эффект может быть статистически доказан, но бизнес-эффект слишком мал для внедрения.

Далее → Как формулировать гипотезы, которые можно проверить и масштабировать

#ABtesting@mrtnv_prism

@mrtnv_prism

Гипотезы в А/Б-тестах [3/3]: от интуитивных идей к системному подходу

← В предыдущих постах мы разобрали основы А/Б-тестов и основы статистических тестов

💡TL;DR – сформулированная SMART-гипотеза + приоритизация (ICE) превращают эксперименты из лотереи в системный инструмент роста

🎯 Откуда брать идеи для гипотез

Вот 4 надёжных источника:

Логи пользователей – где они останавливаются? уходят? путаются?
Customer interviews – спросите напрямую, что мешает достичь цели
Конкурентный анализ – что тестируют другие игроки рынка?
AI-майнинг – используйте LLM для генерации гипотез на основе данных

💡

Бонус-источник

: фиды A/B-тестов гигантов вроде Booking, Amazon, Spotify. Они постоянно экспериментируют – можно подсматривать :)

🔍 Шаблон SMART-гипотезы

❌

Слабая

: "Сделаем кнопку зелёной – вырастут продажи"

✅

Сильная

: "Если мы изменим цвет кнопки 'Купить' с серого на зелёный, то CTR увеличится на 15% (±5%) для мобильных пользователей, потому что зелёный цвет ассоциируется с действием и лучше выделяется на белом фоне."

Формула SMART:
🔤pecific – что конкретно меняем?
🔤easurable – какую метрику отслеживаем?
🔤ttainable – реалистичный ожидаемый эффект?
🔤elevant – почему это должно сработать?
🔤imed – как долго будем тестировать?

📊 Приоритизация: ICE-фреймворк

Как выбрать из 10 идей 2-3 для тестирования? Используйте ICE-оценку:
🔤mpact – потенциальное влияние (1-10)
🔤onfidence – уверенность в гипотезе (1-10)
🔤ase – простота реализации (1-10)

Пример оценки:
1. Зелёная кнопка: I=4, C=8, E=10 → ICE=320
2. Персонализация рекомендаций: I=9, C=6, E=3 → ICE=162
3. Редизайн целиком: I=10, C=3, E=1 → ICE=30

Стоит начать с №1 – конечно не самый высокий Impact, но быстрее получим результат.

🔄 Построение экспериментального пайплайна

Оч круто выстраивать процесс как конвейер, а не разовые акции:

Backlog → Design → Run → Analyze → Scale/Kill

Backlog: собираем гипотезы постоянно
Design: детализируются метрики, дизайн, расчет выборки
Run: тестируем чисто, без вмешательств
Analyze: оценивается статистика и бизнес-эффект
Scale/Kill: внедряем или документируйте провал

💡

Совет

: держите в работе разные типы тестов одновременно – мелкие/быстрые и крупные/долгие

🚀 Масштабирование победителей

Нашли победителя? Не спешите на 100% аудитории:

1. A/A-проверка – убедитесь, что измерительная система работает корректно
2. Поэтапный rollout: 10% → 30% → 50% → 100%
3. Holdout-группа – можно на время оставить 5% пользователей на старой версии для долгосрочного контроля

⚠️ Типичные анти-паттерны

P-хакинг – досрочная остановка теста, как только увидели "значимый" результат
HARKing – придумывание гипотезы после просмотра результатов
Конфликт экспериментов – одни пользователи в нескольких тестах одновременно
Игнорирование сегментов – эффект может сильно отличаться для разных групп
"Закрытый пробирочный эффект" – работает на тесте, но не в реальном мире

💎 Итоги всей серии:

1️⃣ А/Б-тест – это система, а не случайный выбор
2️⃣ Правильная формулировка гипотез повышает шансы на успех
3️⃣ Приоритизация помогает выбрать тесты с лучшим ROI
4️⃣ Экспериментальный пайплайн превращает отдельные тесты в фабрику улучшений

🟢

Хорошие гипотезы иногда рождаются спонтанно – и это нормально.

Но если вы хотите стабильный рост, добавьте к спонтанности щипотку системности. В итоге ваши A/B-тесты из интересных опытов превратятся в надёжную систему непрерывных улучшений.

#ABtesting@mrtnv_prism #ProductGrowth #AI

@mrtnv_prism

24 мая, Забег.рф

Жара под +30, а мне – норм!

Суббота удалась! Спасибо коллегам за компанию и отличное настроение 🌨

#running@mrtnv_prism

✈️ Telegram и xAI объявили о глобальном партнерстве

Павел Дуров и Илон Маск договорились о сотрудничестве, которое должно кардинально изменить Telegram.
Уже этим летом все миллиард+ пользователей получат доступ к Grok с глубокой интеграцией.

Что обещают для Grok в Telegram:
– Суммаризация чатов, ссылок и файлов
– Помощь в написании сообщений
– Модерация групп и каналов
– Фактчекинг постов
– Создание персональных стикеров

Финансовая составляющая сделки: Telegram получит $300M деньгами и акциями xAI + 50% выручки от подписок, оформленных через мессенджер. За xAI остаются данные взаимодействий пользователей с ИИ.

Звучит уже супер, а потенциал огромный: обещанная интеграция почти точно станет пушкой, но представьте полноценный семантический поиск по чатам, голосовой ввод/вывод в реальном времени и персонального ИИ-секретаря 😍

Пока что доступ к Grok есть через бота [@GrokAI] для подписчиков Telegram Premium – можно тестить

А лето, между прочим, уже через пару дней 🙃

#AI@mrtnv_prism
#Telegram #Grok #xAI

@mrtnv_prism

Microsoft сократил 6000 человек. При этом 20-30% их кода пишет ИИ

Это не совпадение – это новый паттерн в Big Tech. Компании показывают рекордные прибыли и одновременно проводят массовые увольнения

Что происходит прямо сейчас:

🟢Microsoft отчитался о прибыли $25,8 млрд (выше прогнозов) и тут же объявил об увольнении 6000 сотрудников (~3% штата). Сатья Наделла при этом спокойно отмечает: 20-30% кода в компании уже генерирует ИИ.
🟢Booking запустил вторую волну сокращений. Компания объявила о сокращении "сотен" сотрудников, включая лидерские позиции.
🟢Остальные игроки показывают тот же паттерн:
– Meta*: -5% (~3,600 чел.) увольняют "наименее эффективных" сотрудников
– Autodesk: -9% штата при росте выручки
– Hewlett Packard Enterprise (HPE): +16% выручки до $7,9 млрд, но -5% людей (~2500 чел.)
– CrowdStrike: -5% с формулировкой "ИИ трансформирует индустрию"
– Workday: -8.5% (1,750 чел.) – сокращения ради приоритета на ИИ

🔄 Почему рост больше не требует найма
В 2020-2022 деньги были дешёвые (ставка ~0%), был пандемийный бум на digital, и компании нанимали всех подряд. Главное было расти любой ценой.

Сейчас всё изменилось:

– Ставка ФРС 4,25-5,25% = дорогой капитал, инвесторы требуют операционной маржи
– Инвесторы (включая активистов вроде Elliott и Starboard) хотят efficiency, а не growth
– ИИ закрывает рутинные задачи
– Инвестиции идут в GPU-кластеры и AI-инфраструктуру

💡Новая формула успеха:
Раньше (growth): больше людей → больше продуктов → больше выручки
Сейчас (efficiency): умнее ИИ → меньше людей → больше маржи

🎯 Кто в зоне риска и кто останется

Выживают те, кто близок к железу (инфра), к абстракции (архитектура), либо к бизнесу (value ↔ code)

🔴Под угрозой:
– Джуны без уникальных скиллов, которые пока не освоили работу с ИИ-инструментами, I-shape (ИИ пишет шаблонный код лучше)
– Средний менеджмент (отчёты и координацию автоматизируют)
– Специалисты узкого профиля (один домен)

🟢Будут нужны:
– Архитекторы распределённых систем
– ML/AI-инфра инженеры (RAG-пайплайны, оптимизация inference
– Product-инженеры (код + бизнес-контекст)
– Специалисты по безопасности и FinOps

🚀 Что это значит для индустрии
Это не временная оптимизация – это структурная перестройка. Порог входа растёт, джунам будет сложнее найти первую работу. Зарплатные ожидания на старте снизятся. Спрос сместится от количества кода к качеству решений.

Компании внедряют «AI productivity benchmarks» и будут отчитываться, сколько % работы делает ИИ. К 2026 это станет стандартной метрикой.

💀 Memento mori для разработчика

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

Три закона выживания в эпоху ИИ:
1. Не соревнуйся с машиной там, где она уже лучше
2. Стань незаменимым в том, что машина делать не умеет [пока]
3. Если не можешь победить – возглавь

#AI #BigTech
#FutureOfWork@mrtnv_prism

*Meta признана экстремистской организацией и запрещена в РФ

@mrtnv_prism

Архитектура LLM-приложений: ключевые принципы и лучшие практики

В пятницу был на 🥚 True Tech Day и собрал множество ценных инсайтов от крутых экспертов индустрии.
Буду делиться в канале записями и размышлениями с мероприятия 😉

В ближайшие годы решения на базе LLM станут ключевым элементом бизнес-продуктов: от интеллектуальных помощников до персонализированных рекомендаций.
Но только системный подход к архитектуре и взаимодействию с данными позволит превращать эксперименты в надёжные сервисы.

💡 TL;DR

🟢Начните с архитектурной модели: заранее пропишите, как модули LLM будут взаимодействовать с остальными сервисами
🟢 RAG + структурированный вывод: свежие данные + чёткие схемы (Pydantic-контракты) = меньше сюрпризов в ответах
🟢Контроль качества: метрики + Human-in-the-Loop обеспечат предсказуемость и рост
🟢Оркестрация и автоматизация: гибрид «граф вызовов ↔ автономные агенты» снижает издержки и риски
🟢 Безопасность и непрерывное обучение: red-teaming, этические проверки и обновление моделей под запросы рынка

➡️Архитектура

– Классический граф: каждый шаг (код → LLM → инструменты → код) подробно описан.
Система интентов предварительно классифицирует запросы и выбирает оптимальный путь обработки
Отлично подходит, когда важны SLA-гарантии и возможность чёткого аудита

– Автономные агенты: модель сама планирует цепочку действий, вы лишь даёте инструменты
Пока что идеально для быстрых прототипов, но без контроля растут риски

– Гибридный подход (оптимальное решение на данный момент):
→ Внешний оркестратор следит за таймаутами, логированием и переключает между режимами
→ Инструменты обёрнуты в Pydantic-схемы с идемпотентным API

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

➡️Свежие данные без компромиссов (RAG)

– Vector Search для семантических совпадений: позволяет находить близкие по смыслу фрагменты текста, например с помощью FAISS, Pinecone или Milvus.
– BM-25, классический статистический алгоритм для точного поиска фраз
– SQL/графовые базы для сложных отчётов
– Гибридные схемы (Vector Search + BM25/phrase queries + SQL/графовые запросы) повышают полноту (recall) и точность (precision), сохраняя актуальность данных.

Эффект: вы поддерживаете актуальность ответов и снижаете стоимость дорогостоящего файнтюна

➡️Структурированный вывод = спокойный продакт-менеджер

– Обязательное соглашение об ответах: JSON-схемы Pydantic, OpenAPI или GraphQL
– Валидация на уровне сервиса: ошибки формата сразу отсекаются

Эффект: быстрее интегрируетесь с frontend/back-office, меньше «неожиданных» падений в проде

➡️Метрики и Human-in-the-Loop

– Классические метрики: Accuracy, BLEU, ROUGE – сравнивают с эталонными ответами
– Нечёткие сценарии: BERTScore, LLM-eval или оценка экспертов
– Автоматические пороги уверенности переключают задачи на операторов
– Обратная связь → дообучение: фиксируете кейсы-ошибки и регулярно обновляете модель

Цель: выстроить цикл «измерили – проанализировали – улучшили»

➡️Оркестрация и дистилляция

– Шаги для агента: Plan → Execute → Review с критериями остановки и дедупликацией задач
– Дистилляция: большие модели обучают компактные, чтобы экономить на инференсе
– Автоматический роутинг запросов: лёгкие модели для простых запросов, тяжёлые – для глубокого анализа

Эффект: баланс между скоростью и качеством при минимальных затратах

Что делать прямо сейчас

➡️Если вы только начинаете – сфокусируйтесь на RAG + структурированном выводе. Это даст быстрый результат и заложит основу для масштабирования.
➡️Если уже есть MVP – внедряйте метрики качества и Human-in-the-Loop. Разница в надёжности будет заметна через 2-3 месяца.
➡️Планируете production на сотни тысяч запросов – инвестируйте в гибридную архитектуру и дистилляцию. Экономия на инференсе окупит разработку за полгода.

#AI #LLM #DataEngineering

@mrtnv_prism

Классификация LLM: как подобрать модель под задачу

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

Погнали разбираться!

TL;DR

➡️Лицензия – proprietary / open-weight / open-source: бюджет, возможность модификации и юридические риски
➡️Размер – 1 B-400 B+ параметров: компромисс качества и скорости инференса
➡️Контекстное окно – считайте не токены «на бумаге», а реальную эффективность
➡️Модальность – text / vision / audio / video: подбирайте под сценарий
➡️Специализация – универсальная или доменная модель: точность vs универсальность

🔐 Уровень открытости
Proprietary (GPT-4o, Claude, Gemini)
– Доступ только через API
– Высокое качество «из коробки»
– Веса закрыты. Ограниченный файнтюн

Open-weight (Llama 3, Mistral 8×22B)
– Веса доступны для скачивания, можно запускать локально
– Лицензия запрещает Llama 3 для сервисов ≥ 700 млн MAU
– Частичный контроль: архитектура закрыта, но инференс у себя

Open-source (Falcon, BLOOM, Mistral 7B)
– Полная свобода: изменения, коммерциализация, аудит кода
– Сильное комьюнити, быстрые патчи и расширения

Многие называют Llama «

open-source

», но формально это

open-weight:

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

💪 Размер модели
Малые (1–7 B) – можно запускать на ноутбуке; задержка < 100 мс, идеальны для edge и real-time-сценариев.
Средние (13–70 B) – баланс «качество / стоимость»; требуют одного-двух GPU A100/H100; покрывают 80 % production-кейсов.
Гиганты (175 B+) – state-of-the-art; нужны под задачи, где ошибка дороже инфраструктуры (медицина, финансы, R&D).

Аритектурный патерн

Mixture-of-Experts (MoE)

позволяют модели в 8 B параметров вести себя, как классическая 70 B, потому что при каждом запросе включается лишь часть «экспертов». Это резко сокращает требования к памяти и повышает скорость.

🔁 Контекстное окно: заявленное ≠ эффективное
– GPT-4o: заявлено 128 K токенов → эффективно ≈ 64 K
– Claude 3.5: 200 K → ≈ 150 K
– Llama 3: 128 K → ≈ 32 K
Эффективность измеряестя тестами Needle-in-a-Haystack и RULER (2024), где проверяют, находит ли модель «иголку» – факт, спрятанный в длинном документе.

В реальных экспериментах accuracy падает на 30–40 % после ~ 60 % от заявленного окна. Для RAG лучше закладывать запас. Важно: это все эмпирика на опыте :)

🎭 Модальность
Text – классика 90 % задач.
Vision + Text (GPT-4V/o, Claude 3.5 Sonnet, Gemini Pro) – анализ изображений, схем, таблиц; в финтехе заменяют связку «OCR → LLM».
Audio (Whisper-v3, AudioLM) — надёжная транскрипция и генерация речи.
Video (Sora, Lumiere, Google Veo )– уже больше чем R&D. Массового коммерческого внедрения пока нет, но ожидается рост интереса и запуск первых коммерческих сервисов.

🎯 Специализация
Языковая: модели под конкретный язык (Saiga-70B-RU) обычно превосходят универсальные на локальных задачах.
Доменная: Med-PaLM 2, BloombergGPT, CodeLlama-70B обучены на отраслевых корпусах и дают более точные ответы в своей нише.

Например,

для ru-юридических и медицинских кейсов

связка «специализированная модель + RAG» часто дешевле и точнее, чем GPT-4-o без дообучения.

📌 Рекомендации
Стартап / MVP – open-weight 7–13 B; быстрые эксперименты, локальный деплой, квантование до 8-бит.
Enterprise с жёстким compliance – проприетарная модель с SLA или 100 % open-source в своём кластере для контроля данных.
Продукт с миллионами DAU – MoE-архитектура + квантование; оптимизируйте latency и «живое» контекстное окно.

🔮 Взгляд на 2025-2026 гг.
– Контекст >1M токенов станет стандартом к 2026
– Генерация видео выходит в коммерцию уже сейчас
– Ультрамалые модели (<1B) on-device-LLM откроют рынок персональных ассистентов и edge-аналитики без облака

🟢

Рынок LLM растёт экспоненциально: то, что вчера требовало дата-центра, завтра запустится на смартфоне. Не существует «лучшeй» модели в абсолюте – есть задача, бюджет и ограничения.

Выбирайте модель под конкретную задачу и TCO

😉

#LLM #AI #MachineLearning #DataScience
@mrtnv_prism

Open source ≠ “бесплатно и без ограничений”

В прошлых постах обсуждали уровни открытости LLM: proprietary, open-weight и open source. Часто вижу, как путаются в этой теме, поэтому сегодня копнем глубже: что такое open source (глобально), какие бывают лицензии и почему это важно всем нам 🙂

TL;DR

➡️Open source – это не про "бесплатно", а про свободу: запускать, изучать, модифицировать
➡️Есть разница между открытым кодом и настоящим open source
➡️Лицензия решает многое: MIT и Apache дают больше свободы, GPL – больше контроля
➡️Все чаще встречаются гибридные форматы: open-core, source-available, open-weight
➡️Понимайте риски: от supply-chain атак до юридических обязательств

🔐 Что считается настоящим open source?
Если коротко: open source – это когда лицензия разрешает не только читать код, но и
✔️свободно использовать
✔️менять под себя
✔️делиться с другими
✔️даже продавать (при соблюдении условий)

Open Source Initiative (OSI) одобряет лицензии как совместимые с этим определением. Если лицензия не признана OSI – это может быть "source-available", но не open source.

📜 Популярные лицензии и их особенности

MIT / Apache 2.0 – максимально гибкие. Можно использовать даже в закрытых продуктах
GPL – требует, чтобы любые изменения тоже распространялись открыто
AGPL – расширяет GPL на SaaS: если запускаете сервис на базе AGPL-кода, должны открыть все изменения
BSD, MPL, LGPL – промежуточные варианты с разной степенью обязательств

Классический пример путаницы

: Llama 3 – вроде бы «открытая», но лицензионные ограничения не позволяют её использовать в сервисах с аудиторией > 700 млн MAU. Это уже не совсем open source, а open-weight – веса есть, а свободы нет.

⚖️ Зачем бизнесу open source?
Плюсы:
– Прозрачность (можно делать аудит)
– Кастомизация (можно доработать под свои задачи)
– Снижение стоимости владения
– Независимость от вендора
Минусы:
– Нужна своя экспертиза – поддержку придётся выстраивать
– Есть юридические тонкости – нужен review лицензии
– Иногда нет SLA – особенно важно в продакшене

🐧 Linux как пример настоящего open source

Linux начинался как студенческий проект Линуса Торвальдса в 1991 году. "Just a hobby, won't be big and professional" – писал он тогда. Спустя 30+ лет Linux работает на 100% топ-500 суперкомпьютеров мира, большинстве серверов интернета, в каждом Android-смартфоне.
Почему Linux победил? GPL-лицензия создала уникальную экосистему. Компании-конкуренты (IBM, Intel, Google) вкладываются в общий проект, потому что никто не может его "украсть" – все улучшения возвращаются в сообщество. Это win-win: каждый получает надёжную ОС, никто не может монополизировать.
Бизнес-модель вокруг Linux доказала жизнеспособность open source. Red Hat продаёт не Linux, а поддержку и гарантии – и стоит $34 млрд. Canonical, SUSE, множество других компаний зарабатывают на экспертизе, а не на коде.

🟢

Open source

перестал быть "движением энтузиастов".

Это инструмент контроля над технологическим будущим

. Google контролирует мобильный рынок через Android. Microsoft купила GitHub за $7.5 млрд не из любви к опенсорсу.

🟢

Понимать разницу между MIT и GPL, между open source и source-available — это важно.

Даже если вы не пишете код, эти решения влияют на то, какие продукты вы сможете использовать и как

.

📚 Полезное:
➡️ Choosealicense – выбор лицензии за 5 минут
➡️ Open Source Guides – гайды от GitHub
➡️ Software Licenses in Plain English – лицензии простым языком

#OpenSource #TechStrategy #DevTools

@mrtnv_prism

GigaConf 2025

Снова побывал на GigaConf от 🏦– это одно из самых интересных AI-событий года.

🟢Главный вектор: переход от AI-assisted к AI-driven процессам

Сейчас мы на уровне code creation – человек работает, AI помогает и дополняет.
Но дальше этапы, где AI берёт инициативу, а человек лишь валидирует.
А потом и вовсе не участвует.

Уже сегодня строятся агентные системы, где LLM = не просто модель, а полноценный runtime. Они выполняют задачи, управляют пайплайнами и принимают решения.

Вижу, как через 2–3 года это станет стандартом: не просто «AI-помощник в IDE», а автономный контур в продуктах и бизнесе.

Готовлю серию постов: от архитектуры до внедрения и анализа метрик эффективности 😉

#GigaConf2025 #AI #AgentSystems

@mrtnv_prism

Снова ухожу в горы!

Будет интересно – и, скорее всего, непросто…

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

AI и технологии временно оффлайн, включаюсь в режим high altitude runtime 🔥

#ПикЛенина #expeditionlog