История о том, как очередная «быстрая костыль-интеграция» на коленке неожиданно превратилась в почти полноценную Order Management System (OMS) с элементами event-driven архитектуры. Всё это — без предварительного проектирования и без единой строчки кода на Java/Scala/Python (хотя тут немного лукавства, так как пару скриптов на Groovy все-таки имеется), на чистом Apache NiFi и SQLite.

Девизом этого проекта мог бы стать слоган: «Мы не ищем лёгких путей, мы ищем работающие решения». Я инженер в одной ритейл компании, который любит решать задачи, и сегодня расскажу, как закрыл боль бизнеса малой кровью, используя не совсем типичный для веб-сервисов инструмент.

Вот здесь можно посмотреть исходники

Привет, Хабр! Представьте: ваше приложение зависло на минуту. Если это интернет-магазин — пользователь просто перезагрузит. А если это система учёта, связанная с логистикой зерна, — остановится вся цепочка поставки, или клиент уйдёт в офлайн к привычным бумажным документам. В этом и есть главная разница между B2B и B2C.

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

B2B-системы не работают с толпой — они работают с уникальными процессами каждой компании. У одного клиента простое согласование документа, у другого — 15 подписантов по строгой иерархии. Попробуйте втиснуть это в стандартную B2C-логику — провалитесь. Всё это требует не только высокой надёжности каждой операции, но и умения подстроиться под каждого клиента — предоставить ему кастомизацию.

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

На конференции Web 2.0 в 2006 году Marissa Mayer из Google указала на проблему, что дополнительные полсекунды задержки приводили к снижению поискового трафика примерно на 20%. Amazon сообщал о похожем эффекте: каждые дополнительные 100 мс уменьшали продажи примерно на 1%. 

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

Конференция была проведена почти 20 лет назад, компьютерные технологии за это время стали демократичнее, что привело к увеличению количества пользователей и продуктов. Проблема задержек не исчезла — наоборот, она стала острее: чем больше информации накапливают сервисы, тем тяжелее становится её обработка. Чтобы справиться с нагрузкой, приходилось менять архитектурные подходы к хранению и обработке данных. В статье мы разберем один из них – event-driven design.

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

Еще один инструмент для бизнес-аналитика (БА), как когда-то им были MS Visio или Jira. Это фундаментальный сдвиг, который меняет саму суть работы, ценность специалиста и структуру команд.

При про­ектировании RAG-системы инженер каждый раз сталкивается со множеством вопросов: какую базу данных использовать, как организовать получение релевантной информации, да даже выбор эмбеддера может занять приличное время, а это лишь вершина айсберга. Что хорошо работает в одной сфере, например в техподдержке, может полностью провалиться в другой — например, при анализе юридических документов. Поэтому задачей инженера является выявление особенностей предметной области и адаптации RAG системы к ним. Однако, чтобы это сделать, необходимо не только понимать, какие приёмы можно использовать, но и знать насколько они эффективны.

В данной статье мы разберём основные RAG техники, посмотрим их сильные и слабые стороны, сферы применения, а также немного поэкспериментируем. В следующей части статьи мы проведём тестирование этих техник на реальных пользовательских запросах из датасета Natural Questions и оценим качество работы с помощью RAGAS и BertScore, посмотрим на графики и разойдёмся, чтобы обдумать всё написанное. Поэтому предлагаю начать!

Чем только компании не занимаются под видом цифровой трансформации. Разбираем, что это такое и из каких элементов состоит этот процесс.

Первым делом следует определить термин "трансформация". Так вот, четкого определения нет! В генетике, лингвистике, электронике, бизнесе и праве термин определяет разные процессы, но есть одна общая составляющая, которую и возьмем за основу.

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

ZennoPoster и Browser Automation Studio (BAS) - два популярных инструмента для автоматизации веб-браузера. Оба используются для создания ботов, парсеров, спам-скриптов и других утилит, снимающих рутину с пользователя. Но если бы все было так просто и если бы выбор был очевиден - не было бы вокруг сторонников обоих инструментов столько споров.

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

Основной тезис Пикетти звучит так: неравенство — это не баг, а фича, намеренно вшитая в «операционную систему» общества через идеологию и законы. Это прямой аналог того, как кодекс программы определяет её поведение.

API — это не просто техническая прослойка. Это продукт. Его пользователи — другие разработчики. И, как у любого продукта, у него может быть ужасный или превосходный пользовательский опыт. Плохой API — это источник постоянной боли, багов и потраченного времени. Хороший API интуитивно понятен, предсказуем и прощает ошибки. Он становится продолжением мыслей разработчика.

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

Сегодня мы рассмотрим реализацию Outbox паттерна в разных ЯП. Цель простая: одним атомарным действием обновлять бизнес-данные и фиксировать факт события, а затем надежно доставлять его в брокер. Разберем общую схему, конкуренцию воркеров, ретраи, дедупликацию, метрики и покажу, как это собрать на C#, Java, Go, Python и Node.js.

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

Статья из серии "Чем болен средний бизнес? Диагностика и лечение управленческих болезней"

Вы - самый занятой и самый уставший человек в своей компании. Хватит.

Вы - тот самый "пожарный", "нянька" и "арбитр", который лично разруливает каждый затык. А в это время ваш бизнес, как тот воз из басни, тянут в разные стороны. Знакомо?

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

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

Готовы посмотреть правде в глаза и начать строить систему, а не латать дыры?

Первая статья из серии уже ждет вас. Осторожно, может быть больно.

**#бизнеспроцессы #управление #менеджмент #хаос #стартап #дракон

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

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

Чтобы справиться с этим, компании переходят на более гибкие подходы к управлению данными. В этой статье разберем четыре наиболее популярные архитектуры: Data Warehouse, Data Lake, Data Lakehouse и Data Mesh. Обсудим, чем они отличаются и какую выбрать под конкретные задачи.

Продолжам изучать исскуство промптинга. Если советы из первой части статьи были ориентированы, на написание промптов «на лету» то все следующие требуют определенной подготовки и (или) нескольких дополнительных действий. Но они же заметно прокачают качество ответов.

Мой счет за Google API взлетел до €51 из-за контекста LLM. Эта статья раскрывает, почему "память" моделей так дорога, как работает механизм Внимания, и предлагает 5 хаков для управления контекстом. Узнайте, почему будущее за Инженерией Контекста, а не за промптами.

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

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

Бывают разные зависимости у людей, разной степени вредности. Если зависимости от вредных привычек вредят здоровью, то зависимость от плёнки вредит лишь кошельку, — но и здесь можно найти варианты, как сэкономить и получать удовольствие от модного нынче увлечения, не разорившись и не разочаровавшись в нём. Дисклеймер: я точно не специалист в плёночной фотографии, но опыт некоторый имеется.

📝 Описание

Рассматриваем подход Schema Guided Reasoning (SGR) — метод структурированного промптинга, который направляет рассуждения LLM через типизированные схемы и явные рабочие процессы. Также разбираем расширение для пространственного рассуждения — SG² (Schema-Guided Scene-Graph Reasoning), многоагентный фреймворк «рассуждай-пока-извлекаешь» для задач по графам сцены. Подходы демонстрируют прирост точности на 5–10% и достигают 95%+ воспроизводимости, одновременно снижая галлюцинации за счёт валидации схем и программного извлечения фактов.

🔍 Ключевые особенности

• Структурированные выводы: типизированные схемы (JSON Schema / Pydantic) обеспечивают контроль формата и смысла ответа.
• Три паттерна рассуждения: Cascade, Routing, Cycle — для разных типов задач и контроля шага рассуждений.
• Constrained decoding: CFG/grammar-ограничения для безопасной генерации, автоматические повторы при валидации.
• Мультиагентная архитектура SG²: разделение на модуль рассуждений и модуль извлечения с программным доступом к графу.
• Программное извлечение: генерация Python-кода для обхода scene-graph вместо жёстких API.
• Снижение галлюцинаций: разделение контекста и схема-навигация уменьшают отвлечения и ошибочные выводы.
• Совместимость: OpenAI Structured Outputs, Instructor, LangChain, Pydantic AI, локальные бэкенды (xgrammar/Outlines/etc.)

📝 Описание

Рассматриваем подход Schema Guided Reasoning (SGR) — метод структурированного промптинга, который направляет рассуждения LLM через типизированные схемы и явные рабочие процессы. Также разбираем расширение для пространственного рассуждения — SG² (Schema-Guided Scene-Graph Reasoning), многоагентный фреймворк «рассуждай-пока-извлекаешь» для задач по графам сцены. Подходы демонстрируют прирост точности на 5–10% и достигают 95%+ воспроизводимости, одновременно снижая галлюцинации за счёт валидации схем и программного извлечения фактов.

🔍 Ключевые особенности

- Структурированные выводы: типизированные схемы (JSON Schema / Pydantic) обеспечивают контроль формата и смысла ответа.
- Три паттерна рассуждения: Cascade, Routing, Cycle — для разных типов задач и контроля шага рассуждений.
- Constrained decoding: CFG/grammar-ограничения для безопасной генерации, автоматические повторы при валидации.
- Мультиагентная архитектура SG²: разделение на модуль рассуждений и модуль извлечения с программным доступом к графу.
- Программное извлечение: генерация Python-кода для обхода scene-graph вместо жёстких API.
- Снижение галлюцинаций: разделение контекста и схема-навигация уменьшают отвлечения и ошибочные выводы.
- Совместимость: OpenAI Structured Outputs, Instructor, LangChain, Pydantic AI, локальные бэкенды (xgrammar/Outlines/etc.).

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