Обновить

AI и ML

Сначала показывать
Порог рейтинга

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

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

Теги:
+11
Комментарии0

Anthropic выпустила бета‑версию плагина Claude Security для Claude Code. Инструмент запускает многоагентную проверку репозитория, составляет отчёт об уязвимостях и предлагает исправления в виде патчей. Инструмент поддерживает четыре уровня глубины проверки. Чем выше выбранный уровень, тем больше агентов участвует в анализе и тем шире охват репозитория. При этом сканирование расходует токены в рамках тарифа пользователя.

Плагин работает внутри обычной сессии Claude Code и запускается командой /claude‑security. Пользователю доступны три основных сценария: проверка всего репозитория или отдельной его части; анализ изменений в ветке, pull request или коммите; создание патчей для выбранных уязвимостей.

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

Для установки необходимо подключить плагин из официального каталога Anthropic. Для работы требуется платная подписка, Claude Code версии не ниже 2.1.154, Python 3.9.6 или новее и Git. Поддерживаются Linux, macOS и Windows.

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

Теги:
+3
Комментарии0

Еще не поздно стать спикером на GoCloud Tech 2026 🎤

Хардкорная конференция для тех, кто создает технологии в эпоху ИИ, GoCloud Tech состоится 15 октября! Мы собираем доклады от коллег из индустрии и готовы предоставить трибуну каждому, кто хочет повлиять на развитие инженерных практик и готов делиться своим реальным опытом. Не важно, в какой компании вы работаете, если вам есть, что рассказать: 

  • о технологиях, на которых держатся современные облачные платформы, и лучших практиках работы с ними;

  • о том, как строить сложные системы и делать разработку в облаке эффективнее и безопаснее;

  • о том, как подготовить данные и инфраструктуру к работе с ИИ.

Ждем ваши заявки на выступление до 11 августа!

Вместе обсудим, как ИИ меняет инфраструктуру, разработку и работу с данными.

Узнать подробнее о тематиках и таймлайне подготовки, а также подать заявку можно на лендинге

Теги:
+3
Комментарии0

ИИ-актриса впервые снимется в кино. Технологии отправят в утиль ещё одну профессию?

Компания Particle 6 анонсировала фильм Misaligned («Сдвинутая» или «Нестандартная» — как вам больше нравится). Впервые в полнометражном фильме главную роль сыграет актриса Тилли Норвуд, сгенерированная ИИ-моделью. Некоторые актёры протестуют, опасаясь, что нарисованные модели отнимут у них работу. Похоронит ли ИИ ещё одну профессию, как когда-то автоматика убила специальность лифтёра?

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

Правда, и победу ИИ никто не гарантирует. Актёры не первый раз беспокоятся за свою работу — например, двадцать лет назад Джет Ли отказался сниматься в культовой «Матрице», чтобы не отдать свою цифровую копию Голливуду. Прошло четверть века — мы видели образы умерших актёров в фильмах, но они не стали трендом. Цифровой актёр не устроит скандал, не уйдёт в запой, не будет устраивать демарши из-за гонорара. (Хотя после историй о хакерских атаках на ИИ-модели и диких галлюцинациях уже сложно быть уверенным, что модель будет работать хорошо.)

С другой стороны, уже есть ИИ-певицы, ИИ-блогеры и т. п., собирающие миллионы поклонников. С технологической точки зрения ИИ научились генерировать красивое видео, в которое можно добавить реальных людей. Такой уровень вполне позволит сделать полнометражный фильм. Но не гарантирует его успеха. Единицы актёров остаются популярными на протяжении десятков лет. Обычно аудитория находит новых кумиров, возводит их на пьедестал, а потом переключается на новых героев.

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

Теги:
+15
Комментарии1

Вебинар: ИИ в бизнесе — работает или только обещает?

Привет, Хабр! Мы тут уже не раз писали про ИИ: где он помогает бизнесу, где пока не очень, как вообще влияет на IT-индустрию. Тема горячая, бюджеты растут, пилоты запускаются один за другим. Но есть интересный момент: больше 90% компаний пробуют внедрять ИИ, а до полноценного запуска проектов доходят всего 7–10% (исследования легко найти у ICT Moscow и не только).

Мы в OXYGEN уже накопили опыт внедрений GPU-инфраструктуры, работы с нейросетями и языковыми моделями. И хотим поделиться тем, что выяснили на практике, вместе с коллегами из Aston, которые занимаются непосредственно запуском ИИ-проектов.

Поэтому приглашаем на вебинар:

Тема: «ИИ в бизнесе — работает или только обещает?»

Дата: 28 июля, вторник

Время: 11:00 мск

Формат: онлайн

Регистрация по ссылке, бесплатная.

Не будем рассказывать, какой ИИ замечательный и как скоро он изменит вообще все. Вместо этого разберем прикладные вопросы:

  • почему многие ИИ-проекты останавливаются сразу после пилота;

  • как выбрать сценарий внедрения с учетом реальных задач и бюджета;

  • какая инфраструктура нужна для разных типов нагрузок;

  • как подобрать конфигурацию серверов с GPU и не переплатить;

  • какие инструменты могут приносить пользу уже с первых дней;

  • где чаще всего ошибаются команды;

  • как оценить бизнес-эффект;

  • и как честно определить ту точку, в которой стоит задать вопрос: а нужно ли вообще продолжать проект?

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

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

Кто будет рассказывать:

Александр Будкин, IT-директор OXYGEN

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

Руслан Мельников, директор по развитию Aston Development

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

И напоследок о нас (об организаторах):

OXYGEN — дата-центр и интегратор облачных решений, входит в ТОП-5 провайдеров ЦОД в России. С 2011 года обеспечивает бизнесу отказоустойчивую инфраструктуру с гарантией 100% uptime. Специализируется на гибридных и приватных облаках, при этом в портфеле у нас более 40 облачных сервисов.

Aston — разработчик корпоративного программного обеспечения для крупных заказчиков. Aston помогает бизнесу расти через качественную разработку, поддержку и облачные технологии.

В общем, приходите — будет интересно: Регистрация на вебинар

Теги:
+4
Комментарии0

Как мы закрываем задачу: тесты, диптрак, аудит и ещё пара рубежей

Продолжение серии про работу с ИИ-агентом. В прошлый раз разбирали, где живёт задача. Теперь — что с ней происходит, прежде чем она станет done.

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

1. Автоформат — молча и сразу. После каждого Edit/Write срабатывает хук: Pint для PHP, Prettier для JS/TS правят изменённый файл. Не блокирует, ничего не спрашивает. Форматирование просто снято с повестки — про пробелы и переносы мы не спорим никогда.

2. Приёмка «прогнал — работает» (скилл verify-task). Финал задачи — не «по идее работает», а таблица. Перечитываем Definition of Done, по каждому пункту: как проверено → PASS/FAIL. Внутри:

  • прогон тестов затронутой области (Pest/PHPUnit) — зелёные, а не «вроде есть»;

  • smoke живого сценария через tinker или artisan-команду;

  • корнер-кейсы: пусто, граница, null, таймаут внешнего сервиса;

  • в diff нет ключей и .env.

Любой FAIL — задача не закрыта. Без «ну это мелочь, потом починим».

3. Deptrac — границы слоёв (Stop-хук). На попытке закрыть ход прогоняется анализатор архитектуры. Уехала логика из сервиса в контроллер, модель полезла напрямую во внешний API — exit 2, ход не закрывается, пока не переложишь код в правильный слой. Тот же гейт стоит в CI, а легаси-долг зафиксирован baseline’ом, чтобы старые грехи не блокировали новую работу. Правило в конфиге кажется неверным? Правь конфиг явно и объясняй — обходить молча нельзя.

4. Секреты не текут (guard-secrets). Отдельный хук стережёт, чтобы содержимое .env, ключей и дампов не улетело в чат: cat/grep по секретному файлу блокируются, Read на него — тоже. Править такие файлы можно (Edit/scp), а вываливать в переписку — нет.

5. Рефлексия — иначе не закрыть (guard-discipline). Код менялся, а записи в task/history за сегодня нет? Снова exit 2. Хук требует короткий разбор: что ставили, как решал, решено да/нет/частично, что можно было лучше. Следующая сессия начнёт с этих заметок и не наступит на те же грабли.

6. Независимый аудит — по коду, а не по рассказу. После нетривиальной доработки запускается отдельный агент, который не видел, как ты решал. Ему дают diff и чек-лист: все ли call-сайты покрыты, нет ли регрессий, есть ли тесты, скрытые баги, не уехали ли слои, не утекли ли секреты. Вердикт — APPROVE или CHANGES NEEDED со списком «файл:строка — почему». Нашёл проблему — не чинит молча, возвращает автору. Без аудита мёрдж не предлагаем.

7. И только теперь — в done и на мёрдж. Задача переезжает в task/done до открытия MR, в той же ветке. Прямой push в main закрыт хуком — только через merge request. А прод-pull делает человек: guard-prod fail-closed не пускает агента мутировать боевой сервер, агент лишь готовит команды.

Тут важно, кто есть кто. Автоформат, Deptrac, защита секретов, рефлексия, запрет пуша в main и защита прода — это хуки. Они срабатывают автоматически на события (после правки файла, при попытке закрыть ход, перед bash-командой) и возвращают exit 2, если что-то не так. Их нельзя «забыть» или уговорить — они не читают промпт, они перехватывают действие. А приёмка и аудит — это скиллы, процедуры, которые агент запускает сам: тут уже нужна голова, а не только стенка. Стенки ловят механику, скиллы — смысл.

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

«Готово» — не когда агент дописал код, а когда код прошёл все рубежи.

Теги:
+3
Комментарии0

Математик Дмитрий Рыбин вместе с GPT-5.6 опроверг известную гипотезу, которую открыли ещё 30 лет назад — он попросил ИИ «совершить прорыв».

Серьёзно, никаких хитрых промптов для научного исследования не понадобилось: математик просто просил ChatGPT продолжить опровержение. После этого ИИ 80 минут выстраивал цепочку аргументов. Автор поделился чатом с моделькой и называет ситуацию «чистым мемом».

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

Теги:
+7
Комментарии1

Пройди воркшоп по наблюдаемости ИИ-агентов с Langfuse

Воркшоп по наблюдаемости ИИ-агентов с Langfuse
Воркшоп по наблюдаемости ИИ-агентов с Langfuse

Привет! Меня зовут Филипп Бочаров, я CPO в МТС Web Services и член ПК HighLoad++. Мы с командой придумали воркшоп «Смотри, как думает агент: Observability AI-агентов с Langfuse». Его прошли уже более 60 человек на конференциях AIConf 2026 и Saint HighLoad++ 2026, а теперь он стал доступным публично всем желающим!

На примере демонстрационного ИИ-агента на Python вы узнаете:

  • сколько могут стоить ошибки агента в рублях;

  • как сломать продуктивный агент, не меняя ни строчки кода;

  • что может пойти не так с MCP.

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

Что будет на воркшопе

Мы будем работать с демонстрационным ИИ-агентом Cookbook Agent. Он умеет создавать рецепты блюд и рассчитывать стоимость ингредиентов.

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

Демонстрационный ИИ-агент состоит из пяти частей:

  • Cookbook-agent — агент на Python. Это основной проект, который мы будем изучать и изменять.

  • MCP-server — MCP-сервер, к которому агент обращается за поиском рецептов и их стоимостью. Развернут локально, но вы считаете, что он находится где-то в облаке. MCP-сервер для вас — черный ящик.

  • Qdrant — векторная база данных с рецептами.

  • RAG-loader — утилита для загрузки рецептов в Qdrant при первом запуске.

  • Redis — хранилище памяти для сессии агента. Изначально наш агент память не использует, но она будет добавлена на последнем шаге.

Зачем это нужно…

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

На этом воркшопе мы покажем, как можно диагностировать такие типовые проблемы. Цель — освоить инструмент для диагностики типовых проблем AI-агента.

Что такое Langfuse

Это open-source-платформа для разработки и наблюдения приложений на базе LLM. Ее ключевые функции:

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

  • Возможность хранить промпты централизованно с контролем версий.

  • Метрики качества: проверка ответа агента на корректность, безопасность и так далее.

Требования к участникам

  • ноутбук с доступом в интернет;

  • git, Docker v24.x+ и Docker Compose v2.22.x+;

  • любой редактор кода, желательно с поддержкой Python;

  • 500 рублей для оплаты LLM в сервисе MWS GPT Model Hub

  • два часа свободного времени.

Как пройти воркшоп

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

  • Сценарий — задание, в рамках которого имитируется проблема нужно сделать. 

  • Решение — это ответ на задание с подробным разбором причин и способа исправления.

Старайтесь разобраться в задании самостоятельно, не забегайте вперед и не подсматривайте в решение.

Теги:
+3
Комментарии0

Открытый проект PriceGhost позволяет искать самые дешёвые и качественные товары в сети Интернет с помощью ИИ:

  • внутри команда ИИ‑агентов, которая проверяет сотни площадок с нужным вам товаром;

  • агенты сравнивают цены, сроки доставки, качество, характеристики, скрытые доплаты и комиссии, наличие страховки груза и прочее;

  • выдаётся подробный отчёт с инфографикой. ИИ также выдаст рекомендации, если товара не будет в наличии;

  • результат — можно купить вещь выгоднее и не ждать долго доставку, а ещё не навяжут скрытые условия.

Теги:
+6
Комментарии0

Мировое Anthropic с авторами на $1,5 млрд: не тот прецедент, каким его подают

На днях суд в Сан-Франциско окончательно утвердил мировое Anthropic с авторами на $1,5 млрд. Это крупнейшее известное урегулирование по авторскому праву в США. Дело вёл судья Alsup, но к финалу он вышел в отставку (конец 2025), утвердила мировое судья Araceli Martinez-Olguín.

Новость разошлась под заголовком «суд признал обучение ИИ на книгах добросовестным использованием». Это не совсем верно.

Что решил суд, исходя из информации из открытых источников: судья Alsup ещё в июне 2025 указал: само обучение модели на книгах - это fair use (добросовестное использование по праву США), потому что использование трансформирующее. Нарушение увидели в другом - Anthropic скачали больше 7 млн книг из пиратских библиотек (LibGen, PiLiMi) и держали на их базе «центральную библиотеку», часть которой в обучение, возможно, и не пошла бы. Мировое и $1,5 млрд - именно за это хранение, не за обучение.

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

Что из этого практического. Источник данных теперь из чисто технического вопроса дополняется его классификацией, как юридического факта - важным становится «откуда взяли», а не на чём обучали. Лицензированный и открытый контент для обучения; правомерные источники для RAG (генерация с опорой на найденные документы - СПС, свой архив, купленные базы); лог того, на чём модель реально училась.

Про РФ. Прямого переноса вывода про fair use у нас нет: в российском праве отсутствует институт добросовестного использования в том формате, как он существует в праве США, но есть закрытый перечень случаев свободного использования (ст. 1274 ГК и рядом). Так что «обучение = fair use» к нашей юрисдикции не прикладывается. А вот риск пиратского происхождения данных прикладывается один в один - суды в разных странах смотрят на одно и то же: откуда контент и не бьёт ли он по правообладателю.

ИМХО, главный итог состоявшегося события не в том, что теперь «ИИ можно учить на книгах», а в том, откуда взяли данные и легально ли их происхождение. Anthropic, к слову, вину так и не признали и всё равно заплатили $1,5 млрд за то, как собирались данные для обучения.

Теги:
+2
Комментарии0

Что-то не сиделось мне на месте, и я решил облегчить работу своему нейро-бро (агенту) на Windsurf/Cascade.

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

Алгоритм прост как 2 пальца об асфальт:

  1. Выбираем директорию

  2. Разбиваем код на удобные батчи (функции, классы, структуры и т. д.)

  3. Индексируем при помощи какой-нибудь embedding-модели через ollama (кстати работает достаточно быстро) или через платное API

  4. Вуаля! -> агент теперь умеет искать информацию по всем локальным проектам

А также вкратце про другую MCP. Она работает примерно как Playwright, но без Node.js-зависимостей и расширений.

Рецепт опять же очень прост:

  • Chrome + запущенный CDP

  • Сам MCP, который умеет навигацию, клики, заполнение форм, скриншоты, инспекцию сети и консоли, исполнение JS-скриптов

Мозг: https://github.com/quonaro/GnostisMCP

Руки для браузера: https://github.com/quonaro/KlyxarMCP

Теги:
+3
Комментарии0

Представлена мини‑камера и персональный тренер BodyPark ATOM, которая следит за техникой упражнений и исправляет ошибки прямо во время тренировки. Камера анализирует технику исполнения пользователя с помощью ИИ и 34-точечной модели скелета. Гаджет сам считает повторения, подсказывает голосом, если пользователь делает упражнение неправильно, и следит за траекторией грифа, амплитудой, центром тяжести и мощностью движений.

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

Теги:
+4
Комментарии1

RAG умер?

Сравнил RAG vs ReAct-агент на существующей компании на корпусе в 100+ документов.

Оценка: 0 — нет ответа, 1 — верный ответ, 2 — верный и более развёрнутый.

Итог: 83 vs 53 в пользу ReAct (OpenClaw).

Главные плюсы ReAct:

👉 добирает детали и шаги «что делать»;
👉 ходит на сайты (расписания, билеты, формы);
👉 даёт контакты, ссылки, уточняет контекст;
👉 лучше форматирует ответ.

Единственный минус — медленнее: лишние циклы ReAct. Но именно в этих циклах он обычно и добирает доп. инфу.

Больше деталей по теме в канале.

Теги:
-1
Комментарии0

Ближайшие события

HAL 9000, ты ли это?

В «Космической одиссее 2001 года» Артура Кларка компьютер HAL 9000 практически обладал разумом и вёл себя как равный участник полёта с космонавтами. В книге компьютер плохо кончил, но именно он — первая ассоциация с «агентским смартфоном» StepX Neo компании StepFun.

Смартфон содержит ИИ-агент Step Amoo, который выполняет все запросы локально. Собственно, локальное выполнение запросов — главная фишка смартфона: получается, что он не зависит от связи, не перестаёт работать, если внешние LLM не на связи (как в случае с блокировкой Fable 5).

Разработчик реализовал собственную операционную систему Step AOS на базе Android, Linux и RTOS. Она спроектирована так, чтобы все операции на смартфоне делились на четыре категории: коммуникации, приложения, файлы и системные инструменты. Каждый запрос пользователя на естественном языке раскладывается на подзадачи и транслируется в запросы ИИ-агенту с учётом необходимого уровня вычислительных мощностей и затрат энергии. Отдельное внимание разработчики уделили безопасности и подключённым внешним сервисам для расширения возможностей системы (на простые запросы агент ответит сам, но подобрать актуальные билеты он может только при подключении к внешним сервисам — что логично).

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

Идея объединить все данные пользователя и скормить их ИИ-модели, чтобы она лучше понимала и помогала ему, не нова. Ещё десяток лет назад Microsoft показывала концепцию Skype, который извлекает из диалога договорённость о встрече и добавляет дату и место в календарь. Неслучайно StepFun организовали… выходцы из Microsoft. Только напомним, что ИТ-гигант так и не реализовал эту функцию и закрыл Skype.

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

Теги:
+20
Комментарии0

Задача — это файл в git, а не сообщение в чате

Предисловие. За год плотной работы с ИИ-агентами — пять проектов доехали до продакшна — у нас сложился набор практик. Разбираем по одной. Первая и базовая: где живёт задача.

Приходит, значит, товарищ к агенту: сделай, милый, вот такую фичу. Агент кивает, бодро пишет код, всё замечательно. Проходит два дня. Товарищ открывает новый чат — а там пусто. Агент не помнит ни фичи, ни уговора, ни что «готово» вообще должно было означать. У него каждое утро чистый лист. И сидит наш товарищ, восстанавливает контекст по диффу, как археолог по черепкам.

Причина простая: задача жила в переписке, а переписка не версионируется и сессию не переживает. Поэтому у нас задача — это файл в git, рядом с кодом. Он коммитится вместе с кодом, который его закрывает, и едет в той же feature-ветке.

Структура папок

Всё, что касается задач, лежит в репозитории и отслеживается git (у нас — 294 файла):

task/                  ← активные задачи (сейчас в работе)
├── done/              ← закрытые
└── history/           ← рефлексия по сессиям (отдельная практика)
plans/                 ← длинные roadmap'ы
  • task/ — только то, что сейчас в работе. Незакрытое и без хвостов. У нас тут обычно 1–3 файла.

  • task/done/ — задача переезжает сюда, как только выполнен Definition of Done. Не после деплоя, а сразу как критерий закрыт. Это архив сделанного: сейчас 121 задача, каждую можно открыть и посмотреть, что и как решали.

  • plans/ — большие направления, которые не влезают в одну задачу. Roadmap режется на пачку мелких task-файлов; агент читает общий план, потом берёт из него конкретный кусок. Сейчас 9 роадмапов.

  • task/history/ — рефлексия по сессиям. Это уже про память агента, отдельная практика; здесь только упоминаю, чтобы структура была полной.

Имя файла — YYYY-MM-DD_HH-MM-название.md, с датой и временем создания. Даёт хронологию из коробки: задачи сортируются по возникновению, имена не конфликтуют, ничего не перетирается.

Что внутри задачи

  • Одна задача = одна функция. Она же — одна feature-ветка и один MR. Есть задача на эту фичу — работаем с ней, вторую не заводим: два файла на одно дело — и потом сам не разберёшь, который из них настоящий.

  • Фазы со статусом. Внутри — шаги, у каждого [ ] или [x]. Сессия оборвалась — следующая открывает файл и видит, где остановились: что сделано, что ждёт, что готово, но не проверено. Состояние читается из файла, а не восстанавливается по памяти.

  • Definition of Done — перечисляемым списком. Не «сделать фичу», а конкретные пункты: что именно должно работать. Без списка «готово» у каждого своё. Этот же список потом становится чек-листом приёмки: пункт → проверка → PASS/FAIL, любой FAIL — задача не закрыта.

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

Скелет реальной задачи из проекта:

# Фаза 7 — калибровка порога confidence
**Тип:** chore + small feat
**Ветка:** chore/retrieval-calibration
**Зависимости:** фаза 6 в проде
**Статус:** Шаг 1 готов; Шаги 2-3 ждут трафика

## Прогресс
- [x] Шаг 1 — инструментовка. Тесты зелёные.
- [ ] Шаг 2 — сбор датасета с прода (ждёт трафика).
- [x] Шаг 3 — эвал-команда готова. Осталось прогнать на реальных данных.

## Контекст
Почему пороги пока с потолка и что от них зависит.

Что это даёт

  • Переживает сессию и машину. Контекст не теряется между чатами: новый агент читает файл и продолжает с той же точки.

  • Едет в ревью вместе с кодом. Ревьюер видит не только дифф, но и зачем он и по каким критериям принимать.

  • Имеет историю. Кто завёл, когда, что и почему решили — в git-логе, а не в чьей-то памяти. Через полгода понятно без археологии.

  • Держит остальные практики. Приёмку не сверить, если непонятно, что считалось «сделано». DoD из файла и есть этот критерий.

Мораль простая. Пока в файле не прописано, что считается «готово», любое «готово» — вопрос веры. Вера в хозяйстве вещь неплохая, но к продакшну отношения не имеет. Список превращает её в проверяемый факт.

Теги:
+6
Комментарии1

Всем привет!

Сегодня поделюсь своим проектом, где использовал возможности открытых моделей LLM для создания автоматизированного конвейера по переводу англоязычных pdf-файлов в русскоязычные pdf. Как человек, интересующийся именно технологиями в области ИИ мне особенно было интересно максимальное приближенное к оригиналу сохранение содержимого переведенного материала, включая схемы, математические формулы, блоки кода (python) и bash-команд, рисунков (само собой), сохранение сносок, ссылок и пр. метаданных. Целью проекта было применение всевозможных доступных стеков и программ, использующих LLM в конкретной практической задаче. И как оказалось, на первый взгляд, простая задача перевода, с которой современная LLM, созданная и обученная на архитектуре трансформеров справляется на сегодняшний день блестяще, для pdf-формата оказалась не совсем простой (но и не скажу, что особо сложной).

О выборе программного стека технологий. Здесь во многом все определило глубина моих познаний и практических умений работать с LLM-моделями и тем оборудованием (потребительским, конечно), которое имеется дома. Поэтому, исходя из пары-тройки (пары) вычислительных узлов (ноутбуков) в домашней локалке мой выбор определил следующие программные и аппаратные компоненты.

Программные компоненты. Прежде всего это среда выполнения wsl. Просто работает в windows, удобна мне как новичку. В wsl установка обычной env стандартным python. И далее уже конкретные ПО для выполнения задачи перевода pdf на русский. Тут пришлось почитать в сети что есть свободное (исходя из цели использования только открытого ПО и LLM, чтобы оценить уровень их развития). Были опробованы такие программы как Docling, Marker-pdf и еще какую-то). В итоге, для извлечения из pdf в markdown формат я использовал Marker-pdf. У него имеется целый набор специализированных ocr-моделей для парсинга содержимого pdf. Marker в режиме конвейера осуществляет извлечение в указанную папку все содержимое исходного pdf в виде отдельных jpg-файлов, файла метаданных и итогового англоязычного .md файла. Для обратного процесса конвертации переведенного на русский язык ru.md я использовал WeasyPrint и Pandoc. Мой выбор - Pandoc. Сложнее, но поддержка xeLatex и куча настроек через опции командной строки и переменных окружения wsl. Pandoc - единственное ПО в моем конвейере, которое не использует LLM. И собственно, середина - перевод. Готовый скрипт на python. Перевод разбитых на части (chanks) в endpoint LLM - requests.post. Фишкой является url, который через специальный балансировщик, управляющий вычислительными узлами в локалке отправляется в requests.post. Получается параллельный перевод на нескольких узлах с  развернутыми OpenAI-совместимыми LLM. Количество узлов - сколько найдется в домашней ИИ лаборатории))). До и после отправки на перевод в LLM - чистка регулярками от различных костылей и защиты от перевода не нужных элементов (чистка колонтитулов, пагинация, сглаживание двойных переносов строк, изоляция спец. блоков от LLM блоков кода, мат. формул, кода внутри строк, приведение кода к pep8), подготовка переведенного _ru.md к сборке pdf-файла в Pandoc. В итоге - pipeline в 3 шага: Marker-pdf, Скрипт-переводчик на python, Pandoc.

Основные шаги перевода (marker, python скрипт, pandoc)
Основные шаги перевода (marker, python скрипт, pandoc)

Все вместе также можно запустить скриптом bash-сценария:

Использование: ./pipeline.sh <path_to_input_pdf> <output_path> [page_range]

Пример1: перевод всего Pdf-файла

./pipeline.sh /mnt/project/raw_data/embeddings.pdf /mnt/project/rendered/embeddings

Пример1: перевод первых 21 страниц Pdf-файла

./pipeline.sh /mnt/project/raw_data/embeddings.pdf /mnt/project/rendered/embeddings 0-20

Репозиторий на github DemonODG/pdf-translator: English-to-Russian PDF Translation Pipeline

Это мой первый пост на тему применения современных LLM моделей в различных практических задачах. Если это вызовет интерес в более подробном описании данного pipeline - напишу статью поподробнее.

Всем добра!

Теги:
+3
Комментарии0

Greenfield по технологии, brownfield по бизнес-правилам

Сегодня в комментариях к чужой статье про greenfield и brownfield в эпоху AI вспомнил свою миграцию 200К строк JS в TypeScript. Тогда я не думал в этих терминах. Теперь вижу: проект был greenfield и brownfield одновременно, и путаница между ними стоила нам двух недель дебага в середине миграции.

Я думал: раз меняем весь стек, это чистый лист

Оказалось: технология была greenfield, стек новый, границы модулей новые, тесты новые. Бизнес-правила остались brownfield на все сто. Восемь лет продакшена, часть логики нигде не задокументирована, живёт только в поведении старого кода. Агент писал типобезопасный, красивый TypeScript и с той же уверенностью ломал правило, о существовании которого никто в команде уже не помнил.

Я думал: раз тесты зелёные, поведение сохранилось

Оказалось: существующее покрытие было тонким именно там, где пряталась история. Странный if с комментарием «не трогать, тут баг у клиента X» тестами не покрывался, потому что баг был найден руками три года назад и с тех пор просто жил в коде. Агент видел if без контекста и оптимизировал его как мёртвый код.

Что сработало: golden-master тесты перед тем, как подпускать агента

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

Главный вывод

В greenfield-части задачи вопрос «правильно ли мы строим» решается быстрой обратной связью и итерацией. В brownfield-части вопрос другой: «сохранили ли мы то, что уже работает». Агент одинаково уверенно предлагает и то, и другое решение, разницу видно только через инструмент вроде golden-master, не через код-ревью на глаз.

Если в проекте есть куски старше пары лет, перед тем как звать агента туда, стоит сначала спросить не «как сделать красиво», а «что именно нельзя сломать, и как я об этом узнаю раньше продакшена».

Пишу об этом подробнее в канале @ai_in_prod.

Теги:
-1
Комментарии0

Представлен открытый список Awesome Hermes Agent - сборник самых полезных скиллов, плагинов и инструментов для Hermes Agent. С его помощью ИИ‑агент учится на ошибках и становится умнее после каждой сессии. Внутри — мультиагентные системы, провайдеры памяти, наборы скиллов и много полезных инструментов. Каждый проект разделён на категории: готовые, экспериментальные и бета‑версии.

Теги:
+5
Комментарии0

Масштабируем ИИ: как эффективно выстроить инфраструктуру в контуре бизнеса

Узнайте, как развернуть ПАК-AI, запустить on-prem агентов и оптимизировать ИТ-бюджет 21 июля на вебинаре К2 НейроТех и Яндекс. 

Спикеры:

▫️ Вячеслав Дегтярев, руководитель по развитию продуктовых решений, К2 НейроТех

▫️ Тарас Юзефович, тимлид по работе с партнерами направления ML&AI, Yandex Cloud

Что в фокусе:

🟢 ИИ-агенты и стратегии 2026: как перевести инициативы из презентаций в работающий продакшн

🟢 Кадровая независимость: способы ускорить запуск проектов, снизив потребность в ML-экспертах

🟢 Борьба с «зоопарком» технологий: как объединить разрозненный стек в единую управляемую систему

🟢 Экономика ПАК–AI: разберем модели поставки и способы оптимизации ИТ-бюджета

🟢 Разберем, как это реализовано на кейсах бьюти-ритейла, а также страховой и финансовой отраслей

21 июля | 11:00–12:30 | Онлайн

Регистрация по ссылке

Теги:
+4
Комментарии0

Что изучить на неделе: 23 бесплатных урока по разработке, ИИ и инфраструктуре

С 20 по 23 июля пройдут открытые уроки по разработке, тестированию, архитектуре, сетям, управлению и работе с ИИ. На них можно разобрать конкретную тему с практикующим экспертом, задать вопросы и закрыть отдельные пробелы в знаниях.

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

ИИ и машинное обучение

  • 20 июля, 20:00. «ИИ для продуктового discovery: как анализировать рынок, конкурентов и пользователей быстрее». Записаться

  • 21 июля, 20:00. «Алгоритм DQN — учим нейросеть принимать решение без помощи человека». Записаться

  • 21 июля, 20:00. «Разработка ИИ‑приложений с Claude Code». Записаться

  • 21 июля, 20:00. «Выбор между Serverless и Kubernetes для AI‑ворклоадов: как определить оптимальную платформу под задачу». Записаться

  • 22 июля, 20:00. «Что надо знать про работу LLM‑моделей». Записаться

  • 22 июля, 20:00. «От рутины к влиянию: как HR использовать ИИ в ежедневной работе». Записаться

  • 23 июля, 20:00. «Когнитивные архитектуры: ReAct, Reflection и RAG». Записаться

Разработка и архитектура

  • 20 июля, 20:00. «Асинхронное программирование в Android». Записаться

  • 20 июля, 20:00. «Как перестать писать на Java внутри Go‑проекта». Записаться

  • 21 июля, 20:00. «Данные в TOGAF. Где скрыты? Разбираемся в деталях». Записаться

  • 22 июля, 20:00. «Архитектура программ на C++: как управлять разработкой и функциями приложения». Записаться

  • 22 июля, 20:00. «DAO на Spring JDBC». Записаться

  • 23 июля, 20:00. «Основы многопоточности в Java». Записаться

  • 23 июля, 20:00. «malloc — кто же ты на самом деле?». Записаться

Тестирование и безопасность

  • 21 июля, 19:00. «Оценка трудозатрат в QA: как перестать ошибаться в сроках». Записаться

  • 21 июля, 20:00. «UI‑ и API‑тестирование с Java и Playwright». Записаться

  • 23 июля, 20:00. «Тестирование интернет‑магазина: от каталога до оплаты». Записаться

  • 23 июля, 20:00. «Фаззинг и реверс: как понять, что делает программа, и найти в ней ошибки». Записаться

Инфраструктура и сети

  • 20 июля, 20:00. «Проектирование адресного пространства. Основы сетей ЦОД». Записаться

  • 22 июля, 20:00. «VLAN на пальцах: изоляция трафика и маршрутизация». Записаться

Управление продуктами и командами

  • 22 июля, 20:00. «Как CTO управляет неопределённостью: оценки, планы и ожидания бизнеса». Записаться

  • 22 июля, 20:00. «Как собрать полный CJM — карту клиентского пути». Записаться

  • 22 июля, 20:00. «Операция "Воркшоп": как получить поддержку руководства для новой инициативы». Записаться

Больше открытых уроков июля смотрите в дайджесте.

Теги:
+9
Комментарии0
1
23 ...