Узнайте, как использовать шаблоны элементов и коннекторов в 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], однако в них лишь косвенно указана первопричина формирования концепции, что, следовательно, делает выбор того или иного способа недоказательным.
Для устранения указанных недостатков, в этой статье мы попытаемся вскрыть исходную проблематику, что порождает необходимость формирования стратегии доставки содержания, а также уточним и детализируем способы решения. Следует сразу сделать оговорку, что стратегии доставки содержания, ни в коей мере не противоречат и не заменяют активности фаз внедрения. По существу, они дополняют и максимально их уточняют. Поэтому существование фазы анализа как пример не исключает наличия одноименной стратегии.
Research Vision — приглашение к дискуссии о следующем поколении человеко‑машинного взаимодействия
Уверен в том, что Вас когда‑нибудь раздражало, что ИИ объясняет «слишком подробно», когда нужен один ёмкий абзац?
Или наоборот: вы ждёте системного обзора, а получаете банальный сниппет кода. Эти ситуации знакомы каждому, кто работает с ИИ. Но проблема не в контенте — проблема в несовпадении мышления (как минимум).
Привет, на связи Алексей Дубинец, Павел Беспалов и Глеб Гладков — BI-аналитики Авито. В тексте делимся идеями и промптами для использования локальной LLM в своих повседневных задачах, а ещё расскажем, как настроить инхаус модель в LM-Studio. Статья будет полезна аналитикам разных грейдов, которые сталкиваются с задачами, где нужно собрать, классифицировать и систематизировать большие объёмы информации.
Привет, Хабр!
Меня зовут Софья Петаева, я руковожу отделом системного анализа. Уже почти 10 лет в этой теме, и за это время я научилась не только смотреть на результат работы аналитиков, но и понимать, как они его добиваются. В последнее время мне часто приходится организовывать аналитиков и придумывать новые процессы. Это и помогло мне лучше понять их работу.
В этой статье я расскажу о Discovery-фазе, о том, какие ошибки мы сделали, на каких граблях потанцевали, и как эти уроки до сих пор влияют на нашу работу и принятие решений.
Эту статью хотел бы посвятить некоторым технологиям распределения/балансировки трафика по разрозненным радиолинкам в пределах одной РРЛ.
В предыдущей статье «РРЛ для самых маленьких» https://habr.com/ru/companies/megafon/articles/925514/ я рассказывал о некоторых технологиях и решениях, позволяющих увеличить пропускную способность РРЛ (радиорелейных линий):
- XPIC (Cross-Polarization Interference Cancellation)
- CA (Carrier Aggregation)
- SDB (Super Dual Band)
- или строительство параллельных линков на разных частотах
Использование этих решений позволяет получить РРЛ в конфигурации N+0 (2+0, 4+0, 8+0 или 16+0), где N – это количество независимых радиолинков. Почему независимых? А потому, что эти технологии не занимаются распределением трафика между линками, у них другая задача – организация дополнительных радиолиний ("стволов").
Как обстоят дела с ИИ в реальном мире? Узнайте из опыта Лили Ван, CIO в Barclays, и Бернхарда Шаффрика, главного аналитика Forrester, которые исследуют, как предприятия преодолевают разрыв между инвестициями в ИИ и получаемыми результатами.
Всем привет. Меня зовут Дмитрий Таратута, я руководитель направления аналитики и отчётности в коммерческом блоке НОТА (входит в Холдинг Т1). Мы развиваем B2B‑аналитику, автоматизируем отчётность и поддержку управленческих решений на основе CRM‑платформы НОТА Модус.
В этой статье я расскажу, как мы реализовали дашборды для НОТА Модус, которые стали универсальным инструментом B2B‑аналитики и помогли нам выстроить экспертизу в развитии аналитических решений для продаж.
Всем привет! Я Илья Глазунов, системный аналитик в проекте карточного хранилища T-Pay Online — быстрого способа оплаты для наших клиентов. В качестве БД в проекте хранилища мы используем Apache Cassandra. В статье — обзорный материал, который поможет познакомиться с БД.
В культуре Т-Банка важно, чтобы системные аналитики знали особенности интеграционных схем с другими компонентами, умели строить схемы БД так, чтобы минимизировать издержки, связанные с i/o-операциями. А еще — чтобы могли вычислять узкие места в кейсах и влиять на выбор верхнеуровневого компонента в проекте.
Когда мы выбирали БД для нашего проекта, столкнулись с тем, что существует мало материалов, которые бы сжато передавали главные особенности Apache Cassandra без глобальных неточностей и на русском языке для первичного ознакомления. Поэтому решили помочь тем, кто окажется в таком же положении, что и мы.
Разберем, для чего нужна Cassandra, рассмотрим основные концепции архитектуры, разложим принципы проектирования БД с ее особенностями модели данных и затронем некоторые принципы расчета конфигурирования БД Cassandra.
На днях прочитал об ограблении банка в Бангладеш, которое похоже на голливудский блокбастер. В статье узнаете:
• Как хакеры подделали SWIFT-запросы, не ломая саму систему?
• Зачем им понадобился обычный офисный принтер и что они с ним сделали?
• Кто стоял за атакой?
Мы давно работаем на рынке BI и, как любой зрелый продукт, регулярно сравниваем себя с другими системами, которых с каждым годом появляется всё больше и больше — каждая со своими сильными и слабыми сторонами. И мы решили задать себе простой, но важный вопрос: а чем мы в Luxms BI действительно гордимся? Что нравится не только нам, как разработчикам, но и экспертам, которые делают на нашей платформе десятки проектов? Какие особенности мы сами считаем важными и удобными?
Так появилась эта серия: 23 фичи Luxms BI, которыми мы гордимся. Это не список «всё, что у нас есть», и не подборка базовых возможностей, которые сегодня есть почти в каждом BI-инструменте. Мы собрали то, что нас самих вдохновляет, и то, что мы чаще всего видим в успешных проектах наших клиентов.
Для удобства мы разделили эти фичи на четыре тематических блока. Начнём с первого блока — архитектура и платформенность, с того, на чём держится всё остальное. В этой статье мы расскажем, как устроена платформа Luxms BI, почему мы сделали ставку на датацентричную модель, как устроена быстрая кастомизация интерфейсов, что такое BI-Magic-Resources, и зачем внутри BI-платформы observable-сервисы.
