Все потоки

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

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

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

Меня зовут Антон Омельяненко, я Head of Software Development в EXANTE. Менеджер управляет командой так, чтобы она приносила бизнесу результат. Чтобы понимать, насколько хорошо люди справляются с задачами, ему нужны данные о работе и система оценки. С разработкой это сложнее, чем кажется.

В статье я разберу три вопроса: почему классические метрики не подходят для оценки эффективности разработчиков, как измерять её правильно и что делать, если вам кажется, что сотрудник работает не только на вас.

Привет, Хабр! Как и обещали — вторая часть истории про то, как мы строим InfoWatch ARMA Стена (NGFW) в текущих реалиях. Первая часть — тут.

Сегодня про:

- ИИ и нейросети
- миграцию
- отечественное железо
- почему NGFW, а не data diode
- цены и пилотирование

ИИ сейчас почти из каждого утюга. Как у вас с этим дела в продукте?

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

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

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

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

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

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

Ох уж эти журналисты! На прошлой неделе по СМИ полетела «шок-новость» о «новом» решении российского суда.

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

Что дальше началось в СМИ, это жесть:

— «Авторские права на картинки из нейросетей больше не действуют!»
— «Нейроарт теперь не творчество, официально!»
— «Теперь всем «нейронщикам» будут отказывать!»

Я как юрист по авторским правам нашел это дело, вычитал решение и готов рассказать, что там произошло на самом деле.

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

Интересные факты, о которых не написали в СМИ:

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

История Николая именно такая.

Последние годы стали серьёзным испытанием для тестирования.

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

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

В этой статье я хочу привлечь внимание к тому, насколько большую роль подготовка данных играет для нейросетей в QA. Конкретно, речь пойдёт о группировке падений перед анализом их причин. Я буду анализировать запуски инструментом для автоматической отладки багов — playwright-ai/auto-debug.

MLSecOps переносит принципы DevSecOps на ИИ-системы. Он делает безопасность измеримой, воспроизводимой и встроенной в разработку и эксплуатацию, а не «прикрученной» в конце. В этой статье мы описываем практический road-map из пяти этапов, который позволяет последовательно выстроить этот контур: от видимости и политик к управляемому доступу, контролю кода, runtime-защите и полноценным AI Security Operations.

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

Книжный тир-лист, SPA, боты и 55 запросов в месяц. Честная история пет-проекта: от «все обнимут меня» до пререндера и коллабораций с блогерами.

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

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

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

Люблю я мини-ПК. Это крайне интересные устройства, позволяющие добиться впечатляющей производительности при небольшом объеме. Причем корпоративные модели HP, Dell и Lenovo устроены заметно интереснее большинства недорогих китайских коробочек. В них используются обычные сменные процессоры, доступная память, стандартные накопители и вполне ремонтопригодные цепи питания.  

К чему это я? Будем чинить один из таких девайсов. А именно — HP Pro Mini 400 G9, его я нашел на одной из онлайн-барахолок. Продавец указал, что компьютер не включается, а на плате есть заметный прогар. С подобными повреждениями я уже работал и несколько раз успешно возвращал технику к жизни, поэтому аппарат показался подходящим кандидатом для очередного ремонта. Расчет был простой: разобрать корпус, удалить сгоревшие детали, восстановить дорожки и выяснить, насколько далеко система сможет пройти последовательность запуска. На практике все оказалось немного сложнее, зато сама диагностика дала хороший повод подробно посмотреть, как устроен современный корпоративный мини-ПК.

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

Однако, как мы знаем, электролиз зачастую ассоциируется и ещё с одним процессом — разложения растворов на газообразные компоненты, в частности воды, — на кислород и водород…

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

Учёные постоянно исследуют новые потенциальные возможности по осуществлению электролиза и находят иной раз просто поразительные варианты!

Например, как вам понравится электролиз без подвода внешнего электричества, с прямым использованием механической энергии для разложения воды?!

«Электролиз без* электричества»… Хмм, а разве такое бывает? Как выясняется, вполне себе!

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

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

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

В прошлых частях мы тестили и сравнивали разные модели, которые рисовали игровые ассеты по референсу из Пейнта. А что насчет разрушаемых декораций? Отправляемся на нейро-полигон.

Я инженер-программист на небольшом российском заводе. Несмотря на скромные масштабы производства, в штате имеется финансовый аналитик с постоянными потребностями в (внезапно) данных из учётной системы.
В сети я так и не нашёл более-менее полного гайда по подключению баз 1С к агентским средам через MCP. Встречаются отдельные статьи про Model Context Protocol (много), примеры для файловых систем, GitHub или PostgreSQL, но ничего про реальную интеграцию с 1С.

Поэтому решил собрать собственный опыт в одном месте.

В первой статье я говорил, что безопасность — это свойство архитектуры, а во второй разложил по полочкам способы построить logical air gap. Теперь самое главное: «А зачем вообще это всё? У нас есть firewall, WAF, TLS и патч-менеджмент».

Каждый инженер или системный администратор, работавший в компании с большой историей, знаком с этой болью: инфраструктура масштабируется, сотрудники приходят и уходят, а в службах каталогов постепенно накапливаются тонны legacy-объектов. С одной стороны, всё может работать в штатном режиме, но на деле контроллеры домена начинают с задержкой откликаться на LDAP-запросы, аутентификация периодически дает сбои, а в случае миграции на новое ПО админам приходится долго разбираться с правами доступа.

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

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

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

Use case: поверхность, где результат зависит от процесса

Магнитная поверхность не равна одной банке материала. Это система.

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

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