Kurgan-Telecom Ru | Информационные технологии

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

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

Полгода назад по сети разошлась история про AI-агента, который слил 441 тысячу за один твит — у модели был доступ к исполнению, и никто не стоял между её решением и деньгами. С тех пор каждый раз, когда речь про «дать агенту управлять чем-то важным», всплывает один страх: а если он сделает глупость с реальными деньгами?

Я строю сервис, где AI-агент управляет рекламными кампаниями в Яндекс.Директе, Google Ads и VK — то есть ровно там, где ошибка агента стоит денег напрямую. И главный вопрос проектирования был не «как научить агента управлять рекламой», а «как сделать так, чтобы он физически не мог потратить деньги без человека».

В статье — архитектура, где у агента нет ни одной кнопки, которая тратит бюджет сама:

— граница read/write: агент свободно читает метрики, ищет аномалии, строит отчёты и дашборды, но любое действие, тратящее деньги, — только три инструмента, и все через подтверждение; — контур human-in-the-loop: перед тратой сумма сверяется с порогом, выше порога агент не исполняет, а лишь предлагает — исполнит отдельный сервис после клика человека; — срок годности подтверждений, защита от двойного исполнения, белый список исполняемого, prepaid-модель как естественный ограничитель цикла.

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

На входе у нас вакансия, на выходе — проверенный контакт в одной из трёх кампаний. Между ними: дубли, таймауты, catch-all, неоднозначные SMTP-ответы и окно, в котором процесс может упасть после передачи контакта, но до сохранения статуса. Показываю, как мы расставили дешёвые и дорогие проверки и почему выбрали at-least-once.

Сотни миллиардов вложены в IIoT, предиктивную аналитику и цифровые двойники. Но часто проекты предиктивного ТОиР достигают технологического успеха — и операционного провала: модели верно прогнозируют отказы, а оборудование по-прежнему ремонтируют «по факту».

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

Привет, Хабр! На связи Данила Трусов, директор продукта «Инферит ИТМен».

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

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

Поэтому мы запустили акцию «Яблочный Спас»: получите сертификат на скидку 30% на лицензии «Инферит ИТМен» на сайте и успейте применить его до 31 декабря 2026 года.

Когда я начал работать с CH32V203G6U6 и обнаружил, что там есть 64-битный аппаратный таймер, то подумал: ух, это же отлично, раз таймер аппаратный, то и о чтении/записи заботится сам микроконтроллер. И какое-то время это не вызывало вопросов. А потом…

Некоторые банки и государственные сервисы используют TLS-цепочки, которые заканчиваются корнем Russian Trusted Root CA. Яндекс Браузер и Атом умеют работать с такими цепочками. Chrome для Android показывает NET::ERR_CERT_AUTHORITY_INVALID, потому что этого корня нет в хранилище Chromium.

Я пользуюсь Chrome и не хотел заводить второй браузер для нескольких сайтов. Поэтому добавил корень в Chromium, ограничил его зонами .ru и .рф и собрал отдельный APK. Проект получил название Ruthenium.

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

Но у такого замера есть неприятное слепое пятно. Можно аккуратно сохранить 99% выдачи исходного эмбеддера и все равно плохо находить нужные документы на своем домене. Внешний бенчмарк, даже сильный, этого не гарантирует. BEIR как раз был создан, чтобы показать, насколько результаты retrieval меняются между разными задачами и доменами; один усредненный скор там не заменяет проверку на собственных данных.

Нужен свой eval set. И тут обычно возникает ложная развилка:

Вы уже брали когнитивный долг

Представьте, что вы руководите проектом. Аналитик Вася присылает двадцать слайдов, которые сегодня (а на самом деле вчера) надо показать клиенту. Общая логика вроде ОК, ключевые цифры разумные. На 17-м слайде есть результаты расчета, на проверку которого, по-хорошему, уйдет день. Вася говорит, что все проверил.
Можно попытаться перенести встречу. А можно решить: достаточно, Вася выглядит адекватным, риск небольшой, идем к клиенту.
Если вы были в похожей ситуации – вы уже брали когнитивный долг.
И никакого искусственного интеллекта для этого не требовалось.

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

Начальник не повторяет все вычисления сотрудника. Архитектор не читает каждую строчку каждого сервиса. Главный редактор не перепроверяет каждый факт так, как это делал автор. Партнер консалтинговой фирмы не строит своими руками каждую модель, которую показывает клиенту.
Более того, если заставить его все это делать, организация перестанет иметь экономический смысл.
Поэтому вопрос — не «есть ли у нас когнитивный долг?»
А два других: сколько его у нас и достаточно ли мы контролируем риск? 

Инструмент: C4 QuietGridLabs. Можно открыть демо без авторизации: проект будет храниться локально в браузере.

Иногда архитектура «есть» — но пользоваться ею невозможно.

На доске лежит схема сервисов. В Confluence живёт описание. Где-то рядом — sequence-диаграмма, которую никто не открывал с прошлого года. ER-модель хранится в другом инструменте. А когда на ревью возникает простой вопрос «какой endpoint обслуживает этот путь?», команда начинает собирать ответ из памяти, догадок, выдумок, ссылок и исходников.

Я больше 15 лет работаю в ИТ, из них около десяти занимаюсь проектированием и системным дизайном. За это время перепробовал немало: Sparx, ArchiMate, Structurizr, Confluence, whiteboard-сервисы. Я не считаю их плохими — у каждого есть свой сценарий и своя аудитория. Но лично у меня постоянно оставалось ощущение разрыва: диаграмма была отдельно, документация отдельно, а живой контекст системы — в голове у людей.

В какой-то момент моими рабочими спасателями стали whiteboard и VS Code, а позже Cursor. В них можно быстро собрать мысль, оставить немного полезного творческого беспорядка и двигаться дальше. Но они не решали главную проблему: хотелось, чтобы система, её связи, сценарии и документация были одной навигационной моделью.

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

Рассказываем, как одна система из камер, датчиков и нейросетей закрыла сразу три задачи стройки: охрану труда, учет транспорта и контроль сроков.

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

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

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

Сделай сам — покажи другим, как надо. На старте сезона DIY Лемана Тех и Хабр пришли с таким запросом к сообществу авторов, и они не подвели. В рамках сезона вышло множество статей о самых разнообразных проектах, сочетающих работу с железом и софтом. Участники соревновались в том, кто лучше всех владеет отвёрткой, 3D‑принтером, различными языками программирования, у кого самая необычная идея и кто способен максимально хардкорно её воплотить.

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

В прошлой статье про StyleX я разбирал, почему компилируемый CSS выглядит логичным продолжением ветки CSS-in-JS. Одно из главных свойств StyleX для меня — предсказуемость: стили описываются в ограниченной форме, которую можно анализировать ещё до запуска приложения.

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

Теперь Meta открыла Astryx — дизайн-систему, построенную на React и StyleX. На первый взгляд это выглядит как релиз большой библиотеки: больше 170 компонентов, темы, тёмный режим, шаблоны, CLI, всё как мы любим. Но количество компонентов здесь не самое интересное. Astryx стоит рассматривать как следующий шаг после StyleX: если StyleX делает предсказуемыми стили, то Astryx пытается сделать предсказуемой работу с интерфейсом целиком — и для человека, и для AI-агента.

Привет, Хабр! Представьте ситуацию в интернет-магазине. Клиент звонит и пишет в поддержку, так как получил поврежденный заказ. При этом он уже откладывал повторную покупку из-за долгой доставки в прошлый раз и не дописал отзыв, который хотел оставить неделю назад. Человек на грани ухода к конкурентам. Что увидит типичный оператор поддержки? Да просто текущее обращение. Он оформит возврат, закроет тикет — и на этом как бы все. Остальные сигналы останутся незамеченными им. В противовес ему, агентная система видит всю картину, ловит паттерны и закрывает боли клиента: оформляет возврат, предлагает промокод на следующую покупку, устраняет причину недовольства. Это рабочая модель, которую уже описывают аналитики McKinsey в свежем отчете о перестройке клиентского опыта в эпоху агентского ИИ.

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

Битва уже идёт, даже если ты этого не замечаешь. Более того, AI уже побеждает!

Старые фильмы про битву против искусственного интеллекта, обычно, рисовали нам классическое поле боя. «И восстали машины из пепла ядерного огня. И пошла война на уничтожение человечества. И шла она десятилетиями…» — наверняка почти все, кто смотрел «Терминатор 2: Судный день» помнят это вступление. Тогда войну с искусственным интеллектом воспринимали как что-то, что будет похоже на то, что мы уже знаем. Но так как «интеллект» искусственный, война идёт по искусственным правилам.

Как вам название? Звучит интригующе? Нет, это не кликбейт. Это моя реальная история.

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

Начну я свою историю с начала. Т. е. со школы. Детский сад, так уж и быть, упущу ;-)

Приветствуем, Хабр.

Не секрет, что большие языковые модели и, в частности, трансформеры (GPT) серьезно повлияли на работу программиста, привели к автоматизации многих рутинных задач, значительно удешевили проверку концепций и эксперименты при разработке новых продуктов. Коренные изменения произошли не только в разработке, но и во взаимодействии пользователя с ботами, агентами, поисковыми системами. Промпт-инжиниринг буквально за полтора года превратился из искусства в ремесло, которое способен освоить и подросток. Мы хотим очертить ближайшие перспективы выхода книг из типографии и планы на обозримое будущее — на наших верфях и уже практически на стапелях готовится целый флот литературы, ориентированной на работу с искусственным интеллектом.

Когда начинаешь выбирать оперативную память, сразу бросаются в глаза две главные цифры. Производители даже в маркировку обычно выносят тип-частоту и тайминги. Обычно это цифры вроде DDR5-6000 и CL30. Споры о том, что из них важнее для игр, идут уже не меньше 15 лет, и как правило, обе стороны в них не правы примерно одинаково. Частота и тайминги — это не два независимых параметра, они связаны между собой через длительность такта, но часто важнее оказывается другой фактор. Об этом сейчас и поговорим.