Искусственный интеллект

Привет, Хабр! Меня зовут Кира, я бизнес‑аналитик клиентского сервиса ITSM 365 и куратор командной базы знаний.

Наш продукт развивается с каждым годом, и вместе с ним растет количество клиентских обращений: их становится больше, а сами вопросы — сложнее. Если в 2015 году один бизнес-аналитик разбирал около 300 кейсов в год, то сегодня — около тысячи. При этом средняя оценка работы с обращениями остается на уровне 4,9+.

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

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

Всем привет! Меня зовут Дима Матушкин, я инженер в команде Nova и занимаюсь развитием Nova AI.

В этой статье разберем одну из задач, с которой сталкивается почти любая команда, запускающая AI/ML-нагрузки в Kubernetes: как эффективно использовать GPU в кластере, где одновременно живут инференс, обучение, эксперименты, ноутбуки дата-сайентистов и batch-задачи.

На старте кажется, что достаточно установить NVIDIA GPU Operator, прокинуть видеокарты в Kubernetes и начать указывать nvidia.com/gpu в манифестах. Для простых сценариев этого действительно хватает. Но как только нагрузок становится больше, а GPU начинают конкурировать между собой, выясняется, что проблема не только в том, чтобы "выдать видеокарту" конкретному поду.

Нужно уметь запускать связанные поды как единое целое, управлять очередями, учитывать приоритеты, не ломать распределенные задачи из-за сетевой топологии и делить GPU так, чтобы дорогие ресурсы не простаивали. Обычный планировщик Kubernetes не закрывает эти сценарии комплексно, поэтому для Nova AI мы начали смотреть в сторону специализированных планировщиков для AI/ML нагрузок.

Переносные колонки с ассистентом давно освоили уже даже в России. Новое здесь — камера, которая смотрит, как ты живёшь.

С чего всё началось

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

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

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

Мне не хватало не ещё одного источника — их и так достаточно. Не хватало того, чтобы кто‑то прошёлся по всему этому за меня: убрал повторы, выкинул лишнее и выдал короткий список по важности. Без экспертов, желтухи, рекламы, баннеров — чистая событийная лента.

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

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

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

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

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

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

Однако, какой бы ни была архитектура, все их объединяет одна и та же проблема — данные. Для полноценного обучения нужны сотни и тысячи изображений, с разных ракурсов, в разных условиях. Если цель — академический проект, обнаружение машин или колосков пшеницы, то найти датасет не составляет проблем. Но что, если датасета нет и/или его невозможно собрать в принципе в нужном объеме? Скажем, редкий дефект в производстве, истребитель новой конструкции? Ждать, пока накопится много брака, или надеяться на утечку чертежей?

Мы провели пару экспериментов с моделью YOLO для проверки гипотезы: как далеко можно уехать, используя исключительно синтетические данные?

Статья про то, как построить приложение с AI-ассистентом и не застрять на самом неприятном месте, когда бэк готов, а интерфейс внезапно съедает недели.

Почему современный фронтенд сложнее, чем кажется снаружи. Особенно если вы идёте через spec-driven development, пишете требования вместо кода и ждёте, что Claude, Cursor или Kiro быстро соберут работающий продукт.

👀 Внутри: перекос фронта и бэка по объёму кода, состояние кнопок и форм, дизайн-системы, локализация, accessibility, тысячи npm-зависимостей, скучные интерфейсы от LLM, Playwright MCP, Figma MCP, визуальные тесты и планирование проекта с нормальным запасом на UI-грабли.

Заходите, читайте и делитесь своим опытом AI-разработки ❤️

Хотите научиться генерировать видео по тексту или аудио, но не знаете, как это сделать? Wan2.2 отлично работает в ComfyIU, но интеграция в собственные проекты затруднительна. К счастью, есть альтернатива: LTX-2 можно легко запустить без дополнительной обвязки.

В этой статье рассмотрим, как запустить модель LTX-2 на своем облачном сервере.

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

В конце соберём собственное приложение, которое объединяет эти возможности на платформе для вайбкодинга от Битрикс24.

Признаю: в прошлой статье про тестирование Caveman я в конце написал, что такие инструменты, как RTK, действительно, могут помочь сэкономить токены. Я доверял самому принципу возможности экономии токенов, но не доверял конкретным цифрам эффективности, которые заявляет Headroom. Был уверен, что, садясь за тесты, скорее всего, увижу, не 60–95% экономии токенов, а типа 10% — или что-то такое. Но результат меня удивил в худшую сторону. Итак, тестируем Headroom вместе:

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

Обычный чат-бот вроде ChatGPT, Gemini или Claude быстро разберет данные и выдаст идеи, которые могут зайти вашей аудитории.

GPU-версия ByteTrack, где математика всех камер считается общими батчами: один вызов на все потоки вместо трекера-на-камеру. На 16 потоках это ускоряет трекинг в 6 раз (104 → 17 мс/кадр на RTX 4090). А за первой, «наивной» версией пряталось всего 1.2x — почему, показали три антипаттерна PyTorch, на которых легко застрять и вне трекинга: GPU-вызовы в цикле, заливка кадров на 1.6 ГБ/с вместо 25, и FP16, который тихо съедал по 300 мс на кадре. Все цифры воспроизводимы, есть сравнение с NVIDIA DeepStream и открытый код.

Claude Code, Codex, Gemini CLI — мощные штуки. Но живут они в терминале: вы открываете окно, печатаете задачу, смотрите, как агент думает, лезет в файлы, гоняет тесты. Для человека — отлично. А теперь представьте, что в это кресло перед терминалом нужно посадить не человека, а вашу программу: чтобы она сама ставила агенту задачу, видела каждый его шаг и могла остановить опасное действие до того, как оно случится.

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

Первая статья из цикла «Аналитик в чужом процессе»

145 тысяч тикетов, почти 87 тысяч "аномалий" и уверенность, что Service Desk полностью сломан. Но один разговор с опытным специалистом первой линии заставил меня выбросить половину критериев, переписать анализатор и полностью изменить выводы. Эта статья — о том, почему большие данные сами по себе ничего не объясняют, если сначала не понять сам процесс.

12 июля флагманская GPT-5.6 Sol Pro после восьми часов размышлений побила лучший человеческий результат в задаче о длине пути градиентного спуска — и оформила его полноценной статьей на 14 страниц с доказательствами, таблицей констант и скриптом для их проверки. Прежний рекорд — оценка 2.29^n — принадлежал людям, но о нем мало кто знал: он так и не был опубликован. Историю двухлетнего противостояния людей и моделей исследователь OpenAI Себастьен Бубек рассказал в треде 10 июля, а уже через два дня объявил о падении рекорда.

Забавная история про то, как я решил разбавить актив в своем чате для друзей, добавив самого настоящего Т-800, который мог бы свободно общаться с участниками, не потратив копейки денег на API - чисто бесплатные модели с OpenRouter. Впрочем, впоследствий была попробована и локальная модель.

Привет, «Хабр»!

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

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

Последнее время я все чаще вижу одну и ту же картину.

Появился тикет. Программист копирует ссылку, передает ее AI-кодинг-агенту и через какое-то время получает готовый Pull Request.

Вроде бы красота.

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

Только потом начинается самое интересное.

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

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

Но инструмент, который быстро пишет код, не отменяет необходимость думать.

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

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

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

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

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