Проблема Zero Shot не в том, что он не умеет читать закон. Проблема в том, что закон нельзя честно превратить в требования одним действием. Всё, что скрыто между нормой и системой, модель слишком легко маскирует красивым ответом.
Разберём подробнее, как ZS выплёскивает с водой ребёнка:
Всем привет. Да мы снова про Excel и да мы уверены что более совершенного инструмента для первичной обработки информации нет ( и возможно не будет). Мы не ставим себе цель убедить вас отказаться от любимого табличного редактора, и стать адептом других дата инструментов. В этой статье обсудим всего лишь одну задачу — это что делать , когда нужно перенести прототип (или живую модель) дата приложения созданного в Excel VBA и Power Query в другую систему — это может быть как BI, так и Ms Access или другой инструмент из семейства LowCode | NoCode. А вдруг вы занимаетесь импортозамещением, то миграция на Р7 офис / Мой Офис / … наверняка стало вашей головной болью.
В 2018 году мы начали разрабатывать CRM-систему, заточенную под сеть СТО. Разработка была масштабна, а цели — амбициозны: мы стремились учесть потребности всех участников процесса. Над проектом работали аналитики, программисты, тестировщики, настройщики Битрикс, дизайнеры и др. специалисты. Кроме того, работа продолжалась и после сдачи проекта. Я сейчас не только о поддержке системы — мы продолжали непрерывно улучшать ее, добавляли новые фичи, оптимизировали процессы.
И всё же, начав «за здравие», через 5 лет, в 2022 году, мы с заказчиком подошли к финалу известной поговорки. Эта статья про то, почему так получилось и какие уроки мы извлекли из этой истории.
Меня зовут Алексей Постригайло. Моя компания специализируется на системной интеграции и имеет 20-летний опыт реализации крупных проектов. В своих статьях я рассказываю о «закулисах» наших проектов.
Роли аналитиков в IT-компаниях давно вышли за рамки простых классификаций. Если раньше можно было уверенно разделить бизнес-аналитиков, фокусирующихся на требованиях заказчика, и системных аналитиков, отвечающих за техническую реализацию, то сегодня рынок диктует универсальность. Российские вакансии на том же hh.ru полны требований, где BPMN соседствует с SQL-оконными функциями, а знание REST API - с ГОСТами. И это не прихоть рекрутеров, а реальность цифровизации, импортозамещения и дефицита кадров.
Просматривая содержание курсов для аналитиков 1С, я заметил любопытную закономерность. Везде учат рисовать схемы бизнес-процессов. Но нигде не учат помещать в них ключевого участника — Систему. Ту самую учетную программу, ради демонстрации которой, вообще-то, вся эта красота и рисуется.
Вместо этого ее функции размазывают между участниками процесса, как масло по бутерброду. В результате Система есть везде и нигде. И по схемам невозможно понять, что она реально делает и за что бизнес платит деньги.
Вторая проблема - универсальность. Курсы учат рисовать одну схему для всех сотрудников заказчика разом. Как будто топ-менеджер, руководитель среднего звена и исполнитель — это один и тот же человек. На практике у них три разных видения мира. В итоге схемы работают усредненно — а значит, посредственно.
И наконец, схемы рисуют, не сообщая, а зачем они? Для презентации руководству, для инструкции рядовому исполнителю или для чего-то еще?
В этой статье я покажу, как встроить Систему в схемы бизнес-процессов, адаптировать схемы под разные уровни аудитории и применять на практике — под конкретные задачи.
Привет! Я Артём Юрченко — DS-инженер в команде Недвижимости Авито. Наши кол-центры совершают до 30 000 звонков в день, и вручную можно проверить лишь небольшую часть из них. Расскажу, как мы начали строить систему речевой аналитики и разработали первую модель, которая автоматически находит в звонках возражения клиентов и анализирует, как операторы их отрабатывают.
Статья будет полезна DS-инженерам, аналитикам и продакт-менеджерам, которые работают над продуктами построения речевой аналитики.
Анализ проблемы и формирование гипотезы — удача является важным фактором в жизни человека. Но главный вопрос — насколько? Какие категории параметров можно выделить для декомпозиции с целью анализа? Начинаем погружение в “кроличью нору”.
При использовании современных IDE сред разработка прикладных приложений и сервисов с использованием естественного языка уже становится привычным делом. Но вот с задачей создания процессных артефактов в нотации BPMN 2.0, ИИ-агенты пока еще плохо справляются. И если в визуальном представлении эти схемы становятся уже более-менее адекватными, то вот заставить их “работать” получается далеко не с первого раза. Почему так происходит и как помочь ИИ-агентам в решении поставленных задач разбираемся по мотивам перевода материалов от Тима Цёллера.
Самые интересные новости финансов и технологий в России и мире за неделю: лимит на зарубежный инет-трафик в России, банковская инфраструктура РФ поломалась на день, IPO SpaceX целит уже на $2 трлн, OpenAI купили подкаст для псиопов, а у Claude Code утек исходный код.
В Ташкенте курсируют около 1 800 активных автобусов на 170 маршрутах. Их GPS-координаты поступают каждые 10 секунд. В сутки это составляет порядка 15 миллионов координатных пингов. Но объём – не самая сложная часть.
Настоящая проблема в том, что отдельный GPS-пинг сам по себе ничего не значит. Координата автобуса на заданной широте/долготе не отвечает на вопросы:
Начну с контекста. Я играю в EA FC (ранее FIFA) в режиме Clubs (11×11), где каждым виртуальным игроком управляет человек. Сам по себе режим интересный, но мне, как человеку, который любит цифры и аналитику, довольно быстро стало не хватать доступной статистики.
Я пришёл в лигу, у которой уже был свой сайт (я в этой статье опущу тему о том, что я администрировал проект порядка 3 лет). Там статистику собирали вручную: люди пересматривали записи матчей и заносили базовые показатели — голы, ассисты, перехваты, отборы и так далее. На основе этих данных считались различные рейтинги: лучшие игроки, бомбардиры, разрушители и прочее.
Выглядело это примерно так: набор таблиц, где действия сгруппированы по категориям и амплуа.
Меня зовут Иван Васильев, я ведущий аналитик в Ви.Tech, IT-дочке ВсеИнструменты.ру. Хочу показать, как из на первый взгляд простой формулы KPI выросла инженерная задача: нам нужно было не просто посчитать интегральный показатель эффективности поставщика, а объяснить, какая именно закупка его ухудшила и почему. В статье разберу, почему для агрегированных метрик не работает наивный подход, как мы пришли к remove-one analysis и где пришлось отдельно фиксировать логику расчета, чтобы результат вообще можно было интерпретировать.
В одной из систем, над которой я работаю, мы рассчитываем интегральный показатель эффективности поставщика. Сначала задача казалась очень простой: несколько метрик, несколько весов, обычная агрегированная формула. Но однажды бизнес задал вопрос:
| Почему показатель поставщика снизился?
Ответить на него можно было бы общими словами. Но затем появился уточняющий вопрос:
| А какая именно закупка ухудшила показатель?
И в этот момент простая аналитическая задача внезапно превратилась в интересную инженерную проблему: с агрегированными метриками, нелинейными функциями и неожиданными эффектами, которые больше похожи на задачи из дискретной математики, чем на обычный backend.
Представьте: вы подходите к коллеге и спрашиваете: «Сколько у нас продаж в этом квартале?» Звучит просто. Но за кулисами начинается ад. О каком квартале речь — календарном или финансовом? А «продажи» — это отгруженные товары, оплаченные заказы или подписанные договоры?
Без семантического слоя ИИ работает напрямую с исходными данными, где названия колонок часто неоднозначны (сумма, количество, дата). Это приводит к тому, что ИИ не может корректно интерпретировать запрос и выдаёт ошибку или бессмысленный результат. Семантический слой выступает как «переводчик»: он определяет, что означает каждая колонка, как связаны таблицы и какие метрики считаются главными. Благодаря этому ИИ получает чёткие инструкции и отвечает на вопросы пользователей точно, а не наугад.
В предыдущих публикациях было описано, как использовать функциональность FEB_FILE_HANDLING как единую точку входа для импорта банковских выписок в SAP, независимо от каналов получения выписок (прямые каналы связи с банковскими системами или выгрузка файлов из систем «Банк‑клиент») и используемых форматов (XML или текстовые форматы). При этом рассматривалась только обработка итоговых банковских выписок.
Ссылки на предыдущие публикации:
Продолжаем описание создания симуляции с учетом фактора удачи. Составляем список факторов, влияющих на жизненный успех. Изначально идея была простой. Но что получилось в итоге?
Привет, меня зовут Янина. Днем я управляю продуктами и проектами. Вечером — сижу в Jitsi с ребятами из IT и обсуждаю, почему у кого-то не полетел A/B-тест, как считать retention и что вообще считать ценностью в продукте. Мой разговорный клуб давно перестал быть просто поболтать на английском.
Раньше основой домашек были подкасты про какую-то боль в аналитике. Но в какой-то момент я поймала себя на мысли, что про аналитику очень сложно слушать. Ее лучше видеть (дашборд, cjm и тд). Поэтому в клуб пришли воркшопы и лекции из YouTube. И сегодня делюсь каналами, которые у нас в итоге прижились.
Если хотите, чтобы просмотр видео был максимально полезным для вашего английского, то:
Представьте: вы заходите в репозиторий, открываете папку schemas и через пять минут понимаете, как устроена база во всём проекте, со всеми связями. Никаких устаревших диаграмм в Confluence, никаких гаданий по коду миграций. Схема базы данных становится частью кодовой базы — её можно версионировать, ревьюить, тестировать. Модель в формате ArchDB становится единым источником истины, из которого автоматически генерируются документация, DDL-скрипты и даже ORM-сущности. Звучит как мечта? Для нас с командой это стало реальностью, когда мы перешли на ArchDB.
Привет, Хабр!
В течение последнего года я занимался разработкой аналитической панели для продавцов на маркетплейсах Wildberries и Ozon, а в перспективе планируется интеграция с Яндекс.Маркет. Я хотел бы поделиться своим опытом и представить систему WBOZYA-dash, которая предназначена для анализа продаж через эти маркетплейсы. До конца весны 2026 выпущу, думаю, с десяток статей на эту тему, а пока сделаю общий обзор своей системы.
Ошибки в API часто воспринимаются как второстепенная часть контракта – до тех пор, пока интеграции не начинают ломаться в самых неожиданных местах. В этот момент выясняется, что одного HTTP-кода недостаточно: без ясной структуры и контекста ошибки превращаются в источник неопределённости и лишней работы. В статье разберём, как проектировать ошибки как полноценный элемент API – с понятной семантикой, единым форматом и возможностью для автоматической обработки.
Почти все компании начинают построение аналитики в Excel. Это удобно потому, что на старте данных немного и все можно собрать в одну таблицу, быстро посчитать и в целом понимать, что происходит.
Excel довольно универсальный инструмент. Хочешь — отчет собери, хочешь — модель посчитай, хочешь — гипотезу проверь. Но постепенно его начинает не хватать.
Сначала компании разрастаются данными. Потом они появляются в разных местах , таких как, CRM, рекламные кабинеты, бухгалтерия, сайт. Потом с ростом компании появляются дополнительные отчеты. И тебе уже приходится работать сразу в нескольких файлах и системах.
Сначала это терпимо. Потом начинает раздражать. А потом ловишь себя на мысли, что даже на простой вопрос по бизнесу нужно потратить время: открыть несколько таблиц, сверить цифры, проверить формулы.
Тогда многие компании начинают задумываться об усовершенствовании аналитики и внедрении BI.