Все потоки

Решил посчитать, сколько раз языковые модели отзываются плохо о конкретной компании. Вроде простая задача: прогнать запросы через несколько моделей, разметить тональность ответов, поделить негативные на общее число. У меня получилось три негативных ответа из 358 — 0,8%. Число выглядело спокойным, и я чуть не отправил его в отчёт как есть.

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

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

Кэшировал агентный цикл ИИ‑триажа в своём security‑гейте — 80% входных токенов из кэша, ≈ 61% экономии. По пути нашёл 4 реальных бага, читая сырой вывод модели, вместо того чтобы верить цифрам в отчёте.

Бывает так: код хороший, задачи закрыты, к технической части претензий нет. Но и повышения тоже нет. Или идею не взяли. А на интервью — отказ без внятной причины.

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

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

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

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

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

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

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

Нейросетям в современном виде — несколько десятилетий. А вопросом «как вообще возникает знание?» люди занимаются больше двух тысяч лет. Значит, рассуждал я, где-то между Платоном, Аристотелем, Пирсом, Гегелем и Кантом наверняка лежит забытый метод обучения. Осталось перевести его с философского на PyTorch, вызвать backward().

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

Абдукция Пирса уже живёт в Abductive Learning и нейросимвольных системах. Скептическое воздержание от суждения называется selective prediction. Воплощённое познание ездит по лабораториям в роботах. Телеология устроилась в goal-conditioned reinforcement learning. Даже диалектика уже добралась до отдельных алгоритмических работ.

То есть бесплатной оптимизации у Платона не нашлось, а то что нашлось я упаковал здесь.

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

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

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

Интересно вот что: большинство этих возможностей Kubernetes не нужны. Он опирается лишь на небольшое подмножество YAML. Отсюда возник простой вопрос: если Kubernetes нужна только малая часть YAML, почему бы не стандартизировать именно эту часть, а остальное не использовать? Вместо того чтобы вводить новый язык конфигурации, SIG CLI представила KYAML, более строгий и последовательный способ писать YAML. А мы в VK Cloud перевели об этом статью.

У большой базы знаний есть неприятное свойство. Она хорошо отвечает на вопросы, которые в нее уже положили, и никак не сообщает о вопросах, которых в ней не хватает

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

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

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

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

В статье расскажу, чем ИТ-аутстаффинг отличается от аутсорсинга по закону и по сути, когда специалист на площадке нужен и как устроен гибрид «руки на месте, команда удаленно».

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

Привет! Я Саломея, продуктовый технический писатель в Selectel. В этой статье поделюсь своим опытом, как с помощью tmux упорядочить этот хаос и сделать работу удобнее. Разделим окно терминала на панели, запустим сессию, которая не прервется при закрытии окна, автоматизируем настройку рабочего пространства. Посмотрим, как выполнять команду сразу на нескольких серверах.

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

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

Делаем приложение, которое готовит расчётные наборы данных для нативного BI-конструктора Битрикс24.

Пользователь описывает нужные показатели обычной фразой, приложение через ИИ-помощника собирает набор и публикует датасет в «Рабочее место аналитика». Аналитику остаётся один раз собрать по нему график, выбрав нужные поля и способы визуализации.

Поиск работы в 2026 году на крупнейших агрегаторах вроде hh.ru напоминает прогулку по минному полю без миноискателя. То, что когда-то было удобным инструментом, деградировало в гигантский marketplace для мошенников, траферов и корпоративных паразитов. Вместо оффера мечты обычный работяга получает каскад из фейковых вакансий, психологических тестов для умственно отсталых и откровенного криминала, прикрытого маской «менеджера по обработке заявок».

Хотите убить сложный процесс? Просто перенесите его в таск-трекер как есть. Мы чуть не сделали именно так, но за 45 объектов успели разобраться, как строить доски, не тонуть в задачах и не превращать систему в ещё один обязательный ритуал. Рассказываю, как все было.

Меня зовут Вера Касьяненко, я разработчик из команды DevRails AI в MTS Web Services. Сейчас мы создаем агента-разработчика — сервис, в котором языковая модель сама пишет код, запускает тесты, делает ревью и создает коммиты.

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

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

Привет, Хабр! Меня зовут Дмитрий Сенюшкин, на связи AIRI и команда «Автономное зрение». Наша научная группа активно интересуется темой беспилотных автомобилей и сегодня хотелось бы рассказать об одной из наших последний наработок в области симуляции для тестирования и обучения алгоритмов. 

В этой области важную роль играет не только объём обучающих данных, но и их разнообразие. Эту проблему можно решить с помощью синтетики, которую производят реалистичные дорожные симуляторы. Мы пошли по этому пути и создали XSIM — новую технологию, для которой пришлось пересмотреть традиционные пайплайны представления объектов. Мы представили XSIM на недавно прошедшей IJCAI 2026, здесь же я перескажу суть нашей работы.

Атакующий уже знает логин и пароль — купил, подобрал по утечке, вытащил стилером с домашнего ноутбука. Второй фактор — пуш в приложении с кнопками «Одобрить» и «Отклонить». И вот он просто начинает логиниться. Раз за разом. Телефон жертвы звенит в двадцать третий раз в 02:40, человек спросонок жмёт зелёную кнопку — не потому что глупый, а потому что это самый быстрый известный ему способ прекратить вибрацию. Всё, второй фактор пройден.

Так вынесли Uber в сентябре 2022-го — там пушам ещё помогло сообщение в мессенджере от «айтишника»: мол, одобрите, чтобы это прекратилось. Примерно так же заходили в Cisco несколькими месяцами раньше.

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

Основной вопрос возникает раньше:

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

1-2 года назад я реализовывал такую интеграцию на PHP. Токены хранили в MySQL, а работу с OAuth разбили на несколько отдельных файлов.

Сейчас решил восстановить общую архитектуру этой реализации.

Если убрать детали, OAuth-интеграция выглядит довольно просто:

Authorization Code → Access Token + Refresh Token → сохранение в БД → запросы к REST API → обновление токенов → повторное сохранение в БД.

Код авторизации берется в AmoCRM:

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

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

Чем больше филиалов у компании, тем труднее поддержать обучение персонала на одном уровне. Без чёткой системы каждый офис со временем начинает учить по‑своему.