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

28 мая вышел Opus 4.8 — через 41 день после 4.7 и с Dynamic Workflows, на которых переписали Bun. Через два дня появился DeepSWE и поставил под сомнение весь лидерборд, включая только что вышедший Opus. Enterprise-клиент без лимитов сжёг $500M за месяц. DeepSeek набирает команду для создания своего агента. А в MySQL закрыли 21-летний баг.

В продуктах, построенных поверх моделей распознавания речи (Automatic Speech Recognition models, ASR), качество распознавания речи напрямую влияет на пользовательский опыт.

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

В августе прошлого, 2025 года, я рассказал о создании собственной чёрно-белой темы для GNU Emacs. Почти год безсменно я её использую и не испытываю никаких проблем (скриншот позволяет в этом убедиться). Но рассказ будет не про это, а про то, как выглядит техника создания собственной темы для Emacs. Для тех, кто подумал, что будет также скушно и сложно, как и в рассказах про создание собственного пакета и режима для Emacs, да, это так, только не сложно.

После выхода новой локальной модели Qwen 3.5 мне захотелось проверить не абстрактный бенчмарк, а более приземленную вещь: можно ли отдать маленькой локальной модели обычную задачу из backend-разработки и получить рабочий результат.

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

Про подход, железо и выводы подробно описано в статье.

Кажется, что в ИИ чатах интерфейс довольно вторичен: ты пишешь, модель тебе отвечает, особо больше ничего и не надо (если модель отвечает хорошо). Но интерфейс очень влияет на то, насколько правильное решение вы примете, и насколько легко будет найти ошибку модели. Я собрала несколько научных исследований, которые могут пригодится тем, кто делает ИИ фичи в своих продуктах.

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

В итоге я интегрировал это в свой пет-проект, и в итоге сделал так, что браузер в аренду может взять любой желающий. Заодно сделал SDK, CLI и доки. Вот моя история погружения в пучину безумия.

Ваши UI‑автотесты снова «иногда падают», а команда уже привычно лечит это ретраями? Проблема может быть не в CI и не во фронтенде, а в том, что тест ждёт не то состояние интерфейса.

Разбираем пять ошибок в ожиданиях Selenium, из‑за которых автотесты превращаются в лотерею.

Я ожидал, что прогнозирующий контроллер обгонит HPA на коротком пике. Но в Kubernetes всё упёрлось не только в алгоритм: пик длился 30 секунд, а новые Pod становились Ready примерно через 40.

Привет, Хаброжители! Более десяти миллиардов строк кода C++ в настоящее время используется в реальных проектах, и 98 % разработчиков ежедневно находят и исправляют в них ошибки. Даже в критически важных приложениях встречаются баги, проблемы с производительностью и читаемостью. Эта книга поможет выявить их в коде, который вы поддерживаете, и избежать — в коде, который вы пишете.

«Самые прекрасные решения, основанные на анализе огромного количества данных и обещающие миллионы рублей экономии, будут бесполезны, если клиент или его бизнес не будут способны их внедрить».

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

Если у вас пет-проект или небольшой стартап на GitLab.com, рано или поздно вы упрётесь в потолок бесплатного тарифа: 400 минут пайплайнов в месяц и общая очередь раннеров. Покупка дополнительных минут стоит денег и не решает вторую проблему: общие раннеры GitLab обслуживают миллионы проектов, и в часы пик ваша джоба может провисеть в очереди 10-20 минут.

Решение — свой GitLab Runner на VPS: без чужих джоб, под полным контролем. Такой раннер не имеет лимитов по времени, кроме ресурсов самого сервера. В статье за вечер собираем такой раннер с нуля на Ubuntu 24.04 LTS, поднимаем пайплайн на три стадии (тесты, сборка Docker-образов, пуш в GitLab Container Registry), добавляем кэширование, безопасность и автообновление.

Привет, Хабр! Меня зовут Татьяна Козленко, я координатор по технологиям цифрового моделирования в команде девелопера ПИК. 

Хочу рассказать про автоматизированную параметризацию в Revit с помощью инструмента «Склеить параметры». Также освоим три сценария подготовки модели к экспертизе ЦИМ и настроим параметры в семействах кабельных лотков. 

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

В этой статье мы поделимся опытом, как инструмент «Склеить параметры» из набора PikTools.Общее решает эти задачи. Мы разберем три ключевых сценария подготовки модели для экспертизы цифровой информационной модели (ЦИМ) и покажем, как упорядочить многообразие семейств от производителей на примере кабельных лотков и шинопроводов.

Ранее мы уже рассказывали об инструменте в статье «Склейка как помощник в проектировании» и на вебинаре «Как ускорить проектирование с помощью Склейки». Подробное описание синтаксиса формул, логики фильтров и алгоритмов записи значений доступно в инструкции «Склеить параметры». Во всех примерах используются те же правила фильтрации и синтаксис формул, что описаны в перечисленных материалах.

Пока лента обсуждает LLM и агентов, а инвесторы спорят про окупаемость GenAI, «скучный» классический ML тихо зарабатывает реальные деньги. Я Senior Data Scientist в финтехе, выступаю с лекциями по карьере и ML в ИТМО и ВШЭ. Разберем в статье на цифрах пять компаний из четырех разных областей и почему классику рано списывать со счетов.

Для многих обывателей, да и инженеров, которые не углублялись в тему, работа с LLM выглядит как работа с обычным сервисом: мы просто кидаем запросы по нужному endpoint и получаем JSON с ответом. Но на деле появляется много вопросов: как здесь работает кэш? От чего зависит время ответа? Что делать с огромным контекстным окном? И если у нас один GPU-сервер, на котором происходят все вычисления, то это не так и важно. Но что делать с масштабными распределёнными системами? Обычный Kubernetes не понимает, как устроен запрос языковой модели. Однако за последний год платформенные инженеры очень хорошо продвинулись в этом вопросе. И в этой статье я хочу подробно разобрать, как именно строится K8s-кластер под высоконагруженные LLM.

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

Очевидно, его откровенно раздражают бесконечные посты в духе: «Я заменил весь свой отдел продаж Claude». По его словам, практически каждая такая история — либо откровенная ложь, либо полуправда, упакованная в эффектный кейс о цифровой трансформации.

Гётте много лет профессионально разрабатывает ИИ-инструменты для продаж и хорошо понимает реальные возможности таких систем. Поэтому он уверенно утверждает: сегодня никто не заменяет полноценный отдел продаж искусственным интеллектом.

Что на самом деле скрывается за подобными заявлениями?

Предприниматель, который пишет: «Я заменил свой отдел продаж», зачастую сам работает продавцом по 60 часов в неделю и называет это автоматизацией. Компания, рассказывающая об исходящих продажах «без единого человека», раньше имела одного координатора продаж, а теперь ИИ выполняет часть его функций. А за громкими заявлениями вроде «ИИ теперь закрывает сделки за нас» нередко стоят компании с падающей выручкой — просто об этом в последующих публикациях уже не рассказывают.

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

Проблема в том, что подобные публикации подталкивают руководителей и владельцев бизнеса к ошибочным выводам. Успешные и вполне рациональные люди начинают думать: «А может, действительно просто заменить людей ИИ?» Отдел продаж начинает восприниматься как расходная статья, которую можно и нужно автоматизировать и сократить. Решения о людях всё чаще принимаются под влиянием хайпа и кликбейтных заголовков.

Привет, Хабр! Я Дмитрий Клепиков из команды Modus. 

После прошлой статьи захотелось взять тот же стек — ИИ-агента и пару MCP-серверов — и собрать через него в нашем BI-портале DQ-шаблон. DQ здесь — это Data Quality, то есть проверка качества данных: полнота, корректность, уникальность, согласованность, актуальность и всё то, из чего потом складывается доверие к данным.

Шаблон получился не универсальным в духе «подставь любую таблицу, и всё само поймётся». Скорее универсальным оказался каркас: одни и те же этапы, одна таблица результатов, один набор отчётов, история запусков и каталог правил. А вот сами правила остаются доменными. В адресном реестре это КЛАДР, ФИАС, ГКН, кадастровые номера и нюансы вроде «ё» в названиях улиц. Для контрагентов будут ИНН, КПП и ОГРН, для продаж — совсем другой набор проверок.

В качестве тестового датасета я взял открытый Реестр адресов Москвы. Задача была такая: агент через postgres-mcp смотрит схему, выбирает проверки из каталога правил, запускает SQL, пишет результаты в dq_snapshots, а потом через modusbi-mcp собирает отчёты в портале. Ниже расскажу, как именно он шёл, что получилось на выходе и почему после такого эксперимента агенту всё равно нельзя просто верить на слово.

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

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

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

Разбор применения метода DREM (Dynamic Regressor Extension and Mixing) для обучения линейного перцептрона. Рассматривается алгоритм декомпозиции многопараметрической задачи на набор независимых скалярных регрессий. В ходе экспериментальной апробации на синтетических и реальных данных оценено влияние различных параметров на величину MSE и время выполнения, а также проведен сравнительный анализ со стандартными оптимизаторами (SGD, ADAM).

Сборщик мусора в Go обычно воспринимается как что-то, что просто работает. И это, в общем, хорошо: большую часть времени о нём действительно не хочется думать.

Ровно до того момента, когда под нагрузкой сервис начинает тормозить, растут задержки и потребление памяти. В такой момент проверяешь всё подряд: CPU, метрики, сеть, pprof. И среди всего этого про сборщик мусора обычно даже не вспоминают - хотя он вполне может быть причиной просадок производительности.

В Go есть встроенные инструменты, чтобы заглянуть в его работу. Проблема в том, что в реальном запуске это быстро превращается в поток строк и чисел, из которого крайне сложно понять общую картину: стал ли GC вызываться чаще, появились ли долгие паузы, растёт ли потребление памяти.

Я написал gcscope — терминальный визуализатор сборщика мусора для Go. Он показывает, как ведёт себя GC в реальном времени: насколько часто он запускается, как меняется потребление памяти, есть ли моменты, когда паузы становятся заметно длиннее обычного. Работает с любым Go-приложением без правок в коде, и вы сразу видите наглядные графики вместо потока логов. А ещё можно сравнивать поведение своего сервиса до и после изменений.