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

🤖 Turbo ML Conf 2025: агентные системы в проде, "Афанасий" и T-One

Высоту я сбросил – зато теперь снова на волне AI

В субботу был на Turbo MLConf от Т-Банка и особенно зацепил блок LLM Applications & Copilots.
Делюсь ключевыми трендами, которые уже формируют будущее разработки! 🚀

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

Про качество, безопасность и тестирование сгенерированного кода поговорим отдельно – будет не только полезно, но и весело! 😁

Три главных тренда, которые меняют всё:
🔥 Vibe Coding – пользователь описывает итог и ограничения, а ИИ анализирует контекст, подбирает стек, генерирует тестируемый код и сразу предлагает pull‑request.
🧠 Agentic AI – автономные интеллектуальные агенты, способные выполнять комплексные задачи без постоянного контроля со стороны человека. Это уже не вспомогательные инструменты, а полноформатные цифровые коллеги.
⚙️ Context Engineering – искусство создания правильного контекста для LLM. То, как мы формулируем задачу, напрямую определяет глубину и качество получаемого ответа.

Реальные кейсы из продакшена:
– Круто выглядел агент "Афанасий" от Т-Банка – Computer-use агент для саппорта, который уже работает в проде! Он может самостоятельно взаимодействовать с интерфейсами и решать пользовательские проблемы.
– Ребята из Авито рассказали про свою мультиагентскую систему – показали всю кухню от архитектуры до внедрения. Хотя они только начали, уже есть отличные результаты: разобрали, как не перегрузить MCP-сервера, какие модели выбрать и зачем дообучать компактные решения под конкретные задачи.

Безопасность превыше всего:
Отдельный фокус был на защите агентных систем.
Два ключевых направления:
– mTLS для безопасной коммуникации между сервисами
– GuardRails – системы безопасности, которые не дают агентам "сойти с ума" и делать то, что не должны

Релизы от T-Банк:
🚀 T-Pro 2.0 презентовали и выложили прямо в день мероприятия! Новая версия с гибридным reasoning и спекулятивным декодингом. Особенно круто, что делятся не только моделью, но и SFT датасетами для обучения.
📢 T-One – открытая потоковая модель для телефонных каналов. Презентовали на конференции, сегодня выложили в открытый доступ! Заточена под "прелести" телефонии: 8 кГц, помехи, эхо. Всего 70M параметров, но в 2-3 раза лучший WER чем у whisper-large-v3 на телефонных каналах.

🟢

Мы стоим на пороге эры, когда разница между человеком и AI в решении бизнес-задач стирается

.
Главное – научиться правильно проектировать архитектуру и обеспечивать безопасность.

#AI #LLM #AgenticAI #TurboMLConf

🧩 AI Design Patterns: GoF для эры ИИ

Ух, давно не писал – был в режиме deep work 🔥
Сейчас погрузился в Patterns for Modern AI Systems – есть чем поделиться. Поэтому сегодня пост про то, как в AI складывается свой "дизайн-паттернс".

Помните GoF (Gang of Four) и их легендарные Design Patterns 1994 года? 23 шаблона дали разработчикам общий язык и избавили от изобретения велосипеда. Сейчас похожий словарь складывается в AI-разработке.

TL;DR:

➡️

В AI уже сформировались

повторяемые паттерны

– готовые решения для типовых задач

➡️

Пять слоев

: Prompting & Context, Responsible AI, UX-паттерны, AI-Ops, Optimization

➡️

Как GoF для ИИ

: общий словарь, меньше ошибок, быстрее в продакшн

➡️

Думайте об этом как о

"микросервисах для искусственного интеллекта"

О чем этот пост (и о чем не говорим)

Фокус на пользовательских приложениях поверх готовых моделей через API.
Не затрагиваем: тренинг моделей, хостинг, квантование, (мульти)агентные системы – это отдельные большие темы.

Зачем вообще паттерны в AI?

Как когда-то GoF и облачные паттерны (pub/sub, event-driven, serverless) ускорили разработку, так и в ИИ появляются стандартные приёмы.

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

Пять слоев AI-паттернов

➡️Слой 1 – Prompting & Context
"Направь модель и дай ей знать больше"

– Шаблоны промптов с явной ролью, задачей и критериями качества
– Контекст-инжиниринг: RAG, knowledge snippets прямо в запрос
– Ограничения: формат ответа, шаги верификации, примеры

➡️Слой 2 – Responsible AI
"Меньше галлюцинаций, больше доверия"

– Фильтры до/после, факт-чекинг, цитирование источников
– Политики контента и детект запрещённого контента
– Снижение bias и прозрачность: логи решений, объяснимость

➡️Слой 3 – UX-паттерны
"Новые интерфейсы для новых диалогов"

– AI предлагает → человек правит: история изменений, версионность
– Метки неопределённости: источники, уровень уверенности
– Умные кнопки: "уточнить", "расширить", "сжать", "проверить факты"

➡️Слой 4 – AI-Ops
"Как управлять ИИ на масштабе"

– Версионирование промптов и конфигов, A/B тесты, канареечные релизы
– Наблюдаемость: метрики качества, латентности, отказов; алерты
– Отказоустойчивость: фолбэки, ретраи, квоты, умный роутинг

➡️Слой 5 – Optimization
"Баланс качества и цены"

– Умный роутинг на подходящую модель (не все через "самую большую" – GPT5 привет)
– Производительность: кэш, батчинг, стриминг
– Специализированные (под домен) модели там, где это окупается

Почему это важно прямо сейчас

Общий словарь слоев экономит время команд, снижает риски и синхронизирует разработку. С этого фундамента удобно расти в агентные системы и доменные решения.

🟢

Индустрия AI переживает тот же процесс стандартизации, что и веб-разработка 20 лет назад

. Кто освоит паттерны раньше и будет их правильно использовать – получит конкурентное преимущество.

😀😃😄😁😅😂🤣😊
😇🙂🙃😉😌😍🥰😘
😗😙😚😋😛😝😜🤪
🤨🧐🤓😎🤩🥳😏😒

🔗Полезное чтиво на тему: Beyond the Gang of Four: Practical Design Patterns for Modern AI Systems

#AI #DesignPatterns #TechStrategy #Development

🧠 Почему ИИ уверенно фантазирует и что с этим делать

Меня часто спрашивают: «Зачем нам эти LLM, если они периодически несут чушь и все придумывают?».
Вопрос справедливый! Да, модели иногда уверенно фантазируют – и на это есть нормальные причины в данных и в том, как мы их оцениваем

В этом посте разберем, откуда берутся «уверенные промахи» и как простыми инженерными приемами (пороги уверенности, RAG-правила, калибровка, UX/Ops) сделать так, чтобы ошибочных ответов стало заметно меньше, а пользы – больше 🙃

TL;DR

➡️

Модели часто угадывают, когда не уверены — как студент на экзамене с оценкой «правильно/неправильно». А бенчмарки это поощряют...

➡️

Есть класс вопросов, где нет закономерности (типа «дата рождения X»). Если факт встречался в данных 1 раз, ниже которого модель падает трудно – это singleton rate

➡️

Формально: ошибки генерации связаны с ошибками бинарной классификации (Is-It-Valid). Если путаем «валидно/невалидно», галлюцинации неизбежны

➡️

Решение – менять стимулы: не штрафовать “не знаю”, вшивать пороги уверенности и проверять поведенческую калибровку

Где ломается логика

Представим экзамен: за правильный ответ – 1, за пустой – 0. Угадывать выгоднее, чем промолчать. Так же и с LLM: большинство оценок – бинарные, то есть модель отвечает либо «правильно», либо «неправильно». А вариант IDK (I don't know / «я не знаю») не учитывается. Результат: модель учится всегда что-то говорить.

Техническая сторона

- Редукция к классификации. Генерацию можно представить как простую проверку «валидно/невалидно» (Is-It-Valid). И чем чаще система ошибается в такой проверке, тем выше шанс, что в тексте появятся галлюцинации
- Singleton rate (Good–Turing-интуиция). Если заметная доля фактов в корпусе встретилась один раз, то по таким запросам ожидаем сопоставимую долю промахов – база просто не успела «выучить» закономерность
- Пост-тренинг не спасает, если метрика против «IDK». Пока лидерборды награждают «смелые догадки», система будет учиться блефовать.
- RAG ≠ серебряная пуля. Поиск снижает часть ошибок, но как только поиск не дал уверенного сигнала, бинарная оценка снова толкает к «уверенной догадке»

Что с этим делать?

1️⃣ Разрешить «не знаю»
В проде и на внутренних тестах вводим порог уверенности: «Отвечай только если ≥t, иначе — краткое “не знаю/нужен поиск”». И перестаем штрафовать за воздержание. Это резко снижает соблазн «уверенно фантазировать»
2️⃣ Показывать основания
По умолчанию – ссылки/цитаты из RAG. Нет надежных источников, то следуем по правилу – «не знаю». Поиск и рассуждение помогают, но не отменяют стимул угадывать, если оценка настроена неправильно
3️⃣ Мерить правильные метрики
Имеет смысл добавлять поведенческую калибровку: для набора порогов t сравнивать точность среди ответов и долю воздержаний – модель должна последовательно «молчать» ниже порога.
4️⃣ UX-паттерны для честности
Кнопки «проверить факты», «уточнить», бейджи уверенности и явные «источники». Если уверенность низкая – просим подтверждение пользователя (human-in-the-loop)
5️⃣ Ops-практики
Фолбэки на более «надежную» модель/человека при низкой уверенности, ретраи, алерты. Это про процессы, а не только про модель

Немного тонкостей

- Плохая модель vs плохие данные. Ошибки бывают из-за «формы» модели (например, токенизация мешает посчитать буквы) и из-за GIGO (мусор в корпусе)
- Комплексность задач. Есть классы запросов, где «лучше не отвечать» – вычислительно тяжелые/инвертирование шифрования и т. д. и т. п. Это теоретически обосновывается там, что там тоже будет тянуть на ложные догадки
- Калибровка: база vs после RL. Базовые модели обычно честнее в своей уверенности, а пост-тренинг под бинарные метрики уводит в «гиперуверенность» — то самое ощущение «говорит уверенно, но мимо»

Короткая мысль напоследок:

🟢

Галлюцинации – не «прихоть модели», а следствие статистики и наших же метрик.

Перестанем наказывать «не знаю» – модели станут реже «уверенно врать» и чаще вести себя как полезные ассистенты.

🔗Рекомендую почитать: исследование OpenAI –Why language models hallucinate, меня оч вдохновило :)

#AI #LLM #AITrust #TechStrategy

Интернет шутит мемами про «вечный генератор денег», но история куда глубже

Пара мыслей:

1️⃣ Compute становится новой энергией XXI века. 10 гигаватт – это масштаб национальных энергосистем, теперь перенесённый в ИИ-датасентры.

2️⃣ $100B от NVIDIA в OpenAI — не про деньги сами по себе, а про закрепление вертикальной интеграции: от GPU → до облаков → до AGI.

3️⃣ 2026 год, запуск Vera Rubin – точка отсчета следующего уровня конкуренции: кто контролирует вычислительные фабрики, тот контролирует темпы прогресса.

А мемы все равно хороши 😁

🤖 From Prompts to Context: почему это важно для AI-агентов

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

Кстати, еще в июле я упоминал Context Engineering как один из ключевых трендов 2025 – и вот сейчас самое время разобрать его подробнее.

TL;DR

➡️Контекст-инжиниринг – это эволюция промпт-инжиниринга: управление всем набором токенов (инструкции, инструменты, история, данные), а не только текстом промпта
➡️У LLM есть "бюджет внимания" – чем больше токенов, тем хуже модель извлекает информацию (context rot). Контекст = конечный ресурс
➡️Эффективный контекст – это минимальный набор токенов с высокой информационной ценностью. Системные промпты должны быть на оптимальном кровне абстракции
➡️ Агентский поиск: вместо загрузки всех данных заранее, агенты используют "just-in-time" стратегию – динамическая загрузка через инструменты

Почему контекст-инжиниринг критичен
Раньше промпт-инжиниринг работал для one-shot задач – классификация, генерация текста. Но современные агенты работают в циклах, на длинных горизонтах, накапливая все больше данных. И тут появляется проблема: context rot – чем больше токенов в окне контекста, тем хуже модель достает нужную информацию.
Исследования и здравый смыслпоказывают: модели теряют точность при росте контекста (некоторые деградируют плавнее). Причина – в архитектуре трансформеров: каждый токен "смотрит" на все остальные, создавая n² связей. Чем больше n, тем меньше внимания приходится на каждый отдельный токен. Плюс модели обучались на коротких последовательностях – у них меньше опыта с длинным контекстом.

Анатомия эффективного контекста

Задача:

найти минимальный набор токенов с высокой информативностью

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

1️⃣Системные промпты: "оптимальный уровень абстракции"
Есть две крайности: хардкодить хрупкую логику (if-else в промптах) или писать размытые инструкции. Золотая середина: достаточно конкретно для направления, но гибко для эвристик. Структурируйте промпт (JSON/XML-блоки, Markdown-заголовки), но делайте его минимальным и достаточным.
2️⃣ Инструменты: эффективность и четкость
Инструменты – контракт между агентом и средой. Они должны возвращать токен-эффективные результаты и поощрять эффективное поведение.
Классическая проблема: раздутый набор инструментов с перекрытием функций. Если человек не может точно сказать, какой инструмент использовать, агент тоже не сможет (пока что)
3️⃣ Примеры: качество > количество
Few-shot промптинг работает, но не стоит учитывать все edge-случаи. Лаконичный набор разнообразных
канонических примеров – вот что нужно. Для LLM пример = образ желаемого результата.

Агентский поиск и "just-in-time" контекст
Старый подход: embedding-based retrieval до инференса – достать все заранее.
Новый тренд: "just-in-time" – агенты хранят легкие идентификаторы (пути к файлам, ссылки, запросы) и динамически загружают данные в runtime через инструменты.

Claude Code

анализирует большие базы данных, не загружая их в контекст

– пишет целевые запросы, сохраняет результаты, использует bash-команды.

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

🟢

Контекст-инжиниринг – это не про идеальный промпт, а про вдумчивую курацию информации на каждом шаге. Ключевой принцип:

контекст – драгоценный, конечный ресурс.

🟢

Во второй части разберем техники для долгих задач

: компакцию, агентскую память и мульти-агентские архитектуры

🔗 Рекомендую почитать: оригинальный пост Anthropic Effective context engineering for AI agents

#AI #LLM #Agents #ContextEngineering #TechStrategy