Разработка

Вышла нейросеть для инженеров, которая умеет генерить сложные 3D-модели в CAD. Просто закидываете чертёж и получаете готовую модель детали, которую можно отредактировать промптом или задействовать в AutoCAD для ручного редактирования.

Строительные автопилоты: почему данные становятся главным активом строительства.

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

За последние 30 лет CAD/BIM фактически превратились в инструмент ручной разметки строительной реальности: инженеры и архитекторы создавали базы элементов зданий и сооружений, превращая чертежи и 3D-модели в структурированные датасеты.

То, что Google, Tesla или Waymo делали силами миллионов студенто-часов, размечавших вручную изображения с людьми и объектами, в строительстве десятилетиями заполняли инженеры проектировщики в специальных базах слабоструктурированных данных AutoCAD или структурированной базы данных Revit или ArchiCAD.

Именно эти массивы станут сырьём для «строительных автопилотов» — систем, способных автоматически расставлять элементы в пространстве проекта и рассчитывать стоимость, сроки и ключевые параметры новых проектов. Как LLM обучаются на массиве текстов, чтобы генерировать новые знания и целые приложения, так и в строительстве мы сможем с помощью AI и workflow использовать опыт тысяч реализованных проектов, чтобы проектировать и планировать новые проекты быстрее и точнее.
У отрасли есть лишь десятилетие, чтобы превратить накопленный опыт в основу будущих систем. После этого рынок займут те, кто сумел первым построить собственные «автопилоты».

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

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

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

Хотите обсудить новые пайплайны автоматизации, поделиться своими кейсами или получить помощь? Больше примеров автоматизации вы можете найти в репозитарии на GitHub или в нашем телеграмм чате "n8n Development | Практика автоматизации и готовые решения" Присоединяйтесь к нашему Telegram-сообществу для живых обсуждений, советов и эксклюзивного контента.

Квиз: основы работы с базами данных

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

Пройти квиз

Не забудьте поделиться результатами в комментариях!

Telegram Wallet Кошелек скам? Заблокировали средства и уже 2 недели "проверяют"!

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

Уже 2 недели как "отклонили верификацию" и "ограничили доступ к аккаунту", идет общение с поддержкой и "проверка". Примечательно, помимо немалой суммы, что аккаунту полтора года и за это время ничего (!), кроме 8 пополнений из других моих кошельков не было. То есть никаких расходов, P2P транзакций, никаких бирж, НИЧЕГО, к чему можно было бы даже теоретически придраться. Соблазнился стейкингом по 17% на USDT и удобным интерфейсом. При этот аккаунт был верифицирован на уровне "плюс", это паспорт и фото. 

Да, кастодиальный сервис, но в Телеграме все устроено, чтобы показать, что этот сервис родной, вы видите его в настройках мессенжера, и даже анимация в нем фирменная телеграмовская с "уточкой". Разве мы не доверяем Телеграму и Павлу Дурову?!)

В общем сначала "верификация отклонена", после общения с поддержкой в боте 8 дней, наконец-то потом появилась форма запроса данных, сразу внес туда документы "подтверждающие доход", статус изменился на "Аккаунт на проверке", и снова тишина почти неделю... хотя и в форме и FAQе написано, что такое проверяется до 24 часов.

Вебинар «Контроль на 360°: как оценить защищенность от утечек и выполнить требования регулятора?»

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

25 сентября в 11:00 (мск) эксперты «СёрчИнформ» — ведущего российского вендора DLP, и SECURITM — SGRC-системы для управления организационными процессами информационной безопасности, расскажут, как автоматизировать эту проверку.

Вендоры в живой демонстрации представят интеграцию DLP «СёрчИнформ КИБ» с SGRC-системой SECURITM. Это готовый инструмент, который позволит:

• В один клик оценить защищенность компании от утечек: что под контролем, а что — нет.

• Автоматизировать аудит активов.

• Сопоставить «фактуру» из DLP с показателями из других систем защиты, чтобы повысить эффективность ИБ.

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

Спикеры вебинара:

• Николай Казанцев, CEO SECURITM.

• Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».

Участие бесплатное, требуется регистрация по ссылке.

В проекте, где я обучаю ML-модели "запоминать" и "видеть" определенные закономерности на основе исторических данных, и "предсказывать" будущее криптовалютных пар произошел крупный апдейт.

Во-первых, штат ансамбля моделей расширен до 5 штук:

- 2 классических градиентных бустинга CatBoost и LightGBM.

- 2 рекуррентные нейронные сети (RNN-семейство) LSTM (Long Short-Term Memory) и GRU (Gated Recurrent Unit).

- Свёрточная нейросеть для временных рядов TemporalCNN (TCN).

- Все модели стали ближе друг к другу по качеству.

Подробнее о применяемых технологиях и их особенностях я написал в этом посте.

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

Трейдингом, конечно же, не занимаюсь, мой интерес лежит совершенно в другой области.

Если в профиле Max вписать «Телеграм» вместо имени, то такой аккаунт моментально отлетит в бан.

Хочу рассказать про Diffusion модели и одну проблему, которую решили в статье "Fast and Fluent Diffusion Language Models via Convolutional Decoding and Rejective Fine-tuning"

Представьте: вы пишете письмо в саппорт. Большое, с болью, как положено. А потом система берёт и начинает стирать из него слова. Сначала одно-два, потом половину. В итоге доходит до состояния «*** не работает *** вчера *** клиенты». Это называется forward-процесс. То есть сначала текст намеренно превращают в кашу.

Дальше reverse-процесс. Модель берёт этот обрубок и пытается догадаться, что же там было. Сначала простые слова (имена, даты). Потом технические термины. Потом связки. И вот у вас снова появляется более-менее внятное письмо. Это обучение через боль: чтобы в будущем модель могла достраивать даже то, чего не слышала.

Теперь внимание. В обычных генеративках текст растёт пословно, как будто вы диктуете. В диффузии всё наоборот: модель сразу пуляет целое «окно» текста, пытаясь угадать кучу слов одновременно. Звучит круто? Ага, только дальше начинается Long Decoding Window. Чем дальше от начала, тем больше мозг модели закипает. Итог: повторы, бессмысленные вставки, рандомный шум. Письмо начинается адекватно, а заканчивается как будто писал уставший стажёр.

Учёные посмотрели на этот и сказали: ладно, давайте хотя бы починим. Придумали Convolutional Decoding — это как если бы у стажёра попросили сначала сосредоточиться на ближних словах, а дальние воспринимать с осторожностью. Добавили Rejective Fine-Tuning — модель теперь штрафуют за «the the the» и «: : :». И добили EOS-fill: как только модель ставит точку, всё дальше просто забивается точками, и никто не позорится.

Рабочее решение:
— Convolutional Decoding — как если бы стажёру сказали: «сначала смотри на ближние слова, а дальние фильтруй».
— Rejective Fine-Tuning — за повторы и мусор прилетает штраф, и модель учится так не делать.
— EOS-fill — как только модель ставит точку, дальше всё затирается точками, и никто не позорится.

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

Привет, коллеги! 👋

Снова с вами рубрика "вечерний вайбкодер", и сегодня я принёс вам MyRepETL (Ссылка на github)— инструмент для ETL через MySQL репликацию.

Зачем это нужно?

Задача: у вас куча MySQL баз в микросервисах, нужно всё это затащить в Metabase для красивых отчетов.

Проблема в том, что:

• В каждой базе своя схема и структура

• Данные нужно объединить и нормализовать

• Metabase любит когда всё в одном месте

• Ручной экспорт/импорт — это боль

MyRepETL решает это: берёт данные из всех ваших баз, трансформирует их на лету и складывает в единую аналитическую базу для Metabase.

Что умеет MyRepETL

🚀 Основные фишки

Многопоточность из коробки

• Каждый источник работает в своём потоке

• Не блокирует друг друга

• Автоматически восстанавливается при сбоях

Гибкие трансформации

• Переименование таблиц и колонок

• Вычисляемые поля

• Фильтрация данных

• Кастомные Python-функции

JSON-конфигурация

• Всё настраивается через конфиг

Как использовать

Простая синхронизация

Самый базовый случай — просто скопировать данные из одной базы в другую:

{
  "sources": {
    "prod_db": {
      "host": "prod-mysql",
      "user": "repl_user", 
      "password": "repl_pass",
      "database": "production"
    }
  },
  "targets": {
    "backup_db": {
      "host": "backup-mysql",
      "user": "backup_user",
      "password": "backup_pass", 
      "database": "backup"
    }
  },
  "mapping": {
    "prod_db.users": {
      "source": "prod_db",
      "target": "backup_db",
      "source_table": "users",
      "target_table": "users"
    }
  }
}

С трансформациями

А теперь добавим магию — переименуем таблицу, добавим вычисляемые поля:

{
  "mapping": {
    "prod_db.customers": {
      "source": "prod_db",
      "target": "analytics_db",
      "source_table": "customers",
      "target_table": "users",
      "column_mapping": {
        "id": {"column": "user_id"},
        "name": {"column": "full_name"},
        "email": {"column": "email"},
        "birth_date": {"column": "age", "transform": "transform.calculate_age"},
        "phone": {"column": "formatted_phone", "transform": "transform.format_phone"},
        "created_at": {"column": "registration_date"},
        "source": {"column": "source_system", "value": "production"}
      }
    }
  }
}

Создайте файл transform.py с вашими функциями:

# transform.py
def calculate_age(birth_date, row_data, table):
    from datetime import datetime
    if not birth_date:
        return None
    birth = datetime.strptime(birth_date, '%Y-%m-%d')
    return (datetime.now() - birth).days // 365

def format_phone(phone, row_data, table):
    if not phone:
        return None
    # 79991234567 -> +7 (999) 123-45-67
    return f"+7 ({phone[1:4]}) {phone[4:7]}-{phone[7:9]}-{phone[9:11]}"

Запуск

# Установка с GitHub
pip install git+https://github.com/tumurzakov/myrepetl.git

# Или клонировать и установить локально
git clone https://github.com/tumurzakov/myrepetl.git
cd myrepetl
pip install -e .

# Запуск с конфигом
myrepetl run config.json

# Или через Docker
docker run -v ./config.json:/app/config.json myrepetl:latest

На этом всё, удачного кодинга! 👨‍💻

Проблема: Кадровый голод по специалистам, и при этом рекордные количества откликов на вакансии.

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

Общее решение: Изменить процесс наема так чтобы он помогал нанять специалиста для решения задач бизнеса.

Конкретные варианты решения:

1. Использовать зарекомендовавшие себя решения в других воронках\процессах получения чего-либо. Например сарафанное радио и нетворкинг, кумовщину и рефералки, при этом отказаться от существующих фильтров в пользу доверия на старте.

2. Устранить причину мешающую текущему процессу наема. Например сократить цепочку ЛПР-ов на пути соискателя до оптимума.

   (Сейчас это авто-скрипт, эйчар(или ряд эйчаров), собеседующий специалист(или ряд специалистов), представитель команды(или ряд представителей), опционально тут еще какие-то посредники, и вот тут уже можно выйти на работу и работать 😁. Причем на каждом этапе у лже-ЛПР-ов есть цель отсеять человека на основании формального фильтра. Тогда как лучшие работники обычно "неформалы" ибо они про работу работать как Стив Возняк, а не про продукт(себя) продавать как Стив Джобс. Очевидно что не каждая птица долетит даже до середины.. 😢)

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

   ЛПР - это тот кто принимает решение что считает лучшим на этот момент, а не тот который работает по прописанному скрипту (иначе это не ЛПР, а человек которого настоящий ЛПР назначил отрабатывать строго по скрипту 😜).

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

P.S. Все 3 варианта решения на самом деле про одно и то же, только заход с разных сторон: убрать не то что мешает обрабатывать заявки на чиле, в пол уха, левой пяткой, а убрать то что действительно мешает нанять сотрудника для решения конкретных задач. (Да стало много спама, ну и что? Разве то что много спама говорит о том что среди спама нет специалистов способных делать работу? Нет. Как раз таки в этом и заключается задача\работа нанимателя - нанять сотрудника в этих конкретных условиях. Ну да, придется поработать. Соискатель, наниматель и работодатель в одной лодке как ни крути, если кто-то не хочет грести, то далеко ли уплывет такая лодка?🛶)

Хорошего дня, наема и трудоустройства!

Обнял 🤗

Андрей Бурков — канадский специалист по машинному обучению из Квебека. Он руководил командами машинного обучения в Gartner и TalentNeuron, много лет возится с обработкой естественного языка, а прославился «The Hundred-Page Machine Learning Book», компактным учебником, который разошёлся по университетским курсам. В 2024—2025 годах он выпустил продолжение — «The Hundred-Page Language Models Book», где объясняет путь от простых счётных моделей и свёрточным нейросетям к трансформерам и БЯМ.

Впрочем, Бурков не просто повис где-то в сухой академии и написании учебников — он активно ведёт микроблог в X. Тон его микроблога и интервью легко узнать: он любит сбивать хайп и говорить про реальные ограничения моделей. Давайте хотя бы посмотрим, как озаглавлены его недавние беседы: «БЯМ — полезные лжецы» и «Вокруг БЯМ и агентов слишком много хайпа». По его мнению, большие языковые модели полезны, но склонны обещать больше, чем могут, а агенты без аккуратной инженерии разваливаются на форматировании, таксономиях и хрупких пайплайнах.

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

Однако в комментарии пришёл не менее маститый исследователь искусственного интеллекта Андрей Карпатый со своей фирменной иронией. Карпатый — один из одиннадцати основателей OpenAI, он возглавлял компьютерное зрение в Tesla и просто преподавал культовый курс CS231n.

Карпатый с юмором пишет: «Код был написан на слоях 22–30 и хранится в value-активациях, ты просто не можешь его прочитать. Мне кажется, тебе нужно извиниться перед БЯМ».

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

Я исследовал тему связности и связанности в построении кода и вот к чему пришел:

Не существует плохих\хороших\идеальных связности и связанности кода.

Мне кажется проблема и решение глубже - сколько людей столько и вариантов осмысления и построения "модели", столько вариантов же coupling & cohesion. У каждого что-то свое.

Строить приложение от архитектуры - такое себе. Архитектура для приложения, а не приложение для архитектуры. Тогда архитектура будет основана на реальных задачах а не на поиске идеала.

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

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

Т.е. решение кроется в здравом смысле - описываешь приложение плюс-минус понятными человеку структурами и нужная связность и связанность образуются сами собой как следствие.

Ну и когда я говорю ООП, это не значит что я буду писать абстракцию на каждый чих, влоть до Int, Long и т.п., нет, это значит что я начну с самых больших MyApp { UserClient, ServerClient, DeviceClient } и законтачу их между собой логикой приложения, а там дальше буду создавать абстракции по необходимости, если будет удобно и полезно что-то добавить и переиспользовать то я добавлю и переиспользую (вот кстати хороший критерий - моделировать сущность когда надо что-то передавать между главными абсракциями(надсистемами)).

ООП рулит :)

P.S. И не надо стремиться к идеалу, иначе тут можно скатиться в подмену задач, и начать делать не данное конкретное приложение, а предложенный кем-то идеал архитектуры.

Упрашивал ChatGPT нарисовать мне картинку с человеком. Ни в какую! Отказывается!

Сегодня с помощью ChatGPT генерировал картинку к Норм ЦРМ.

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

Попросил нарисовать фрилансера-одиночку за уютным домашним рабочим местом. И тут — хопа — отказ. Мол, это не соответствует нашим политикам.

Тогда попросил нарисовать человека, лица которого мы не видим. Просто фигуру. Снова отказ.

Затем попросил нарисовать антропоморфного кота. И тоже нельзя.

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

Если что, использую пятую версию с подпиской Plus.

——
Апдейт:

В комментариях пишут, что никаких ограничений нет.

Я попробовал сгенерировать в новом диалоге — и тоже ограничений не оказалось.

А вот внутри папки с проектом — не разрешает по какой-то причине.

Буду разбираться дальше.

Хеш-таблица с транзакциями на Go

Привет, продолжим удивительное. Смех смехом, но на Go стали доступны:

1. Хеш-таблица с транзакциями.

2. Структуры данных второго порядка.

И в отличие от C++, они еще не создают проблемы для Garbage Collector. Вы угадайте почему, а я немного процитирую:

------------------8<------------------

Все выглядит примерно так:

func NewMemDb() MemDb { /* ... */ }

type MemDb interface {
    Close() error
    StartTrn() Transaction
}

type Transaction interface {
    Close() error

    Get(key Ptrsz) (Ptrsz, bool)
    All(getKeys bool, getVals bool) (keys []Ptrsz, vals []Ptrsz)

    Set(key Ptrsz, val Ptrsz)
    Del(key Ptrsz)

    DependVal(key Ptrsz, val Ptrsz)
    DependDel(key Ptrsz)

    Commit() error
    Rollback() error
}

А именно:

• Объект MemDb создается с помощью функции NewMemDb().

• У MemDb есть функция Close() -- мы ОБЯЗАНЫ ее вызвать!!!

• Объект Transaction создается с помощью функции StartTrn().

• У Transaction тоже есть функция Close(). Да, мы ОБЯЗАНЫ!

• Transaction работает с данными через lib.Ptrsz. Точно также, как и mdb.BlobMap.

• Чтение данных выполняется посредством функций Get() и All(). Возвращаемые ими Ptrsz указывают на внутренние структуры MemDb. Они остаются валидными пока не завершена транзакция и не было вызовов Set() и Del(), инвалидирующих указатели.

• Изменение данных выполняется посредством функций Set() и Del(). MemDb копирует себе байты, на которые указывают key и val.

• Функции DependVal() и DependDel() устанавливают зависимости. Их проверяет Commit().

• Функции Commit() и Rollback() завершают транзакцию. Завершают, но не закрывают! Мы ОБЯЗАНЫ вызвать Close()!!

• Просто Close() означает Rollback().

------------------8<------------------

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

Игра с огнём, или нулевой байт

В одном проекте заказчик потребовалось различать (и делать поиск) по трем состояниям текстового поля в Lucene индексе:

1. непустое значение (работает из коробки)

2. пустая строка "" (не поддерживается люсин)

3. null (не поддерживается люсин)

Lucene не хранит null и пустые строки "" - значения просто не индексируется. Для бизнес-логики, где нужно различать все три состояния, стандартных механизмов Lucene недостаточно.

Создание "специальных" замен в виде комбинаций типа "_null_" текста и спецсимволов - ломается тестерами которые пропускали различный мусор через индекс.

Был выбран компромиссный подход:

• "\0" (строка из нулевого байта) используется как маркер null

• "\0\0" (строка из двух нулевых байтов) используется как маркер ""

Пробило в холодный пот? Правильно, и меня тоже. Тем не менее, это рабочий способ.

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

Плюсы:

• \0 — это валидный символ в Java-строке, который практически не встречается в реальных данных.

• Символ \0 невозможно ввести напрямую из внешних систем, редакторов или форм без явного кодирования. Это защищает от случайных коллизий, даже если тестировщики пробуют «мусорные» символы.

• Таким образом достигается стабильное различие между null, "" и содержимыми строками.

Риски:

• Утечки наружу. Маркеры \0 могут попасть в API-ответы, логи, сериализацию. В нашем случае lucene был в обертке и поиск напрямую не использовался внешними системами - обработчик вызовов был инкапсулирован в прокси сервис.

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

Германский умлаут и славянская третья палатализация
Кто интересовался историей славянских языков (в частности праславянским), тот наверняка слышал, что современные буквы ъ и ь ранее обозначали звуки ŭ и ĭ, сравните, например древнерусское мьзда, стькло и готское mizdo, stikls или древнерусское кънѧзь и финское kuningas. При этом вследствие третьей палатализации «твёрдый знак» мог переходить в «мягкий», например (в дореформенной орфографии) другиня другъ, но княгиня князь. Причиной палатальной перегласовки в данном случае является наличие в слове князь буквы «я», которая как некоторые любознательные читатели, наверное, уже слышали, может переходить в «ин» размять разминать, распять распинать, ну а «и» может переходить в «ь» липнуть, но льнуть (сравните капать / кануть). Иными словами, тем самым фактором из-за которого отражавшийся ранее на конце слов «ъ» перешёл в слове князь в «ь» является засевший в корне ещё один ерь «ь» «сингармонически» уподобляющий идущие за ним гласные себе. Такое уподобление называется прогрессивным.

Теперь же плавно перейдём к умляуту в германских языках по-иному именуемому i-mutation. Сравним, например английское full полный и fill наполнять. Возвращаясь к означенному в самом начале статьи можно заметить некую аналогию и она действительно есть ...

Продолжение следует

Дело не в том как ты проходишь собеседование

Дело в том хочет человек тебя нанять или нет

Т.е. проходишь ты дальше или нет основывается не на твоих желаниях и знаниях, а на желаниях и знаниях собеседующего

Так что не парься, будь счастлив 😁

Воспринимай собеседования не как путь именно к этой работе, а как путь к чему-то вообще :)

В любом случае этот шаг делает тебя на шаг ближе к цели

Если ты не прошел собес, то выбор простой: сражайся с этим или наслаждайся этим, и даже если сражаешься, то насладись сражением 😁

P.S. И так во всём..

Baidu представила ERNIE X1.1 — модель рассуждений уровня GPT-5 и Gemini 2.5 Pro

На конференции WAVE SUMMIT 2025 китайская компания Baidu анонсировала ERNIE X1.1 — обновленную модель рассуждений с существенными улучшениями в точности, следовании инструкциям и агентских возможностях. Модель превосходит DeepSeek R1-0528 и сопоставима с топовыми решениями от OpenAI и Google.

Технические улучшения

ERNIE X1.1 демонстрирует значительный прирост производительности относительно предыдущей версии. Фактическая точность выросла на 34.8%, следование инструкциям улучшилось на 12.5%, а агентские способности — на 9.6%.

Архитектурные особенности:

• Построена на базе мультимодальной модели ERNIE 4.5

• Использует итеративную гибридную систему обучения с подкреплением

• Объединяет смешанное reinforcement learning и итеративную самодистилляцию

• Поддерживает контекст 128K токенов

Производительность в бенчмарках

По результатам множественных тестов ERNIE X1.1 превосходит DeepSeek R1-0528 в общей производительности, показывая явные преимущества в ряде задач. Модель работает на одном уровне с такими топовыми решениями как GPT-5 и Gemini 2.5 Pro.

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

Доступность и интеграция

ERNIE X1.1 доступна через несколько каналов:

• ERNIE Bot — веб-интерфейс на ernie.baidu.com

• Wenxiaoyan — мобильное приложение Baidu

• Qianfan MaaS — платформа Models-as-a-Service для корпоративных клиентов и разработчиков

Параллельно с ERNIE X1.1 компания открыла исходный код модели ERNIE-4.5-21B-A3B-Thinking — легковесной MoE-модели с 21 миллиардом общих и 3 миллиардами активных параметров.

Экосистема PaddlePaddle

Развитие ERNIE X1.1 происходит в контексте расширения экосистемы PaddlePaddle. На данный момент экосистема PaddlePaddle-ERNIE обслуживает 23.33 миллиона разработчиков и 760,000 предприятий.

Новые инструменты включают:

• PaddlePaddle framework v3.2 с улучшениями обучения и совместимости

• ERNIEKit для разработки фундаментальных моделей

• FastDeploy v2.2 для эффективного развертывания

• Научные тулкиты PaddleCFD и PaddleMaterials

Baidu Comate 3.5S

Одновременно с ERNIE X1.1 представлена обновленная версия ИИ-помощника для программирования Baidu Comate 3.5S. Система поддерживает более 10 миллионов разработчиков, а внутри Baidu 45% нового кода теперь генерируется ИИ.

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

Конкурентная позиция

ERNIE X1.1 позиционируется как прямой конкурент западных моделей рассуждений. Baidu делает ставку на сочетание высокой производительности с локализацией под китайский рынок и требования регуляторов.

Преимущества модели:

• Конкурентоспособная производительность с глобальными лидерами

• Интеграция в экосистему китайских облачных сервисов

• Поддержка специфичных для региона задач и языковых особенностей

• Соответствие местным требованиям по данным и безопасности

Релиз ERNIE X1.1 демонстрирует способность китайских технологических компаний создавать модели мирового уровня и конкурировать с ведущими американскими разработчиками ИИ.

Email и бухгалтерия: почему заголовки писем всё ещё угрожают деньгам компаний

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

Электронная почта — это не только переписка с коллегами или рассылка клиентам. Это канал, через который каждый день проходят платёжки, инвойсы, запросы на переводы. И именно эта часть коммуникаций десятилетиями оставалась в зоне риска, потому что заголовки писем (From, Subject, To) никак не защищались. Мы могли шифровать тело письма, подписывать вложения, использовать все возможные фильтры, но если злоумышленнику хотелось заменить тему на «Срочный перевод контрагенту», он мог это сделать.

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

И вот только в 2025 году IETF принял новый стандарт — RFC 9788. Он наконец-то говорит очевидную вещь: защищать нужно не только тело письма, но и заголовки. Теперь все поля копируются внутрь зашифрованной части, наружу выходит только технический минимум, а тема письма может заменяться на […]. Если кто-то попробует подделать заголовок, клиент сразу покажет рассинхрон.

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

Да, внедрение будет постепенным: сначала open source-клиенты и энтузиасты, потом корпоративные почтовики, потом массовый рынок. Но уже сейчас очевидно, что компании, которые раньше внедрят RFC 9788, снизят риски быстрее. Это история не про «технологическую моду», а про то, сколько денег вы теряете или экономите.

Я уверен, что лет через пять защищённые заголовки будут восприниматься так же естественно, как сегодня HTTPS на сайтах. И точно так же, как сейчас мы удивляемся сайтам без https, пользователи будут удивляться письмам, где можно переписать тему или отправителя. Вопрос только в том, вы хотите оказаться в числе тех, кто внедрил это вовремя, или в числе тех, чью бухгалтерию упомянут в очередной криминальной хронике.

Зачем работать напрямую с клиентом, когда можно просто выкинуть запрос на MCP и дать нейросети подумать? 😎

Расскажу кейс Vivo Chat. Проверка статуса заказов (замените на вашу сущность). Давайте по порядку

Клиент идёт к хосту, чтобы получить доступ к MCP

Итак, наш клиент — это тот, кто первым инициирует запрос. Всё начинается с того, что клиент заходит в свою систему, которая подключена к MCP-серверу через хост. Хост выполняет функцию посредника, направляя запросы и получая ответы от разных компонентов системы.

Клиент: «Привет, хост, мне нужно проверить заказ, и я хочу понять, что из инструментария MCP мне пригодится. Покажи мне, пожалуйста, список доступных инструментов и подсказок, чтобы я мог выбрать что-то нужное для этого запроса.»
Хост (перехватывает запрос и направляет его к серверу MCP): «Окей, сейчас все передам.»

Хост запрашивает у MCP список инструментов (Tools) и подсказок (Prompts)

Хост теперь идёт к MCP-серверу. Этот сервер знает всё, что связано с доступом к данным и обработкой запросов. В MCP сервере хранятся все инструменты (tools) и подсказки (prompts) для выполнения нужных действий.

Хост: «MCP, подкинь мне список доступных tools и prompts для запроса клиента.»
MCP-сервер: «Вот, держи, вот все инструменты и подсказки, которые у нас есть. Для каждого метода я также подготовил параметры, которые можно подставить.»

LLM, любимая нейросеть, выбирает метод из списка

Теперь, когда хост получил список инструментов и подсказок, он передает всё это в LLM (нейросеть), которая и будет решать, какой метод нужно использовать для конкретного запроса.

Хост: «LLM, тебе пришёл запрос от клиента. Вот список инструментов и промптов. Тебе нужно выбрать подходящий метод для выполнения запроса и подготовить все нужные параметры для этого метода.»
LLM: «Хорошо, я выбираю метод X из списка инструментов, и вот какие параметры мне нужны для этого метода. Я знаю, что нужно сделать, и использую соответствующие промпты, чтобы точно понять, что клиент хочет.»

LLM передает параметры и вызывает метод на MCP

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

LLM: «Вот всё, что мне нужно: метод X и параметры для выполнения. Передавай это на MCP.»
Хост: «Принято, иду к MCP.»

Хост направляется к MCP-серверу и передает запрос на выполнение метода.

MCP выполняет метод и возвращает результат

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

MCP-сервер: «Я выполнил метод X с этими параметрами. Вот результат: (ответ).»

Ответ от LLM клиенту

Теперь, когда MCP выполнил метод, хост получает ответ и передает его обратно в LLM, которая уже анализирует результат, добавляет необходимые детали (например, форматирует или уточняет ответ) и отдает всё клиенту.

Хост: «Вот ответ от MCP через LLM: (ответ). Всё готово!»
LLM: «Отлично, теперь я передаю результат обратно клиенту.»
Клиент: «Вау, всё так быстро! Спасибо, LLM!»

Итог

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