Kurgan-Telecom Ru | Информационные технологии

Для начала давайте убедимся, что наш VPS находится в самом актуальном и обновленном состоянии. Подключаетесь к VPS через SSH. Запустите следующие команды, чтобы обновить систему и установить необходимые пакеты...

Привет, Хабр! Меня зовут Даниил Сухан, я занимаюсь разработкой AI-приложений в Just AI. Недавно вышедший AgentKit от OpenAI быстро стал одним из самых обсуждаемых инструментов в сообществе разработчиков.

Мы протестировали платформу для создания ИИ-агентов от OpenAI и сравнили её с нашей Agent Platform. В этой статье разбираем, как создаются агенты на обеих платформах, и в чём заключаются их принципиальные отличия.

Постановка проблемы. Современные промышленные предприятия требуют принципиально новых решений, направленных на прогнозирование отказов работы оборудования и своевременное устранение нештатных аварийных ситуаций, управления затратами на ремонт, а также оптимизации и улучшения стратегий технического обслуживания. Существующие автоматизированные системы прогнозируемого обслуживания имеют различные функциональные ограничения. Это требует разработки новых архитектурных решений для создания интеллектуальных систем, способных обрабатывать большие объемы разнородных данных в режиме реального времени, прогнозировать отказы с высокой точностью и оптимизировать процессы плана обслуживания, в тесной взаимосвязи с работой устройств промышленного Интернета вещей в условиях использования новых технологий периферийного искусственного интеллекта. Данная работа посвящена исследованию возможности применения большой языковой модели OpenThinker2-32B, как вспомогательного инструмента для автоматизированной системы прогнозируемого обслуживания многостадийных технологических процессов. Данная модель может быть использована в реализации следующих функций автоматизированной системы: анализ исторических данных; прогнозирование оставшегося срока службы оборудования; подготовка данных для снижения факторов неопределенности данных для улучшения прогнозов; подготовка экспертных заключений; оптимизация расписаний по техническому обслуживанию промышленного оборудования.

Цель работы. Изучить возможность применения и адаптации большой языковой модели OpenThinker2-32B, как дополнительного и вспомогательного инструмента, применяемого для повышения эффективности работы автоматизированных систем прогнозируемого обслуживания многостадийных технологических процессов для малых и средних промышленных предприятий. Это позволит решить следующие задачи: выполнить анализ исторических данных; с помощью алгоритмов, разработанных на основе теории свидетельств Демпстера-Шафера снизить факторы неопределенности произвести прогнозирование отказов, а также подготовить экспертные рекомендации по оптимизации расписаний и процессов технического обслуживания промышленного оборудования. Также необходимо разработать алгоритмы информационного взаимодействия для каждой из задач, и определить положение большой языковой модели в предложенной концепции конвергентной архитектуры автоматизированной системы прогнозируемого обслуживания для повышения точности прогнозов и возможности ее интеграции с экспертными, аналитическими, прогнозными системами и системами поддержки принятия решений.

Всем привет. Ранее яуже публиковал статьи (раз и два), где рассказывал о проблемах IDEA Maven плагина, основная из которых — это импорт проектов. И о своем решении Easy Maven, как получить информацию о проекте с помощью нативного Maven плагина. Теперь я бы хотел поговорить о запуске и отладке проектов в IDEA. С ними на самом деле похожая проблема. Чтобы это все работало, нужно импортировать в IDEA все настройки компилятора из билд файлов, чтобы среда разработки могла сама компилировать и запускать проект. Но это не так то просто — постоянно появляются новые параметры и возможности компиляторов, также для каждого из JVM языка (Java, Kotlin, Groovy, Scala и так далее) есть свой компилятор со своими особенностями, annotation processors — которые надо дополнительно распознавать и загружать как jar‑файлы с их транзитивными зависимостями и импортировать в IDEA. Постоянно нужно за всем этим следить и нам опять приходить играть в догонялки. Только мы всегда находимся на шаг позади в роли отстающих и нужно тратить много ресурсов, чтобы заставить запускаться проект корректно из IDEA. Поэтому я решил и тут пойти другим путем — а зачем нам вообще все это делать и переносить настройки в IDEA, если мы можно просто выполнить Maven таск для соответствующего плагина — запуск теста или приложения? Поэтому я хотел бы остановиться на этом поподробнее и рассказать о своем решении.

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

В этой статье разбирается, как с нуля собрать минимально полезного бота для малого бизнеса (например, магазина одежды или студии услуг) на Python и библиотеке aiogram 3.x: от получения токена до развёртывания на сервере. Статья рассчитана на разработчиков, которые уже базово знакомы с Python, но ещё не работали с Telegram Bot API или современными фреймворками для ботов.

​​

За годы работы в бигтехе я работал с десятками плохих менеджеров. В статье — топ-7 паттернов слабого управления. Кратко и по делу объясняю, почему они возникают и что с этим можно сделать.

В современных реалиях объёмы данных постоянно растут и появляются всё более жёсткие требования к производительности. Тут традиционный PostgreSQL сталкивается с фундаментальной проблемой: отсутствие нативной поддержки горизонтального масштабирования. 

Сегодня мы, команда платформы данных в Yandex Cloud, хотим рассказать о SPQR — нашем опенсорс‑инструменте, который который создавался как ответ на боль шардирования и эксплуатации крупных OLTP‑систем. Под катом — история о том, что стало отправной точкой для его создания, какие задачи он помогает решать, на чём основано наше решение и что помогает ему быть довольно простым в эксплуатации.

Привет, постоянные и не очень читатели!

Пора вернуться к моим любимым архитектурам, процессорам, техпроцессам и всему причастному. Это седьмой и САМЫЙ масштабный материал из цикла (и, вероятно, во всём Рунете) про китайские ISA, микроархитектуры и микроэлектронику.

Что было раньше:

Part I: Скандальное разоблачение x86: ARM врывается с двух ног (58K, +61, 160 комментариев)

Part II: Этой индустрии нужен новый герой: ARM врывается с двух ног 

Part III: Китайский киднэппинг: похищение дочки 

Part IV: RISC‑V — звезда родилась: x86 не у дел, ARM сломала две ноги (67K, +64, 207 комментариев)

Part V: Смерть GPU/CPU на транзисторах — архитектура квантовых компьютеров

Part VI: У VLIW длиннее x86: Itanium в шаге от величества, Эльбрус — подержите моё пиво, тайны PS2 

Part VII: Как китайцы x86 и ARM убили и создали своё — детектив в Восточном экспрессе ← ВЫ ЗДЕСЬ

Part VIII — ██████████████.

В этом лонгриде я расскажу вам всё о серверных процессорах из Поднебесной на всех ключевых архитектурах: ARM (Huawei), x86 (Zhaoxin), RISC-V (T-Head) и LoongArch (Loongson). Будет и про строящиеся мегафабрики Huawei, и про создание независимой ISA (как наш Эльбрус, но с конкурентными продуктами и производством), и про китайские лицензированные x86-процессоры, и про многое другое.

Бонусом в каждом разделе распишу интересные факты про иероглифы в названиях компаний и их продуктах (символизм в китайской культуре). Например, вы узнаете, как компания Медоед куёт свои процессоры из легендарной стали (образно), чтобы бесстрашно сражаться с западными техногигантами (буквально). И это не шутка, а оммаж на мемы про медоедов.

Дамы и господа — Восточный экспресс готов к посадке. Пожалуйста, позвольте стюарду проводить вас к личному купе.

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

Видимо по этой причине, одним мрачным осенним днем мне захотелось создать графическое приложение на современном C++ под.. классический Mac из 90х.

Детекция мусора в гречке с помощью нейросети YOLO8n + попытки в real-time детекцию (Docker + FastApi, Gradio, TensorFlow Lite) + предложение добавить такую фичу в приложения продуктовых магазинов. За результатами приглашаю в статью.

История о том, как один грамотно настроенный воркфлоу на n8n может стоить дороже команды разработчиков. Рассказываю честно: как я продал своего чат-бота по цене взноса за квартиру в Москве и почему рынок автоматизации сейчас перегрет запросами. Разбор кейсов: «оживление» лидов за 5 минут, работа с API OpenAI и интеграция ИИ агентов в реальный сектор (на примере продажи элитных собак). В конце делюсь лайфхаками и ресурсами, которые помогли мне обучить этому 700+ человек.

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

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

Обожаю игры серии GTA (все, кроме четвертой части). Я бы даже сказал, что многое в них прекрасно: разнообразие сюжетных миссий, выбор транспорта, классные диалоги, тонкая ирония, саркастичный юмор, высмеивание проблем общества, свобода действий, возможность устроить локальный апокалипсис. Однако все это портит поведение ботов-водителей, которые словно намеренно бросаются наперерез игроку, чтобы усложнить ему жизнь. Но так ли это? Действительно ли поведение NPC на дорогах GTA заскриптовано так, чтобы мешать геймерам? Прошу под кат — в поисках правды будем подглядывать за ботами и залезать туда, куда Рокстары не хотят нас пускать.

Привет! Я — Лёша Белов, продуктовый аналитик в команде Отелей сервиса путешествий Туту. Рано или поздно в любом продукте встает вопрос о том, как успевать отлавливать аномалии в аналитических логах и метриках. В статье расскажу о нашем подходе к алертингу и поделюсь кодом, с помощью которого продуктовый аналитик может за пару часов самостоятельно настроить базовый алертинг.

Проброс USB по сети часто нужен в виртуальных средах. В 1С нужно пробрасывать USB ключи лицензирования, для VDI токены налоговой и все это тоже нужно импортозамещать в Linux. Вот только то, что просто делается в Windows - в Linux превращается в спецоперацию с далеко идущими последствиями.

В поддержку Mindbox ежегодно поступает более 50 000 обращений. Чтобы справляться с таким потоком, требуется 16 специалистов поддержки. Они разбирают документацию, находят ответы и помогают клиентам.

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

Теперь бот закрывает 15–20% запросов и отвечает за 25 секунд. Нагрузка на команду поддержки снизилась, а удовлетворенность клиентов (CSAT) AI-помощником поддержки составила около 90%. В этой статье — кейс, как нам удалось сделать такого бота своими силами. 

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

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

Ранее я не раз затрагивал на Хабре тему древнего марсианского климата, и эта тема пришлась сообществу по вкусу. Считаю, что наиболее интересными получились статьи «Удушливые озёра гесперийского периода. Модели углекислотной гидросферы Марса» (+57), «Последнее лето Марса» (+60) и «Когда Олимп был островом» (+37). Определённо, вам доводилось читать, что рельеф и осадочные породы Марса, к настоящему времени изученные роверами в разных регионах планеты, указывают, что ранее климат на этой планете был значительно более тёплым и влажным, чем сегодня.

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

Это несоответствие, впервые отмеченное в середине 1970-х, великий астроном Карл Саган сформулировал как «Парадокс слабого молодого Солнца» (Faint Young Sun Paradox). Под катом будет подробнее разобран данный парадокс, а также проанализированы некоторые версии, призванные его объяснить.

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

В этой статье разберём, как настроить полный сценарий: от вебхуков в МТС Exolve до автоматической оценки звонков с помощью GigaChat и LangChain. По разным исследованиям, менеджеры по качеству тратят до 60% рабочего времени на прослушивание диалогов и при этом успевают проверять лишь 5–10% звонков. Мы соберём сервис на Python, который автоматически обрабатывает каждый звонок, расшифровывает аудио, прогоняет диалог через модель и возвращает структурированный JSON по чек-листу оценки оператора. Такой подход снижает ручную нагрузку и даёт воспроизводимую оценку в реальном времени.

Признавайтесь, уже собрали свой daily streak в Duolingo? Если нет, то вы точно знаете хотя бы одного человека, который делает это регулярно, ведь MAU Duolingo 130млн человек.

Что заставляет пользователей заходить в это приложение каждый день на протяжении многих месяцев, а то и лет? Скорее всего это не просто сила воли и не желание выучить английский. Это — магия геймификации.