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

Один из главных вопросов сегодня: не забегает ли развитие искусственного интеллекта слишком далеко?

Венчурный инвестор Марк Андриссен недавно сформулировал происходящее одной фразой: «Мы научили песок думать».

Разработчик дал Claude задачу самостоятельно провести исследование небольшой модели для настольной игры и оставил агента работать. Когда он вернулся, оказалось, что за это время ИИ успел запустить 16 GitHub Actions runners — виртуальных машин, на которых можно параллельно выполнять вычисления.

Друзья, мы знаем, что многие заждались подробностей о серии блокировок наших сервисов, которые несколько раз практически полностью выводили из строя Amnezia Free и Amnezia Premium для пользователей из России.

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

Под катом — постмортем полутора месяцев игры в кошки-мышки. Расскажем, почему новые серверы жили всего 3–10 часов, как цензор перешёл к блокировке целых подсетей, какие особенности AmneziaWG выдавали нашу инфраструктуру и при чём здесь DDoS, сканирование API и контрольные подключения. В конце — рекомендации для наших пользователей.

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

Это вторая часть разбора ошибок конфигурации MS SQL Server под 1С. Первая часть — про планирование и развёртывание: профили нагрузки, дисковая подсистема, баланс ресурсов, инсталляция и виртуализация, здесь первая часть. Там же была описана типичная история дефолтного развёртывания сервера на прод или «как не надо».

Побудившая меня написать всё это предыстория такова: сервером СУБД под 1С обычно занимается системный администратор в паре с 1С‑разработчиком или франчом, уровень СУБД теряется где‑то между их компетенциями. Первая часть была про то, как этот разрыв закладывает проблемы при развёртывании. Вторая (эта) — про то, как этот же разрыв в компетенциях мешает найти причину, когда система уже тормозит «и всё висит, и прод лежит».

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

Все звонки начинаются как под копирку

«База висит». «Окна не открываются». «К вечеру всё тормозит так, что документ не провести». Жалобы на сервер 1С звучат одинаково в рознице, в производстве и в бухгалтерии, но причины под одинаковыми симптомами всякий раз оказываются разными. Посмотреть, какие типы ожиданий превалируют на сервере, найти тяжёлые запросы, указать в каких местах и что можно поправить. За каждым этим шагом стоит достаточно узкая компетенция администратора баз данных, отдельная профессия — DBA. Разработчики этим навыком, как правило, не владеют, у них другая специализация, отсюда следствие: код, который прекрасно работает на тесте, в проде начинает работать очень тяжело. На тесте нет ни боевых объёмов, ни конкуренции за строки, ни сотни пользователей, проводящих документы одновременно. В проде есть всё и сразу.

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

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

- Польза — зачем это именно мне сейчас?

- Риски — какие риски у вмешательства?

- Альтернатива — есть ли другой способ?

- Ничего — что будет, если подождать?

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

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

Я «обучил» его на открытых источниках (клинические протоколы, международные гайдлайны) и материалах курса. Так за несколько вечеров вырос Second Opinion — мобильное веб-приложение, полностью навайбкоженное в Claude Code.

Случайно услышал на просторах интернета, что у Сбера, оказывается, есть открытая модель, которая по бенчмаркам русского языка бьёт Whisper, проверил, и понял, что она не просто не хуже, она работает мгновенно? да еще и на обычном процессоре, без GPU, а текст появляется быстрее, чем успеваешь отпустить кнопку

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

Что получилось и как работает:

Держишь правый ⌘ command, говоришь, отпускаешь, текст с пунктуацией и заглавными уже вставлен туда, где стоял курсор.

Замеры дали такие параметры: фраза на 6 сек вставляется за 0.08 сек, запись 30 сек транскрибируется меньше чем за полсекунды, а загрузка модели поднимается за 0,22 сек.

Все локально звук не покидает комп, сама модель весит 204 МБ, а приложение 32 мб и работает на процессоре, видеокарту не используем, код открыт, лицензия MIT, с названием мудрить не стал, раз пишет под диктовку, пусть будет Писарь

Почему Писарь, а не Whisper

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

GigaAM, на базе которого я собрал Писаря, обучена Сбером специально на русском, и на нём она заметно точнее, плюс расставляет пунктуацию и заглавные, английские вкрапления в русской речи (термины, названия) она тоже переваривает как надо.

Даже при самом оптимистичном сценарии средняя глобальная температура на планете вырастет как минимум на 1,8 °C, значительно превысив установленную Парижским соглашением цель в 1,5 °C, говорится в докладе ООН. Его авторы предупреждают, что каждая дополнительная доля градуса усиливает разрушительные экстремальные погодные явления, таяние ледников, утрату экосистем и затопление островов и прибрежных городов.

Доклад базирующейся в Найроби Программы ООН по окружающей среде подтвердил, что превышение порога в 1,5 °C, закреплённого в историческом Парижском соглашении 2015 года, теперь «неизбежно» и, несмотря на некоторый прогресс в борьбе с вызванным человеком климатическим кризисом, причиной которого прежде всего служит сжигание ископаемого топлива, скорее всего произойдёт уже в ближайшие несколько лет.

В докладе говорится: «При потеплении выше 1,5 °C хороших сценариев нет».

Если температура поднимется на 3 °C по сравнению с доиндустриальным уровнем, к 2100 году ледники могут потерять более четверти своей массы, а уровень моря из‑за этого повысится на величину до 13 см. Если не разработать эффективные стратегии адаптации, к 2050 году мировое производство продовольствия может сократиться на величину до 14%.

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

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

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

Я делаю персонального ассистента, который читает переписку пользователя в Telegram и отвечает на вопросы вида «какой бюджет мы обсуждали на поездку в Турцию?», «что решили по договору с подрядчиком?», «что я обещал Ане?». То есть строю долговременную память.

Казалось бы, задача решается стандартно: заливаем все сообщения в векторную базу, на каждый вопрос делаем top-k поиск и подкладываем найденные чанки в промпт. Я попробовал этот путь и довольно быстро отказался от него в чистом виде. В этой статье я расскажу почему наивный RAG по переписке ломается и какую архитектуру я построил вместо него.

Разрыв между «отлично работает на истории» и «сливает в реальности» — классика ML на временных рядах. В нашем случае модель заглядывала в будущее на 3.5 часа через некорректный ресемплинг 4-часовых свечей.

Разбираем анатомию утечки, математику позиционного теста для её детекции и делимся сниппетом защиты от подобных ошибок.

Давайте проверим возможности искусственного интеллекта на реальном кейсе. Чтобы не выбирать один ИИ на все случаи жизни, мы будем работать в BotHub, где можно переключаться между моделями. Для каждой задачи будем использовать наиболее подходящую модель: например, мощной Claude Opus 5 мы поручим разбор объемного ТЗ, а быстрой Claude Sonnet 5 — генерацию CSV для дальнейшей работы с план-графиком. 

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

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

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

Сайзинг 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. И это ещё не всё, что он умеет.