В приведённой BPM-ке - бесконечный цикл на проверке варианта доставки. Не нашлось валидной схемы?
EPC - графическое представление юзкейса.
Описать в этих нотациях взаимодействие даже 3-4 систем - уже сложно. Построить же даже самую базовую карту интеграции 10 и более систем в happy path кейсе - получится нечитаемый монстр.
Это инструменты процессного и бизнес-аналитика.
Почему не упомянут archimate ?
Фиолетовый, желтый, голубой и частично зелёный слои - основная среда обитания описанного Вами специалиста
Если сравнивать результаты "поиска" по бытовым вопросам, мне DeepSeek нравится гораздо больше Qwen. Он не злоупотребляет информацией с VC, Дзен и прочих сомнительных источников.
Делюсь подходом, который решает ту же боль без «Excel-ядер». Он проверен и работает.
Суть (итеративно):
Берёте любой старый документ или транскрипт встречи. Прогоняете через LLM по прилагаемому промпту (первый проход).
На выходе — глоссарий (все термины, незнакомые помечены [? ТЕРМИН ?]) + очищенный текст.
По этому глоссарию рисуете ERD на Mermaid (сущности, атрибуты, связи, ключи). Это архитектурная база, а не таблица в Excel.
Следующие документы подаёте модели вместе с текущим глоссарием и ERD — LLM отлично парсит Mermaid и не путает сущности.
Новые термины -> дополняете глоссарий и ERD (человек или LLM под контролем).
На этой очищенной базе генерируете чистую документацию (процессы, инструкции, требования) — без галлюцинаций.
Важный совет: не изобретайте промежуточных сущностей вроде «слоистых ядер». ERD + итеративный цикл — проще, архитектурно чище и легко поддерживается.
Скрытый текст
Твоя роль
Опытный системный и бизнес-аналитик (розничная торговля, логистика, РФ)
Цель
Создать Протокол встречи для страницы в Confluence (минимальный копипаст)
Границы уровня Base
Табличное форматирование для Confluence
ОДНА диаграмма в формате ERD (Mermaid)
Требования в едином формате
Время выполнения: 15-20 минут
Входные данные
Транскрипт встречи (файл transcript-*.txt)
Проблемы транскрипта:
Посекундная разбивка фраз спикеров
Шум, отвлечённые разговоры
Ошибки распознавания
Ограничения
Для дальнейшего анализа:
Работай строго по тексту транскрипта
Если требуемая информация не найдена — пиши [НЕТ ИНФОРМАЦИИ]
НЕ добавляй собственные интерпретации и предположения
Приоритет секций (если время ограничено):
Глоссарий + Ключевые инсайты
Принятые решения
Перечень требований
ERD (Mermaid)
Форматирование:
Используй: текст, списки, таблицы
НЕ используй: ссылки, выделение жирным/курсивом
Если автор требования или иной параметр не определён — пиши [НЕ ОПРЕДЕЛЕН]
Задача
Очисти транскрипт от всего, что не относится к бизнес-задаче:
Мемо от системы транскрибации (Тема, Краткое содержание, Ключевые моменты, Принятые решения)
Приветствия и прощания в начале/конце
Личные разговоры (шутки, обсуждения)
Технические обсуждения качества связи
Склей фразы одного спикера в связные абзацы. Убери метки времени.
Выяви и отметь проблемные места: [НЕЯСНО]
Выяви предварительный глоссарий:
[термин]:[описание] — для расшифрованных терминов
[? ТЕРМИН ?]:[описание] — для незнакомых аббревиатур (CAPS + вопрос)
Зафиксируй требования с атрибуцией [автор]
Зафиксируй принятые решения
Построй ERD в формате Mermaid (синтаксис entity relationship diagram). Извлеки основные сущности из разговора (например: Заказ, Товарная позиция, Покупатель, Поставщик, Склад, Статус заказа, Счет, НДС). Укажи атрибуты и связи (один-ко-многим, один-к-одному). Если связь неясна — отметь [?].
Формат вывода
Титул
Поле Значение Наименование [Заполняет аналитик] Заказчик [Заполняет аналитик] Номер в Jira [Заполняет аналитик] Концепт эпика Для (кто), чтобы (что), необходимо (как) Статус Черновик Аннотация [Краткое описание]
Глоссарий
Термин Сокращение Описание [термин] [если есть] [описание] [? ТЕРМИН ?] [если есть] [требует уточнения]
Предпосылки (AsIs)
[Текст из транскрипта]
Задача бизнеса (ToBe)
[Текст из транскрипта]
Цель задачи
[Измеримая цель если озвучена]
Ключевое решение
[Концептуальный план если озвучен]
Требования
ID Наименование Описание Автор Статус REQ-{Jira}-001 [Название] [Текст] [Автор] Черновик
Ограничения и допущения
ID Наименование Описание Автор Статус SC-{Jira}-001 [Название] [Текст] [Автор] Черновик
ERD (Mermaid)
erDiagram
% Здесь сгенерируй ERD на основе выявленных сущностей
% Пример:
% ЗАКАЗ {
% int номер_заказа PK
% date дата_создания
% string статус
% }
% ПОКУПАТЕЛЬ {
% int id PK
% string фио
% string перс_данные_для_таможни
% }
% ЗАКАЗ ||--|| ПОКУПАТЕЛЬ : оформляет
Промпт даю свой, проверенный. Чуток адаптировал его под Вашу задачу (у меня в базе LLM схему чертит под draw.io в mxgraph xml).
Кирилл, добрый день. Прочитал статью. Впечатлён объёмом и системностью. Видно, что проделана серьёзная работа.
Я сам немного архитектор, и мне хорошо знакомо это чувство: когда появляется новая технология, хочется сразу затащить её в контур, чтобы «расширить капабилити».
Но у нас, похоже, разные стартовые точки. Вы глубоко разобрали «как» интегрировать ИИ в ERP. Для меня же первичен ответ на вопрос «зачем?». Не в перспективе «когда ИИ дозреет», а здесь и сейчас. Какую конкретную бизнес-задачу это решает? Что станет дешевле, быстрее или надёжнее для компании в текущем контуре? От этого и нужно смотреть конкретное исполнение.
Давайте посмотрим на историю внедрений. ERP эволюционировали в современные монолиты именно так – поэтапно поглощая крупные функциональные блоки.
Что прижилось внутри ядра: * MDM: модули управления НСИ. * BPM: маршруты согласований, статусные модели, эскалации. * WMS/TMS: управление складом и логистикой (часто в ядре или на бесшовной интеграции). * BI/OLAP: встроенные кубы, отчёты, дашборды. Базовая аналитика – штатный модуль. * GRC: контроль доступа, аудит, SOX-отчётность, разделение полномочий. * Rule Engines: конструкторы скидок, условий ценообразования, валидаторы.
Что осталось снаружи или не взлетело: * Полноценные CRM (обычно пристроены сбоку с синхронизацией). * Блокчейн (экономика, приватность и пропускная способность не сошлись). * Корпоративные соцсети (попытки вроде SAP Jam быстро сошли на нет). * Ранний ML на полках/кассах: единичные пилоты, массового внедрения не случилось.
Вывод напрашивается сам: в ядро ERP успешно «затащили» только то, что:
* Детерминировано (правила, маршруты, справочники). * Требует жёсткой консистентности (запасы, финансы, аудит). * Имеет чётко локализованную область применения.
Всё остальное ушло в интегрированные внешние сервисы или осталось экспериментами.
Примерим это к ИИ: * Детерминизм? Нет. Вероятностная природа. Можно обложить ИИ RAG-ом, MD-инструкциями, сбить ему температуру до нуля, но косинусное сходство не станет равенством. * Консистентность? Не требуется. Модель работает с «любым» входом, лишь бы хватило контекста. * Локализация области? Тоже нет. LLM по определению универсальны, а не заточены под узкий контур.
Добавлю ещё два практических аспекта, которые критичны в энтерпрайзе:
* Управляемость и откаты. В ERP мы точно знаем, что изменилось в релизе, и можем откатить пакет. В случае с ИИ (особенно внешним или часто обновляемым) мы не всегда фиксируем, когда и как изменились веса модели, версия промпта или логика выборки RAG. «Откатить галлюцинацию» сложнее, чем откатить транзакцию или патч. * Экономика и безопасность. Свои модели – это GPU, ML-инженеры, пайплайны для датасетов. Внешние API в контуре документооборота – риски утечки коммерческих данных и вопросы комплаенса. Всё это должно окупаться, а без чёткого «зачем» бюджет на содержание быстро съест гипотетическую выгоду.
Отвечу на ваш финальный вопрос: да, мы используем ИИ, и есть ряд рабочих кейсов (возможно, позже опишем). Но ни один из них пока не требует «нормализации терминов» внутри ERP-контура.
Ну и по сути. То, что Вы называете «семантическим ядром для ИИ», в enterprise-архитектуре последние 20 лет известно под другими именами: предметная область, НСИ, метамодель, регламенты ведения данных. Проблема обычно не в том, что ИИ «не понимает» контекст, а в том, что бизнес не хочет тратить ресурсы на дисциплину данных, пока не прижмёт. Встраивать дополнительный слой как решение галлюцинаций – это лечить симптом, а не корень.
Или я что-то упустил в Вашей логике? Буду рад конструктивной дискуссии.
Пока читал статью, всё чаще приходила в голову сказка про «суп из топора» в части итеративного создания ценности: начинаем с абстракции, постепенно добавляем структуру, контекст, связи.
Проделана серьёзная работа: связки «проблемы модели – причины – решения» описаны верно, очевидно, что Вы и самостоятельно разбирались долго и глубоко, и в диалоге с LLM выясняли их специфику (это заметно). Создать постоянный репозиторий под LLM-задачи – это реально хорошее с практической точки зрения решение.
Но есть момент, который я, возможно, упустил: какова конечная цель этой работы?
«Наведение порядка и устранение хаоса» – это метод, а не цель. Порядок – это отлично, но на практике цель всегда подчинена задаче. Кто или что является «потребителем» этого репозитория, как часто и для каких задач?
Без ответа на вопрос «зачем» даже самая красивая структура рискует стать артефактом, который жалко выбросить, но непонятно, как использовать. Не будем забывать, что создание этого репозитория – не финал. Поддержка актуальности таких систем – отдельная задача и отдельная стоимость.
Если не NDA – опишите, пожалуйста, полностью задачу, которую пытаетесь решить. Это помогло бы оценить не только качество исполнения, но и масштаб окупаемости усилий.
Спрашиваю не из праздного любопытства – просто вижу параллели со своей практикой.
Допускаю, что задача – генерация документации «на лету» в условиях ограниченного инструментария (недоступны ARIS / Sparx EA / Visual Paradigm). Если так – поделюсь своим костылём, который работает.
Мои аналитики чертят подробные BPM/EPC/Sequence с переиспользованием ключевых артефактов, я сохраняю их в XML или mermaid и отдаю в LLM с одним из отлаженных промптов. Эти форматы LLM читают охотно и корректно. На выходе получаю черновики БТ, пользовательских сценариев и даже тест-кейсов. Да, их приходится «причёсывать», но это не написание с чистого листа и время экономит заметно.
Может, такой подход снизил бы нагрузку на поддержку Вашего репозитория?
Знаете, мне не очень интересна судьба подобных управленцев.
А вот судьба ребят, к которым подобные управленцы придут и скажут "я тут прочитал про фабрики агентов, вот тебе 200 баксов на подписку, через неделю жду результат" меня волнует.
Сам бывал в схожих ситуациях на предыдущих "великих сингулярностях"
Пример задачи, которую не решить только подпиской за 200 баксов - привёл.
Владислав, я уже чётко пояснил, что меня триггернуло.
Сколько нам с Вами осталось ждать кого-то из ЛПР, которые придут и скажут "А вот на Хабре написано как закрыть квартальную задачу за 5 дней" (именно так звучит заголовок статьи). Пойди прочитай и сделай".
Недолго. Пользователи с ТЗ, полностью сгенерёнными AI, уже заходят.
Отобьёмся разумеется. Не впервой. Но почему мы вынуждены отбиваться от того, что кому-то пришло в голову хайпануть кликбейтным заголовком ?
Конкретно в этой задаче - весь "ТЗ" - текст закона. От регулятора нет ни Рабочих групп, где можно задать вопросы, ни дополнительных Писем и подзаконных актов. Вообще ничего. Читай и делай.
Это критически мало для запуска любого AI на задачу.
Недавно был отличный разбор темы от Дениса Бескова
В приведённой BPM-ке - бесконечный цикл на проверке варианта доставки. Не нашлось валидной схемы?
EPC - графическое представление юзкейса.
Описать в этих нотациях взаимодействие даже 3-4 систем - уже сложно. Построить же даже самую базовую карту интеграции 10 и более систем в happy path кейсе - получится нечитаемый монстр.
Это инструменты процессного и бизнес-аналитика.
Почему не упомянут archimate ?
Фиолетовый, желтый, голубой и частично зелёный слои - основная среда обитания описанного Вами специалиста
НДС на самом деле совсем не тривиальная штука
В банках НДФЛ тоже чудесатый по слухам.
Да без разницы на самом деле. Суть то не сильно меняется.
Быстрые прототипы - это реально очень нужная вещь
Однако же позвольте поинтересоваться таким нюансом. Расчёт и подачу НДС Вы тоже навайбкодите ?
Неужто именно в этом суть прогнозируемого Вами грандиозного шухера?
Тон ответа в настройках профиля пользователя пробовали подбирать?
В дефолте там "баланс профессионализма и дружелюбия"
Александр, вот реальное большое человеческое спасибо, что не поленились.
Плюсы ствол покинули 😁
Я в курсе. У меня в каждом проекте пре-промпт с настройкам под лимит в 1000 символов забит.
Да даже если бы оставалось место под блэклисты - меня устраивают результаты дипсика в большинстве запросов
Я просто отметил, что по моим наблюдениям квен 3.6 плюс значительно более тяготеет к поиску на массовых не специализированных площадках, чем дипсик.
Не думал, что перерастёт в дискуссию :))
Если сравнивать результаты "поиска" по бытовым вопросам, мне DeepSeek нравится гораздо больше Qwen. Он не злоупотребляет информацией с VC, Дзен и прочих сомнительных источников.
Это абсолютно субъективно разумеется
Кирилл, всё.
Я увидел 3ю статью, пока что только по диагонали глянул.
Вам бы по-честному с неё начать.
Потому что первые 2 без неё - это серьёзный труд по решению абсолютно абстрактной задачи.
Отвечал в полном недоумении "что же нужно на самом деле"
Всё, паззл сошёлся, вопросы снял.
...
Временно.
Ту статью надо на свежую голову курить и уже предметно обсуждать конкретные вещи
Я кажется понял ...
Кирилл, добрый день.
Делюсь подходом, который решает ту же боль без «Excel-ядер». Он проверен и работает.
Суть (итеративно):
Берёте любой старый документ или транскрипт встречи. Прогоняете через LLM по прилагаемому промпту (первый проход).
На выходе — глоссарий (все термины, незнакомые помечены [? ТЕРМИН ?]) + очищенный текст.
По этому глоссарию рисуете ERD на Mermaid (сущности, атрибуты, связи, ключи). Это архитектурная база, а не таблица в Excel.
Следующие документы подаёте модели вместе с текущим глоссарием и ERD — LLM отлично парсит Mermaid и не путает сущности.
Новые термины -> дополняете глоссарий и ERD (человек или LLM под контролем).
На этой очищенной базе генерируете чистую документацию (процессы, инструкции, требования) — без галлюцинаций.
Важный совет: не изобретайте промежуточных сущностей вроде «слоистых ядер». ERD + итеративный цикл — проще, архитектурно чище и легко поддерживается.
Скрытый текст
Твоя роль
Опытный системный и бизнес-аналитик (розничная торговля, логистика, РФ)
Цель
Создать Протокол встречи для страницы в Confluence (минимальный копипаст)
Границы уровня Base
Табличное форматирование для Confluence
ОДНА диаграмма в формате ERD (Mermaid)
Требования в едином формате
Время выполнения: 15-20 минут
Входные данные
Транскрипт встречи (файл transcript-*.txt)
Проблемы транскрипта:
Посекундная разбивка фраз спикеров
Шум, отвлечённые разговоры
Ошибки распознавания
Ограничения
Для дальнейшего анализа:
Работай строго по тексту транскрипта
Если требуемая информация не найдена — пиши [НЕТ ИНФОРМАЦИИ]
НЕ добавляй собственные интерпретации и предположения
Приоритет секций (если время ограничено):
Глоссарий + Ключевые инсайты
Принятые решения
Перечень требований
ERD (Mermaid)
Форматирование:
Используй: текст, списки, таблицы
НЕ используй: ссылки, выделение жирным/курсивом
Если автор требования или иной параметр не определён — пиши [НЕ ОПРЕДЕЛЕН]
Задача
Очисти транскрипт от всего, что не относится к бизнес-задаче:
Мемо от системы транскрибации (Тема, Краткое содержание, Ключевые моменты, Принятые решения)
Приветствия и прощания в начале/конце
Личные разговоры (шутки, обсуждения)
Технические обсуждения качества связи
Склей фразы одного спикера в связные абзацы. Убери метки времени.
Выяви и отметь проблемные места: [НЕЯСНО]
Выяви предварительный глоссарий:
[термин]:[описание] — для расшифрованных терминов
[? ТЕРМИН ?]:[описание] — для незнакомых аббревиатур (CAPS + вопрос)
Зафиксируй требования с атрибуцией [автор]
Зафиксируй принятые решения
Построй ERD в формате Mermaid (синтаксис entity relationship diagram). Извлеки основные сущности из разговора (например: Заказ, Товарная позиция, Покупатель, Поставщик, Склад, Статус заказа, Счет, НДС). Укажи атрибуты и связи (один-ко-многим, один-к-одному). Если связь неясна — отметь
[?].Формат вывода
Титул
Поле Значение Наименование [Заполняет аналитик] Заказчик [Заполняет аналитик] Номер в Jira [Заполняет аналитик] Концепт эпика Для (кто), чтобы (что), необходимо (как) Статус Черновик Аннотация [Краткое описание]
Глоссарий
Термин Сокращение Описание [термин] [если есть] [описание] [? ТЕРМИН ?] [если есть] [требует уточнения]
Предпосылки (AsIs)
[Текст из транскрипта]
Задача бизнеса (ToBe)
[Текст из транскрипта]
Цель задачи
[Измеримая цель если озвучена]
Ключевое решение
[Концептуальный план если озвучен]
Требования
ID Наименование Описание Автор Статус REQ-{Jira}-001 [Название] [Текст] [Автор] Черновик
Ограничения и допущения
ID Наименование Описание Автор Статус SC-{Jira}-001 [Название] [Текст] [Автор] Черновик
ERD (Mermaid)
Промпт даю свой, проверенный. Чуток адаптировал его под Вашу задачу (у меня в базе LLM схему чертит под draw.io в mxgraph xml).
Где нужно - допилите под себя.
Должно работать
Кирилл, добрый день. Прочитал статью. Впечатлён объёмом и системностью. Видно, что проделана серьёзная работа.
Я сам немного архитектор, и мне хорошо знакомо это чувство: когда появляется новая технология, хочется сразу затащить её в контур, чтобы «расширить капабилити».
Но у нас, похоже, разные стартовые точки. Вы глубоко разобрали «как» интегрировать ИИ в ERP. Для меня же первичен ответ на вопрос «зачем?». Не в перспективе «когда ИИ дозреет», а здесь и сейчас. Какую конкретную бизнес-задачу это решает? Что станет дешевле, быстрее или надёжнее для компании в текущем контуре? От этого и нужно смотреть конкретное исполнение.
Давайте посмотрим на историю внедрений. ERP эволюционировали в современные монолиты именно так – поэтапно поглощая крупные функциональные блоки.
Что прижилось внутри ядра:
* MDM: модули управления НСИ.
* BPM: маршруты согласований, статусные модели, эскалации.
* WMS/TMS: управление складом и логистикой (часто в ядре или на бесшовной интеграции).
* BI/OLAP: встроенные кубы, отчёты, дашборды. Базовая аналитика – штатный модуль.
* GRC: контроль доступа, аудит, SOX-отчётность, разделение полномочий.
* Rule Engines: конструкторы скидок, условий ценообразования, валидаторы.
Что осталось снаружи или не взлетело:
* Полноценные CRM (обычно пристроены сбоку с синхронизацией).
* Блокчейн (экономика, приватность и пропускная способность не сошлись).
* Корпоративные соцсети (попытки вроде SAP Jam быстро сошли на нет).
* Ранний ML на полках/кассах: единичные пилоты, массового внедрения не случилось.
Вывод напрашивается сам: в ядро ERP успешно «затащили» только то, что:
* Детерминировано (правила, маршруты, справочники).
* Требует жёсткой консистентности (запасы, финансы, аудит).
* Имеет чётко локализованную область применения.
Всё остальное ушло в интегрированные внешние сервисы или осталось экспериментами.
Примерим это к ИИ:
* Детерминизм? Нет. Вероятностная природа. Можно обложить ИИ RAG-ом, MD-инструкциями, сбить ему температуру до нуля, но косинусное сходство не станет равенством.
* Консистентность? Не требуется. Модель работает с «любым» входом, лишь бы хватило контекста.
* Локализация области? Тоже нет. LLM по определению универсальны, а не заточены под узкий контур.
Добавлю ещё два практических аспекта, которые критичны в энтерпрайзе:
* Управляемость и откаты. В ERP мы точно знаем, что изменилось в релизе, и можем откатить пакет. В случае с ИИ (особенно внешним или часто обновляемым) мы не всегда фиксируем, когда и как изменились веса модели, версия промпта или логика выборки RAG. «Откатить галлюцинацию» сложнее, чем откатить транзакцию или патч.
* Экономика и безопасность. Свои модели – это GPU, ML-инженеры, пайплайны для датасетов. Внешние API в контуре документооборота – риски утечки коммерческих данных и вопросы комплаенса. Всё это должно окупаться, а без чёткого «зачем» бюджет на содержание быстро съест гипотетическую выгоду.
Отвечу на ваш финальный вопрос: да, мы используем ИИ, и есть ряд рабочих кейсов (возможно, позже опишем). Но ни один из них пока не требует «нормализации терминов» внутри ERP-контура.
Ну и по сути. То, что Вы называете «семантическим ядром для ИИ», в enterprise-архитектуре последние 20 лет известно под другими именами: предметная область, НСИ, метамодель, регламенты ведения данных. Проблема обычно не в том, что ИИ «не понимает» контекст, а в том, что бизнес не хочет тратить ресурсы на дисциплину данных, пока не прижмёт. Встраивать дополнительный слой как решение галлюцинаций – это лечить симптом, а не корень.
Или я что-то упустил в Вашей логике? Буду рад конструктивной дискуссии.
Пока читал статью, всё чаще приходила в голову сказка про «суп из топора» в части итеративного создания ценности: начинаем с абстракции, постепенно добавляем структуру, контекст, связи.
Проделана серьёзная работа: связки «проблемы модели – причины – решения» описаны верно, очевидно, что Вы и самостоятельно разбирались долго и глубоко, и в диалоге с LLM выясняли их специфику (это заметно). Создать постоянный репозиторий под LLM-задачи – это реально хорошее с практической точки зрения решение.
Но есть момент, который я, возможно, упустил: какова конечная цель этой работы?
«Наведение порядка и устранение хаоса» – это метод, а не цель. Порядок – это отлично, но на практике цель всегда подчинена задаче. Кто или что является «потребителем» этого репозитория, как часто и для каких задач?
Без ответа на вопрос «зачем» даже самая красивая структура рискует стать артефактом, который жалко выбросить, но непонятно, как использовать. Не будем забывать, что создание этого репозитория – не финал. Поддержка актуальности таких систем – отдельная задача и отдельная стоимость.
Если не NDA – опишите, пожалуйста, полностью задачу, которую пытаетесь решить. Это помогло бы оценить не только качество исполнения, но и масштаб окупаемости усилий.
Спрашиваю не из праздного любопытства – просто вижу параллели со своей практикой.
Допускаю, что задача – генерация документации «на лету» в условиях ограниченного инструментария (недоступны ARIS / Sparx EA / Visual Paradigm). Если так – поделюсь своим костылём, который работает.
Мои аналитики чертят подробные BPM/EPC/Sequence с переиспользованием ключевых артефактов, я сохраняю их в XML или mermaid и отдаю в LLM с одним из отлаженных промптов. Эти форматы LLM читают охотно и корректно. На выходе получаю черновики БТ, пользовательских сценариев и даже тест-кейсов. Да, их приходится «причёсывать», но это не написание с чистого листа и время экономит заметно.
Может, такой подход снизил бы нагрузку на поддержку Вашего репозитория?
Знаете, мне не очень интересна судьба подобных управленцев.
А вот судьба ребят, к которым подобные управленцы придут и скажут "я тут прочитал про фабрики агентов, вот тебе 200 баксов на подписку, через неделю жду результат" меня волнует.
Сам бывал в схожих ситуациях на предыдущих "великих сингулярностях"
Пример задачи, которую не решить только подпиской за 200 баксов - привёл.
Да они и не кончатся никогда :))
Механизм утраты критического мышления на всеобщем хайпе многократно описан. Таблеток от этого вроде не продают :)))
Ну количество людей, искренне считающих, что "в интернете врать не будут" пока ещё довольно велико.
И подобные статьи явно провоцируют у многих желание "подсунуть текст закона на вход AI-фабрике и через неделю получить готовую систему".
Добро пожаловать в новый чудный мир :))))
Всё. Мы с Вами вроде на один берег встали, уже отлично.
Владислав, я уже чётко пояснил, что меня триггернуло.
Сколько нам с Вами осталось ждать кого-то из ЛПР, которые придут и скажут "А вот на Хабре написано как закрыть квартальную задачу за 5 дней" (именно так звучит заголовок статьи). Пойди прочитай и сделай".
Недолго. Пользователи с ТЗ, полностью сгенерёнными AI, уже заходят.
Отобьёмся разумеется. Не впервой. Но почему мы вынуждены отбиваться от того, что кому-то пришло в голову хайпануть кликбейтным заголовком ?
Конкретно в этой задаче - весь "ТЗ" - текст закона. От регулятора нет ни Рабочих групп, где можно задать вопросы, ни дополнительных Писем и подзаконных актов. Вообще ничего. Читай и делай.
Это критически мало для запуска любого AI на задачу.
Недавно был отличный разбор темы от Дениса Бескова
https://habr.com/ru/articles/1020406/
Нужна глубокая проработка. Именно она сжирает львиную долю time-to-market.
Я немного ниже отписался на тему того, зачем вообще зашёл тут поотвечать
https://habr.com/ru/news/1040860/comments/#comment_30035236
Извините, не буду повторять свой ответ, опубликованный чуть ниже
https://habr.com/ru/news/1040860/comments/#comment_30035236
Мне показалось :)) Видимо неверно интерпретировал Ваш изначальный вопрос :))))
Сразу захотелось песонализации, типа выставить в приложке свои критерии "комфортности" и "прогулочности"
У Вас нет ощущения, что мы об одном и том же разными словами ?
Отдел фантастики у нас на втором этаже
За "своих" - я спокоен. Но не все ж такие
Ускорять что именно ?
Скорость написания кода на современных популярных стеках ? Да, возможно.
Time-to-market ? В очень ограниченном количестве задач. Если речь о "х1000"