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

В блоге Beeline Cloud мы часто поднимаем темы информационной безопасности — например, недавно рассказывали про RFC 9116, который описывает security.txt.

Сегодня мы продолжим тему в контексте LLM. Спроектировать или развернуть систему ИИ — это только полдела. Ее еще нужно тщательно протестировать, отладить и проверить на уязвимость к промпт-инъекциям. Упростить эту задачу помогают специальные инструменты — несколько таких open source-проектов мы собрали в этой подборке.

Как дать пользователю ответ на конкретный вопрос с помощью гео-аналитики? Идеальный ответ — это заходишь в сервис, нажимаешь одну большую кнопку и сразу видишь ответ на свой вопрос. Но, как и в любой сложной системе, в реальности всё устроено сложнее.

В этой статье — история трансформации 2ГИС ПРО: от перегруженного картографического интерфейса для гиков до гибкой платформы, где любой может собрать себе рабочее пространство под конкретную задачу.

Расскажу, как мы:

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

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

Давайте честно. Все эти конференции про "Цифровые Двойники" и "AI на производстве" - это красиво только на слайдах в PowerPoint.

В реальности, когда ты приходишь к главному технологу и просишь данные для обучения модели (например, чтобы предсказывать прогар футеровки), происходит одно из двух:

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

Talifero

В статьях до этого, мы рассматривали интересные высоковольтные устройства, в основном, электростатического толка — электрофорные машины: школьная, генератор Ван де Граафа и т.д. 

И даже рассмотрели механический трансформатор напряжения — сам по себе весьма удивительный аппарат. 

Однако, если перейти к более практичным вещам (и таким же интересным) — то, зададимся вопросом: «если не электростатика, то что?» :-) 

Как нам поднять напряжение, если бы мы хотели сделать это одним из самых простых способов и это было бы применимо на практике? 

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

Привет, Хабр! Хотим поделиться интересной историей, которая требует не только приложения имеющихся навыков, но и переосмысления методик. Чем мы в РТК-Сервис часто занимаемся. На ЦИПРе-2025 мы презентовали публике новое ядро мобильной сети EPC от НТЦ ПРОТЕЙ. Оно на 100% построено из отечественных компонентов. В этой статье я, системный архитектор РТК-Сервис Куликовский Даниил, и мои коллеги Пермяков Константин и Талыпов Динар, расскажем, как мы тестировали разработку и какие доработки пришлось сделать, чтобы решение устраивало потенциальных заказчиков из «большой четверки».

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

Год назад застройщик КамаСтройИнвест начал внедрять диспетчеризацию инженерных систем в своих жилых домах и привлек к проекту компанию EFFI CODE, которая занимается промышленной автоматизацией и диспетчеризацией.

Мы посетили объект вместе с инженерами Эффикода и представителями застройщика и разобрали, как система работает на практике. Все подробности расскажем в статье.

В России, Беларуси и в целом в СНГ - огромное количество креативных, талантливых разработчиков, геймдизайнеров, продактов и просто талантливых людей. У кого-то из них есть идея создать игру, или возможно, он или она уже создает игру, либо управляет, возглавляет, помогает развивать игровой проект.

В какой-то момент возникает желание сделать больше, лучше, расширить команду, нанять дизайнера, композитора, провести исследование, закупить ассетов, библиотеку, новый софт и железо. Иными словами, в том или ином плане возникает потребность в увеличении финансирования, для развития своей уникальной, лучшей игры, супер-игрового проекта. И возникает вопрос - Где взять деньги?

Почему я как инвестор должен вам поверить? Ведь я думаю о деньгах и как их приумножить. Я думаю о том, как 1. Вложить деньги и вернуть их, с прибылью, и желательно быстро. 2. Я думаю о вашей игре, да, и графика, и сценарий, и геймплейный цикл вроде норм, даже интересно, но где во всей этой истории моя прибыль? Как быстро я ее получу? И получу ли?

Что поможет убедить инвестора?

Советскому Союзу нужна была атомная бомба. Теперь уже срочно. Атомный проект стартовал в 1942 году, но после взрывов в Хиросиме и Нагасаки пришлось ускоряться. Это был вопрос буквально жизни и смерти государства.   Поэтому уже через две недели после бомбардировки Японии создаётся Специальный комитет по атому.

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

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

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

В меню — исследования скорости разработки, стоимость изменений, скорость обновления кода для разных отраслей, стоимость инфры. Учитывая эти факторы, посчитаю для скольких RPS экономически оправдано использовать тот или иной язык разработки.

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

Привет, Хабр! Меня зовут Виктор Юрченко, я руковожу командой симуляции сенсоров в автономном транспорте Яндекса. Основная задача, которая стоит перед нашей командой, — искать способы делать симуляции ближе к реальности в части сенсорных данных. И недавно сотрудники команды совместно с исследовательским отделом Яндекса разработали собственный метод для симуляции изображений в проездах — MADrive (Memory-Augmented Driving Scene Modeling).

MADrive позволяет достоверно генерировать синтетические изображения для новых дорожных сценариев. Кроме того, для его работы был собран и выложен в опенсорс крупнейший открытый датасет автомобилей — MAD‑Cars. Он может быть полезен для различных задач 3DCV: от 3D‑реконструкции до генерации синтетических сцен.

В этой статье расскажу, почему симуляции так важны для автономного транспорта, как работает MADrive и чем может быть полезен датасет MAD‑Cars.

Подход RaaS — Robots as a Service — переводит роботизацию в сервисную модель: роботы, управляющее ПО, поддержка, обновления и метрики поставляются «пакетом» и оплачиваются по подписке или по факту использования. Вместо единовременной покупки появляются регулярные платежи и договорные гарантии — их фиксируют в SLA и в договоре. Модель применяют в производстве, логистике и сфере обслуживания. Компании получают доступ к роботизации по подписке и распределяют расходы во времени. Как работает RaaS и что учитывать при работе с поставщиками, расскажем в этой статье.

Цель данной статьи - предоставить сравнение методов решения СЛАУ и их эффективности в разрезе времени решения и нормы невязки, характеризующей точность решения. В статье приводятся результаты решения для числа уравнений от 50 до 3000. Приводится сравнение результатов решения для методов: Гаусса, LU декомпозиции, компактной схемы исключения, QR декомпозиции, декомпозиции, методов вращений, релаксации и градиентного спуска.

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

В последние годы руководители 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 не работает

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