Анализ и проектирование систем *

Каждая платформа для автоматизации AI‑воркфлоу выглядит убедительно в рамках контролируемого демо. Настоящее испытание начинается тогда, когда вы выводите решение в продакшн и вам нужно доказать регуляторам, что именно сделал ваш AI и почему он принял те или иные решения.

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

Семь платформ для автоматизации AI‑воркфлоу, рассмотренных ниже, представляют разные способы балансировки скорости и надзора. Одни в первую очередь ориентированы на быстроту и простоту запуска. Другие фокусируются на контроле, трассируемости и интеграции с существующей инфраструктурой. Некоторые стараются совместить и то и другое.

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

На самом деле, мы, как ИТ специалисты, так и конечные пользователи довольно сильно привыкли к западным программным решениям за последние несколько десятков лет. Известные вендоры заполонили рынок информационных систем и технологий, начиная от Microsoft, Oracle, SAP, завершая SAS. В голове мелькала мысль: зарубежное, значит качественное и общепризнанное, довольно часто игнорируя тот факт, что есть и наше, отечественное программное обеспечение, в которое нужно инвестировать и которое требуется развивать. Казалось, что западные программные продукты безальтернативны, ведь их внедряют во многие предприятия, в том числе и государственный сектор. Особенно это касалось программных решений SAP, несомненно, линейка продуктов вендора обладает качеством, устойчивостью и масштабируемостью, однако инициативы вокруг SAP в какой-то момент превратились из средства реализации в самоцель. Выпуская программные решения на каждый чих, постоянно обновляя продукты до более совершенных версии, SAP-проекты превратились в успешный бизнес, дающий выгоду не столько конечным пользователям, сколько руководству и компаниям интеграторам. Сейчас же нам предстоит вернуться с небес на землю, вспомнить, что такое кастомная разработка и отечественные программные решения, чтобы занять ту нишу, что оставили за собой, уходя, зарубежные вендоры. В связи с этим, разберемся, что нужно делать для вывода нового программного решения на российский рынок.

Основными документами, описывающими план действий реализации корпоративных целей предприятия служат:

Всем привет! Я — Ольга Матушевич, преподаватель онлайн-магистратуры «Дата-аналитика для бизнеса», а в прошлом наставница на курсе «Аналитик данных» в Яндекс Практикуме. И сегодня я расскажу, чем Copilot может помочь аналитику при создании дашбордов в Power BI: как работающему в компании, только приступившей к использованию BI-системы, так и обладателю обширного legacy.

📊 Знаете, что общего у температуры в городах и валютных курсов? И то, и другое — относительные величины. У вас есть разницы, но нет абсолютных значений.

Можно ли из одних лишь парных котировок вроде EUR/USD или USD/JPY вычислить внутреннюю, абсолютную стоимость каждого доллара, евро или йены? Оказывается, можно — и для этого не нужен волшебный экономический калькулятор.

В этой статье мы делаем то, что звучит как задача для детектива: восстанавливаем абсолютные значения из одних лишь отношений. С помощью чистого Python и метода наименьших квадратов мы превращаем сеть из 85 рыночных котировок в единую шкалу стоимости для 45 валют.

Что вас ждёт:

Матрицы, логарифмы и МНК — как линейная алгебра очищает финансовые данные от шума.

Рабочий код — от построения матрицы инцидентности до ежедневного расчёта.

Фокус с разоблачением — на примере USD/JPY покажем, как понять, что на самом деле движет парой: укрепление доллара или ослабление йены?

Масштабирование до 153 валют — как та же математика работает для всей мировой системы.

Если вы когда-либо задумывались, как устроена «кухня» валютного рынка за пределами парных графиков — эта статья для вас. Переходите, чтобы узнать, как превратить относительность в абсолют.

Мир Enterprise-разработки на Java/Kotlin и мир нейронных сетей кажутся параллельными вселенными. С одной стороны - статическая типизация, многопоточность, Spring-контейнеры, а с другой - Python-скрипты, тензорные операции и эксперименты в Jupyter Notebook. Между ними - пропасть, через которую многие команды не решаются перешагнуть.

Однако необходимость строить этот мост возникает всё чаще. Заказчик хочет «искусственный интеллект» в новом фиче, аналитики мечтают о реализации чат-бота  с преферансом и барышнями, а менеджеры слышали, что конкуренты уже всё автоматизировали. Как же совместить надежность и структуру JVM-проекта с гибкостью и мощью AI? В этой статье постараемся разобраться какие инструменты для этого есть на данный момент и как с ними работать.

Изначально микросервисная архитектура решила реальную проблему - изолировала очереди и убрала “head-of-line blocking”, когда один упавший адресат тормозит всех.

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

В итоге команда объединила 140 сервисов в один монолит, собрала монорепо и стабилизировала тесты через запись/воспроизведение HTTP-трафика.

Ограниченные строгими регуляциями и перегруженные высокими объемами транзакций, требующих быстрой обработки, банки должны обеспечивать надежность и безопасность финансовых операций, какие бы проблемы ни возникали на их пути. Хотя в сложных банковских процессах многое может пойти не так, распределенная архитектура систем современных финансовых институтов добавляет сложности в обработку сбоев. Мы собираемся объяснить, как банки могут эффективно автоматизировать откат транзакций через несколько микросервисов и предоставить реальный пример работы компенсационных событий Camunda в банке.

Бытует мнение, что «кто рано встает, тому Бог подает», а успешные CEO спят по 4 часа и начинают день в 5 утра. Но если вы чувствуете, что ваш мозг оживает только тогда, когда город засыпает, а лучший код пишется между полуночью и пятью утра - возможно, дело не в прокрастинации, а в особенностях работы вашего разума.

Как показывают исследования, ночной образ жизни - это не баг, а фича высокоразвитого интеллекта.

Привет! Эта статья - текстовая версия моего стрима с разбором задачи на бесконечную ленту по System Design из https://t.me/siliconchannel/141 этого поста.

Рассмотрим классическую задачу из System Design интервью - персональная лента подписок. По сути, мы проектируем упрощённый клон Instagram. Сама задача звучит следующим образом:

Цифровую трансформацию на заводах всё чаще начинают с MES, аналитики и BI. На слайдах всё выглядит логично: данные собираются, алгоритмы работают, решения принимаются автоматически.

Но в реальности такие проекты либо не стартуют, либо застревают на пилотах, либо теряют половину функциональности уже по ходу внедрения.

Проблема почти никогда не в платформах и не в подрядчиках.

Проблема в том, что нижний инженерный слой живёт своей жизнью: код PLC написан «как получилось», данные есть, но их невозможно использовать, а любая интеграция превращается в раскопки.

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

Почему так происходит, при чём здесь Greenfield и Brownfield, когда стандарт начинает приносить реальные деньги — в проектах и в ремонтах — и почему начинать стандартизацию нужно именно с PLC-кода, а не с BI, — разбираем на практике.

Время идет и каждая из областей в МЛ развивается, часто сложно уловить особенности и прорывы в каждом домене. Я предлагаю начать разбирать вглубь RecSys и постепенно отвечать на вопросы: что общего со всеми, а что стало доменным.

Вдохновением стал курс от ШАДа 2025 года, буду использовать оттуда множество чудесных картинок.

Объявим главные вопросы, на который нужно дать ответ, для решения задачи ML-ем. А также, основные проблемы в рексисе о которых нужно думать заранее.

Миронов В.О., Кальченко С.Н.

Добрый день, уважаемые хаброгорожане;‑) Крайние тренды по части тестирования современных больших языковых моделей выходят на невиданные высоты и ставится цель: пересматривать не только всю систему анализа моделей, но и саму структуру эволюции нашего подхода к пониманию больших языковых моделей в самом широком контексте. Здесь мы всё больше «скатываемся» к математическому описанию объекта промпта и его понятия. По большому счету, наибольшее понимание, а именно, формирование идей в машинном представлении, основано на геометрическом понимании «форм» слов, а не алгебраическом, в виде векторов, эмбеддингов и матриц, хотя это тоже очень важно на базовом уровне. Отличный пример такого подхода изложен в этой статье, где как раз и показано, что важно, топологическое представление пространства слов и их смыслов, так как оно максимально гибко и позволяет работать с двумя главными понятиями для словоформ: значение и время, в течение которого это значение сохраняется для текущего контекста.

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

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

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

В качестве примера я выбрал развитие электротехнической промышленности и специализированного станкостроения, которые и сегодня входят в наивысшие приоритеты. Будет 3 части: 1) Царская Россия, 2) Советская Россия, 3) Современная Россия.

Сегодня Часть 1: Технологический суверенитет в царской России

1.   Газовое и электрическое освещение

Катализатором развития электротехнической промышленности можно считать развитие освещения.

Этап 1. Газовое освещение (1840-1870-е)

В 1835 году была создана первая российская акционерная газовая компания «Общество для освещения Санкт-Петербурга газом». Основатели ее интересные ребята: механики Рейенбах и Штраус, нотариус Пигасовский, генерал-майор Бетхер – современным языком говоря – эксперты в технологии плюс юридическая и GR-поддержка. Но даже дворцовые связи генерал-майора Бетхера не позволили построить газовый завод на берегу Мойки, недалеко от Дворцовой площади, поскольку вид возводимых заводских стен и труб «оскорбил взор августейших особ» и последовало «высочайшее повеление» о переносе предприятия в Каретную часть города, за Обводной канал. В итоге проект «застрял» на 3 года и смета значительно выросла из-за прокладки дополнительных газовых магистралей, которые пришлось вести вдоль Обуховского проспекта; Общество построило первый газовый завод у Обводного канала в 1839 году и стало заниматься уличным освещением столицы.

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

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

Затем посмотрел на квадрат с другой точки зрения, в силу своей фантазии:

Мы, люди разных национальностей и вероисповеданий по разному воспринимаем порядок вещей и явлений.
К примеру западной формы мышления - размещаем информацию слева направо, сверху вниз.
А в арабском мире (я как то изучал арабскую письменность в детстве) пишут справа налево, но при этом, также сверху вниз.
Так вот, если в таблице 3 на 3 заполнять по порядку 1,2,3... 9 и сравнить с порядком расположения чисел в магическом квадрате возникает ощущение, что заполняемость магического порядка, это некий иной порядок размещения чисел, скажем условно "инопланетянский".

Тогда я решил научится мыслить образно как "инопланетяне" и научится легко заполнять магические квадраты на пустых ячейках. Тем самым научившись логике и порядку - применять эти же знания в повседневной жизни и при разработках скриптов
Вариантов 4 на 4 квадратов было много, и один из самых известных это квадрат Юпитера, размещенный в гравюре Альбрехта Дюрера "Меланхолия".

Всем привет! Меня зовут Кирилл Грищук, я Tech Lead в команде Инфомодели в Авито. Мы занимаемся тем, что обрабатываем формы от пользователей: от 5 млн до 15 млн форм в минуту, а это более 150 тысяч в секунду. 

В этой статье на примере Авито я рассказываю, зачем мы стремимся к SLI 99.99%. Внутри — обзор и сравнение решений по доставке неизменных данных, учитывая специфику нашего сервиса. Показываю на примере форм, какие интересные доработки мы придумали, чтобы достичь этих четырёх девяток, и какие ошибки совершали по пути.

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

Заходишь на Хабр.Карьеру, открываешь вакансии системных аналитиков, а в требованиях всё как обычно: построение информационных систем, понимание архитектуры, ТЗ, BPMN, базовый SQL. Нигде ни слова о знании GPT или умении промптить. Формально профессия как будто не изменилась. 

Тем временем в свежем отчёте OpenAI о корпоративном применении ИИ опубликовали статистику: использование ChatGPT в корпоративной среде за год выросло в 8 раз, а объём запросов от одного человека — в среднем на 30%.

Мы решили выяснить, что происходит в полях, и поговорили с двумя коллегами по цеху: системным архитектором из финтех-продукта и аналитиком с опытом работы и в госсекторе, и в корпоративных продуктах. Спросили их о самом важном: какие задачи быстрее делать с ИИ, где он пока бесполезен и что вообще стоит прокачивать аналитику, чтобы не выпасть из профессии, пока всех грозятся заменить моделями.

Продолжение статьи о разработке стекового процессора с оригинальной архитектурой.
Здесь мы занимаемся инфраструктурой - ассемблером, компилятором С и эмулятором процессора.

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

Эту фразу из "Макбета" Шекспира автор осмелится перевести как "благодаря зуду на кончиках моих пальцев может появиться что-то очень странное".

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

Занесло в сторону процессора с собственной архитектурой. Автор давно неровно дышит в сторону стековых процессоров, здесь так же присутствуют раздельные конвейеры для потоков управления/исполнения и расширяемая упаковка кода.

Надеюсь, это окажется кому-то полезным, так же как когда-то автору был полезен игрушечный hoc из книги Кернигана и Пайка "Unix - программное окружение".

Большая часть литературных источников, посвящённых проектированию информационных систем и использованию информационных технологий, содержит детальное описание графических нотаций по моделированию бизнес-процессов [1-3]. Читая подобные научные работы, возникает вполне закономерный вопрос: выходит, что любой проект внедрения информационной или корпоративной системы требует проектирования бизнес-операций? Так ли это на самом деле? Применим ли этот подход к проектам имплементации ERP-систем? Разберемся в этом вопросе на страницах текущей статьи. Это позволит сэкономить драгоценное время дюжины технических специалистов на проекте.

Вспомним основные моменты проектирования процессов. Под бизнес-архитектурой подразумевается совокупность двух взаимосвязанных составляющих: организационной структуры и бизнес-процессов. Оргструктура бывает линейной, функциональной, дивизионной и матричной, каких-то сложностей с ее моделированием обычно не бывает. Бизнес-процессы описывают в моделях «Как есть» и «Как будет», где последняя характеризует работу компании после внедрения ИТ-решения. Моделирование подразумевает собой последовательную декомпозицию процесса с дальнейшим проектированием операций в той или иной графической нотации. Выделяют нотации верхнего и нижнего уровней, к которым можно отнести ARIS VACD, BCM, IDEF0 и UML AD, BPMN 2.0, ARIS eEPC [1-3].

Все множество методов проектирования процессов можно соотнести с содержимым табл. 1, из которой легко заметить, что последующие графические нотации функционально усиливают предыдущие [4]. В литературе часто пишут, что проектирование элементарных операций ведется на 7-8 уровнях декомпозиции [5], в реальности же 3-5 уровней более чем достаточно.

Привет, Хабр! Меня зовут Евгений Мичурин, я senior BI-разработчик в Авито.

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

Мы решили навести порядок и создали фреймворк автосертификации BI‑отчётов. В этой статье рассказываю, как он работает, какие критерии мы выбрали и как мотивировали команды участвовать в процессе.