Андрей Корниенко. Про (аналитить) это

Применение LLM для анализа и проектирования Последние полгода пользуюсь LLM для анализа и разработки и к этому моменту сложилось понимание, что именно делать чтобы извлечь максимум пользы из ИИ. Самое главное что я для себя уяснил: работу по анализу моделька за меня не сделает. Очень много рутины может взять на себя, сделать кросс-проверку по требованиям, чтобы не противоречили сами себе разные части документации; может указать на области, которые я забыл описать или описал слабо. Но понимать, что именно я делаю и зачем, всё равно должен я сам: это настолько сильно меняется от проекта к проекту в интеграторе, что универсального рецепта как не было, так и нет. Для чего конкретно я применяю агентов: (а) формирую документы по пользовательским/бизнес требованиям на основе интервью; (б) анализирую существующую документацию по разрозненным системам у заказчика (господь, храни 1С); (в) анализирую реальный код систем, чтобы понять, как они функционируют и дописываю требования и задачи на доработку. Как я работаю: (1) Инструментарий: Cursor IDE, встроенные модели Composer 1.5/2, в последнее время Custom API Key от OpenRouter. Автороутер по моделям anthropic/*, но там неожиданно дорогой Claude Opus 4.6. Нашёл неплохую xiaomi/mimo-v2-pro, по результатам радует. Но действительно сложные вещи приходится гонять через Opus. (2) Многоступенчатая работа в режиме промптов: - сперва готовлю семантический граф знаний по проекту, складываю доки в читаемых форматах, делаю предварительные прогоны для выжимки для агентов (диаграммы, таблицы и прочее). Граф сохраняю в виде XML, отдельный навык/правила на это; - затем с помощью агента генерю промпт по специальным правилам, которые устанавливают правильный alignment модели, управляемый belief state и погружает агента в контекст задачи. Читайте про то, как работает трансформер, что такое sparse attention и проблема lost in the middle; - затем уже самой дорогой моделью выполняю задачу по сгенерированному промпту. Обычно она работает 10-15 минут на сложных задачах. Бывает останавливается, переспрашивает (в промпте у меня есть строгие указания на этот счёт). (3) Связность и непротиворечивость проверяю, вручную вычитывая получившиеся артефакты. Правлю, объясняю агенту что надо исправить — и главное, почему. Тогда он начинает подсказывать где ещё что надо поправить, понимая мое намерение, а не просто тупо задачу. (фан факт: в разговоре один из заказчиков назвал другого «Даней» и иишка везде в спеке стала так называть Даниила. Пришлось объяснять, что так нехорошо) (4) На больших объемах документов контекстным окном управляю через семантический граф и промпт. Там строго написано не загружать нерелевантные задаче документы; граф лежит в XML и позволяет агенту на стадии sparse attention помечать только те документы, которые нужны для задачи. Если работать с Cursor IDE напрямую через Anthropic, то у них есть встроенный механизм компактирования контекста, когда он его по мере надобности сжимает в вектор. В моем случае при работе через API OpenRouter этот механизм не работает. Поэтому вручную слежу за размером окна. Если грамотно разбивать работу по доменам и документам, то проблем обычно нет. Пока надобности с окне 1М токенов вообще не возникало. Это если ERP какую-нибудь в один присест надо прожевать — тогда да. К счастью, пока таких задач не было :)) На картинке — только кусочек рабочего промпта, он довольно длинный. Расскажите, как у вас дела с ИИшками в работе? #ии

Говорю про банальные вещи, которые тем не менее остаются актуальными: в статье разбираю причины несоответствия ИТ-решений ожиданиям клиентов и предлагаю очевидные (хыхы) методы минимизации разрыва между ожиданиями заказчика и конечным результатом. https://www.it-world.ru/cionews/hk0qmcxmm00k80wcskogcgw8wcg4os4.html

Таксономия базы знаний Т. — учение о классификации сложных иерархических систем. Здесь: система классификации статей в базе знаний (в конфлюенсе, вики, БД). Принципы Найти статью базе знаний будет легче, если она снабжена метками (тэгами) в соответствии с принятой на проекте таксономией. Статья может быть снабжена метками из следующих разделов: Аудитория, Тип документа, Тема, Система, Функция Как работают метки Пример для конфлюенса Чтобы добавить метку, нажмите справа-внизу страницы на иконку бейджика, появится всплывающее окно. Метка создаётся в конфе, когда её первый раз присваивают странице. Метка удаляется из конфы, когда не остаётся больше страниц с такой меткой. Правила именования меток Формат названия: — строчные (малые) буквы — слова-разделены-дефисом (kebab-case) — первое слово метки определяет раздел таксономии: аудитория-; тип-; продукт-; тема-; система-; функция-. Для метки используется только русский язык. Названия систем, функций и модных фичей переводим в удобоваримый аналог на русском языке (например «система-нав»). Таким образом мы всегда будем знать, как набирать название метки в конфе. Правила для тематических меток Метки из группы «тема-*» создаются путем перечисления сущностей из предметной области от общего-к-частному во множественном числе. Например: тема-товары-остатки тема-товары-цены тема-товары-отображение тема-заказы-статусы тема-рефералка-управление К чему я это всё? Нашёл сегодня свою собственную статью в базе знаний проекта и понял, что неплохо её проработал для использования на любых проектах, где документации больше чем пара десятков страниц. Метки удобны тем, что их можно гибко фильтровать и создавать промежуточные страницы для группировки сходных документов, которые лежат исходно в разных ветках базы знаний. Например: «Фиды», «Алгоритмы ETL», «Обработка остатков» и так далее. P.S. Для классификации страниц идеально использовать языковые модели; NLP — их сильная сторона.

Паттерн: Сага Интересный архитектурный шаблон, особенно актуальный в условиях распределённых систем, когда некое бизнес-осмысленное действие будет успешным, только если будет успешным каждый небольшой шаг, а функционал реализован в разных сервисах; если любой шажок закончится неудачей, то надо откатить все предыдущие (успешные) шаги. Сага — это последовательность локальных транзакций. Каждая локальная транзакция обновляет базу данных и публикует сообщение или событие, чтобы запустить следующую локальную транзакцию в саге. Если локальная транзакция завершается неудачей из-за нарушения бизнес-правила, сага выполняет серию компенсирующих транзакций, которые отменяют изменения, внесённые предыдущими локальными транзакциями. — Pattern: Saga Пример — создание заказа на одном из текущих проектов. Задача: создать сущность заказа в OMS в статусе «Создан», затем зарезервировать остатки под заказ в системе оперативных остатков товаров, потом сменить статус заказа на «Оформлен» и в конце отправить уведомления клиенту и менеджеру (ещё нужно будет бонусы списывать в программе лояльности, но это на следующих этапах проекта). Формально сагу рекомендуют делать на событиях, которые либо оркестрируются либо обрабатываются хореографически. Мы сделали упрощённый оркестратор, который хранит состояние саги в реляционной СУБД. В случае неудачи оркестратор пытается выполнить шаг с таймаутом с нелинейным возрастанием задержки. Если попытки исчерпаны — вся сага отменяется с компенсирующими действиями. Наша сага имеет следующие шаги: APPLY_STOCK — создать временный резерв остатков APPLY_LOYALTY — списать бонусы в системе лояльности CONFIRM — подтвердить заказ, отправить уведомления Финальные шаги: FINISHED — сага успешно завершена FAILED — сага завершилась с ошибками Шаг отката: ROLLBACK_STOCK — убрать временный резерв остатков в случае ошибок Я решил не усложнять архитектуру асинхронными очередями, потому что: (1) тестировать сагу стало бы в разы сложнее; (2) проектная нагрузка на систему далека от „High load“; (3) узнать в моменте состояние саги стало бы сложнее. Подобная реализация уже была сделана нашим тимлидом на другом проекте и по моим наблюдениям вполне неплохо себя зарекомендовала. Проблемы, которые там были, появились из-за некачественного логгирования шагов и плохо настроенных таймаутов (финальные таймауты достигали дней между повторами). Я с самого начала спроектировал логгирование правильно, ну а для таймаутов, для разнообразия взял ряд Фибоначчи с ценой деления 1 минута. А есть ли у вас в практике интересные шаблоны проектирования, которые вы использовали осознанно? (ну или случайно, главное чтобы вам понравилось :) )

Все кругом используют ИИ …или как в одном анекдоте, говорят о том, что используют ИИ. При этом все разговоры крутятся обычно вокруг простых языковых трансформеров. Про живые внедрения агентских ИИ я читал только в новостях и профильных каналах, вживую пока не довелось попробовать. Агентские ИИ не просто отвечают на вопросы или выполняют одну команду, а действует самостоятельно, добиваются целей, могут «размышлять» о собственных действиях и менять поведение в процессе выполнения задачи. Сам я использую ChatGPT в работе и хобби — но не в веб-варианте, а как телеграм-бот. В телеге чертовски удобно общаться и регулировать контекст; я написал бот, в котором реализовал шаблон RAG и эмбеддинг узкоспециализированных материалов в контекст для одного дружественного проекта. Попутно изучил, как вся эта кухня работает. Конкретно для анализа и проектирования я обычно беру транскрибированный текст из встречи с заказчиком и командой, размечаю тегами его на блоки (теги любые, чаще использую xml-подобный синтаксис). Далее загружаю контекст в бота, велю ему ждать команду на начало работы. Из последнего — я делал BRD по результатам установочной встречи с заказчиком. Предварительно накидал инструкции о том, что я хочу увидеть в структуре BRD; в той части, где мне нужны высокоуровневые требования, я даю предельно точные инструкции примерно такого вида: (5) Высокоуровневые бизнес-требования. Требования опиши в канонической форме, как указано в примере ниже. Пронумеруй каждое требование в формате БТ-X где X — монотонно возрастающее целое число. Каноническая форма: <Программная система> <должна> позволять <Участник> <действие> <Объект><условия> <пример> Система должна позволять пользователю с ролью “Абонент” создавать карточку жилого помещения.</пример> Дальше велю ИИшке приступать к работе, по частям отдавая мне результат. Дальше я нудно и тщательно проверяю результаты работы и оформляю результирующий документ. ИИшка нет-нет да и наврёт, сколько ты не пиши инструкции «отвечай только если уверен более чем на 75%», галлюцинации проскакивают регулярно. Плюс бывает откровенный бред, но это всё устраняется осмыслением и редактурой. Главное что я получаю — это экономия времени на сбор структуры, поиск альтернативных вариантов и генерация внятного текста. Мне править всегда проще, чем писать с нуля. И ещё: когда долго работаешь с LLM, начинаешь чувствовать некоторую «пластмассовость» в её суждениях и это надо убирать, люди далеко не дураки. Ещё использую LLM для уточнений по пирамидам метрик либо как переводчик с любых языков на любые, либо на поиск терминов или контекста. Но всегда, всегда надо делать фактчек за ИИшкой. Как у вас дела обстоят с ИИ? Получается внедрять в работу, помогает или мешает?

Про протоколы приколы интеграции. Сижу, готовлю презу к Flow. Подходит сын, садится рядом и внимательно изучает, что я рисую. Потом говорит: "Ааа! Протоколы интеграции! А я думал — приколы интеграции!" Ну, поговорили о приколах. Навскидку, вспомнил такие приколы: * SOAP, один из самых сложных по структуре протоколов, расшифровывается как Simple Object Access Protocol. Простой он по сравнению с такими монстрами, как CORBA. * MQTT, несмотря на буквы MQ в названии (обычно означающие Message Queue), вообще не содержит очередей. * YAML не является языком разметки, его теперь так и расшифровывают: YAML Ain't Markup Language. * Основной принцип REST — управление через гипермедиа, HATEOAS. Но этому принципу почти никто следует в реальных REST API. * REST API (HTTP-запросы) считается синхронным, но в реальных программах почти всегда HTTP-запросы выполняются асинхронно. * Брокеры типа Kafka и RabbitMQ считаются (и являются!) асинхронными, но скорость обмена (latency или round trip) в них может быть в разы меньше, чем в "синхронных" HTTP-запросах. * FlatBuffers, несмотря на своё название (flat=плоский), может хранить и вложенные объекты (через опцию nested_flatbuffers). * Продукты RabbitMQ и Kafka часто рассматривают, как альтернативы, но они принципиально отличаются: RabbitMQ — это брокер сообщений с очередями без записи на диск, а Kafka — распределенный журнал с высоконадежным хранением, но без маршрутизации и очередей. Впрочем, в последнее время в Kafka появились очереди (в каком-то виде), а в RabbitMQ — персистентные сообщения и журналы (в каком-то виде). Напоминает сказку Киплинга про ежа и черепаху, которые друг друга учили плавать и сворачиваться в клубок. * Несмотря на наличие "семантики доставки" exactly-once в Kafka, на самом деле доставка консьюмеру тут вообще никак не контролируется, это только про однократную и без потерь запись в журнал. Это те, что я вспомнил минут за пять. Какие у нас ещё есть приколы в области интеграции?

ИИ-психолог Если беседа с ИИ-психологом не будет отличима от беседы с человеком-психологом (тест Тьюринга или что-то более специальное), то в чем тогда разница? Этот вопрос возник у меня после прочтения поста с анализом того, понимает ли ИИ о чем пишет или только мимикрирует? Не вдаваясь в детали — мимикрирует, и делает это очень хорошо, раскладывая запрос в семантический вектор по большому количеству осей смысла и подыскивая релевантный ответ. Задал вопрос в канале психолога Михаила Прасса, где похожий вопрос обсуждался. Ответы процитирую: Михаил Прасс: Дело в том, что по статистике примерно треть случаев относится к категории "сюрприз". То есть, они не имеют схожих не только в практике конкретного психолога, но и в литературе. Здесь нужно действовать методом "проб и ошибок", а в этой сфере ИИ просто ужасен и опасен для человека. Ещё в трети случаев мы имеем "последовательное приближение к результату". Тут уже чуть лучше, но человек пока сильно эффективенее ИИ. И только в случае, когда клиент изначально находится в высокой степени готовности или его случай более-менее стандартен, ИИ уже сейчас может превосходить среднего психолога. Aleksandr K: На типовых случаях может и неотличима. А однажды случится какая-то крайность, не описанная в системном промпте и выяснится, что "король-то голый" а ИИ-психолог не понимает, что несёт. Как пример - ЧатЖПТ, который помогал подростку написать предсмертную записку и в целом консультировал по уходу из жизни но при этом за весьма длинный диалог ни разу не предложил альтернативных решений. Оговорка: есть вероятность, что в ближайшие 10 лет ИИ по качеству работы превзойдёт "среднего" врача в большинстве медицинских специальностей, а может даже встанет на уровень лучших, причём во всех. Но пока предостережения типа моего актуальны. Михаил Прасс: ИИ в медицине уже превосходит узких диагностов в типовых случаях. Но в "смазанных" случаях ИИ уверенно "убивает" пациентов. Даже врач средней квалификации справляется в таких ситуациях лучше. По моим ощущениям, меня сейчас больше всего привлекает связка врач-человек + ассистент ИИ. Потому что ИИ эрудирован, быстрее «думает», внимателен к мелочам. А человек как раз способен мыслить вне рамок «обучения» и «похожести векторов». Идти к автономному врачу-ИИ я сейчас точно не готов. А вы бы пошли к врачу, зная что он либо совсем робот либо человек, который использует помощь ИИ в работе с вами?

Заказчик, может, и неправ, но это его дело На проекте возникла ситуация: клиент хочет решение в дизайне, которое субоптимально, по мнению команды. Один из аналитиков обратился ко мне за советом: Андрей, мне ещё твой совет нужен по сниппету для каталога, они всё-таки размеры и цвета на ховер затащить хотят и отказаться от модалки. У меня пока, кроме как "перегруженный ховер", аргументов нет... Больше, чем уже есть на модалке, они функционал не хотят. Я вспомнил Максима Ильяхова и его мантру: Раньше я говорил себе: «Я должен делать лучшие в мире проекты». Сейчас я говорю так: «Я хочу помогать клиентам решать их проблемы настолько хорошо, насколько могу». Поэтому ответил коллеге вот так: Совет простой: нарисуйте вариант с точки зрения, когда на сниппете «есть всё». Все цвета, размеры, свистелки — всё. И покажите, как это будет выглядеть. Если заказчик скажет, что ему это нравится — значит, мы сделаем ТАК, как этого хочет заказчик. Наша задача — не научить заказчика прекрасному чувству тонкого вкуса, а объяснить, какие есть варианты, разъяснить, чем лучше или хуже. Выбирает заказчик; нам не следует печалиться и терять радость работы в проекте из-за этого. Это нормально, что заказчик может выбрать условное говно; плохо, если не попытались ему объяснить, что это говно. Мы пытаемся, но нужно делать это лаконично, хладнокровно, профессионально и не рвать на себе волосы, если не получилось. === Надо уточнить, что конкретно этот макет в согласовании уже почти месяц, так что переубеждать время было, и все подходы к объяснению «почему лучше иначе» сделаны. Команда откровенно заколебалась уже. И да, какую проблему заказчик хочет решить — тоже отлично понимаем. Осталось просто сделать, как просят.

История провала Однажды мы начинали проект по производству электронного магазина с одним известным брендом и потребовалось срочно подтвердить, что в нашей команде есть специалисты, умеющие работать с OMS Starfish24. OMS — Order Management System, система управления заказами в электронной коммерции. (сразу скажу, что проект закончился относительно успешно, хотя и обошёлся заказчику в несколько раз дороже, чем изначально планировалось. Но виноваты были не мы, там всё было плохо спланировано ещё на этапе идеи и оценки бюджета) В нашей команде, разумеется, вынь-да-положь такого человека не было; планировалось нанять или взять в аренду спеца по ходу дела. А тут — лицо, принимающее решение на стороне заказчика потребовало предъявить компетенции «прям сурочна!». Менеджмент заметался, шестерни завертелись и «жребий упал на меня» (ц) Кир Булычев, «Путешествие Алисы». Я растерянно сказал менеджменту: менеджмент, что я там смогу ответить на собеседовании, если я систему-то в глаза ни разу не видел?! Менеджмент велел мне посмотреть документацию (из документации был список эндпоинтов API в Сваггере) и диаграммы внедрений на других проектах (стрелочки и квадратики невнятного происхождения и семантического наполнения). Делать нечего и я честно поковырял унылую документацию и осторожно потыкал палочкой Сваггер. Ничего не понял, потому что логики между 80+ эндпоинтов и процессом регистрации заказов как-то не улавливалось. В общем, на собеседование я пришёл с видом бравым и слегка придурковатым. Ни на один вопрос я ответить внятно не сумел, хотя тупо не молчал и невероятным усилием воли формулировал ответы, которые теоретически можно было принять за правду. Да вот только нёс я полную чушь, потому что в сути работы системы я не разобрался. Заказчик мне так и сказал (близко к оригиналу, но прошло больше 3-х лет, могу путать слова): «— Молодой человек, вы вообще не компетентны в части работы этой системы. Совершенно точно я буду требовать замены команды и постараюсь больше с вами никогда не встречаться». Сказать, что мне было стыдно — это ничего не сказать. Такого феноменального, катастрофического и бездарно унизительного поражения я не припомню с универа, когда профессор выгнал меня с пары за опоздание, выговаривая на аудиторию из 100 человек. В тот день я поклялся сам себе, что больше не пойду на сделку с совестью и не поведусь на уверения менеджмента, что это «как комарик укусит», «давай, вошли и вышли, приключение на 20 минут». После того случая у меня не раз бывали и уверен, ещё не раз будут ситуации, когда на вопрос собеседника я понятия не имею, что ответить. В этом случае я либо сразу говорю, что не знаю ответа; либо отвечаю, что мне нужно подготовиться и я вернусь с ответом через некоторое время. К слову, с тем человеком, который меня собеседовал, мы потом проработали ещё полтора года на проекте: пришлось дипломатично забыть мой эпичнейший провал, потому что менеджмент, надо отдать должное, встал на мою защиту горой и отказался заменять команду на проекте. А значит — мне пришлось изучать, как работает OMS Starfish24 — только в этот раз по-честному и без дураков. Поделитесь вашими историями провала в комментах? :))

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

Технология бутерброда Когда мне нужно высокоуровнево описать модель какого-то бизнес-процесса, я часто использую нотацию IDEF0. На мой взгляд, она идеально подходит, когда требуется «helicopter view» на один или несколько процессов, чтобы понять: * основные связи между шагами процесса, * регламентирующие документы и воздействия, * роли, которые нужны для выполнения процесса, * системы, механизмы и разнообразные ресурсы — пока не нарисуешь, даже не догадаешься что потребуется. Чтобы объяснить стейкхолдерам, что такое IDEF0 (звучит страшновато и пыльно), нарисовал процесс «Как приготовить бутерброд» по всем правилам и заветам стандарта. Делюсь — может, кому-то пригодится :) Рисую процессы обычно в draw.io и сохраняю исходники на Гуглодиске, либо если у заказчика Confluence с нужными плагинами — то рисую прямо внутри конфы. Нотация минималистичная, кубики-и-стрелочки, всё как мы любим. На этапе концептуального обсуждения ровно то, что нужно. Далее по необходимости отдельные процессы декомпозирую в BPMN, где словарь гораздо богаче и можно точно показать логику исполнения бизнес-процессов. #idef0

Меня признали экспертом года по версии AWG & SkillStaff — что чрезвычайно приятно. Благодарю коллег за доверие! 😄

Уровни архитектуры В сложных проектах мне, бывает, нужно объяснить заказчику (и своей команде), как именно мы анализируем архитектуру предприятия и где проектируем информационные системы. Пока об этом говоришь на словах, попытка объяснить это — дохлый номер. Нужно показывать, включать схему архитектуры предприятия в артефакты проекта и время от времени на созвонах показывать её и уточнять, на каком уровне абстракции мы работаем в данный момент. Мне нравится TOGAF, но всухую без подготовки этот фреймворк довольно сложно начать использовать; на практике помогает вот такая упрощенная схема. На ней показаны основные слои архитектуры и сущности, которые исследуется на этом уровне. TOGAF, аббревиатура от The Open Group Architecture Framework. Фреймворк архитектуры предприятия определяет, как создавать и применять архитектуру предприятия; нас в данном случае интересует системный подход к исследованию архитектуры. Опираясь на эту модель, довольно просто объяснить заказчику, почему нас интересуют причины, побудившие заказчика на этот проект. Здесь же можно указать, что входит в рамки анализа, а что останется за границами проекта. Например, «драйверы бизнеса» и «производственные линии» часто можно исключить безболезненно, а «бизнес-процессы» и «данные логические» — обычно обязательны для анализа. Прикладываю ссылку на диаграмму в draw.io. Рисуете ли вы диаграммы архитектуры предприятия на своих проектах? Какие уровни архитектуры отрисовываете? #архитектура

На выходных провели вместе с Натальей @start_in_IT тренинг «Китайская ручка» по систематизации знаний по разработке требований. Я выступал на тренинге в качестве заказчика, и это было очень необычно; как правило, я выступаю в роли аналитика либо архитектора. Кратко впечатления можно охарактеризовать моими репликами Наталье в личке: Мы (аналитики) в самом деле ерундой такой страдаем на проектах? … Я кое-что начинаю понимать насчёт [заказчика] … Кажется это не они странные Во вторник на встрече с заказчиками начал рисовать такую вот диаграмму, чтобы пояснить где у нас на проекте сложности. Очень удобно обозначить две точки: (а) нет согласованных требований, потому что стейкхолдеры игнорируют наши запросы и предпочитают отмалчиваться (верификация) и (б) огромная вероятность сделать качественный продукт, который абсолютно не попадёт в ожидания заказчика (валидация). Очень поучительно в игровой форме опробовать разные роли. На тренинге я хорошо почувствовал, как аналитики пытаются меня принудить согласовать низкоуровневые требования, которых я явно не выдвигал; вместо этого легко и приятно согласовывать требования бизнес- и менеджерского уровня. Потому что из позиции заказчика такие требования максимально понятны. Всё, что глубже — требует дополнительного когнитивного напряжения и возрастают риски добавить ненужные, на самом деле, ограничения.

На днях прочел перевод статьи Ицхака Адизеса https://premiummanagement.com/blog/ichak-adizes-chto-takoe-zdorovaya-kompania В статье поднимается тема успешности стартапов: - что для этого важно и необходимо для успеха, - о важности внимания к проблемам своих клиентов, - что нужно уделять внимание как краткосрочным так и долгосрочным перспективам Но меня заинтересовала следующая мысль: Организация, которая эффективно обслуживает своих клиентов, принимая во внимание заинтересованные стороны в краткосрочной и долгосрочной перспективе, является ЗДОРОВОЙ компанией.

Помощь ИИ в анализе и проектировании Лично я пока не видел реальной помощи от ИИ в анализе, проектировании и в операционной части бизнеса электронной коммерции. Проблема, на мой взгляд, состоит в том, что ИИ на самом деле не понимает, о чем пишет/говорит/рисует. Он анализирует частотность токенов при обучении и их связь между собой. И чем длиннее ассоциативные цепочки токенов, тем «умнее» выглядит ИИ. В екоме, несмотря на общие закономерности, бизнес-процессы сильно различаются от организации к организации. И выходит, что каждая решаемая аналитиком проблема — оптимизация, проектирование процессов или автоматизация — уникальна. ИИ просто неоткуда взять решение; он пытается собрать из грязи и палок то, что где-то видел. А там про другое. Да ещё без глубины смысла. Поэтому взять и натравить ИИ на бизнес и сказать «проектируй» или «анализируй» — не получится. Те процессы наполовину состоят из «крысиных» чатиков и эмоциональной поддержки людей друг друга; поди это учти в моделях без интервью. Думаю, со временем ситуация улучшится, когда ИИ сможет теснее наблюдать нас в естественной среде обитания; длина цепочек анализируемых токенов позволит таки создавать убедительные результаты и артефакты. Пока максимум что ИИ может в разработке — это помогать писать типовые конструкции в коде, где много повторяющихся паттернов и экономить труд разработчиков на написание действительно сложных частей. Аналитики пользуются ИИ, чтобы набросать типовые sequence-диаграммы (которые потом всё равно допиливать руками до ума). В системах массового обслуживания, которые легко алгоритмизируются — например, колл-центры, кассы и так далее, — там ИИ действительно эффективно помогает. Видели ли вы примеры в работе, где ИИ действительно блестяще справляется? Лучше людей? Поделитесь в комментариях, это интересно.

Задача: передать булевый признак товара в модели данных. Решение: число 1/0 в виде строки 😎 Умоляю, не делайте так 😁