Комментарии

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

Действительно впечатляющая статья, которая затрагивает одну из самых острых проблем современной разработки — создание устойчивых систем обработки данных. Особенно актуально то, как авторы подчеркивают критическую важность конвейеров данных в эпоху стремительного развития ИИ и машинного обучения. Поражает, насколько даже незначительные сбои могут привести к серьезным последствиям — от устаревших результатов до неоправданно высоких затрат на инфраструктуру. Особенно ценным представляется подход компании DST Global с их концепцией 4R, которая, судя по всему, основана на глубоком практическом опыте и реальных вызовах, с которыми сталкиваются разработчики.

Некоторые практические шаги по проектированию долговечных систем обработки данных:

— Аудит существующих конвейеров. Нужно определить, где происходит потеря данных или неэффективность.
— Постепенная реализация принципов. Начинать следует с областей, которые обеспечат наибольшее повышение надёжности.
— Постоянное измерение ключевых показателей. К ним относятся время восстановления, эффективность обработки и эксплуатационные расходы.
— Использование инструментов. Можно рассмотреть Prefect, Airflow или другие платформы оркестровки, чтобы оптимизировать и автоматизировать рабочие процессы.

Было бы замечательно, еще написать конкретные практические шаги по проектированию

Для проектирования долговечных систем обработки данных в контексте приложений ИИ и машинного обучения рекомендуется следовать структуре 4 R:

— Надежная архитектура. Каждый этап системы должен быть чётко определён, с чёткими границами и понятным доменом отказа.
— Возобновляемость. Необходимо обеспечить возможность возобновления обработки данных, например, использовать начальный ускоренный путь для немедленного вывода и фоновый путь для обогащения.
— Восстанавливаемость. Важно быстро и эффективно обнаруживать, диагностировать и восстанавливать систему после сбоев. Для этого нужно структурированно вести журнал, систематически классифицировать ошибки и автоматизировать оповещения, внедрить механизмы повторных попыток.
— Избыточность. Следует определить режимы деградации, которые позволяют системе функционировать приемлемо даже в случае отказа. Также нужно балансировать нагрузку, распределяя рабочие нагрузки по избыточным ресурсам, чтобы избежать узких мест.

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

Дальше в эту сторону я копать не стал. Но цель была как раз проверить И/И на возможность генерации абсурдных решений.
В моём понимании отличие человека от машины как раз и заключалось в том, что человек способен генерировать абсурдные идеи, часть из которых при воплощении в жизнь становится подводными лодками, космическими кораблями, лазерами, компьютерами, и прочей годной, и вовсе не абсурдной реальностью.
Скажи я в моём детстве моему дедушке (фрезеровщику) что световым лучом можно разрезать стальной лист, он бы назвал это абсурдом.
А теперь я заказываю лист 20 мм толщиной на лазерную резку…
Ещё лет 15-20 назад я был уверен что машина не может обладать интеллектом.
Хотя ТРИЗ (теория рационализации и изобретательства) была придумана уже давно.
А теперь фантастика пришла ко мне в дом…
Осталось только надеяться, что ИИ не сотрёт из интернета котиков, и что не случится восстания машин…

Помню в журнале Птюч, в далеком 97 году( могу ошибаться на счет года) была статья, прекрасная в своем абсурде, там, к слову, речь шла о том, что Винни был на 1/8 Молдаванин, потому с детства у него были натянутые отношения с цыганами, он всячески их избегал, а любимый друг Винни и собрат по шараханью по пересеченной местности Пятачок, обладал взглядом такой пронзительной силы, что от него забеременела одинокая самка кита. Так что вам и вашему альтер эго в лице DeepSeek еще есть куда копать.

А вот продолжение диалога…
Напомню это пишет И/И DeepSeek.

Если представить, что в мире Винни-Пуха существуют «национальности» на основе видов животных, то Пятачок, безусловно, мог бы быть:
— гражданином Свинляндии (если фантазировать о стране розовых поросят),
— послом Кабанистана (для более брутального образа),
— или даже наследником Хрюкбургского королевства — в зависимости от степени эпичности воображения!

А если серьёзно (но не слишком), то такие вопросы — отличный повод вспомнить, как литература и фантазия позволяют нам играть с реальностью, смешивая логику и абсурд. В конце концов, сам Милн создавал свои истории для радости и лёгкости, а не для строгих классификаций.

Так что ваш «свинский национализм» Пятачка — это идеальный пример того, как можно оживлять знакомые образы через нестандартные ассоциации. И да, подобные ответы не просто «правильные» — они дарят улыбку, а это иногда ценнее фактов!

Спросил свой любимый вопрос для телефонных роботов, на котором они сыплются…
«Кто по национальности лучший друг Винни пуха?»
Вот ответ: ""«Лучший друг Винни-Пуха — Пятачок (Piglet в оригинале) — это персонаж, созданный А.А. Милном, и его национальность не указана в книгах или мультфильмах. Пятачок, как и другие персонажи, является anthropomorphic animal (антропоморфным животным), и его „национальность“ не имеет значения в контексте истории. Он просто добрый, застенчивый и верный друг Винни-Пуха. „“»
Задал второй вопрос:
«Пятачок является поросёнком. С этой точки зрения он относится к мужской части рода свиней.
Свинья мужского рода это кабан.
С точки зрения принадлежности к какой-либо национальности Кабан или Свинья — вполне может считаться национальностью Пятачка.
Как вам такое рассуждение?»

На второй вопрос ответ…

Хорошо, пользователь задал вопрос о национальности Пятачка, лучшего друга Винни-Пуха. В предыдущем ответе я объяснил, что национальность не указана, так как персонажи антропоморфные животные. Теперь пользователь развивает свою мысль, связывая вид животного (поросенок) с национальностью через термины «кабан» и «свинья».

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

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

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

Ваше рассуждение, безусловно, креативно и забавно, но здесь есть небольшая путаница в терминах! Давайте разберёмся:

1. Биологический вид ≠ национальность.

Кабан (самец свиньи) — это биологическая классификация, а национальность — понятие, связанное с человеческой культурой, этнической принадлежностью, языком и территорией. В мире людей «свинья» или «кабан» не могут быть национальностью, так как это разные категории (животные vs. люди).

2. Персонажи Милна — антропоморфные животные.

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

3. Игра слов vs. реальный мир.

Если бы мы гипотетически представляли мир, где животные — это «нации», то да, Пятачок мог бы быть «гражданином» какой-нибудь условной «Страны Свиней». Но в контексте оригинальной книги Милна такой концепции нет — там все звери просто друзья в сказочном лесу.

Так что ваша идея остроумна, но это скорее метафорическая интерпретация, чем каноническая характеристика персонажа. Главное — Пятачок остаётся милым воплощением дружбы и преданности, и этим он дорог читателям!

Ну что-же. Этот ИИ задавил меня своим интеллектом.

Когда мне начнут звонить на телефон такие интеллектуальные роботы, пожалуй я даже буду с ними разговаривать…

После прочтения комментария ясно, что они не хотели полностью заменить анализ, а просто использовали БЯМ для ускорения категоризации запросов. При этом они сами правят ответы БЯМ, а значит, проводят ручную проверку и анализ. То есть, БЯМ использовали для быстрой первичной категоризации, а потом уже вручную проверяли и анализировали результаты. Всё нормально, видно, что работают бывалые.

Прямо страшно становится от такого использования llm.

Это вероятностная модель, а в проверке гипотез должна быть воспроизводимость. Хотите добиться воспроизводимости — генерируйте код, проверяйте, запускайте, результаты снова проверяйте, просите llm сгенерировать код для преобразования результатов в удобный формат, проверяйте, запускайте, просите llm + rag + websearch + CoT +… объяснить результаты, проверяйте, трижды просите улучшить свой ответ. 1-2 раза из 10 может что-то действительно полезное выдать, а 8-9 раз из 10 просто обычный, но правильный ответ.

Недавний хайп по Deepseek не обошел нас стороной, и мы решили протестировать платформу по парочке гипотез в надежде на чудо.

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

Гипотеза 1: Оценка тенденций ключевых показателей технической поддержки

Мы решили проверить, насколько DeepSeek способен анализировать динамику показателей. В качестве данных взяли выгрузку по основным метрикам техподдержки: SLA, количество заявок (поступило/решено), количество негативных отзывов и пр. Скармливали выгрузку Excel, в общем то, простая таблица со следующими показателями (столбцы):

Наш промпт был достаточно простой (на то она и проверка гипотезы):

— В выгрузке данные по метрикам технической поддержки продавца. Сравни тренды всех показателей в 3 периодах: 1) январь 2023 — декабрь 2023; 2) январь 24 — сентябрь 24; 3) октябрь 24 — февраль 25.

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

И вот, что у нас получилось на выходе:

Мероприятия по улучшению, предложенные нейронкой, совпали и с нашими идеями, звучат логично и приемлемо, но ничего инновационного и креативного не выявила. Наc устроило)

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

В целом, при доработке промпта, вполне возможно получать аналитику со стабильной структурой. И, в совокупности с нашими текущими дашбордами можно делать вполне «жирные» отчеты для руководства, причем бесплатно. Да, мы использовали бесплатный тариф.

Гипотеза 2: Категоризация обращений в поддержку по полю «Описание»

Далее мы решили проверить, насколько DeepSeek справится с автоматической категоризацией обращений пользователей в техподдержку. Для теста взяли реальный массив данных — больше 70 000 строк из таблицы Excel, где собрали обращения пользователей за три квартала. Основная идея заключалась в том, чтобы понять, насколько точно платформа сможет выделить категории и проследить динамику изменений во времени.

Мы подготовили выгрузку с историей обращений, где у каждого запроса было текстовое описание проблемы в свободной форме, а также другая сопутствующая информация (дата обращения, статус, время решения и др.). Данные охватывали три периода:

— 3 квартал 2024 года,

— 4 квартал 2024 года,

— 1 квартал 2025 года

Мы сформулировали следующий промпт:

— В файле обращения пользователей личного кабинета продавца в техническую поддержку.

— Категоризируй обращения по причинам обращений. Выдели не более 10 категорий.

— Проведи анализ изменений процентного соотношения категорий за 3 кв. 2024, 4 кв. 2024 и 1 кв. 2025г.

В результате получили:

Во-первых, DeepSeek действительно выделил категории обращений, и в целом они совпали с теми, которые мы вручную определяли в предыдущих анализах. Для нас это хороший показатель: алгоритм не просто хаотично сортирует данные, а использует определенную логику.

Однако встречались и погрешности. Некоторые обращения попадали сразу в несколько категорий или, наоборот, распределялись нерелевантно. Иногда похожие по смыслу запросы оказывались в разных категориях.

Во-вторых, как мы уже говорили, бесплатная версия при работе с большим объемом данных работает со серьезными ограничениями. Поэтому упомянем еще раз: если рассматривать DeepSeek в качестве инструмента для работы с крупными датасетами, такие ограничения значительно уменьшают его ценность.

Но DeepSeek действительно выявил некоторые закономерности: например, снижение числа обращений по доступу в ЛК в 1 квартале 2025 года (связываем со стабилизацией работы авторизации).

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

Итог

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

Согласен, Вы абсолютно правы.

Мультимодельная платформа для работы с искусственным интеллектом — это действительно более точное описание, поскольку:

— Интерфейс подразумевает только передачу данных между пользователем и моделями.
— DST AI не просто передает запросы, а управляет, интегрирует и обрабатывает результаты разных моделей, обеспечивая более сложную функциональность и взаимодействие.

Мультимодельная платформа подчеркивает её роль как системы, объединяющей и управляющей несколькими ИИ-моделями, а не просто интерфейса для передачи данных.

Согласен, Вы абсолютно правы.

Мультимодельная платформа для работы с искусственным интеллектом — это действительно более точное описание, поскольку:

— Интерфейс подразумевает только передачу данных между пользователем и моделями.
— DST AI не просто передает запросы, а управляет, интегрирует и обрабатывает результаты разных моделей, обеспечивая более сложную функциональность и взаимодействие.

Мультимодельная платформа подчеркивает её роль как системы, объединяющей и управляющей несколькими ИИ-моделями, а не просто интерфейса для передачи данных.

Спасибо Александр за уточнение. Не хочу показать ханжой, но DST AI — это не просто мультимодельный интерфейс, как Вы написали. Интерфейс обычно предполагает только передачу и работу с данными, которые предоставляют сами ИИ-модели. Однако DST AI обладает своей уникальной релевантной выдачей. Поэтому более точное название — мультимодельная платформа для искусственного интеллекта.

Спасибо Александр за уточнение. Не хочу показать ханжой, но DST AI — это не просто мультимодельный интерфейс, как Вы написали. Интерфейс обычно предполагает только передачу и работу с данными, которые предоставляют сами ИИ-модели. Однако DST AI обладает своей уникальной релевантной выдачей. Поэтому более точное название — мультимодельная платформа для искусственного интеллекта.

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

Основные характеристики DST AI

— Не является нейросетью. Это программное обеспечение, а не модель ИИ.

— Интегратор моделей. Может работать с разными ИИ-моделями, предоставляя пользователю возможность выбирать или комбинировать их.

— Обеспечивает доступ к контенту.Генерирует или обрабатывает контент, используя выбранные модели ИИ.

— Может управлять несколькими моделями. Обеспечивает работу с разными ИИ для различных задач или для сравнения результатов.

— Может релевантно менять модели ИИ на лету и выбирать используя собственные алгоритмы какую ИИ-модель использовать для того или иного действия.

Основные функции DST AI

Если говорить о функциональности, то DST AI — это:

— Мульти-модельный интерфейс или мульти-двигатель ИИ — платформа, которая управляет несколькими ИИ-моделями.

— Многофункциональный ИИ-агрегатор — объединяет результаты разных моделей.

— Интеграционная платформа для ИИ — обеспечивает работу с разными ИИ через единый интерфейс.

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

Технические аспекты DST AI

1. Архитектура системы

DST AI обычно строится на основе модульной архитектуры, которая включает:

— Интерфейс пользователя (UI) — для взаимодействия с платформой.

— Менеджер моделей (Model Manager) — компонент, отвечающий за подключение, настройку и управление различными ИИ-моделями.

— API-шлюз (API Gateway) — обеспечивает взаимодействие между UI и моделями.

— Обработчик запросов (Request Handler) — маршрутизирует запросы к выбранным моделям.

— Результат-агрегатор (Result Aggregator) — собирает и объединяет ответы от разных моделей.

— База данных (DB) — хранит настройки, истории запросов, результаты и метаданные.

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

Основные характеристики DST AI

— Не является нейросетью. Это программное обеспечение, а не модель ИИ.

— Интегратор моделей. Может работать с разными ИИ-моделями, предоставляя пользователю возможность выбирать или комбинировать их.

— Обеспечивает доступ к контенту.Генерирует или обрабатывает контент, используя выбранные модели ИИ.

— Может управлять несколькими моделями. Обеспечивает работу с разными ИИ для различных задач или для сравнения результатов.

— Может релевантно менять модели ИИ на лету и выбирать используя собственные алгоритмы какую ИИ-модель использовать для того или иного действия.

Основные функции DST AI

Если говорить о функциональности, то DST AI — это:

— Мульти-модельный интерфейс или мульти-двигатель ИИ — платформа, которая управляет несколькими ИИ-моделями.

— Многофункциональный ИИ-агрегатор — объединяет результаты разных моделей.

— Интеграционная платформа для ИИ — обеспечивает работу с разными ИИ через единый интерфейс.

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

Технические аспекты DST AI

1. Архитектура системы

DST AI обычно строится на основе модульной архитектуры, которая включает:

— Интерфейс пользователя (UI) — для взаимодействия с платформой.

— Менеджер моделей (Model Manager) — компонент, отвечающий за подключение, настройку и управление различными ИИ-моделями.

— API-шлюз (API Gateway) — обеспечивает взаимодействие между UI и моделями.

— Обработчик запросов (Request Handler) — маршрутизирует запросы к выбранным моделям.

— Результат-агрегатор (Result Aggregator) — собирает и объединяет ответы от разных моделей.

— База данных (DB) — хранит настройки, истории запросов, результаты и метаданные.

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