Современные методы описания функциональных требований к системам (Writing Effective Use Cases) (Рубрика #Software)
Во время подготовки материалов для своего сайта по System Design (https://system-design.space/) наткнулся в своей библиотеке на книгу Алистера Кокберна про написание функциональных требования. Сам Алистер - один из соавторов Agile-манифеста 2001 года, а также один из главных популяризаторов метода вариантов использования (Use Cases) для описания требований. Самой книге в этом году исполнилось 25 лет, поэтому я решил вспомнить про нее, а заодно про эволюцию подходов к описанию требований.
К концу 1990-х варианты использования стали одним из основных способов описания требований к поведению системы. Однако писать действительно хорошие use case было нелегко - требовались чёткие формулировки и логичная структура, как при написании хорошего эссе. Коберн решил эту проблему на практике, выпустив своё руководство по написанию вариантов использования в 2001 году. Книга подробно разъяснила как документировать сценарии: как определить границы системы (scope), описать актёров, их цели и пошаговый ход взаимодействия. Автор включил реальные примеры и сформулировал ряд правил, помогающих создавать понятные и полезные описания. Такой прикладной подход сделал книгу популярной среди инженеров.
На текущий момент индустрия разработки существенно изменилась. С появлением Agile-команд громоздкие спецификации требований уступили место более лёгким артефактам - таким как user stories (пользовательские истории). Формальные же use case многими стали считаться устаревшими. Однако на практике варианты использования до сих пор применяются, особенно в крупных сложных проектах. Их структурированный формат с проработкой логики и исключений даёт разработчикам понятное техническое задание. Подготовка use case более трудоёмка, но впоследствии экономится время на реализации и отладке требований.
Если же говорить про эволюцию подходов, то с момента выхода книги Алистера появились другие, более гибкие методы, ориентированные на работу с требованиями пользователей
1️⃣ User Story
Этот формат зародился в Agile-разработке: требования формулируются кратко от лица пользователя (по шаблону “As a ..., I want ..., so that ...”). User stories акцентируют ценность для пользователя и благодаря простоте быстро завоевали популярность в Agile-разработке.
2️⃣ Jobs to be Done (JTBD)
JTBD - концепция, рассматривающая, какую «работу» пользователь «нанимает» продукт выполнить для решения своей проблемы.
3️⃣ Job Story
Формат job story появился как развитие подхода Jobs to be Done. В job story акцент смещён с образа пользователя на саму задачу и контекст её выполнения. Используется шаблон: “When [ситуация], I want to [действие], so I can [результат].” Такой подход чётко обозначает ситуацию и мотивацию, позволяя сконцентрироваться на решении реальной задачи.
4️⃣ Design Thinking
Design thinking (дизайн-мышление) – человеко-ориентированный творческий процесс решения проблем: через эмпатию и эксперименты команда ищет нестандартные решения, отвечающие потребностям пользователей.
В общем, книга Алистера сейчас уже устарела, но сам подход к написанию use cases полезно знать, особенно как предшественников очередных модных подходов, которые обыгрывают похожие идеи косметически изменяя формулировки:)
#Software #Architect #SystemDesign #SoftwareArchitecture #Processes
Во время подготовки материалов для своего сайта по System Design (https://system-design.space/) наткнулся в своей библиотеке на книгу Алистера Кокберна про написание функциональных требования. Сам Алистер - один из соавторов Agile-манифеста 2001 года, а также один из главных популяризаторов метода вариантов использования (Use Cases) для описания требований. Самой книге в этом году исполнилось 25 лет, поэтому я решил вспомнить про нее, а заодно про эволюцию подходов к описанию требований.
К концу 1990-х варианты использования стали одним из основных способов описания требований к поведению системы. Однако писать действительно хорошие use case было нелегко - требовались чёткие формулировки и логичная структура, как при написании хорошего эссе. Коберн решил эту проблему на практике, выпустив своё руководство по написанию вариантов использования в 2001 году. Книга подробно разъяснила как документировать сценарии: как определить границы системы (scope), описать актёров, их цели и пошаговый ход взаимодействия. Автор включил реальные примеры и сформулировал ряд правил, помогающих создавать понятные и полезные описания. Такой прикладной подход сделал книгу популярной среди инженеров.
На текущий момент индустрия разработки существенно изменилась. С появлением Agile-команд громоздкие спецификации требований уступили место более лёгким артефактам - таким как user stories (пользовательские истории). Формальные же use case многими стали считаться устаревшими. Однако на практике варианты использования до сих пор применяются, особенно в крупных сложных проектах. Их структурированный формат с проработкой логики и исключений даёт разработчикам понятное техническое задание. Подготовка use case более трудоёмка, но впоследствии экономится время на реализации и отладке требований.
Если же говорить про эволюцию подходов, то с момента выхода книги Алистера появились другие, более гибкие методы, ориентированные на работу с требованиями пользователей
1️⃣ User Story
A user story is a short, informal explanation of a software feature, written from the perspective of the end user.
Этот формат зародился в Agile-разработке: требования формулируются кратко от лица пользователя (по шаблону “As a ..., I want ..., so that ...”). User stories акцентируют ценность для пользователя и благодаря простоте быстро завоевали популярность в Agile-разработке.
2️⃣ Jobs to be Done (JTBD)
Jobs to be Done is a framework that helps product teams understand what job a customer is hiring a product to do — what problem, challenge, or opportunity is so important to them that they're willing to hire your product to address it.
JTBD - концепция, рассматривающая, какую «работу» пользователь «нанимает» продукт выполнить для решения своей проблемы.
3️⃣ Job Story
An exciting alternative for some teams is the job story. A job story is focused less on the user performing some function than on the job to be done by that story.
Формат job story появился как развитие подхода Jobs to be Done. В job story акцент смещён с образа пользователя на саму задачу и контекст её выполнения. Используется шаблон: “When [ситуация], I want to [действие], so I can [результат].” Такой подход чётко обозначает ситуацию и мотивацию, позволяя сконцентрироваться на решении реальной задачи.
4️⃣ Design Thinking
Design thinking is a problem-solving approach that focuses on understanding users’ needs and creating innovative solutions.
Design thinking (дизайн-мышление) – человеко-ориентированный творческий процесс решения проблем: через эмпатию и эксперименты команда ищет нестандартные решения, отвечающие потребностям пользователей.
В общем, книга Алистера сейчас уже устарела, но сам подход к написанию use cases полезно знать, особенно как предшественников очередных модных подходов, которые обыгрывают похожие идеи косметически изменяя формулировки:)
#Software #Architect #SystemDesign #SoftwareArchitecture #Processes
❤12🔥6👍5
Дискуссия на T-Sync Conf на тему "AI меняет инженерную культуру — быстрее, чем мы это осознали" (Рубрика #AI)
Конференция T-Sync состоится уже 7 февраля, я там буду на стенде презентовать результаты нашего исследования про влияние AI на SDLC, а также поучаствую в крутой дискуссии на тему инженерной культуры и о том, как AI влияет не только на скорость разработки,но и на мышление, ответственность и подходы инженерных команд. Планируем обсудить следующие темы
- Как меняется роль инженера в эпоху AI,
- Что происходит с качеством решений и инженерной экспертизой,
- Усиливает ли AI культуру или размывает её,
- Какие эффекты мы уже видим в реальных командах — и какие пока игнорируем.
Это разговор не про инструменты, а про людей, практики и инженерную идентичность.
P.S.
Если еще не зарегестрировались на конфу, то самое время
#AI #DevOps #Software #Engineering #Culture #Management #Leadership
Конференция T-Sync состоится уже 7 февраля, я там буду на стенде презентовать результаты нашего исследования про влияние AI на SDLC, а также поучаствую в крутой дискуссии на тему инженерной культуры и о том, как AI влияет не только на скорость разработки,но и на мышление, ответственность и подходы инженерных команд. Планируем обсудить следующие темы
- Как меняется роль инженера в эпоху AI,
- Что происходит с качеством решений и инженерной экспертизой,
- Усиливает ли AI культуру или размывает её,
- Какие эффекты мы уже видим в реальных командах — и какие пока игнорируем.
Это разговор не про инструменты, а про людей, практики и инженерную идентичность.
P.S.
Если еще не зарегестрировались на конфу, то самое время
#AI #DevOps #Software #Engineering #Culture #Management #Leadership
❤6🔥5👏3🏆2
Книжный куб pinned «Сайт по system design (Рубрика #Architecture) Многие мои подписчики знают, что я планировал написать книгу ... но я не уточнял какую. Суть была в том, что я параллельно занимался работой над несколькими книгами. Ближе всего к готовности была книга по System…»
[1/2] Prompt Engineering for LLMs (Рубрика #AI)
Прочитал по большей части на новогодних каникулах популярную книгу про prompt engineering , которая вышла ~2 года назад. В ней Джон Берриман и Альберт Циглер рассказывали о том, как правильно «разговаривать» с большими языковыми моделями (LLMs). Авторов интересно читать, так как они – создатели одного из самых успешных AI-продуктов (GitHub Copilot) и шарят в теме.
В 2024 году тема prompt engineering была горячей, ее много обсуждали и эта книга стала одним из первых гидов - от основ до продвинутых тем, также в ней были готовые шаблоны с примерами кода. Все это сделало книгу ценным пособием для разработчиков. Если говорить подробнее про содержание книги, то она состоит из трех частей
1️⃣ Основы LLM: устройство и эволюция моделей, их обучение и переход к диалогам.
В первой части было 4 главы
1. Introduction to Prompt Engineering - почему LLM выглядят как «магия», краткая эволюция языковых моделей и где в этой картине prompt engineering как инженерная дисциплина.
2. Understanding LLMs - LLM как completion engine: токены/токенизация, автрорегрессия, галлюцинации, temperature/probabilities, основы трансформера; почему порядок текста и «нагрузка» на модель реально влияют на качество.
3. Moving to Chat - переход от completion к chat: RLHF (как он собирается), instruct vs chat, «alignment tax», эволюция API и почему следующая остановка — tools. Идея промптинга как «постановки пьесы» (сцены/роли/реплики).
4. Designing LLM Applications - ключевой фрейм: LLM loop (перевод проблемы пользователя в домен модели → completion → пост‑обработка обратно). Внутри: retrieval → snippetizing → scoring → prompt assembly; где добавляются state, внешний контекст, глубина рассуждений, tools и eval.
2️⃣ Ключевые техники: few-shot примеры, добавление внешних данных (подход Retrieval-Augmented Generation) для снижения галлюцинаций, форматирование длинных запросов
Во второй части было 3 главы
5. Prompt Content - из чего «собирать» промпт: static (инструкции, few-shot + типовые риски) vs dynamic (контекст на лету); RAG (lexical vs neural), эмбеддинги/векторное хранилище; суммаризация (в т.ч. иерархическая) и выбор «общей» vs «под задачу».
6. Assembling the Prompt - как упаковать всё в лимит контекста: «анатомия» промпта, выбор формата документа (advice conversation / analytic report / structured doc), форматирование сниппетов и few-shot, elastic snippets, зависимости между кусками (position/importance/dependency). Плюс важная практика: середина промпта часто “проседает” (условная valley of meh), важное лучше держать ближе к концу.
7. Taming the Model - «анатомия completion»: preamble, узнаваемые start/end, postscript; stop‑sequence/стриминг; logprobs для уверенности/классификации; как выбирать модель (качество/цена/латентность/фичи).
В продолжении я расскажу про продвинутые темы, а также поделюсь своими мыслями насчет актуальности книги в 2026 году.
#AI #DevOps #Software #Engineering #Architecture
Прочитал по большей части на новогодних каникулах популярную книгу про prompt engineering , которая вышла ~2 года назад. В ней Джон Берриман и Альберт Циглер рассказывали о том, как правильно «разговаривать» с большими языковыми моделями (LLMs). Авторов интересно читать, так как они – создатели одного из самых успешных AI-продуктов (GitHub Copilot) и шарят в теме.
В 2024 году тема prompt engineering была горячей, ее много обсуждали и эта книга стала одним из первых гидов - от основ до продвинутых тем, также в ней были готовые шаблоны с примерами кода. Все это сделало книгу ценным пособием для разработчиков. Если говорить подробнее про содержание книги, то она состоит из трех частей
1️⃣ Основы LLM: устройство и эволюция моделей, их обучение и переход к диалогам.
В первой части было 4 главы
1. Introduction to Prompt Engineering - почему LLM выглядят как «магия», краткая эволюция языковых моделей и где в этой картине prompt engineering как инженерная дисциплина.
2. Understanding LLMs - LLM как completion engine: токены/токенизация, автрорегрессия, галлюцинации, temperature/probabilities, основы трансформера; почему порядок текста и «нагрузка» на модель реально влияют на качество.
3. Moving to Chat - переход от completion к chat: RLHF (как он собирается), instruct vs chat, «alignment tax», эволюция API и почему следующая остановка — tools. Идея промптинга как «постановки пьесы» (сцены/роли/реплики).
4. Designing LLM Applications - ключевой фрейм: LLM loop (перевод проблемы пользователя в домен модели → completion → пост‑обработка обратно). Внутри: retrieval → snippetizing → scoring → prompt assembly; где добавляются state, внешний контекст, глубина рассуждений, tools и eval.
2️⃣ Ключевые техники: few-shot примеры, добавление внешних данных (подход Retrieval-Augmented Generation) для снижения галлюцинаций, форматирование длинных запросов
Во второй части было 3 главы
5. Prompt Content - из чего «собирать» промпт: static (инструкции, few-shot + типовые риски) vs dynamic (контекст на лету); RAG (lexical vs neural), эмбеддинги/векторное хранилище; суммаризация (в т.ч. иерархическая) и выбор «общей» vs «под задачу».
6. Assembling the Prompt - как упаковать всё в лимит контекста: «анатомия» промпта, выбор формата документа (advice conversation / analytic report / structured doc), форматирование сниппетов и few-shot, elastic snippets, зависимости между кусками (position/importance/dependency). Плюс важная практика: середина промпта часто “проседает” (условная valley of meh), важное лучше держать ближе к концу.
7. Taming the Model - «анатомия completion»: preamble, узнаваемые start/end, postscript; stop‑sequence/стриминг; logprobs для уверенности/классификации; как выбирать модель (качество/цена/латентность/фичи).
В продолжении я расскажу про продвинутые темы, а также поделюсь своими мыслями насчет актуальности книги в 2026 году.
#AI #DevOps #Software #Engineering #Architecture
❤14🔥7👍5👎2🥱1🥴1
[2/2] Prompt Engineering for LLMs (Рубрика #AI)
Заканчивая рассказ про книгу о промпт инжиниринге надо рассказать про продвинутые темы, а также поделюсь своими мыслями насчет актуальности книги в 2026 году.
3️⃣ Продвинутые темы: разработка чат-агентов с памятью и инструментами (метод ReAct), разбиение сложных задач на шаги (workflows), оценка качества решений моделью.
8. Conversational Agency - tool use в деталях: как проектировать инструменты (имена/аргументы), разруливать ошибки и опасные действия; reasoning‑паттерны (CoT, ReAct и дальше); контекст для task‑диалогов; сборка агента, управление диалогом и UX.
9. LLM Workflows - когда «чат‑агент» не нужен, а нужен workflow: задачи как кирпичики; реализация через шаблонные промпты или tools; усложнение/вариативность; идея «eval начинается на уровне task»; пример end‑to‑end workflow; продвинутые схемы: agent‑driven workflow, stateful task agents, роли/делегирование.
10. Evaluating LLM Applications - что вообще тестируем; offline: example suites, gold standard / functional testing / LLM‑as‑judge, SOMA; online: A/B и метрики.
11. Looking Ahead - куда всё едет: multimodality, UI/UX как часть качества, рост «интеллекта»/скорости/доступности моделей.
В общем, контента в книге много, но возникает вопрос, а насколько он полезен сейчас (в 2026 году). И действительно с момента выхода книги LLM-технологии шагнули вперёд, и некоторые в 2025-м провозгласили «prompt engineering мёртв». Качество моделей выросло – они всё лучше понимают пользователя даже без хитрых подсказок; кроме того, лучшие техники уже встроены в инструменты (готовые шаблоны промптов). В реальных продуктах поведение модели всё чаще определяется системными настройками или fine-tuning’ом, а не текстом пользовательского запроса. В итоге роль "prompt engineer" вскоре слилась с более широкими ролями AI/LLM-разработчиков.
Однако книга не потеряла ценности – её фундаментальные принципы по-прежнему полезны каждому инженеру. Авторы честно предупреждали, что конкретные API могут устареть, но базовые идеи останутся актуальными. Так и вышло: например, подход RAG теперь повсеместно применяют для подключения знаний модели, а техника chain-of-thought стала стандартным приёмом в современных AI-агентах. А в 2025 году Андрей Карпати ввёл термин «контекст-инжиниринг» – фокус на предоставлении модели полного окружения (данные, история, инструменты) вместо подбора идеальной формулировки запроса. Такой подход требует уметь динамически находить и подставлять нужные сведения, ужимать их под контекстное окно, чётко задавать роли (system/user) и подключать внешние инструменты по мере необходимости. Кроме того, появились практики вроде PromptOps – управление промптами (версионирование, мониторинг качества запросов). А некоторые команды уже пытаются полностью автоматизировать подготовку контекста и инструкций (т.н. workflow-подход).
#AI #DevOps #Software #Engineering #Architecture
Заканчивая рассказ про книгу о промпт инжиниринге надо рассказать про продвинутые темы, а также поделюсь своими мыслями насчет актуальности книги в 2026 году.
3️⃣ Продвинутые темы: разработка чат-агентов с памятью и инструментами (метод ReAct), разбиение сложных задач на шаги (workflows), оценка качества решений моделью.
8. Conversational Agency - tool use в деталях: как проектировать инструменты (имена/аргументы), разруливать ошибки и опасные действия; reasoning‑паттерны (CoT, ReAct и дальше); контекст для task‑диалогов; сборка агента, управление диалогом и UX.
9. LLM Workflows - когда «чат‑агент» не нужен, а нужен workflow: задачи как кирпичики; реализация через шаблонные промпты или tools; усложнение/вариативность; идея «eval начинается на уровне task»; пример end‑to‑end workflow; продвинутые схемы: agent‑driven workflow, stateful task agents, роли/делегирование.
10. Evaluating LLM Applications - что вообще тестируем; offline: example suites, gold standard / functional testing / LLM‑as‑judge, SOMA; online: A/B и метрики.
11. Looking Ahead - куда всё едет: multimodality, UI/UX как часть качества, рост «интеллекта»/скорости/доступности моделей.
В общем, контента в книге много, но возникает вопрос, а насколько он полезен сейчас (в 2026 году). И действительно с момента выхода книги LLM-технологии шагнули вперёд, и некоторые в 2025-м провозгласили «prompt engineering мёртв». Качество моделей выросло – они всё лучше понимают пользователя даже без хитрых подсказок; кроме того, лучшие техники уже встроены в инструменты (готовые шаблоны промптов). В реальных продуктах поведение модели всё чаще определяется системными настройками или fine-tuning’ом, а не текстом пользовательского запроса. В итоге роль "prompt engineer" вскоре слилась с более широкими ролями AI/LLM-разработчиков.
Однако книга не потеряла ценности – её фундаментальные принципы по-прежнему полезны каждому инженеру. Авторы честно предупреждали, что конкретные API могут устареть, но базовые идеи останутся актуальными. Так и вышло: например, подход RAG теперь повсеместно применяют для подключения знаний модели, а техника chain-of-thought стала стандартным приёмом в современных AI-агентах. А в 2025 году Андрей Карпати ввёл термин «контекст-инжиниринг» – фокус на предоставлении модели полного окружения (данные, история, инструменты) вместо подбора идеальной формулировки запроса. Такой подход требует уметь динамически находить и подставлять нужные сведения, ужимать их под контекстное окно, чётко задавать роли (system/user) и подключать внешние инструменты по мере необходимости. Кроме того, появились практики вроде PromptOps – управление промптами (версионирование, мониторинг качества запросов). А некоторые команды уже пытаются полностью автоматизировать подготовку контекста и инструкций (т.н. workflow-подход).
#AI #DevOps #Software #Engineering #Architecture
Telegram
Книжный куб
[1/2] Prompt Engineering for LLMs (Рубрика #AI)
Прочитал по большей части на новогодних каникулах популярную книгу про prompt engineering , которая вышла ~2 года назад. В ней Джон Берриман и Альберт Циглер рассказывали о том, как правильно «разговаривать»…
Прочитал по большей части на новогодних каникулах популярную книгу про prompt engineering , которая вышла ~2 года назад. В ней Джон Берриман и Альберт Циглер рассказывали о том, как правильно «разговаривать»…
❤15👍7✍3
CS230 Lecture 2 @ Stanford (Рубрика #AI)
Раньше я уже рассказывал про то, что начал изучать этот курс и посмотрел первую лекцию Andrew Ng. Дальше пришло время второй лекции, которую вел Kian Katanforoosh, со-автор этого курса, CEO и основатель Workera (платформа для оценки AI-навыков), сооснователь deeplearning.ai. Лекция выглядела как "recap про supervised" после изучения лекций с Coursera, но на деле это разбор инженерных рычагов в AI‑проектах: постановка задачи → данные/разметка → архитектура → loss → эксплуатация embeddings. Основные тезисы примерно следующие
1️⃣ Supervised ML решение - это обычный прод‑сервис
- В проде «модель» = архитектура + веса (два артефакта), вокруг которых крутятся пайплайны, метрики и деплой.
- Меняете задачу (binary → multi‑label) - меняется контракт лейблов, loss и метрики. Это не «добавили классы в датасет».
- Capacity: размер модели должен соответствовать сложности + разнообразию данных + compute/latency. Иначе получите красивый dev и боль в реальном трафике.
- Embeddings - когда расстояния в пространстве имеют смысл. Это фундамент поиска, рекомендаций, retrieval/RAG и «переиспользуемых представлений».
2️⃣ Три кейса, где всё решают данные и постановка
1) Определение day/night по картинке: сначала scope (одна камера или «весь мир»? indoor/outdoor? рассвет/закат/полярный день?) → потом сбор данных. Разрешение подбирают через human‑эксперимент: печатаем/показываем людям разное качество и ищем нижнюю границу информативности. Типичный компромисс: ~64×64×3 + небольшая CNN.
2) Работа с триггер словом типа "Алекса"/"Алиса"/"Siri", тут предлагается “activate”: классический паттерн каскада (дешёвое → дорогое): VAD/activity → trigger → ASR/intent. Чтобы не разметить руками бесконечные аудио, делают synthetic data + programmatic labeling: позитивы (“activate”), hard negatives (“deactivate” и похожие), фоновые шумы; скрипт миксует всё в 10‑сек клипы и генерит временные метки. Часто выигрыш даёт не «ещё данных», а правильная схема разметки по времени.
3) Face verification: «сравниваем пиксели» и «классифицируем каждого человека» не масштабируются. Решение - face embeddings + triplet loss (A,P ближе, чем A,N + margin). Дальше один embedding‑слой закрывает сразу три продукта:
- verification: distance < threshold
- identification: nearest neighbor по базе
- clustering: k‑means/agglo
3️⃣ Как масштабироваться без дорогих меток
- Self‑supervised: contrastive (SimCLR‑стиль) - две аугментации одного объекта должны быть ближе, остальные дальше; и next‑token prediction (GPT) - данные «размечают себя».
- Weak supervision: используем естественные пары модальностей (image↔️text, video↔️audio, subtitles↔️video). Отсюда CLIP/ImageBind‑подходы и единые multimodal embedding‑spaces.
Что можно почерпнуть для техлида DL/ML проекта
- Начинайте проект с постановки + распределения + edge‑кейсов, не с выбора модели.
- Ревьюйте свои ML модели как код: labels contract + loss + метрики (и их связь с бизнес‑ценой ошибок).
- Делайте быстрые human‑тесты до траты GPU‑недель.
- Оптимизируйте iteration speed: чуть меньшая модель/разрешение часто быстрее приводит к правильной системе.
- Стройте архитектуру вокруг embedding‑API: «выучили представление один раз → решаем N задач».
- Ищите в домене неразмеченные потоки и слабые связи (логи↔️действия, текст↔️телеметрия) - это топливо для self/weak supervision.
#Software #ML #AI #Engineering #Architecture
Раньше я уже рассказывал про то, что начал изучать этот курс и посмотрел первую лекцию Andrew Ng. Дальше пришло время второй лекции, которую вел Kian Katanforoosh, со-автор этого курса, CEO и основатель Workera (платформа для оценки AI-навыков), сооснователь deeplearning.ai. Лекция выглядела как "recap про supervised" после изучения лекций с Coursera, но на деле это разбор инженерных рычагов в AI‑проектах: постановка задачи → данные/разметка → архитектура → loss → эксплуатация embeddings. Основные тезисы примерно следующие
1️⃣ Supervised ML решение - это обычный прод‑сервис
- В проде «модель» = архитектура + веса (два артефакта), вокруг которых крутятся пайплайны, метрики и деплой.
- Меняете задачу (binary → multi‑label) - меняется контракт лейблов, loss и метрики. Это не «добавили классы в датасет».
- Capacity: размер модели должен соответствовать сложности + разнообразию данных + compute/latency. Иначе получите красивый dev и боль в реальном трафике.
- Embeddings - когда расстояния в пространстве имеют смысл. Это фундамент поиска, рекомендаций, retrieval/RAG и «переиспользуемых представлений».
2️⃣ Три кейса, где всё решают данные и постановка
1) Определение day/night по картинке: сначала scope (одна камера или «весь мир»? indoor/outdoor? рассвет/закат/полярный день?) → потом сбор данных. Разрешение подбирают через human‑эксперимент: печатаем/показываем людям разное качество и ищем нижнюю границу информативности. Типичный компромисс: ~64×64×3 + небольшая CNN.
2) Работа с триггер словом типа "Алекса"/"Алиса"/"Siri", тут предлагается “activate”: классический паттерн каскада (дешёвое → дорогое): VAD/activity → trigger → ASR/intent. Чтобы не разметить руками бесконечные аудио, делают synthetic data + programmatic labeling: позитивы (“activate”), hard negatives (“deactivate” и похожие), фоновые шумы; скрипт миксует всё в 10‑сек клипы и генерит временные метки. Часто выигрыш даёт не «ещё данных», а правильная схема разметки по времени.
3) Face verification: «сравниваем пиксели» и «классифицируем каждого человека» не масштабируются. Решение - face embeddings + triplet loss (A,P ближе, чем A,N + margin). Дальше один embedding‑слой закрывает сразу три продукта:
- verification: distance < threshold
- identification: nearest neighbor по базе
- clustering: k‑means/agglo
3️⃣ Как масштабироваться без дорогих меток
- Self‑supervised: contrastive (SimCLR‑стиль) - две аугментации одного объекта должны быть ближе, остальные дальше; и next‑token prediction (GPT) - данные «размечают себя».
- Weak supervision: используем естественные пары модальностей (image↔️text, video↔️audio, subtitles↔️video). Отсюда CLIP/ImageBind‑подходы и единые multimodal embedding‑spaces.
Что можно почерпнуть для техлида DL/ML проекта
- Начинайте проект с постановки + распределения + edge‑кейсов, не с выбора модели.
- Ревьюйте свои ML модели как код: labels contract + loss + метрики (и их связь с бизнес‑ценой ошибок).
- Делайте быстрые human‑тесты до траты GPU‑недель.
- Оптимизируйте iteration speed: чуть меньшая модель/разрешение часто быстрее приводит к правильной системе.
- Стройте архитектуру вокруг embedding‑API: «выучили представление один раз → решаем N задач».
- Ищите в домене неразмеченные потоки и слабые связи (логи↔️действия, текст↔️телеметрия) - это топливо для self/weak supervision.
#Software #ML #AI #Engineering #Architecture
YouTube
Stanford CS230 | Autumn 2025 | Lecture 2: Supervised, Self-Supervised, & Weakly Supervised Learning
For more information about Stanford’s Artificial Intelligence professional and graduate programs, visit: https://stanford.io/ai
September 30, 2025
This lecture covers key AI concepts through case studies.
To learn more about enrolling in this course, visit:…
September 30, 2025
This lecture covers key AI concepts through case studies.
To learn more about enrolling in this course, visit:…
👍7❤4🔥2
AI Periodic Table Explained: Mapping LLMs, RAG & AI Agent Frameworks (Рубрика #AI)
Посмотрел очередное интересное обучающее видео от Martin Keen из IBM, где он пытается свести AI терминологию в понятную систему. Все из-за того, что у нас куча терминов навроде таких: "агенты", "RAG", "эмбеддинги", "гардрейлы", все эти термины летают вокруг, и от разработчиков ожидается, что они просто знают, как это всё связано, но это далеко не так просто уложить в голове. Для этого Мартин предложил свою структуру для систематизации в виде периодическиой системыМенделеева "AI Periodic Table". У этой таблицы, как ни странно, два измеренияя
Строки (периоды) - этпы
1. Primitives - атомарные блоки (Prompts, Embeddings, LLMs)
2. Compositions - комбинации примитивов (RAG, Vector DBs, Guardrails)
3. Deployment - продакшн-паттерны (Agents, Frameworks, Fine-tuning)
4. Emerging - передний край (Multi-Agent, Thinking Models, Interpretability)
Колонки (семейства)
1. Reactive (реактивные) - изменение входа → радикальное изменение выхода
2. Retrieval (поиск) - хранение и извлечение информации
3. Orchestration (оркестрация) - связывание множества компонентов
4. Validation (валидация) - безопасность и тестирование
5. Models (модели) - стабильные фундаментальные возможности
Если разбирать содержимое таблицы по колонкам, то получится интересно
Reactive Family
- Pr (Prompt) - инструкции для AI
- Fc (Function Calling) - вызов внешних API/инструментов
- Ag (Agent) - цикл думай-действуй-наблюдай
- Ma (Multi-Agent) - коллаборация нескольких AI агентов
Retrieval Family
- Em (Embeddings) - численные представления смысла
- Vx (Vector Database) - хранилище для семантического поиска
- Ft (Fine-tuning) - адаптация к доменным данным
- Sy (Synthetic data) - синтетические данные, на которых сейчас зачастую учатся новые модели
Orchestration Family
- Rg (RAG) - блок про Retrieval Augmented Generation
- Fw (Framework) - платформы вроде LangChain
Validation Family
- Gr (Guardrails) - runtime-фильтры безопасности
- Rt (Red Teaming) - adversarial-тестирование при помощи атакующих red teams
- In (Interpretability) - понимание "почему" модель именно так отрабатывает во время inference
Models Family
- Lg (LLM) - большие языковые модели от OpenAI, Antrhopic, Google, Alibaba, DeepSeek и других
- Mm (Multi-modal) - мультмодальные модели, что позволяют обрабатывать помимо текста изображения, аудио и так далее
- Sm (Small Models) - дистиллированные модели для edge и не только
- Th (Thinking Models) - chain-of-thought встроен в архитектуру новых моделей
Дальше в видео Мартин рассказывает как такая картинка в голове помогает лучше укладывать информацию, а также размышлять про решение задач, связанных с AI в реальном мире. Мне концепция нравится - я сам часто размышляю визуально схемами и эта схема выглядит неплохо и хорошо укладывается в мою голову:))
Плюс мне кажется, что эту схему можно использовать при проектировании и прогонять идеи через призму таблицы. Например, когда кто-то питчит "AI-решение", можно мгновенно декомпозировать его на элементы таблицы:
- Какие элементы используются?
- Какие реакции они запускают?
- Отсутствует ли элемент безопасности (Gr)?
- Нет ли over-engineering в оркестрации?
- Подходит ли Thinking Model там, где хватило бы Small Model?
#AI #DevOps #Software #Engineering #Architecture #SystemDesign
Посмотрел очередное интересное обучающее видео от Martin Keen из IBM, где он пытается свести AI терминологию в понятную систему. Все из-за того, что у нас куча терминов навроде таких: "агенты", "RAG", "эмбеддинги", "гардрейлы", все эти термины летают вокруг, и от разработчиков ожидается, что они просто знают, как это всё связано, но это далеко не так просто уложить в голове. Для этого Мартин предложил свою структуру для систематизации в виде периодическиой системы
Строки (периоды) - этпы
1. Primitives - атомарные блоки (Prompts, Embeddings, LLMs)
2. Compositions - комбинации примитивов (RAG, Vector DBs, Guardrails)
3. Deployment - продакшн-паттерны (Agents, Frameworks, Fine-tuning)
4. Emerging - передний край (Multi-Agent, Thinking Models, Interpretability)
Колонки (семейства)
1. Reactive (реактивные) - изменение входа → радикальное изменение выхода
2. Retrieval (поиск) - хранение и извлечение информации
3. Orchestration (оркестрация) - связывание множества компонентов
4. Validation (валидация) - безопасность и тестирование
5. Models (модели) - стабильные фундаментальные возможности
Если разбирать содержимое таблицы по колонкам, то получится интересно
Reactive Family
- Pr (Prompt) - инструкции для AI
- Fc (Function Calling) - вызов внешних API/инструментов
- Ag (Agent) - цикл думай-действуй-наблюдай
- Ma (Multi-Agent) - коллаборация нескольких AI агентов
Retrieval Family
- Em (Embeddings) - численные представления смысла
- Vx (Vector Database) - хранилище для семантического поиска
- Ft (Fine-tuning) - адаптация к доменным данным
- Sy (Synthetic data) - синтетические данные, на которых сейчас зачастую учатся новые модели
Orchestration Family
- Rg (RAG) - блок про Retrieval Augmented Generation
- Fw (Framework) - платформы вроде LangChain
Validation Family
- Gr (Guardrails) - runtime-фильтры безопасности
- Rt (Red Teaming) - adversarial-тестирование при помощи атакующих red teams
- In (Interpretability) - понимание "почему" модель именно так отрабатывает во время inference
Models Family
- Lg (LLM) - большие языковые модели от OpenAI, Antrhopic, Google, Alibaba, DeepSeek и других
- Mm (Multi-modal) - мультмодальные модели, что позволяют обрабатывать помимо текста изображения, аудио и так далее
- Sm (Small Models) - дистиллированные модели для edge и не только
- Th (Thinking Models) - chain-of-thought встроен в архитектуру новых моделей
Дальше в видео Мартин рассказывает как такая картинка в голове помогает лучше укладывать информацию, а также размышлять про решение задач, связанных с AI в реальном мире. Мне концепция нравится - я сам часто размышляю визуально схемами и эта схема выглядит неплохо и хорошо укладывается в мою голову:))
Плюс мне кажется, что эту схему можно использовать при проектировании и прогонять идеи через призму таблицы. Например, когда кто-то питчит "AI-решение", можно мгновенно декомпозировать его на элементы таблицы:
- Какие элементы используются?
- Какие реакции они запускают?
- Отсутствует ли элемент безопасности (Gr)?
- Нет ли over-engineering в оркестрации?
- Подходит ли Thinking Model там, где хватило бы Small Model?
#AI #DevOps #Software #Engineering #Architecture #SystemDesign
👍15❤5🔥4
ASML Statement on Strengthening Focus on Engineering and Innovation (Рубрика #Engineering)
Вышла интересная новость от ASML, чьи литографы хотят все производители чипов. Так вот ASML внезапно обнаружила, что стала… less agile, процессы усложнились, скорость упала, матричная оргструктура начала мешать инженерии и пора принимать меры.
Если переводить с корпоративного, то можно прочитать это письмо так
- Matrix-структура больше не вывозит - слишком много пересечений, согласований и «непонятно кто владелец результата»
- Хотим product-ориентированную модель - чёткие продуктовые направления, end-to-end ownership, меньше размазанной ответственности
- Processes became “less agile” - для компании, которая живёт на скорости R&D, это почти диагноз.
В итоге, ребята решили сократить лишние уровни менеджмента и уволить 1.7к сотрудников, что я прочитал примерно так "кажется, у нас слишком много людей, которые управляют людьми, которые управляют процессами". Интересно будет дальше посмотреть как пройдет эта трансформация.
#Engineering #Management #Leadership #Software #Processes
Вышла интересная новость от ASML, чьи литографы хотят все производители чипов. Так вот ASML внезапно обнаружила, что стала… less agile, процессы усложнились, скорость упала, матричная оргструктура начала мешать инженерии и пора принимать меры.
Если переводить с корпоративного, то можно прочитать это письмо так
- Matrix-структура больше не вывозит - слишком много пересечений, согласований и «непонятно кто владелец результата»
- Хотим product-ориентированную модель - чёткие продуктовые направления, end-to-end ownership, меньше размазанной ответственности
- Processes became “less agile” - для компании, которая живёт на скорости R&D, это почти диагноз.
В итоге, ребята решили сократить лишние уровни менеджмента и уволить 1.7к сотрудников, что я прочитал примерно так "кажется, у нас слишком много людей, которые управляют людьми, которые управляют процессами". Интересно будет дальше посмотреть как пройдет эта трансформация.
#Engineering #Management #Leadership #Software #Processes
🔥9👍6❤3
Командировка в Питер (Рубрика #Travel)
Сегодня тревел-пост про комадировку в Питер, куда мне нравилось приезжать и раньше. Но в прошлом году у нас открылся новый офис, который подальше от метро, но супер уютный и удобный. Кроме того, в этот приезд нам как часть стратсессии коллеги устроили посещение Эрмитажа, но в закрытом режиме с отдельным гидом и почти пустыми залами и это было бомбически. Я люблю искусство, но я очень не люблю толпы людей, поэтому я редко хожу на большие мероприятия (концерты, популярные музеи и так далее). А тут получилось очень здорово - крутой музей и почти весь наш ... Теперь я и в другие музеи хочу ходить в таком режиме:))
#Travel
Сегодня тревел-пост про комадировку в Питер, куда мне нравилось приезжать и раньше. Но в прошлом году у нас открылся новый офис, который подальше от метро, но супер уютный и удобный. Кроме того, в этот приезд нам как часть стратсессии коллеги устроили посещение Эрмитажа, но в закрытом режиме с отдельным гидом и почти пустыми залами и это было бомбически. Я люблю искусство, но я очень не люблю толпы людей, поэтому я редко хожу на большие мероприятия (концерты, популярные музеи и так далее). А тут получилось очень здорово - крутой музей и почти весь наш ... Теперь я и в другие музеи хочу ходить в таком режиме:))
#Travel
🔥41👍13❤12
Dronescapes (Рубрика #Travel)
У меня в библиотеке есть большое количество красивых книг, которые я люблю иногда лтстать по вечерам, особенно когда устаю от рабочих вопросов днем. Одна из таких книг это "Dronescapes", которая вышла в те времена, когда дроны использовали в основном фотографы и выкладывали их на сайт https://www.dronestagr.am/ (инстаграм для дронов). Я помню, что 10 лет назад, когда я увлекался фото, то очень хотел попробовать квадрокоптеры для фото, но тогда не сложилось, но зато теперь можно, сидя вечером и попивая чай, наслаждаться чужими красивейшими фото:)
#Culture
У меня в библиотеке есть большое количество красивых книг, которые я люблю иногда лтстать по вечерам, особенно когда устаю от рабочих вопросов днем. Одна из таких книг это "Dronescapes", которая вышла в те времена, когда дроны использовали в основном фотографы и выкладывали их на сайт https://www.dronestagr.am/ (инстаграм для дронов). Я помню, что 10 лет назад, когда я увлекался фото, то очень хотел попробовать квадрокоптеры для фото, но тогда не сложилось, но зато теперь можно, сидя вечером и попивая чай, наслаждаться чужими красивейшими фото:)
#Culture
1👍13🔥7❤4🤩1