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

Когда я иду по улице и разговариваю по телефону, прохожие регулярно переспрашивают: «Это вы мне?»

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

Спойлер: это не телефон. И рецепт — не блокировщики и не кнопочная звонилка, а кое-что бесплатное и по-настоящему скучное.

Сайзинг RAM и vCPU для локальной языковой модели начинается с конкретных весов и профиля запросов. Исходные требования self-hosted LLM включают длину входа и ответа, конкурентность, рантайм и схему offload. Расчёт по размеру весов и формуле KV-кэша даёт стартовую конфигурацию, а прогретый тест показывает реальное потребление памяти и точку, где CPU перестаёт помогать.

Хотел сделать это как пост, но символов не хватило...

Пишу на RPG под IBM i. И вот возникла проблема на вход некоей функции приходит дата в виде строки в формате ISO (YYYY-MM-DD). Ее надо проверить на корректность и перевести в формат CYMD (CYYMMDD где C - век, 0 для 1900Б 1 для 2000 и т.п.) в число zoned(7) (формат с фиксированной точкой, 7 знаков). Да, формат экзотический, но на IBM i используется, поддерживается и достался нам в наследство от разработчиков нашей АБС - компании MySys.

Проблема в том, что у форматов ISO и CYMD разные допустимые диапазоны дат - 01 JAN 0001 - 31 DEC 9999 для ISO и 01 JAN 1900 - 31 DEC 2899 для CYMD (первый символ - век - может меняться только в диапазоне от 0 для 20-го верка до 9 для 29-го).

Т.е. даже провалидировал входящую строку на предмет того что там содержится корректная ISO дата, нет уверенность что при конвертации в CYMD не случится исключения по причине того, что эта дата выходит за границы диапазона CYMD.

Естественно, я знаю как это правильно и эффективно сделать. Но решил проверить ИИшку. Сформулировал задачу, запустил. Получил ответ

Во время работы аналитиком в рекрутменте я часто строил множество метрик, которые отвечали на абсолютно разные вопросы:• сколько дней закрывали вакансию;• сколько стоил найм;• какая воронка кандидатов;• какой процент кандидатов принял оффер и т.п.

Все они что-то измеряют, но далеко немногие из показателей отвечают на главный вопрос – а подходящего ли человека мы в итоге наняли?

Иногда аналитика рекрутмента заканчивается с выходом кандидата на работу, что далеко не всегда помогает работе бизнеса. Ведь можно закрыть вакансию за 10 дней, потерять человека через 2 месяца и снова искать нового сотрудник. А может быть наоборот – искали два месяца, получили сильного специалиста, который уже 5 лет работает в компании.

По одной из самых популярных метрик в рекрутменте (я про time-to-hire) первая история будет намного выгоднее для рекрутмента, а вот по эффекту на бизнес - эффективнее будет вторая.

Поэтому сегодня я попробую предложить вариант расчета иной метрики для подбора – качество найма.

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

Привет, Хабр! Меня зовут Илья Копаничук, я старший научный сотрудник лаборатории «Сильный ИИ в медицине» AIRI. Мы с коллегами создаём ИИ‑инструменты, задача которых сделать качественную медицину доступнее. Например, основанное на нашей технологии приложение «Помощник по здоровью» стало лучшим ИИ‑решением в клиентском сервисе по версии Generation AI Awards 2025. Но речь сегодня не об этом.

За время нашей работы мы поняли, что контроль качества ИИ‑диагностики в медицине — это одна из ключевых задач, которая, как оказалось, не была ещё достаточно хорошо решена. Во‑первых, тесты для медицинских моделей зачастую далеки от реальной практики. А во‑вторых, всегда ли точны люди? 

Пытаясь ответить на эти вопросы, мы с помощью коллег из ФГБУ «НМИЦ им. В. А. Алмазова» Минздрава России собрали собственный фреймворк и опубликовали про него статью в Scientific Reports. Здесь я расскажу, как он устроен и на какие метрики мы обратили внимание, а также постараюсь дать ответ на вопрос, заданный в заголовке. 

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

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

Привет, мы команда SimpleOne ITAM. В статье разберём, какие данные закрывают каждый из трёх вопросов, почему расчет TCO на неточном реестре может подорвать доверие ко всей системе учета сильнее, чем отсутствие расчета, и когда компании достаточно базового набора цифр без сложной аналитики.

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

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

Все это звучит конечно логично, но явно 10x инженером так не стать. Да и будем честны, даже 2x тоже. В IT, где эффективность, это не один из критериев оценки сотрудника, а недостижимая цель, к которой стремятся все. Мой стиль работы — это проблема. Но благодаря появлению AI, эта проблема стала решена.

Есть число, которое не меняется от смены знака. Минус перед ним ничего не делает, а модуля у него не существует: Math.Abs бросает исключение.

Это int.MinValue. И это ещё не всё, что он умеет.

Спросите десять независимых разработчиков, как они выбрали проект Unity, который они переделали, и вы, вероятно, услышите один и тот же ответ как минимум от семи из них: «В демоверсии он выглядел круто». Это неплохая отправная точка, но неполная. Отполированная демоверсия практически ничего не говорит о том, подходит ли жанр вашим навыкам, вашему свободному времени или рынку, на который вы пытаетесь выйти.

Тестирование API часто сводится к одному: отправить запрос и убедиться, что сервер ответил 200. На собеседовании этого хватает на пару минут, а в проде именно здесь всплывает то, чего статус-код не ловит: чужой заказ в ответе, молчаливый 500 вместо ошибки валидации, товар, который не списался со склада.

Разберём 20 базовых проверок, которые отличают QA, тестирующего API, от того, кто просто дёргает ручки: успешный ответ, входные данные, ошибки, доступ и состояние системы — на одном сквозном сценарии, с примерами на curl и в Postman. Начинающий выстроит последовательность, опытный сверится и поймёт, куда расширять набор тестов.

Многие аналитические платформы сталкивается с одним и тем же вопросом: как связать компоненты, которые изначально не знают друг о друге? График живёт по одним правилам, карта — по вторым, таблица — по третьим. Каждый движок говорит на собственном языке событий и данных, и заставить их работать слаженно — нетривиальная архитектурная задача. В этой статье рассказываем, как мы её решаем в Modus.

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

Для этого недостаточно просто установить WMS. Нужны описанные операции, данные по их стоимости и производительности, а также владелец, который отвечает за изменение.

Когда в работе появляется несколько независимых задач, возникает очевидная идея - "почему бы не поручить их разным AI-агентам одновременно, вместо того чтобы ждать, пока один агент закончит все по очереди?"

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

В статье разберу - как был устроен эксперимент, чем отличались три тестируемых процесса, что показали цифры и какие проблемы обнаружились во время самого запуска.

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

Про диаризацию на рабочем созвоне: как размечался эталон, почему в системном канале нет твоего собственного голоса, чем закончился A/B четырёх эмбеддеров (место в бенчмарке VoxCeleb никак не предсказало результат на живой записи), что показали VibeVoice и MOSS и почему адаптивный фильтр не вычитает эхо из микрофона.

Что, если добавить виртуальной машине процессоров — и она станет работать медленнее? В сильно переподписанных серверах это не мысленный эксперимент, а повседневность. Новый механизм ядра Linux — steal governor — предлагает решать проблему с другого конца: не раздавать ВМ больше ресурсов, а научить её добровольно ужиматься.

Идея была простая: смотреть аниме с друзьями так, чтобы пауза у одного означала паузу у всех. Не Discord Go Live с его артефактами и мылом, не «на счёт три жмём пробел», а честный общий плеер: кто угодно нажал — у всех перемоталось.

Я думал, это вечер работы. Получилось четыре нетривиальных проблемы, три из которых я не нашёл описанными нигде, и одна ночь отладки того, почему hls.js молча ничего не делает.

Под катом: почему прямая ссылка на видео бесполезна в браузере, как выглядит прокси с подписанными токенами и переписыванием HLS-плейлистов на лету, как синхронизировать плеер без вечного эха событий, и почему preload="none" ломает Media Source Extensions.

При обработке больших аудио сначала важно определить, на каком языке говорит человек, и только затем направить запись в подходящую систему распознавания речи. Это становится особенно важно при обработке больших объёмов аудио, где модель должна анализировать тысячи и миллионы записей. Нам удалось создать быструю модель определения языка (LID-классификатор), сохранив качество распознавания. Благодаря ей обработка аудиоданных (ASR) требует значительно меньше вычислительных ресурсов и может эффективнее масштабироваться на существующей инфраструктуре.

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

Разработку компактной модели выполнил исследователь компании «Криптонит» по направлению обработки аудиоданных Александр Самойлов, при участии Александра Тарарина и Артёма Рыженкова.

Они создали компактную модель для определения языка по короткому фрагменту речи, которая примерно в 10 раз быстрее и в 5 раз легче. Вдобавок, модель получилась устойчивой к искажениям.

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

Как самодельный фреймворк пережил первый коммерческий релиз — соло, в цейтноте и с вайб‑кодингом в финале.

4 сентября вышел мой первый коммерческий продукт, целиком написанный на Vortex, — симулятор свиданий с минииграми и интеграцией нарративного движка Naninovel. Причём вышел не «в срок», а раньше срока: релиз стоял на 11-е, уехал на 4-е. Досрочный релиз софта — зверёк редкий, а на самодельном фреймворке — вообще краснокнижный... Гордость! XD

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

Короткий вывод: оправдал. Дал ровно то, ради чего задумывался, — простоту и предсказуемость масштабирования по всем осям, которые понадобились. А понадобилось немало.

Коротко: я снял ответы ChatGPT для клиента на 20 вопросов тремя способами. Бренд без подсказки прозвучал на одном вопросе из 19 в первом съёме и ни разу в двух других. У окна чата и API общих источников 17 из 49 и 68 доменов, поэтому способ съёма пишу рядом с каждой цифрой.