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

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

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

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

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

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

В качестве примера я выбрал развитие электротехнической промышленности и специализированного станкостроения, которые и сегодня входят в наивысшие приоритеты. Будет 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‑отчётов. В этой статье рассказываю, как он работает, какие критерии мы выбрали и как мотивировали команды участвовать в процессе.

Теневой рынок киберпреступности не страдает от корпоративной бюрократии и не пытается продать клиенту «ощущение безопасности». Он построен на принципах экстремальной эффективности, где каждый участник от разработчика эксплойта до оператора ботнета мотивирован только конечной прибылью. В то время как легальная индустрия ИБ усложняет защиту.

Вендор приходит с решением. SIEM-система, которая сама разберётся в хаосе. Покупают. Система требует полгода на настройку правил корреляции. Нанимают консультантов. Консультанты уходят через три месяца, оставив конфигурацию, которую никто не понимает. Система продолжает работать. Генерирует отчёты. Отчёты никто не читает, потому что они написаны на языке, понятном только тем консультантам.
Индустрия продаёт не защиту. Она продаёт ощущение, что вы что-то делаете. Разница огромная.

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

Одна из таких стратегий - арбитраж ставок финансирования (funding rate arbitrage). Это безопасная стратегия с небольшим количеством рисков, которая доступна каждому. Из навыков тут при наличии автоматической системы тут нужно лишь умение открывать позиции на разных биржах.

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

Здравствуйте, меня зовут Дмитрий Карловский и я... серийный убийца устоявшихся стандартов. Сегодня я выследил и нанёс критический урон UTF-8. И сейчас я расскажу, как я его переиграл и уничтожил новым стандартом кодирования текста — Unicode Compact Format.

Для начала — немного контекста. Я не программист и не разработчик. Последние 12 лет я проработал в Федеральной налоговой службе. Начинал с низов, занимался выездными и камеральными проверками (проводил лично и курировал). Два месяца назад я уволился, завел свой телеграм‑канал и теперь работаю в налоговом консалтинге.

Эта статья — история о том, как я попытался решить огромную проблему государственной системы с помощью домашнего ноутбука и нейросетей. О том, как я переоценил свои силы, недооценил масштаб задачи, но все‑таки попробовал создать инструмент, который мог бы изменить работу инспектора.

Привет, Хабр!

ИТ-проекты – это далеко не только создание новых систем с нуля. Существенная часть специалистов занята поддержкой и сопровождением действующих систем. А когда в состав ИТ-системы добавляется новое ПО (или заменяется какой-то из её компонентов), актуальной задачей является перенос архивных данных и настройка взаимодействия нового софта с окружающим ландшафтом. При этом задачей-максимум является добавление новых свойств для системы, улучшающих пользовательский опыт или процессы администрирования и сопровождения. Ниже я расскажу, как мы провели классификацию объектов информационной модели при интеграции действующей системы расчета производственных показателей с внешней, вновь создаваемой системой управления НСИ.

После моей статьи про АИС «Налог-3» (как одну из самых мощных государственных IT-систем России) в комментариях больше всего спорили не про масштабы данных и вопроса, «видит ли ФНС всё». Основной скепсис вызвал мой тезис о необходимости внедрения больших языковых моделей (LLM) в работу налоговых органов.

Основной аргумент в противовес моей позиции звучал так: «Зачем там нужен Искусственный Интеллект? Всё формализовано, достаточно жестких алгоритмов и грамотных шаблонов. Экспертная система справится сама, не надо усложнять».

В этой статье я постараюсь привнести ясность в то, как происходит сбор доказательственной базы по налоговым правонарушениям и как формируется итоговый документ (акт и решение по налоговой проверки). Потому что в реальной налоговой проверке проблема не в том, чтобы найти риск или подсветить признаки. Это АИС «Налог-3» уже умеет делать достаточно хорошо. Проблема в другом - превратить массив фактов в доказательства и выводы, а затем изложить это в юридически выверенном тексте, который выдержит спор сначала на стадии возражений, потом в вышестоящем налоговом органе, а при необходимости и в суде.

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

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

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

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

Статья поделена на три части.

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

Статья техническая и адресована инженерам-программистам в тестировании (SDET) и инженерам по автоматизации тестирования, которые перешли от написания обособленных тестов к осознанному проектированию тестового фреймворка или только начинают этот переход.

Недавно снова услышал вайб: да все эти принципы это только направление и их можно не придерживаться. И таких людей не переубедишь. Приводи им примеры или нет - свой опыт им не передашь. Да и слушать у нас как-то стало не модно. У нас же все теперь гибко и как договоритесь. И требовать каких-то стандартов отрасли - это уже абьюз…

Интеграционные тесты тормозят и не нужны, линтер можно и не использовать. Нарушение архитектурных принципов - так мы ж делаем MVP - зачем оно нам?

Я в корне не согласен с таким подходом и буду это разбирать на примере SOLID и перфораторной дрели...

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

Здесь про архитектуры, GRPO и про то, почему бенчмарки больше ничего не значат.

Дальше — слово автору.

За последнее десятилетие Федеральная налоговая служба (ФНС) совершила фундаментальный переход от традиционной модели администрирования к подходу, основанному на анализе больших баз данных.

Если вы соприкасались с налоговой системой - проходили проверки, бывали на комиссиях в инспекциях, общались с налоговыми органами, то вы слышали про АИС «Налог-3», одну из самых масштабных государственных IT-платформ в России.

Я проработал в системе налоговых органов 12 лет - от рядового инспектора в ИФНС до заместителя начальника отдела проведения налоговых проверок Управления ФНС - и наблюдал эту трансформацию изнутри. В этой статье я хочу показать, насколько эта система действительно мощная, как она эволюционировала, что она реально умеет сегодня и почему, несмотря на весь объём данных, это пока не «искусственный интеллект, который всё делает сам»

Сразу обозначу границу: я не раскрываю никакой служебной информации. Всё, о чём в статье пойдёт речь, это обобщение моего опыта работы в службе и данные, которые размещены в открытом доступе. Из налоговых органов я ушёл относительно недавно (2 месяца назад), и за это время мало, что могло поменяться, поэтому информация все еще остается актуальной.