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

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

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

Именно с такой реальностью нам (мне и коллегам) и пришлось столкнуться.

Данная статья описывает библиотеку muRPC для создания сервера и клиента для протокола JSON-RPC. Режим работы предполагает, что один из клиентов JSON-RPC предоставляет какие-то методы и сообщает об этом серверу. Тогда другие клиенты JSON-RPC могут эти методы вызывать и получать ответ. Сервер предоставляет маршрутизацию и валидацию сообщений между клиентами.

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

Я чувстовал себя клоуном подключая 5ю библиотеку для написания устойчивого к ошибкам API клиента. После этого я написал библиотеку объединяющую все воедино. Мотивация и история архитектурных решений.

…Был обычный ноябрьский вечер, 2024 год шёл к своему завершению: на носу была «чёрная пятница». Я вернулся домой в Новосибирск из почти двухнедельной командировки, пробыв в пути 12 часов и поспав часа четыре. В 19:07 алерт сообщил мне о падении одного из контроллеров. В целом, проблема не критичная, так как сервисы зарезервированы. Но всё же одним глазом я заглянул в чат с разбором.

Через час ситуация стремительно ухудшилась: каскадом начали отказывать узлы, отвечающие за внешнюю связность. А затем развитие событий приняло фатальный оборот — в какой‑то момент одновременно отказали сервисы внешней связности сразу в двух зонах доступности… 

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

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

Я сделал Telegram-бота, который по короткому фрагменту детского плача (в MVP беру 5 секунд) пытается угадать причину из 6 классов и быстро вернуть ответ. Это не диагностика: бот может ошибаться, а шум и контекст ломают предсказание сильнее, чем хочется.​

Машинное обучение обычно ассоциируется с датасетами, метриками и бесконечными экспериментами в ноутбуках. Но в какой-то момент для нас ML перестал быть абстрактной технологией - и стал маршрутом. Причём буквально. Эта история о том, как модели, гипотезы и пара неочевидных решений привели нас не только к рабочему результату, но и на самый настоящий остров Парамушир (северные Курилы).

Попытка улететь на вертолёте из Петропавловска-Камчатского в Северо-Курильск сразу превратилась в маленькое приключение: местные хором пугали погодой и перспективами — «можете не прилететь, а если вдруг прилетите, то потом не улетите». Камчатка в этом смысле честна и беспощадна, особенно к планам. Но желание полетать на вертолёте здесь перевешивало все разумные доводы — уж слишком манила сама идея увидеть полуостров с воздуха, да ещё и недорого (у вертолетных экскурсии на Камчатке кусачие цены). На вопрос "как не играть в рулетку с погодой" - ответ очевиден, ML.

P.S. хоть Хабр и не про туризм, но вдруг кому интересно, на Парамушире есть и свои достопримечательности, такие как действующий вулкан Эбеко и аэродромное плато (бывшие японские ангары) поэтому не только ради дешевого полета на вертолете мы оказались в Северо-Курильске.

Представьте, что вы объясняете ребёнку, что такое «яблоко». Вы покажете картинку, дадите попробовать, расскажете, что оно круглое, сладкое, растёт на дереве, а теперь попробуйте объяснить это нейросети. Она не видит, не пробует, но она понимает только числа.

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

Проблема «слепого» кодирования: почему one-hot не работает

Самый наивный подход- это пронумеровать все слова в словаре и закодировать каждое вектором из нулей и одной единицы:

MCPHero - новая библиотека/проект для Python для использования MCP tools как native tools в ИИ библиотеках типа openai, которые не поддерживают MCP сами по себе.

Всем привет!

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

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

Несмотря на свою простоту, эта модель имеет существенный недостаток: потоки операционной системы обходятся дорого. Каждый поток потребляет от 1 до 2 МБ памяти только на свой стек, а переключение между ними включает в себя переключение контекста на уровне операционной системы, что также является ресурсоемкой операцией.

Представьте, что есть задача по обработке 100 000 одновременных запросов с помощью этой модели. Это приведёт к потреблению десятков гигабайт памяти только под стеки потоков и, скорее всего, к аварийному завершению JVM задолго до достижения такого количества потоков, также будет тратиться время на переключение контекста между потоками. Пропускная способность системы резко упадет из-за накладных расходов.

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

Судебные материалы раскрывают, как компании наперегонки добывали всё больше книг, чтобы скормить чат-ботам: в числе прочего, покупали, сканировали и уничтожали миллионы экземпляров

В начале 2024 года руководители Anthropic, стартапа по разработке искусственного интеллекта, взялись за амбициозный проект, одновременно пытаясь держать его в тайне. «Project Panama — это наша попытка провести деструктивное сканирование всех книг мира», — говорилось во внутреннем плане, рассекреченном в судебных материалах на прошлой неделе. «Мы не хотим, чтобы факт нашей деятельности стал известен».

Как следует из документов, примерно через год на эту цель был освоен бюджет в десятки миллионов долларов. Эти деньги потратили, чтобы приобрести книги и сре́зать корешки, а затем отсканировать страницы и вкачать больше знаний в ИИ-модели, лежащие в основе продуктов по типу популярного чат-бота Claude.

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

По данным GitHub, количество открытых библиотек растёт экспоненциально. Только в экосистеме npm (JavaScript) насчитывается более 2 миллионов пакетов. При этом:

Мы привыкли видеть Telegram как список чатов и каналов на своём устройстве. Но это лишь малая часть большой экосистемы, ограниченная подписками каждого пользователя. А как выглядит вся экосистема целиком? Эта статья — о том, как мы провели масштабное исследование контента Telegram и разработали интерактивную карту с 500 000 каналами.

Всех приветствую!
В прошлый раз я не указал важный аспект: на данном этапе проект - это монолит. Однако архитектура закладывается с учетом того, что в будущем систему можно будет разнести на разные серверы.
Хочу поблагодарить пользователей за конструктивную критику в комментариях. В частности, @aleksandy верно подметил использование LocalDateTime вместо Instant. Повторюсь: на этапе прототипирования это осознанный выбор для удобства отладки и прямого контроля данных в БД "глазами", без конвертации часовых поясов в уме. Переход на Instant - это стандарт для продакшена, и он заложен в план развития.
Также коснулись темы equals() и hashCode(). В текущей реализации я использую getClass(). Знаю, что это не учитывает работу Hibernate Proxy (когда вместо реального объекта мы получаем его обертку-пустышку для ленивой загрузки). На текущей "плоской" структуре данных это не критично, но как только мы перейдем к сложным связям, будет рефакторинг этих методов через instanceof, чтобы избежать ошибок сравнения.

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

Программа визуализирует решение и промежуточные результаты задачи Дирихле для уравнения Лапласа/Пуассона в прямоугольнике на CPU и GPU.

Уравнение Пуассона(при уравнение Лапласа) :

Задача Дирихле(краевые условия 1-го рода) - заданы значения на границе области(в данном случае в прямоугольнике).

Результаты визуализируются при помощи тепловой карты(HeatMap). Используются цвета и оттенки синего, сине-зелёного(циан), зеленого, желтого и красного цветов(от меньшего к большему значению).

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

Процесс масштабирования бэкенд приложения на основе flask_restx и OpenApi. Реализация авторизации в приложении и обеспечение базового уровня безопасности.

GigaCode vs SourceCraft Code Assistant: что выбрать аналитику в 2025?

Сравнил две российские AI-IDE по критериям, важным не разработчику, а аналитику: работа с документами, контекстное окно, агентный режим, бесплатные квоты. Плюс пошаговые инструкции — от регистрации до первого запроса в чате.

SourceCraft: 3000 предложений + 1000 чат-запросов в неделю бесплатно, лимиты прозрачны.
GigaCode: бесплатен для пользователей GitVerse, квоты не публикуются.

Бонус: таблица соответствия концепций Roo Code → российские платформы. Для тех, кто читал мои предыдущие статьи и хочет применить подходы на одобренном стеке.

Это перевод эссе Дарио Амодеи «Подростковый период технологий». Да, мы уже жутко устали от статей про ИИ (многие из которых и написаны LLM). А здесь ещё и лонгрид!.. Но я всё же решился перевести это эссе. Его автор — генеральный директор и соучредитель Anthropic (модель Claude). В 2025 году он вошёл в список 100 самых влиятельных людей по версии журнала Time, до этого работал в OpenAI, курировал создание GPT-2 и GPT-3. Был назван одним из «архитекторов искусственного интеллекта», которых Time выбрал «человеком года», наравне с парнями и девушками на картинке (Амодеи второй справа).

У него есть свой взгляд на то, какие риски несёт развитие ИИ, взгляд "изнутри отрасли", и этим он интересен (даже если мы не согласимся с некоторыми его резко политизированными тезисами). Да, будущее покажет, реализуются ли эти риски, вот только речь идёт о будущем, измеряемом годами, максимум, ближайшим десятилетием...

Сегодня зашел на сайт ollama, а там представили новую LLM модель qwen3-coder-next. Но при попытке ее установить вышло предупреждение что моя текущая версия 0.15.4 не будет работать с ней, нужно установить 0.15.5 которая еще только в бета тестировании. А стандартная установка ставила только 0.15.4, сначала я плюнул на это.

Но немного разобравшись, оказалось что установить бета версию не так и сложно, стандартная установка для линукс выглядит так

curl -fsSL https://ollama.com/install.sh | sh

а установка бета варсии (сейчас она 0.15.5-rs2) выглядит так

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.15.5-rc2 sh

Представлено 2 версии qwen3-coder-next