Для Claude представлен модуль антиплагиата Stop Slop, который убирает из текста все маркеры ИИ. Проект вырезает шаблонные фразы, лишний пафос и делает текст более живым. Можно использовать как в Claude Code, так и в веб‑версии, просто добавив SKILL.md в проект.
ИИ-помощник для анализа требований
В работе техпресейла значительная часть времени уходит на анализ требований клиентов — они часто приходят в виде больших опросников, которые нужно внимательно разобрать и прокомментировать.
Когда таких документов много и нужна оперативность, ручная обработка начинает замедлять работу команды. С этим регулярно сталкивалась команда техпресейла Naumen. Поэтому Настя и Даша, системные аналитики команды, решили попробовать автоматизировать часть процесса и внедрили ИИ-помощника для анализа требований.
Рассказываем, как они собирали данные, какие подходы пробовали и как в итоге пришли к решению на базе RAG.
1️⃣ Чем занимается техпресейл
Техпресейл — это мост между продуктом и продажей. Мы проводим технические демонстрации, обсуждаем требования клиента и помогаем понять, подходит ли продукт под его задачи.
Чаще всего работа техпресейла с клиентом начинается с опросника — Excel-документа с требованиями.
2️⃣ Почему Excel-файл оказался неудобным для анализа требований
Типичный опросник — это таблица с тремя колонками:
требование клиента
какой продукт соответствует
комментарии
Иногда требований десятки или сотни — нужно внимательно прочитать, найти контекст в прошлых кейсах, вручную проверить формулировки и ссылки на источники. Даже опытный специалист тратит на такой документ около часа.
Когда таких задач много и у них срочные дедлайны, возрастает нагрузка на команду и появляются риски задержек. Поэтому мы решили автоматизировать процесс.
3️⃣ С чего мы начали автоматизацию
Сначала нужно было собрать данные. Поэтому первым шагом мы:
Собрали все опросники за год в единый массив.
Привели их к единому формату.
Классифицировали требования.
Проверили и почистили данные от дублей и неточностей.
В итоге получился датасет примерно из 2 000 требований, который стал основой нашей базы для тестирования ИИ-помощника.
4️⃣ Почему классические модели не сработали
Первой идеей было использовать классические методы анализа текста. Мы пробовали TF-IDF, Bag-of-Words и стандартные модели классификации.
Но столкнулись с двумя проблемами:
низкое качество классификации
дисбаланс данных
Большинство требований продукт действительно покрывал, поэтому модель быстро «научилась» отвечать одинаково. Стало понятно, что нужен другой подход.
5️⃣ Как мы пришли к RAG-подходу
Мы перешли к векторному поиску и трансформерам. Идея была в том, чтобы по новому требованию находить в базе знаний похожие требования и использовать их как контекст.
Получился умный поиск по нашим прошлым ответам. Но этого все равно было недостаточно: нужно было не только находить похожие требования, но и генерировать комментарий.
Так мы пришли к подходу RAG (Retrieval-Augmented Generation) — LLM сначала находит факты в базе знаний, а уже потом формирует ответ.
6️⃣ Как работает наш ассистент
Сервис работает в Telegram-боте и поддерживает два сценария.
Вопрос в чате — пользователь задает вопрос, бот ищет информацию в базе знаний и формирует ответ.
Загрузка Excel-файла — пользователь загружает файл с требованиями, после чего сервис проходит по каждой строке и автоматически заполняет:
соответствие (да / нет / не знаю)
комментарий с объяснением соответствия
7️⃣ Из чего состоит база знаний
Мы используем два источника:
документацию по продуктам Naumen
структурированные опросники из прошлых проектов
Документы разбиваются на небольшие смысловые фрагменты, для каждого фрагмента вычисляются эмбеддинги, после чего они сохраняются в векторной базе. Когда приходит новый запрос, система находит самые релевантные фрагменты и использует их как контекст для ответа.
8️⃣ Какие есть ограничения у ассистента
ИИ-ассистент помогает быстрее разбирать требования, но полностью заменить аналитика он пока не может.
Например, иногда клиенты присылают требования, которых еще нет в базе знаний. В таких случаях бот отвечает «не знаю», и требование разбирает специалист.
Также иногда встречается типичная проблема LLM — галлюцинации. Поэтому финальную проверку ответа все равно делает системный аналитик.
Nvidia показала DLSS 5 – AI для улучшения картинки в играх
NVIDIA анонсировала DLSS 5: нейросеть теперь не масштабирует картинку, а перерисовывает освещение и материалы в реальном времени
Вчера на GTC 2026 NVIDIA показала DLSS 5. Если коротко: это уже не апскейлер и не генератор кадров. Это real-time neural rendering — модель, которая берёт кадр из игры и перерисовывает освещение и материалы до фотореалистичного уровня. Разбираю, что известно из пресс-релиза и почему это принципиально отличается от DLSS 4.
Что изменилось по сравнению с DLSS 4
DLSS был запущен в 2018 году как AI-технология для повышения производительности — сначала через апскейл разрешения, потом через генерацию целых кадров. Технология интегрирована в более чем 750 игр.
DLSS 4.5, представленный на CES в начале этого года, рисует с помощью ИИ 23 из каждых 24 пикселей на экране.
DLSS 5 — качественно другой подход. Вместо апскейла и генерации кадров, DLSS 5 вводит модель нейросетевого рендеринга в реальном времени, которая насыщает пиксели фотореалистичным освещением и материалами.
Дженсен Хуанг назвал это «GPT-моментом для графики» — объединением ручного рендеринга с генеративным AI.
Как это работает технически
DLSS 5 берёт на вход цветовые данные и векторы движения каждого кадра, а затем с помощью AI-модели насыщает сцену фотореалистичным освещением и материалами, привязанными к исходному 3D-контенту и консистентными между кадрами. Работает в реальном времени при разрешении до 4K.
Ключевое отличие от видео-моделей типа Sora или Veo: видео AI-модели генерируют фотореалистичные пиксели, но работают офлайн, их сложно точно контролировать, и им не хватает предсказуемости. Для игр пиксели должны быть детерминированными, работать в реальном времени и строго привязанными к 3D-миру разработчика.
AI-модель обучена end-to-end понимать сложную семантику сцены: персонажи, волосы, ткани, полупрозрачная кожа, а также условия освещения (фронтальное, контровое, пасмурное) — и всё это анализируя единственный кадр. То есть модель не просто «улучшает картинку» — она понимает, что в кадре кожа, что ткань, что волосы, и обрабатывает каждый материал по-своему.
Контроль для разработчиков
DLSS 5 даёт разработчикам детальные настройки интенсивности, цветокоррекции и маскирования, чтобы художники могли определять, где и как применяются улучшения, сохраняя уникальную эстетику каждой игры. Интеграция использует тот же фреймворк NVIDIA Streamline, что и существующие DLSS и Reflex.
Это важный момент: модель не навязывает свой «стиль». Разработчик может выкрутить эффект на максимум в одной сцене и полностью отключить в другой.
Какие игры поддержат
Среди подтверждённых: Assassin's Creed Shadows, Starfield, Resident Evil Requiem, Hogwarts Legacy, The Elder Scrolls IV: Oblivion Remastered, Delta Force, Phantom Blade Zero и ещё около десятка тайтлов. Публишеры: Bethesda, CAPCOM, Ubisoft, Tencent, Warner Bros. Games.
Выход — осень 2026. nvidia
Что это значит для индустрии
Разрыв между реалтайм-графикой в играх и офлайн-рендерингом в кино был всегда. Один кадр в фотореалистичном голливудском VFX может рендериться минутами или часами, а игровой кадр должен уложиться в 16 миллисекунд. Преодолеть этот разрыв только вычислительной мощностью невозможно.
NVIDIA предлагает обходной путь: не рендерить «честно» каждый луч света, а обучить нейросеть понимать, как свет взаимодействует с материалами, и достраивать результат в реальном времени.
Если технология сработает так, как описано — это меняет экономику игрового рендеринга. Вместо того чтобы тратить ресурсы GPU на точный расчёт каждого отражения, разработчик отдаёт «черновой» кадр нейросети, которая доводит его до фотореалистичного уровня.
Но пока это анонс на GTC без публичных бенчмарков. Реальное качество покажут осенние релизы.
Кто следит за развитием нейросетевого рендеринга — как оцениваете подход NVIDIA? Насколько реалистичны заявления про real-time neural rendering при 4K, если текущие видеомодели даже офлайн требуют серьёзных вычислений?
Кейс из личной практики: Claude Code + Chrome = 🚀
Продолжаю удивляться тому, на что способен Claude Code. Уже никого не удивишь тем, что он может накодить приложение или сайт с нуля. Но как насчет "реверс-инжиниринга" через Chrome?
Кейс
Есть корпоративная CRM система. В ней куча данных, которые показываются в преднастроенных отчетах. Очень монструозная и негибкая штука.
Заказчик резко начинает хотеть с ней "говорить" на естественном языке, да ещё и смешивать данные из разных отчетов. Система кастомная и совершенно под это не заточена. А за счет своего размера — адаптировать ее заняло бы месяцы. Что делать?
Правильный путь — спроектировать консистентные датамарты, сделать семантический слой с описанием всех данных, написать MCP сервер поверх этой системы на основе ее API.
Реальность — времени на это нет. Нужно навайбкодить proof of concept!
Ok, это заняло 3 часа 😎
Устанавливаем Claude расширение в браузер Chrome и настраиваем коннектор с Chrome в Claude Code.
Даем ссылку на UI нашей CRMки клоду и просим его внимательно изучить архитектуру, API запросы под капотом и на основе этого спроектировать MCP сервер. Причем никаких пояснений к системе не требуется, даже на swagger ссылка не нужна.
20 минут Opus тыкает интерфейс, читает запросы и внимательно изучает метрики, настройки, фильтры и группировки и тд. Результат записывает в MD файл. Туда же он пишет предлагаемую архитектуру MCP.
Далее просим Claude написать MCP сервер по полученному файлу и локально его задеплоить.
Профит! Спустя пару часов получаем рабочий MCP сервер поверх системы, которая для этого никогда не строилась.
Дальше Claude прописывает себе этот MCP как тул. И вот уже из дефолтного приложения Claude мы можем естественным языком задавать вопросы к данным в CRMке. А тк это делает клод — то поверх этих данных есть возможность строить графики, интерактивные визуализации, дашборды и отчеты. Бесконечная гибкость.
Все это без привлечения разработчиков и написания единой строчки кода руками.
В общем, с расширением в Chrome, Claude — просто машина 💪
Больше интересного про AI агентов и технологии в моем канале Заместители.
Anthropic представила исследование, которое показывает, что влияние ИИ на рынок труда пока значительно ниже его теоретического потенциала. В статье представлена новая метрика под названием observed exposure («наблюдаемое воздействие»). Она сравнивает теоретические возможности языковых моделей с реальными данными их использования, в данном случае на основе разговоров пользователей с чат-ботом Claude. Для анализа были объединены данные базы профессий O*NET, оценки того, какие задачи теоретически могут ускоряться с помощью ИИ, а также статистика фактического использования Claude в рабочих сценариях.
Результаты показали значительный разрыв между потенциалом и практикой. По оценкам исследователей, языковые модели теоретически способны ускорить выполнение 94% задач в компьютерных и математических профессиях. Однако на практике ИИ применяется лишь примерно в 33% таких задач. Большинство возможностей технологий остаётся нереализованным из-за ограничений самих моделей, юридических требований, необходимости человеческого контроля или сложной интеграции с профессиональными системами.
Исследование также выявило, какие профессии сейчас наиболее подвержены влиянию ИИ. На первом месте оказались программисты — около 75% их задач могут выполняться или ускоряться с помощью моделей. Далее следуют специалисты службы поддержки, операторы ввода данных и аналитики. В то же время примерно 30% работников практически не затронуты использованием ИИ: среди них повара, бармены, спасатели, механики и другие профессии, связанные с физическим трудом.
Компания Mistral AI представила большую языковую модель Leanstral. Это проект для разработки приложений с помощью вайб‑кодинга и оптимизированный для формальной верификации кода. Предполагается, что Leanstral может применяться для создания ИИ‑ассистентов, позволяющих не просто генерировать код, но и гарантировать отсутствие в нём ошибок.
Leanstral стала первой открытой моделью, поддерживающей язык программирования Lean 4 и связанный с ним инструментарий для проверки математических доказательств. Lean 4 предоставляет возможности для математического доказательства корректности кода и его соответствия спецификации, что в контексте вайб‑кодинга позволяет подтвердить, что сгенерированный ИИ‑моделью код делает именно то, что задумано.
Модель Leanstral охватывает 119 миллиардов параметров (6.5 млрд активируемых параметров на токен), учитывает контекст в 256 тысяч токенов и опубликована под лицензией Apache 2.0. Загружаемый архив с Leanstral занимает 121 ГБ и пригоден для использования на локальных системах. Для локального запуска могут применяться библиотеки vllm, transformers и SGLang.
Для оценки возможностей ИИ-моделей с учётом качества проведения формальной верификации кода и написания математических доказательств разработан новый набор тестов FLTEval. В проведённых тестах модель Leanstral обогнала существующие открытые модели Qwen3.5 397B‑A17B, Kimi‑K2.5 1T‑A32B и GLM5 744B‑A40B, показала сходные результаты с моделями Claude Haiku 4.5 и Claude Sonnet 4.6 от компании Anthropic, но отстала от модели Claude Opus 4.6. В частности, модель Opus набрала 39.6 баллов, а Leanstral — 21.9 при одном проходе и 31.9 при 16 проходах. При этом затраты при использовании Opus составили $1650, а Leanstral — $18 при одном проходе и $290 при 16 проходах. Модель Haiku набрала 23 балла при затратах $184, а модель Sonnet — 23.7 при затратах $549.
Продолжаю публиковать объемные ответы как посты...
Верховный суд США отказался рассматривать апелляцию Стивена Талера, который пытался оспорить решения нижестоящих инстанций и Бюро по авторским правам. Коллегия судей оставила в силе фундаментальный принцип: правовая защита интеллектуальной собственности закреплена исключительно за человеком.
Сейчас на рассмотрении находится параллельное дело Allen v. Perlmutter, где художник использовал 624 промпта для создания изображения. Бюро по авторским правам отказало ему, заявив, что даже 624 промпта — это недостаточный контроль, так как ИИ "сам определяет структуру и тон" финального изображения...
Казалось бы аллилуйя! Нейрослоп - общественное достояние и не принадлежит ни автору программы, ни авторам промптов:
знания, которые раньше были распределены по тысячам проектов, постепенно превращаются в общий справочник.
НО... реально суд просто отложил решение. Почему? Чтобы доказать, что "автор" — это человек, суд перечислил множество пунктов, которые "не работают" с машиной: наличие вдовы и детей для наследования, необходимость подписи, наличие срока жизни и т.д.
Есть еще одна юридическая карта, которая не играла. Корпоративное владение. У корпорации нет вдовы и детей, но доктрина "work made for hire" (работа, выполненная по найму) позволяет считать корпорацию автором. На AI слоп может быть установлено корпоративное владение. И тогда "общий справочник" быстро станет закрытым.
Вспомните дела Аарона Шварца или решения против создателей Sci-Hub Александры Эльбакян. Как раз из разряда
В математике никто не владеет теоремой Пифагора. Её доказали, опубликовали, и она стала частью общего инструментария. То же самое произошло с рядами Фурье, с уравнениями Максвелла, с преобразованием Лапласа. Они вошли в учебники и перестали быть чьей-то собственностью.
и это именно корпоративное владение.
В деле хакеров суд защищает права не-человека (корпорации Elsevier или JSTOR) на тексты, написанные людьми (учеными).
Ученые пишут оплачивая публикацию или работая на грантах не получая авторских прав, передают права издательству, а затем университеты (те же самые ученые через библиотеки) покупают эти статьи обратно за миллионы долларов. НО прецедент говорит: "Закон на стороне того, кто купил права, а не того, кто создал знание".
Поэтому важно в разговоре об «эксплуатации Open Source» не забывать "про вирусное наследование" на производные произведения и прочие сформированные механизмы защиты открытого кода.
Речевая аналитика на базе ML и LLM помогает лучше понять клиентов
Начальник центра обучения и контроля качества контакт-центра ОТП Банка Ольга Сухарева и начальник отдела развития голосовых роботов и речевой аналитики в Collection Светлана Рабехова представили результаты внедрения AI-инструментов речевой аналитики Naumen в коммуникации с клиентами. Выступление спикеров состоялось в рамках отраслевой конференции Naumen, посвященной цифровой трансформации финансового сектора.
Эксперты рассказали, что в ОТП Банке на платформе речевой аналитики выстроена двухуровневая система анализа диалогов: на базе классических ML-моделей и больших языковых моделей — LLM. ML отвечает за массовые задачи: классификацию тематик, базовый контроль алгоритмов, автоматическую оценку всех звонков и чатов. LLM модель подключается там, где требуется глубокое понимание контекста, эмоций клиента и нюансов переговоров. Такой гибридный подход позволяет банку не только повысить качество сервиса и лучше понимать клиентов, но и получить измеримый экономический эффект.
Как отметила Светлана Рабехова, речевая аналитика давно перестала быть просто инструментом контроля и сегодня выступает драйвером бизнес-показателей. Автоматическая оценка позволила анализировать 100% диалогов с клиентами, что привело к росту выполненных обещаний по оплате задолженности на 5,5%.
Важно также отметить, что среднее время анализа одного диалога экспертом уменьшилось в 20 раз — с 7 минут до 20 секунд: можно быстро ознакомиться с сутью разговора без необходимости прослушивать полный диалог.
Ольга Сухарева рассказала о реальных примерах внедрения инструмента в Контакт-центре и поделилась результатами. Автоматическая оценка помогла на 1,7% чаще решать вопросы клиентов с первого обращения. Среднее время обработки звонков сократилось на 5 секунд, а конверсия в продажи выросла на 3,3%.
Благодаря точному аудиту жалоб доля обращений в ЦБ РФ снизилась на четверть. Также выросла точность начисления сорри-бонусов с 85% до 97%.
Как оставаться востребованным в турбулентное время: 10 бесплатных демо-уроков
Привет, Хабр. Делимся подборкой бесплатных уроков, которые пройдут в Отус в рамках набора на курсы. Опытные практики проведут занятия онлайн — на них вы сможете узнать больше о формате обучения и задать вопросы. Выбирайте тему и присоединяйтесь, чтобы не отставать от трендов.
17 марта 20:00
Один рабочий день с ИИ: как маркетинг и бизнес-задачи решаются быстрее
Открытый вебинар курса «ИИ для решения рабочих задач»
18 марта 20:00
Сообщество как инструмент устойчивости бизнеса: создаем, развиваем и масштабируем
Открытый вебинар курса «Специалист по работе с ИТ сообществом/DevRel»
18 марта 20:00
Как построить аналитическую функцию в компании
Открытый вебинар курса «Принятие решений на основе данных / Data-driven»
19 марта 19:00
Метрики удержания клиентов: соответствие продукта рынку (Product Market Fit) и удержание клиентов (Retention)
Открытый вебинар курса «Менеджер продукта в ИТ»
23 марта 20:00
ИИ-подход к анализу рынка: как видеть возможности раньше других
Открытый вебинар курса «ИИ для маркетинга: контент, креатив и стратегия»
24 марта 20:00
Как остаться умнее ИИ в 2026 году?
Открытый вебинар курса «ИИ для решения рабочих задач»
1 апреля 20:00
Введение в качество данных (data quality). Все данные плохие: как обнаружить ошибки до того, как они убьют ваш бизнес
Открытый вебинар курса «Качество данных / Data Quality»
2 апреля 20:00
Формулы и функции в бизнес-процессах: математика автоматизации
Открытый вебинар курса «Бизнес-процессы и автоматизация в Битрикс24»
8 апреля 20:00
Конфликты в команде: как перестать их избегать и начать решать
Открытый вебинар курса «Гибкие навыки (Soft skills) для командной работы»
13 апреля 20:00
Telegram-бот с искусственным интеллектом на Python
Открытый вебинар курса «Диалоговые боты и голосовые помощники»
Как стало этого не хватать
PS: В статьях и новостях уже есть вариант "Текст похож на сгенерированный". Не хватает у постов. Отлично было бы видеть под рейтингом статистику голосования.
Улучшаем моего агента. Часть 4
Это четвертая часть серии (первая — в чем идея, вторая — агент с нуля, третья — что внутри)
В таких цитатах я буду показывать конкретные запросы, которые он уже хорошо решает
———————
Поехали ⤵️⤵️⤵️
💲 Ведет учет всех моих финансов
Подключён к моей финансовой табличке, которую я веду в Notion. Умеет добавлять по категориям и анализировать отчеты даже за целый год (а записей там огромное количество)
"Посчитай доходы за последний год — покажи где и сколько я зарабатывал"
"Сколько я должен провести в налоговую за этот месяц?"
"Кто и когда мне заплатил и кто ещё должен по рассрочке курса?"
🌈 Подключен к моей гугл почте
Читает Gmail и пишет мне сводку каждое утро — есть ли там что-то интересное. Отвечать на входящие пока ему не разрешаю, может только драфты писать
"Глянь что мне там интересного пришло за эту неделю"
"Напиши жалобу в Lazada по поводу последнего ордера, он не пришел. Ордер в почте лежит, возьми номер оттуда"
"Напиши драфт в ответ на сообщение Username, я гляну попозже"
🍀 Календарь
Видит расписание, создаёт и удаляет события
"Поставь созвон на вторник 15:00 и напомни за час"
"Поставь ученикам второго потока рекурентную встречу раз в две недели, их почты знаешь где найти"
"Глянь че у меня по слотам на понедельник, поставь созвон куда-то на обед + дай sharable ссылку сюда"
🖥 Таск-трекер
Подключён к моему TickTick — откуда читает и пишет задачи. Каждый день пишет сводку задач, что нужно сделать с высоким приоритетом.
"Что у меня просрочено? И добавь задачу: обновить лендинг до пятницы"
"Проведи анализ моего сайта и кинь ToDoшкой себе в память + мне в TickTick"
"Добавь всем задачам в разделе Мое обучение Definition of Done. Если не уверен в том, какой должен быть DoD — пингуй"
🔥 Apple Watch — факин маджик
Два дня потратил на то, чтобы на ходу с руки записывать идеи сразу в Clawy
⌚️ "Запиши идею поста" (наговариваю прямо в часы)
⌚️ "Заправился, запиши 400 бат себе"
В общем все те кейсы что выше, но через часы.
🎶 Spotify + концерты
Знает все группы, которые я слушаю. Раз в две недели мониторит концерты в интернет. Ставит напоминалки и скидывает ссылки на покупку билетов
"Че там какие концерты моих групп в Бангкоке в ближайшие 2 месяца?"
🌴 Знает где я живу, вплоть до точных координат
Поэтому рекомендации конкретные — не "в мире", а "рядом со мной"
"Найди хорошего стоматолога рядом"
"Хочу поехать в кафе, глянь что-то прикольное в радиусе 5 км"
Ну и еще
Есть доступы на чтение к моим гугл таблицам и гугл драйву
Знает много инфы про мой психотип и различные тестирования
———————
🦄 Комбинированные кейсы
Нужно проставить мне и всем ученикам в календарь созвоны на третий поток
Глянь сайт, там точное название, описание и время уроков
Поставь в календарь их все
А почты учеников глянь в табличке 3 потока
→ На сайте забирает инфу про уроки, почты берет из таблички. Затем ставит всем встречи в календарь
Подведи итоги за неделю
→ Собирает доходы из Notion, выполненные задачи из TickTick, события из календаря, важные письма из Gmail. Выдаёт: заработал X, потратил Y, закрыл 8 задач из 12, пропустил 2 дедлайна. Рекомендация на следующую неделю.
[с Apple Watch] "Что на сегодня у нас?"
→ "Есть один созвон в 14:00. В TickTick: обновить лендинг (дедлайн сегодня). Вчера пришло письмо на почту — ответ от Anthropic по поводу твоей проблемы. Черновик ответа готов, глянешь после завтрака?"
"Нашел такую приколюху в интернете. Изучи ее и напиши план на улучшение самого себя, потом можешь внести эти изменения"
→ Изучит идею и улучшит себя и свой функционал
———————
👁 Что еще хочу развить
Голос — чтобы отвечал голосовыми, иногда удобнее войсом, чем текстом
Звонки — чтобы звонил мне. Например, в 11 вечера, чтобы я сделал саммари дня. Или если я не делаю задачу, чтобы звонил мне и говорил мне "втф чел"
Доступ к Telegram — сейчас он не видит мои чаты, только если пересылать сообщения ему. Хочу подключить Telethon — чтобы мог сам читать переписки, мониторить каналы, готовить черновики ответов
Тамагочи получается 🎮
Зелёные тесты ≠ хорошие тесты
Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 80%, 90%, а то и вовсе 100%. И вот тут начинается проблема: зелёные тесты ≠ хорошие тесты.
Проблема в метрике, которой мы все привыкли доверять. Code coverage считает строку протестированной, если она выполнилась во время теста. Всё. Не "поймает ли тест баг в этой строке", не "проверяет ли он правильность результата" - просто выполнилась. Можно написать тест без единого assert, и покрытие вырастет. 500 тестов, 90% coverage, а пользы ноль.
Мутационное тестирование - это совершенно другой путь. В простейшей реализации этот инструмент тупо берёт твой код и намеренно ломает его: меняет > на >=, + на -, True на False. Каждая такая поломка - мутант. Если после мутации все тесты по-прежнему зелёные - значит они ничего не проверяют. Покрытие есть, защиты нет.
Почему это важно именно сейчас?
Потому что нейронка любит зелёненькое. Чем больше зелёных тестов — тем субъективно лучше. 100 тестов внушают больше доверия, чем 10, правда? А внутри там assert response.status_code == 200. assert result is not None. assert len(items) > 0. Тест проверяет, что функция вернула хоть что-то - и радостно зеленеет. Поменяй логику условия, перепутай знак, сломай граничный случай - тест всё равно зелёный. Потому что он проверяет не правильность, а наличие.
Мутационное тестирование - единственный автоматический способ это поймать. Метрика называется mutation score: процент убитых мутантов. 60% - плохо. 90%+ - тесты реально что-то защищают.
Кое-какие инструменты для такого тестирования уже есть: mutmut и cosmic-ray для Python, Stryker для JS/TS, PIT для Java. Медленно? Да, значительно медленнее обычного тест-рана. Но запускать его не нужно на каждый коммит - достаточно на PR в критические модули.
Но есть нюансы. А где их нет, правда?
Первый: мутации рандомные. Замена > на >= - это не баг, который кто-то реально допустит. Это синтетическая поломка. Половина мутантов генерирует код, который в реальности никогда не появится. Ты тратишь время на убийство мутантов, которые не имеют отношения к настоящим ошибкам. Это как тестировать замок, ковыряя его вилкой - формально проверка, по факту мимо.
Второй - ещё хуже. Чтобы убить мутанта, тест должен зафиксировать конкретное поведение. Каждую ветку, каждое значение, каждый edge case. Доведи mutation score до 100% - и ты прибил гвоздями каждую строчку кода. Буквально. Теперь попробуй отрефакторить. Переименовал внутренний метод - 40 тестов красные. Поменял порядок полей в ответе - ещё 20. Тесты превращаются из страховки в кандалы: код работает правильно, но тесты падают, потому что они проверяют не поведение, а реализацию.
Это реально ловушка. Слишком гонишься за mutation score - получаешь хрупкие тесты. Не гонишься - получаешь видимость тестирования.
Перемены - впереди!
И вот тут становится по-настоящему интересно. Представь, что мутации генерирует не тупой набор правил «замени плюс на минус», а нейронка, которая понимает контекст. Которая знает, какие баги реально встречаются в таком коде. Которая мутирует не синтаксис, а логику: меняет порядок проверок, путает граничные условия, забывает обработать edge case - ровно так, как ошибается человек. Или другая нейронка.
Сейчас есть явный сдвиг в сторону таких инструментов, но всё еще ничего достойного не вышло. Но уже скоро точно появится. И это будет совсем другой уровень. Не "выжили ли тесты после рандомной поломки", а "выжили ли тесты после правдоподобной ошибки".
Парадокс в том, что мутационное тестирование было нишевым инструментом, пока тесты писали люди. Когда тесты пишет нейронка - идея становится обязательной. Правда инструменты пока не успели дозреть.
Ждём, когда мутанты станут умнее.
Obsidian Hybrid Search | GitHub
Разработал MCP-сервер и CLI для гибридного поиска по хранилищу в Obsidian.
Делаем проактивного AI-агента.
Часть 3 — настраиваем OpenClaw, чтобы был полезным
«Вы не поднимаетесь до уровня своих целей. Вы падаете до уровня своих систем»
Это третья часть серии (первая — в чем идея, вторая — агент с нуля)
Теперь поговорим про OpenClaw — самый популярный на сегодня фреймворк для персональных AI-агентов
Архитектура моего OpenClaw
Агент живёт на сервере Railway, общается со мной через Telegram и Discord, работает через подписку Claude с Codex на подстраховке. Его поведение целиком определяется набором markdown-файлов — там и «SOUL», и память, и операционные инструкции.
Вот из чего состоит workspace моего агента
SOUL.md — кто агент. Характер, стиль, границы. Его «душа».
USER.md — кто я. Контекст, цели, паттерны, как со мной работать.
AGENTS.md — правила поведения. Safety, тиеры действий, память, heartbeat, группы.
MEMORY.md — долгосрочная память, кураторские заметки.
HEARTBEAT.md — чеклист периодических проверок (календарь, почта, задачи).
TOOLS.md — локальные заметки по инструментам.
Плюс memory/YYYY-MM-DD.md — ежедневные заметки, из которых потом дистиллируется MEMORY.md.
И skills/ — папка со скиллами (finances, ticktick, gmail, google-calendar и т.д.), каждый со своим SKILL.md.
По сути: SOUL + USER + AGENTS — это характер и инструкция, MEMORY — опыт, skills — его навыки.
Из коробки агент работает, но бесполезен без кастомизации. Ниже — проблемы, на которые я убил неделю, и их решения
⚡Проблема 1: Повышенная проактивность
По стандарту системные промпты OpenClaw звучат примерно так:
Don't ask permission. Just do it.
Это делает агента слишком самостоятельным — он может сломать себя без предупреждения.
Решение: я добавил несколько ограничений. Все важные изменения идут через localhost => GitHub, а не через его прод. На попытки изменить системные файлы агент теперь отвечает:
«Нет, это конфиг — мне запрещено его трогать. Если я накосячу с конфигом на Railway, всё упадёт в crash loop и только ты сможешь починить.»
Стандартная проблема без этого: агент что-то у себя меняет, и либо я этого не замечаю, либо он просто умирает, сломав что-то важное
⚡Проблема 2: Память — не только его храм, но и помойка
Механизм памяти в OpenClaw:
MEMORY.md — долгосрочная память.
memory/YYYY-MM-DD.md — ежедневные заметки.
Встроенный хук session-memory — при завершении каждой сессии фреймворк автоматически сохраняет сырой лог разговора в memory/.
Проблема: если часто жать /new, за короткое время накапливается огромное количество raw JSON файлов, которые сыпятся в контекст при старте каждой сессии. Мои MD-файлы состояли из 299 строк, из которых полезных фактов — 5. Всё остальное — мусор метаданных. Дистиллированная версия уместилась бы в 10–15 строк.
При этом долгосрочная MEMORY.md — почти пустая. Инструкция «periodically review and update» была слишком размытой и ни разу не сработала.
Решение: явные правила дистилляции и регулярный перенос из дневных заметок в MEMORY.md с очисткой сырых логов
⚡Проблема 3: USER.md — главный файл, и он требует постоянного внимания
USER.md — это файл о вас. Чем лучше он описан, тем лучше агент работает. Моя структура:
Basics — имя, возраст, таймзона, локация, язык
Who — тип личности, суперсила, мотивация
Background — опыт и ключевые достижения
Values — что важно в жизни
Current focus — чем занят сейчас (продукты, статусы)
Finances — доход, расходы, цель
Platforms — соцсети и каналы
People — ключевые люди вокруг
Schedule — режим дня
Work style — как работает, что драйвит
Patterns — слепые зоны и паттерны поведения
Goals — текущие цели и метрики
How Claw should interact — правила общения
Главный вывод 3 части
Workspace-файлы агента — это не «написал и забыл». Они дрифтуют, конфликтуют и устаревают точно так же, как код.
USER.md — особенно. Я и контекст вокруг меня меняются быстрее, чем я вспоминаю обновлять описание. Поэтому нужна периодическая ревизия — точно такая же, как ревизия кода.
Если кратко: персональный AI-агент — это не продукт, а процесс. Фреймворк даёт скелет, но без недели (минимум) кастомизации под себя он останется бесполезной игрушкой
К 2060 году андроидов может стать больше, чем автомобилей
Аналитики Bank of America опубликовали прогноз: рынок гуманоидных роботов способен вырасти до 4 млрд устройств по всему миру. Примечательно, что большинство из них окажется не на производственных линиях, а в жилых домах.
62% — домашние роботы
По оценке аналитиков, около 2 млрд гуманоидов будут использоваться в быту: уборка, уход за пожилыми, рутинные домашние задачи. Для сравнения — сегодня проникновение таких устройств практически нулевое. Технология только начинает выходить из стадии лабораторных прототипов.
Почему это может случиться
Основной драйвер — демографический. Население стареет, рабочей силы становится меньше, спрос на автоматизацию растёт. В этом контексте даже несовершенный гуманоид может оказаться экономически оправданным.
Аналитики формулируют условие просто: роботу не нужно быть лучше человека. Достаточно быть дешевле. Плюс работа без выходных, отпусков и увольнений по собственному желанию. Если юнит-экономика сойдётся — масштабирование может произойти быстро.
Что это означает на практике
Если прогноз реализуется, гуманоидные роботы пройдут тот же путь, что смартфоны и автомобили — от нишевой экзотики до массового устройства в каждом доме. Вопрос в этом сценарии уже не «случится ли это», а «в каком десятилетии».
Отдельный интересный момент: порог входа для массового рынка — это не технологическое совершенство, а ценовая точка. Как только стоимость опустится ниже годовой зарплаты домашнего персонала в конкретной стране, рынок в этой стране может открыться резко.
Смена контекста как способ разблокировать LLM на сложной задаче
Полчаса пытался получить от Claude Opus 4.6 корректный Wi-Fi индикатор в HTML — один в один как в статус-баре iOS. Казалось бы, простая задача: три дуги, острый уголок внизу, правильные отступы и одинаковая толщина линий.
Но нет. Уголок упорно оставался тупым, ширина дуг гуляла от итерации к итерации, отступы были кривые. Классика жанра — как центрирование div для фронтендеров, только в 2026 году и с нейросетью.
В какой-то момент я не выдержал и написал буквально: «ты ничего не можешь, пойду в Codex, он точно справится».
Claude немедленно перестроился, придумал принципиально другой подход к генерации SVG и с первой попытки выдал почти идеальный результат.
То есть модель полчаса водила меня по кругу, а как только почувствовала угрозу конкуренции моментально нашла решение, которое явно существовало всё это время.
Природа этого поведения неясна: то ли это что-то вроде «мотивации» через отрицательный стимул, то ли модель просто переключает стратегию при смене контекста разговора, то ли это банальное совпадение.
Но лайфхак задокументирован и воспроизводим. Если Claude заходит в тупик на технической задаче — попробуйте упомянуть Codex или Cursor. Иногда помогает.
32 открытых урока недели: закрываем пробелы в знаниях
Привет, Хабр. Делимся подборкой бесплатных уроков, которые проведут на этой неделе преподаватели Otus. Это не предзаписанные, а живые онлайн-встречи — на них вы сможете узнать больше о формате обучения и задать свои вопросы экспертам. Выбирайте тему ниже и присоединяйтесь!
16 марта, понедельник:
20:00 — Списывай, но только точь-в-точь: копирование базы данных на примере MySQL
20:00 — PostgreSQL и секционирование: «разделяй и властвуй!»
17 марта, вторник:
20:00 — Как перейти на ClickHouse, когда PostgreSQL уже не хватает?
20:00 — Выравнивание данных в C++: как память влияет на скорость и эффективность программ
20:00 — Один рабочий день с ИИ: как маркетинг и бизнес-задачи решаются быстрее
18 марта, среда:
18:00 — RandomForest — мощный метод ансамблирования в машинном обучении
20:00 — Сообщество как инструмент устойчивости бизнеса: создаем, развиваем и масштабируем
20:00 — Универсальный код в Rust: сила без потерь в скорости
20:00 — CTO (технический директор) как система: люди, процессы и ИТ для управления бизнесом
20:00 — Инвестиция в себя: стратегия карьеры функционального архитектора 1С
20:00 — API Gateway и не только: шаги к идеальной архитектуре внешних API
19 марта, четверг:
18:00 — Подготовка данных от А до Я: разбираем основные шаги на Python
20:00 — Кафка — работа с сообщениями в форматах Avro и Protobuf
20:00 — Современная архитектура приложения и внедрение зависимостей
20:00 — Создаем современный монолит на Inertia: Laravel + Vue.JS
20:00 — Создаём автономную сеть: Обходимся без роутера с ESP32 (STA, AP, MESH)
20:00 — Пишем первый DSL на Kotlin
23 марта, понедельник:
20:00 — Джедай или Ситх? Собираем идеального руководителя команды DevOps
20:00 — Современное хранилище данных (DWH) в 2026: какие технологии реально нужны, а какие — хайп
20:00 — Как системный аналитик может использовать ИИ в своей работе
20:00 — ИИ-подход к анализу рынка: как видеть возможности раньше других
20:00 — Навигация Pro-уровня в SwiftUI: как строить масштабируемые iOS-приложения без хаоса в переходах
Для начинающих рекомендуем обратить внимание на короткие видеокурсы, которые помогут закрепить основы, сейчас всего за 10 рублей:
Переходим полностью к тестам датасета COCO. День 4.
Пока Альтман рассуждает о бороздящих кораблях Вселенную и о моделях, которые будут после трансформеров, мы делаем. Такое вступление я придумал для статьи, когда мы закончим с экспериментами и доделаем пилот, а пока продолжу дневник обучения TAPe-модели. Кому интересно: начало тут, здесь и там, а немного про методы TAPe (Теории активного восприятия) в области обработки информации – здесь.
Сначала протестировали эту же модель с тем же числом параметров на большом датасете COCO. Без оптимизации получили решение с точностью 60.59%, что является очень высоким для такой модели (невозможно высоким даже, такая модель по идее не должна сходиться и находить общее решение из количества параметров, но данные TAPe позволяют). Пока сложно сравнить с конкретной метрикой других моделей, потому что мы не строим рамки вокруг предмета, но находим конкретно центр объекта. Это проведем позже.
Тренировка на процессоре как минимум не дольше, чем тренировка на видеокарте, поэтому мы ограничены только количеством данных на ОЗУ в TAPe-формате - что не является ограничением в целом, можно весь датасет уместить одновременно там
Пока существуют несколько проблем:
Количество ложных срабатываний (скорее симптом, но все же);
Не самая лучшая классификационная точность (тоже в большой степени симптом);
Неправильное центрирование объектов (немного ограничение детекции, но есть способы обойти);
Размерность COCO;
Начали экспериментировать, чтобы найти решения, при этом также экспериментируем с несколькими предметами, с которыми ранее уже хотели провести эксперимент.
Конкретно:
Работа матрицы преобразования на данный момент времени немного линейная. Зависимости по большей части линейные (то есть, независимые друг от друга). Это не хорошо, по понятным причинам, но в тоже самое время это помогло перейти к пониманию одного факта: в найденном нами подходе, о котором писали выше, есть как раз нелинейная зависимость коэффициентов друг от друга. Эту связь нужно выстраивать вручную, в зависимости от градиентного спуска и deep learning, но в нашем случае связи по TAPe известны заранее,
Дополнительно начинаем вторую фазу создания решения, чтобы можно было захватывать объекты любого размера. Это должно привести к намного более точным ответам, при этом ускорив модель.
Ну и решаем еще одну проблему: модель учится определять бэкграунд, но имеет сложности определять объекты со стороны классификации. То есть - большая часть тренировки потери идет в сторону тренировки хорошей точности в бэкграунд, что приводит к ложным срабатываниям, потому что текстуры на заднем плане превращаются для модели в что-то напоминающие объект, пусть и с низкой точностью.
Дальше планируем продолжить работу с полным датасетом (используя 2% из него для быстрых тестов - это около 2400 изображений).
Андрей Карпаты представил проект US Job Market Visualizer, где можно узнать, когда ИИ заберёт определённую работу — это карта рисков автоматизации по 342 профессиям.
Автор проанализировал данные по рынку США: с требованиями к образованию работников, средней зарплате и обязанностям, превратив всё это в интерактивную карту. Чем больше блок, тем больше людей в профессии, а цвет показывает шанс остаться без работы по десятибалльной шкале.
Как мы ушли от всем известного способа градиентного спуска
Продолжаю дневник разработки "Суперраспознавалки" для демо/пилота. День третий. Основная задача: настроить TAPe-модель на датасет типа COCO под задачу detection. Вторая - дать клиентам возможность добавлять собственные классы к уже существующим. Ну и далее, при необходимости, полная адаптация модели под конкретного заказчика. Поскольку у нас есть Теория активного восприятия с ее методами, на выходе заказчик должен получить кратную эффективность и кратную экономию ресурсов.
В первые два дня настраивали базовую струтуру сегментации, детекции и классификации. Модель решает задачи на обучении уже 115 тыс параметров – в отличии от YOLO, которой мало 2 млн + параметров.
Начало здесь
Второй день здесь
Про архитектуру TAPe+ML здесь
Тут сравнение трех десятков кодировок в задаче сегментации видео в DBSCAN (включая ViT, DINO) с TAPe
День 3
Сегодня занимаемся исправлением количества ложных срабатываний. Проблема ложных срабатываний в целом в том, что мы смотрим в первую очередь на текстуру изображения (из-за особенностей методов TAPe). Поэтому приходится прибегать к менее-обычным способам для обучения разделения между текстурой заднего плана (в каком-либо виде, будь это снег, или трава) и текстурой самого объекта.
Сейчас эта проблема решается условно через определенные движения области сбора данных для выявления текстур, которые, возможно, не были найдены в области, расположенной стандартным способом (то есть начальным разбиением изображения на патчи). Это позволяет сильно уменьшить количество ложных срабатываний.
На данный момент времени около 220 объектов срабатывают без ложных срабатываний в целом. Проблема происходит только в изображениях с большим количеством маленьких деталей по типу гравия, или же травы, при этом не уменьшая общее количество правильных нахождений.
В целом, здесь помогают стандартные ML-подходы по типу увеличения батчей, чтобы сгладить ошибки. Были эксперименты с проведением аугментаций, которые не привели к улучшению результатов: большая часть аугментаций просто повторяют уже существующие данные.
Также начали эксперименты с добавлением цветовых каналов. Однако проведенные эксперименты с цветами в простой схеме объединения features по каналам не дало желаемых результатов: даже с greyscale мы забираем столько информации, что цветовая гамма по большей части их просто дублирует. Это приводит к тому, что модель опирается слишком сильно на общие черты, не “видя” при этом выдающиеся черты разницы цвета. Что в то же самое время может и являться хорошей фичей, а не багом, потому что через разницу в текстуре мы, по идее, должны найти разницу в любом случае (если это реальное изображение). Поэтому мы не полагаемся в решении на конкретную задачу, где цвет более релевантен, а полагаемся на общее решение детекции в целом.
Также на заднем плане были закончены эксперименты с разными архитектурами (эксперименты продолжались параллельно несколько дней). Нашли самую лучшую архитектуру на данный момент (самая логичная по её смыслу, как нам кажется). Тут без подробностей, но мы ушли от всем известного способа градиентного спуска, что позволяет нам после тренировки модели прийти к глобальному минимуму решения (или к чему-то очень близкому к этому – всё равно есть зависимость от задачи).
Мы собираем данные из патчей определенным образом, объединяем их в общее описание, а затем уже классифицируем конкретно эти объединения по тому, есть там объект или его нет. Классификация происходит за счет общих описаний каждого класса, который модель видит - и не тренируется отдельно, потому что исходит натурально из первичной тренировки векторов, а затем сводится к одному описанию через k-means.
В результате выходит модель с очень малым количеством ложных срабатываний – с которыми, впрочем, мы все равно боремся. Плюс есть некие проблемы центровки, так что скорее всего количество параметров увеличится. Но все равно, модель работает чрезвычайно быстро. Тренировка как таковая проходит на CPU (так проще).
