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

Когда речь заходит о языковых моделях (LLM), большинство представляет себе инструмент для генерации текста или изображения по запросу. Эта функция действительно стала визитной карточкой технологий вроде ChatGPT. Однако существует менее известная, но не менее важная функция: преобразование текста в числовые векторы (эмбеддинги).

Меня зовут Вадим Скляров, и я бизнес-аналитик в MWS. Казалось бы, тема векторизации текстов сугубо техническая, зачем мне в нее погружаться? Ответ прост: чтобы понимать возможности и ограничения работы с векторными представлениями и задавать правильные вопросы заказчику, не обещать того, чего сделать не получится. Плюс это помогает точнее оценить сроки и стоимость проекта.

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

Привет всем, я Дмитрий Кислов, системный аналитик-технолог в ПСБ. Отвечаю за создание новых и доработку существующих продуктов для клиентов малого и среднего бизнеса.

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

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

Сегодня расскажу историю о том, как мы еще в 2017 году решили поменять инфраструктурную платформу. Мы расшифровали мой доклад с DevOpsConf21, много всего уточнили, переписали и дополнили с учетом опыта следующих четырех лет, прошедших после того выступления. 

8 лет назад у нас было 40 сред, 15 разработчиков, 2 монолита, 10 сервисов и свое железо в трех серверных стойках. С такими исходными данными мы решили перейти с Puppet на Ansible. Окружений много, потому что с 2010-го мы поставляли разработчикам и тестировщикам маленькие копии нашего приложения — это делало задачу еще интереснее.

Путь был непростой. О нем расскажу в хронологическом порядке, не забывая о косяках и ошибках. По ходу повествования я выделил инсайты, которые могли бы сильно помочь мне в прошлом. В конце оформил их в виде письма для себя образца 2017-го 🙂.  А если вы решитесь проделать нечто столь же безумное (ну там, не знаю, переехать с микросервисов на монолит, с linux на windows и так далее), надеюсь, мои заметки уберегут вас от сложностей, с которыми мы столкнулись.

Микросервисная архитектура при построении приложений в последние годы пользуется большой популярностью среди разработчиков. Всевозможные веб-приложения активно используют данную архитектуру. Но почему бы не попробовать использовать эту архитектуру при работе с 1С?

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

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

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

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

Недавно ко мне обратилась команда дизайна с вопросом о том, как оценить удовлетворенность пользователей новым внешним видом Студии RUTUBE для авторов. 

Существует много известных методологий оценки удобства использования веб-сайтов и приложений (UMUX, SUS и т.д.). Есть также комплексные метрики, где оценка внешнего вида является одним из измеряемых критериев (например, SUPR-Q). Но широко применимых методологий для оценивания именно визуальных характеристик интерфейса, которые подходили бы под наши задачи, нет.

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

Бизнес-требования на автоматизацию и их связь с корпоративной архитектурой организации

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

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

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

Приветствую всех! С вами старший системный аналитик, эксперт онлайн-школы по системному анализу Ольги Пономарёвой System Analyst. Статья основана на практическом опыте, в нашей школе мы не просто даем теорию, а любим делиться тем, что действительно работает на проектах.

Разбор legacy-системы без документации кажется сложной задачей. Но это возможно с правильным подходом и современными инструментами. Это руководство даст вам план действий, практические методы и покажет, как использовать ИИ для ускорения работы.

Привет! Это команда курса «Аналитик данных». Мы подготовили подборку материалов для тех, кто делает первые шаги в мире анализа данных и хочет освоить исследовательский анализ данных с нуля.

Разведочный или исследовательский анализ данных (Exploratory Data Analysis, EDA) — это этап работы с данными, на котором аналитик изучает доступную информацию перед построением сложных аналитических моделей. Это основа работы с данными, которая помогает понять, какая информация доступна и возникнут ли трудности с будущим анализом.

Узнайте, как использовать шаблоны элементов и коннекторов в Camunda, чтобы быстро создавать эффективные, стандартизированные и многократно используемые процессы.

Не так давно OpenAI анонсировала Instant Checkout и затем опубликовала Agentic Commerce Protocol — два важных изменения, которые могут качественно повлиять на то, как будет выглядеть еком в ближайшие несколько лет. А может и нет.

Однажды в интервью продуктологов OpenAI я прочитал важную мысль про подход к запуску новых продуктов — «мы трясем яблоню и смотрим что упадет». Можно любить OpenAI и не любить, любить LLMки и нет (лучше — любить), но все, что делает OpenAI неизбежно долгосрочно оказывает влияние на всю индустрию, поэтому совсем пройти мимо такого интересного события — не хотелось.

И как говорил мой англоговорящий друг: «Is that just hype, low hanging fruit, or a real game changer?» (хороший вопрос, кстати).

Попробуем разобраться что внутри и куда движет еком, сравнив в том числе с тем, что делает Google.

ИИ-планировщик отправил туристов в несуществующий каньон. Разбираем, почему нейросети опасны для путешественников

Недавно BBC опубликовала статью о том, как туристы, доверившись нейросети, оказываются в несуществующих местах.

Кейс №1: «Священный каньон» в Перу

Гид из Перу Мигель Анхель Гонгора Меса столкнулся с туристами, которые собирались в одиночный поход к «Священному каньону Умантай». Проблема в том, что такого места не существует. Нейросеть просто скомбинировала названия двух реальных локаций и сгенерировала красивое, но абсолютно фейковое описание. Туристы потратили $160, чтобы добраться до глухой дороги в горах без связи, гида и понимания, что делать дальше. На высоте 4000 метров такая «галлюцинация» ИИ могла закончиться трагически.

Кейс №2: Застрявшие на горе в Японии

Другая пара использовала ChatGPT для похода на гору Мисэн в Японии. ИИ уверенно сообщил, что последняя канатная дорога вниз работает до 17:30. В реальности она закрылась раньше, и туристы застряли на вершине горы после заката.

Таких историй становится все больше: от Эйфелевой башни в Пекине до невыполнимых марафонских маршрутов. Почему так происходит?

Суть проблемы — «галлюцинации» LLM

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

Сами разработчики, включая главу Google Сундара Пичаи, признают, что галлюцинации — это, похоже, врожденная и неустранимая особенность таких систем.

Что в итоге?

Полагаться на ИИ в путешествиях можно, но с большой осторожностью. Золотое правило: если совет от нейросети кажется слишком хорошим, чтобы быть правдой, — скорее всего, так и есть. Каждое название, время работы и маршрут нужно перепроверять по надежным источникам. Иначе рискуете оказаться героем похожей истории.

LLM - мощный инструмент, но его эффективность в продакшене зависит не от одного «хитрого промпта», а от всей архитектуры: что мы даём модели, как управляем её рассуждением и как проверяем/обрабатываем результат. В этой статье - компактная карта паттернов, разбитая по этапам конвейера: Input -> Reasoning -> Output.

Технический вкус — это не то же самое, что технический навык. Вы можете быть технически подкованы, но иметь плохой технический вкус и наоборот. Как и любой вкус в принципе, технический вкус зачастую не зависит от наличия фактического навыка. Вы же можете отличить хорошую еду от плохой, не умея готовить? То же самое с ПО — вы вполне способны понять, нравится ли оно вам, не имея возможности его создать. И если технические навыки можно наработать через усердное изучение и повторение, то хороший вкус вырабатывается менее очевидным путём.

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

TL;DR: Оказалось проще формализовать и реализовать с нуля свой потокобезопасный движок формул Excel, чем оптимизировать уже готовый мутабельный движок epplus. Хотя позже я реализовал более простой в кодировании вариант, но гораздо более сложный с точки зрения архитектуры.

Контекст-карта — это не просто схема, а сюжет: есть акторы, сцена, цель, взаимодействия, ограничения.

Формула-ядро:
Когда [Актор] в [Сцене] хочет [Цель], он взаимодействует с [Актор/Система] через [Интерфейс/Событие], соблюдая [Ограничение].
Как из истории нарисовать диаграмму:
1. ...
2. Глаголы и объекты → связи / поток

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

Следующий этап эволюцииИИ — агентные системы. Что это и почему это важно для вашего бизнеса?

2025 год называют «годом AI‑агентов», но что это на самом деле? Большинство путает их с продвинутыми чат‑ботами или RAG‑системами. Однако настоящий агентный ИИ — это следующий шаг: система, которая не просто отвечает на вопросы, а самостоятельно анализирует, планирует и действует для достижения цели.

В своей новой статье я сделал выжимку из материала военного журнала Small Wars Journal, где эта концепция раскрывается на примере современной армии. Они называют это «доминированием в принятии решений».

Что внутри:

Четкое разделение: где хайп, а где реальность агентного ИИ в 2025 году.

Таблица, показывающая, как агентные системы меняют 4 ключевых этапа управления: Понимание, Визуализация, Направление и Оценка.

Практический чек-лист для оценки готовности вашей компании к технологиям завтрашнего дня.

Привет! В этой статье я детально разберу основные фреймворки для AI-агентов, попробую их побенчить и детально распишу их плюсы и минусы. Если вы подступались к агентам, то первым вопросом наверняка стало «а на чем их делать?». Отовсюду все говорят про langchain и десяток других фреймворков, звучат аббревиатуры типа MCP и A2A, какие-то Swarmы и CrewAI, мультиагентность и самое всякое разное.

Давайте попробуем все это разложить по полочкам, потестировать, замерить и собрать материал, который поможет за раз во всем разобраться. А в качестве задачи мы возьмем мой проектик, который я с удовольствием поделываю в качестве развлекухи по ночам: сложный выбор товаров на маркетплейсах LLMкой.

Что будем тестировать: LangChain, LangGraph, AutoGen, CrewAI, OpenAI Swarm, LlamaIndex, MetaGPT, ControlFlow, Haystack, Phidata, Pydantic AI, smolagents, DSPy, SuperAGI, Semantic Kernel, Claude Agent SDK

Стратегия является ключевым документом, описывающим предполагаемый подход к решению той или иной задачи. В области внедрения ERP-систем выделяют такие концепции доставки содержания, как: анализа, проектирование, реализация, ролей и полномочий, миграции, обучения, тестирования, технической подготовки системы, бизнес-катовера, изменений и поддержки. Основой использования стратегий в проектах имплементации ERP-систем служит теория корпоративных информационных систем, предложенная в работе [1]. Анализ литературных источников в области корпоративных информационных систем и стратегий доставки включает множество работ [2-14], однако в них лишь косвенно указана первопричина формирования концепции, что, следовательно, делает выбор того или иного способа недоказательным.

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