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

Привет! Меня зовут Яна Мотрий, я старший системный аналитик в Контуре. Моя команда развивает сервисы для партнёрской сети: внутреннюю PRM, где сотрудники Контура ведут партнёров, и личный кабинет, куда заходят сами партнёры.

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

Статья будет полезна системным аналитикам уровня middle+, а ещё — аналитикам из заказной разработки, которые присматриваются к продуктовым командам или бизнес-анализу.

Привет, Хабр. На связи Николай Карасов, ведущий разработчик отдела рекомендаций контентных сервисов в AI VK. Наша команда отвечает за рекомендации в Ленте ВКонтакте.

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

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

Когда у функции на базе языковой модели нет одного правильного ответа, привычные проверки по принципу «ожидание = фактический результат» перестают работать. Тестировщику приходится определить, какие свойства ответа действительно важны, как отделить допустимую вариативность от ошибки и построить понятный критерий pass/fail.

В этой статье на примере функции суммаризации обращений разберём, как сформировать контракт поведения, набор проверок и подход к регрессионному тестированию AI-фич.

Привет, Хаброжители!

Встречаем осень с хорошими новостями — в нашем интернет-магазине только что началась новая распродажа!

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

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

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

Есть как минимум один сценарий, который знаком каждому, кто хоть раз занимался ремонтом своего и особенно чужого компьютера. Я про тот случай, когда Windows не грузится, а средства восстановления не помогают. И тут начинается квест с поисками второго рабочего компьютера, скачиванием образа, подготовкой загрузочной флешки и колдовством с BIOS. Но времена меняются, и Microsoft решила, что надо максимально упростить эту цепочку. Собственно, добавление функции Cloud rebuild сократило эту цепочку до одного шага. Это полная переустановка системы прямо из среды восстановления с загрузкой через интернет. В бета-канале программы Insider она доступна с 8 сентября. Вот только флешку выбрасывать все равно рано.

В диспетчере задач напротив Archicad 26 стояло «Не отвечает». Процесс держал около 13% процессора и почти 4 ГБ памяти, каталог покрытий стен больше шести минут показывал «2D | Обработка элементов». Обычно в этот момент задачу снимают. Мы не стали: на 389-й секунде обработка ещё шла, к 452-й таблица была готова. Программа не зависла, она считала.

Это ноутбук дизайнера интерьеров, нашей клиентки. Она попросила помочь удалённо: каталог отделки стен открывается минутами, а когда его ставишь на лист, Archicad перестаёт отвечать. Работали две нейросети. Codex управлял её рабочим столом через удалённый доступ: открывал проект, читал настройки, замерял время и вёл журнал. Claude Code разбирал журнал, задавал вопросы клиентке и готовил задания на следующий заход. Кода в этой истории нет вообще, только чужая программа с интерфейсом, в котором агенту приходится кликать.

Есть довольно неприятная проблема с тестовой документацией: тест работает, успешно проходит и при этом уже проверяет не совсем то, что нужно.

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

На очередном регрессе он снова зелёный.

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

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

Для этого и нужна трассировка требований.

У меня есть коллекция музыки, которой нет ни в одном стриминге: FLAC, японские альбомы, редкие релизы. Слушать её хотелось так же удобно, как Spotify, с телефона и компьютера, с текстами и итогами года. Готовые решения закрывали задачу по кусочкам, поэтому я написал своё: Nami — плеер для Android, Windows и Linux и собственный сервер на Rust. Внутри: синхронизация между устройствами через одну SQL‑таблицу вместо девяти, караоке‑тексты с выравниванием по словам нейросетью прямо на телефоне, фуригана и ромадзи для японских песен, bit‑perfect‑вывод на USB‑ЦАП и сервер, который занимает 69 МБ памяти.

Не так давно меня приглашали тестировать Figma-like редактор от Ростелекома. Тогда он был всё-таки сильно сырой. Оказалось, что другие команды не дремлют и тоже готовят свои решения. Сегодня у нас на обзоре новый кандидат на импортозамещение Figma. Называется linia.pro. Сервис около года разрабатывается командой из Москвы.

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

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

При всех достоинствах Telegram, есть у него одна особенность — он тоже оставляет следы в ВебАрхиве. То есть, при наличии желания и определенного количества свинца (не картечи) в пятой точке, мы можем найти следы жизнедеятельности того или иного персонажа в Telegram через Wayback Machine.

Для этого мы можем пойти сюда: https://web.archive.org/collection‑search/telegram и начать лопатить все вручную. Дорки нам в помощь. А можем автоматизировать наш поиск при помощи CDX API или собственных скриптов или других приспособлений. Это уж кому как больше нравится.

Механизм работы с Telegram через Wayback Machine не оригинален и принципиально не отличается от поиска по другим ресурсам. Но, как всегда, есть нюансы...
Разберемся.

Дисклаймер: изначально это был комментарий на другую статью, но та статья оперативно улетела в черновики, а @0xKubik — в readonly (?!). Так что пишу тут, в надежде что однажды автор ответит тут, или свяжется иначе.

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

Статья будет полезна тем кто работает в автоматизации retail, речь в ней пойдёт о настройке весов rongta RLS1000/1100 — с ними частенько приходиться работать на просторах СНГ.

Первая версия получилась курсом по shell-скриптингу. А я не этого хотел: мне нужно было разобраться с Linux на практике, а не в теории по книге — права, службы, журналы, монтирование, сеть. На выходе же лежала полсотня заданий вида «напиши .sh, который…». Хотя каждое по отдельности выглядело нормально.

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

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

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

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

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

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

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

Я продуктовый дизайнер, больше шести лет делаю SaaS. Программировать умею, но фулстек-разработчиком себя не назову. Уже несколько месяцев я в одиночку делаю Котомку, планировщик жизни по методу PARA: сферы, проекты, задачи, календарь, привычки, финансы. Есть веб, мобильная версия, синхронизация между устройствами и с Google и Apple календарями. Почти весь код пишет Claude Code. Я ставлю задачи, проверяю результат и принимаю решения.

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

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

Может ли Россия участвовать в этой гонке, не пытаясь полностью повторить NVIDIA? Какие направления выглядят реалистичнее универсального GPU и где в подобных системах может использоваться RISC‑V?

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

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

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

А в итоге разобрала файлы проектов Claude Design по кусочкам, потратила месяц на отладку и сделала плагин, который переносит готовый проект из Claude Design прямо в Figma — с редактируемыми слоями, auto‑layout, текстами и данными.