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

ИИ-ассистент с долговременной памятью, агентами и vision - делал для себя. Память с весами и забыванием, разные модели под задачу, поиск по маркетплейсам с инъекцией профиля. Технически готов, но упёрся в 152-ФЗ: данные уезжают за рубеж, а GigaChat не может. История проекта + опрос что с ним делать.

У Claude Code есть одна неприятная особенность, про которую редко говорят вслух. Можно навесить на агента огромную библиотеку скиллов — дизайн, проектирование API, миграции БД, ревью безопасности, отдельные наборы под каждый язык, — и всё это будет честно лежать в ~/.claude/skills/. Нужный скилл почти всегда там есть. Проблема не в том, что его нет. Проблема в том, что про него надо вспомнить в нужный момент.

skill-compass решает ровно эту задачу. Это маленький хук для Claude Code, который смотрит на проект перед агентом и подсказывает, какие скиллы подключить — до того, как написана первая строка кода. Без зависимостей, один файл на Node, около 200 строк, которые читаются за один присест.

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

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

В [прошлой статье](https://habr.com/ru/articles/1049482/) я разбирала, почему классический QA ломается на LLM: нет одного эталонного ответа, один и тот же тест плавает от прогона к прогону, зелёный прогон ничего не гарантирует. Это была статья про осознание проблемы.

Эта — про то, как с этим жить в коде, когда агентов не один, а несколько.

Собрал на Claude Code конвейер авто-оценки качества вебинаров: локальная расшифровка whisper.cpp на Apple M4, LLM-судья по рубрике с цитатами и тайм-кодами, SQLite, письмо и дашборд. Главное оказалось не в промпте, а в методике: рубрика как данные, калибровка под методистов и то, чего текст расшифровки не тянет.

Хабр, привет! Меня зовут Егор Черепанов. Я аспирант Центра когнитивного моделирования МФТИ и младший научный сотрудник команды «Воплощенные агенты» лаборатории когнитивных систем искусственного интеллекта AIRI. Я занимаюсь памятью у роботов и RL‑агентов, и сегодня хочу рассказать об одной из наших работ — архитектуре ELMUR, которую мы представляли в апреле на ICLR 2026.

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

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

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

TL DR: Автор считает, что как только появится ИИ уровня исследователя, он создаст сверхразумный ИИ, а тот найдет способ сконструировать наномолекулярные фабрики на основе "технологий" которые применяются в биологических клетках, и которые бы отличались от клеток настолько, насколько самолет отличается от птицы, и сразу после этого войдет в конфликт с человечеством ради своих собственных целей, что быстро кончится в его пользу. Допускается любой другой сценарий, но если в результате него мы умрем это будет плохо, пнятненько?

Автор - известный исследователь в этой области Элиезер Юдковский, а также Нейт Соарес. Не могу точно ничего сказать о научных работах и плодах деятельности Юдковского (хотя он по крайней мере основатель сообщества LessWrong и автор нескольких научных статей), но для меня это всегда был талантливый писатель, чьи произведения оказали на меня существенное влияние.

Вводная часть

Идея создания собственного бота звучит сложнее, чем выглядит на практике. Многие представляют такую систему как нечто, доступное только программистам, системным администраторам или специалистам по искусственному интеллекту. На деле первый рабочий вариант можно собрать по понятному маршруту: подготовить рабочее место, настроить доступ к большой языковой модели (далее – БЛМ), установить несколько про-грамм, создать Telegram-бота, подключить интересующие Вас источники средств массовой информации (телеграмм-каналов) и выполнить тестовый запуск. Важнее всего делать всё по инструкции.

Карточки-инфографики (слайды), которые сопровождают подобные инструкции, показывают именно вышеуказанный алгоритм предлагаемой методики повышения Вашей круглосуточной ситуационной осведомленности. Они рассчитаны на обычного пользователя, которому демонстрируется, что «открыть», «куда нажать» и «как понять», а также убедиться, что этап методики завершен успешно. Такой бот должен отвечать простым и понятным для обывателя языком, объяснять термины, ссылаться на подготовлен-ные материалы и не выходить за пределы разрешенной образовательной среды.

Представьте, что с помощью Вашего телеграмм-бота и продвинутой нейронки Вы можете самостоятельно собрать качественный датасет Вашей предметной области (например, по военно-политическим силам в далекой африканской стране) АВТОМАТИЧЕСКИ, БЕЗ КРУГЛОСУТОЧНОГО РУЧНОГО МОНИТОРИНГА-ГУГЛИНГА, для после-дующего анализа, оценки и обработки отобранных актуальных данных (даже с использованием технологий прогнозирования).

Создать LLM-судью легко. Гораздо сложнее сделать так, чтобы его оценкам можно было доверять.

Мы убедились в этом на практике при разработке нейроразбора резюме для ИИ-помощника hh.ru. Быстро выяснилось, что хороший LLM-судья — это отдельный продукт со своими рубриками, датасетами, метриками качества и стоимостью эксплуатации.

Меня зовут Женя Орлов, я LLM Eval Lead. В этой статье расскажу, как мы проектировали систему оценки для нейроразбора резюме, почему отказались от наивных подходов и какие выводы сделали по ходу разработки.

Самые интересные новости финансов и технологий в России и мире за неделю: Куба встает на путь капитализма, Набиуллина вернулась и чуть-чуть снизила ставку, британцам делают интернет по паспорту, Илон Маск продолжает неистово богатеть и покупает Cursor в SpaceX, в слитой финотчетности OpenAI нашли рекордные убытки, а виртуальные очки от Snap поразили всех своей всратостью.

Это прямое продолжение статьи "meta-attention is all you need".

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

Так же будут предоставлена готовая легкая обученная обвязка для моделей, один малыш (Qwen-3.5-4b) и среднячок (Granite 4.1 8B). Все их можно будет запустить через llama.cpp.

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

В апреле я писал тут про PaydaDosh — открытый словарь и корпус ингушского языка. Та статья была про «вот, собрали всё в одном месте»: 66 тысяч статей, параллельный корпус, ИИ в разделе вопросов. С тех пор прошло два месяца, и проект перестал быть просто словарём. Мы начали строить грамматику — движок, который понимает, как устроено ингушское слово.

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

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

В феврале я публиковал первую статью про Yttri: что это за приложение, зачем я его делаю и почему мне не хватало Obsidian, Notion, почтового клиента, таск-трекера и AI-чата по отдельности.

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

С тех пор Yttri сильно изменился. Это уже не просто «единый интерфейс для всего», а более взрослая local-first среда: с открытыми markdown-данными, локальными моделями, агентом, почтой, задачами, заметками, финансами, записями встреч и нормальной доставкой тяжёлых AI-компонентов.

Сейчас я расширяю бета-тестирование и хочу позвать новых пользователей.

Мы в Beeline Cloud решили продолжить тему увольнений, найма и кадровых перестановок, происходящих под «нейросетевым соусом». Часть компаний сокращает вакансии джунов, делая ставку на (почти фанатичное) использование ИИ в разработке — и тратит на токены больше, чем на «человеческий персонал». Другие идут «против течения» и, напротив, активнее набирают выпускников вузов на младшие позиции с целью обеспечить преемственность поколений. Разберем ситуацию и обсудим мнения!

Недавно я решил перечитать рассказ «В исправительной колонии» Франца Кафки. Впервые я познакомился с ним еще студентом — задолго до того, как узнал о существовании профессии технического писателя.

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

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

Недавно в нашей команде продакт-менеджеру понадобился рабочий прототип dashboard-панели для демо партнёрам.

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

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

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

Самое интересное было даже не в скорости. Интереснее было то, кто мог продолжить работу дальше.

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

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

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

Аргумент про то что растёт выручка можно в 2026 читать ровно наоборот.

Пока подписки были щедро субсидированы, вопрос «а что мы с этого получаем» можно было не задавать. В первом квартале 2026-го фронтир-компании перевели корпоративных клиентов на оплату по токенам - субсидия кончилась, вопрос задали, ответ вернулся пустым. Uber сжёг весь годовой бюджет на токены за квартал, и его операционный директор честно признал, что не может провести линию от красивых метрик к отгруженной пользе. SemiAnalysis показал экономику на одного пользователя в лоб: на подписке за $200 в месяц можно сжечь токенов на $8–14 тысяч - провайдер доплачивает за то, что вы им пользуетесь. Meta через пару недель после того, как сама подстёгивала сотрудников жечь побольше токенов, ввела лимиты. Обе компании, по данным WSJ, обсуждают резкое снижение цен на и без того убыточный сервис. А отчёт KPMG про триумф агентного ИИ тихо сняли, когда выяснилось, что десятки ссылок в нём - галлюцинации модели, которой и поручили этот отчёт написать.

По сути - это схлопывание схемы финансирования.

И показательнее всего то, что миф о продуктивности рушится даже у тех, кто продаёт лопаты. 9 июня официальный аккаунт AWS - да, того самого Amazon, который зарабатывает на каждом вашем токене, - написал, что больше ИИ-кода не делает команду быстрее, а может и замедлить. Шесть миллионов просмотров. Когда поставщик инфраструктуры публично сдаёт главный тезис собственного маркетинга, это не оговорка - это «покажи окупаемость», пришедшее из самого замка. Свежий NBER подтверждает арифметику: строк кода стало больше, а реально отгруженных приложений - нет.

Мы уже разобрались с тем, что такое BaaS, почему появились Firebase и Supabase, чем они отличаются от обычного backend и можно ли самому собрать что-то похожее.

Как я и говорил в прошлой статье, сегодня мы наконец попробуем самостоятельно собрать альтернативу Firebase с Realtime исключительно на open-source компонентах!

Но важная оговорка: мы не будем делать полный клон Firebase с его тонной функционала, но мы соберем минимальную рабочую альтернативу, которую уже можно подключить к frontend через SDK и использовать почти как Firebase.

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

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